[05:32] <ameno> will the vanilla kernel build configs get synced/fixed?
[11:15] <amitk> jjohansen: Have you seen: pastebin.ubuntu.com/255032 ?
[11:49] <apw> smb, i see that 27.31 just dropped reverting something... might want to check we didn't slurp it up someewhere
[12:09] <amitk> seems like a nice reference to git: http://progit.org/book/
[12:54] <smb> apw, Thanks, seems we are safe. Did not find the original patch in our trees.
[12:54] <apw> smb, phew ...
[12:56] <amitk> ogra: should the bootloader be set to "flash-kernel" for dove as well?
[12:56] <amitk> ... to facilitate updates?
[12:56] <ogra> amitk, depends on the design NCommander develops
[12:56] <ogra> which he didnt document *anywhere*
[12:56] <ogra> (grmbl)
[12:57] <amitk> ogra: I assume it should be for imx51 atleast?
[12:57] <ogra> yes, for imx51 we use flash-kernel for updates (not as the bootloader indeed)
[12:58] <ogra> bootloader == redboot, flash-kernel is the upgrade tool for kernel and initramfs in flash
[12:58] <ogra> (where flash might be mtd or SD here )
[12:58] <amitk> ogra: ok, I've pushed that fix to the FSL branch (rtg, FYI). Will await your instructions for dove.
[12:58] <ogra> dove uses uboot as bootloader, i'm not sure how NCommander planned to implement it
[12:59] <rtg> amitk, did you change to uImage as the target (I haven't looked at all my email yet)
[12:59] <ogra> https://blueprints.launchpad.net/ubuntu/+spec/mobile-karmic-marvell-desktop is the dove spec
[13:00] <amitk> rtg: not yet. It requires adding the uboot-tools dependency. I'd much prefer NCommander to finish his design before making those changes.
[13:00] <ogra> right
[13:01] <ogra> nobody apart from him even remotely knows how the images will look like
[13:01] <rtg> amitk, I think all it requires from the kernel side is uboot-mkimage.
[13:01] <ogra> i asked him to document it already but seems he didnt yet, https://wiki.ubuntu.com/Specs/KarmicMarvellDesktop looks quite empty
[13:01] <ogra> right, for uImage you need a dep on uboot-mkimage
[13:02] <amitk> rtg: uuh, right. uboot-mkimage, not uboot-tools
[13:02] <ogra> and indeed make the build process call "make uImage" instead of zImage
[13:02] <ogra> i think thats a clear fact that we'll need it
[13:02] <ogra> marvell wont switch to another bootloader
[13:02] <amitk> true
[13:03] <ogra> i dont know how the whole rest of the bootprocess will look like though
[13:03] <ogra> theoretically we shouldnt need flash-kernel given that uboot should be able to read the kernel and initramfs binaries from disk
[13:05] <rtg> ogra, will you ever need udebs for Dove? I've disabled all but the nic-modules
[13:05] <ogra> we might at some point, not urgent now though
[13:05] <ogra> but i think your naming of the headers wil cause probs
[13:05] <ogra> http://paste.ubuntu.com/255034/ is a snippet from the livefs builder script
[13:06] <ogra> can you shuffle the name a bit for them ?
[13:06] <rtg> ogra, much like linux-image-* ? I suppose.
[13:06] <ogra> yeah
[13:07] <ogra> well, it even looks for linux-image-2* and linux-headers-2*
[13:07]  * apw waves to rtg.  i see you pulled in some of the abstraction stuff into the arm branches
[13:08] <rtg> apw, its where I actually developed the proof of concept. master came last
[13:08] <apw> ahh makes more sense when you think about it that way
[13:09]  * rhkfin_ wonders if #403656 aka CVE-2009-2692 (incorrect proto_ops initializations) will get a fix soon... (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/413656)
[13:09] <ubot3> Malone bug 413656 in linux "Local root exploit via CVE-2009-2692 (incorrect proto_ops initializations)" [Unknown,Confirmed]
[13:10]  * Nakkel wonders if anyone notices rhkfin_'s wondrings about #403656 aka CVE-2009-2692 (incorrect proto_ops initializations)
[13:11] <ogra> luckily that doesnt affct 9.04 at least
[13:11] <ath> really?
[13:11] <ath> why?
[13:12] <ogra> but #ubuntu-security would be the better place to ask about 8.10 and 8.04
[13:12] <ogra> because the 9.04 kernel sets vm.mmap_min_address to 65535 via sysctl, the issue only shows up if thats not the case
[13:12] <ogra> well, actually if its set to 0
[13:13] <ogra> but its definately a question for #ubuntu-security more than here
[13:13] <ath> cat /proc/sys/vm/mmap_min_addr
[13:13] <ath> 0
[13:13] <ath> Reaaallly safe
[13:13] <ln-> *definitely
[13:13] <ogra> well, thats not the default
[13:13] <mjg59> If you've got wine or dosemu installed you'll have it at that address
[13:14]  * rhkfin_ has 0 there too..
[13:14] <ogra> right wine wipes that setting
[13:14]  * rhkfin_ thinks it makes it an issue for 9.04 too...
[13:16] <ogra> but doesnt make it more on topic here :)
[13:16] <rhkfin_> -> #ubuntu-security...
[13:16] <ogra> right :)
[13:17] <rtg> apw, if you're OK with the abstracted-debian branch, then I'm just gonna do it for master, then make all of the topic branches work right with rebase.
[13:20] <apw> rtg am happy with it, i already implemented it for head on my abstracted-debian branch
[13:21] <apw> that contains the runes to allow it be reconstructed on any master
[13:21] <rtg> apw, I'd just planned on cherry-picking and squashing those 4 commits.
[13:21] <apw> it might be worth squashing 2-4 and leaving 1 as a separate entiry
[13:21] <apw> entity as that better lets someone implement the same on older trees
[13:22] <rtg> which we are going to do (smb^^)
[13:22] <apw> as the first is a 'programatic step' and 2-4 is just the delta
[13:22] <apw> ie can be cherry-picked back to older debian's
[13:22] <apw> but yes squash 2-4 for sure
[13:22] <rtg> apw, why don't you go ahead and push those changes the way you'd like to see them
[13:23] <smb> rtg, Was your comment about the branches or the security issue?
[13:24] <rtg> smb, about master as well as the topic branches.
[13:26] <smb> rtg, I have not followed to be honest. I know you had done some things to the karmic arm branches to make rebasing a simple rebase. But I had no time to look at what you actually did
[13:26] <rtg> smb, so now that yingying has slapped you around, are you gonna backport the igb driver?
[13:27] <apw> rtg i am guessing we could do the equivalent on just the branches on jaunty... ie make i safer by not modifying the master branch
[13:27] <smb> rtg, If that is completely new, why not. They could use a few new numbers to be a bit more diverse
[13:27] <apw> as the conversion there is the programatic step and then the patch on top
[13:27] <apw> that can just as well be in the branch
[13:29] <rtg> apw, why wouldn't we do Jaunty master? The rebase issues there are at least as problematic as they are for Karmic, what with the netbook and arm branches
[13:29] <lesshaste> hi all
[13:30] <apw> rtg we can, from a risk point of view we could choose to leave master alone but do the same trick inside the branch
[13:30] <apw> it depends how risk averse we are feeling
[13:30] <rtg> apw, these are build issues. I consider that to be pretty low risk, if not zero.
[13:31] <apw> fair enough
[13:31] <smb> apw, Likely most of it is in the buildenv, so at least it would be failing early
[13:31] <apw> yeah likely so, fair enough, i am convinced
[13:34] <apw> rtg shall i prepare a jaunty master delta to see how it looks?
[13:34] <rtg> apw, sure
[13:34] <apw> i am assuming you are handling karmic en-toto as its complex with the branches there
[13:34] <apw> then i can see how easy my jaunty netbook branch rebases too
[13:35] <rtg> apw, nope, just [ush the master branch changes and I'll fix the topic branches after the fact.
[13:35] <apw> ok i'll squash 2-4 and push that
[13:58] <amitk> rtg: fsl-imx51 doesn't need uboot (ATM)
[13:59] <amitk> only mvl-dove needs it for now
[13:59] <amitk> also, fsl-imx51 will still use zImage, while mvl-dove will use uImage
[14:07] <rtg> amitk, oops, wrong flavour.
[14:07] <ogra> as long as yu dont switch -generic to uboot :)
[14:08] <ogra> i suspect even grub2 wouldnt handle that :)
[14:16] <rtg> amitk, I just slammed HEAD on the fsl-imx51 branch to drop the build-dep patch
[14:17] <amitk> rtg: ack
[15:10] <gonzo_> Hi! Two questions: 1. Are the kernels at http://kernel.ubuntu.com/~kernel-ppa/mainline/ built from  http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-karmic.git;a=summary
[15:11] <gonzo_> 2. With the latest 2.6.31 kernels my DVB-T receiver stopped working. It seems that the modules are not built anymore. Is that known?
[15:15] <NCommander> rtg, ping?
[15:16] <rtg> apw, I though we were gonna squash the karmic master branch 'ARM: IMX51:' patches out of existence?
[15:16] <rtg> NCommander, yo
[15:17] <NCommander> rtg, I just wanted to compare notes w.r.t. to the dove kernel on the generation of the output files (I heard that the kernel packages are getting twisted to build uImages now)
[15:17] <rtg> NCommander, if that is what you want, then now is the time to make the change to uImage
[15:18] <NCommander> Well, I did a writeup of what I'm sorta hoping to get w.r.t. to filesystem layout in the Marvell spec (it was living on the internal wiki until earlier today: https://wiki.ubuntu.com/Specs/KarmicMarvellDesktop)
[15:18] <rtg> NCommander, I'll have a look. I'm in the middle of reorganizing the dove branch, so it'll be a bit.
[15:19] <NCommander> rtg, I'd appeicate your input in it
[15:19] <NCommander> oh right
[15:20] <ogra> using uImage saves extra hacks and the dove cant use a zImage anyway
[15:21] <NCommander> ogra, right, and then we can just update any boot script (if we use one, which I'm in favor of) as part of the postinst after the updated ramdisk is generated
[15:21] <ogra> beyond that marvell will take care of the load adresses change in the kernel tree and you dont need to make the up yourself
[15:21] <ogra> s/of/if/
[15:21] <ogra> s/the/them/
[15:21] <NCommander> ogra, load address changes?
[15:21] <ogra> for mkimage you need load adresses
[15:21] <NCommander> Right
[15:22] <NCommander> Oh, Marvell gave us a set of addresses to use for uImage/uRamdisk?
[15:22] <ogra> the kernel tree has some for uImage
[15:22] <ogra> mkimage wont run without proper load address
[15:22] <ogra> to create a uImage mkimage is run
[15:23] <NCommander> I was using the addresses from the sheevaplug, but I much rather use a more sancationed address :-)
[15:23] <NCommander> ^- ogra
[15:23] <ogra> right, make uImage will set the ones definaed by marvell
[15:23] <NCommander> \o/
[15:23] <ogra> *defined
[15:23] <NCommander> Yay for making life easier
[15:23] <ogra> thats how make uImage works
[15:24] <NCommander> Ah, I didn't know there was a pre-existing target in the Marvell kernel tree to spit out a uImage
[15:25] <ogra> so the only change you will need will be to initramfs-tools
[15:25] <ogra> if you even need a uInitramfs
[15:30] <amitk> NCommander: the 'make uImage' target isn't just in the Marvell kernel tree. Upstream kernels also support it IIRC
[15:31] <apw> rtg, we were and erm did
[15:31]  * apw looks whats occured
[15:31] <rtg> apw, they appear to be back in the repo
[15:31] <apw> yes they do
[15:32] <NCommander> amitk, that's good to know
[15:32]  * apw must have the original branch here somewhere
[15:36] <amitk> ogra: what command are you running?
[15:37] <ogra> i run fakeroot debian/rules binary, kill that if i see it starting to build (assuming it configured) and then run make uImage
[15:37] <rtg> apw, I'm wondering if I didn't do it because of the way I rebase against origin/master.
[15:37]  * ogra knows thats wrog but seemed the fastesr
[15:37] <ogra> *fastest
[15:37] <apw> rtg as in you think you might have undone it?
[15:38] <amitk> ogra: use fakeroot debian/rules prepare-dove
[15:38] <rtg> apw, right. after you pushed I likely did 'git fetch origin;git rebase origin master'. Since I still had those commits in my master branch, then I probably pushed 'em back out.
[15:38] <apw> hmm perhap :/
[15:38] <ogra> ogra@dove:~/kernel/mvl-dove$ fakeroot debian/rules prepare-dove
[15:38] <ogra> make: *** No rule to make target `prepare-dove'.  Stop.
[15:39] <amitk> ogra: the prepare target will create the debian/build dire
[15:39] <ogra> hrm
[15:39] <amitk> are you on the dove branch?
[15:39] <apw> well i can get rid of them again in short order
[15:39] <ogra> i thought so
[15:39]  * ogra curses git once again
[15:39] <rtg> apw, I've already done that.
[15:39] <rtg> I'll just re-push, OK ?
[15:39] <apw> rtg ok then
[15:39] <ogra> ogra@dove:~/kernel/mvl-dove$ git branch
[15:39] <ogra> * master
[15:39] <apw> absolutly
[15:39] <ogra> meh
[15:40] <bjf> ogra, building that way in the dove/mvl branch isn't working
[15:40] <ogra> how do i have to build it then ?
[15:40] <apw> rtg do the dove and imx51 branches have my patch to allow all targets trhough?
[15:40] <ogra> right, git fetch only gets me
[15:40] <ogra>  + ba9ee58...a5dde05 fsl-imx51  -> origin/fsl-imx51  (forced update)
[15:40] <ogra>  + b5c2598...a436a05 master     -> origin/master  (forced update)
[15:41] <bjf> ogra, you need to:debuild --no-lintian -eCROSS_COMPILE=arm-none-linux-gnueabi- --prepend-path=/home/toolchains/arm-2009q1/bin -b -aarmel -us -uc
[15:41] <rtg> apw, not yet. I'm in the middle of it.
[15:41] <ogra> bjf, no
[15:41] <apw> ahh so prepare-dove won't work
[15:41] <bjf> ogra, no?
[15:41] <apw> you would need to do fakeroot debian.mvl-dove/rules prepare-dove to get it to work
[15:41] <ogra> bjf, a) i dont crossbuild, b) i dont want to use debuild, amitk wants the binary from make uImage
[15:41] <apw> that will be fixed shortly
[15:42] <rtg> apw, master HEAD pushed. I suggest you make sure your update doesn't recreate those damn IMX51 patches.
[15:42] <apw> heh yep am updating now to make sure it doesn't
[15:42] <amitk> ogra: make ARCH=arm CROSS_COMPILE=arm-linux- O=`pwd`/../build/
[15:43] <amitk> ogra: you'll need to create a ../build and copy the .config there first, though
[15:43] <apw>  fakeroot debian.mvl-dove/rules prepare-dove
[15:43] <rtg> amitk, dove won't build out of tree yet
[15:43] <apw> somthing like that ought to get it prepared in theory
[15:43] <ogra> it did so last week
[15:43] <amitk> ohh right, drop the O=
[15:43] <ogra> the kernel i currently run is built from your mvl-dove tree
[15:44] <apw> ogra, yeah but someone keeps wanting machinary changes, and they have risk of breakage
[15:44] <apw> :)
[15:44]  * ogra hugs apw
[15:44] <ogra> that seems to work :)
[15:44] <apw> ogra, that should get fixes shortly when we rebase those trees onto the new abstracted stuff
[15:44] <ogra> sure, i only care about an uImage to give feedback to amitk
[15:45]  * ogra doesnt want to touch the packaging :)
[15:45] <apw> rtg on this abstracted form for jaunty... it occurs to me we are also going to want the stuff to allow us to change the source package name and the like
[15:45] <rtg> apw, correct
[15:45] <apw> and so i am thinking that actually i should really be looking to take the karmic machinary
[15:45] <apw> and all the nice fixes therein
[15:45]  * amitk steps out for a bit
[15:45] <rtg> apw, agreed
[15:45] <apw> good.  thats much easier (i hope)
[15:46] <bjf> ogra, are you talking mvl or fsl?
[15:46] <ogra> mvl
[15:46] <rtg> apw, my goal is to have the packaging for all branches in all repos look mostly the same.
[15:46] <apw> yeah so thats also the right thing that way
[15:46] <ogra> bjf, amitk wants to know if the resulting uImage from make uImage works fine so we can enable it in the package
[15:47] <jjohansen1> amitk: no I haven't seen pastebin.ubuntu.com/255032, where did you hit it
[15:47] <ogra> instead of running make zImage
[15:47] <ogra> apw, hmm, still fails with "make: *** No rule to make target `include/config/auto.conf', needed by `include/config/kernel.release'.  Stop."
[15:48] <bjf> ogra,ok
[15:48]  * ogra just ran make oldconfig now ... seems to work
[15:49] <ogra> though it used my existing /boot/config-2.6.31-0-dove apparently
[16:04] <amitk> jjohansen1: just saw it randomly on my laptop (rebooted since and not seen)
[16:05] <amitk> bjf: make uImage is a supported target in the kernel. If that works already, then we don't have to do postinst munging of zImage to uImage. Therefore, I asked someone who had the HW to test if the resulting kernel is bootable.
[16:06] <amitk> I recall that sometimes the kernels aren't bootable (wrong addresses, perhaps)
[16:06] <ogra> amitk, well, it definately worked on friday i'm currently running that uImage on my dove
[16:06] <jjohansen1> amitk: hrmm okay that is a strange failure
[16:06] <ogra> i just dont have the latest merges
[16:07] <ogra> but i doubt they change anything wrt mkimage
[16:07] <bjf> amitk, I had been building that way before this last week and I was giving the mobile guys my uImage to test with
[16:07] <amitk> ogra: but you did a manual mkimage then, right?
[16:07] <bjf> amitk, that had/has been working
[16:07] <ogra> amitk, no
[16:07] <ogra> amitk, oh, sorry, i did
[16:08] <ogra> i used debuild and used the vmlinuz from that package
[16:08] <bjf> amitk, the issue right now is that the work that rtg and apw have been doing has "changed" things a bit
[16:09] <amitk> bjf: ok, great. Then we should change rule.d/vars.armel in the mvl branch (build_image = uImage, kernel_file= arch/$(build_arch)/boot/uImage, etc.)
[16:09] <bjf> amitk, yes
[16:10] <rtg> amitk, don't forget the prerm, postinstall, etc scripts
[16:10] <amitk> ack
[16:10] <amitk> rtg: does this new debian.* world order mean that all the debian.* directories are in the master branch?
[16:11] <rtg> amitk, yeah, have a look at Karmic master. There is now a debian.master
[16:11] <rtg> the only thing under the debian directory is rules.
[16:12] <rtg> s/thing/file/
[16:12] <rtg> and some other invariant stuff
[16:12] <amitk> doesn't debuild complain (about the relatively empty debian/ dir)?
[16:13] <rtg> amitk, run 'fakeroot debian/rules clean' first
[16:15] <amitk> rtg: I see it now. But can't _all_ the debian.* directories now live in the master branch? That way all the topic branches only muck with code.
[16:15] <apw> amitk, the debian.branch is still only in the branch currently
[16:15] <apw> if you do that, to change something which needs to add code and modify configs say
[16:15] <apw> you would have to commit half to master, the other half to branch and then rebase the branch to get the whole
[16:16] <apw> or somthing nasty like that
[16:16] <rtg> amitk, I found that the packaging rules vary enough across topic branches that it was simpler to just separate them out.
[16:16] <amitk> ok
[16:57] <cking> **
[16:57] <cking> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[16:57] <cking> **
[17:07] <rydberg> I have a question regarding suspend problems in 2.6.31-6-generic not present in v2.6.31-rc6
[17:08] <rtg> rydberg, rfkill related?
[17:10] <rydberg> Hello Tim, long time no see. I cannot say, sorry - was just wondering if these problems seem common, and thus whether I should simply wait with whistle-blowing until after karmic catches up with rc6. I guess from your answer that it is common indeed.
[17:11] <rtg> rydberg, we did note some suspend issues with bluetooth. try 'sudo rfkill block all' prior to suspending.
[17:11] <rtg> if you indeed have bluetooth.
[17:12] <ogra> amitk, http://paste.ubuntu.com/255224/ ... lets see if it boots now :)
[17:12] <rydberg> i usuall keep it off, but i will have a look anyways, thanks for the tip
[17:24] <rydberg1> rtg, no dice using 'rfkill block all'. What does work so far is a pristine rc6, without ramdisk.
[17:31] <rtg> rydberg1, what is your platform?
[17:33] <rydberg1> its a macbook air 1,1 running karmic alpha 4 plus updates. I just noted there were updates in the karmic kernel today, I will try building those and report back
[17:33] <rtg> rydberg1, its just packaging changes. I doubt it'll have any effect
[17:34] <rydberg1> oh, ok
[17:34] <rtg> you have ath5k wireless?
[17:35] <rydberg1> the bcm4328, which works with the bcmwl dkms package
[17:35] <rtg> rydberg1, try 'sudo modprobe -r wl' before suspending.
[17:35] <rydberg1> oki
[17:35] <smb> apw, FYI, I pushed all repos
[17:36] <apw> ack, thanks
[17:36] <rydberg1> nope, still hangs with blinking cursor on suspend
[17:37] <apw> you might want to boot with no_console_suspend, and then perform the suspend from VT-1 using sudo pm-suspend
[17:37] <rtg> rydberg1, do you still have older Ubuntu kernels installed, like 2.6.31-5.24 ?
[17:38] <rydberg1> thanks apw, ive been doing all those things, there is a distinct difference in behavior between ubuntu-2.6.31-6 and v2.6.31-rc6
[17:39] <rydberg1> trying the 2.6.31-5 now
[17:44] <rydberg1> same thing there, not suspending but hanging. i am happy to wait with further testing until a rc6 rebase, i am hopeful it will work
[17:45] <apw> 2.6.31-6 is an -rc6 rebase?
[17:45] <rydberg1> i thought it was rc5?
[17:46] <apw> nope its definatly an -rc6 rebase
[17:47] <rydberg1> i just read the git tree, couldnt find the rebase point but that changes things drastically. Ok, ill dig a bit more
[17:48] <apw> the -rc6 kernel you are testing, is that our mainline build?
[17:48] <rydberg1> its staight off linus' tree
[17:48] <bjf> apw, the reading back he tested 2.6.31-5 not 2.6.31-6
[17:48] <apw> $ git show `git merge-base linus/master Ubuntu-2.6.31-6.25`
[17:48] <apw> commit 64f1607ffbbc772685733ea63e6f7f4183df1b16
[17:48] <apw> Author: Linus Torvalds<EMAIL_ADDRESS>[17:48] <apw> Date:   Thu Aug 13 15:43:34 2009 -0700
[17:48] <apw>     Linux 2.6.31-rc6
[17:49] <apw> rydberg1, can we confirm which ones of ours you have tested?
[17:50] <rydberg1> i have tested the two packages 2.6.31-6-generic and 2.6.31-5-generic
[17:50] <rydberg1> and i have tested the -rc6 from linus, without ramdisk
[17:50] <rydberg1> the two former hangs on suspend, the latter works flawlessly, both suspend and resume
[17:50] <apw> that implies the bug is in our delta, so you could consider doing a bisect between -rc6 and Ubuntu-2.6.31-6.25
[17:51] <rydberg1> yep
[17:53] <rydberg1> "day" means US day time, I suppose? this will take a couple of hours :-)
[17:59] <apw> day ?
[17:59] <rydberg1> as in bug day - im in europe
[18:00] <ogra> bug days in ubuntu usually span across all timezones
[18:01] <rydberg1> long working hours, then :-)
[18:01] <ogra> starting at NZ moring and ending in pacific evening
[18:02] <ogra> well, the ubuntu developer and bugtriager teams span across the whole world ;)
[18:02] <ogra> (as well as the users reporting bugs :) )
[18:03] <Q-FUNK> ogasawara: thanks for subscribing yourself to the bug :)
[18:03] <rydberg1> rtg, apw: ill start off verifying the problem between 64f1607ffbbc772685733ea63e6f7f4183df1b16 and the karmic head, just to make sure its not my kernel config that makes it work
[18:03] <apw> sensible idea
[18:28] <rydberg1> tlsup seems to have a problem compiling here, same for you?
[18:29] <ogasawara> dhillon-v10: hi!  thanks for sitting in on the meeting
[18:29] <dhillon-v10> ogasawara: Hi how are you
[18:30] <ogasawara> dhillon-v10: great, so you mentioned you'd be interested in helping out
[18:30] <dhillon-v10> ogasawara: yes how can I get started
[18:30] <ogasawara> dhillon-v10: one of the biggest problems we face as a team is dealing with a large volume of bugs coming in
[18:31] <ogasawara> dhillon-v10: I think dealing with some of these bugs would be a great starting point
[18:31] <dhillon-v10> ogasawara: yah I read that in the wiki, I am actually working with Ubuntu-doc team in the wikis and such
[18:32] <ogasawara> dhillon-v10: awesome.  we can also always use help cleaning up or documentation on the wikis also
[18:32] <dhillon-v10> ogasawara: :)
[18:32] <ogasawara> dhillon-v10: as it happens, today we're holding a kernel bug day
[18:33] <dhillon-v10> ogasawara: I am subscribed to the mailing list and I get a lot of bugs in my mail but I can't solve any of them can you help me with that
[18:33] <dhillon-v10> ogasawara: most of them are sound related, I mostly work in computer vision
[18:33] <ogasawara> dhillon-v10: sure, do you have a list of them you can point me to
[18:34] <dhillon-v10> ogasawara: please elaborate yourself, I don't get it
[18:35] <ogasawara> dhillon-v10: you mentioned you have some sound related bugs which you'd like to try to work on, I'm wondering if you have specific bug #'s we can work through
[18:35] <dhillon-v10> ogasawara: oh sure just one sec.
[18:36] <dhillon-v10> ogasawara: how about this one: Bug 414977
[18:36] <ubot3> Malone bug 414977 in pulseaudio "in karmic, any application being started mutes the volume" [Undecided,Fix committed] https://launchpad.net/bugs/414977
[18:37] <ogasawara> dhillon-v10: hrm, that's reported against pulseaudio (ie not the kernel) but it seems Daniel's commited a fix?
[18:38] <ogasawara> dhillon-v10: I do know that the upgrade to pulseaudio 0.9.16 cause some regressions
[18:38] <ogasawara> dhillon-v10: which I believe they are trying to resolve by uploading test packages to their PPA
[18:40] <dhillon-v101> ogasawara: sorry about that
[18:41]  * apw ^5's ogasawara
[18:41] <apw> ogasawara, i've rearranged the regressions review to next monday, sorry we forgot yesterday even though you were ahead
[18:41] <dhillon-v10> ogasawara: my internet just  got disconnected, I fixed that
[18:41] <apw> and got it out on time
[18:42] <rydberg1> rtg, apw: 64f1607f: good (suspends, resumes)
[18:42] <ogasawara> apw: no worries, wasn't much to review this week anyways
[18:42] <rydberg1> rtg, apw: ad1dfe69: good (suspends, resumes)
[18:42] <rydberg1> rtg, apw: thus the problem lies somewhere in the configuration, not the tree itself (phew, saved me a couple of hours of bisecting :-))
[18:42] <dhillon-v10> ogasawara: So what was that you were saying before my Internet got disconnected
[18:43] <apw> ogasawara, we did meet this morning in and doa  quick review
[18:43] <apw> rydberg1, interesting, now to bisect the configuration delta
[18:43] <ogasawara> [10:37:40] <ogasawara> dhillon-v10: hrm, that's reported against pulseaudio (ie not the kernel) but it seems Daniel's commited a fix?
[18:43] <ogasawara> [10:38:33] <ogasawara> dhillon-v10: I do know that the upgrade to pulseaudio 0.9.16 cause some regressions
[18:43] <ogasawara> [10:38:49] <ogasawara> dhillon-v10: which I believe they are trying to resolve by uploading test packages to their PPA
[18:44] <ogasawara> dhillon-v10: do you have another kernel bug we could look at?  Or I can put together a list for us to work through.
[18:44] <dhillon-v10> ogasawara: I think you should put together a list, thanks
[18:44] <ogasawara> dhillon-v10: would you prefer to target sound related bugs?  If not, I'll assemble a variety.
[18:45] <dhillon-v10> ogasawara: I doesn't really matter :)
[18:46] <ogasawara> dhillon-v10: ok, care to privately msg me your email address and I'll send you a good starter list with instructions
[18:46] <dhillon-v10> ogasawara: how do I do that
[18:46] <ogasawara> I'll message you
[19:01] <dmclain> Whats the equivalent of kern.maxproc for Ubuntu?
[19:02] <dmclain> in /etc/sysctl.conf?
[19:04] <dmclain> Whats the equivalent of kern.maxproc for Ubuntu in /etc/sysctl.conf?  I didn't see a default in there for it, but I think I need to set it higher than the default for the box.
[19:40] <Q-FUNK> ogasawara: is there anything I should do, now that we narrowed down the source of the regression and attached screenshots?
[19:42] <ogasawara> Q-FUNK: I pasted the bad commit we bisected to the upstream bug report so hopefully it'll get passed along
[19:42] <ogasawara> Q-FUNK: I noticed that in the thread on LKML you'd posted that another user mentioned they were not seeing issues . . .
[19:43] <ogasawara> Q-FUNK: looking at the config they posted it seems they have CONFIG_FS_POSIX_ACL list disabled so they won't be affected by that patch
[19:43] <Q-FUNK> ogasawara: I mentioned this earlier as well and attached that user's config to the LP bug.
[19:43] <ogasawara> Q-FUNK: since the bad patch is ifdef'd with CONFIG_FS_POSIX_ACL
[19:43] <Q-FUNK> indeed
[19:43] <ogasawara> Q-FUNK: you did?  maybe I missed that
[19:44] <Q-FUNK> good point
[19:44] <Q-FUNK> I'll reply to him and point this out
[19:47] <ogasawara> Q-FUNK: if you like, I can build you a test kernel with that config disabled
[19:48] <ogasawara> Q-FUNK: else we can try to revert that commit, but I recall it didn't revert cleanly on the latest Karmic
[19:48] <Q-FUNK> ogasawara: sure, why not.  against 2.6.31-rc6 ?
[19:48] <ogasawara> Q-FUNK: yup
[19:48] <Q-FUNK> ogasawara: sure, let's have a go at it
[19:49] <ogasawara> Q-FUNK: k, gimme a bit, I have to queue up another build first but you're next in the queue
[19:49] <Q-FUNK> ogasawara: ok, fair enough :)
[19:53] <apw> rtg ok i've reconstructed abstracted debian against jaunty before smbs latest pushed its here:   git://kernel.ubuntu.com/apw/ubuntu-jaunty abstracted-debian
[19:53] <apw> will update it shortly to the latest tip#
[19:55] <apw> smb, am i only expecting to find one new tag in jaunty?
[19:55] <smb> apw, In theory there should be one new one, yes. Why?
[19:56] <apw> i was expecting a tag for security and a new proposed one?
[19:56] <smb> apw, Which proposed? :)
[19:57] <apw> we have no -proposed to jaunty now then i guess?
[19:57] <smb> apw, Right, the old one just was accepted and I had no time to create the new one
[19:57] <apw> ok cool thanks, thought i was going mad for a sec there
[19:58] <smb> apw, Relax, its just me being slow
[19:58] <apw> heh no i think thats the definition of _me_ being slow :)
[19:59] <smb> Heh, lets agree on that it is past beer o' clock for both of us. We are entitled to being slow. :)
[19:59] <apw> yeah thats all very true, and worse my beer store is empty
[19:59] <apw> i must go get some more asap
[19:59] <smb> Not even cider?
[19:59] <apw> nope ... not a drinkable thing other than ... water
[20:00] <smb> eek. thats an emergency
[20:01] <rydberg1> bring some for the rest of us, too :-)
[20:01] <apw> heh a plan indeed
[20:03] <smb> We should pre-order for Portland. The bars tend to get out of stock if we arrive. :)
[20:08] <rydberg1> quite the contrary happened when Las Vegas hosted the yearly American Physical Society conference: they were kindly asked never to return :-)
[20:09] <rtg> apw, looks good. i assume you test built?
[20:17] <rtg> apw, you're gonna have to rebase your Jaunty abstracted-debian branch against Ubuntu-2.6.28-15.49
[20:19] <rydberg1> rtg, apw: ad1dfe69 with config-2.6.31-6-generic: fail (hangs on suspend)
[20:19] <rydberg1> looking at suspicious modules now
[20:20] <smb> rtg, apw I might make a new proposed tomorrowish. Maybe it is more worth the effort to rebase against that...
[20:21] <rtg> smb, lets get it tip of the tree soonish
[20:22] <smb> rtg, I guess apw and me will sort things out tomorrow morning
[20:23] <rtg> bjf, amitk, git://kernel.ubuntu.com/rtg/ubuntu-karmic fsl-imx51 for a preview of the havoc I'm gonna wreak on your branch
[20:29] <bjf> rtg, debuild: fatal error at line 630:
[20:29] <bjf> cannot find readable debian/changelog anywhere!
[20:29] <bjf> Are you in the source code tree?
[20:29] <rtg> bjf, fdr clean first
[20:30] <bjf> rtg, ok, thats working, when we settle on this we'll need to do some wiki updating
[20:30] <rtg> bjf, right. my hope is to have all of the topic branches behave the same way.
[20:37] <bjf> rtg, I'm looking at that tree & branch, what should I notice?
[20:37] <rtg> bjf, just make sure I didn't lose any IMX51 patches.
[20:38] <bjf> rtg, that's kind of hard to tell, I'm not sure what amit commited
[20:38] <rtg> bjf, do you HW to run the kernel on?
[20:39] <bjf> rtg, that's part of the reason I went back and reapplied *all* the patches to jaunty, I don't have to remember what I did or didn't apply
[20:39] <bjf> rtg, however, it was/is harder for amit since the patches are against .28 not .31
[20:39] <rtg> bjf, yeah, well, the fsl-imx51 branch was a little disorganized wrt to master because of the way the rebase script works
[20:40] <bjf> rtg, well my build of the mvl-dove branch worked just fine
[20:41] <apw> rtg yep, already done here, will push it shortly (rebase to smb's latest tag) will get with him to get it on tip in the am
[20:41] <rtg> bjf, the dove branch is much simpler right now because its not  a rebase against master, its just the debianiozed build system for the kernel that Marvell provrides.
[20:41] <rtg> apw, thanks
[20:42] <rtg> apw, as soon as you have that sorted in the  AM, how about tackling the netbook branch?
[20:42] <bjf> rtg, is your plan to rebase the dove branch against master?
[20:43] <rtg> bjf, the dove branch _is_ rebased against master
[20:43] <rtg> (or will be when I push it)
[20:44] <rtg> bjf, shit, never mind. the dove branch won't get rebased against master until Marvell produces a 2.6.31 final.
[20:44] <bjf> rtg, ok, you said earlier it wasn't, look forward to your push
[20:44] <rtg> bjf, it's fsl-imx51 thats currently rebased against master (when I push it)
[20:45] <apw> rtg absolutly, my plan is to get the thing on tip and get smb to review, as he's not seen it yet
[20:46] <apw> and in parallel frig it onto the current netbook branch, and then prove that a rebase works
[20:46] <bjf> rtg, the packaging stuff you have been hashing out with mobile guys and with cjwatson, is that all handled in the "meta" package
[20:48] <rtg> bjf, the meta package is a bit of a different animal. its the package we use to maintain upgradeability when the kernel package name changes.
[20:55] <rydberg1> rtg, apw, current status: the config-2.6.31-6-generic breaks the karmic head, compared to a slimmed custom configuration. Will take a while to single out the configuration culprit (taking a break now).
[21:29] <Q-FUNK> ogasawara: can you put the link to this new kernel on the bug, when it's ready?  I'll be heading to bed soon here.
[21:30] <ogasawara> Q-FUNK: will do
[21:34] <Q-FUNK> ogasawara: thanks! :)
[21:34] <NCommander> apw, did you ever get a chance to apply the sparc config patch i sent to you?
[21:36] <apw> NCommander, remind me of the patch, i thought i saw all the patches get pulled, but i may have blinked
[21:38] <NCommander> apw, it was the patch that fixed the d-i folder to disable all the modules that couldn't be built on SPARC (like DAC960), and a few config tweaks)
[21:38] <NCommander> apw, I can resend/paste-bin it if need be
[21:39] <apw> was there a subject
[21:39] <apw> so i can check
[21:39] <NCommander> apw, probably SPARC configuration
[21:43] <apw> NCommander, resend it and i can check
[22:18] <ghostcube> hi i just wanted to know if anyone is taking care about the mainline kernels too
[22:18] <ghostcube> :)
[22:18] <ghostcube> or is this only release support
[23:42] <Fjodor> Hi guys. Does anyone know what happened to the gspca driver in the 2.6.31-rc series from http://kernel.ubuntu.com/~kernel-ppa ?
[23:56] <ghostcube> hmm i have a problem with mainline 2.6.31rc6 and winbond chipdriver with lmsensors
[23:56] <ghostcube> it doesnt load the modul rc5 does


[00:08] <qwebirc98148> a
[00:12] <qwebirc98148> New to mythTV and attempting the 'easy' way... compiled all-in-one 14.0.4.  Install goes well until attempting to config backend.   On General, install will not allow edit of loopback <IP_ADDRESS>, to real IP.
[02:57] <dmfrey> anyone know how to disable the vision impaired audio track while playing a video in the video library?  This is only playing new as of a fresh install of 14.04.1
[02:58] <dmfrey> this is occurring on mkv bluray rips


[02:18] <tsimonq2> wxl: I am getting a consistent bug with all of the Trusty daily images, bug 1417918
[02:18] <tsimonq2> wxl: Please take note of that
[05:40] <ianorlin> bug 1496293
[16:07] <phillw> wxl: Just had confirmation from Julien that 15.10 desktop ISO will be DVD size. Alternate will remain CD sized.
[16:08] <tsimonq2> nice to know


[00:12]  * netritious is just not as close to his PC as he used to be
[00:12] <netritious> proximity wise....I know it misses me when I'm not tickling the keyboard
[00:12] <netritious> so how have you guys been Unit193, wrst?
[00:18] <Unit193> Alive, and now that Nov4 is over, better.  Also sorry to hear. :(
[15:14] <netritious> On another note, having a problem with VLC on windows: http://i.imgur.com/o3QUFaM.jpg?1
[15:15] <netritious> ^^via reddit. avoided that site what seems like forever, now partially addicted.
[16:15] <netritious> anyone here still using ubuntu?
[17:13] <wrst> netritious: I do some
[17:51] <netritious> me to wrst, although it's been a while since I installed. Still running 12.04 on a LXC server.
[17:53] <wrst> I also install it for several people
[18:07] <netritious> I have to upgrade a family from 12.04 to 14.04. Upgrading them from 10.04 to 12.04 was stupid easy...hoping I have the same luck this go around.
[18:10] <average_guy> I've done the auto-upgrade from 12.04 to 14.04 with no problem netritious, shood work
[18:10]  * average_guy crosses fingers
[18:13] <netritious> I've only had an upgrade problem when I decided to go from 8.04->10.04->12.04 on a server, but they weren't unsolvable ones.
[18:15] <wrst> init system changeoever in some of that I guess?
[18:15] <netritious> iirc the biggest prob was none of my beep scripts worked any more. I think I had to edit the modules blacklist and comment pcspkr or something like that.
[18:16] <wrst> ahh ok
[18:19] <netritious> on a headless system I find beep invaluable for knowing when a long running process is finished, or to get periodic notifications on a series of long processes.
[18:22] <netritious> eg when building rainbow tables, which takes /forever/
[18:39] <wrst> makes sense
[18:48] <average_guy> gpu cracking is what's hot now-a-days I hear
[18:48] <average_guy> http://blog.ircmaxell.com/2011/08/rainbow-table-is-dead.html
[18:48] <average_guy> http://arstechnica.com/security/2012/12/25-gpu-cluster-cracks-every-standard-windows-password-in-6-hours/
[18:54] <netritious> I agree, just giving an example. I still have tables around here somewhere. Not bad for checking weak passwords on the spot with a $200 laptop.
[19:07] <netritious> I like that blog. Good info average_guy
[19:08] <netritious> and looks like when I find that drive I can format it and put it to use for something else lol


[00:19] <guiverc> jailbreak, use today's lubuntu daily & you'll get both (oops); we'll fix that though
[00:19] <jailbreak> damn.... not what I wanted to hear. snap is cancer
[00:19] <jailbreak> Maik: yeah makes no sense
[00:20] <jailbreak> I guess I'll be trying debian or mint then :-S
[00:20] <guiverc> snap browsers provide greater security protection though; as browser is confined with limited access to your / fs
[00:20] <jailbreak> yeah but slow down, not a good thing
[00:21] <jailbreak> you tried opening chromium after a reboot with snap? even on quick systems it's long
[00:21] <guiverc> slower to start yeah, but having used chromium as snap since mid-2019 it's about equal speed wise
[00:21] <jailbreak> I use this: #!/bin/bash /snap/chromium/current/usr/lib/chromium-browser/chrome $* && exit
[00:22] <jailbreak> opens instantly, hopefully there's a way to do something like that with FF
[00:28] <guiverc> the initial run of a snap is slower (it's got a confined space to setup; ie. added security cost), but as stated once it's running I find it about equal; and I'm on a 2009 dell desktop here (ie. hardly a modern box; pre-intel-i series era; ie. c2q, but I find same on i5 etc)
[04:37] <lotuspsychje> anyone got a bug ID handy of system problem detected on ubuntu-advantage-desktop-deamon?
[04:37] <lotuspsychje> second day it popups for me on -desktop
[06:40] <alkisg> jailbreak: you can get firefox.deb from the PPA: https://launchpad.net/~mozillateam/+archive/ubuntu/ppa
[23:04] <JanC> alkisg: is that supposed to stay?
[23:10] <JanC> sounds like Firefox are really planning to force people to use old insecure versions (not just this snap thing but also the fission changes that eat all your RAM)
[23:28] <JanC> Ubuntu should just rename Firefox to Ubuntu Browser and see if Mozilla really prefer that more...


[17:44] <Asad2005> How to upgrade from 16.04 to 16.10 beta command line i tried update-manager -d and do release upgrade but no beta showing
[22:35] <hggdh> Asad2005: you probably are set to only upgrade to  "lts" releases. Check /etc/update-manager/release-upgrades, and change Prompt to "normal"
[22:37] <hggdh> Asad2005: anyway, unless you are willing to risk your install being broken, and *KNOW* how to re-glue the pieces together, this is not a good time to move to 16.10
[22:37] <hggdh> Asad2005: with that warning given, I had no problems with 16.10
[22:39] <hggdh> huh. Let me rephrase it: I had no *serious* problems with 16.10
[22:40] <hggdh> (upgrade barfed at the end, but far enough for the system to be functional; some packages tried to wrongly uninstall others because they were released too early; etc)


[00:05] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[00:05] -kubuntu-ci:#kubuntu-devel- Project mgmt_merger build #1056: FIXED in 5 min 36 sec: https://kci.pangea.pub/job/mgmt_merger/1056/
[00:05] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[00:05] -kubuntu-ci:#kubuntu-devel- Project mgmt_progenitor build #1034: FIXED in 5 min 38 sec: https://kci.pangea.pub/job/mgmt_progenitor/1034/
[00:05] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[00:05] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_ktextwidgets build #38: FIXED in 16 min: https://kci.pangea.pub/job/bionic_unstable_ktextwidgets/38/
[00:06] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[00:06] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_kglobalaccel build #77: FIXED in 17 min: https://kci.pangea.pub/job/bionic_unstable_kglobalaccel/77/
[00:26] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_gcompris build #84: STILL FAILING in 19 min: https://kci.pangea.pub/job/bionic_unstable_gcompris/84/
[00:32] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[00:32] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_kiconthemes build #61: FIXED in 26 min: https://kci.pangea.pub/job/bionic_unstable_kiconthemes/61/
[00:36] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_kcharselect build #40: FAILURE in 4 min 38 sec: https://kci.pangea.pub/job/bionic_stable_kcharselect/40/
[00:37] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_krfb build #63: FAILURE in 5 min 40 sec: https://kci.pangea.pub/job/bionic_stable_krfb/63/
[00:39] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_libkipi build #92: FAILURE in 6 min 58 sec: https://kci.pangea.pub/job/bionic_stable_libkipi/92/
[00:39] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_kruler build #63: FAILURE in 7 min 3 sec: https://kci.pangea.pub/job/bionic_stable_kruler/63/
[00:39] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_kcolorchooser build #58: FAILURE in 7 min 7 sec: https://kci.pangea.pub/job/bionic_stable_kcolorchooser/58/
[00:40] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_libksane build #81: FAILURE in 8 min 9 sec: https://kci.pangea.pub/job/bionic_stable_libksane/81/
[00:40] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_kmousetool build #52: FAILURE in 8 min 15 sec: https://kci.pangea.pub/job/bionic_stable_kmousetool/52/
[00:44] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_gcompris build #85: STILL FAILING in 12 min: https://kci.pangea.pub/job/bionic_unstable_gcompris/85/
[00:45] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_kcharselect build #41: STILL FAILING in 3 min 37 sec: https://kci.pangea.pub/job/bionic_stable_kcharselect/41/
[00:50] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_kscreen build #86: STILL FAILING in 4 min 40 sec: https://kci.pangea.pub/job/bionic_unstable_kscreen/86/
[00:58] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[00:58] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_krfb build #64: FIXED in 15 min: https://kci.pangea.pub/job/bionic_stable_krfb/64/
[00:59] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_kscreen build #87: STILL FAILING in 3 min 39 sec: https://kci.pangea.pub/job/bionic_unstable_kscreen/87/
[01:11] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[01:11] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_libkipi build #93: FIXED in 27 min: https://kci.pangea.pub/job/bionic_stable_libkipi/93/
[01:12] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[01:12] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_kruler build #64: FIXED in 27 min: https://kci.pangea.pub/job/bionic_stable_kruler/64/
[01:12] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[01:12] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_libksane build #82: FIXED in 26 min: https://kci.pangea.pub/job/bionic_stable_libksane/82/
[01:12] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[01:12] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_kcolorchooser build #59: FIXED in 27 min: https://kci.pangea.pub/job/bionic_stable_kcolorchooser/59/
[01:12] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[01:12] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_kmousetool build #53: FIXED in 26 min: https://kci.pangea.pub/job/bionic_stable_kmousetool/53/
[01:13] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[01:13] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_kio build #88: FIXED in 41 min: https://kci.pangea.pub/job/bionic_unstable_kio/88/
[01:38] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[01:38] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_kxmlgui build #58: FIXED in 24 min: https://kci.pangea.pub/job/bionic_unstable_kxmlgui/58/
[01:44] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_ktp-contact-list build #85: FAILURE in 6 min 7 sec: https://kci.pangea.pub/job/bionic_stable_ktp-contact-list/85/
[01:44] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_sddm-kcm build #48: FAILURE in 6 min 8 sec: https://kci.pangea.pub/job/bionic_stable_sddm-kcm/48/
[01:44] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_kamera build #61: FAILURE in 6 min 9 sec: https://kci.pangea.pub/job/bionic_stable_kamera/61/
[01:44] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_dragon build #78: FAILURE in 6 min 10 sec: https://kci.pangea.pub/job/bionic_stable_dragon/78/
[01:45] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_klines build #81: FAILURE in 6 min 52 sec: https://kci.pangea.pub/job/bionic_stable_klines/81/
[01:45] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_kimagemapeditor build #75: FAILURE in 7 min 7 sec: https://kci.pangea.pub/job/bionic_stable_kimagemapeditor/75/
[01:46] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_libkeduvocdocument build #35: FAILURE in 8 min 14 sec: https://kci.pangea.pub/job/bionic_stable_libkeduvocdocument/35/
[01:46] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_kdiamond build #43: FAILURE in 8 min 19 sec: https://kci.pangea.pub/job/bionic_stable_kdiamond/43/
[01:46] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_ruqola build #124: STILL FAILING in 8 min 21 sec: https://kci.pangea.pub/job/bionic_unstable_ruqola/124/
[01:52] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_yakuake build #81: FAILURE in 14 min: https://kci.pangea.pub/job/bionic_unstable_yakuake/81/
[01:58] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_akonadi-contacts build #107: STILL FAILING in 20 min: https://kci.pangea.pub/job/bionic_unstable_akonadi-contacts/107/
[01:59] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[01:59] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_krunner build #80: FIXED in 20 min: https://kci.pangea.pub/job/bionic_unstable_krunner/80/
[01:59] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_ktuberling build #56: STILL FAILING in 21 min: https://kci.pangea.pub/job/bionic_unstable_ktuberling/56/
 Micron (the company where I work) now supports employee matching to registered non-profit and charites up to $2K per employee/year.
 And KDE ev is on their list.    Yes!!!
 I applied to back match my Dec 31st donation (which would be even more aweseome if they approve).
[02:09] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_kdenetwork-filesharing build #28: STILL UNSTABLE in 31 min: https://kci.pangea.pub/job/bionic_stable_kdenetwork-filesharing/28/
[02:10] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_peruse build #59: STILL UNSTABLE in 32 min: https://kci.pangea.pub/job/bionic_unstable_peruse/59/
[02:11] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_kdenetwork-filesharing build #68: STILL UNSTABLE in 33 min: https://kci.pangea.pub/job/bionic_unstable_kdenetwork-filesharing/68/
[02:13] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_amarok build #40: STILL FAILING in 35 min: https://kci.pangea.pub/job/bionic_unstable_amarok/40/
 NICE
[02:39] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_cantor build #59: STILL UNSTABLE in 31 min: https://kci.pangea.pub/job/bionic_unstable_cantor/59/
[02:40] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_amarok build #41: STILL FAILING in 14 min: https://kci.pangea.pub/job/bionic_unstable_amarok/41/
[02:40] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_kalzium build #60: STILL UNSTABLE in 31 min: https://kci.pangea.pub/job/bionic_unstable_kalzium/60/
[02:40] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_ark build #90: STILL UNSTABLE in 1 hr 2 min: https://kci.pangea.pub/job/bionic_unstable_ark/90/
[02:41] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_ruqola build #125: STILL FAILING in 16 min: https://kci.pangea.pub/job/bionic_unstable_ruqola/125/
[02:43] <valorie> that's super, @DarinMiller
 Glad someone posted issues/comments regarding the ninja pppa as I forgot it was enabled on my test box from Rik's previous request for testing.
[02:45] <valorie> yowza
[02:46] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_umbrello build #52: FAILURE in 6 min 15 sec: https://kci.pangea.pub/job/bionic_unstable_umbrello/52/
[02:51] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_ark build #79: STILL UNSTABLE in 28 min: https://kci.pangea.pub/job/bionic_stable_ark/79/
[02:51] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[02:51] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_sddm-kcm build #49: FIXED in 27 min: https://kci.pangea.pub/job/bionic_stable_sddm-kcm/49/
[02:51] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[02:51] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_kamera build #62: FIXED in 27 min: https://kci.pangea.pub/job/bionic_stable_kamera/62/
[02:51] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[02:51] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_kdiamond build #44: FIXED in 26 min: https://kci.pangea.pub/job/bionic_stable_kdiamond/44/
[02:51] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[02:51] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_dragon build #79: FIXED in 27 min: https://kci.pangea.pub/job/bionic_stable_dragon/79/
[02:51] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[02:51] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_ktp-contact-list build #86: FIXED in 27 min: https://kci.pangea.pub/job/bionic_stable_ktp-contact-list/86/
[02:51] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[02:51] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_klines build #82: FIXED in 27 min: https://kci.pangea.pub/job/bionic_stable_klines/82/
[02:51] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[02:51] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_kimagemapeditor build #76: FIXED in 27 min: https://kci.pangea.pub/job/bionic_stable_kimagemapeditor/76/
[02:51] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[02:51] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_libkeduvocdocument build #36: FIXED in 27 min: https://kci.pangea.pub/job/bionic_stable_libkeduvocdocument/36/
[02:53] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_discover build #101: STILL UNSTABLE in 28 min: https://kci.pangea.pub/job/bionic_unstable_discover/101/
[02:53] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[02:53] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_yakuake build #82: FIXED in 28 min: https://kci.pangea.pub/job/bionic_unstable_yakuake/82/
[02:53] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_akonadi-contacts build #108: STILL FAILING in 28 min: https://kci.pangea.pub/job/bionic_unstable_akonadi-contacts/108/
[02:53] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_kstars build #88: STILL UNSTABLE in 30 min: https://kci.pangea.pub/job/bionic_unstable_kstars/88/
[02:54] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_ktuberling build #57: STILL FAILING in 28 min: https://kci.pangea.pub/job/bionic_unstable_ktuberling/57/
[02:56] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_umbrello build #53: STILL FAILING in 4 min 56 sec: https://kci.pangea.pub/job/bionic_unstable_umbrello/53/
[03:27] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_krita build #84: STILL UNSTABLE in 1 hr 28 min: https://kci.pangea.pub/job/bionic_unstable_krita/84/
[03:50] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_messagelib build #151: STILL FAILING in 34 min: https://kci.pangea.pub/job/bionic_unstable_messagelib/151/
[04:22] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_messagelib build #152: STILL FAILING in 26 min: https://kci.pangea.pub/job/bionic_unstable_messagelib/152/
[06:30] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_messagelib build #76: FAILURE in 1 min 52 sec: https://kci.pangea.pub/job/bionic_stable_messagelib/76/
[07:00] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[07:00] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_messagelib build #77: FIXED in 25 min: https://kci.pangea.pub/job/bionic_stable_messagelib/77/
[08:30] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_discover build #370: STILL FAILING in 3 min 51 sec: https://kci.pangea.pub/job/xenial_unstable_discover/370/
[08:31] -kubuntu-ci:#kubuntu-devel- Project xenial_stable_discover build #161: STILL FAILING in 4 min 50 sec: https://kci.pangea.pub/job/xenial_stable_discover/161/
[08:39] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_discover build #371: STILL FAILING in 3 min 44 sec: https://kci.pangea.pub/job/xenial_unstable_discover/371/
[08:40] -kubuntu-ci:#kubuntu-devel- Project xenial_stable_discover build #162: STILL FAILING in 3 min 42 sec: https://kci.pangea.pub/job/xenial_stable_discover/162/
[08:46] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[08:46] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_kcharselect build #42: FIXED in 24 min: https://kci.pangea.pub/job/bionic_stable_kcharselect/42/
[08:49] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[08:49] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_discover build #210: FIXED in 22 min: https://kci.pangea.pub/job/artful_unstable_discover/210/
[08:49] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[08:49] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_discover build #102: FIXED in 22 min: https://kci.pangea.pub/job/bionic_unstable_discover/102/
[08:52] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_gwenview build #386: STILL FAILING in 4 min 52 sec: https://kci.pangea.pub/job/xenial_unstable_gwenview/386/
[09:00] -kubuntu-ci:#kubuntu-devel- Project xenial_stable_kblog build #66: STILL FAILING in 2 min 44 sec: https://kci.pangea.pub/job/xenial_stable_kblog/66/
[09:02] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kblog build #352: FAILURE in 4 min 46 sec: https://kci.pangea.pub/job/xenial_unstable_kblog/352/
[09:02] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_gwenview build #387: STILL FAILING in 4 min 40 sec: https://kci.pangea.pub/job/xenial_unstable_gwenview/387/
[09:08] -kubuntu-ci:#kubuntu-devel- Project xenial_stable_kblog build #67: STILL FAILING in 3 min 34 sec: https://kci.pangea.pub/job/xenial_stable_kblog/67/
[09:09] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kblog build #353: STILL FAILING in 2 min 34 sec: https://kci.pangea.pub/job/xenial_unstable_kblog/353/
[09:10] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[09:10] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_gcompris build #86: FIXED in 25 min: https://kci.pangea.pub/job/bionic_unstable_gcompris/86/
[09:11] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[09:11] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_gwenview build #200: FIXED in 23 min: https://kci.pangea.pub/job/artful_unstable_gwenview/200/
[09:24] -kubuntu-ci:#kubuntu-devel- Project xenial_stable_kdeplasma-addons build #126: STILL FAILING in 2 min 48 sec: https://kci.pangea.pub/job/xenial_stable_kdeplasma-addons/126/
[09:24] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kdeplasma-addons build #288: STILL FAILING in 2 min 49 sec: https://kci.pangea.pub/job/xenial_unstable_kdeplasma-addons/288/
[09:28] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[09:28] -kubuntu-ci:#kubuntu-devel- Project xenial_stable_gwenview build #112: FIXED in 41 min: https://kci.pangea.pub/job/xenial_stable_gwenview/112/
[09:32] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[09:32] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_gwenview build #110: FIXED in 44 min: https://kci.pangea.pub/job/bionic_unstable_gwenview/110/
[09:32] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[09:32] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[09:32] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_konsole build #444: FIXED in 31 min: https://kci.pangea.pub/job/xenial_unstable_konsole/444/
[09:32] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_konsole build #200: FIXED in 31 min: https://kci.pangea.pub/job/artful_unstable_konsole/200/
[09:32] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[09:32] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_konsole build #80: FIXED in 32 min: https://kci.pangea.pub/job/bionic_unstable_konsole/80/
[09:32] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[09:32] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_kblog build #127: FIXED in 34 min: https://kci.pangea.pub/job/artful_unstable_kblog/127/
[09:32] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[09:32] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_kblog build #36: FIXED in 34 min: https://kci.pangea.pub/job/bionic_unstable_kblog/36/
[09:32] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kdeplasma-addons build #289: STILL FAILING in 3 min 37 sec: https://kci.pangea.pub/job/xenial_unstable_kdeplasma-addons/289/
[09:33] -kubuntu-ci:#kubuntu-devel- Project xenial_stable_kdeplasma-addons build #127: STILL FAILING in 4 min 19 sec: https://kci.pangea.pub/job/xenial_stable_kdeplasma-addons/127/
[09:39] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_plasma-workspace build #422: STILL FAILING in 3 min 47 sec: https://kci.pangea.pub/job/xenial_unstable_plasma-workspace/422/
[09:40] -kubuntu-ci:#kubuntu-devel- Project xenial_stable_plasma-workspace build #176: STILL FAILING in 4 min 21 sec: https://kci.pangea.pub/job/xenial_stable_plasma-workspace/176/
[09:48] -kubuntu-ci:#kubuntu-devel- Project xenial_stable_plasma-workspace build #177: STILL FAILING in 2 min 42 sec: https://kci.pangea.pub/job/xenial_stable_plasma-workspace/177/
[09:48] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_plasma-workspace build #423: STILL FAILING in 3 min 19 sec: https://kci.pangea.pub/job/xenial_unstable_plasma-workspace/423/
[09:55] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[09:55] -kubuntu-ci:#kubuntu-devel- Project artful_stable_kdeplasma-addons build #203: FIXED in 33 min: https://kci.pangea.pub/job/artful_stable_kdeplasma-addons/203/
[09:57] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kcoreaddons build #543: STILL FAILING in 3 min 16 sec: https://kci.pangea.pub/job/xenial_unstable_kcoreaddons/543/
[09:58] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[09:58] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_kdeplasma-addons build #101: FIXED in 36 min: https://kci.pangea.pub/job/bionic_unstable_kdeplasma-addons/101/
[09:58] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[09:58] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_kdeplasma-addons build #193: FIXED in 36 min: https://kci.pangea.pub/job/artful_unstable_kdeplasma-addons/193/
[10:10] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kcoreaddons build #544: STILL FAILING in 7 min 36 sec: https://kci.pangea.pub/job/xenial_unstable_kcoreaddons/544/
[10:27] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[10:27] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_plasma-workspace build #132: FIXED in 29 min: https://kci.pangea.pub/job/bionic_unstable_plasma-workspace/132/
[10:28] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » linode-01 build #2099: SUCCESS in 46 sec: https://kci.pangea.pub/job/mgmt_docker/label=linode-01/2099/
[10:28] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » master build #2099: SUCCESS in 1 min 7 sec: https://kci.pangea.pub/job/mgmt_docker/label=master/2099/
[10:31] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » swy-01 build #2099: SUCCESS in 3 min 45 sec: https://kci.pangea.pub/job/mgmt_docker/label=swy-01/2099/
[10:47] <BluesKaj> Hi folks
[11:20] <ghostcube> O/
[12:08] -kubuntu-ci:#kubuntu-devel- Project merger_juk build #491: FAILURE in 6.3 sec: https://kci.pangea.pub/job/merger_juk/491/
[12:19] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[12:19] -kubuntu-ci:#kubuntu-devel- Project merger_juk build #492: FIXED in 12 sec: https://kci.pangea.pub/job/merger_juk/492/
[12:27] <BluesKaj> does the latest Bionic daily image have the ubiquity crash problem fixed yet ?  I need to reinstall
[12:30] <acheronuk> BluesKaj: the crash should be gone
[12:31] <BluesKaj> acheronuk, good , thanks :-)
[12:44] <santa_> good morning everyone
[12:45] <santa_> acheronuk: do you mind if I stage frameworks 5.44?
[12:45] <BluesKaj> ;morning santa_
[12:53] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_juk build #210: FAILURE in 31 sec: https://kci.pangea.pub/job/xenial_unstable_juk/210/
[12:54] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_juk build #99: FAILURE in 35 sec: https://kci.pangea.pub/job/artful_unstable_juk/99/
[12:56] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_juk build #86: FAILURE in 1 min 35 sec: https://kci.pangea.pub/job/bionic_unstable_juk/86/
[12:59] <acheronuk> santa_: already done in ppa:kubuntu-ninjas/plasma so it stays out of the way until we get any FFE approved
[12:59] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_juk build #211: STILL FAILING in 1 min 7 sec: https://kci.pangea.pub/job/xenial_unstable_juk/211/
[13:00] <acheronuk> santa_: git in branch kubuntu_bionic_staging
[13:01] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_juk build #100: STILL FAILING in 1 min 6 sec: https://kci.pangea.pub/job/artful_unstable_juk/100/
[13:01] <santa_> acheronuk: ack, why are you using the ninjas ppa instead of the regular staging ppa?
[13:02] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_juk build #87: STILL FAILING in 59 sec: https://kci.pangea.pub/job/bionic_unstable_juk/87/
[13:04] <acheronuk> santa_: my thought was to keep it out of the way there until chance of tarball respins went down, and as said so other stuff doesn't build with it until FFE is approved
[13:14] <acheronuk> santa_: I want to get plasma 5.12.3 done by end of today as well. keep up the good speed of getting bugfix updates to backports
[13:14] <acheronuk> though that won't be able to go in the archive until after beta 1 freeze is over
[13:16] <santa_> acheronuk: that's great, I'm going to schedule tests rebuilds with autopkgtrollings, this way I would be also testing what I have @ KA's git master
[13:16] <acheronuk> santa_: apologies for not communicating. I think I got quite used to just ****ing doing stuff in the last few months where it was just me working visibly
[13:17] <santa_> np
 Can we ship a newer version of Digikam in Bionic? Looks like it's currently got 5.6.0, which is pretty old. 5.8.0 resolves a shortcut conflict that will otherwise generate a large number of bug reports. See https://phabricator.kde.org/D8296#217924 … As an alternative, we can patch Digikam with the diffs in https://bugs.kde.org/show_bug.cgi?id=386335
 @nggraham, No. 5.7 onward is not compabible with the exiv2 version in bionic 18.04, so they won't build. If they did, they would be in.
 ok, then we need to patch, I'm afraid
 But maybe to the patch
 @nggraham Please create a task for it, and I'll see if I can do some patched test builds
 today is plasma 5.12.3 day, so I might not get to it until end of the week.
 ok, will do. Thanks!
 or anywone else with nijnas rights can try if they like
 https://phabricator.kde.org/T8154
 @nggraham, Thanks 🙂
 no problemo
[13:55] <acheronuk> santa_: have you push your screenlocker fixes>
[13:55] <acheronuk> *pushed
[13:58] <santa_> acheronuk: oops, I have just pushed now, sorry
[13:59] <acheronuk> santa_: happy with that? apologies I have not tested
[14:00] <acheronuk> not heard of neon users having a issue
[14:00] <santa_> acheronuk: the fix seems to work fine for me, so yep, I would say I'm happy with that
[14:00] <acheronuk> :)
[14:00] <santa_> <acheronuk> not heard of neon users having a issue
[14:00] <santa_> cause the thing was already fixed in neon for a while
[14:01] -kubuntu-ci:#kubuntu-devel- Project xenial_stable_kscreenlocker build #90: STILL FAILING in 2 min 39 sec: https://kci.pangea.pub/job/xenial_stable_kscreenlocker/90/
[14:01] <santa_> but I got the issue here with kubuntu and I got users confirming the issue a while ago
[14:01] <acheronuk> santa_: yeah. I meant issues caused by this postinst
[14:01] <santa_> ah, ok
[14:02] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kscreenlocker build #470: STILL FAILING in 3 min 41 sec: https://kci.pangea.pub/job/xenial_unstable_kscreenlocker/470/
[14:10] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kscreenlocker build #471: STILL FAILING in 2 min 34 sec: https://kci.pangea.pub/job/xenial_unstable_kscreenlocker/471/
[14:10] -kubuntu-ci:#kubuntu-devel- Project xenial_stable_kscreenlocker build #91: STILL FAILING in 4 min 6 sec: https://kci.pangea.pub/job/xenial_stable_kscreenlocker/91/
[15:03] -kubuntu-ci:#kubuntu-devel- Starting build #122 for job mgmt_pause_integration (previous build: ABORTED)
[15:44] -kubuntu-ci:#kubuntu-devel- Project mgmt_pause_integration build #122: ABORTED in 41 min: https://kci.pangea.pub/job/mgmt_pause_integration/122/
[15:58] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_kscreen build #88: STILL FAILING in 13 min: https://kci.pangea.pub/job/bionic_unstable_kscreen/88/
[15:59] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_plasma-vault build #78: FAILURE in 15 min: https://kci.pangea.pub/job/bionic_stable_plasma-vault/78/
[16:01] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_kscreen build #110: STILL FAILING in 17 min: https://kci.pangea.pub/job/artful_unstable_kscreen/110/
[16:05] -kubuntu-ci:#kubuntu-devel- Project artful_stable_plasma-vault build #48: FAILURE in 20 min: https://kci.pangea.pub/job/artful_stable_plasma-vault/48/
[16:06] -kubuntu-ci:#kubuntu-devel- Project artful_stable_kscreen build #116: FAILURE in 22 min: https://kci.pangea.pub/job/artful_stable_kscreen/116/
[16:15] -kubuntu-ci:#kubuntu-devel- Project artful_stable_ksysguard build #121: FAILURE in 30 min: https://kci.pangea.pub/job/artful_stable_ksysguard/121/
[16:15] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_kscreen build #38: FAILURE in 31 min: https://kci.pangea.pub/job/bionic_stable_kscreen/38/
[16:21] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_ksysguard build #90: FAILURE in 36 min: https://kci.pangea.pub/job/bionic_stable_ksysguard/90/
[16:38] -kubuntu-ci:#kubuntu-devel- Project artful_stable_breeze build #128: FAILURE in 53 min: https://kci.pangea.pub/job/artful_stable_breeze/128/
[16:39] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_breeze build #80: FAILURE in 54 min: https://kci.pangea.pub/job/bionic_stable_breeze/80/
[16:40] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_kscreen build #89: STILL FAILING in 37 min: https://kci.pangea.pub/job/bionic_unstable_kscreen/89/
[16:40] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_plasma-vault build #79: STILL FAILING in 35 min: https://kci.pangea.pub/job/bionic_stable_plasma-vault/79/
[16:41] -kubuntu-ci:#kubuntu-devel- Project artful_stable_plasma-vault build #49: STILL FAILING in 30 min: https://kci.pangea.pub/job/artful_stable_plasma-vault/49/
[16:41] -kubuntu-ci:#kubuntu-devel- Project artful_stable_ksysguard build #122: STILL FAILING in 20 min: https://kci.pangea.pub/job/artful_stable_ksysguard/122/
[16:41] -kubuntu-ci:#kubuntu-devel- Project artful_stable_kscreen build #117: STILL FAILING in 29 min: https://kci.pangea.pub/job/artful_stable_kscreen/117/
[16:41] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_kscreen build #111: STILL FAILING in 34 min: https://kci.pangea.pub/job/artful_unstable_kscreen/111/
[16:41] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_kscreen build #39: STILL FAILING in 20 min: https://kci.pangea.pub/job/bionic_stable_kscreen/39/
[16:42] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_libkscreen build #73: FAILURE in 1 min 0 sec: https://kci.pangea.pub/job/bionic_stable_libkscreen/73/
[16:42] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_ksysguard build #91: STILL FAILING in 16 min: https://kci.pangea.pub/job/bionic_stable_ksysguard/91/
[16:44] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_libksysguard build #78: FAILURE in 1 min 0 sec: https://kci.pangea.pub/job/bionic_stable_libksysguard/78/
[16:51] -kubuntu-ci:#kubuntu-devel- Project artful_stable_breeze build #129: STILL FAILING in 7 min 59 sec: https://kci.pangea.pub/job/artful_stable_breeze/129/
[16:52] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_breeze build #81: STILL FAILING in 7 min 40 sec: https://kci.pangea.pub/job/bionic_stable_breeze/81/
[17:06] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[17:06] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_libksysguard build #79: FIXED in 17 min: https://kci.pangea.pub/job/bionic_stable_libksysguard/79/
[17:07] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[17:07] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_libkscreen build #74: FIXED in 19 min: https://kci.pangea.pub/job/bionic_stable_libkscreen/74/
[17:17] -kubuntu-ci:#kubuntu-devel- Project artful_stable_plasma-integration build #102: FAILURE in 9 min 49 sec: https://kci.pangea.pub/job/artful_stable_plasma-integration/102/
[17:21] -kubuntu-ci:#kubuntu-devel- Project artful_stable_kwin build #191: FAILURE in 14 min: https://kci.pangea.pub/job/artful_stable_kwin/191/
[17:26] -kubuntu-ci:#kubuntu-devel- Project artful_stable_plasma-integration build #103: STILL FAILING in 4 min 36 sec: https://kci.pangea.pub/job/artful_stable_plasma-integration/103/
[17:27] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_plasma-integration build #70: FAILURE in 3 min 40 sec: https://kci.pangea.pub/job/bionic_stable_plasma-integration/70/
[17:27] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_khotkeys build #75: FAILURE in 3 min 42 sec: https://kci.pangea.pub/job/bionic_stable_khotkeys/75/
[17:28] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_oxygen build #69: FAILURE in 3 min 58 sec: https://kci.pangea.pub/job/bionic_stable_oxygen/69/
[17:28] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_kdeplasma-addons build #86: FAILURE in 4 min 7 sec: https://kci.pangea.pub/job/bionic_stable_kdeplasma-addons/86/
[17:29] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_powerdevil build #82: FAILURE in 4 min 47 sec: https://kci.pangea.pub/job/bionic_stable_powerdevil/82/
[17:29] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_plasma-desktop build #119: FAILURE in 5 min 15 sec: https://kci.pangea.pub/job/bionic_stable_plasma-desktop/119/
[17:30] -kubuntu-ci:#kubuntu-devel- Project artful_stable_kwin build #192: STILL FAILING in 3 min 42 sec: https://kci.pangea.pub/job/artful_stable_kwin/192/
[17:35] -kubuntu-ci:#kubuntu-devel- Project artful_stable_powerdevil build #155: FAILURE in 5 min 41 sec: https://kci.pangea.pub/job/artful_stable_powerdevil/155/
[17:42] -kubuntu-ci:#kubuntu-devel- Project artful_stable_khotkeys build #110: FAILURE in 11 min: https://kci.pangea.pub/job/artful_stable_khotkeys/110/
[17:42] -kubuntu-ci:#kubuntu-devel- Project artful_stable_kdeplasma-addons build #204: FAILURE in 11 min: https://kci.pangea.pub/job/artful_stable_kdeplasma-addons/204/
[17:42] -kubuntu-ci:#kubuntu-devel- Project artful_stable_oxygen build #135: FAILURE in 12 min: https://kci.pangea.pub/job/artful_stable_oxygen/135/
[17:42] -kubuntu-ci:#kubuntu-devel- Project artful_stable_plasma-desktop build #234: FAILURE in 12 min: https://kci.pangea.pub/job/artful_stable_plasma-desktop/234/
[17:44] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_kdecoration build #67: STILL UNSTABLE in 34 min: https://kci.pangea.pub/job/bionic_unstable_kdecoration/67/
[17:44] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_kdecoration build #231: STILL UNSTABLE in 34 min: https://kci.pangea.pub/job/artful_unstable_kdecoration/231/
[17:52] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_khotkeys build #76: STILL FAILING in 19 min: https://kci.pangea.pub/job/bionic_stable_khotkeys/76/
[17:53] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_plasma-integration build #71: STILL FAILING in 20 min: https://kci.pangea.pub/job/bionic_stable_plasma-integration/71/
[18:01] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_kdeplasma-addons build #87: STILL FAILING in 27 min: https://kci.pangea.pub/job/bionic_stable_kdeplasma-addons/87/
[18:02] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_oxygen build #70: STILL FAILING in 29 min: https://kci.pangea.pub/job/bionic_stable_oxygen/70/
[18:02] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_plasma-desktop build #120: STILL FAILING in 28 min: https://kci.pangea.pub/job/bionic_stable_plasma-desktop/120/
[18:02] -kubuntu-ci:#kubuntu-devel- Project artful_stable_powerdevil build #156: STILL FAILING in 21 min: https://kci.pangea.pub/job/artful_stable_powerdevil/156/
[18:02] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_powerdevil build #83: STILL FAILING in 28 min: https://kci.pangea.pub/job/bionic_stable_powerdevil/83/
[18:07] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_oxygen build #149: STILL FAILING in 23 min: https://kci.pangea.pub/job/artful_unstable_oxygen/149/
[18:07] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_plasma-desktop build #240: STILL FAILING in 23 min: https://kci.pangea.pub/job/artful_unstable_plasma-desktop/240/
[18:10] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_plasma-desktop build #106: FAILURE in 25 min: https://kci.pangea.pub/job/bionic_unstable_plasma-desktop/106/
[18:10] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_oxygen build #51: FAILURE in 25 min: https://kci.pangea.pub/job/bionic_unstable_oxygen/51/
[18:10] -kubuntu-ci:#kubuntu-devel- Project artful_stable_khotkeys build #111: STILL FAILING in 23 min: https://kci.pangea.pub/job/artful_stable_khotkeys/111/
[18:10] -kubuntu-ci:#kubuntu-devel- Project artful_stable_kdeplasma-addons build #205: STILL FAILING in 23 min: https://kci.pangea.pub/job/artful_stable_kdeplasma-addons/205/
[18:11] -kubuntu-ci:#kubuntu-devel- Project artful_stable_oxygen build #136: STILL FAILING in 23 min: https://kci.pangea.pub/job/artful_stable_oxygen/136/
[18:11] -kubuntu-ci:#kubuntu-devel- Project artful_stable_plasma-desktop build #235: STILL FAILING in 23 min: https://kci.pangea.pub/job/artful_stable_plasma-desktop/235/
[18:11] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_kmenuedit build #33: FAILURE in 18 min: https://kci.pangea.pub/job/bionic_stable_kmenuedit/33/
[18:15] -kubuntu-ci:#kubuntu-devel- Project artful_stable_kmenuedit build #139: FAILURE in 4 min 43 sec: https://kci.pangea.pub/job/artful_stable_kmenuedit/139/
[18:16] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_oxygen build #150: STILL FAILING in 3 min 43 sec: https://kci.pangea.pub/job/artful_unstable_oxygen/150/
[18:20] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_plasma-desktop build #241: STILL FAILING in 7 min 44 sec: https://kci.pangea.pub/job/artful_unstable_plasma-desktop/241/
[18:20] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_plasma-desktop build #107: STILL FAILING in 5 min 51 sec: https://kci.pangea.pub/job/bionic_unstable_plasma-desktop/107/
[19:32] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_oxygen build #52: STILL FAILING in 1 hr 17 min: https://kci.pangea.pub/job/bionic_unstable_oxygen/52/
[19:34] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_kmenuedit build #34: STILL FAILING in 1 hr 17 min: https://kci.pangea.pub/job/bionic_stable_kmenuedit/34/
[19:34] -kubuntu-ci:#kubuntu-devel- Project artful_stable_kmenuedit build #140: STILL FAILING in 1 hr 13 min: https://kci.pangea.pub/job/artful_stable_kmenuedit/140/
[19:41] -kubuntu-ci:#kubuntu-devel- Project artful_stable_plasma-workspace build #245: FAILURE in 7 min 5 sec: https://kci.pangea.pub/job/artful_stable_plasma-workspace/245/
[19:42] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_kwin build #104: FAILURE in 8 min 26 sec: https://kci.pangea.pub/job/bionic_stable_kwin/104/
[19:55] -kubuntu-ci:#kubuntu-devel- Project artful_stable_plasma-workspace build #246: STILL FAILING in 8 min 44 sec: https://kci.pangea.pub/job/artful_stable_plasma-workspace/246/
[19:56] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_kwin build #105: STILL FAILING in 8 min 49 sec: https://kci.pangea.pub/job/bionic_stable_kwin/105/
[19:59] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_plasma-workspace build #97: FAILURE in 2 min 55 sec: https://kci.pangea.pub/job/bionic_stable_plasma-workspace/97/
[20:02] -kubuntu-ci:#kubuntu-devel- Starting build #123 for job mgmt_pause_integration (previous build: ABORTED)
[20:10] -kubuntu-ci:#kubuntu-devel- Project mgmt_pause_integration build #123: ABORTED in 8 min 23 sec: https://kci.pangea.pub/job/mgmt_pause_integration/123/
[20:19] <acheronuk> valorie mparillo DarinMiller mamarley santa_ : Plasma 5.12.3 is now in backports-landing for artful and plasma-staging for bionic
[20:32] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_plasma-workspace build #98: STILL FAILING in 21 min: https://kci.pangea.pub/job/bionic_stable_plasma-workspace/98/
[20:32] <mamarley> acheronuk: Cool, I will try it out later. :)
[20:40] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_plasma-workspace build #99: STILL FAILING in 2 min 45 sec: https://kci.pangea.pub/job/bionic_stable_plasma-workspace/99/
[20:44] <kfunk> same question as every 6 months: is it safe to upgrade to 18.04 already? :)
[20:55] <acheronuk> kfunk: many have been running it. upgrades are never as safe as a fresh install. also we have this unresolved right now: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1749472
[20:56] <acheronuk> vut currently trying to get new Qt to hit the release pocket!
[20:56] <acheronuk> *but
[20:58] <acheronuk> it will be beta 1 on thursday if we can unstick things and get the isos tested
 so the double wifi password issue is not solved for me in the latest Bionic ISO, sadly: https://phabricator.kde.org/T8061#131706
 @nggraham, let me try today's iso
 @nggraham, In live session on today's iso, I am only asked once. and it connects ok
 hmm
 so after you enter the password in the widget, no dialog box pops asking you again?
 I get one password request dialog only
 how are you connecting?
 for me, I click on the wifi icon, I click on my network, I click "connect", and then the widget itself asks me for the password
 after I enter the password in the widget, a dialog box appears asking for it again
 not here. widget does not ask me
 really?
 interesting
 OK, something is screwy here. Many of the networks in the list are not listed as password-protected, when they really are. For these networks, clicking "Connect" will pull up the password dialog instead of asking for the password inline
 Can you try again with a network that shows up in the list as being password-protected?
 (and that, presumably, you have the password to :p)
 that is what my network is
 does it show up with a lock icon in the network widget's network list though?
 hold on. restarting
 @nggraham, Ok. on boot it does not at first. If I connect then it connect with one popup dialog. If I wait a short while then something cleary detects it is protected, then I get the iin-wideget password box and the duplicate request pop-up
 boooooo
 lets see what people report with the beta
 if we're both seeing it here, is there any reason to suspect that other people won't see it too?
 no. but we may get more feedback on the nature of it. probably not, but it isn't getting fixed tonight so hey!
 heh
 [21:30] <infinity> acheronuk: Qt looks migratey. … [21:31] <infinity> migratory?
 @nggraham, but maybe we know the casue now!
 or part of it
 So about the email to kubuntu-devel...
 I'm -1 on seeding snaps
 I'm personally unclear on how critical regressions can be effectively handled
 For a calculator? OK, maybe...
 But for other things? I'm -1
[23:03] <valorie> evidently there are some snaps already done
[23:04] <valorie> but I dunno about 'em
 are there actually any snaps of KDE apps?
 I know there are some Flatpaks on Flathub, and we're actually building flatpak Nightly builds of all KDE apps
 can't think of anything we would want to seed
[23:10] <valorie> neon has some snaps
[23:11] <valorie> krita would be a likely one
 @valorie, https://twitter.com/KdeNeon/status/970347468503339009
 no thanks!
[23:20] <valorie> wow
[23:20] <valorie> I did use a snap to test telegram on my travel laptop and it worked
[23:21] <valorie> but it was huge, and had so many "loop devices" that i eventually purged it
[23:23] <valorie> no ISOs yet, and I seem unable to login to kubuntuforum, so....
[23:23] <valorie> gotta go afk for now
 lets try to think if there is something minimal and meaninful that doesn't require many 100s MB of runtime
 not over keen on it, but it would be good politics
 @valorie, That's a bug in the KDE Solid framework that's since been fixed FWIW; now Snaps don't create a zillion loop devices in Dolphin
[23:58] <valorie> I have heard that that was fixed, yeah
[23:58] <valorie> but have not tested recently


[03:08] <lotuspsychje> good morning to all
[03:10] <Bashing-om> lotuspsychje: :) Hey - http://ubuntu-manual.org/ is not connecting . Any idea who we contact to get it resolved ?
[03:14] <lotuspsychje> hey Bashing-om
[03:17] <lotuspsychje> Bashing-om: on my side it loads
[03:17] <lotuspsychje> Bashing-om: perhaps a country block for the user?
[03:18] <lotuspsychje> Bashing-om: perhaps #ubuntu-mirrors guys might know the way?
[03:19] <Bashing-om> lotuspsychje: Humm .. I am in the US .. and I tried it too .. ;emme try again :)
[03:20] <Bashing-om> lotuspsychje: Nope . pressing 'download now ' and errors out for the routing .
[03:20] <lotuspsychje> Bashing-om: for me it forwards the manual in my language(dutch)
[04:03] <lightF> are you in china? /say Bashing-om
[04:04] <lightF> Bashing-om are you in china?
[04:09] <Bashing-om> lightF: No ,, not presently - why ?
[04:11] <lightF> Bashing-om :in china, it's normal.
[04:11] <Bashing-om> lightF: :(
[06:14] <alkisg> Good morning all
[06:14] <lotuspsychje> hey alkisg
[06:48] <Bashing-om> For me, "that's all folks" g nite \o
[06:48] <lotuspsychje> nite Bashing-om
[06:49] <Bashing-om> Take care lotuspsychje catch ya on my flip :)
[07:01] <lordievader> Good morning
[07:04] <lotuspsychje> hey lordievader
[07:04] <lordievader> Hey lotuspsychje
[07:04] <lordievader> How are you doing?
[07:04] <lotuspsychje> great here
[07:05] <lotuspsychje> testing bionic
[07:08] <lordievader> And?
[07:09] <lordievader> Runs Wayland (in Ubuntu) right?
[07:17] <lotuspsychje> lordievader: 2 out 3 boxes still need xorg for me
[07:17] <lotuspsychje> wayland lags alot
[07:19] <jink> IS HET AL WEEKEND?
[07:19] <lordievader> Oh, that doesn't surprise me. There are not many applications which do native Wayland yet.
[07:36] <ducasse> good morning
[07:37] <alkisg> \o ducasse
[07:38] <ducasse> hi alkisg - all well?
[07:40] <alkisg> I spent a day yesterday backing up my 1 tb disk only to discover that the target disk had bad sectors :/
[07:40] <alkisg> Oh well a day lost; everything fine otherwise
[07:40] <alkisg> How are you?
[07:44] <ducasse> all quiet, still sleepy, but good :) absolutely freezing outside, so probably staying in.
[07:45] <lotuspsychje> hey ducasse
[07:48] <ducasse> hi lotuspsychje - how goes?
[07:48] <lotuspsychje> all fine this side of the planet :p
[07:49] <alkisg> Btw, which sides of the planet are you guys from?
[07:51] <ducasse> norway here
[07:52] <ducasse> lotus is from belgium
[07:52] <alkisg> Ah, so we're +-1 in timezones, cool :D
[07:52] <ducasse> and you?
[07:52] <alkisg> I'm from Greece
[07:53] <lordievader> Hey ducasse
[07:53] <lordievader> Hey alkisg
[07:53] <alkisg> Here's an old page: https://wiki.ubuntu.com/AlkisGeorgopoulos
[07:53] <alkisg> Hey lordievader
[07:53] <ducasse> hi lordievader
[07:55] <lordievader> How are you all?
[07:57] <ducasse> i'm good, thanks, and you?
[08:00] <lordievader> Doing good, trying to solve an advent of code.
[08:00] <ducasse> lordievader: gotten your coffee yet? :)
[08:00] <lordievader> Yes, right in front of me 😁
[08:09] <lotuspsychje> all sides of the world :p
[08:09] <lotuspsychje> now -r and we good to go!
[08:10] <alkisg> Was anyone at #ops convinced about it?
[08:10] <lotuspsychje> dax was interested
[08:10] <lotuspsychje> about the graph from ben64
[08:11] <lotuspsychje> but we didnt catch his url yet
[08:26] <lotuspsychje> bbl work
[08:26] <lotuspsychje> almost holiday
[13:47] <BluesKaj> Howdy folks
[13:48] <pauljw> hey BluesKaj :)
[13:49] <BluesKaj> Hi pauljw 😎
[14:44] <lordievader> Hey BluesKaj
[14:44] <BluesKaj> Hi lordievader
[14:50] <lordievader> How are you doing?
[14:52] <BluesKaj> good here lordievader, and you?
[14:53] <lordievader> Doing okay
[17:01] <Bashing-om> Yukkie outside . Will procrastinate here awaiting improved conditions :)
[17:01] <daftykins> :D
[17:01] <daftykins> sounds like a plan
[17:03] <Bashing-om> daftykins: Wonderful .. Hey all your clients happy now ?
[17:03] <daftykins> Bashing-om: ooh yes all buttoned up for winter, all totally quiet now other than finishing up payments and paperwork with the insurance company for the house stuff
[17:05] <Bashing-om> daftykins: Well !  That's the way I feel . Freezing this week end and I am now ready .
[20:46] <daftykins> :D


[00:02] <axisys> sarnold: well i was capturing for udp pkts from this server .. nothing going out
[00:02] <axisys> no pkts even trying to send to remote.. pure quite
[00:03] <sarnold> axisys: how about trying nc to send udp to the remote host?
[00:03] <axisys> ok.. let me check
[00:04] <sarnold> axisys: that would let you sort out if it is a matter of configuring rsyslog or fixing firewall rulesets or routing or something similar
[00:04] <axisys> right.. how do I generate a udp pkt with nc
[00:05] <axisys> got it..
[00:07] <axisys> ok nc <IP_ADDRESS> works .. remote server gets the pkts.. so it is issue with rsyslog then
[00:08] <axisys> nc <IP_ADDRESS> 514
[00:08] <sarnold> are you using -u ? or not
[00:09] <axisys> nc -u <IP_ADDRESS> 514 works too.. pkt recvd on remote side
[00:09] <sarnold> oh okay
[00:09] <sarnold> so that leaves troubleshooting rsyslog :/
[00:09] <axisys> right..
[00:13] <sarnold> hrm, do you need to restart or reload rsyslog to pick up changes? have you started or restarted rsyslogd since adding this line?
[00:13] <axisys> I did .. let me do it again
[00:15] <axisys> I killed it and it came back up right away
[00:16] <axisys> ah.. upstart
[00:18] <axisys> this is pre-start /lib/init/apparmor-profile-load usr.sbin.rsyslogd and /etc/default/rsyslog has RSYSLOGD_OPTIONS="" and then just an exec rsyslogd $RSYSLOGD_OPTIONS ..
[00:20] <sarnold> do you have anything in dmesg?
[00:22] <axisys> [20646747.288516] init: rsyslog main process ended, respawning
[00:23] <sarnold> heh. handy :) but sadly not much help
[00:23] <axisys> lol
[01:03] <sarnold> nacc: pity this was marked private security .. it might have been easier to address ~ten days ago. Is this something for your team? 1753018
[02:54] <nacc> sarnold: looking
[02:54] <nacc> sarnold: yes
[02:55] <nacc> sarnold: i'll make sure it gets noticed tmrw
[06:28] <cpaelzer> good morning #server
[07:24] <lordievader> Good morning
[12:22] <Mava> i'm facing quite an interesting case with sas storage in hp server. the storage is configured to be 12Tb, but the ubuntu server sees with blockdev only 1.1Tb. Any tips ?
[12:26] <OpenTokix> Mava: wrong partition table?
[12:27] <Mava> OpenTokix: should it affect the information blockdev reports ?
[12:29] <OpenTokix> Mava: It's where the sectors and sector-size is stored.
[12:30] <Mava> OpenTokix: good point, unfortunately converting it to gpt did not fix anything.
[12:32] <OpenTokix> Does the num sectors and sector size add up to wrong or right?
[12:32] <Mava> once you said: both are wrong
[12:33] <Mava> like. it calculates it right
[12:34] <Mava> but the amount of sectors and the sector size is not the ones specified in the array configuration utility
[12:37] <Mava> now i've got a clue. thanks OpenTokix !
[12:43] <Cheez> how do people monitor mdadm arrays? ilke, I have 2 different arrays, a 2 drive raid 1 for / and /boot and an 8 drive raid 6 for /mnt/storage - I know I can look at mdadm --detail and check the state is clean anddisks are active, but is there a best practice way of keeping on top of it in case a disk fails?
[12:44] <patdk-lap> I just let munin do it for me
[12:47] <dlloyd> you can also configure MAILADDR in mdadm.conf for alerting
[12:48] <Cheez> ooh, that'd probably be good enough
[12:49] <Cheez> although i presume it expects there to be a local MTA rather than being able to specify an SMTP server?
[13:10] <cpaelzer> ahasenack: rbasak: did you ever realize that system looses "fast" error messages?
[13:10] <ahasenack> not really
[13:11] <ahasenack> what did you (not) see?
[13:11] <OpenTokix> Mava: cool, good luck
[13:11] <rbasak> Am I missing some context here?
[13:11] <cpaelzer> slow: http://paste.ubuntu.com/p/2nybTkkm3h/
[13:11] <cpaelzer> fast: http://paste.ubuntu.com/p/mSfYPHssfT/
[13:12] <cpaelzer> essentially echo + exit vs echo + sleep + exit
[13:12] <cpaelzer> result: http://paste.ubuntu.com/p/TT38mQ83Mf/
[13:12] <ahasenack> you must be debugging something interesting :)
[13:13] <cpaelzer> many services that have wrappers do like "initial check, error out if failed"
[13:13] <cpaelzer> I realized while working on one that the message isn't there
[13:13] <cpaelzer> ahasenack: this is what got me to this
[13:14] <ahasenack> for what is worth, I do find that the logs from systemd are lacking detail
[13:14] <cpaelzer> ahasenack: rbasak: do you see that the "fast" output is not in the status info
[13:14] <ahasenack> maybe because of that
[13:14] <rbasak> Interesting
[13:14] <cpaelzer> ahasenack: I find the logs better accessible than before sytemd, but this is odd
[13:14] <cpaelzer> I just wondere - might this be a general flaw
[13:14] <cpaelzer> or do I miss something
[13:14] <rbasak> I can't think of any architectural reason why there has to be a race like that
[13:14] <cpaelzer> but I feel my example is not simplified a lot, and still reproduces
[13:14] <ahasenack> are they also not in the output of journalctl?
[13:15] <cpaelzer> ahasenack: the are in the journal
[13:15] <ahasenack> just not in the status output?
[13:15] <cpaelzer> just not on systemctl status, which is where people look first
[13:15] <ahasenack> ohh
[13:15] <ahasenack> that just got more interesting
[13:15] <cpaelzer> an i mean, sleep fixes it c'mon we are not in 1998
[13:16] <ahasenack> sleep fixes so many things
[13:16] <cpaelzer> I tried to echo to stderr (unbuffered) but that didn't change anything
[13:16] <ahasenack> how do you echo unbuffered?
[13:16] <ahasenack> or is that stderr's default behavior
[13:16] <cpaelzer> the default of stderr
[13:17] <cpaelzer> ahasenack: rbasak: but none of you points out obvious flaws right - so I might ask #systemd then
[13:17] <ahasenack> and even after a while systemctl status still won't show it?
[13:17] <ahasenack> right
[13:17] <cpaelzer> ahasenack: not after 7 minutes
[13:17] <ahasenack> good enough
[13:17] <ahasenack> what about the <3> prefix, does that mean anything special?
[13:18] <ahasenack> or just log level
[13:18] <ahasenack> (which would be special)
[13:18] <cpaelzer> ahasenack: that makes log levels for journal/systemd
[13:18] <cpaelzer> but yeah, lets try without
[13:19] <cpaelzer> removing the log level has no effect
[13:19] <cpaelzer> but was worth a try
[13:19] <ahasenack> ok
[13:20] <cpaelzer> sleep 0.01 is enoug
[13:20] <cpaelzer> h
[13:21] <cpaelzer> so just any sort of interruption
[13:29] <cpaelzer> rbasak: ahasenack: xenial not affected, but showing in bionic
[13:33] <TJ-> Is there a recommended way to set the FQDN on a pure IPv6 setup. Equivalent to the IPv4 /etc/hostname "<IP_ADDRESS> hostname.domain.tld hostname" ? The "::1" is generally set to a similar list as '<IP_ADDRESS>' but do is there an IPv6 version of '<IP_ADDRESS>' ?
[13:34] <patdk-lap> no
[13:34] <patdk-lap> but I dunno why your using loopback for fqdn, that just doesn't work
[13:34] <TJ-> That explains why my search-fu has been failing :)
[13:34] <patdk-lap> you could always use ::<IP_ADDRESS>
[13:35] <TJ-> I'm not, I've been investigating a pure IPv6 deployment/config with IPv4 totally disabled in kernel to provoke bugs and other problems
[13:36] <TJ-> Recommendation is not but FQDN in /etc/hostname; if sticking to that then there ought to be a recommended location for the domain
[13:36] <TJ-> s/but/put/
[13:36] <OpenTokix> Anyone know what the point of the <IP_ADDRESS> address is? - From what I understand it's just a smeantic differnce. No technical difference.
[13:37] <TJ-> OpenTokix: i /think/ originally it was to prevent errors where 'localhost' was removed from the '<IP_ADDRESS>' entry
[13:37] <OpenTokix> since the entire network <IP_ADDRESS>/8 is the same interface.
[13:43] <patdk-lap> no
[13:43] <patdk-lap> it's so you can have multible things going on
[13:43] <patdk-lap> I bind a lot of things to different loopback ip's
[13:45] <cpaelzer> rbasak: ahasenack: FYI that is https://github.com/systemd/systemd/issues/2913
[13:46] <ahasenack> I was following your discussion in #systemd
[13:46] <ahasenack> nice that you found the bug
[13:46] <cpaelzer> it essentically fails to associate with the unit before it is gone
[13:46] <cpaelzer> and therefore missing on systemctl status and journal -u output
[13:47] <ahasenack> that's an old bug :/
[13:47] <cpaelzer> it does not affect my xenial system it seems
[13:50] <cpaelzer> as I understand it we might loose any late message
[13:50] <cpaelzer> as long as it comes very shortly before the PID goes away
[13:50] <cpaelzer> :-/
[13:51] <cpaelzer> But quite often the last message before something dies is the most important one
[13:52] <OpenTokix> patdk-lap: yes, but they all bind to the same interface.
[13:53] <patdk-lap> isn't that the whole point?
[13:53] <patdk-lap> if it didn't, useless
[13:55] <OpenTokix> it is very useful, but also a magic interface
[13:56] <patdk-lap> nothing magic about it
[13:56] <patdk-lap> now, dummy, that is a magical interface :)
[13:56] <OpenTokix> It binds to a whole /8, but only one of those ips is showing.
[13:57] <patdk-lap> no it doesn't
[13:57] <patdk-lap> it binds to exactly one ip
[13:57] <patdk-lap> but it *routes* the rest
[13:57] <patdk-lap> just like anything else
[14:01] <cpaelzer> rbasak: ahasenack: for the sake of awareness on the Ubuntu side I filed bug 1756081
[14:05] <ahasenack> ok
[14:25] <Slashman> hello, I have an issue with the HWE kernel for xenial "linux-image-4.13.0-37-generic", it's freezing my server some minutes after the boot, is this a known issue?
[14:28] <rbasak> Slashman: try #ubuntu-kernel
[14:28] <Slashman> rbasak: thx
[14:44] <ahasenack> rbasak: hi, are you reviewing https://code.launchpad.net/~paelzer/ubuntu/+source/chrony/+git/chrony/+merge/341461 or was that comment just a drive-by?
[14:45] <rbasak> ahasenack: I claimed the review as I was curiousu to look anyway
[14:45] <ahasenack> cool
[14:45] <rbasak> cpaelzer: what does EFF_ stand for OOI?
[14:45] <cpaelzer> EFFECTIVE
[14:45] <cpaelzer> a rename can be done
[14:45] <rbasak> Ah
[14:45] <cpaelzer> just let men know
[14:45] <cpaelzer> me
[14:46] <cpaelzer> I just replied for the default conffile change
[16:28] <madLyfe> https://gist.github.com/61a118ed1c8437e2b480c6049cee07d7
[16:28] <madLyfe> not sure why i got those errors after running update && upgrade
[16:28] <sarnold> try running it as root
[16:45] <madLyfe> run commands it suggests or run update && upgrade again?
[16:46] <sarnold> update and upgrade again as a first step
[16:46] <madLyfe> its odd because i have 4 identical servers and only two of them had these errors.
[16:47] <madLyfe> and i always update them at the same time.
[17:05] <JimBuntu> madLyfe, what happens if you try `touch /var/lib/apt/lists/test.txt` ?
[17:06] <madLyfe> well it looks like the updates are going through at this point with root.