=== DarkTrick_ is now known as DarkTrick
=== genii is now known as genii-core
cpaelzerhmm - is it a recent change that ppas are no more served from launchpad.net but from ppa.launchpadcontent.net ?06:51
cpaelzerSeems to have broken some of my automated tests, so I wonder about the timing and backgrounds if anyone knows more about it06:51
cpaelzerboth servers seem to be up still, wget from both serves the same, so maybe only apt or add-apt-repository changed to use the new URL by default now ...06:54
vorloncpaelzer: yes, in the past month; I know the Launchpad team included it in their internal weekly report, and it also required some changes to IIRC the core snap builds which I saw float by as MPs07:10
cpaelzerthanks vorlon07:13
cpaelzerthant confirms it isn't just me and my tests were quickly adapted and are fixed now07:13
schopinathos: I'm doing the python-debian merge, and have forwarded-ported your zstd patches. Given the comments on the Salsa MR, I figured you might be interested in these, since they keep the external tool approach :)10:50
schopinathos: https://salsa.debian.org/schopin/python-debian/-/tree/external-zstd10:50
cjwatsoncpaelzer: Out of interest, what did it break?  https://bugs.launchpad.net/launchpad/+bug/1473091 has the background11:17
ubottuLaunchpad bug 1473091 in Launchpad itself "default PPAs to HTTPS" [Low, Fix Released]11:17
cjwatsoncpaelzer: and https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1959015 for the add-apt-repository change11:18
ubottuLaunchpad bug 1959015 in software-properties (Ubuntu Jammy) "Switch to new HTTPS-capable domains for PPAs" [Medium, Fix Released]11:18
cpaelzerthanks for the background cjwatson11:31
cpaelzercjwatson: it did break tests that did use add-apt-repository - that started to fail since the URls were not in the no_proxy env and then got some ssl handshake issues11:32
cpaelzerit had a few different symptoms in different places, but adding launchpadcontent.net + api.launchpad.net to no_proxy resolved it all11:33
cjwatsoncpaelzer: right, fair enough11:35
cjwatsonslightly bumpy but it should be better in the long run11:35
cpaelzersince it wasn't change at jammy release day it should be fine after a short bumpy time11:35
cpaelzerI was told that this was in the launchpad weekly update (I have to admit I do not read that), maybe it would be time to announce that change a bit more11:36
cpaelzerto make it easier for others that might e.g. like me need to adapt proxy config11:36
cpaelzer"announce -> fix" is alway nicer than "fail -> debug - arrrrr -> fix" :-)11:37
athosschopin: thanks! still haven't figured out the merge myself :) => current dealing with how to handle large files12:04
schopinathos: fwiw I keep amending the linked branch because the CI seems particularly pedantic.12:05
=== genii-core is now known as genii
rbasakutkarsh2102: hi! Did I hear correctly that you were going to look at the ruby-mysql2 dep8 holdup on mysql-8.0?16:28
rbasakI'm concerned to get the dep8 rdeps fixed for mysql-8.0. I'm not sure what might be caused by the OpenSSL 3.0 transition, what might be caused by a new upstream release, and now we have maybe some issues with language connectors that might be being affected by potential changes upstream, etc. So I don't have much confidence that there isn't a more serious blocker hiding somewhere that we don't know16:29
rbasakabout yet.16:30
utkarsh2102rbasak: hey, yes, I'll take a look. I'll sync up with you or lenavoytek before diving into it.16:36
blucajuliank: it seems some jobs on https://autopkgtest.ubuntu.com/running#pkg-systemd-upstream are running multiple times16:47
blucaI was watching the amd64 job for PR id 22458 and it completed successfully, went back to queued, and started over16:48
blucathere were no pushes on the PR16:48
juliankbluca: it might have failed16:48
blucait ran for many hours and I caught glimpses from the log snippet16:48
juliankbluca: was there a push somehow that it passed?16:48
blucait completed at least until the second to last job16:48
bluca/job/autopkgtest suite/16:49
juliankso it might have rebooted and failed to come up again16:49
blucano push on the PR16:49
ubottuPull 22458 in systemd/systemd "some safety tweaks to conf-parser.[ch]" [Open]16:49
juliankbluca: this is failing16:50
juliankbluca: last run failed 35 mins ago16:51
juliankwell timing is wrong16:52
blucais the failed log accessible?16:52
blucaalso any reason it's just rerunning instead of reporting the failure?16:52
juliankif the machine fails to come back up again after a reboot it's a testbed failure that will be retried 3 times or so16:52
juliankyou'll have to wait until it failed often enough or passed16:53
juliankthere is no useful log16:53
juliankIt's also not just systemd upstream jobs, machines just don't always come back up in general16:54
juliankor lose network connectivity16:54
juliankabout 25% of the tests on amd64 are such abnormal failures16:54
blucauhm but why is the machine rebooting before all the autopkgtest suites are done?16:54
juliankbecause it's rebooting between tests16:55
blucais that expected?16:55
juliankor like between testbed setup and tests16:55
jawn-smithvorlon: I know you love removing packages16:55
blucaok, got it, thanks16:55
jawn-smithLP: #196043316:55
ubottuLaunchpad bug 1960433 in aegisub (Ubuntu) "Please remove src:aegisub from jammy" [Undecided, New] https://launchpad.net/bugs/196043316:55
juliankI have no idea how to debug this further16:55
* vorlon oils the chainsaw16:55
juliankI'd have to patch autopkgtest to keep one such failing machine around I suppose16:56
juliankI've tried to reproduce the issue manually multiple times, but those always work16:56
juliankmaybe I should create a vm and do a reboot loop16:57
vorlonjawn-smith: first I need to know if this is parsed as aegi-sub or aegis-u-b16:59
vorlonjawn-smith: for reference, the existence of Debian bug #997098 is sufficient for me, no need to file a separate bug in Ubuntu if there's already a release-critical Debian bug for the issue17:01
ubottuDebian bug 997098 in src:aegisub "aegisub: FTBFS: make[2]: *** No rule to make target '/<<PKGBUILDDIR>>/Makefile.inc'.  Stop." [Serious, Open] https://bugs.debian.org/99709817:01
juliankvorlon: failure count today of amd64 hosts: https://paste.ubuntu.com/p/F9D7xpvnqJ/17:08
juliankI'd like to get an instance on elektra really17:08
juliankIS did a soft restart of all OVS but it did not help17:09
juliankvorlon: OK I see in the failing logs that systemd is starting a job called "/usr/bin/sh -c sleep 3; reboot"17:19
juliankvorlon: I wonder where that is from17:19
juliankvorlon: I think if the machine reboots itself vs the outside, autopkgtest gets confused as it still expects it to be up17:19
juliankBecause the machines take ages to boot due to load right now17:22
juliankStartup finished in 7.265s (kernel) + 15.902s (userspace) = 23.167s17:24
jawn-smithvorlon: it's a subtitles package so I'm going with aegi-sub. Thanks for the tip about the Debian bug17:27
juliankvorlon: So I added -o ConnectionAttempts=20 to the ssh command autopkgtest auxverb uses which will make it try to connect 20 times with 1s timeouts, maybe that helps17:35
juliankI guess I should hack that into existing running processes17:36
juliankwe now have debugging enabled for half the jobs18:07
juliankvorlon: I locally hacked in NOVA_REBOOT=1 in ssh-setup/nova and will see if that helps. It seemingly helped a long long time ago in bos0118:36
juliank(pitti added --nova-reboot to the worker.conf; but we don't really have the luxury to reload workers right now)18:36
bdmurrayI'm trying the new aiocoap w/ python3.10 defaults18:41
bdmurrayhrm, I might have jumped the gun there18:44
jawn-smithseb128: can you have a look at LP: #1960458 when you get a chance? Your name is on the patch that is causing the issue23:46
ubottuLaunchpad bug 1960458 in at-spi2-core (Ubuntu) "patch git_socket_dir.patch causing FTBFS in gspell" [Undecided, New] https://launchpad.net/bugs/196045823:46
jawn-smithor, at least the changelog entry for that patch23:46

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!