liushuyuafk for a while00:04
=== bdmurray changed the topic of #ubuntu-devel to: Archive: Post-Beta Freeze | Devel of Ubuntu (not support) | packages with removed amd64 binaries that need resolving: https://pad.riseup.net/p/migrate-list-amd64 | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: N/A
vpa1977cgmb: it seems that glibc bug is fixed, so maybe just retrying build should help00:52
cgmbvpa1977: my understanding is that upstream basically responded wont-fix.00:53
cgmbIt is definitely still broken.00:54
cgmbI have a patch for glibc, but I don't expect it to be merged and uploaded in time for noble.00:54
vpa1977cgmb: would it be possible to put some comment in the merge proposal regarding this?00:55
cgmbvpa1977: done01:00
vpa1977cgmb: I've added it to the commit for the next person01:18
vorloneeew kdiagram ftbfs on riscv64 because building with nocheck changes the ABI of the library06:05
adrienI'm looking at some convenience plumbing and retry-autopkgtest-regressions documents a way to interact with autopkgtest.u.c; are there other places where that's documented/implemented/whatever?08:42
adrienbecause I *really* want to trigger PPA tests after a PPA build is done and published08:42
sudipadrien: https://wiki.ubuntu.com/ProposedMigration#autopkgtests has a section "Testing against a PPA"08:51
adriensudip: yes, and actually ppa-dev-tools can generate the URLs for that in addition to checking the results but AFAIK it cannot trigger tests at the moment (I have to say the CLI UI for that is maybe not trivial, especially when queues are heavily loaded)08:54
adrienwhat's missing for me is the automation between the build and test steps08:54
vpa1977sudip: Hi! =) would it be possible to forward fix for https://bugs.launchpad.net/ubuntu/+source/hxtools/+bug/2060825 to Debian?09:14
-ubottu:#ubuntu-devel- Launchpad bug 2060825 in hxtools (Ubuntu) "hxtools ftbfs in Noble" [Undecided, Confirmed]09:14
sudipvpa1977: In Debian libHX is waiting for a sponsor to upload, hxtools wont be ftbfs after that09:15
-ubottu:#ubuntu-devel- Debian bug 1064734 in src:libhx "Please include upstream patch" [Serious, Open]09:15
vpa1977sudip: ah, sorry, I linked wrong one. You've also fixed the missing dependency there09:15
-ubottu:#ubuntu-devel- Launchpad bug 2060728 in hxtools (Ubuntu) "gpsh fails to run in Noble" [Undecided, New]09:17
sudipvpa1977: sure, but its not an issue in Debian. as libfile-find-rule-perl is a dependency of usrmerge so its already there and the issue is not seen in Debian09:18
vpa1977sudip: ah I see, thank you!!!!!!!09:19
vpa1977its just sometimes they accept fixes that they do not really need =)09:20
sudipI will open a bug as soon as I am out of this meeting in my $dayjob09:23
sudipvpa1977: done09:47
-ubottu:#ubuntu-devel- Debian bug 1068855 in hxtools "hxtools: gpsh fails to run" [Normal, Open]09:47
vpa1977sudip: Thank you!!!!!!!09:47
sudipI am seeing lots of rust packages failing to install in Noble10:32
=== guiverc2 is now known as guvierc
jbichasudip: could you give an example? I know that the Rust GNOME stack is incomplete but I'm working on it13:13
sudipjbicha: librust-gsk4-dev13:17
sudipthere are many more :)13:19
jbichasudip: that one is part of the Rust GNOME stack; probably 50+ source packages13:26
sudipohh.. ok.. I will check my list again13:30
sudipso I think only 3 in my list are non Rust GNOME stack, but thats a guess from the failed dependency name13:38
sudiplike librust-ripasso-dev13:39
jbichasudip: ok, I'm syncing rust-ripasso to probably fix that issue13:43
jbichahopefully that will allow rust-sequoia/capnp* to migrate13:44
sudipI think remaining all in my list is from rust GNOME13:47
jbichaall of those except for rust-pleaser are also broken in Debian13:49
jbichahttps://ubuntu-archive-team.ubuntu.com/transitions/html/rust.html and https://release.debian.org/transitions/html/rust.html can be helpful13:50
jbicharust-pleaser has no rdeps so may not be worth much effort right now. It needs to be tweaked since Ubuntu has done the rust-nix 0.27 transition but Debian hasn't yet13:51
* sudip does not understand the rust ecosystem13:57
jbichathe Debian Rust packaging is "interesting"14:49
sudipyeah, I wanted to take https://bugs.debian.org/1064957 but after reading about Debian Rust packaging I discarded that idea15:04
-ubottu:#ubuntu-devel- Debian bug 1064957 in wnpp "RFP: bpftop -- dynamic real-time view of running eBPF programs" [Wishlist, Open]15:04
=== cpaelzer_ is now known as cpaelzer
akarlsonCan anyone please change the status of LP: #2060692 to "In Progress" and mark it as affecting Noble?16:27
-ubottu:#ubuntu-devel- Launchpad bug 2060692 in cups (Ubuntu) "cupsd 2.4.7-1.2ubuntu5 on noble crashes due to recently backported commits from 2.4.x git" [Undecided, Fix Committed] https://launchpad.net/bugs/206069216:27
ahasenack@pilot in16:41
=== ChanServ changed the topic of #ubuntu-devel to: Archive: Post-Beta Freeze | Devel of Ubuntu (not support) | packages with removed amd64 binaries that need resolving: https://pad.riseup.net/p/migrate-list-amd64 | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: ahasenack
vorlonliushuyu: hi, were you looking at magics++/odc?16:59
vorlonliushuyu: I don't know if the comment on https://pad.riseup.net/p/migrate-list-amd64 for magics++ is yours, it says "incorrect build with wrong version of odc" but the blocker - for 2 weeks, so before that pad existed - is build failures on !amd6417:01
bdrungshould we remove the packages from https://pad.riseup.net/p/migrate-list-amd64 once they migrated?17:07
javaJakeThere's a Launchpad bug with a patch ready to go, but it's for a package in universe. Are community members able to volunteer to push a fix through?17:10
liushuyuvorlon: Yes, I believe you mentioned this was an issue with dh-fortran-mod + patchelf17:11
ahasenackjavaJake: can you upload/sponsor? If not, pass me the link and I can take a look, I'm on patch pilot this afternoon17:13
javaJakeahasenack: I've never participated in this process before, so if it's a privileged thing I probably can't. The bug is https://bugs.launchpad.net/ubuntu/+source/crun/+bug/205296117:14
-ubottu:#ubuntu-devel- Launchpad bug 2052961 in linux-meta-hwe-6.5 (Ubuntu) "Error: OCI runtime error: crun: chmod <path>: Operation not supported" [Undecided, Confirmed]17:14
ahasenackthat rings a bell17:15
ahasenackjavaJake: is that the same as https://bugs.launchpad.net/cloud-images/+bug/2056442 ?17:15
-ubottu:#ubuntu-devel- Launchpad bug 2056442 in crun (Ubuntu Mantic) "Podman (crun) regression in Ubuntu 22.04: OCI runtime error: chmod `run/shm`: Operation not supported" [Undecided, New]17:15
ahasenackthe latter has a crun package in proposed for jammy already, but missing a fix in mantic17:15
liushuyuvorlon: also, https://bugs.launchpad.net/ubuntu/+source/rustc/+bug/205298517:15
-ubottu:#ubuntu-devel- Launchpad bug 2052985 in rustc (Ubuntu) "[FFe] Upgrade Rust to 1.76.0" [Medium, Incomplete]17:16
javaJakeahasenack: that's the one. Mine was first though ;)17:16
ahasenackjavaJake: I'll mark it as a duplicate, as the other one (the one I linked) is far ahead in the update process17:17
javaJakeYea that makes sense. :) And it looks like the resolution for 23.10 is to just wait for 24.04 and upgrade.17:18
ahasenackyeah, I'm not super happy with that, I don't like to skip releases just because they are not LTSs17:18
liushuyutaking ucspi-tcp17:19
ahasenackjavaJake: would you be willing to prepare a fix for mantic?17:19
javaJakeahasenack: I would be willing to give it a try. I have done a lot of patch submissions to Gentoo but never to Ubuntu. I'll look around for packaging documentation.17:20
ahasenackjavaJake: this is how it was fixed in jammy: https://git.launchpad.net/ubuntu/+source/crun/commit/?id=4104b1eb0fb1f5d258b54785786d7034f3076b4417:21
-ubottu:#ubuntu-devel- Commit 4104b1e in ubuntu/+source/crun "0.17+dfsg-1.1ubuntu0.1 (patches unapplied) import/0.17+dfsg-1.1ubuntu0.1 ubuntu/jammy-proposed ubuntu/jammy-devel"17:21
ahasenackunfortunately all is squashed as a single commit17:21
ahasenackjavaJake: the key things are: d/changelog update with versiom bump, d/p/<actual-patch>, and d/p/series listing that patch17:21
javaJakeahasenack: got it17:22
ahasenackjavaJake: for mantic, you can start here: https://code.launchpad.net/~git-ubuntu-import/ubuntu/+source/crun/+git/crun/+ref/ubuntu/mantic-devel17:23
ahasenack"ubuntu/mantic-devel" is the tip/main/master of the package in ubuntu mantic17:23
ahasenackthen create a branch off of that with your fix (name it appropriately), and start committing17:23
ahasenackif you rather just provide the patch, with no ubuntu packaging, that also works17:24
ahasenackbut if you are familiar with git, I think it shouldn't be difficult to work with that repository17:24
liushuyutaking xbill17:25
javaJakeahasenack: I am generally confident in working with code, but the nitty-gritty of each community's process and tooling is what I need help with.17:27
ahasenackso if you want to get to know the nitty-gritty of ubuntu, or just provide the patch, both work, and I can help (in today's shift) with both17:27
javaJakeahasenack: sounds good. I'm getting a 23.10 install I can mess with and got the git repo cloned.17:47
ahasenackjavaJake: if I can give you a tip, I don't know what's your host OS17:48
javaJakeAh, it's unfortunately Windows 11 Pro atm :) but I have Hyper-V running a new install.17:49
ahasenackyou can easily bring up a mantic vm17:49
javaJakePerhaps WSL2 would've worked but I didn't want to add WSL2 variables to the mix.17:49
ahasenackwell, there I cannot help (bringing up a mantic vm)17:49
ahasenackthis test needs a vm17:49
ahasenackas you need to run the ubuntu kernel17:49
javaJakeYea, that's what I figured.17:49
ahasenackin ubuntu with lxd installed if would have been "lxc launch ubuntu-daily:mantic my-mantic-vm --vm"17:50
javaJakeAhhh, I didn't realize lxd could run whole VMs17:51
ahasenackyep, it can17:51
=== pushkarnk1 is now known as pushkarnk
javaJakeahasenack: is there a page similar to this that has content I can reference? https://canonical-ubuntu-packaging-guide.readthedocs-hosted.com/en/latest/tutorial/getting-set-up/18:05
javaJakeThis entire site appears to be heavily WIP18:05
vorlonliushuyu: yes, but someone needs to do the work of tracing the deps and requesting removal of the binaries18:06
vorlonliushuyu: I'll have a look at the rustc FFe later today18:07
ahasenackjavaJake: there is this which the ubuntu server team wrote: https://github.com/canonical/ubuntu-maintainers-handbook?tab=readme-ov-file18:07
ahasenackit might be way more detailed than what you want18:07
javaJakeI can pick through it! Thanks! Debian packaging has been a black box for too long. It's time I learned. :)18:07
ahasenackyou are welcome :)18:08
javaJakeOh my gosh! Ubuntu uses quilt? That's awesome. I love quilt.18:10
ahasenackdebian packaging can use quilt, yes (most do)18:10
javaJakeThis repo recommends an lxc to build a package. I'd like to build the package as-is just to confirm I can. Is that how you'd recommend?18:17
ahasenackwell, inside a lxd container (or vm, or chroot), you can make any changes you want without fearing breaking your host system18:17
ahasenackor polluting it18:17
ahasenackbecause to buildt the package, you will have to install build dependencies18:17
ahasenackif you do that on your host, well, you will be installing packages you might not need anymore after this build18:18
ahasenackusing a clean lxd (or vm, or chroot, ...) is also closer to what will be used in the real builders later on18:18
ahasenackthey start clean, and install the exact build dependencies that are declared18:18
ahasenackif you build on your host, you might just happen to have a build-dep already installed, and the build works then without you having to declare it. Just to later on find out it's missing, when the official builders get your package18:19
javaJakeThat last bit is what gives me nightmares18:19
ahasenackso yeah, in general, get a vm/container/chroot to test-build the packages18:19
ahasenacksince you will want to test this in a mantic vm anyway, I would suggest to use that same vm for the building18:20
ahasenackbrb, coffee18:20
javaJakeahasenack: alright, dumb question: I'm getting an "aborting due to unexpected upstream changes" on a clean clone of mantic-devel in an ubuntu:23.10 lxc. The file it's complaining about are these "..git" files which appear to be some kind of submodule reference: https://git.launchpad.net/ubuntu/+source/crun/tree/libocispec/image-spec/..git?h=ubuntu/mantic-devel19:16
ahasenackhow are you building the source package? WHich command?19:16
javaJakeGreat question. I'm using https://github.com/canonical/ubuntu-maintainers-handbook/blob/main/PackageBuilding.md#build-source-packages-with-dpkg-buildpackage but I swapped the 'lxc launch' image to 'ubuntu:23.10'. On another read through, perhaps it's the 'pull-debian-source' line...19:17
ahasenackok, just a sec19:18
ahasenackjavaJake: so at first you are trying to just rebuild the existing package, with no changes, right?19:18
javaJakeYea, just as a sanity check19:19
ahasenackhm, those instructions seem overly complicated19:19
ahasenackdoes that env still have ubuntu-dev-tools installed?19:19
ahasenackdid you git checkout the package?19:20
ahasenackor you just ran those commands?19:20
javaJakeAh, yep. I ran those commands within a git clone of the repo you linked, at the branch you referenced, so the 'tar' would migrate the git clone to the lxc correctly.19:20
ahasenackok, so since you have the git tree, no need to run those commands19:21
ahasenackexcept one tiny bit, get the orig tarball source19:21
ahasenackmake sure you are in a clean git checkout of mantic-devel for that package19:22
ahasenackdo git clean -f -x -d; git reset --hard if you have to19:22
ahasenackHEAD should be ce6b5807a7ba8449bd799128344df641bb3a806b19:22
javaJakeYea, it is squeaky clean there.19:24
ahasenackthen, in the parent directory (so, run "cd ..")19:24
ahasenackrun "pull-lp-source -d crun mantic" to download the orig tarball (and some other artifacts, not important)19:24
ahasenackthat will download-only (-d) the crun source, from mantic19:24
javaJakeAnd the HEAD is correct. I just trusted the eyeball of that giant && block more than I should have. I suspect the goal is to just get the dpkg-buildpackage command to work with as little fiddling as possible.19:25
ahasenackthat blob is assuming many things, like that the build will just work19:25
ahasenackall in one command line...19:25
ahasenackso maybe let's skip those pages for now19:26
ahasenackdo you have a crun_1.8.5.orig.tar.xz file now?19:26
javaJakeThe man page for pull-lp-source and pull-debian-source both go to pull-pkg... is your use of pull-lp-source just a habit?19:26
ahasenackubuntu and debian share a lot (A LOT) of things19:27
javaJakeahasenack: and yes I have the orig.tar.xz19:27
ahasenackbut to get what was published in a specific ubuntu release, you should use pull-lp-source19:27
ahasenackand if you want something from a specific debian release, then pull-debian-source19:27
ahasenackjavaJake: ok, now go back into the git checkout path19:27
ahasenacknext step is to install the build dependencies19:28
javaJakeOK. More just a curiosity question: do the behaviors change based on the alias (like vi vs vim or sh vs bash)?19:28
ahasenack"sudo apt-get build-dep ."19:28
ahasenackjavaJake: yes19:28
ahasenackmany programs check with which name they were called19:28
ahasenack(if the alias points to the same executable)19:28
javaJakeWhoa. What is apt-get reading from "."?19:28
ahasenack"." is current directory19:29
ahasenackI suppose it would also work from the parent dir, then specifying the name of the directory where the git checkout is19:29
ahasenackagain, muscle memory/habit :)19:29
ahasenackbut it's reading the BUild-Depends field in debian/control19:29
javaJakeI knew . is current directory ;) I was just surprised apt-get will accept a directory.19:30
javaJakeGot it, very cool.19:30
ahasenackin older versions (like, much older), it didn't19:30
ahasenackafter that finishes, there is one extra build-dep that is rarely declared, but sometimes needed, and it's annoying to have to find out just because of an error. So go ahead and also install "fakeroot" (sudo apt install fakeroot)19:31
javaJakeAlright, is it time to run 'dpkg-buildpackage -S'?19:31
javaJakeOh, got it.19:31
ahasenackafter you have fakeroot, let's build the binaries. No need to build the source at this stage19:31
ahasenackto build the binaries for testing, run "dpkg-buildpackage -uc -us". The -uc -us parameters are to skip gpg signing19:32
ahasenackI like to (muscle memory!) use "time dpkg-buildpackage -uc -us 2>&1 | tee ../build.log"19:32
javaJakeAhhh, I thought '-S' meant "from" source. OK.19:32
ahasenack-S is build a source package, yes19:32
ahasenackthat is needed when you want to upload the source somewhere, like a ppa, or actual ubuntu, for processing19:32
ahasenackah, got your point19:32
javaJake'-b' must be the default?19:33
ahasenackthere is no shortage of command-line options for dpkg-buildpackage19:33
ahasenacksome are not even for dpkg-buildpackage itself, but passed on to other helpers it calls19:33
ahasenackrabbit hole warning19:33
ahasenackit's "fun" to chase these down in manpages19:33
ahasenackafter this finishes, you will see that your parent directory got a bit messy, with lots of files in it (hopefully)19:34
javaJakeHah. :) This is why I was initially trusting of the && block because I was trying not to do my usual of poking around, since I know I'm dealing with decades-old infra that's going to have a lot of long ways to lose time reading.19:34
ahasenackof all the things in the parent directory, if you want to cleanup, you can delete all, except the orig tarball. Without that, the build won't proceed and you will have to download it again19:35
ahasenack(if there is a detached gpg signature, like *.asc, keep it too)19:36
javaJakeOK, I might've must have messed up the clone because it's giving me the same error. I deleted the clone, and reran in the lxc (to avoid possible issues with tar) and that still failed. I've got git-ubuntu installed so I can try that.19:41
javaJakeThose submodules might be an extra wrinkle.19:42
ahasenackcan you paste the whole session, starting from the clean git checkout at ce6b5807a7ba8449bd799128344df641bb3a806b ?19:42
ahasenacknot here, but in a pastebin19:42
ahasenackI'll try the same here19:42
ahasenackand guess what, I also got that19:43
ahasenacknow I'm annoyed19:43
javaJakeI mean :(19:43
ahasenackhow dare crun ruin this19:43
ahasenackgood news is you did nothing wrong19:44
javaJakeI've never seen the "..git" file before. It looks like a submodule but it's also not recognized by git as one.19:45
ahasenackthe ..git is an escaping mechanism19:45
ahasenackit means the upstream tarball had a .git directory in it already19:45
javaJakeAh, gotcha.19:45
ahasenackand to represent that in git, without its special meaning, means we need to rename it somehow19:45
ahasenackthat's... annoying19:45
javaJakeWould a tool like git-buildpackage read the ..git and know how to rehydrate that?19:47
ahasenackI don't know19:47
ahasenackyou can try this instead:19:48
ahasenackdpkg-buildpackage -uc -us -I -i -i..19:48
ahasenack-I and -i are used to exclude common "noise" directories, like .git19:48
ahasenackops, wait19:48
ahasenackwell, that worked, but I don't know how19:48
ahasenackI meant to use -i..git19:48
ahasenack@rbasak: do we have a trick to build packages where the orig tarball has .git somewhere, and git-ubuntu renamed that to ..git?19:52
ahasenackbecause ..git is not in the list of patterns that dpkg-* excludes when building a package, and then it complains the source contents do not match the orig tarball anymore19:53
ahasenackjavaJake: options: a) find the right incantation of dpkg-buildpackage that works (maybe that -i.. I tried? But I don't know how it worked)19:55
ahasenackb) build without the git checkout, just using the source package downloaded from launchpad (pull-lp-source, which you might have noticed also downloaded some other files: all of these together make up a debian source package)19:55
ahasenackyou can try -i.., it *seems* to have worked19:56
javaJakeAlso git-buildpackage does not help either.19:56
ahasenacklet me see how it imports the package19:57
ahasenackthere is gbp import-dsc *.dsc19:57
ahasenackit will use the "crun" directory, so if that is the git checkout, better try somewhere else where it can start clean19:57
javaJakeAnd it put me on a debian tag rather than Ubuntu...19:59
ahasenackyeah, its import cannot be used to create PRs in launchpad20:00
ahasenackit's just to help managing the code locally, trying patches, cleaning the build, etc20:00
javaJakeGotcha. Yea it also is a git without a remote which is disorienting.20:00
ahasenacksorry, starting with this package was a bummer20:00
ahasenackdid you try the build with -i.. ?20:01
javaJakeNah, it's all good :) I'll try it now.20:01
ahasenackback into the ubuntu git checkout20:01
javaJakeIt is running now20:03
javaJakeAnd built! Nice. Now to break it with an attempt at patching.20:04
ahasenackI'm searching https://bugs.launchpad.net/git-ubuntu to see if this is known20:04
javaJakeI'm going to continue with this and see how far I get: https://github.com/canonical/ubuntu-maintainers-handbook/blob/main/PackageFixing.md#apply-the-fix20:10
ahasenackjavaJake: maybe https://github.com/canonical/ubuntu-maintainers-handbook/blob/main/DebianPatch.md#generate-a-patchfile-with-git directly20:12
ahasenackkeep in mind that the actual source tree should remain unchanged (except for changes in debian/*). So if making a change to the source tree, to then get "git diff" to show it and generate a patch, the only thing you should be committing is the patch, NOT the source code changes20:12
ahasenackjust the patch in debian/patches/<patch>, and corresponding debian/patches/series20:13
ahasenackgit diff > debian/patches/myfix.patch20:13
ahasenackgit add debian/patches/myfix.patch20:13
ahasenackgit commit -m hooray20:13
ahasenackgit clean -f -x -d20:13
ahasenackand then update debian/patches/series too20:14
javaJakeThankfully I have experience with quilt so this is familiar to me.20:16
javaJakeBuilt with a patch! I've installed and am running the repro in the bug to see if I fixed the issue.20:31
javaJakeIf I was extra cool, I suppose the repro would be nice to add as a regression test?20:31
ahasenackoh, yeah, coolness++20:42
john-cabajI'm trying to build with `sbuild` in my local environment on a noble chroot, but it's having issues. I ran `dpkg-buildpackage -uc -us` from within the chroot and things are going much more smoothly. Is there a fundamental difference between these two methods?20:42
ahasenackI rarely use sbuild, I tend to just have lxd containers lying around for that, as usually after a build I also want to install and test the package, so the container serves both purposes20:43
john-cabajI'll grab the build log dumps from both and see where things go sideways20:44
liushuyuucspi-tcp fix: https://code.launchpad.net/~liushuyu-011/ubuntu/+source/ucspi-tcp/+git/ucspi-tcp/+merge/46423020:54
liushuyuA bit chaotic for this package20:54
javaJakeahasenack: what's the best way to make sure my source package is built with my GPG key for the PPA submission?20:56
liushuyuPatch forwarded to Debian as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=106662920:56
-ubottu:#ubuntu-devel- Debian bug 1066629 in src:ucspi-tcp "ucspi-tcp: FTBFS: tcpserver.c:143:29: error: implicit declaration of function ‘getpid’ [-Werror=implicit-function-declaration]" [Serious, Open]20:56
ahasenackjavaJake: you can't upload to ubuntu I suppose, so even if you sign the package (i.e., drop the -uc -us options), your upload will be rejected20:57
ahasenackjavaJake: the way it works is that you get sponsorship for your upload20:57
ahasenackso d/changelog will have your entry, with your name/email, but someone else will sign the upload for you20:57
liushuyujavaJake: for PPA purposes, you can set the environment variable DEBSIGN_KEYID to your GPG key ID20:57
ahasenackonce uploaded, the change will be yours, credited to you, and go under your upload tally, but there will be af ield saying it was sponsored by someone else20:57
ahasenackah, yes, there are ppas that you can create, as liushuyu is explaining. There you can upload20:58
javaJakeahasenack: OK so for the purposes of this fix, just push my branch, then a sponsor will handle the signing and uploading for the rest of the test process?20:58
liushuyuTo set the environment variables, you can use the `export` command20:58
javaJakeYea, I saw that PPA's are a nice way to run tests and it also is done in infra rather than a "trust me" human :)20:59
ahasenackcorrect, it a ppa fails to build, it's very likely the final upload will also fail20:59
liushuyuexport DEBSIGN_KEYID=<your key id>20:59
ahasenacksorry, I had missed the "PPA submission" part of your question before21:00
liushuyuPPA uses the same infra as the Ubuntu primary package archives21:00
liushuyuIf your packages build in your PPA, it's highly likely that your packages will build successfully in the official Ubuntu archives21:00
ahasenackjavaJake: the moment you do a "git push" with your remote, the response should include a url that you can use to file a merge proposal21:02
ahasenack@pilot out21:02
=== ChanServ changed the topic of #ubuntu-devel to: Archive: Post-Beta Freeze | Devel of Ubuntu (not support) | packages with removed amd64 binaries that need resolving: https://pad.riseup.net/p/migrate-list-amd64 | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: N/A
ahasenack(I'm off shift, but feel free to continue the conversation. It's 6pm here, so I'll be on and off)21:03
liushuyutaking samhain21:03
liushuyutaking scrollz21:05
liushuyuvorlon: can you generate a new migration list to see if there are anything left to migrate? I think we have exhausted the current pile21:06
javaJakeahasenack: should I put you on the review for the merge proposal?21:08
ahasenackyou may, but ubuntu-sponsors is a wider audience21:08
ahasenackyou can do both21:10
javaJakeahasenack: thanks :) https://code.launchpad.net/~fun2program8/ubuntu/+source/crun/+git/crun/+merge/464233 it is in! First ever attempt to contribute. I'll be looking forward to what additional information or changes are needed to accept, if a sponsor has time. Thanks for your help getting it in!21:13
ahasenackgot it21:14
ahasenackcongrats! Thanks a lot for working over the unexpected hurdles21:14
john-cabajWell it seems that `dpkg-buildpackage -uc -us` does fail in the same was as `sbuild`. For some reason libtirpc-dev is not being installed in the Noble chroot. Manually installing it fixes `dpkg-buildpackage` in the chroot, but `sbuild` fails in the same way.21:20
john-cabajI'm not sure why `sbuild` isn't picking that up. Or why it's necessary to manually install libtirpc-dev21:21
ahasenackis it declared in d/control?21:22
john-cabajahasenack: It is not21:27
john-cabajThough I haven't actually made any changes to the package. This was a `pull-lp-source` and rebuild. So I don't know how this ever built21:27
liushuyujohn-cabaj: That's very fragile. Maybe there is a transitive dependency that removed libtirpc-dev from its depends21:27
liushuyuIt seems like your sbuild instance does not contain libtirpc-dev21:28
liushuyusamhain fix: https://code.launchpad.net/~liushuyu-011/ubuntu/+source/samhain/+git/samhain/+merge/46423421:29
john-cabajThere was a no change rebuild against libtirpc3t64 a few versions back. Not sure if that is just a coincidence in name. My chroot definitely doesn't have libtirpc-dev installed by default.21:29
john-cabajMantic chroot has it installed by default21:29
liushuyujohn-cabaj: It should not have development headers installed by default, I believe libtirpc-dev should be added to the package Build-Depends21:30
john-cabajliushuyu: Worth a shot21:30
john-cabajliushuyu: That seems to have done the trick. Still, debian doesn't have that particular dependency. That's interesting.21:42
liushuyujohn-cabaj: Some packages with time_t changes have not even uploaded to Debian21:43
liushuyuThere may lie the differences21:44
john-cabajliushuyu: Good point21:44
john-cabajliushuyu: With other packages seeing similar issues, are quilt patches generally being used to account for this?21:45
liushuyujohn-cabaj: quilt patches are used to patch upstream code (not Debian files)21:46
liushuyuIf you want to represent Debian package changes, you might want to use debdiff21:47
john-cabajliushuyu: That's right. I'm working to get this to git-ubuntu, so at least a patch there would be a commit.21:48
liushuyujohn-cabaj: If you are using git-ubuntu, I believe you don't have to worry about that. Just commit your changes, add a debian/changelog entry (you can use `dch -i`), and then open a merge proposal21:49
liushuyuIf you are making changes to the zfs-linux code, then you will need a patch21:50
liushuyuThe patch in my previous sentence means "quilt patch"21:50
john-cabajliushuyu: ack21:51
liushuyuI hope I have expressed the process clear enough, this does look like a confusing situation21:51
john-cabajYou have21:51
john-cabajzfs-linux isn't in git-ubuntu yet, I'm working on getting it ready for that process21:52
liushuyujohn-cabaj: Ah okay, I see21:53
john-cabajliushuyu: (And updating for zfs 2.2.3, and fixing fallout from xz/time_t apparently)21:54
liushuyuIf you can't use git-ubuntu, the process will be submitting a patch with a Launchpad bug. You will need to use debdiff to generate a source package patch21:54
john-cabajliushuyu: ack21:54
liushuyu... which can be quite a confusing experience21:55
john-cabajliushuyu: I'm definitely not in kernel-land anymore21:55
liushuyujohn-cabaj: "land" or an "island", I am unsure :)21:56
john-cabajliushuyu: Closer to the latter lately, haha21:57
john-cabajOn to other build failures, so task failed successfully.22:00
john-cabajDinner time now, thanks for the help all!22:00
vorlonliushuyu: I lost the script to generate that list in my shell history, heh. I'll reconstitute it and post a new list yes22:12
vorlonooh found it22:12
vorlonok regenerating22:12
vorlonliushuyu: https://bugs.launchpad.net/ubuntu/+source/rustc/+bug/2052985 - sorry, I guess I misunderstood what you were saying earlier as there is no new comment on here since your comment on March 8 saying "rebuild testing is hard".  I thought you had said you did do rebuild testing of the rust reverse-dependencies.  This should be possible to do for the packages in the release pocket?  And I would22:15
-ubottu:#ubuntu-devel- Launchpad bug 2052985 in rustc (Ubuntu) "[FFe] Upgrade Rust to 1.76.0" [Medium, Incomplete]22:15
vorlonwant the results of such a rebuild test before signing off on an FFe this late that could regress buildability of a large group of packages in the archive22:15
liushuyuscrollz fix: https://code.launchpad.net/~liushuyu-011/ubuntu/+source/scrollz/+git/scrollz/+merge/46423622:21
liushuyuForwarded to Debian as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=106648322:22
-ubottu:#ubuntu-devel- Debian bug 1066483 in src:scrollz "scrollz: FTBFS: configure: error: Fatal: You must get working getaddrinfo() function." [Serious, Open]22:22
liushuyuvorlon: the rebuild ppa is https://launchpad.net/~liushuyu-011/+archive/ubuntu/rust-updates-1.76-wrb/+packages22:23
liushuyua lot of those packages failed to build due to unmet dependencies22:23
liushuyu(we can't sync all those micropackages into Ubuntu, and some of those are removed from Ubuntu as well)22:24
vorlonliushuyu: of the current noble release pocket versions?22:24
vorlonliushuyu: "we can't sync" why not?22:24
liushuyuvorlon: IIRC Debian Rust team currently has a new policy where new packages are staged, but some broken ones still slipped through the cracks22:25
liushuyuthey will not have the correct dependencies and they don't care22:26
liushuyuI can redo the archive copy though22:26
vorlonliushuyu: fwiw I have 40 packages so far that are not yet resolved in the release pocket wrt amd64 binary removals (currently at 'p' in the alphabet)22:28
vorlonthis list may get shorter after britney manages to finish running, since it was down all day22:29
liushuyuvorlon: the shared notepad shows we have already finished though22:29
vorlonit shows action was taken on each package, but that action may or may not have been sufficient to get a fix into the release pockt22:30
liushuyuvorlon: yes, so that's why a new list is needed to assess if those actions are suffice22:30
vorlonliushuyu: https://paste.ubuntu.com/p/bXwBKWkF3P/22:51
vorlonbut as I said, maybe that gets shorter after britney + publisher run22:52
liushuyuvorlon: okay, let's wait for the britney update then22:56
vorlonwell, britney run just failed because of a rabbit disconnect error (and because my workaround for such errors was incomplete); next run has started now23:59

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