[00:07] <amurray> vorlon: libseccomp merge is in bileto https://bileto.ubuntu.com/#/ticket/4358 - this is not final, I plan to make some changes though though for debian/tests so it can be more easily SRUd back ontop of older kernels but that will oonly affect debian/tests not anything else so if you want to test against it, it should be good
[01:09] <vorlon> amurray: ta.  fwiw I found up doing a trivial merge locally and the build in question still fails with libseccomp-dev 2.5.0-3ubuntu1.  I'm now at a loss to understand how this ever built in Debian, since it appears to depend on interfaces not exposed by any version of golang-github-seccomp-containers-golang-dev that's been published
=== ijohnson|lunch is now known as ijohnson
[01:25] <amurray> vorlon: I don't follow - what fails to build? (golang-github-seccomp-containers-golang-dev ?)
[01:26] <vorlon> amurray: the failing package is golang-github-containers-buildah, which references non-existent seccomp.ActLog and seccomp.ActKillProcess
[03:25] <ItzSwirlz> I assume people are aware that ports (ports.ubuntu.com) doesn't have a Packages file for any of their dists but archive does, right?
[03:28] <sarnold> ItzSwirlz: what specificailly do you mean? I picked 'focal', 'arm64', and 'amd64' with the theory that they'd be well-worn paths, and there's a Packages.xz in both: http://us.archive.ubuntu.com/ubuntu/dists/focal/main/binary-amd64/ http://ports.ubuntu.com/dists/focal/main/binary-arm64/
[03:35] <ItzSwirlz> sarnold, Just the file named "Packages". No tarball or anything, it's just a text file with GPG keys and such for the packages. http://ports.ubuntu.com/ubuntu-ports/dists/hirsute/main/binary-arm64/
[03:40] <sarnold> ItzSwirlz: Packages.xz exists in both http://us.archive.ubuntu.com/ubuntu/dists/hirsute/main/binary-amd64/ and http://ports.ubuntu.com/ubuntu-ports/dists/hirsute/main/binary-arm64/ .. what exactly is different?
[03:41] <ItzSwirlz> Trying to (for fun and to see how livecd-rootfs works) build an arm64 image. Germinate part with lb config fails because there is no file called http://ports.ubuntu.com/ubuntu-ports/dists/hirsute/main/binary-arm64/Packages
[03:41] <ItzSwirlz> Which that directory *doesnt exist*. In archive.ubuntu.com from what i see it does, but only here in the ports it doesnt
[03:45] <sarnold> ItzSwirlz: because the compression method for that file changes from release to release, apt sometimes just reports 'Releases' when it really should report the full path with extension
[03:46] <sarnold> ItzSwirlz: try using tshark or opensnoop or strace to find out what's actually being done
[03:46] <ItzSwirlz> I've tried looking at the script with nano and it shouldn't be a problem. It's most likely apt
=== didrocks999 is now known as didrocks
[08:21] <eoli3n> Hi
[08:22] <eoli3n> mwhudson when i use an early_command like "which ip" or "ip -V" it outputs nothing
[08:22] <eoli3n> to be able to workaround the DHCP hostname issue, i need to use ip -j (json) output
[08:22] <eoli3n> what's strange is that when i use ip -j in early_command, it fails
[08:22] <eoli3n> then if i open tty2 and run it, it succeed
[08:22] <eoli3n> can you tell me why ?
[08:24] <eoli3n> i think it uses busybox "ip", lets try to force /usr/sbin/ip
[08:24] <eoli3n> but if it does, why does it ?
[08:42] <mwhudson> no early commands run in the full server environment, no busybox or anything
[09:06] <eoli3n> so that's strange that "ip" differs from "/usr/sbin/ip"
[09:06] <eoli3n> i can't which, it outputs nothing
[09:06] <eoli3n> i can't tell what ip binary is played from the PATH
[09:23] <doko> mitya57: did something change in sphinx so that more dependencies on libjs-sphinx are generated? probably already in Sep/Oct?
[09:28] <mitya57> doko: maybe https://salsa.debian.org/python-team/packages/sphinx/-/commit/72fe9228e17faf8f
[09:28] <mitya57> Does it cause any problems?
[09:30] <doko> node-jquery was promoted last cycle, but we don't know why. I demoted it again, and also demoting a few -doc packages which have gained that dependency
[09:32] <mitya57> doko: Hm, then maybe this change is not related. It only made the dependencies more strict, but it shouldn't add *new* dependencies.
[09:33] <mitya57> I have another guess…
[09:33] <doko> yes, libjs-sphinxdoc depends on libjs-query, but already in focal.
[09:35] <mitya57> doko: maybe it was mkdocs, not sphinx?
[09:36] <eoli3n> mwhudson with which user are run early and late commands ?
[09:38] <mitya57> doko: Also libjs-jquery itself now depends on node-jquery!
[09:38] <mitya57> Looks like already in groovy, but not in focal: https://packages.ubuntu.com/groovy/libjs-jquery
[09:42] <doko> mitya57: ahh, jquery source renamed to node-jquery?
[09:43] <doko> ok, that explains it
[09:44] <doko> sarnold, cpaelzer, vorlon: ^^^
[09:47] <mitya57> doko: not renamed, but merged into, I would say
[09:48] <mitya57> See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940975
[09:48] <ubottu> Debian bug 940975 in libjs-jquery, node-jquery "jQuery may not need two different packages" [Normal,Fixed]
[09:50] <doko> it looks like the same source
[09:51] <mitya57> I mean it existed before this year, so it's a merge/unification, not a rename. But that shouldn't change anything :)
[09:52] <doko> yes, but it was a package without a subscriber. now subscribing the owner of jquery
[09:52] <doko> and re-promoting
[10:10] <LocutusOfBorg> mitya57, hello, can you please update the intltool repository in debian? I merged it in Ubuntu, but the patch should really be upstreamed
[10:10] <LocutusOfBorg> https://salsa.debian.org/gnome-team/intltool/
[10:10] <LocutusOfBorg> there are few merge requests, and somebody did NMU it
[10:16] <mitya57> LocutusOfBorg: I can do it, but later, not now
[10:20] <LocutusOfBorg> sure, if you could also apply the Ubuntu patch it would be awesome
[10:20] <LocutusOfBorg> or add me to the team, even better
[10:22] <cpaelzer> doko: the new bin:libjs-jquery (now from src:node-jquery) depends on bin:node-jquery which gladly is not pulling in any more of node-*
[10:23] <cpaelzer> doko: but yeah the recommends to libjs-sizzle from there is what we see in mismatches
[10:23] <cpaelzer> doko: original jquery is under foundations-bugs, so node-jquery (which gladly deos not do much else) should probably be subscribe by foundations-bugs as well?
[10:24] <cpaelzer> doko: do you have the power to subscribe the team ?
[10:24] <doko> already done
[10:24] <cpaelzer> oh thanks
[10:25] <cpaelzer> doko: and mid term - MIR for src:sizzle or delta to drop the dependency?
[10:26] <mitya57> LocutusOfBorg: about adding to the team — better ask on #debian-gnome. I don't know why I'm an owner — that's probably a mistake :)
[10:27] <mitya57> But if nobody replies then I can do it :)
[11:04] <eoli3n> https://bugs.launchpad.net/subiquity/+bug/1905731
[11:04] <ubottu> Launchpad bug 1905731 in subiquity "feature request autoinstall: late_command scripts and chroot key" [Undecided,New]
[11:04] <eoli3n> mwhudson i think you're sleeping, but if you could take a look on this
[13:16] <xnox> i am very bad at weechat
[13:16] <xnox> i have no idea how to remove a server
[13:19] <xnox> horay, managed to do it.
[13:53] <gpiccoli> Hi folks, does anybody know if it's possible to skip installation integrity check on server ISO, for Focal ?
[13:53] <gpiccoli> The installer checks md5 for all files, it takes a while in case of a a virtual media mount...
[13:54] <gpiccoli> Maybe we have a parameter to skip it ?
[13:57] <seb128> gpiccoli, https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1892369
[13:57] <ubottu> Launchpad bug 1892369 in ubiquity (Ubuntu) "Impossible to skip integrity test for ubuntu-server 20.04.1 iso" [Undecided,Confirmed]
[13:57] <gpiccoli> I saw this =/
[13:57] <gpiccoli> hehe
[13:58] <gpiccoli> I was in hope that there was some hack hehe
[13:58] <seb128> xnox might know a way
[13:58] <gpiccoli> I might reconstruct the casper initrd to skip the bottom script that does the integrity check
[13:59] <gpiccoli> it's uber slow if ISO is mounted as virtual media..my case is exactly the one in the LP (Dell machine)
[13:59] <gpiccoli>     if (strncmp(tok, "fsck.mode=skip", sizeof("fsck.mode=skip")) == 0)
[13:59] <gpiccoli> promissing...I'll try this one
[14:00] <gpiccoli> It's from the casper-md5check tool
[14:18] <jdstrand> vorlon, amurray: fyi in Ubuntu patched golang-github-seccomp-libseccomp-golang for those two things ahead of upstream's 0.9.1 release iirc. perhaps golang-github-seccomp-containers-golang has < 0.9.1 vendored or something?
[14:22] <jdstrand> vorlon, amurray: that said, it looks like only ActLog is in 0.9.1. ActKillProcess is in master
[14:30] <jdstrand> vorlon, amurray: oh, we didn't patch the archive for those, we patched snapd's vendored golang-github-seccomp-libseccomp-golang, sorry. maybe the info about 0.9.0, 0.9.1 and master is still useful to you
[14:36] <sil2100> seb128: hey! So just now I did a quick look and it feels to me that maybe the best choice will be to indeed add a new image type for canary! Like daily-canary or something. I'll prep a quick MP later, trying to fix the publishing while at it
[14:37] <seb128> sil2100, k, thanks for checking, let me know when you have a proposed change and I can test that locally
[15:06] <sil2100> Will do!
[15:25] <Odd_Bloke> waveform: https://lists.launchpad.net/cloud-init/msg00320.html <-- does this sounds like a workflow that you'd expect to work ATM?
[15:41] <waveform> Odd_Bloke, yes - that workflow *should* work; sounds like something is broken with the naming setup in network-config - I'll try and replicate here
[15:51] <Odd_Bloke> waveform: Thanks!
[17:20] <gpiccoli> "fsck.mode=skip" didn't work =/
[18:01] <gpiccoli> xnox, saw your comment in LP #1892369, but it didn't work for me
[18:01] <ubottu> Launchpad bug 1892369 in casper (Ubuntu) "Impossible to skip integrity test for ubuntu-server 20.04.1 iso" [Undecided,New] https://launchpad.net/bugs/1892369
[18:01] <gpiccoli> I guess Dell virtual media is slow, given it's a remote ISO mounting...I'm not sure why so slow, but here it takes many minutes to complete the integrity check
=== ijohnson is now known as ijohnson|lunch
[18:11] <kbr> so rust-bat in hirsute is 0.12.1-1 and for some reason 0.12.1-5 sits in hirsute-proposed. I can't figure out why - shouldn't this be automatically imported to hirsuite proper from Debian?
[18:15] <kbr> according to https://wiki.ubuntu.com/SyncRequestProcess it should be synced automatically, as DebianImportFreeze is not yet in place
[18:20] <kbr> same question applies for rust-sniffglue, which has 0.11.1-5 in hirsute-proposed (but that FTBFS, not sure if this may be stopping the sync?)
[18:36] <LocutusOfBorg> kbr, https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[18:37] <LocutusOfBorg> Issues preventing migration:
[18:37] <LocutusOfBorg> Build-Depends(-Arch): rust-bat rust-dirs (not considered)
[18:38] <sarnold> doko,mitya57, thanks for tracking that down :)
[18:38] <LocutusOfBorg> vorlon, is it possible to kick out https://launchpad.net/ubuntu/+source/rust-vte due to it being out from debian testing? this might make some rust stuff migrate
[18:39] <LocutusOfBorg> I tried a rebuild just to make sure we have a log
[18:39] <LocutusOfBorg> kbr, ^^ this should fix the migration issue
[18:39] <kbr> hah, I kinda knew in the back of my mind that update_excuses existed, but couldn't find it
[18:39] <kbr> cheers
[18:42] <kbr> I was hoping to get a SRU going to fix LP #1868517 but since this is not yet fixed in hirsute I understood it doesn't qualify for SRU in groovy
[18:42] <ubottu> Launchpad bug 1868517 in rust-bat (Ubuntu) "Stray /usr/.crates2.json file" [High,Fix committed] https://launchpad.net/bugs/1868517
[18:48] <vorlon> LocutusOfBorg: lgtm, done
[19:14] <LocutusOfBorg> thanks
[19:16] <LocutusOfBorg> kbr, I hope this is enough for migration, but I really don't like rust :)
=== ajmitch_ is now known as ajmitch
=== ijohnson|lunch is now known as ijohnson
[20:39] <LocutusOfBorg> vorlon, also https://packages.qa.debian.org/r/rust-x11rb.html needs a kick out...
[20:40] <LocutusOfBorg> kbr, in order to have that migration somebody has to: fix rust-glib and rust-onig tests
[20:41] <LocutusOfBorg> fix rust-libsystemd and fix rust-libmount
[20:55] <mwhudson> ricotz: yeah will take a few more days, hopefully not too many
[21:04] <vorlon> LocutusOfBorg: rust-x11rb removed
[21:09] <LocutusOfBorg> ta
[21:13] <ricotz> mwhudson, thank you, regarding the bootstrapped update issue, iirc the packaging supports using the upstream binaries
[21:14] <mwhudson> ricotz: yes but ubuntu does not
[21:14] <ricotz> mwhudson, https://forge.rust-lang.org/infra/other-installation-methods.html#standalone
[21:14] <ricotz> hmm
[21:16] <ricotz> I guess eventually riscv64 will require this way
[21:27] <siretart> vorlon: thanks for your patch for containers/image and merging it into ubuntu!
[21:34] <vorlon> siretart: thanks for picking it up so quickly! btw I also noticed after filing the bug that it should also be a runtime dep
[22:05] <kbr> LocutusOfBorg: I'll try to have a look into these in the next few days
[22:06] <kbr> thanks
[23:03] <siretart> vorlon: oh, I (more or less) accidentally picked that already up: https://salsa.debian.org/go-team/packages/golang-github-containers-image/-/commit/55195fe6aa2ed23f5aaf0b55ec1b609d30140fc0 :-)
[23:03] <vorlon> siretart: ah, great :)