[10:00] juliank, Laney, do you know what's going on with autopkgtests/arm64? [10:05] can you be more specific? [10:07] Laney, https://autopkgtest.ubuntu.com/running has a focal/arm64 queue of 465 ... is that normal business, just busy and need time [10:07] or do we have a capacity problem? [10:07] both of those things are true at the same time [10:07] k, let me rephrase [10:07] it's normal, arm64 is always the slowest arch [10:07] and more faster hardware would help with that [10:07] do we just wait or is there a problem that needs to be handled (maybe with #is)? [10:07] but it looks to be proceeding [10:08] k, so normal business, we just DoSed the infra by number of uploads? [10:09] I was wondering if there was a problem,it has been a long time since we had > 1 day for items to get picked so it looked like maybe there was some problem [10:09] if not all good, I'm just going to wait :) [10:10] we need moar arms [10:10] there was a glibc upload and some other big ones [10:14] seb128: cracklib, yes use the python3 path [10:14] doko, thx [10:15] xml2-config: I tried to restore the original behavior, however Debian's plan is not to ship that at all, that will be the long term solution [10:15] use pkg-config instead [10:15] doko, right, I saw your follow up upload you just did, sounds it should fix the regression, thx === Wryhder is now known as Lucas_Gray [10:28] rbasak: https://launchpadlibrarian.net/465508087/buildlog_ubuntu-focal-amd64.python-sniffio_1.0.0-1build1_BUILDING.txt.gz could you fix that and maybe update to the new upstream in debian? [10:59] xnox: https://launchpadlibrarian.net/465504895/buildlog_ubuntu-focal-amd64.m2crypto_0.31.0-9build1_BUILDING.txt.gz fails with a SSL error, could you have a look? [11:04] doko: it's trying to test that tls1 connection is refused by configuring server without tls1 => that won't work any more, as tls1 is disabled on the client too. It already skips the test in fips mode, and it should skip it forever now. Because just like fips, we don't allow tls1 anymore. [11:31] Hi, the latest cups sync from debian in focal broke cups, now e.g. `cupsctl` sprouts HTML instead of just var=value output; and any settings change writes html to /etc/cups/cupsd.conf, completely breaking cups [11:31] Would I file a bug in debian for this, or in ubuntu? [11:31] tkamppeter, ^ [11:32] Working: 2.3.1-4, broken: 2.3.1-7 [11:32] alkisg, seems worth reporting to Debian in any case [11:32] Thank you seb128; I'll stick around in case launchpad is also desired [11:34] alkisg, thx [11:38] interesting [11:38] alkisg: I've got -4 still on two systems and I see that on one of them but not the other [11:38] * alkisg updates his bullseye VM to test/report there... [11:39] Laney: hrm [11:39] https://paste.ubuntu.com/p/YdhZtpRYMk/ [11:39] Laney: also keep a backup of /etc/cups/cupsd.conf, as e.g. `cupsctl _share_printers=1` will overwrite it with broken html [11:41] good hint [11:42] etckeeper ftw [11:49] Meh, it doesn't happen on debian with 2.3.1-7 [11:49] It might be an upgrade path, missing or additional packages etc [11:54] is there a way to get https://bugs.launchpad.net/ubuntu/+source/libbinio/+bug/1839038 fixed for 20.04 LTS? [11:54] Launchpad bug 1839038 in ocp (Ubuntu) "adplug+libbinio+memory mapped = crash on some files" [Undecided,Confirmed] [11:54] i actually have a fix (for libbinio+ocp) but there's no time left for it happen before freeze [11:55] seb128, thanks for telling me. Seems that some Debian change has totally broken CUPS, as the upstream versions are the same. [11:56] and does canonical want to have fwupd.org thing in 20.04 LTS? [11:57] seb128, so a report to Debian would make sense here. [12:25] tarzeau: fwupd.org => do you mean fwupdates which are integrated for years now into software-updater and are applied on all UEFI machines for which there are firmware updates already? (e.g. Dell laptops) [12:28] i have no idea of it, i just maintain flashrom (and coreboot) [12:28] but someone maintaining fw* asked me to build libflashrom1 + libflashrom-dev (which i do with flashrom 1.2-2 in new queue debian) [12:44] tkamppeter: I would report it to debian, but I can't reproduce it there; it only happens in my focal VM, not in my bullseye VM [12:45] The cups-filters package version is different though [12:45] Dunno if that would justify the difference [12:46] alkisg, cups-filters should not influence the output of cupsctl, as cupsctl only shows some common configuration options of the cups daemon, this should not change by the presence of certain filters or cups-browsed. [12:46] I get the messy cupsctl output with cups-browsed not running. [12:46] tkamppeter: then the versions are the same; yet I only see the issue in ubuntu :/ [12:47] Debian is gnome, Ubuntu is mate, but I don't think that makes a difference either [12:47] So perhaps there are some environment variables set in Ubuntu which are not set in Debian, and here we perhaps had a change in recent days. [12:47] tkamppeter: and I have two Ubuntu machines: same cups versions, one with the issue, one without [12:48] Laney: similar uptimes? Or maybe the one wasn't rebooted for days/updates? [12:48] so I suppose something that happened on one of them made the bug appear ... but what? [12:48] 5 days on the affected machine, 12 the other [12:48] Laney, and the Ubuntu environments, how do they differ? Different releases? [12:48] no, they are both focal [12:49] I mean I'm sure there are differences in what's happened to each of them, but that's figuring out the bug isn't it :-) [12:49] Laney: I think it doesn't happen if I `su`... can you verify that? [12:49] Laney, could you get a full list of the env variables from the terminals out of which cupsctl got started? [12:49] I used su - on debian, and just cupsctl on ubuntu [12:50] alkisg: yes, can confirm that [12:50] tkamppeter: It happens even when I run "env -i /usr/sbin/cupsctl" [12:50] So does it mean that from root and normal user only one environment shows the problem? [12:51] https://paste.ubuntu.com/p/cHTPG8tpSD/ [12:51] For me as root the output is OK and as user it is messy. [12:51] In Debian, as the user, /usr/sbin/cupsctl => doesn't produce the issue [12:51] So it's not a matter of uid, but of environment variables or something, testing more... [12:51] messy -> you see the bug? [12:54] Laney, yes. [12:56] Independent whether with or without "env -i" as user it is broken and as root (with sudo) it is correct. [12:56] whoops, I ran cupsctl --debug-logging and it made the daemon exit, and now cupsctl just prints "Bad file descriptor" [12:56] tkamppeter: right, good, then you see the same as me [12:56] My user account is in the "lpadmin" group, by the way. [12:57] ah, I guess doing that corrupted my cupsd.conf [12:59] and restoring that has made the bug stop happening, so be careful when restarting things [13:03] tkamppeter, Laney, setting WebInterface No in cupsd.conf and restarting cups works around the issue [13:04] Somehow, the web server is contacted by cupsctl [13:07] I am looking through the source of cupsctl. [13:08] cupsctl calls a linbrary function cupsAdminGetServerSettings which returns an aplphabetically sorted list of key-value pairs. Somehow, when runniung as user, there get two garbage pairs, both with grabage as key and empty value into the list. [13:09] The first one starts with & and therefore gets to the beginning, and the second one starts with a letter and it falls to the end. [13:10] The five main options start with _ and in the messy case other options which start with a letter do not appear. [13:15] cupsctl reads cupsd.conf, but not directly as a file as it is only readable for root. It uses a function to poll the config file from the CUPS daemon. [13:16] That all happens in the cupsAdminGetServerSettings() in cups/adminutil.c of the CUPS library. [13:19] doko: thank you for the ping. I'm hoping to catch the trio stack up in Debian before Monday. In personal time - I'm off until then. [13:21] Following cupsd's opinion, my cupsd.conf lokks like this: https://pastebin.ubuntu.com/p/gpyrnBTrP6/ [13:22] This article mentions environment variables you can set to to tune the kernel build process: https://help.ubuntu.com/community/Kernel/Compile#Build_Method_A:_Build_the_kernel_.28when_source_is_from_git_repository.2C_or_from_apt-get_source.29 [13:22] Is there an environment variable I can set to customize the kernel version string? [13:22] But if I trust my own eyes, my cupsd.conf looks like this: https://pastebin.ubuntu.com/p/VctGgxP5BP/ [13:23] alkisg, Laney, ^^ [13:33] Laney, alkisg, sorry, CUPS' interpretation of my cupsd.conf is https://pastebin.ubuntu.com/p/nCpSdxntBm/ [13:33] For me it loks like what the web interface displays if you select do modify the server settings. [13:45] Laney, alkisg, I am already coming closer, on a Focal machine and on a Bionic machine, take a browser and go to http://localhost:631/admin/conf/cupsd.conf When asked for user name enter your user name and password. [13:45] Bionic shows cupsd.conf as expected, Focal shows the min page for we admin [13:45] Needs WebInterface=Yes, naturally. [14:12] tkamppeter: indeed; yet, on bullseye, it shows the admin interface, but the problem doesn't appear there [14:14] Btw on bionic I'm not getting a security warning for the localhost:631 certificate, while I am on focal; dunno if it's at all related [14:15] Oh never mind that, my mistake, I had already accepted the certificate on bionic [14:43] OverflowError: timestamp out of range for platform time_t [14:43] is it already 2038? [15:03] tkamppeter: Don't think I can help much any more since it stopped happening after the file got corrupted [15:04] unless we figure out how to trigger it again [15:23] pipewire 0.3 released : https://gitlab.freedesktop.org/pipewire/pipewire my ppa build: https://launchpad.net/~jan-koester/+archive/ubuntu/pipewiremaster [15:47] doko, jbicha, could you update Avahi to the new upstream version 0.8 for Focal? [15:48] tkamppeter: no, please go ahead yourself [15:51] doko, I cannot upload by myself, I am not core-dev. [15:51] doko, therefore I am asking. [15:53] tkamppeter: prepare the package in a PPA, and then ask for a sponsor [16:34] coreycb, jamespage: python-vitrageclient probably needs a MIR (pulled in by heat), and vitrage ftbfs in focal [17:21] doko: ok thanks I'll take care of those [17:22] Laney, alkisg, I have found a fix for CUPS. Mike Sweet had messed it up between 2.3.0 and 2.3.1. [17:26] nice one [17:49] Laney, alkisg: https://github.com/apple/cups/issues/5744 [17:52] Patch attached. [18:10] tkamppeter: thanks, reading... [19:45] Can someone confirm for me that Focal will stick with Python 3.7, not move to 3.8? [19:46] it's 3.8 only [19:47] Oh wow, I swear I looked a week or two ago, did that change recently? [19:47] Maybe I was looking at eoan [19:48] 3.8 by default migrated to focal a weeek ago [19:48] it was atleast partially announced a month ago or so https://lists.ubuntu.com/archives/ubuntu-devel/2020-January/040882.html [19:50] and the transition looks like it's pretty far along, 96% on https://people.canonical.com/~ubuntu-archive/transitions/ [19:52] sarnold, does that represent the transition from 3.7 to 3.8 though, or the removal of python? [19:52] I thought it was the latter [19:54] kyrofa: I'm no expert on the syntax at the top of the page but I *think* the 3.8 transition is about dropping dependencies on python 3.7 things [20:01] yes [20:01] the previous one was switching defauts [20:04] Ah okay [20:04] Thank you both! Very pleased to see 3.8 come in [21:44] I'm SSH'd into a desktop and I'm trying to build and, crucially, sign a package using a GPG key with a passphrase. I'm not being prompted in the console for my passphrase, instead seeing a hang (presumably because a graphical prompt is configured). How can I get GPG to prompt me in the terminal? [21:47] Odd_Bloke, have you tried ssh -X to pass the X11 forwarding? [21:47] powersj: I have. [21:47] unset SSH_AUTH_SOCK [21:48] actually, you probably need to get it to use the console pin entry [21:52] I tend to just unset DISPLAY. :P [21:52] tumbleweed: Thanks! That hint got me to https://superuser.com/questions/520980/how-to-force-gpg-to-use-console-mode-pinentry-to-prompt-for-passwords which has worked.