[05:49] <zhsj> hi, could someone retry the build https://launchpad.net/ubuntu/+source/golang-github-rogpeppe-go-internal/1.10.0+git20230524.ec11942-1/+build/26322895 (chroot problem)
[05:49] <zhsj> and `./retry-autopkgtest-regressions --blocks golang-defaults` as well
[05:52] <Unit193> Did the former.
[05:54] <zhsj> Unit193: thanks
[05:56] <Unit193> (I don't have that script and don't have core dev permissions anyway.)
[05:57] <gioele> hi, what is the right way to close a bug in launchpad that has been fixed upstream, in debian, and in lunar?
[05:57] <gioele> this one: https://bugs.launchpad.net/ubuntu/+source/bats/+bug/1882542
[05:57] -ubottu:#ubuntu-devel- Launchpad bug 1882542 in bats (Ubuntu) "regression: 8789f9108 broke environment-variable preservation" [Undecided, Fix Committed]
[06:02] <zhsj> Unit193: the script is at https://git.launchpad.net/ubuntu-archive-tools (iirc there's a discussion to move that to ubuntu-dev-tools)
[06:04] <zhsj> gioele: is the bug affects 1.2.0 and after, which means jammy and kinetic are broken?
[06:07] <gioele> zhsj: it even affects focal's version of bats
[06:08] <Unit193> zhsj: Right, though as noted I have 0 permissions on anything in main (except irssi!)
[06:09] <zhsj> ginggs: i have updated the bug status to indicate that focal, jammy, kinetic are affected
[06:10] <zhsj> gioele: ^ (sorry ginggs..)
[06:11] <Unit193> zhsj: FWIW, I retried what I could.
[06:13] <zhsj> Unit193: thanks, i think these packages are all in universe, so it should be enough
[06:16] <gioele> zhsj: thanks. So the bug will remain open with status "Fix released" until kinetic is no longer supported, right?
[06:17] <zhsj> gioele: hmm, the bug is closed since it's fixed in latest release (mantic)
[06:19] <zhsj> https://bugs.launchpad.net/ubuntu/+source/bats has no bug. but https://bugs.launchpad.net/ubuntu/focal/+source/bats has.
[06:20] <gioele> zhsj: Oh, I see. I only refreshed the bug page and not looked at the list of open bugs. Got it, thanks!
[06:21] <Unit193> o/
[06:53] <zhsj> sigh, i think the autopkgtest regressions vim-youcompleteme & ycmd with golang-defaults are real...
[06:54] <Unit193> Urgh.  Condolences.
[06:57] <zhsj> but they pass on Debian...
[07:02] <zhsj> could someone retry the build https://launchpad.net/ubuntu/+source/ycmd/0+20230611+git3392251+ds-1/+build/26333790 (llvm 15 install problem, but i think it should be sorted out)
[08:06] <utkarsh2102> zhsj: successfully built now^
[08:07] <zhsj> utkarsh2102: yeah, someone triggers that
[08:07] <utkarsh2102> zhsj: has someone triggered those tests for you? or do you want me to do something?
[08:07] <utkarsh2102> "./retry-autopkgtest-regressions --blocks golang-defaults"
[08:09] <zhsj> utkarsh2102: all have been triggered.
[08:32] <liushuyu> Hi there, is any AA available to help me with the removal of the `cargo` source package from the primary archive? The `cargo` source package has been merged into `rustc` source package (you can see it here: https://launchpad.net/ubuntu/+source/rustc/1.68.0+dfsg0ubuntu1-0ubuntu1)
[08:33] <liushuyu> Thank you in advance!
[08:55] <seb128> liushuyu, you probably want someone from the release team to let the cargo autopkgtest result ignored so it can migrate to mantic
[08:55] <liushuyu> seb128: will do
[08:55] <seb128> removing cargo from mantic before the new rustc migrate seems wrong, it would mean mantic have no cargo anymore until the update manage to migrate
[08:56] <liushuyu> Then should I just wait for the autopkgtest first?
[08:59] <seb128> liushuyu, checking https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html#rustc the cargo ones are red
[09:06] <liushuyu> "badpkg: rules extract failed with exit code 1" Looks like it already caused some issues
[09:09] <seb128> liushuyu, which is why I say you need to ask the release team to skip those tests
[09:10] <liushuyu> seb128: Ah, I see. I mis-understood your previous statement. I will inform a release-team member after most of the other tests are finished
[09:12] <seb128> liushuyu, why waiting? it's clear that cargo isn't going to work and will need an override...
[09:13] <liushuyu> seb128: I want to see the results of other packages. Because after this change, our rustc version will be far ahead of Debian, which may cause some issues
[09:14] <seb128> liushuyu, I'm curious but did we document somewhere the rational for diverging from Debian and merging those sources?
[09:14] <liushuyu> seb128: Yes, it's a Foundations spec
[09:14] <seb128> liushuyu, overriding the cargo tests result isn't going to make a difference on other tests, the package is still going to wait and depends on results from those
[09:15] <seb128> it isn't going to migrate before all return and are green
[09:15] <liushuyu> Basically, the `cargo` package is not meant to be packaged out-of-tree. The proper way to do this is to build `rustc` and `cargo` in the same source tree
[09:15] <seb128> any chance to convince Debian to do the same? ;-)
[09:15] <liushuyu> seb128: I am currently working on that
[09:15] <seb128> great
[09:16] <liushuyu> seb128: Thank you. I will do that in a moment
=== sammy12 is now known as frillyturtle
[13:27] <danilogondolfo> Can someone run this for me please? https://autopkgtest.ubuntu.com/request.cgi?release=mantic&arch=amd64&package=libwww-mechanize-perl&trigger=libwww-mechanize-perl/2.17-1&trigger=libwww-perl/6.71-1
[13:39] <ginggs> danilogondolfo: .
[13:39] <danilogondolfo> ginggs, thanks!
[13:40] <ginggs> de nada
[13:47] <enr0n> I am looking for a sponsor for bug 2025291 and bug 2025279
[13:47] -ubottu:#ubuntu-devel- Bug 2025291 in mlpack (Ubuntu) "mlpack: FTBFS: mkdir: cannot create directory ‘/usr/lib/python3.11/site-packages/’: Permission denied" [Undecided, New] https://launchpad.net/bugs/2025291
[13:47] -ubottu:#ubuntu-devel- Bug 2025279 in triton (Ubuntu) "triton 2.0.0.post1-3 FTBFS" [Undecided, New] https://launchpad.net/bugs/2025279
[16:36] <bdmurray> @pilot in
=== ChanServ changed the topic of #ubuntu-devel to: Archive: Mantic Open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Bionic-Lunar | Patch Pilots: bdmurray
[17:09] <bdmurray> sarnold: Do you remember which ubuntu-release-upgrader bug related to losing your session and something about dbus?
[17:10] <bdmurray> Ah, I found it.
[18:48] <sarnold> bdmurray: hah, I don't remember that at all :(
[18:50] <bdmurray> bug 1968845
[18:50] -ubottu:#ubuntu-devel- Bug 1968845 in dbus (Ubuntu) "Upgrade to 22.04 from 20.04 ends with dbus installation asking for a reboot" [High, Triaged] https://launchpad.net/bugs/1968845
[18:58] <hcoin>  Hi everyone!  Many Ubuntu 'official' webpages appear when I look for a 'walkthrough' of the basic cycle: 'get an ubuntu kernel source package, fix one bug, make a changlog entry, then package it up'.  Can someone tell me where 'the latest latest' is for that?  (Jammy)
[19:04] <sarnold> bdmurray: oh yeah! thanks
[19:04] <sarnold> hcoin: there might not be recent documentation for that task
[19:09] <hcoin> sarnold: Reminds when I asked someone in a small town near Boston, MA how to get to another small town near there.  The answer was "I don't think you can get there from here".
[19:09] <sarnold> hcoin: *nod*
[19:10] <hcoin> I wish the Canonical people would at least put 'deprecated' or dates on their 'official instruction' web pages.  Now the only hint I get to 'not bother reading further' is when the author uses a release name from 2014.
[19:12] <bdmurray> hcoin: Are you specifically looking at fixing a kernel bug?
[19:12] <sarnold> yeah, the fact that the wiki was too painful to use for a few years damaged a *lot* of docs :(
[19:13] <hcoin> Yet they persist.  For example I was instructed by Ubuntu to visit the #ubuntu-kernel channel for this.  There is exactly 0 traffic other than my question for some hours.
[19:14] <hcoin> I posted the question on Reddit/ubuntu, so far 465 people have 'viewed it' (how many are bots and how many are people?)  0 responses.
[19:14] <sarnold> yeah, that channel can be dead for weeks on end
[19:15] <sarnold> it's just the case that working with distro kernels is *heavy* lifting. it's not easy to work with our kernel packages, those have been optimized to manage dozens of different requirements for different environments
[19:15] <hcoin> So anyway I've been supporting ubuntu for a while, use it often, and now I need to fix a kernel bug.   It's not a big deal.  I know how to debug the kernel.
[19:16] <sarnold> it's probably not realistic for end-users to work with our kernel packages
[19:16] <hcoin> Yeah, well I've only been doing kernel code since ;
[19:16] <hcoin> well.. 1980 something.   I just need 'the ubuntu way'.
[19:17] <sarnold> this is the best I know, and I don't know if it still works https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
[19:17] <hcoin> Thanks, it's one lead more than I had.   All I need to do is fix one bug for one arch and that's that.
[19:18] <bdmurray> I also found this https://wiki.ubuntu.com/Kernel/Dev/KernelGitGuide
[19:19] <hcoin> The 'kernel git guide' lacks just one thing:  How to turn it into a set of .deb files.
[19:20] <sarnold> lol
[19:20] <hcoin> Found a bug that breaks STP when network bridges are in a net namespace.  Generates packet storms.  Easy fix.  Just looking for 'ubuntu packaging mechanics'.
[19:20] <sarnold> man, so close and yet so far
[19:22] <hcoin> Yeah, tried 'dpkg-buildpackage' and 'dch ...'   and -nc .... it happily wipes out the changelong.  Ooops.
[19:24] <hcoin> BTW if you don't chmod 0666 the README file in the .../test_build directory from the 'official sources' -- it won't build.
[19:25] <hcoin> Notice the 'buildyourownkernel' was written when the release was 'disco'.
[19:26] <hcoin> The 'skipdbg' flag mentioned there is treated as an error now, preventing the build.
[19:26] <sarnold> hah, it was probably just *updated* when the release was disco. I bet most of it long predates that.
[19:28] <hcoin> I'm also pretty sure 'fakeroot' is built in now, as well.  There's got to be some page somewhere (git) where actual people who do this all the time have a walkthrough.
[19:35] <sarnold> hcoin: the kernel team uses https://git.launchpad.net/~canonical-kernel/+git/kteam-tools/tree/ to manage the dozens of trees
[19:36] <sarnold> hcoin: this thing describes all the trees and omg .. https://git.launchpad.net/~canonical-kernel/+git/kteam-tools/tree/info/kernel-series.yaml
[19:36] <hcoin> The official guide... instructs to use commands current code rejects as unrecognized (skipdbg...) and also some nebulosity between 'debian.master/changelog' and 'debian/changelog'.    Also the 'editconfigs' thing that results in a .config file seems to have been replaced with some half-a-database-in-json thingy.
[19:37] <hcoin> Oh good, yet another yaml file.  Right up there with 'yama, becoming mindful'.
[19:38] <hcoin> I can't be the only poor guy with tens of thousands of lines of code to manage, that just has to fix one stupid bug in the kernel for one arch and be done.
[19:39] <hcoin> Not looking to save the world, manage 100 trees, or even convince anyone my change is worth the price of a coffee.
[19:42] <hcoin> And, you know, with the cost of a 'vm' being almost zero, is there really any need for 'fakeroot' any longer?   Just cook up a VM that does one thing, log in as root there, map it to whatever host file tree you want and...'
[20:50] <bdmurray> @pilot out
=== ChanServ changed the topic of #ubuntu-devel to: Archive: Mantic Open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Bionic-Lunar | Patch Pilots: N/A