[00:04] <liushuyu> afk for a while
=== 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
[00:52] <vpa1977> cgmb: it seems that glibc bug is fixed, so maybe just retrying build should help
[00:53] <cgmb> vpa1977: my understanding is that upstream basically responded wont-fix.
[00:54] <cgmb> It is definitely still broken.
[00:54] <cgmb> I have a patch for glibc, but I don't expect it to be merged and uploaded in time for noble.
[00:55] <vpa1977> cgmb: would it be possible to put some comment in the merge proposal regarding this?
[01:00] <cgmb> vpa1977: done
[01:18] <vpa1977> cgmb: I've added it to the commit for the next person
[06:05] <vorlon> eeew kdiagram ftbfs on riscv64 because building with nocheck changes the ABI of the library
[08:42] <adrien> I'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] <adrien> because I *really* want to trigger PPA tests after a PPA build is done and published
[08:51] <sudip> adrien: https://wiki.ubuntu.com/ProposedMigration#autopkgtests has a section "Testing against a PPA"
[08:54] <adrien> sudip: 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] <adrien> what's missing for me is the automation between the build and test steps
[09:14] <vpa1977> sudip: 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:15] <sudip> vpa1977: In Debian libHX is waiting for a sponsor to upload, hxtools wont be ftbfs after that
[09:15] <sudip> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064734
[09:15] -ubottu:#ubuntu-devel- Debian bug 1064734 in src:libhx "Please include upstream patch" [Serious, Open]
[09:15] <vpa1977> sudip: ah, sorry, I linked wrong one. You've also fixed the missing dependency there
[09:17] <vpa1977> https://bugs.launchpad.net/ubuntu/+source/hxtools/+bug/2060728
[09:17] -ubottu:#ubuntu-devel- Launchpad bug 2060728 in hxtools (Ubuntu) "gpsh fails to run in Noble" [Undecided, New]
[09:18] <sudip> vpa1977: 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 Debian
[09:19] <vpa1977> sudip: ah I see, thank you!!!!!!!
[09:20] <vpa1977> its just sometimes they accept fixes that they do not really need =)
[09:23] <sudip> I will open a bug as soon as I am out of this meeting in my $dayjob
[09:47] <sudip> vpa1977: done
[09:47] <sudip> https://bugs.debian.org/1068855
[09:47] -ubottu:#ubuntu-devel- Debian bug 1068855 in hxtools "hxtools: gpsh fails to run" [Normal, Open]
[09:47] <vpa1977> sudip: Thank you!!!!!!!
[10:32] <sudip> I am seeing lots of rust packages failing to install in Noble
=== guiverc2 is now known as guvierc
[13:13] <jbicha> sudip: could you give an example? I know that the Rust GNOME stack is incomplete but I'm working on it
[13:17] <sudip> jbicha: librust-gsk4-dev
[13:19] <sudip> there are many more :)
[13:26] <jbicha> sudip: that one is part of the Rust GNOME stack; probably 50+ source packages
[13:30] <sudip> ohh.. ok.. I will check my list again
[13:38] <sudip> so I think only 3 in my list are non Rust GNOME stack, but thats a guess from the failed dependency name
[13:39] <sudip> like librust-ripasso-dev
[13:43] <jbicha> sudip: ok, I'm syncing rust-ripasso to probably fix that issue
[13:44] <jbicha> hopefully that will allow rust-sequoia/capnp* to migrate
[13:45] <sudip> librust-secret-service-dev
[13:46] <sudip> librust-pleaser-dev
[13:46] <sudip> librust-octocrab-dev
[13:46] <sudip> librust-minijinja-dev
[13:47] <sudip> I think remaining all in my list is from rust GNOME
[13:49] <jbicha> all of those except for rust-pleaser are also broken in Debian
[13:50] <jbicha> https://ubuntu-archive-team.ubuntu.com/transitions/html/rust.html and https://release.debian.org/transitions/html/rust.html can be helpful
[13:51] <jbicha> rust-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 yet
[13:57]  * sudip does not understand the rust ecosystem
[14:49] <jbicha> the Debian Rust packaging is "interesting"
[15:04] <sudip> yeah, I wanted to take https://bugs.debian.org/1064957 but after reading about Debian Rust packaging I discarded that idea
[15:04] -ubottu:#ubuntu-devel- Debian bug 1064957 in wnpp "RFP: bpftop -- dynamic real-time view of running eBPF programs" [Wishlist, Open]
=== cpaelzer_ is now known as cpaelzer
[16:27] <akarlson> Can 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/2060692
[16:41] <ahasenack> @pilot in
=== 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
[16:59] <vorlon> liushuyu: hi, were you looking at magics++/odc?
[17:01] <vorlon> liushuyu: 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 !amd64
[17:07] <bdrung> should we remove the packages from https://pad.riseup.net/p/migrate-list-amd64 once they migrated?
[17:10] <javaJake> There'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:11] <liushuyu> vorlon: Yes, I believe you mentioned this was an issue with dh-fortran-mod + patchelf
[17:13] <ahasenack> javaJake: can you upload/sponsor? If not, pass me the link and I can take a look, I'm on patch pilot this afternoon
[17:14] <javaJake> ahasenack: 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/2052961
[17: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:15] <ahasenack> that rings a bell
[17:15] <ahasenack> javaJake: 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] <ahasenack> the latter has a crun package in proposed for jammy already, but missing a fix in mantic
[17:15] <liushuyu> vorlon: also, https://bugs.launchpad.net/ubuntu/+source/rustc/+bug/2052985
[17:16] -ubottu:#ubuntu-devel- Launchpad bug 2052985 in rustc (Ubuntu) "[FFe] Upgrade Rust to 1.76.0" [Medium, Incomplete]
[17:16] <javaJake> ahasenack: that's the one. Mine was first though ;)
[17:17] <ahasenack> javaJake: I'll mark it as a duplicate, as the other one (the one I linked) is far ahead in the update process
[17:18] <javaJake> Yea that makes sense. :) And it looks like the resolution for 23.10 is to just wait for 24.04 and upgrade.
[17:18] <ahasenack> yeah, I'm not super happy with that, I don't like to skip releases just because they are not LTSs
[17:19] <liushuyu> taking ucspi-tcp
[17:19] <ahasenack> javaJake: would you be willing to prepare a fix for mantic?
[17:20] <javaJake> ahasenack: 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:21] <ahasenack> javaJake: this is how it was fixed in jammy: https://git.launchpad.net/ubuntu/+source/crun/commit/?id=4104b1eb0fb1f5d258b54785786d7034f3076b44
[17: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] <ahasenack> unfortunately all is squashed as a single commit
[17:21] <ahasenack> javaJake: the key things are: d/changelog update with versiom bump, d/p/<actual-patch>, and d/p/series listing that patch
[17:22] <javaJake> ahasenack: got it
[17:23] <ahasenack> javaJake: for mantic, you can start here: https://code.launchpad.net/~git-ubuntu-import/ubuntu/+source/crun/+git/crun/+ref/ubuntu/mantic-devel
[17:23] <ahasenack> "ubuntu/mantic-devel" is the tip/main/master of the package in ubuntu mantic
[17:23] <ahasenack> then create a branch off of that with your fix (name it appropriately), and start committing
[17:24] <ahasenack> if you rather just provide the patch, with no ubuntu packaging, that also works
[17:24] <ahasenack> but if you are familiar with git, I think it shouldn't be difficult to work with that repository
[17:25] <liushuyu> taking xbill
[17:27] <javaJake> ahasenack: 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] <ahasenack> definitely
[17:27] <ahasenack> so 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 both
[17:47] <javaJake> ahasenack: sounds good. I'm getting a 23.10 install I can mess with and got the git repo cloned.
[17:48] <ahasenack> excellent
[17:48] <ahasenack> javaJake: if I can give you a tip, I don't know what's your host OS
[17:49] <javaJake> Ah, it's unfortunately Windows 11 Pro atm :) but I have Hyper-V running a new install.
[17:49] <ahasenack> you can easily bring up a mantic vm
[17:49] <ahasenack> ah
[17:49] <javaJake> Perhaps WSL2 would've worked but I didn't want to add WSL2 variables to the mix.
[17:49] <ahasenack> well, there I cannot help (bringing up a mantic vm)
[17:49] <ahasenack> this test needs a vm
[17:49] <ahasenack> as you need to run the ubuntu kernel
[17:49] <javaJake> Yea, that's what I figured.
[17:50] <ahasenack> in ubuntu with lxd installed if would have been "lxc launch ubuntu-daily:mantic my-mantic-vm --vm"
[17:51] <javaJake> Ahhh, I didn't realize lxd could run whole VMs
[17:51] <ahasenack> yep, it can
=== pushkarnk1 is now known as pushkarnk
[18:05] <javaJake> ahasenack: 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] <javaJake> This entire site appears to be heavily WIP
[18:05] <ahasenack> hm
[18:06] <vorlon> liushuyu: yes, but someone needs to do the work of tracing the deps and requesting removal of the binaries
[18:07] <vorlon> liushuyu: I'll have a look at the rustc FFe later today
[18:07] <ahasenack> javaJake: there is this which the ubuntu server team wrote: https://github.com/canonical/ubuntu-maintainers-handbook?tab=readme-ov-file
[18:07] <ahasenack> it might be way more detailed than what you want
[18:07] <javaJake> I can pick through it! Thanks! Debian packaging has been a black box for too long. It's time I learned. :)
[18:08] <ahasenack> you are welcome :)
[18:10] <javaJake> Oh my gosh! Ubuntu uses quilt? That's awesome. I love quilt.
[18:10] <ahasenack> debian packaging can use quilt, yes (most do)
[18:17] <javaJake> This 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] <ahasenack> well, inside a lxd container (or vm, or chroot), you can make any changes you want without fearing breaking your host system
[18:17] <ahasenack> or polluting it
[18:17] <ahasenack> because to buildt the package, you will have to install build dependencies
[18:18] <ahasenack> if you do that on your host, well, you will be installing packages you might not need anymore after this build
[18:18] <ahasenack> using a clean lxd (or vm, or chroot, ...) is also closer to what will be used in the real builders later on
[18:18] <ahasenack> they start clean, and install the exact build dependencies that are declared
[18:19] <ahasenack> if 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 package
[18:19] <javaJake> That last bit is what gives me nightmares
[18:19] <ahasenack> so yeah, in general, get a vm/container/chroot to test-build the packages
[18:20] <ahasenack> since you will want to test this in a mantic vm anyway, I would suggest to use that same vm for the building
[18:20] <ahasenack> brb, coffee
[19:16] <javaJake> ahasenack: 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-devel
[19:16] <ahasenack> how are you building the source package? WHich command?
[19:17] <javaJake> Great 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:18] <ahasenack> ok, just a sec
[19:18] <ahasenack> javaJake: so at first you are trying to just rebuild the existing package, with no changes, right?
[19:19] <javaJake> Yea, just as a sanity check
[19:19] <ahasenack> hm, those instructions seem overly complicated
[19:19] <ahasenack> does that env still have ubuntu-dev-tools installed?
[19:19] <javaJake> Yes
[19:20] <ahasenack> did you git checkout the package?
[19:20] <ahasenack> or you just ran those commands?
[19:20] <javaJake> Ah, 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] <javaJake> s/migrate/copy/
[19:21] <ahasenack> ok, so since you have the git tree, no need to run those commands
[19:21] <ahasenack> except one tiny bit, get the orig tarball source
[19:22] <javaJake> OK
[19:22] <ahasenack> make sure you are in a clean git checkout of mantic-devel for that package
[19:22] <ahasenack> do git clean -f -x -d; git reset --hard if you have to
[19:22] <ahasenack> HEAD should be ce6b5807a7ba8449bd799128344df641bb3a806b
[19:24] <javaJake> Yea, it is squeaky clean there.
[19:24] <ahasenack> then, in the parent directory (so, run "cd ..")
[19:24] <ahasenack> run "pull-lp-source -d crun mantic" to download the orig tarball (and some other artifacts, not important)
[19:24] <ahasenack> that will download-only (-d) the crun source, from mantic
[19:25] <javaJake> And 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] <ahasenack> that blob is assuming many things, like that the build will just work
[19:25] <ahasenack> all in one command line...
[19:26] <ahasenack> so maybe let's skip those pages for now
[19:26] <ahasenack> do you have a crun_1.8.5.orig.tar.xz file now?
[19:26] <javaJake> The 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] <ahasenack> mostly
[19:27] <ahasenack> ubuntu and debian share a lot (A LOT) of things
[19:27] <javaJake> ahasenack: and yes I have the orig.tar.xz
[19:27] <ahasenack> but to get what was published in a specific ubuntu release, you should use pull-lp-source
[19:27] <ahasenack> and if you want something from a specific debian release, then pull-debian-source
[19:27] <ahasenack> javaJake: ok, now go back into the git checkout path
[19:28] <ahasenack> next step is to install the build dependencies
[19:28] <javaJake> OK. 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] <ahasenack> javaJake: yes
[19:28] <ahasenack> many programs check with which name they were called
[19:28] <ahasenack> (if the alias points to the same executable)
[19:28] <javaJake> Whoa. What is apt-get reading from "."?
[19:29] <ahasenack> "." is current directory
[19:29] <ahasenack> I suppose it would also work from the parent dir, then specifying the name of the directory where the git checkout is
[19:29] <ahasenack> again, muscle memory/habit :)
[19:29] <ahasenack> but it's reading the BUild-Depends field in debian/control
[19:30] <javaJake> I knew . is current directory ;) I was just surprised apt-get will accept a directory.
[19:30] <javaJake> Got it, very cool.
[19:30] <ahasenack> in older versions (like, much older), it didn't
[19:31] <ahasenack> after 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] <javaJake> Alright, is it time to run 'dpkg-buildpackage -S'?
[19:31] <javaJake> Oh, got it.
[19:31] <ahasenack> after you have fakeroot, let's build the binaries. No need to build the source at this stage
[19:32] <ahasenack> to build the binaries for testing, run "dpkg-buildpackage -uc -us". The -uc -us parameters are to skip gpg signing
[19:32] <ahasenack> I like to (muscle memory!) use "time dpkg-buildpackage -uc -us 2>&1 | tee ../build.log"
[19:32] <javaJake> Ahhh, I thought '-S' meant "from" source. OK.
[19:32] <ahasenack> -S is build a source package, yes
[19:32] <ahasenack> that is needed when you want to upload the source somewhere, like a ppa, or actual ubuntu, for processing
[19:32] <ahasenack> ah, got your point
[19:33] <javaJake> '-b' must be the default?
[19:33] <ahasenack> yep
[19:33] <ahasenack> there is no shortage of command-line options for dpkg-buildpackage
[19:33] <ahasenack> some are not even for dpkg-buildpackage itself, but passed on to other helpers it calls
[19:33] <ahasenack> rabbit hole warning
[19:33] <ahasenack> it's "fun" to chase these down in manpages
[19:34] <ahasenack> after this finishes, you will see that your parent directory got a bit messy, with lots of files in it (hopefully)
[19:34] <javaJake> Hah. :) 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] <ahasenack> yep
[19:35] <ahasenack> of 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 again
[19:36] <ahasenack> (if there is a detached gpg signature, like *.asc, keep it too)
[19:41] <javaJake> OK, 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:42] <javaJake> Those submodules might be an extra wrinkle.
[19:42] <ahasenack> can you paste the whole session, starting from the clean git checkout at ce6b5807a7ba8449bd799128344df641bb3a806b ?
[19:42] <ahasenack> not here, but in a pastebin
[19:42] <ahasenack> I'll try the same here
[19:43] <ahasenack> and guess what, I also got that
[19:43] <ahasenack> now I'm annoyed
[19:43] <javaJake> :D
[19:43] <javaJake> I mean :(
[19:43] <ahasenack> how dare crun ruin this
[19:44] <ahasenack> good news is you did nothing wrong
[19:45] <javaJake> I've never seen the "..git" file before. It looks like a submodule but it's also not recognized by git as one.
[19:45] <ahasenack> the ..git is an escaping mechanism
[19:45] <ahasenack> it means the upstream tarball had a .git directory in it already
[19:45] <javaJake> Ah, gotcha.
[19:45] <ahasenack> and to represent that in git, without its special meaning, means we need to rename it somehow
[19:45] <ahasenack> that's... annoying
[19:47] <javaJake> Would a tool like git-buildpackage read the ..git and know how to rehydrate that?
[19:47] <ahasenack> I don't know
[19:48] <ahasenack> you can try this instead:
[19:48] <ahasenack> dpkg-buildpackage -uc -us -I -i -i..
[19:48] <ahasenack> -I and -i are used to exclude common "noise" directories, like .git
[19:48] <ahasenack> ops, wait
[19:48] <ahasenack> well, that worked, but I don't know how
[19:48] <ahasenack> I meant to use -i..git
[19:52] <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:53] <ahasenack> because ..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 anymore
[19:55] <ahasenack> javaJake: 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] <ahasenack> b) 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:56] <ahasenack> you can try -i.., it *seems* to have worked
[19:56] <javaJake> Also git-buildpackage does not help either.
[19:57] <ahasenack> let me see how it imports the package
[19:57] <ahasenack> there is gbp import-dsc *.dsc
[19:57] <ahasenack> it will use the "crun" directory, so if that is the git checkout, better try somewhere else where it can start clean
[19:59] <javaJake> And it put me on a debian tag rather than Ubuntu...
[20:00] <ahasenack> yeah, its import cannot be used to create PRs in launchpad
[20:00] <ahasenack> it's just to help managing the code locally, trying patches, cleaning the build, etc
[20:00] <javaJake> Gotcha. Yea it also is a git without a remote which is disorienting.
[20:00] <ahasenack> sorry, starting with this package was a bummer
[20:01] <ahasenack> did you try the build with -i.. ?
[20:01] <javaJake> Nah, it's all good :) I'll try it now.
[20:01] <ahasenack> back into the ubuntu git checkout
[20:03] <javaJake> It is running now
[20:04] <javaJake> And built! Nice. Now to break it with an attempt at patching.
[20:04] <ahasenack> I'm searching https://bugs.launchpad.net/git-ubuntu to see if this is known
[20:10] <javaJake> I'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-fix
[20:12] <ahasenack> javaJake: maybe https://github.com/canonical/ubuntu-maintainers-handbook/blob/main/DebianPatch.md#generate-a-patchfile-with-git directly
[20:12] <ahasenack> keep 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 changes
[20:13] <ahasenack> just the patch in debian/patches/<patch>, and corresponding debian/patches/series
[20:13] <ahasenack> tl;dr
[20:13] <ahasenack> hack
[20:13] <ahasenack> hack
[20:13] <ahasenack> git diff > debian/patches/myfix.patch
[20:13] <ahasenack> git add debian/patches/myfix.patch
[20:13] <ahasenack> git commit -m hooray
[20:13] <ahasenack> git clean -f -x -d
[20:14] <ahasenack> and then update debian/patches/series too
[20:16] <javaJake> Thankfully I have experience with quilt so this is familiar to me.
[20:31] <javaJake> Built with a patch! I've installed and am running the repro in the bug to see if I fixed the issue.
[20:31] <javaJake> If I was extra cool, I suppose the repro would be nice to add as a regression test?
[20:42] <ahasenack> oh, yeah, coolness++
[20:42] <john-cabaj> I'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:43] <ahasenack> I 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 purposes
[20:44] <john-cabaj> I'll grab the build log dumps from both and see where things go sideways
[20:54] <liushuyu> ucspi-tcp fix: https://code.launchpad.net/~liushuyu-011/ubuntu/+source/ucspi-tcp/+git/ucspi-tcp/+merge/464230
[20:54] <liushuyu> A bit chaotic for this package
[20:56] <javaJake> ahasenack: what's the best way to make sure my source package is built with my GPG key for the PPA submission?
[20:56] <liushuyu> Patch forwarded to Debian as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066629
[20: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:57] <ahasenack> javaJake: 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 rejected
[20:57] <ahasenack> javaJake: the way it works is that you get sponsorship for your upload
[20:57] <ahasenack> so d/changelog will have your entry, with your name/email, but someone else will sign the upload for you
[20:57] <liushuyu> javaJake: for PPA purposes, you can set the environment variable DEBSIGN_KEYID to your GPG key ID
[20:57] <ahasenack> once 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 else
[20:58] <ahasenack> ah, yes, there are ppas that you can create, as liushuyu is explaining. There you can upload
[20:58] <javaJake> ahasenack: 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] <ahasenack> yes
[20:58] <liushuyu> To set the environment variables, you can use the `export` command
[20:59] <javaJake> Yea, 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] <ahasenack> correct, it a ppa fails to build, it's very likely the final upload will also fail
[20:59] <liushuyu> export DEBSIGN_KEYID=<your key id>
[21:00] <ahasenack> sorry, I had missed the "PPA submission" part of your question before
[21:00] <liushuyu> PPA uses the same infra as the Ubuntu primary package archives
[21:00] <liushuyu> If your packages build in your PPA, it's highly likely that your packages will build successfully in the official Ubuntu archives
[21:02] <ahasenack> javaJake: the moment you do a "git push" with your remote, the response should include a url that you can use to file a merge proposal
[21:02] <ahasenack> @pilot out
=== 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
[21:03] <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] <liushuyu> taking samhain
[21:05] <liushuyu> taking scrollz
[21:06] <liushuyu> vorlon: can you generate a new migration list to see if there are anything left to migrate? I think we have exhausted the current pile
[21:08] <javaJake> ahasenack: should I put you on the review for the merge proposal?
[21:08] <ahasenack> you may, but ubuntu-sponsors is a wider audience
[21:09] <javaJake> OK
[21:10] <ahasenack> you can do both
[21:13] <javaJake> ahasenack: 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:14] <ahasenack> got it
[21:14] <ahasenack> congrats! Thanks a lot for working over the unexpected hurdles
[21:20] <john-cabaj> Well 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:21] <john-cabaj> I'm not sure why `sbuild` isn't picking that up. Or why it's necessary to manually install libtirpc-dev
[21:22] <ahasenack> is it declared in d/control?
[21:27] <john-cabaj> ahasenack: It is not
[21:27] <john-cabaj> Though 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 built
[21:27] <liushuyu> john-cabaj: That's very fragile. Maybe there is a transitive dependency that removed libtirpc-dev from its depends
[21:28] <liushuyu> It seems like your sbuild instance does not contain libtirpc-dev
[21:29] <liushuyu> samhain fix: https://code.launchpad.net/~liushuyu-011/ubuntu/+source/samhain/+git/samhain/+merge/464234
[21:29] <john-cabaj> There 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-cabaj> Mantic chroot has it installed by default
[21:30] <liushuyu> john-cabaj: It should not have development headers installed by default, I believe libtirpc-dev should be added to the package Build-Depends
[21:30] <john-cabaj> liushuyu: Worth a shot
[21:42] <john-cabaj> liushuyu: That seems to have done the trick. Still, debian doesn't have that particular dependency. That's interesting.
[21:43] <liushuyu> john-cabaj: Some packages with time_t changes have not even uploaded to Debian
[21:44] <liushuyu> There may lie the differences
[21:44] <john-cabaj> liushuyu: Good point
[21:45] <john-cabaj> liushuyu: With other packages seeing similar issues, are quilt patches generally being used to account for this?
[21:46] <liushuyu> john-cabaj: quilt patches are used to patch upstream code (not Debian files)
[21:47] <liushuyu> If you want to represent Debian package changes, you might want to use debdiff
[21:48] <john-cabaj> liushuyu: That's right. I'm working to get this to git-ubuntu, so at least a patch there would be a commit.
[21:49] <liushuyu> john-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 proposal
[21:50] <liushuyu> If you are making changes to the zfs-linux code, then you will need a patch
[21:50] <liushuyu> The patch in my previous sentence means "quilt patch"
[21:51] <john-cabaj> liushuyu: ack
[21:51] <liushuyu> I hope I have expressed the process clear enough, this does look like a confusing situation
[21:51] <john-cabaj> You have
[21:52] <john-cabaj> zfs-linux isn't in git-ubuntu yet, I'm working on getting it ready for that process
[21:53] <liushuyu> john-cabaj: Ah okay, I see
[21:54] <john-cabaj> liushuyu: (And updating for zfs 2.2.3, and fixing fallout from xz/time_t apparently)
[21:54] <liushuyu> If 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 patch
[21:54] <john-cabaj> liushuyu: ack
[21:55] <liushuyu> ... which can be quite a confusing experience
[21:55] <john-cabaj> liushuyu: I'm definitely not in kernel-land anymore
[21:56] <liushuyu> john-cabaj: "land" or an "island", I am unsure :)
[21:57] <john-cabaj> liushuyu: Closer to the latter lately, haha
[22:00] <john-cabaj> On to other build failures, so task failed successfully.
[22:00] <liushuyu> uh-oh
[22:00] <john-cabaj> Dinner time now, thanks for the help all!
[22:12] <vorlon> liushuyu: I lost the script to generate that list in my shell history, heh. I'll reconstitute it and post a new list yes
[22:12] <vorlon> ooh found it
[22:12] <vorlon> ok regenerating
[22:15] <vorlon> liushuyu: 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 would
[22:15] -ubottu:#ubuntu-devel- Launchpad bug 2052985 in rustc (Ubuntu) "[FFe] Upgrade Rust to 1.76.0" [Medium, Incomplete]
[22:15] <vorlon> want 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 archive
[22:21] <liushuyu> scrollz fix: https://code.launchpad.net/~liushuyu-011/ubuntu/+source/scrollz/+git/scrollz/+merge/464236
[22:22] <liushuyu> Forwarded to Debian as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066483
[22:22] -ubottu:#ubuntu-devel- Debian bug 1066483 in src:scrollz "scrollz: FTBFS: configure: error: Fatal: You must get working getaddrinfo() function." [Serious, Open]
[22:23] <liushuyu> vorlon: the rebuild ppa is https://launchpad.net/~liushuyu-011/+archive/ubuntu/rust-updates-1.76-wrb/+packages
[22:23] <liushuyu> a lot of those packages failed to build due to unmet dependencies
[22:24] <liushuyu> (we can't sync all those micropackages into Ubuntu, and some of those are removed from Ubuntu as well)
[22:24] <vorlon> liushuyu: of the current noble release pocket versions?
[22:24] <vorlon> liushuyu: "we can't sync" why not?
[22:25] <liushuyu> vorlon: IIRC Debian Rust team currently has a new policy where new packages are staged, but some broken ones still slipped through the cracks
[22:26] <liushuyu> they will not have the correct dependencies and they don't care
[22:26] <liushuyu> I can redo the archive copy though
[22:28] <vorlon> liushuyu: 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:29] <vorlon> this list may get shorter after britney manages to finish running, since it was down all day
[22:29] <liushuyu> vorlon: the shared notepad shows we have already finished though
[22:29] <vorlon> "finished"
[22:30] <vorlon> it shows action was taken on each package, but that action may or may not have been sufficient to get a fix into the release pockt
[22:30] <liushuyu> vorlon: yes, so that's why a new list is needed to assess if those actions are suffice
[22:31] <vorlon> sure
[22:51] <vorlon> liushuyu: https://paste.ubuntu.com/p/bXwBKWkF3P/
[22:52] <vorlon> but as I said, maybe that gets shorter after britney + publisher run
[22:56] <liushuyu> vorlon: okay, let's wait for the britney update then
[23:59] <vorlon> well, britney run just failed because of a rabbit disconnect error (and because my workaround for such errors was incomplete); next run has started now