[09:06] @pilot in === ChanServ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: juliank [10:00] Could somebody, please, explain the meaning of "[MANUALDEPWAIT]" shown on a build (https://launchpad.net/ubuntu/+source/pytorch/2.0.1+dfsg-5/+build/26922141). [10:06] xypron: I'm not seeing the string in question, rather a standard "missing build dependencies" status (confirmed by rmadison libsleef-dev, only published on x86* and arm* in Ubuntu) [10:12] schopin: the label seems to be gone. If you search on Google with: "[MANUALDEPWAIT]" site:launchpad.net , you will find that the label appears frequently. [10:14] Oh, it's the alt text of the icon for the Dependency wait status! [10:23] schopin: no, we need rustc-1.73 for new kernels in noble. when will that be available for us to upgrade? [10:37] xnox: thanks for the reminder, I'll upload it to NEW in a few minutes and try to find an AA to process it before I update the generic rustc to 1.73. [10:38] schopin: yes please. i still don't know why you don't bootstrap each one as versioned one first; as it makes it easier to have them all in the same ppa, and then bootstrap unversioned one as needed. [10:39] (because if rustc-bootstrap ppa only has all of rustc-1.NN surely it makes it easier to rebootstrap all of them) [10:39] even if the archive only ships select rustc-1.NN and select unversioned rustc [10:41] oh I agree, it's just a matter of actually taking the time to switch gears. I think Zixing is working on that (last comment on the relevant card is "blocked waiting for all the pending Rust updates") [11:10] xnox: sorry, slight delay on rustc-1.73, I'm missing some pieces, this'll have to wait until Zixing's morning. [12:27] need help please.. zeitgeist is passing the tests in Debian but one of the test is failing in Ubuntu. It used to fail in Debian also but that has been fixed since Jan'2022. the build log is at https://launchpadlibrarian.net/702673539/buildlog_ubuntu-noble-amd64.zeitgeist_1.0.4-5ubuntu1_BUILDING.txt.gz [12:27] any idea what I should be looking for? [12:33] I rebuild openafs on mantic against heimdal-to-be-proposed (so, from a ppa of mine by now), but It's complaining about unmet dependencies [12:33] because the Depends: ${shlibs:Depends}, ${misc:Depends} is converted on Depends: libroken19-heimdal (= 1.8.10-1ubuntu2.1) [12:34] but that version is openafs version, not heimdal [12:35] I'm wondering if the change I introduced in the symbols file for libroken is the cause [12:35] -libroken.so.19 #PACKAGE# #MINVER# +libroken.so.19 #PACKAGE# (= ${binary:Version}) [12:36] (it looks like it, to me) [12:37] any idea/clue/hint about this, please? [12:38] _playing with that in the meantime_ [12:42] mirespace: yes, I don't think that syntax will work for the symbols file [12:45] jbicha: mmm... that worked in the krb5 case maybe because the symbols were not used outside the src:krb5? [12:46] mirespace: maybe adding a Build-Depends-Package line could help: https://salsa.debian.org/gnome-team/gegl/-/blob/debian/latest/debian/libgegl-0.4-0.symbols [12:46] jbicha: Thanks! Trying... [12:48] oh, I didn't realize krb5 uses something like that for mantic, I had never seen that syntax in a symbols file [12:49] me neither, but I was using that as reference for fixing heimdal, but is true that krb5 don't have the external affected packages as heimdal [14:32] doko: I think there might be an issue with the new dpkg build flags in Noble. I'm seeing this kind of errors in a package that was buildling fine a couple of days ago: [14:32]

: error: "_FORTIFY_SOURCE" redefined [-Werror] [14:32]

: note: this is the location of the previous definitio [14:33] ravikant_: FYI, the package in question is your ltrace MP ;) [14:37] arraybolt3, satpy ping... testsuite failures :/ [15:09] mirespace, do you have a list of applications needing a rebuild? === leftyfb_ is now known as leftyfb [15:12] we need to break them [15:12] (and rebuild) [15:31] LocutusOfBorg: It's only openafs [15:31] so we need to break old openafs build and upload a no change rebuild [15:31] I opened a bug for it (bug 2046441) [15:31] -ubottu:#ubuntu-devel- Bug 2046441 in openafs (Ubuntu Noble) "aklog: symbol lookup error: aklog: undefined symbol: rk_strlcat, version HEIMDAL_ROKEN_1.0" [Undecided, New] https://launchpad.net/bugs/2046441 [15:31] ybut on noble is now FTBFS for other reasons [15:34] LocutusOfBorg: yes, you're right... not only the two libraries libafs*, also the binaries deployed by other openafs binary packages [15:34] I have that list... Putting that on the bug [15:34] the heimdal one, I mean [15:35] also please put a new debdiff with the correct breaks on libraries affected [15:35] so we force people to upgrade them together... [15:35] btw for me the mantic SRU is useless / risky [15:35] transitions done in stable are painful [15:35] and this looks really a transition [15:36] it has now the Breaks for the libraries, but not for the /usr/bin/* that uses the symbols [15:36] I'll do the changes and I'll ping you again [15:36] yes... and unexpected transition hehehe [15:37] jbicha, mirespace: Can't help with heimdal, but krb5 does have at least one "private" symbol that's used outside of it... nfs-tools inlines `_krb5_gss_ctx_id_rec`: https://sources.debian.org/src/nfs-utils/1:2.6.4-2/utils/gssd/context_mit.c/?hl=58#L58. Just spreading the knowledge. [15:37] UnivrslSuprBox: Thank you! [15:52] need to afk ... I'll come later [16:36] schopin, happens also for libheif [16:36] the FORTIFY thing? [16:36]

: error: "_FORTIFY_SOURCE" redefined [-Werror] [16:36] yes [16:38] schopin, does this mean we have to rebuild gcc with the new FORTIFY_SOURCE= [16:38] ? [16:38]

: note: this is the location of the previous definition [16:38] don't know what means, is it glibc/gcc? [16:38] doko, ^^ you might want to know this... [16:38] gcc is my guess, glibc defines have an actual file as a source. [16:39] I agree with your guess [16:39] this is why I pinked Matthias [16:39] *pinged [17:14] LocutusOfBorg, schopin: this is most likely because of the mismatch in definitions for _FORTIFY_SOURCE. it should be fixed after the next gcc upload. Or build without -Werror [18:29] thanks for the clarification [18:30] ahasenak: Thank you for looking at the maven issue. I have updated the debdiffs - fixed the version and the encoding. [18:33] vpa1977: ah, hello [18:34] was just about to ping you, after I looked at the time and did some timezone calculations [18:34] uh, still early for you, is it 7h34? [18:34] =) [18:35] I'm definitely not an early bird, and am always amazed at how early many people start their days [18:35] I am on vacation, just keeping the inbox clean daily =) [18:36] hehe [18:42] vpa1977: you need sponsoring? [18:46] ahasenack: yes [18:46] ok, I think I can do that without a conflict of interest, since it's just a d/changelog fixup [18:46] Thank you!!!! [18:49] fossfreedom_: Do you have any insights re: bug 2046386? [18:49] -ubottu:#ubuntu-devel- Bug 2046386 in livecd-rootfs (Ubuntu) "Ubuntu Studio images aren't being built with a live user" [High, New] https://launchpad.net/bugs/2046386 [18:58] LocutusOfBorg: Grief, again? I built and autopkgtested it against proposed even, IIRC. Sigh, this is one tough package... [18:58] re satpy [18:59] Oh, interesting. Packages in -proposed aren't being used in the autopkgtest. [19:00] Ok, time for AA assistance. [19:02] sorry arraybolt3 do you need trigger with all-proposed? [19:03] (done now) [19:05] Oh, that would likely work. Thanks! [19:05] Eickmeyer lukasz added this for us. Guess you need something similar? [19:05] https://git.launchpad.net/~mwhudson/debian-cd/+git/ubuntu/tree/tools/boot/mantic/common.sh?h=a-bit-less-hardcoding&id=ac37446391574e6c4f25dee816e82ffb1e55c70b [19:06] Pretty sure the recent failures are from https://github.com/pytroll/satpy/pull/2640, the new trollimage is in proposed but is stuck on satpy, which is in turn stuck on trollimage :P [19:06] -ubottu:#ubuntu-devel- Pull 2640 in pytroll/satpy "Keep original dtype in DayNightCompositor" [Merged] [19:07] fossfreedom_: That's huge. Thanks! [19:07] @pilot in === ChanServ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: tsimonq2, juliank [19:07] arraybolt3: Whaaatcha doin'? :P [19:08] tsimonq2: fighting with satpy [19:08] tsimonq2: I read that in what's-her-name from "Phineas and Ferb"'s voice. [19:08] My upload was good I believe, but I forgot that autopkgtests triggered by Britney don't include proposed packages in them by default. [19:09] arraybolt3: all-proposed or similar? [19:09] Eickmeyer: hahahah someone's cultured :D [19:09] Yep. That's what LocutusOfBorg just did. [19:09] Cool :) [19:23] @pilot out === ChanServ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: juliank [19:25] tsimonq2 flying a puddle jumper for his 15 minute flight. [19:25] Eickmeyer: Well, the queue just hit zero, I have nothing else to do! [19:26] hehe [19:26] * tsimonq2 watches as 15 lines show up on the next refresh... :P === smoser1 is now known as smoser [20:40] @pilot in === ChanServ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: tsimonq2, juliank [20:40] Well, there's two already. :D [20:44] Eickmeyer: Looks like you've done some recent bug status updates for src:impressive / bug 1969968 - you got it? [20:44] -ubottu:#ubuntu-devel- Bug 1969968 in impressive (Ubuntu Jammy) "[SRU] impressive segfault" [Undecided, New] https://launchpad.net/bugs/1969968 [20:45] @pilot out === ChanServ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: juliank [20:45] tsimonq2: Yeah, just helped out someone in #ubuntu-bug asking for the targeting, wasn't going to do much otherwise. Looks like an SRU. [20:45] s/#ubuntu-bug/#ubuntu-bugs/ [20:46] Eickmeyer: I'll give it a few hours to see if that person follows up appropriately; if not, I will. [20:46] tsimonq2: It was sudip, who is in here. [20:46] * sudip is here, do I need to do anything for that? [20:46] debdiff is already attached [20:49] tsimonq2: Thanks for the sponsorship! [20:49] sudip: Hey, so I was confused on the bug status, got that sorted out. [20:50] sudip: I'm reviewing your diff right now: two things that stick out immediately are the version number and the non-DEP-3 compliant header. [20:51] sudip: If you're available to fix those and provide a new diff, cool, otherwise I can fix up and upload. :) [20:51] (I can also provide links if you need more information.) [20:52] version numbers in Ubuntu always confuses me, if you have some link to know more about it, that will be really great [20:52] cpete: Of course! If I end up sponsoring enough of your uploads, let me know when your application comes through. ;) https://udd.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=&sponsor_search=name&sponsoree=Chris+Peterson&sponsoree_search=name [20:53] !sru | sudip: Check the links to the security team here under version numbers [20:53] sudip: Check the links to the security team here under version numbers: Stable Release Update information is at https://wiki.ubuntu.com/StableReleaseUpdates [20:53] sudip: Sure! So, the short version is, the version you have is fine, if it's an upload for the development release. [20:53] sudip: Erich's link is good, I'll also provide https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging as a good reference. [20:54] (We should *really* change dch to automatically do that "the right way" if the upload targets a known stable or ESM release...) [20:54] Anyway, you [20:54] *'re *almost* there. Just need to make it 0.1, or similar. [20:55] tsimonq2: dch is intelligent enough, you'd think it could handle a little nuance like that. [20:55] (Just as a force-of-habit general rule of thumb I can apply everywhere, I usually do e.g. 0.22.04.1 for Jammy, just in case I miss that the version in another stable release is the same.) [20:55] * sudip did 0.1 initially and then changed to 1 after seeing another upload [20:56] sudip: That may have been correct for that upload: the key question here is, *where* is it going? :) [20:57] tsimonq2: this is a really cool tool I didn't know existed. I will certainly let you know, thanks :) [20:58] sudip: Anyway, the only other point I have (that's also specific to SRUs) is, given Erich's link above, could you potentially increase the verbosity of the SRU template? [20:58] It doesn't have to be a huge essay, but one or two sentences uuuuuusually doesn't do the trick WRT acceptance from the queue. [20:58] cpete: Happy to help :) and thank *you* for your work! [20:59] s/template/information/ ~= [21:01] tsimonq2: sure, let me try write something, about the dep3 headers.. can you please point out what I missed.. I guess you are thinking about the origin [21:02] sudip: Sounds good, let me know how I can help! [21:02] Sort of, let me explain. :) [21:03] DEP-3, as you probably know, is a standard for patch headers in Debian: https://dep-team.pages.debian.net/deps/dep3/ - that's the reference page. [21:03] If I happen to see a key that's non-standard, I'll usually fix it/upload, every once in a while I'll ignore it. :P [21:04] ahh.. right.. so you mean the notes... [21:04] The wider point that applies to your patch is, typically patch headers are separated from the actual diff by a single newline. There really shouldn't be any newlines between DEP-3 headers, simply so it doesn't confuse some tools. [21:04] Re: notes, yeah, minor point. Standard is probably Comment or something, heh. [21:04] (Oh, right, it's Description.) [21:13] s/newline/empty newline/g (probably makes that clearer) [21:20] tsimonq2: added modified debdiff now. [21:23] * sudip checks https://udd.debian.org/cgi-bin/ubuntu-sponsorships.cgi and sees waveform and sergiodj are having a close competition as my sponsor [21:29] :D [21:29] sudip: Got caught up in a conversation, looking now. [21:34] sudip: Uploaded with minor patch tweaks :) [21:35] cpete, sudip: Another cool link: https://raphaelhertzog.com/2012/08/08/how-to-use-quilt-to-manage-patches-in-debian-packages/ [21:36] Eickmeyer: I just realized that sudip is the author of that kernelshark upload I sponsored. ;) [21:38] thanks tsimonq2 [21:38] tsimonq2: do do do do do do [21:38] sudip -- heh, afraid I'm a bit busy with other maintenance bits this evening, but it looks like you're in good hands! [21:38] but what patch tweaks? usually I will test with "quilt push -a --fuzz=0" [21:39] waveform: np, I will have another SRU tomorrow :) [21:39] if noble syncs from Debian tonight [21:40] :)) [21:40] sudip: Here's what it looks like now (forgive me IRC mods, for I am about to sin): [21:40] Description: Find correct library based on pygame sdl version I could not find any upstream repo for impressive, source downloads are available. So, considering Debian source for this change. [21:40] Origin: upstream, https://sources.debian.org/src/impressive/0.13.1-1/impressive.py/#L416 [21:40] Bug-Ubuntu: https://launchpad.net/bugs/1969968 [21:40] -ubottu:#ubuntu-devel- Launchpad bug 1969968 in impressive (Ubuntu Jammy) "[SRU] impressive segfault" [Undecided, New] [21:40] --- [21:41] So essentially, I just moved those two lines up and above the --- [21:41] There is an empty newline between that and the start of the header. [21:41] sudip: Does that make sense? :) [21:43] hmm.. looks like I have missed "A line containing 3 dashes (---) should stop the parsing: lines after it are not relevant part of the meta-information." in **all** my patches ;( [21:44] thanks a lot tsimonq2 [21:45] sudip: Out of any mistake you can make in Ubuntu Development, patch headers are one of the more minor ones. [21:45] That being said, I'm happy to help, and I'm glad you understand the changes made :) [23:05] * arraybolt3 calls ops on tsimonq2 for flooding /s