[04:57] <superdug> why am I so impressed with linux on a processor that can run linux?
[09:40] <ogra> lool, so about imx-libs and xserver-xorg-video-imx and theior linking .... xserver-xorg-video-imx needs to link against mxcfb.h/ipu.h as well (looking for it on include/linux), do you know if the policy allows it that i would copy both headers during package build into imx-libs so it would ship these two in /usr/include/linux and the xserver wouldnt have to be hacked up for isung linux-headers ?
[09:42] <ogra> s/isung/using/
[09:48] <lool> ogra: I think this would create another libdrm and I dont think we want that; it sounds like these headers should be in the kernel tree instead?
[09:49] <lool> ogra: In which case we'd have to build-dep on linux-headers-imx51 instead of linux-libc-dev because of the mx51 stuff not being upstream
[09:49] <ogra> lool, yes, it is in the kernel tree atm
[09:50] <ogra> and imx-libs dep on linux-headers-imx51 and build fine with it
[09:50] <ogra> the xserver has no configure option to add additional includes though
[09:50] <ogra> and hasnt /usr/src/linux* in its default include path
[09:51] <ogra> given that apps that build against imx-libs always need to have the headers from linux-headers it would be more easy to have imx-libs ship them in the default include path instead of having to hack up each app that uses them
[09:53] <lool> Oh right
[09:53] <lool> ogra: I disagree that we want imx-libs to ship them
[09:53] <lool> These headers are in the kernel source and should remain there
[09:54] <lool> ogra: But we might have to move them to the expected place
[09:54] <ogra> ok, then i'll need to hack up the xserver autofoo
[09:54] <lool> Or add -I flags when using imx-libs
[09:54] <lool> ogra: Well you could also copy them in linux-fsl-imx51
[09:54] <lool> But you'd have to be really careful in only adding new headers
[09:55] <ogra> hmm, would linking not work ?
[09:55] <lool> Perhaps it's best to add an -I flag for now; until the headers make it to linux-libc-dev
[09:55] <lool> To avoid any clash
[09:55] <lool> ogra: Well linking or copying, yeah, but the issue is that if the upstream kernel or another vendor or another kernel tree (e.g. lange) wants to provide the same filenames, we're in trouble
[09:55] <lool> While adding the -I is safe
[09:56] <ogra> i could make a link from /usr/include/linux/mxcfb.h to /usr/src/linux-headers/*.../mxcfb.h in the libimx-dev package
[09:56] <ogra> i think currently its highly inlikely that we get the same files anywhere
[09:57] <ogra> ipu.h and mxcfb.h are pretty exclusively only on the imx51 arch
[09:57] <lool> I'm not too hot on it
[09:58] <ogra> well, ok, i'll hack up the xserver for now to look in the linux-headers dir too
[09:58] <ogra> but that makes two packages that have to stay in sync
[09:59] <lool> ogra: Actually one thing which strikes me is that the headers are under an ABI path
[09:59] <ogra> right
[09:59] <ogra> which is pointless unless the patches get actually updated
[10:00] <ogra> even if we have an ABI bump they usually stay untouched
[10:00] <lool> ogra: The core of the issue is that we currently rely on linux-libc-dev/armel to build everything on armel
[10:00] <lool> While we truly have multiple kernel ABIs
[10:00] <lool> One per subarch
[10:00] <ogra> yeah
[10:00] <ogra> plus vendor patches
[10:00] <lool> We cant have multiple linux-libc-dev
[10:00] <lool> I think using the upstream kernel ABI/API is best for us by defalut
[10:01] <lool> But we could use a more specific ABI/API for packages which need it, like here
[10:01] <ogra> right, but that wont work for such device specific headers
[10:01] <lool> Still, this should be offered by the linux-fsl-imx51 packages
[10:01] <ogra> well, i fear any changes in the packaging of linux-fsl-imx51
[10:02] <lool> So perhaps we should have a linux-libc-dev-fsl-imx51 which would install in /usr/include/fsl-imx51/* (/linux etc.)
[10:02] <ogra> especially this late in the cycle and with the experience i made this round
[10:02] <lool> (I'm speaking long term)
[10:02] <lool> I dont think that's doable for karmic
[10:02] <ogra> yes, i understand
[10:02] <ogra> right
[10:02] <lool> (But I want to get the logic right as to solve this properly next cycle)
[10:02] <ogra> yup
[10:03] <lool> ogra: So either imx51 gets merged upstream in the kernel and we use linux-libc-dev (unlikely before long), or we come up with such a hack
[10:03] <ogra> well, atm there are in max 5 devices
[10:03] <lool> ogra: I'd rather use a new binary package for this since the linux-headers packages already have use cases
[10:03] <ogra> so that package would be fairly empty
[10:03] <ogra> we only use three of the 5 atm
[10:03] <lool> ogra: I think it would be a full replacement for libc-dev
[10:04] <lool> ogra: In theory, the ABI could be difference in some places than the upstream one
[10:04] <ogra> though sahara was enabled in the config, i will probably switch it back on in imx-libs
[10:04] <lool> ogra: e.g. they could add some fb ABI calls
[10:04] <lool> (ioctls)
[10:04] <ogra> ah
[10:04] <ogra> yep, i understand
[10:04] <lool> ogra: Is this approach fine with you for karmic+1?
[10:04]  * ogra thought of it as addon package
[10:04] <ogra> yup
[10:05] <lool> ogra: Ok; now looking at what we can do in karmic
[10:05] <ogra> bloats the archive with duplkicates though ... but surely the best path to take
[10:05] <lool> ogra: So I dont think we want to change kernel at this point
[10:05] <ogra> well, both packages arent even in the archive
[10:05] <ogra> and unlikely to enter
[10:06] <ogra> so let me add hacks to the packages for now
[10:06] <lool> ogra: What we could do is have imx-libs build-dep on linux-headers-fsl-imx51 and copy the latest headers from there into imx-libs
[10:06] <lool> or use them directly there
[10:06] <ogra> thats what i asked initially for :)
[10:06] <ogra> it alreayd build-deps on the headers
[10:06] <lool> Well I prefer planning the clean fix first, then looking at immediate workarounds
[10:06] <lool> ogra: Do you that in imx-libs or xorg-imx51 or both?
[10:07] <ogra> and libimx-dev can easily copy them into /usr
[10:07] <ogra> i would do it in libimx-dev and make it ship them in /usr/include/linux
[10:07] <ogra> then have the xserver just b-d on libimx-dev
[10:07] <lool> Well dont you think we can implement the /usr/include/fsl-imx51 part directly?
[10:08] <ogra> that would mean to hack up the xserver package to look in there
[10:08] <lool> Which will be needed for the long term plan anyway
[10:08] <ogra> ok
[10:08] <ogra> so i'll do both
[10:08] <ogra> copy the headers and hack up xserver
[10:09] <lool> Cool
[10:09] <ogra> thanks :)
[10:09] <lool> ogra: Do you want to file the bug for the lucid stuff?
[10:09] <ogra> can do
[10:09] <lool> Ok
[10:09] <lool> ogra: I just had this bug again that I did a reboot on babbage 2.0 and it shutdown instead; do you know if we have a bug for that or shall I file one?
[10:09] <ogra> we dont
[10:10] <ogra> and i didnt see such behavior yet
[10:10] <lool> ogra: So reboot works for you?
[10:10] <ogra> yep
[10:10] <ogra> but thats 2.5
[10:10] <JamieBennett> lool: I had the exact same thing yesterday
[10:10] <lool> Right
[10:10] <ogra> you have other weird issues on your 2.0
[10:10] <lool> JamieBennett: On 2.0 and/or 2.5?
[10:10] <JamieBennett> 2.0
[10:10]  * ogra remembers the xterm issue
[10:10] <lool> JamieBennett: did you try on 2.5?
[10:11] <JamieBennett> I don't have the lead yet (going to a specialist shop this morning to get it.
[10:11] <JamieBennett> )
[10:13] <lool> b444386
[10:13] <lool> #444386
[10:14] <ogra> we should try to make that bug appear on 2.5 too, then it would at least shut off at all :P
[10:15] <lool> Eh
[10:15] <lool> I thought the same, that it was really ironic that one shuts off too easily while the other cant
[10:15] <ogra> yeah :)
[10:15] <JamieBennett> lool: have you seen video issues with 2.0 on the desktop? I have about 20 pixels missing from the top left hand corner running horizontal.
[10:15] <ogra> could that be caused by the toolchain issue ?
[10:15] <lool> ogra: make sure you include karmic+1 or something in the headers bug
[10:16] <ogra> will do
[10:16] <lool> ogra: No
[10:16] <lool> The toolchain issues are only problematic when doing stack unwinding in C++ stuff, so not in the kernel
[10:16] <ogra> ok
[10:16] <lool> JamieBennett: I did file a couple of video bugs on b2.0
[10:16]  * JamieBennett goes to look
[10:16] <lool> JamieBennett: 2.5 is more stable so nobody bothers with the 2.0 specific bugs
[10:17] <JamieBennett> ok
[10:17] <ogra> JamieBennett, does it go away if you definate a video= option on the cmdline
[10:17] <lool> JamieBennett: https://bugs.launchpad.net/ubuntu/+source/linux-fsl-imx51 and ~ubuntu-armel bugs are good places to check for them
[10:17]  * ogra thinks he has seen that before
[10:17] <lool> https://bugs.launchpad.net/ubuntu/+source/linux-fsl-imx51/+bug/430969
[10:17] <ubot4> Launchpad bug 430969 in linux-fsl-imx51 "Display unstable when running xterm" [Low,New]
[10:18] <ogra> JamieBennett, make sure to have the laters redboot-tools (0.7) you can easily edit the cmdline with redboot-cmdline from the running system
[10:18] <JamieBennett> ogra: haven't tried, just strange that its 1px x 20px top left and nothing else
[10:18] <lool> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/358956
[10:18] <ubot4> Launchpad bug 358956 in linux-fsl-imx51 "armel Babbage iMX51 line truncation and addition on VGA output" [Undecided,Incomplete]
[10:18] <ogra> i think it goes away if the driver gets a video= option
[10:18] <JamieBennett> ok
[10:19] <lool> JamieBennett: Can you reopen that last bug if it matches?
[10:19] <JamieBennett> lool: Will do.
[10:21] <ogra> JamieBennett, try with video=mxcfb:1024x768-32@60
[10:21] <JamieBennett> ogra: OK
[10:21]  * ogra hopes he has that right from the top of his head
[10:56] <lool> JamieBennett: also, the first bug (xterm makes display unstable) wasn't confirmed by anyone else; it's low prio but your confirmation would be nice
[10:59] <JamieBennett> lool: I'll look into it now
[11:06] <ogra> lool, the truncation bug is different though ... its just a small square above thats rendered black directly over the applications menu
[11:06] <ogra> s/above/at the top/
[11:26] <lool> JamieBennett: Or perhaps file a new bug, use your judgement
[11:27] <lool> It was painful to setup this local debmirror, but it feels so snappy when I use it that I really don't regret it!
[11:27] <lool> I think I'll enjoy deboostrap as well
[12:09] <JamieBennett> Just caught your Bug #430969 on camera lool :)
[12:09] <ubot4> Launchpad bug 430969 in linux-fsl-imx51 "Display unstable when running xterm" [Low,New] https://launchpad.net/bugs/430969
[12:36] <lool> k
[12:38] <ogra> ogra@babbage2:~/devel/kernel/linux-fsl-imx51-2.6.31$ grep -r "pin config changed" *
[12:38] <ogra> ogra@babbage2:~/devel/kernel/linux-fsl-imx51-2.6.31$
[12:38]  * ogra scratches his head
[12:38] <ogra> i wonder where "iomux_config_mux: Warning: iomux pin config changed" might come from on boot
[12:44] <ogra> its the very first bootmessage the babbage spits out
[12:55] <ogra> lool, the regulator errors on bug 438680 look suspiciously like a porting error
[12:55] <ubot4> Launchpad bug 438680 in linux-fsl-imx51 "please quieten down bootmessages" [Low,Triaged] https://launchpad.net/bugs/438680
[12:55] <ogra> i wonder if i should open a new bug for it
[12:55] <ogra> ogra@babbage2:~/devel/kernel/linux-fsl-imx51-2.6.31$ grep -r "with no identifier" drivers/*
[12:55] <ogra> drivers/regulator/core.c:		printk(KERN_ERR "regulator: get() with no identifier\n");
[13:02] <ogra> lool, i think bug 439282 should be high instead of medium
[13:03] <ubot4> Launchpad bug 439282 in linux-fsl-imx51 "does not power down the system properly" [Medium,Confirmed] https://launchpad.net/bugs/439282
[13:03] <ogra> what do you think ?
[13:21] <lool> ogra: I dont really care beween the two as long as it's fixed   ;-)
[13:21] <lool> ogra: I dont think it's a big deal for a developer board
[13:21] <lool> I find it a pain that sound doesn't work because I can imagine people using that for development
[13:22] <lool> And ethernet not working with NM is also a pain for a desktop use case, since ethernet is in the soc it hits all boards
[13:22] <lool> But wiring of the PMU is likely to differ per board (as it does on lange for instance) so I'm not too concerned that we use power when off; even if it's a bug we should try to fix for release
[13:23] <lool> ogra: Not sure what you want me to do about the regulator stuff?
[13:25] <ogra> nothing, i want to know if you would consider it better being a separate bug
[13:26] <ogra> i have no idea what it implies if the code isnt properly integrated with the core kernel regulator code
[13:26] <ogra> the messages seem to come from that
[13:26] <lool> Oh I dont know either
[13:26] <lool> probably best to check with kernle folks
[13:26] <ogra> yeah
[13:27] <ogra> waiting for brad or some other ARM person to get up though
[13:36] <NCommander> ogra, I talked w/ cjwatson. The easiest way to get partman-uboot tested is in an alternative CD environment. Probably best if I spend a few cycles working on this with your assistance (as we want alternates anyway ...)
[13:37] <NCommander> er
[13:37] <NCommander> lool,
[13:37] <ogra> NCommander, but d-i should come up, shouldnt it ?
[13:37] <NCommander> ogra, it doesn't get as far as partman
[13:38] <ogra> whats the stopper ?
[13:38] <lool> NCommander: Well they are mostly working already
[13:38] <NCommander> lool, they are?
[13:38] <lool> NCommander: For me alternates worked
[13:38] <lool> I think I tested netboot
[13:39] <lool> I got the console fonts bug and then the symlink issue IIRC
[13:39] <ogra> lool, right, cd detection fails on the normal alternates
[13:39] <NCommander> Oh, netboot works, but there isn't a way to easily preseed on netboot
[13:40] <ogra> netinst should work if you have a working NIC
[13:40]  * NCommander notes that he should probably write a boot.scr for netboot soonish
[13:40] <lool> NCommander: Oh and I had to do the cdrom-detect/try-usb=y thing
[13:40] <lool> NCommander: There isnt??  I thought there was a preseed file on the CD and it's just a kernel cmdline parameter
[13:41] <lool> Oh you mean in the image itself; I'm sure we can add that
[13:41] <NCommander> lool, ah :-)
[13:41] <lool> NCommander: files are in initrd, so it's probably trivial to add one and add a cmdline arg
[13:41] <NCommander> lool, yeah, I was going to make that change once I sit down and hit d-cd with a shovel
[13:44] <lool> it's debian-installer rather


[08:56] <alkisg> Hi, I have some schools with this graphics card: 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation NV5 [Riva TNT2 Model 64 / Model 64 Pro] [10de:002d] (rev 15)
[08:56] <alkisg> And it's causing this segfault in Ubuntu MATE 18.04: http://termbin.com/haem
[08:57] <alkisg> It runs fine up to lightdm, but then when mate starts, xorg produces this segfault. Any parameters that I could try to work around it?
[08:58] <tjaalton> NoAccel?
[08:59] <alkisg> Thanks, trying...
[09:24] <alkisg> Nah, the same :/
[09:24] <alkisg> Trying with vesa...
[09:25] <tjaalton> try uninstalling nouveau, then it should use modesetting
[09:25] <alkisg> Ty, trying...
[09:32] <alkisg> tjaalton: thank you, that worked, so I guess I can force modeset from xorg.conf if I don't want to uninstall nouveau (multiple clients netbooted from the same image)
[09:33] <tjaalton> sure
[09:33] <alkisg> I used to use "vesa" there, but it seems like that stopped working now?
[09:34] <tjaalton> not sure if it works with kms
[09:35] <alkisg> Hmm, this is what ltsp puts in xorg.conf, it used to work up to 16.04 but now in 18.04 it still loads nouveau:
[09:35] <alkisg> Section "Device"    Identifier "Device0"         Driver "modeset"   EndSection
[09:42] <tjaalton> you just said using modeset works?
[09:46] <alkisg> If I uninstall nouveau, it's auto loaded
[09:46] <alkisg> So modeset works fine if I apt purge nouveau
[09:46] <tjaalton> ok
[09:46] <alkisg> But if I try to specify Driver "modeset" in xorg.conf, it's not loaded, nouveau is, so it fails
[09:47] <alkisg> So something changed in xorg.conf handling/syntax...
[09:48] <tjaalton> the driver isn't called 'modeset'
[09:48] <tjaalton> but modesetting
[09:50] <tjaalton> man modesetting
[09:50] <alkisg> Whoops, thanks, trying that
[09:54] <alkisg> tjaalton: works fine, great, thank you. Should I report the nouveau segfault upstream?
[09:55] <tjaalton> maybe
[09:55] <tjaalton> if it's still broken on cosmic
[09:55] <alkisg> I'll see if I can find such a card locally then, to be able to test more easily
[09:55] <tjaalton> or just build the git version
[09:56] <tjaalton> cosmic has the same release version
[09:56] <tjaalton> git has some fixes that might help
[09:56] <alkisg> OK, will do
[11:12] <tjaalton> tseliot: hi, nvidia-340 needs fixing, and drop libGLESv1_CM.so.1
[11:12] <tjaalton> which is now shipped by libgles1
[11:12] <tjaalton> also on bionic
[11:13] <tjaalton> proposed
[11:13] <tjaalton> hmm, or add a diversion
[11:13] <tjaalton> forgot this version doesn't support glvnd
[11:17] <tjaalton> https://bugs.launchpad.net/ubuntu/+source/libglvnd/+bug/1791542
[11:40] <tseliot> tjaalton: we don't do alternatives any more in 340, so libGLESv1_CM.so.1 points to nvidia's binary
[11:41] <tseliot> same as /usr/lib/x86_64-linux-gnu/libEGL.so.1
[11:42] <tjaalton> so handle it the same way as libEGL.so.1
[11:47] <tjaalton> it doesn't use diversions either?
[11:47] <tjaalton> wonder how it's installable if it would conflict with libegl1
[11:49] <tjaalton> Setting up nvidia-340 (340.107-0ubuntu1) ...
[11:49] <tjaalton> dpkg: warning: version '*-*' has bad syntax: version number does not start with digit
[11:49] <tjaalton> dpkg: error: version '-' has bad syntax: revision number is empty
[11:49] <tjaalton> on a cosmic chroot
[11:50] <tjaalton> /var/lib/dpkg/info/nvidia-340.postinst: 121: /var/lib/dpkg/info/nvidia-340.postinst: update-initramfs: not found
[11:50] <tjaalton> and it does use diversions
[12:11] <tseliot> correct
[12:16] <tseliot> It should be easily fixed
[12:17] <tjaalton> yes, just add libGLESv1_CM.so.1 to the list of libs to divert
[12:17] <tjaalton> in the preinst
[12:25] <tseliot> and prerm, and postrm, because diversions are not to be trusted ;)
[12:25] <tjaalton> right
[14:06] <tseliot> tjaalton: nvidia-graphics-drivers-340 (340.107-0ubuntu2) has the change (in cosmic)
[14:07] <tseliot> I need to backport that to bionic
[14:08] <tjaalton> cool, thanks


[01:29]  * ball sighs
[11:26] <zxmpi> on this day in 1982 sony and philips launched the cd player in japan
[11:47]  * penguin42 hands zxmpi some marmalade
[11:58] <zxmpi> great show tomorrows world
[12:07] <zxmpi> https://www.youtube.com/watch?v=bMp1pSVxoqw tomorrows world compact disc
[16:37] <m0nkey_> Fun starts tonight, one final full backup of my workstation then I finally get Ubuntu installed.
[16:50] <zxmpi> good luck
[17:56] <penguin42> hmm, why have Symbio sent me a notification for a new DD given they've gone under


[00:36] <[Relic]> Is there a way to track down what goes into swap?  I have never had anything go into swap before and there is no reason for it to be used but a small amount keeps showing up
[01:08] <nano> Good day.
[01:08] <nano> I try to install kubuntu on an nvme hard drive with Intel Optane, everything is correct until I restart and my PC go directly to windows without GRUB appearing, how can I correct it
 Did you manual partition?  If so, did you ensure to create a ~300MB EFI partition?
[01:19] <nano> Hey Darin Miller tahnk you for you answer, in the efi partition I have 260 mb and it is all busy, how can I create it without breaking windows?
[01:20] <nano> Sorry you are Ircsomebot
 Yes you can dual boot along side windows
[01:21] <nano> in the C partition?
[01:21] <nano> in the Windows C partition?
 Ensrue to tell the kubuntu install to use the UEFI partition.  (The installer usually warns you if you forget but the message is a little cryptic)
 No, UEFI will be a fat32 partition by itself.
[01:26] <nano> when I see the partition table of the manual installer of kubuntu until below appears to install the boot and only puts the disk nvme. I have not seen the option install on uefi partition
[01:33] <nano> I leave the chat, I will check the installer
 ok
 Let me know if you need more info...
[01:50] <nano> Hi again... In the NVME disk fof all there is a free space of 1 mb without marking anything.
[01:50] <nano> Then there is the first NVME0N1P1 partition that is the EFI partition (I don't know if I should indicate in the boot installer that it should be installed there)
[01:51] <nano> Then there is the second NVME0N1P2 partition with 16 mb that I think is Optane
[01:52] <nano> Then there is the third partition NVME0N1P3 which is the windows installation
[01:53] <nano> Should I indicate that the boot loader is installed in NVME0NP1 where is the EFI partition?    You point the install to park the necessary boot files in partition (NO formatting).
 To clarify DO FORMAT NVME0N1P1.  Resize NVME0N1P3 and create a new partition with the new space  (at least 50GB). Format the new partition.
 If you don't mind a more complex approach.  Use a 30G to 50G partition for root "/", a 5 GB parition for /opt and whatever size you want for /home.  If you plan to install apps like wine-staging, chrome, telegram etc, place them in your /opt directory.  Then assign each of the above partitions in manual boot loader menu.
 The above adivice is a little complex if you have never played with partitions, so feel free to ignore.
 However, the complex approach is very handy for re-installs as you do not need to reformat /opt and /home.
 Re-installs are hardly necessary anymore as the upgrade process is well tested/polished.  But if you like to experiment like I do... sometimes re-install can be faster than fixing the damage caused by experimenting....
 Sup
 nm
[05:48] <Heiak> hi
[05:48] <Heiak> I just opened a "mobile hotspot" on my phone and connected my Kubuntu laptop to it.
[05:49] <Heiak> the phone shows me in the status bar how much traffic the WiFi connection caused
[05:49] <Heiak> so, it jumped up to 7 MB, then above 20, then above 50 MB
[05:49] <Heiak> within less than a minute
[05:49] <Heiak> but, no browser was open on my laptop
[05:49] <Heiak> also no downloads, etc.
[05:50] <Heiak> How can I monitor all network traffic on Kubuntu?
[05:50] <Heiak> I would like to know what causes downloads without me doing anything
[05:50] <diogenes_> Heiak, run etherape.
[05:51] <Heiak> thank you
[05:55] <Heiak> diogenes_, I installed it, but it's only a GUI
[05:55] <Heiak> diogenes_, can't I view it in the command line?
[05:56] <diogenes_> Heiak, so what's the problem with the gui?
[05:56] <Heiak> I feel like I am not really getting much information out of it
[05:56] <Heiak> I'll google for a command line based solution
[05:56] <Heiak> thank you anyway
[05:58] <diogenes_> there is a lot of info if you click on nodes but ok.
[06:01] <Heiak> diogenes_, I appreciate your help, but the key advantage of Linux is that we do _not_ have to deal with GUI's ;)
[06:03] <diogenes_> hehe i pick whatever works faster with less hassle but to each his own.
[07:17] <lordievader> Good morning
[12:22] <BluesKaj> Howdy all
[13:48] <user|14088> I have installed kubuntu 18.04 and update the packs.. discover software center is too slow..please help-me
[13:52] <BluesKaj> user|14088, that's a network problem, could be the repository in your country is very busy or your network speed is slow
[13:54] <user|14088> bluesKaj thanks
[18:30] <thomas_> hello
[18:32] <thomas_> i need help
[19:35] <yuradoc> Hello. I can't restart plasmashell, course it tell me some qt plugin isn't found
[19:36] <yuradoc> What to do? I need to restart it, because it won't load fully.
[19:37] <yuradoc> Plugin name is "xcb"
[19:50] <diogenes_> yuradocMC, then install it.


[02:48] <Woofybean> bit of a left field question, reviewing various bits of performance tuning, any modern up to date pointers for tuning directory cache and so on for fast rsync and content listing?
[02:53] <sarnold> Woofybean: the bytes in here are kinda specific to my machine -- 128 gigs ram, and I wanted the filesystem to 'own' the machine: $ cat /etc/modprobe.d/zfs.conf
[02:53] <sarnold> options zfs l2arc_write_boost=1073741824 l2arc_write_max=1073741824 zfs_arc_max=120847181648 zfs_arc_meta_limit_percent=95 zfs_arc_dnode_limit_percent=75
[02:53] <sarnold> that raises the arc from 64g to 120g, drastically raises the meta limit to 95 of arc, drastically raises the dnode percentage of the meta portion to 75 percent of that
[03:05] <Woofybean> thanks sarnold, I'll give that a test
[03:05] <Woofybean> this is a 256GB machine, so more than sufficient for caching the directory tree
[03:06] <sarnold> hah I'll say
[03:06] <sarnold> mine was tuned to try to provide good ripgrep speeds over the unpacked archive
[03:06] <sarnold> the 'normal' archive might have fit in the defaults


[10:16] <Myrtti> anyone keep an eye on #ubuntu, the sudo discussion is starting to veer offtopic soon
[10:16] <Myrtti> I need to go pack for a flight
[18:36] <DJones> !list > mitico08
[22:53] <Myrtti> hi chillpil9_, Alexander-HostUS


[00:00] <ninetls> Unit193: that's strange, I tried to use xdt-autogen against tarball but don't see any errors
[00:02] <ninetls> Unit193: try autoreconf --install
[00:03] <Unit193> ninetls: I forgot about the xdt-autogen part.  :D
[00:05] <ninetls> it will work
[00:05] <ninetls> but I don't know how ppa work so I don't sure
[00:06] <Unit193> Sure it'll work, but I'm kind of phasing 16.04 out.  However, if you want it, sure thing.
[00:06] <ninetls> I wanted to show it my friend
[00:07] <Unit193> Will be there in a minute.
[00:34] <ninetls> Unit193: I see. thanks
[00:38] <Unit193> Nothing else I can do for ye?
[00:39] <ninetls> no, thanks
[00:49] -SwissBot:#xubuntu-devel- ::xubuntu-artwork:: [greybird] r524 Explicitly set background color in stack (Fixes #194)... (by Simon Steinbeiß)
[01:15]  * Unit193 just noticed something!
[01:15] <Unit193> bluesabre: Did you move?  +0400 :P
[01:15] <bluesabre> Unit193: woops! :D
[01:15] <bluesabre> I copy pasted and cheated the package a lot
[01:15] <bluesabre> Missed that details :D
[01:15] <Unit193> I know,I could tell. :D
[01:16] <bluesabre> ;')
[01:16] <Unit193> ...Now just to get it in.
[04:27] <Unit193> 0_o
[04:27] <Unit193> `dcmd`
[09:06] <Unit193> bluesabre: https://sigma.unit193.net/source/xfdashboard_0.7.3-0ppa1_i386.build that's a lot of symbol changes and drops...
[09:11] <Unit193> Pushed to https://loki.unit193.net/cgit/users/unit193/xfdashboard.git/ in a slightly modified layout.
[12:04] -SwissBot:#xubuntu-devel- ::xfce4-announce:: ANNOUNCE: xfconf 4.13.3 released @ http://xfce.10915.n7.nabble.com/ANNOUNCE-xfconf-4-13-3-released-tp49578.html (by Ali Abdallah-4)


 I don't know if saw but build is failing on a test issue
[08:21] <seb128>         	Error:      	Not equal:
[08:21] <seb128>         	            	expected: "adsysd\tdev\n"
[08:21] <seb128>         	            	actual  : "adsysd\t0.3ubuntu1\n"
[08:21] <seb128> that's TestAppVersion
[08:21] <jibel> seb128, yes, it's fixed, we'll do a new upload
[08:21] <seb128> great
[08:48] <oSoMoN> salut seb128
[09:14] <luna> Hello any idea of why there is no new Hirsute Daily builds today?
[09:17] <seb128> luna, hey, it's beta week but I don't know if that means the iso builds should be stopped ...
[09:18] <seb128> sil2100, ^ can you help reply to that question?
[09:20] <sil2100> luna, seb128: yes, during Beta week dailies are stopped as we will be only doing controlled builds until Beta is released
[09:20] <jibel> luna, there is no daily during beta week, sil2100 said he would be spinning some today
[09:20] <sil2100> I'll be starting some builds soon, but with possible respins later
[09:21] <seb128> luna, there you go ;-)
[09:21] <seb128> thanks sil2100 and jibel
[13:54] <kenvandine> Anyone here looking for the weekly IRC meeting, see https://discourse.ubuntu.com/t/announcing-the-ubuntu-desktop-team-indaba-ama-april-23-2021/21591
[14:25] <hellsworth> good morning desktopers
[14:25] <oSoMoN> good morning hellsworth
[14:26] <hellsworth> hi there oSoMoN
[14:28] <ricotz> hey hellsworth
[14:28] <hellsworth> hey ricotz .. responding to your email now
[14:28] <ricotz> hellsworth, ok
[14:29] <ricotz> hellsworth, or PM, if you want
[15:18] <seb128> hey hellsworth, how are you?
[15:18] <hellsworth> hi seb128 i'm pretty good! how are you?
[15:19] <seb128> I've been better, I got the cold from the kids over the weekend which knocked me down in bed for a few days, I start feeling better though
[15:20] <hellsworth> yeah i hear you. Aurelia had a cold for half a day and i'm on day 8 but almost at 100% now :)
[15:20] <seb128> I did a covid test and they didn't call back which should mean it's negative (I don't like the 'if you didn't hear back then it's negative' since it's not explicit and could be that they screwed)
[15:20] <hellsworth> oh here they call you either way
[15:20] <seb128> that's better!
[15:21] <seb128> on other news, result from recent hacking which could interest people working on desktop snaps
[15:21] <hellsworth> and covid tests here are $150 so i wasn't eager to go get one since i didn't have a fever
[15:22] <hellsworth> yes! your logs right? ken mentioned how we could add some automated builds there too. it's on my todo to look into how the heck to do that :)
[15:22] <hellsworth> i'm gearing up for a culture fit interview here shortly though (first one ever! i'm both nervous and excited)
[15:22] <seb128> https://people.canonical.com/~platform/desktop/trello.log
[15:23] <seb128> right, that's an updated log ^
[15:23] <seb128> check for 'outcome' to have a summary
[15:23] <seb128> I'm going to close the cards that should be moved now
[15:24] <seb128> the code needs to be smarter though
[15:24] <seb128> like there i a stack of libreoffice cards under
[15:24] <seb128> 'Doing promotion for libreoffice would help resolving'
[15:24] <hellsworth> yeah is there a way to check that if a card already exists for a snap, to not create another one?
[15:24] <seb128> which the label I use when there is a newer revision available in another channel
[15:24] <seb128> but in the libreoffice case it's edge which is outdated
[15:25] <seb128> so probably it needs a rebuild in edge
[15:25] <seb128> that would close that stack of cards if that happened
[15:25] <hellsworth> why is the LO in edge being looked at instead of latest stable?
[15:26] <hellsworth> also there is a new build in candidate from today that I plan to test and release (with ricotz's blessing)
[15:26] <seb128> it's not, the top of the log has details
[15:26] <seb128> see https://paste.ubuntu.com/p/M9TGgpzwwc/
[15:26] <seb128> Those versions are known to be impacted by a CVE
[15:26] <seb128> {'amd64': 205}
[15:26] <seb128> The versions available in the store are
[15:26] <seb128> {'amd64': {'stable': 205, 'candidate': 207, 'edge': 193}}
[15:26] <seb128> edge is on r193 still it seems (unless the code I used to check the store is buggy)
[15:27] <seb128> $ snap info libreoffice | grep edge
[15:27] <seb128>   latest/edge:      <IP_ADDRESS> 2020-10-08 (193)
[15:27] <seb128> seems not
[15:27] <seb128> why is edge on 7.0 where stable is on 7.1?
[15:28] <hellsworth> well really edge isn't used very often. mostly it's just candidate and stable. i could close edge to make it less confusing
[15:28] <seb128> yes, I was going to say
[15:28] <hellsworth> ok that makes sense that all channels are checked for vulnerabilities
[15:28] <seb128> because the script is right, edge currently is impacted by those CVE
[15:28] <seb128> and an edge which is outdated is probably not really on the edge :)
[15:29] <seb128> I would +1 to close it, it's just confusing imho if you autobuild to candidate that's enouh
[15:29] <ricotz> it there a pocket-copy mechanism to copy candidate to edge?
[15:29] <hellsworth> also, rico and i were talking about changing the versioning scheme of the LO snap, so it is something more like debian. so every time we update the snap it would be <IP_ADDRESS>+uc20~1 , <IP_ADDRESS>+uc20~2 etc. do you see any problem with this?
[15:29] <seb128> ricotz, in the store UI you can dnd revisions around
[15:29] <ricotz> hellsworth, no, I don't want to change the version scheme
[15:30] <hellsworth> then i totally misunderstood you
[15:30] <ricotz> hellsworth, my assumption was the "version" is *not* just informational
[15:31] <seb128> it is informational
[15:31] <ricotz> so I was just thinking about distinguishing uc18 from uc20 builds
[15:31] <hellsworth> ok i've closed latest/edge
[15:31] <ricotz> but edge is perfect for a uc20 build
[15:32] <ricotz> ok
[15:32] <hellsworth> we don't need to keep around uc18 builds though. move everyone to the uc20 updated one
[15:33] <seb128> hellsworth, thanks! I refreshed the log, it just moved a stack of libreoffice cards to be closed ;-)
[15:33] <hellsworth> great!!
[15:54] <seb128> kenvandine, could you trigger a rebuild on https://launchpad.net/~ken-vandine/+snap/lp-build-snap ? it would knock a few cards out of the trello board
[15:56] <GunnarHj> seb128: Today's c++ symbols file madness:
[15:56] <GunnarHj> https://launchpad.net/~gunnarhj/+archive/ubuntu/marisa/+packages
[15:56] <GunnarHj> Can you sponsor please?
[15:56] <seb128> GunnarHj, do you know why those changed?
[15:57] <GunnarHj> seb128: No. Must be something with the arch environment. (Similar to opencc yesterday.)
[15:58] <seb128> GunnarHj, how did you notice? It might be due to the lto toolchain change, could you perhaps check with d_oko if updating like that is the right fix?
[15:59] <GunnarHj> seb128: I saw them here:
[15:59] <GunnarHj> https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20210325-hirsute-hirsute.html
[16:00] <GunnarHj> But sure, I can check with d_oko.
[16:00] <seb128> right, please check with him, listing random arch for individual symbols like that doesn't seem a proper way to handle whatever is happening, we should maybe turn off lto for it or something
[16:01] <RikMills> that looks very much like lto
[16:01] <GunnarHj> seb128, RikMills: What's lto?
[16:02] <seb128> GunnarHj, https://wiki.ubuntu.com/ToolChain/LTO
[16:02] <GunnarHj> thx
[16:02] <seb128> which was enabled 10 days ago (see ubuntu-devel@ emails)
[16:04] <seb128> symbols for cpp are really annoying to maintain :-/
[16:06] <GunnarHj> seb128: Yeah.. So are you saying that disabling lto is the right way to deal with it? Or should I still consult with d_oko?
[16:08] <GunnarHj> seb128: Under "Known issues" I read:
[16:09] <GunnarHj> "C++ symbols files differ, usually because some symbols for template instantiations are optimized out."
[16:13] <RikMills> the 3 packages I had with this I just marked the symbols as optional=lto. BUT I already had delta, and knew the next time I was likely to sync/merge from debian, they would be be doing bookworm and probably have LTO on
[16:13] <RikMills> |I think you just pick the path that seems most sensible for you
[16:17] <GunnarHj> RikMills: Ok.. We already have a delta in these two cases, and haven't really sorted that yet. So if it's right to change the symbols file rather than disabling lto, I think that just letting pkgkde-symbolshelper do its job makes sense for now.
[16:21] <RikMills> well, the symbolshelper doesn't know it is a toolchain change, so goes off doing complicated arch specific modifications. applying what I knew from context, and adjusting the ones it changed to marking as optional seemed better to me
[16:21]  * RikMills shrugs
[16:22] <RikMills> trying to second guess what debian might do when they have lto on is hard
[16:29] <GunnarHj> RikMills: Right. But our cases are in preliminary states, and we still need to redo it to get a sensible solution going forward.
[16:29] <GunnarHj> RikMills: That said, if you are able to give me some handholding how exactly to add "optional" to deal with Debian/Ubuntu delta it would be much appreciated.
[16:58] <kenvandine> seb128: done
[19:07] <seb128> kenvandine, thanks
[19:19] <seb128> kenvandine, also please kick rebuilds for xournalpp , transporter and leafpad
[19:19] <kenvandine> Ok
[19:19] <seb128> thanks
[19:19] <seb128> I would do those bug I think they are yours only currently right?
[19:20] <seb128> I will test candidates tomorrow and ping you for promotions to stable if things work
[19:20] <seb128> trying to clean some of those USN rebuilds old cards
[19:20] <kenvandine> Yeah, not sure the team should be on the hook for them, but I appreciate the help!
[19:21] <kenvandine> leafpad is my test case for a gtk2 snap and themes
[19:21] <seb128> kenvandine, well, you are putting cards for those on the team trello board, which is sort of putting the team involved... ;)
[19:22] <kenvandine> Yeah :-)
[19:22] <seb128> hellsworth, https://launchpad.net/~hellsworth/+snap/glimpse-editor-stable sounds like you disabled the i386 build? if so you should perhaps remove the i386 binary from the store since it's outdated, it would reflect reality that we aren't supporting that arch anymore
[19:23] <seb128> I did clean out i386 binaries for most gnome snaps
[19:23] <hellsworth> that is a great idea. i'll do that right now
[19:23] <seb128> the store UI isn't making that easy for you though
[19:24] <seb128> you need to close a channel and move back revisions for the other archs
[19:24] <seb128> thanks!
[19:24] <seb128> it feels weird having to close stable to get ride of stable/i386
[19:24] <seb128> but seems it's the only way atm
[19:25] <hellsworth> wait... so i'm looking at this in the store ui
[19:25] <seb128> https://launchpad.net/~hellsworth/+snap/glimpse-editor is failing to apply a launcher patch?
[19:25] <hellsworth> why do i need to close stable? it has build 85 for i386
[19:26] <seb128> there is no other way to remove that build 85 from stable afaik
[19:27] <kenvandine> seb128: i triggered builds for leafpad and xournalpp
[19:27] <kenvandine> looks like transporter has been failing to build
[19:27] <seb128> and you want to remove because all the i386 builds up to edge are outdated and impacted by some CVE issues
[19:27] <seb128> kenvandine, ah :/ I can try to look at that tomorrow
[19:27] <hellsworth> do i need to close stable, beta, and edge then?
[19:27] <seb128> I think so
[19:27] <hellsworth> darn ok
[19:27] <seb128> it really sucks as an UI but I didn't find a way around it
[19:27] <hellsworth> man that sucks
[19:28] <seb128> I usually moved stuff around
[19:28] <seb128> like moved stable to beta (when that was unused), saved
[19:28] <kenvandine> https://www.irccloud.com/pastebin/DMNONGLo/
[19:28] <seb128> then moved back amd64/... to stable
[19:28] <kenvandine> vala errors in the build
[19:28] <seb128> then closed beta
[19:28] <seb128> kenvandine, ah, you need ricotz :)
[19:29] <hellsworth> i haven't touched glimpse in a good bit.. Bobby, the upstream dev took over but then didn't so let me pick it back up and dustoff the i386 binaries
[19:29] <seb128> kenvandine, is gtk2-common-themes something we can easily rebuild? last rebuilt on     22 June 2020
[19:29] <hellsworth> but is there a store person that we could ask if there's a better way?
[19:29] <hellsworth> rather who is the best store person
[19:29] <kenvandine> i haven't touched transporter in ages
[19:29] <kenvandine> i'll update it to gnome-3-38 extension
[19:30] <seb128> hellsworth, you can ask on ~snaptore on the private chat but I asked there and the reply I got was to close the track, maybe you find someone with a better advice, worth asking again
[19:30] <hellsworth> ok maybe not worth it. i'll just close and reopen
[19:30] <hellsworth> oh no i didn't know you had asked. thanks seb :)
[19:31] <seb128> np!
[19:31] <seb128> I guess it's uncommon enough that they didn't really think about it
[19:31] <seb128> kenvandine, sorry I didn't mean to pull you into fixing things there :-)
[19:31] <hellsworth> fair enough
[19:32] <hellsworth> sometimes i just assume there's a better way and idk what it is
[19:32] <kenvandine> seb128: no worries, it needs attention :)
[19:32] <seb128> it's a fair assumption to make and right to ask
[19:32] <sarnold> where's the infomercial voice-over announcer to tell us what can solve our problems for two simple payments?
[19:32] <seb128> kenvandine, you try rebuilding gtk2-common-themes as well if you can?
[19:32] <seb128> and I will stop there for today :p
[19:32] <seb128> next round tomorrow!
[19:32] <kenvandine> i took a stab at changing it to gnome-3-38 and kicked a build
[19:33] <seb128> great
[19:33] <kenvandine> seb128: ignore gtk2-common-themes
[19:33] <kenvandine> it doesn't have any binaries
[19:33] <seb128> ah
[19:33] <seb128> so we just close those cards?
[19:33] <kenvandine> yes
[19:33] <kenvandine> sorry, should have mentioned that :)
[19:33] <seb128> any way to teach your script magic to not card for this component?
[19:33] <seb128> np
[19:34] <kenvandine> maybe :)
[19:34] <kenvandine> right now my mail filter is pretty generous
[19:34] <kenvandine> we can look at filtering it in butler on trello
[19:34] <kenvandine> ok, while this builds i'm going to go back to being on holiday :)
[19:35] <kenvandine> i'll be back at my keyboard tomorrow :)
[19:35] <seb128> kenvandine, enjoy
[19:36] <seb128> and I'm going back to have an evening and some rest
[19:36] <seb128> have a nice evening and see you tomorrow desktopers!
[19:36] <kenvandine> good night
[19:44] <ricotz> kenvandine, what kind of vala error?
[23:36] <KGB-2> gnome-shell ubuntu/focal 21d148c Marco Trevisan * pushed 23 commits (first 5 follow) * https://deb.li/FJvs
[23:36] <KGB-2> gnome-shell ubuntu/focal 8e7e933 Ivan Molodetskikh js/ui/workspacesView.js * workspacesView: Fix copy-paste error * https://deb.li/3dMtU
[23:36] <KGB-2> gnome-shell ubuntu/focal 442d44c Mike Gerow js/gdm/loginDialog.js * loginDialog: Make notListedButton accessible * https://deb.li/u8nn
[23:36] <KGB-2> gnome-shell ubuntu/focal e48f6ce Florian Müllner (6 files in 5 dirs) * Bump version to 3.36.8 * https://deb.li/i4xf7
[23:36] <KGB-2> gnome-shell ubuntu/focal 3ae4a28 Marek Černocký po/cs.po * Updated Czech translation * https://deb.li/WVOy
[23:36] <KGB-2> gnome-shell ubuntu/focal 419415d Marek Černocký po/cs.po * Revert "Updated Czech translation" * https://deb.li/3FxG4
[23:36] <KGB-2> gnome-shell signed tags 3c46a61 Marco Trevisan ubuntu/3.36.9-0ubuntu<IP_ADDRESS> * gnome-shell Debian release 3.36.9-0ubuntu<IP_ADDRESS> * https://deb.li/AMPM
[23:36] <KGB-2> gnome-shell tags 5e97ed9 Marco Trevisan upstream/3.36.9 * Upstream version 3.36.9 * https://deb.li/3uDMj
[23:37] <KGB-2> gnome-shell upstream/3.36.x 32a7bcc Marco Trevisan * pushed 15 commits (first 5 follow) * https://deb.li/fZKN
[23:37] <KGB-2> gnome-shell upstream/3.36.x 6ecfe4e Ray Strode js/ui/panel.js * panel: Disconnect destroy signal handler when needed * https://deb.li/3Y8yx
[23:37] <KGB-2> gnome-shell upstream/3.36.x 05f051e Florian Müllner src/shell-screenshot.c * screenshot: Handle window screenshot failures gracefully * https://deb.li/34Jcg
[23:37] <KGB-2> gnome-shell upstream/3.36.x 906a0d1 Florian Müllner js/ui/dateMenu.js * dateMenu: Fix temperature edge case * https://deb.li/ijM4l
[23:37] <KGB-2> gnome-shell upstream/3.36.x 8e7e933 Ivan Molodetskikh js/ui/workspacesView.js * workspacesView: Fix copy-paste error * https://deb.li/3dMtU
[23:37] <KGB-2> gnome-shell upstream/3.36.x 442d44c Mike Gerow js/gdm/loginDialog.js * loginDialog: Make notListedButton accessible * https://deb.li/u8nn
[23:37] <KGB-2> gnome-shell pristine-tar b699e1d Marco Trevisan (Treviño) gnome-shell_3.36.9.orig.tar.xz.delta gnome-shell_3.36.9.orig.tar.xz.id * pristine-tar data for gnome-shell_3.36.9.orig.tar.xz * https://deb.li/iVjI
[23:48] <KGB-2> mutter Marco Trevisan 234231 * commented merge request !70 * https://deb.li/qMRe
[23:48] <KGB-2> mutter ubuntu/master Marco Trevisan * [close] merge request !70: Remove G_PARAM_EXPLICIT_NOTIFY from the "opacity" property * https://deb.li/3jtnn