[06:12] good morning [06:14] cpaelzer: o/ [06:14] o/ utkarsh2102 [08:26] good morning o/ [08:30] hi gjolly [08:41] gjolly: o/ [08:49] good morning [08:51] mirespace_: o/ === mirespace_ is now known as mirespace [08:52] Friday! [08:53] mirespace: indeed :-) [09:18] utkarsh2102: mirespace: paride: has one of you time for https://code.launchpad.net/~paelzer/ubuntu/+source/ldns/+git/ldns/+merge/417678 to upload it before beta-freeze? [09:18] hi cpaelzer, looking [09:35] cpaelzer, approved [09:42] woot! [09:48] thanks paride [10:52] hi! I trying tu run autopktest against a private ppa [10:53] I added the string with user and stringpass [10:53] I mean , the deb http:/.... [10:53] used the --login [10:54] athorized the token [10:54] but LP said the token is unclaimed [10:54] What else do I have to do? [11:08] I'm reading this in the meantime: https://uci.readthedocs.io/en/latest/oauth.html [11:12] used the --login [11:12] ups [11:12] something tells me that I won't be able to do it that way because a different oauth token is generated each time. [12:11] I haven't done that, sorry [12:11] you are using one of the ubuntu-release or ubuntu-archive scripts? [12:12] or autopkgtest, the normal runner? Can't you then use --setup to just add the ppa url with u:p in /etc/apt/sources.list.d/myppa.list? [12:14] ahasenack: I'm using the normal runner, with the setup ... [12:15] then it should work, can you paste it, with the user and password masked? [12:15] --setup-commands="sudo add-apt-repository -y -u -s --login deb https://mirespace:@private-ppa.launchpadcontent.net//ubuntu jammy main" [12:16] ups, I didn't mask the user [12:16] utkarsh2021 is suggesting adding the [trusted=yes] [12:16] I'll try it again :) [12:17] I didn't know add-apt-repository worked with private ppas, I would have just echoed the sources.list line to a file [12:17] not 2021 but 2102 [12:17] and yes :) [12:17] I think that --login option is for something else [12:17] it saysor not [12:17] or not [12:18] sorry utkarsh2102 (2th Feb ;) ) [12:18] in the meantime I came back to the local testing, resizing qemu img [12:18] and I recommend `--add-apt-sourcre` instead of `--setup-commands` [12:19] --login option was suggested from the tool in the fail [12:19] bbut it doesn't appears in the --help for autopkgtest neither add-apt-repository [12:20] utkarsh2102: I don't see that option, maybe you meant -S, --sourceslist [12:20] ? [12:20] differing add-apt-repository versions perhaps? [12:21] hold on a sec [12:21] are we talking about autopkgtest or sbuild [12:21] ? [12:21] autopkgtest [12:22] correct, then `--add-apt-source` is there. [12:22] just to be clear, I'm on Focal atm. [12:23] man autopkgtest should show the option I'm talking about. [12:23] me also in Focal [12:24] ah, right [12:45] oh man, update-initramfs is so much faster now in jammy. [12:45] whoever pushed the compression level change through - thank you :) [13:21] isn't that user definable? I remember having to go to lz4 because the default /boot size is too darn small [13:23] mybalzitch: looks like it: `grep COMPRESS= /etc/initramfs-tools/initramfs.conf` [13:25] the algorithm is configurable [13:25] but not the compression level [13:27] ahhh [14:19] mybalzitch: isn't xz better than lz4? last I checked, lz4 doesn't compress that well, but it's really fast. xz is the complete opposite [14:23] RoyK: here is the long thread: https://lists.ubuntu.com/archives/ubuntu-devel/2021-December/041726.html [14:23] and here: https://lists.ubuntu.com/archives/ubuntu-devel/2022-March/041907.html [14:24] the latter one has the conclusions/actions [14:45] my initramfs grew by like 1MB after the level change - a trade-off I'm more than willing to take. [14:49] (zstd, anyway) [15:01] did they even enable multithreading? :) [15:12] -T0, which iirc means "auto" [15:13] `Setting threads to a special value 0 makes xz use as many threads as there are CPU cores on the system.` [15:13] but picture a vm a dev is using for local tests, that needs to be updated [15:13] mkinitramfs was taking like 10min for m [15:13] me [15:14] but I don't think -T0 is the default so unless someone set it [15:15] it's what was used [15:15] with the higher levels [15:16] and still now I think [15:22] server team, postgresql-14 FTBFS fix up for review: https://code.launchpad.net/~ahasenack/ubuntu/+source/postgresql-14/+git/postgresql-14/+merge/417695 [15:25] ahasenack: ah - I see - pi zero :) [15:25] well, yes, some extremes were mentioned :) [15:25] but my vm case was real enough to me [15:25] I had 3 vms with 1Gb each, 1 core, to run a glusterfs cluster [15:25] which I was testing [15:26] and waiting 10min for each (in parallel) to generate the initramfs after a normal apt-get dist-upgrade, prior to testing, was painful [15:27] I always hate when a dkms package updates, and it kicks off a recursive initramfs updates [15:27] patdk-lap, -T0 is indeed the default with zstd at least: https://git.launchpad.net/ubuntu/+source/initramfs-tools/tree/mkinitramfs#n195 [15:28] (though not with xz interestingly, although it also has -T0 for "auto-threading" -- but both lead to *huge* memory usage at the higher compression levels) [15:28] ya, I didn't know where to look to find it coded in there [15:28] was just saying, unless someone passed that option, that isn't the zstd default [15:29] ah, sorry -- misunderstood the context [16:39] holy excuses, batman, what happened https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#ubuntu-server [16:39] lots of rebuilds [16:39] * No change rebuild for ppc64el baseline bump. [16:39] ahasenack, yeah I noticed that last night. [17:14] bryceh: found this old MP, is it still relevant and are you still waiting for it? https://code.launchpad.net/~bryce/pdbq/+git/pdbq/+merge/409788 [17:14] I don't even know what pdbq is [17:33] ahasenack, yeah that's still relevant, although it's a bit dated. That's the last piece needed for our merges board, and provides tracking for MRE tasks. [17:33] what is pdbq? [17:33] ahasenack, pdbq is Pinot's database backend that does the various queries to gather data from launchpad, et al. [17:34] pdbq's a flask application and where most of the "real" code is. Pinot is a web frontend, just smatterings of css, html, and javascript [17:36] ahasenack, having this split to frontend/backend means there can be CLI tools that interact with the backend, so the information shown in the web frontend will also be available from cli tools [17:37] sure, I just had no idea what it was [17:37] and looks like the others forgot about it too [17:39] yeah, I've been preoccupied myself, but now hopefully have some chunks of time [17:39] anyway, don't worry about reviewing that, I'll respin it at some point [18:04] bryceh: would you have time to review this ftbfs fix for postgresql-14? [18:04] https://code.launchpad.net/~ahasenack/ubuntu/+source/postgresql-14/+git/postgresql-14/+merge/417695 [18:04] certainly [18:05] and I certainly thank you effusively [18:05] (had to look that spelling up) [18:08] ahasenack, are you aware of / have you used Christian's lp-test-ppa ? [18:08] aware-ish [18:09] what's on your mind? [18:10] * ahasenack senses a lightning talk coming :) [18:13] @ahasenack, hah it is indeed already scheduled as a lightning talk for next week by Christian :-) [18:13] aha [18:15] anyway, you've remarked some concerns about bileto, but I have a suspicion that between ppa-dev-tools (lightning talk week after next), and lp-test-ppa, it should be possible to cobble together the main bileto-ish workflow you like to use. It makes me curious what functionality from bileto might be missing, that might need implementated. [18:16] I think the biggest one would be testing the dependencies [18:16] don't know if the tools you mentioned do that [18:17] for example, upload postgresql, and run dep8 tests in the things that use postgresql [18:17] just like the real migration does [18:17] no, they don't do that directly. I'd need to understand more detail of what it'd need to do. [18:18] I want to add a --list option to install-build-deps, which might provide some of that [18:19] I'll have to dig into bileto's code a bit [18:20] anyway, breakfast calls. bbl [18:27] heed that call :) [18:27] uh, samba on riscv64 takes a while to build... [18:28] last build took 4 hours, 40 minutes, 32.5 seconds in LP [19:49] RoyK: I don't recall what I ended up with. might have been xz indeed. I know it was an issue on my surface laptop [20:05] bryceh: I have another one up, https://code.launchpad.net/~ahasenack/ubuntu/+source/samba/+git/samba/+merge/417699 [20:06] on top of what I uploaded earlier today, after miriam's review [20:06] the risc build takes forever :/ https://launchpad.net/ubuntu/+source/samba/2:4.15.5~dfsg-0ubuntu3 [20:06] ok [20:07] the samba MP reviews scare me :-D [20:08] yeah [20:08] I should have pinged about the previous one that was stuck this week [20:08] this is just the 0ubuntu4 one, 0ubuntu3 was uploaded already, git-ubuntu just didn't import it yet because riscv64 is still building [20:09] *nod* [21:45] mybalzitch: IIRC, xz will also require a lot of memory. gz should be pretty low there