[01:11] <dannf> jbicha: juliank: fyi, that kdump-tools autopkgtest failure on arm64 should be fixed now. i think it was only passing before because it was being skipped due to limited memory
[06:34] <adrien> UnivrslSuprBox: in noble it will be fixed soon for armhf
[06:35] <adrien> for i386 it won't but I think it would be more appropriate to remove it from there
[06:35] <adrien> for that we need to know what it is used for: do you know?
[06:35] <adrien> also, if it's only tests, we can hint these so they're not affecting migrations
[06:35] <adrien> (non-build-time tests that is)
[08:44] <bastif> Could someone merge php-codeigniter-framework from Debian to Ubuntu? It includes the patches suggested by an Ubuntu developer. See https://bugs.launchpad.net/ubuntu/+source/php-codeigniter-framework/+bug/2054713
[08:48] <bastif> (fix ftbfs with python3.12 & php8.3)
[08:56] <LocutusOfBorg> sgmoore, hello, ksanecore needs an update :)
[08:56] <LocutusOfBorg> libkf5sane needs it :D
[09:03] <ginggs> bastif: re php-codeigniter-framework, do you mean merge or sync?
[09:05] <bastif> what's the difference? I mean take the version of Debian and put it into Ubuntu?
[09:06] <bastif> the package is listed in merge-o-matic, so I guess autosync won't work?
[09:10] <LocutusOfBorg> bastif, ginggs syncd
[09:15] <ginggs> bastif: merge would be if there were ubuntu changes to be kept, sync means manual sync, like LocutusOfBorg just did
[09:16] <bastif> ok, sync then.
[09:26] <sgmoore> LocutusOfBorg: looking into it, thank you
[09:31] <sgmoore> LocutusOfBorg: Seems I do not have upload rights to some of the newer packages. Will have to wait for someone with fancier upload rights to upload. SOmething I intend to fix once things settle down.
[09:42] <LocutusOfBorg> sgmoore, if you need sponsoring, ping
[09:43] <sgmoore> LocutusOfBorg: yeah, I think everyone is asleep
[09:47] <sgmoore> LocutusOfBorg: packaging is here: https://code.launchpad.net/~kubuntu-packagers/kubuntu-packaging/+git/ksanecore/+ref/kubuntu_noble_archive
[09:49] <LocutusOfBorg> uscan to download, right?
[09:49] <LocutusOfBorg> sponsored
[09:49] <LocutusOfBorg> Uploading ksanecore_23.08.5-0ubuntu1_source.changes
[09:50] <bluca> is there a specific team that looks after dpkg? I see many signatures in the changelog
[09:50] <bluca> it would be really great if lp:2054741 could get fixed in noble - MR with fix is attached to the bug
[09:50] -ubottu:#ubuntu-devel- Launchpad bug 2054741 in dpkg (Ubuntu Noble) "dpkg-buildpackage ignores DEB_BUILD_PROFILES" [Undecided, Confirmed] https://launchpad.net/bugs/2054741
[09:51] <LocutusOfBorg> bluca, is this a bug in Debian?
[09:51] <bluca> no, it's a bug in the ubuntu delta
[09:51] <LocutusOfBorg> ack sponsoring
[09:52] <bluca> more precisely side effect of this bit of delta in dpkg-buildpackage.pl:
[09:52] <bluca> -set_build_profiles(@build_profiles) if @build_profiles;
[09:52] <bluca> +set_build_profiles(@build_profiles);
[09:52] <bluca> thanks!
[09:53] <LocutusOfBorg> and instead, can't we drop that part of delta?
[09:54] <bluca> it's the patch that always appends the noudeb profile to every build, unless opted-out
[09:55] <bluca> it's necessary for that - I don't know whether that functionality is still needed or not
[09:57] <bluca> the fix in the MR ensures that still works as before
[10:05] <LocutusOfBorg> ok thanks
[10:06] <LocutusOfBorg> however the test can be upstreamed in Debian?
[10:11] <LocutusOfBorg> https://launchpadlibrarian.net/715739490/buildlog_ubuntu-noble-amd64.dpkg_1.22.4ubuntu4_BUILDING.txt.gz
[10:11] <LocutusOfBorg> bluca, ^^
[10:21] <bluca> the test might, yes
[10:21] <sgmoore> LocutusOfBorg: thanks!
[10:22] <bluca> Parse errors: Bad plan.  You planned 11 tests but ran 10.
[10:22] <bluca> the MR contains this bit:
[10:22] <bluca> -use Test::More tests => 10;
[10:22] <bluca> +use Test::More tests => 11;
[10:23] <bluca> for scripts/t/Dpkg_BuildProfiles.t - did that get lost by any chance?
[10:23] <bluca> oh wait it's the opposite
[10:28] <bluca> aaagh I screwed up the cherry pick
[10:32] <bluca> I refreshed the branch before as it was behind ubuntu/devel, except I used the wrong one (based on jammy), my bad
[10:36] <bluca> fix: https://code.launchpad.net/~bluca/ubuntu/+source/dpkg/+git/dpkg/+merge/461112
[10:37] <bluca> corrected full patch if preferred: https://code.launchpad.net/~bluca/ubuntu/+source/dpkg/+git/dpkg/+merge/461113
[10:40] <dviererbe> Can someone sponsor these merge proposals:
[10:40] <dviererbe> https://code.launchpad.net/~dviererbe/ubuntu/+source/unzip/+git/unzip/+merge/444896
[10:40] <dviererbe> https://code.launchpad.net/~dviererbe/ubuntu/+source/inetutils/+git/inetutils/+merge/461107
[10:46] <bluca> LocutusOfBorg: did a new test run in a new, clean noble chroot with the fix from above, build passes now - sorry for the snafu
[10:59] <LocutusOfBorg> good catch bluca
[10:59] <LocutusOfBorg> I also didn't spot it
[11:23] <LocutusOfBorg> dviererbe, ack
[11:23] <dviererbe> LocutusOfBorg: thanks!
[11:29] <adrien> bryyce: I just had a case of several builds in a PPA because I pushed two consecutive versions fairly quickly so it's a case that is difficult to avoid even when paying attention (I'm not using my output-rewriting script ATM: it seems it has a few corner cases and it was only meant as a demo/PoC)
[11:38] <LocutusOfBorg> sgmoore, https://launchpadlibrarian.net/715743773/buildlog_ubuntu-noble-riscv64.kimap_23.08.5-0ubuntu1_BUILDING.txt.gz
[11:38] <LocutusOfBorg> looks like test is not built on riscv64
[11:38] <LocutusOfBorg> dh_install: warning: Cannot find (any matches for) "usr/lib/*/libkimaptest.a" (tried in ., debian/tmp)
[11:38] <LocutusOfBorg> qt5tests is not there...
[11:44] <sgmoore> Correct, I have had to fix quite a few. I will fix it shortly. Thanks
[13:03] <ravikant_> Hello o/, where is the code for https://launchpad.net/pkg-website (http://packages.ubuntu.com/)?
[14:02] <sudip> ravikant_: https://salsa.debian.org/webmaster-team/packages/-/tree/ubuntu-master
[14:20] <sudip> can anyone please retrigger the build of vtun in jammy-proposed for riscv64.
[14:46] <ravikant_> sudip: thanks!
[14:52] <bluca> LocutusOfBorg: thanks for the noble upload - any chance we can also do a backport to jammy? https://code.launchpad.net/~bluca/ubuntu/+source/dpkg/+git/dpkg/+merge/461136
[14:54] <LocutusOfBorg> ack done
[14:54] <LocutusOfBorg> bluca, also mantic is on your radar?
[14:56] <Trevinho> vorlon: hey, FYI in the debian side of power profiles daemon I marked it as conflicting with tlp (that one is too powerful not to be) again, so if you want patch it on ubuntu side feel free but imho it would be just easier to add a compatibility layer on the dbus side to just be able to manage it from gnome side.
[14:57] <Trevinho> vorlon: Also... One question, isn't there any dh fancy sequence for pam-auth-update, right?
[14:57] <LocutusOfBorg> U0m doing it
[14:59] <bluca> LocutusOfBorg: thanks - I don't usually look at short term releases as I just don't use them - if really necessary for process reasons I can
[14:59] <LocutusOfBorg> I uploaded also mantic
[14:59] <LocutusOfBorg> meh
[14:59] <LocutusOfBorg> not sure worth the effort
[15:00] <LocutusOfBorg> I think non lts are just a waste of time for SRUs
[15:00] <bluca> I agree - thanks for the help
[15:29] <bluca> juliank: it seems apport autopkgtest is failing to due bash moving to /usr/bin: https://objectstorage.prodstack5.canonical.com/swift/v1/AUTH_0f9aae918d5b4744bf7b827671c86842/autopkgtest-noble/noble/amd64/a/apport/20240223_131926_86bf6@/log.gz
[15:30] <bluca> just noticed when looking at some unrelated package
[15:30] <UnivrslSuprBox> adrien: It is build-time tests (dh_auto_test). faketime is a build-depend of some things in i386.
[15:34] <adrien> UnivrslSuprBox: do you know what does?
[15:41] <juliank> bluca: heh this only happened after bash migrated of course
[15:43] <juliank> bdrung: apport needs adjustment for bash move to /usr/bin/bash ^^
[16:23] <UnivrslSuprBox> adrien: looks like it's a depends of epoptes, recommends of reprotest, and suggests of devscripts. I actually don't see any build-depends on i386, but that might be because 'apt rdepends' doesn't check that...
[16:34] <UnivrslSuprBox> `reverse-depends -a i386 -b faketime` reveals quite a few things
[16:36] <adrien> I was looking at that too and there are many more than I had hoped
[16:36] <adrien> altos devscripts doxygen festival gem2deb genometools jags katarakt mcabber moon-buggy osslsigncode postsrsd pyscanfcs rsyslog sssd xapian-omega
[16:37] <adrien> the three or four I've looked at are not easy to make optional
[16:37] <adrien> maybe the only solution is to change coreutils to use 32-bit time_t on i386
[16:38] <adrien> or skip the test in faketime's build but I expect we'd have issues down the road
[16:39] <adrien> vorlon: does it sound good to you that i386 coreutils use a 32-bit time_t again? this should fix faketime's build and would probably be more compatible with the rest of the packages
[16:41] <UnivrslSuprBox> I mean, we can override dh_auto_test to skip it on i386, it's just armhf that's a problem then.
[16:41] <UnivrslSuprBox> It's a question of how long we need to wait for armhf to, uh, work
[16:41] <adrien> armhf will be fixed soon when the 64-bit time_t transition happens; or at least I don't think it's wise to spend time on it right now
[16:42] <adrien> armhf is a matter of days hopefully
[16:43] <adrien> but I don't think skipping the test is necessarily a good idea as you would end up with an ecosystem of packages where a single package has a different notion of time_t
[16:43] <UnivrslSuprBox> But Steve's made it pretty clear that we shouldn't care about i386 basically at all
[16:44] <adrien> if some package then does "faketime year-3000 date" and "faketime year-3000 my-own-implementation-of-date", you'd get different results (sure, the second one is a bug but fixing the y2038 on i386 isn't a goal anyway)
[16:45] <adrien> IIRC there's a configure switch to change time_t for coreutils so it's not a lot of work (I can probably look at that next week)
[16:45] <adrien> well, maybe there isn't, but we can probably do something
[17:22] <juliank> base-files and glibc should land next britney run, everyone brace yourselves
[17:46] <vorlon> adrien: whenever someone asks me a question like this, my first response is to check why we're messing around with a package like faketime at all and if we can throw it away on i386.  I care about i386 not *blocking* faketime but otherwise I don't care whether faketime itself is usable on this arch
[17:46] <vorlon> I also don't care what size time_t coreutils uses on i386
[17:46] <vorlon> so: whichever solution is less work?
[17:47] <vorlon> faketime                              | faketime                           | ocl-icd (Build-Depend)                     | Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>      |           11034 |              41
[17:47] <vorlon> yah super invested in this (not)
[17:48] <vorlon> nobody needs an i386 version of opencl :P
[17:49] <vorlon> adrien: how about patching libwine instead to not want ocl
[17:55] <adrien> vorlon: I'm fine doing that; it looks like I didn't generate the list of packages well; can you share the commands you used?
[17:55] <adrien> (is that really the only thing that requires it?)
[17:55] <vorlon> adrien: I was looking at https://ubuntu-archive-team.ubuntu.com/germinate-output/i386.noble/all
[17:55] <vorlon> it's not guaranteed that this is the only thing that requires it, but there's a reasonable chance this is so
[17:56] <vorlon> germinate unfortunately does not produce full graphs, it truncates on first match
[17:56] <vorlon> juliank: ^ ;)
[17:56] <adrien> good to know
[17:56] <adrien> I don't have time right now; I'll be back a bit later
[18:39] <bluca> apport autopkgtest failing due to bash moving is affecting dpkg's migration in noble, could that be hinted through please?
[18:43] <juliank> Please force-badtest apport/2.28.0-0ubuntu1
[18:44] <juliank> Or force-skiptest dpkg/1.22.4ubuntu5
[18:44] <juliank> If we force-badtest apport we need to make sure to remove it before the next apport upload?
[18:46] <juliank> vorlon: wanna force-skiptest dpkg/1.22.4ubuntu5 ? I think we'll fix apport next week but I did not hear from bdrung but he wanted to cut a new release and I don't really want to get in the way before
[18:46] <juliank> Though I guess I could, it's non-native at least
[18:47] <juliank> But anyway, force-skiptest dpkg for now is a good idea
[18:49] <juliank> OK I won't touch the apport code today, it tests that /bin/bash is in the bash package in a bunch of places and it's very annoying, if I start that it turns into a very long day again and I don't have bread for breakfast if I don't make dough now
[20:22] <adrien> I made at least a couple mistakes earlier: I reverse-depends'ed and rmadison'd but didn't restrict that to noble; I also skipped packages which contain were reported for only source and not i386, which is the case for ocl-icd (although I'm not sure of what that entails)
[20:23] <adrien> I'll have another look on monday I think, there's a bit to unwrap
[20:24] <adrien> that being said, sssd seems to require faketime and is in main (I'm not sure why it's needed on i386 however)
[20:45] <tsimonq2> juliank, sudip: Hi, thanks for lxqt-archiver :) just had some confusion on our (Lubuntu's) end initially.
[20:45] <tsimonq2> We're trying to steer away from "ZOMGWTFBBQ!!!11 don't touch our packages" - there's better approaches than that. :)
[20:45] <tsimonq2> Anyway, just a long way of saying "thanks," that's all :)
[20:55] <sudip> tsimonq2: which is I pinged you that bug when I added ubuntu-sponsors to it, I knew you and Lubuntu will be the best person to look at that one
[20:57] <sudip> but that one was quite an interesting bug, if you see the upstream interaction for that  :)
[21:40] <tsimonq2> sudip: ahhhhh you pinged me, it's been *so* busy I apologize