=== cpaelzer_ is now known as cpaelzer === kklimonda_ is now known as kklimonda === mwhudson_ is now known as mwhudson === FlannelKing is now known as Flannel [09:43] oSoMoN, seb128: libreoffice ftbfs, blocking the poppler transition [09:44] doko, talk to Steve, he did that upload? [09:44] seb128: I'm talking to you, because you started the poppler transition ... [09:45] doko, I know, and we didn't finish it yet, not my fault if people do random uploda that fail to build [09:46] doko, we don't have rules that a transition started needs to be finished less than a business day, things can stay in proposed for some days the time to be sorted out [09:47] sure, that's the best recipy for entanglement of transitions [09:47] if you say so [09:48] oSoMoN, we need an upload with https://github.com/LibreOffice/core/commit/5e8bdd92 it looks like, do you want to include other changes while we do an upload? [10:02] seb128, looking [10:02] oSoMoN, thx [10:05] seb128, nothing else needed I think, want me to do the upload? [10:05] oSoMoN, that would be nice, be careful that they tried a no-change rebuild upload so you need to bump the revision over that [10:06] seb128, yeah, I'll integrate that changelog entry in the vcs [10:06] good [10:06] oSoMoN, thx! === sam_w_ is now known as sam_w [11:23] seb128, doko: uploading libreoffice 1:6.1.3-0ubuntu5 [11:33] darn, that upstream patch wasn't enough [11:53] :( [11:58] changing ssh to use systemd by default is a terrible idea. People will keep editing /etc/ssh/sshd_config to change the port and it magically will not do anything === cpaelzer__ is now known as cpaelzer [12:05] LtWorf: it works fine here [12:08] jbicha: until u want to change port, yes… [12:08] you need to change it in /lib/systemd/system/ssh.socket, something like that [12:09] since it's systemd doing the listening actually [12:12] LtWorf: no I mean it literally works here :) [12:13] have you actually tried it? [12:13] you probably need to reload the service but I think that's typical with system services [12:13] maybe u don't have the socket activated one? [12:14] systemctl status ssh.socket [12:14] should be active [12:14] and systemctl status ssh.service should be dead [12:14] why should it be dead? [12:14] because no connection was received yet [12:14] so no ssh is running [12:15] but I am connected, that's how I'm talking to you :) [12:15] so of course it works for u :P [12:15] that socket unit isn't enabled in the shipped package [12:15] but before u connect to ssh [12:15] yeah the socket is inactive (dead) here [12:15] no? Why is it enabled for me then? I am quite sure i didn't enable it [12:15] unless because am using ubuntu core? [12:16] I can't very well tell you what it looks like before I connect to it since my ssh server is on a VPS :) [12:16] but i'd imagine the package to be the same, unless the configuration is different [12:17] Check if there is a symlink in /etc/systemd/system/sockets.target.wants/? [12:17] is your sshd provided by a snap? [12:17] nope [12:18] hm let me go to lunch, i'll report back later [12:19] oSoMoN: arch has an extra hunk in their 0.71 patch for wrapper_gpl.cxx and a 0.70 patch which might fix the other errors? [12:19] https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/libreoffice-fresh [12:58] acheronuk, thanks, I'll have a look in a moment [13:03] Laney: yep [13:03] there is a link [13:04] lrwxrwxrwx 1 root root 30 Nov 26 12:55 ssh.socket -> /lib/systemd/system/ssh.socket [13:06] but I can't figure out what installs it dpkg -S /etc/systemd/system/sockets.target.wants/ssh.socket [13:06] returns nothing [13:06] mvo, ^ ?! [13:07] LtWorf, it does look like said system is using the inetd-style socket activation, which is indeed at the moment not sensitive to some of the sshd_config changes. =/ [13:08] eh, i know, but that symlink is not present in the core .tar.gz, and I can't find out what package placed it there, so besides disabling it myself, I am not sure how to prevent it from being there [13:15] LtWorf, unless you are looking at the wrong core? [13:15] =) [13:15] (we have had multiple Core products over the time) [13:17] well no i checked in the same .tar.gz that I used to create my vm :D [13:17] ubuntu-base-18.04.1-base-amd64.tar.gz [13:26] LtWorf: openssh-server postinst script, "deb-systemd-helper enable 'ssh.socket' >/dev/null || true" [13:30] on my debian system tho the link is not there, even if the .socket file has `WantedBy=sockets.target` [13:30] but am not sure why [13:31] anyway i fixed it, but is it something that should be addressed by the distribution? [13:31] LtWorf: look at the postinst script; the action is conditional [13:33] just compares versions [13:33] The fragment starting with "# Automatically added by dh_systemd_enable/11.1.6ubuntu1 " [13:34] ah i was looking at the debian one [13:34] (why is it different damn!) [13:41] hi #foundations, I think https://people.canonical.com/~ubuntu-archive/proposed-migration/cosmic/update_excuses_by_team.html is stuck, the timestamp currnetly shows 2018.10.30 08:18:06 [13:59] mwhudson: ^^^ [13:59] ahasenack: wait, this is cosmic, not updated anymore [13:59] ohh [13:59] hmpf [13:59] * ahasenack updates his bookmark [14:00] I thought it was a permanent link, like proposed migration for the devel series, I didn't realize it had "cosmic" in it until now [14:00] thanks [14:59] rbalint: i see you're doing bzr-to-git migration [14:59] https://gist.github.com/smoser/e4e5388faa6dcc92d8acfb1b7fbabb7c [15:00] i have meant to put that into a snap or something to make it easier to "install" [15:00] but please read the "Features" added there. [15:00] i think they're useful. [15:04] responded to ml post. [15:14] smoser, thanks for raising this [15:16] rbalint: thanks for converting things to git :) [15:20] smoser, if bazaar upstream showed any activity i'd suggest pushing for including the patch into bzr-fastexport [15:23] i filed bug [15:24] and put patch on bug [15:24] but i kind of agree that it isn't perfect [15:24] so i just convert mine that way. [15:24] smoser, i'm giving a try to brz fastexport in may work already or they take patches [15:24] and others may argue that this information fits better in a 'git note' than in commit message. [15:26] smoser, hm, that makes sense [15:27] smoser, especially for the bzr commit id [15:28] i think that replacing the --fixes with git notes is essentially a "equivalent" conversion [15:28] but in launchpad many things are using LP: # [15:28] and same for github. [15:29] so i think from that perspective the commit-message format is fine [15:29] ie, i expect that people contributing to livefs would continue using 'LP: #' so it makes sense to just do that. [15:30] and if later someone said "hey we should all use git notes" [15:30] then that could be handled. [15:34] smoser, pushing and pulling notes seems to be a pain :-( [15:34] smoser, (i just learned they exist :-)) [15:34] https://web.archive.org/web/20180121193320/http://git-scm.com/blog/2010/08/25/notes.html [15:37] yeah. [15:38] i think comments are the right thing for now. [15:45] agreed === geofft_ is now known as geofft === zyga is now known as zyga|afk [18:34] does anyone know where the default I/O scheduler configuration sits, or what it is? [18:35] teward: Baked into the kernel, and not sure. [18:35] cking: ^ [18:36] one can tweak it with /sys/block/sd*/queue/scheduler [18:36] cking: right, but i'm curious what the kernel-baked default is [18:36] less so tweaking it [18:36] teward, so, CFQ or deadline [18:37] (base)adconrad@nosferatu:~$ cat /sys/block/sda/queue/scheduler [18:37] noop deadline [cfq] [18:37] (base)adconrad@nosferatu:~$ cat /sys/block/sdb/queue/scheduler [18:37] noop deadline [cfq] [18:37] I assume the one in brackets is the one in use? [18:37] modern kernels will have mq-deadline for multiqueue devices [18:37] the one in brackets is the one in use [18:37] you can modprobe other schedulers, such as bfq (if it's available) [18:39] generally, /sys/block/sda/queue/rotational tells you if it's a spinny driver or not. I suggest nop for non-spinny media and cfq or deadline for spinny [18:39] cking, infinity, teward, we also have an init script; upstart job; systemd unit which tweaks the scheduler on boot as well! on per-architecture basis! [18:39] (depending on the release) [18:39] or not [18:40] * xnox ponders if i'm thinking of the cpu scheduler, instead of hte block devices [18:40] and now i can't find it. [18:40] I'm also evaluating the current 4.19+ defaults to make a "reasonable" best default depending on the type of device [18:41] cking, do you have any recollection, of the thing, i'm thinking off....? [18:41] xnox, we used to put the CPU scheduler into an agressive mode on boot and then fallback to powersaving after that [18:41] and then we have other tweaks if it was a laptop in pm utils [18:42] ah [18:43] but in the strange new world of systemd I think things got cleaned up, and I'm not sure what systemd does not [18:43] *now [18:44] the brave new world of I/O scheduler choice will also provide kyber, bfq, etc [18:45] so much choice, so many tunables, so much for making a reasonable default ;-) [18:45] cking: Oh, hrm. All this time, my SSDs should have been running noop? [18:45] xnox: i think you're thinking CPU scheduler [18:45] cking: Definitely would be nice to make those defaults more defaulty. :) [18:45] because I see those for CPU sched. [18:46] yeah probably [18:46] but also, failing to find traces of that thing now. [18:46] cking: does this extend to the LVM'd SSDs? My 18.04 laptop here doesn't appear to have an IO scheduler enabled o.O [18:46] xnox: /etc/init.d/ondemand [18:47] teward, for a LVM'd SSD I think noop will be OK, for the next release, "none" will be the SSD multiqueue default [18:47] infinity, thanks! and totally still a thing.... [18:47] https://paste.ubuntu.com/p/BWDhJjXm5f/ [18:48] noop won't steal any overhead, deadline will eat more CPU than noop for sure [18:48] xnox: Did you just pastebin a file we all have on our systems? :) [18:48] infinity, yes =) [18:48] infinity, two files, to be precise =) [18:49] infinity, i've been working on a snap for half a day, i'm in a special state of mind at the moment =) [18:50] xnox, infinity, of course, most laptops will have the intel-pstate CPU freq driver, so I'm not sure how well that applies nowadays [18:51] i think it's powersave and performance for modern kernels [18:51] and the pstate driver, so that script needs some love [18:53] cking: erm, any chance 18.04.1 used 'none'? [18:53] because this new 18.04.1 instlal on this computer says 'none' [18:53] (for desktop not server) [18:53] https://paste.ubuntu.com/p/Nhk4jXDGzJ/ [18:53] teward, yeah, none really means none [18:54] ah, nice. [18:54] so no worries then [18:54] cking: I think the last time we visited all of that, pstate was still setting things on fire, and we forgot to circle back around... [18:54] we had some IO performance concerns on some VMs, though, hence the line of questions heh [18:54] yeah, modern kernels kinda do the defaults better [18:54] cking: That was, what, 6 years ago? :P [18:54] Maybe 4. [18:55] infinity, yeah, pstate is now fine and with thermald all that catch-fireness is a thing of a past unless one has a fan that is clogged with belly button fluff [18:56] infinity, the default of powersave is generally OK for most purposes unless one want's to crank up the CPU quickly and made it more toasty and compute friendly [18:56] *make it [18:56] doh, can't type [18:57] cking: Yeah, and I tihnk we once discussed if it was possible to detect if thermald was running before enabling pstate, and falling back to powersave if not. And also didn't follow up on that. [18:57] cking: I think maybe you added a kprintf to warn people to have the package installed, no idea if that's still a thing. But that's the last I remember discussing it. [18:57] infinity, i think that's now history, pstate = good + thermal = sweet [18:58] cking: Ahh, so pstate is now safe even without thermald? How's that work? Just more agressively powersavey if no thermald there to keep it in check? [18:58] infinity, pstate is just now mature, so it's all good IMHO for most users [18:59] but thermald is useful for users with systems with dodgy fans and lame thermal paste or poor thermal design [18:59] you mean like older laptops? :P [18:59] I'm not sure "more mature" is enough to make me feel better. Realtek ethernet drivers are very mature, and still complete garbage. But at least don't set your NIC on fire. [19:01] cking: "poor thermal design" probably describes half the laptops with pstate-capable CPUs. And it gets worse if they've been knocked about a bit and maybe cracked a more solid thermal adhesive solution. [19:01] infinity, well, it won't catch your CPU on fire, thermald will throttle and also the kernel can add in CPU clock throttling too, so all is quite solid now [19:01] cking: I want a default that's safe for those people, even if it means being suboptimal for folks with gaming laptops with 30 inch blowers. [19:02] infinity, pstate + thermald will be safe for users unless something is severely broken, in which case when the CPU gets to Tjmax it will shutdown automatically anyhow [19:03] cking: "it won't catch your CPU on fire, thermald will throttle", I'm asking about pstate *without* thermald. I think we'd established it was safe with. [19:03] But we still can't seem to guarantee it's actually there/. [19:03] infinity, that's true for any CPU scheduler, if the H/W is borked you can hit Tjmax, [19:03] cking: Sure, but pstate was known to be extra aggressive and trip faster, that's all. :P [19:04] infinity, and it's my understanding it's pretty well OK nowadays [19:04] cking: I still think maybe the best solution here is "if pstate available && thermald running; then pstate; else powersave; fi" [19:04] cking: Since we set this all in userspace anyway (barring a user doing something themselves on the commandline, which isn't my problem), that should be easy enough. [19:05] infinity, pstate will provide powersave and performance options, and we default to powersave, so it's all good [19:05] Oh, wait. governor != driver in this case, does it? [19:05] So, I might be powersave pstate? [19:05] Life is so confusing. [19:06] it's confusing, the other CPU freq scaling drivers may provide other governor options, so that makes it all fun [19:06] but as long as we're in powersave, I'm happy as it's a good default with or without pstate [19:06] Right, okay. [19:06] I'm pstate/powersave here. [19:06] Which sounds like a safe default. [19:06] So ignore the last 100 lines. [19:07] and thermald is just the final icing on the cake for users with bored H/W :-) [19:07] *borked [19:07] I guess I should see what scaling mess my new Ryzen laptop ends up with when I boot Linux on it later. [19:08] ... when the RAM gets here. [19:08] ... if the RAM gets here. [19:08] you got a shiny new laptop w/o any RAM? [19:08] cking: A lot cheaper to buy RAM third party than to buy 32G from Lenovo. [19:09] cking: So, it has the bare minimum 4G from Lenovo. But wasn't going to reinstall it until I'd popped in all the bits and screwed it back together. [19:09] very true. I buy reconditioned Lenovos and get a third party to shove in discounted quality RAM and SSD - makes it ultra competitive priced [19:10] cking: Yeahp, same with the SSD. I ordered it with the cheapest/crappest (7200 RPM 500G) they had. [19:10] Hilariously, those 500G spinny drives are actually really nice, and make good parts to throw in firewalls and such. [19:10] But yeah, not competitive with the 40mm NVMe and massive SATA SSD I got to replace it. :P [19:10] yeah, slower distributed backup devices [19:11] nice - no spin and multiqueue = speed [19:16] aww man he quit just before I got to the bit about 'reconditioned lenovos', I'm curious :) [19:17] sarnold: lol [19:18] teward: I've been thinking it might be nice to have a 'work laptop' and a 'play laptop'.. something cheap and cheerful .. [19:19] sarnold: i know where you can get 8 year old Latitude E5700s :P [19:19] if you want to talk about 'cheap' [19:19] :P [19:19] lol [19:20] too cheap too cheap [19:20] lenovo keyboard is the minimum :) [19:27] heh [19:41] sarnold: You're saying you want to buy my T450s after I finish migrating to my new A485? [19:42] sarnold: Or maybe my T420s? [19:42] Man, I have too many Thinkpads... [19:42] infinity: heh, yeah, that could probably work :) [19:43] The T450s is a beast. I'm trying to figure out how to either make it useful here, or sell it to someone who will appreciate it. === freyes_ is now known as freyes