[00:26] <jbicha> jawn-smith: I think I fixed that issue a different way. I am uploading to Debian and it will autosync to Ubuntu
[00:42] <jawn-smith> jbicha: awesome, thanks!
[07:59] <cpaelzer> athos: I updated https://bugs.launchpad.net/ubuntu/+source/amavisd-new/+bug/1895799 as discussed
[08:00] <cpaelzer> athos: I'll try to remind foundations on monday about it if they did not pick it up already by then
[12:04] <athos> thanks, cpaelzer :)
[12:04] <ahasenack> morning
[12:40] <Fantu> hi, memtest86+ 5.31b+dfsg-4 that solves many issues and inlcudes also ubuntu changes of latest years was uploaded to debian unstable 4 days ago but I still not saw it in next ubuntu (Jammy) as proposed, is there something that block autosync from debian? thanks for any reply
[13:06] <xypron> sil2100: for new package cd-boot-images-riscv64 we will need a repository https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/cd-boot-images-riscv64. Could you, please, create a repo for which I can create my merge request.
[13:15] <jbicha> Fantu: packages don't autosync if they have Ubuntu-specific changes (the version number has the word 'ubuntu' in it) so someone will need to manually merge that update https://launchpad.net/ubuntu/+source/memtest86+
[13:17] <ahasenack> xypron: is that a new src package?
[13:17] <Fantu> jbicha thanks for reply, can anyone check and force sync please?
[13:18] <schopin> ginggs: ping regarding the memtest thing?
[13:18] <schopin> (see just above)
[13:18] <xypron> ahasenack: yes LP: #1960216
[13:19] <ahasenack> I can import it into git-ubuntu once there is a publication in LP
[13:20] <xypron> ahasenack: should I push to git+ssh://xypron@git.launchpad.net/~xypron/ubuntu/+source/cd-boot-images-riscv64 ?
[13:21] <ahasenack> whatever you feel more comfortable with, unless your team has a policy and you need it in some specific place. rbasak, I don't think the very first import of a package can account for rich history, can it?
[13:29] <rbasak> ahasenack: I think that might be a currently unsupported edge case. But you're welcome to try if the rich history exists. Worst case: it doesn't get adopted.
[14:37] <rbasak> "This team is responsible for administrative and maintenance tasks for the Ubuntu package archive, including processing of new packages, handling requests for package syncs from external repositories, migration of packages between components, and other administrative matters."
[14:37] <rbasak> "handling requests for package syncs from external repositories"
[14:37] <rbasak> That's not a thing any more, right?
[14:48] <Fantu> rbasak thanks for the message, about handling memtest86+ sync from debian is there something that I should do? (like open a request somewhere) or I only need wait that someone of the team take care of it?
[14:49] <rbasak> Sorry, that wasn't intended for you. I was asking about the description of the ~ubuntu-archive team in Launchpad.
[14:49] <rbasak> There is a process to request a sync
[14:50] <rbasak> But I thought maybe the people discussing it above would be able to just do it, without requiring that process.
[14:50] <rbasak> Maybe hang around to see?
[14:50] <rbasak> If not, and you'd like to submit to the process to make sure it's not forgotten about, that's fine too.
[14:51] <rbasak> https://wiki.ubuntu.com/SyncRequestProcess#For_people_requiring_sponsorship
[14:51] <rbasak> Basically, there should be a bug in Launchpad against the package with the details, and ~ubuntu-sponsors should be subscribed.
[14:52] <rbasak> But please keep poking here either way to make sure it gets done
[15:07] <cjwatson> rbasak: Yeah, I don't think that's been a thing for a loooong time.  I've removed that clause
[15:17] <Fantu> rbasak thanks, done https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/1960521
[15:39] <rbasak> schopin, ginggs: ^
[16:07] <ahasenack> mirespace: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/arm64/d/dgit/20220210_145249_430b1@/log.gz and https://autopkgtest.ubuntu.com/results/autopkgtest-bionic/bionic/ppc64el/l/lxc/20220210_122101_7c5b0@/log.gz need an explanation or fix about why they are failing
[16:08] <ahasenack> the rsync sru bug should also have two comments at the end with links to the excuses page with these failures
[16:28] <mirespace> the skew-clone test for digit in focal stills fails fo '
[16:28] <mirespace> curl: (22) The requested URL returned error: 400 Bad request
[16:28] <mirespace> dgit: failed command: curl --proto-redir '-all,http,https' -L -f -o ./example_1.0-1.debian.tar.xz -- http://127.0.0.1:43933//pool/main/example_1.0-1.debian.tar.xz
[16:28] <mirespace> local file is not found
[17:13] <ahasenack> that's a localhost url
[17:13] <ahasenack> which the test itself presumably sets up
[17:24] <mirespace> yes
[18:03] <mmikowski> @bdmurray @vorlon @schopin @Juliank I saw some posts on /boot partition discussions.
[18:04] <bdmurray> mmikowski: Starting a discussion on the ubuntu-devel mailing list would be the best way for all of us to be able to discuss this.
[18:05] <juliank> yes, please do not discuss this on irc
[18:06] <mmikowski> yet 4 people just did discuss this on IRC.
[18:06] <mmikowski> over numerous posts.
[18:07] <mmikowski> I'm happy to move to a mailing list post, but just pointing out the obvious I guess.
[18:08] <bdmurray> That was during a regular scheduled meeting of the Foundations team a team which all four of those people are members.
[18:08] <juliank> moving the discussion to mail was the outcome of the discussion
[18:08] <juliank> also you are not on that channel, so how did you see it in the first place?
[18:08] <mmikowski> bdmurray: ok, thank you for the clarification.
[18:09] <mmikowski> The conversation was forwarded to me. I was under the impression that was IRC conversation, not a meeting.
[18:09] <mmikowski> Sorry for the misunderstanding.
[18:09] <juliank> the meeting took place on #ubuntu-meeting
[18:10] <mmikowski> The link was sent to me.  Of course, this is a public transcript.
[18:11] <mmikowski> In any event, I'd be happy to post the responses to the bug which seems more appropriate as it will be proximate to the issue at hand.
[18:15] <bdmurray> mmikowski: Please start a discussion on the mailing list so we can have reply with context. This is much harder to do in a Launchpad bug.
[18:15] <bdmurray> s/reply/replies/
[18:17] <mmikowski> bdmurray: ok, let me review my mailing lists and report. However, I can respond to all these issues on 1959971
[18:18] <mmikowski> bdmurray: thanks
[20:40] <bdmurray> seb128: I see bug 1959362 is assigned to you, are you working on it?
[20:43] <seb128> bdmurray, no yet, comment #5 suggested it might be already fixed though
[21:08] <mwhudson> "test_many_processes (test.test_multiprocessing_forkserver.WithProcessesTestProcess) ... Killed" oh come on
[21:08] <mwhudson> can upstreams write test cases that don't kill the infrastructure please
[21:11] <mwhudson> vorlon: this is python3.9/ppc64el you talked about in the meeting btw
[21:11] <vorlon> mwhudson: I added it to big_packages, did it get retried on larger instance yet?
[21:11] <vorlon> it did
[21:12] <vorlon> it passed
[21:12] <mwhudson> ah yes
[21:12] <mwhudson> hooray latency
[21:12] <mwhudson> now does anyone know what pgloader is
[21:13] <mwhudson> because https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/amd64/p/pgloader/20220205_231601_7da15@/log.gz sure looks like an openssl problem and not a glibc problem
[21:13] <vorlon> yeah that was mentioned in backchannel during the meeting
[21:13] <vorlon> this of course means there are no logs so I don't remember who called dibs - possibly schopin but I'm not sure
[21:16] <mwhudson> ok
[22:52] <mwhudson> what is going on here
[22:52] <mwhudson> https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/i386/d/dbus-broker/20220204_132422_b139c@/log.gz
[22:52] <mwhudson> Broken libexpat1-dev:i386 Depends on libc6-dev:i386 < 2.35-0ubuntu1 @ii R >
[22:52] <mwhudson> i don't see that constraint anywhere
[22:53] <mwhudson> oh it's cross-toolchain-base fun and games i guess