[07:57] is there a way to identify all reverse build-depends in the same way as 'apt-cache rdepends' works for binary packages? Specifically wanting to identify all packages that build-depend: bison | flex [08:01] TJ-: if package a build-depends on b, the binary b is fetched, so there in that second step, you'd need "normal reverse depends", not "reverse build-depends" [08:02] So I think you could just grep for Build-Depends:.bison. in /var/lib/apt/lists/*source... [08:02] *not "source reverse build-depends" [08:03] Eeeh OK I phrased it terribly but I think you get my meaning [08:04] yeah, but that requires quite a lot of awk pre-post processing! [08:05] actually, not so much! awk '/^Package:/{P=$2} /^Build-Depends:.*bison/{print P}' /var/lib/apt/lists/*source* [08:05] TJ-: "reverse-depends -b packagename" with ubuntu-dev-tools installed [08:06] thanks ... I'm sure there's a tool that does this too. build-rdeps in devscripts [08:07] I hate it when I know I've used a tool in the distant past and cannot recall what it is, only how I used it! [08:09] mitya57: that one too, thanks [08:10] now for the interesting one ... the intersection of packages that reverse build-depend on both bison and flex ! [08:11] reverse-depends fails in 2 ways. output text is all over the place terminal, and stops with RecursionError: maximum recursion depth exceeded while calling a Python object" [08:12] also seems like reverse-depends is sending to stderr not stdout [08:13] Intersection with shell? `comm -3` can help... [08:14] Eeh, `comm -1 -2` [08:15] looks like 'reverse-depends -b flex' will fail due to circular dependencies, but 'bison' is fine [08:16] reverse-depends --list ... solves the recursion issue [08:19] ok, so finally: " comm -3 <(reverse-depends -lb bison 2>&1 | sort) <(reverse-depends -lb flex 2>&1 | sort) " [08:20] oops, wrong, alkisg :) [08:20] " comm -1 -2 <(reverse-depends -lb bison 2>&1 | sort) <(reverse-depends -lb flex 2>&1 | sort) " [08:21] * alkisg needs to learn a few bashisms, they make scripts shorter :D [08:21] most annoying is reverse-depends writing to stderr! [08:23] TJ-: not sure if this workflow will also match packages that build-depend on "bison | flex" though (OR instead of AND) [08:23] ...but I guess that doesn't make sense... maybe some other variant [08:25] Only want the conjunction - trying to accelerate learning how to use them together to create a 'mid-range' parser (not overly complex but not toy either) [08:25] Now I have 444 packages to consider :s [08:29] TJ-: You might find grep-dctrl useful [08:29] If you have the necessary Sources file inputs handy then it makes a lot of these sorts of queries fairly easy [08:30] cjwatson: bingo! thanks, with the AND operator [08:32] " grep-dctrl -s Package -F Build-Depends,Build-Depends-Indep bison --and flex /var/lib/apt/lists/*Sources " seems to do it [08:33] although... with my former 'comm' the result is 444 lines whereas with grep-dctrl 540 [08:33] still it'll do for what I want it for :) [08:36] BTW I normally add -w to avoid accidental substring matches [08:36] And I think you probably want --and -F Build-Depends,Build-Depends-Indep flex, not just --and flex [08:37] That probably explains the excess matches [08:37] ahhh, thanks, didn't realise it was filter-specific [08:38] There might also be some duplicates due to release vs. updates etc., so run through sort -u afterwards [08:38] haha, reduced by 1! :) [08:38] and ... 451 - thanks cjwatson :) [08:38] If it's the first touch with flex/bison, I think online tutorials or notes from universities courses would be more helpful than existing code, as their syntax and semantics aren't really intuitive [08:39] amazing how even after 16 7 years hacking on code you can learn something new like this :) [08:39] alkisg: they're not; I need actual real usage examples. The tutorials are too basic for me [08:39] 👍️ [08:40] alkisg: I'm trying to determine if I'm making the correct choice since this may not be the optimal parsing method for my requirements - trying to avoid wasting time going down an avenue to later abandon it [08:41] Yeah, been there twice; once for implementing a pascal-like language for greece (where I found out that bison/flex didn't have unicode support at least back then), and later on while implementing an openmp compiler... [08:48] Btw, may I ask about https://bugs.launchpad.net/snap-core20/+bug/1926355 one more time? (especially my comments #15 and #17). libc got updated in focal, then withdrawn, and the people that have that temporary release now have problems installing other packages like dkms or clang... [08:48] Launchpad bug 1926355 in glibc (Ubuntu Focal) "Snap applications segfault with new core20 (rev: 1015+)" [Undecided, In Progress] [10:18] https://bugs.launchpad.net/ubuntu/+source/heimdal/+bug/1934936 [10:18] Launchpad bug 1934936 in heimdal (Ubuntu) "package libwind0-heimdal 7.7.0+dfsg-2build1 failed to install/upgrade: trying to overwrite shared '/usr/share/doc/libwind0-heimdal/changelog.Debian.gz', which is different from other instances of package libwind0-heimdal:i386" [Undecided, Incomplete] [10:18] this seems legitimate [10:18] laney@raleigh> md5sum changelog.Debian.gz* [10:18] 9d8317066f8048a9efae252f5bb41f39 changelog.Debian.gz-amd64 [10:18] ebd19e846a9942d0a1c4366c03d45934 changelog.Debian.gz-i386 [10:19] wonder what's going on there [10:23] ah the changelog truncation/symlinking stuff has broken it, good good [11:06] juliank: i have a weird feeling about all of these fixes https://code.launchpad.net/~xnox/grub/+git/grub/+merge/405806 as if there must be typo somewhere. Doing test builds in a ppa. [11:06] xnox: all looks good to me [11:10] xnox: what do you think of this? https://paste.ubuntu.com/p/mJqSSb2HPP/ - I want to make shim-signed download from versioned url instead of current; such that we don't get stuck behind the arm64 cache for hours with an old version [11:10] ./download-signed shim current shim signed [11:10] Downloading http://archive.ubuntu.com/ubuntu/dists/impish/main/signed/shim-amd64/15.4-0ubuntu7/SHA256SUMS ... found [11:10] It works for me :) [11:12] I sure hope it doesn't cache the 404s [11:13] I don't think the squid config is that bad [11:15] Wondering if I need to URL quote + characters or stuff [11:16] arguably they don't appear in shim versions, so meh [11:17] juliank: i like that. [11:17] juliank: i used to have that, but it was pain to constantly bump numbers, hence switched to current. [11:18] xnox ack, will upload :) [11:18] cjwatson: is there a header we can set "X-Squid-Please-Fetch-Latest: yes" ? [11:18] Filed https://bugs.launchpad.net/ubuntu/+source/shim-signed/+bug/1936640 for SRU tracking purposes :) [11:18] Launchpad bug 1936640 in shim-signed (Ubuntu) "Download signed version from versioned URL" [Undecided, New] [11:18] xnox: We can actually set cache-control headers, yes, but this works more nicely I think [11:18] or i think we should adjust expiry on signed.gpg tarballs. [11:18] or i think we should adjust expiry on signed tarballs. [11:19] xnox: "Pragma: no-cache" does that, but I think versioning the URL is better if possible [11:19] ack [11:20] (or should do that - I haven't actually tested in this particular case but it would be usual) [11:20] If that squid cached 404s for multiple hours, that would be a bug anyway IMO [11:20] I think that is unlikely [11:21] I would prefer not to get into having to manually tweak the config on these squids - they're pretty obscure and hard to debug [11:21] We'll see if it works when the SRUs build :) [11:22] doko: to test that my lto stuff works correctly, i should first upload the lto list package that drops grub2 into my ppa, right? [11:22] juliank: URL quoting: you should do Python urllib.parse.quote or equivalent [11:24] I'll leave that to a future cycle I suppose [11:24] We never get any special characters in those shim versions because they always upload to devel and get binary copied anyway [11:24] I wish I could also binary-copy the signing tarballs [11:24] Yeah, but it's good software engineering to do quoting properly [11:30] at the moment we generate new signing in -proposed, -updates, -release pockets. [11:31] and different series could have different EFI keys. [11:31] cool [11:31] and different GPG archive publishing signing keys [11:31] it is a bit of a side channel. generating multiple signatures for the same data, but with just a different timestamp for the sig. [11:31] I don't want to quote now, as I don't want to dig into what uses the potentially quoted values in the script, and there's no use atm [11:32] either way, it was wrong before when we explictly passed version instead of current anyway [11:42] just don't introduce and epoch [11:42] just don't introduce an epoch [11:42] The correct point to quote is when assembling the URL [11:49] I don't know, I think the correct point is to quote each path component [11:49] e.g. "%s/%s" % (quote a, quote b) vs "http://server" + quote("%s/%s" % (a,b)) [11:56] xnox: Do you remember what grub2-signed I need for SBAT; i.e. is >= 1.167~ enough? [11:57] I guess so [11:59] 1.167 was ubuntu44, and ubuntu42 added SBAT [12:11] juliank: each path component> yes, that's what I meant, just at the stage of assembling the URL [12:11] obviously not quoting the full URL, that just wouldn't work [12:11] cjwatson: yeah, we build the path first and not sure if we use it outside the URL, so meh [12:11] xnox: this was crazy https://git.launchpad.net/~ubuntu-core-dev/shim/+git/shim-signed/diff/?id=1.37_18.04.9&id2=1.37_18.04.8 [12:12] I think I got everything right, though [12:13] Basically replaced everything with 1.50 and then backported it :D [12:13] maybe should have called it 1.50~18.04.0 [12:13] anyhow, it works :) [12:23] looks good. [12:23] juliank: and my grub2 build failed in PPA. glad I uploaded it into the ppa. [12:23] very good === cjwatson_ is now known as cjwatson [14:54] xnox: opinions on skipping changelog symlinking for MA: same packages? [15:26] stgraber: is there a place images for old fedoras (already EOL) are moved to (instead of being fully removed from images repo) ? [15:27] fedora 30/31/32... [15:27] btw lxd rocks: https://usercontent.irccloud-cdn.com/file/MSgXxmlB/image.png [15:29] the virtiofs integration is super smooth [16:23] rafaeldtinoco: sadly, no. We have limited amount of space on the various servers so 10 days after we stop building a distro image, it's gone. You could still grab the YAML from the lxc-ci repository and build yourself a new image with distrobuilder though [16:26] laney: urgh. i bet it is unpredictable because we build different number of packages on i386 vs amd64. [16:27] laney: i kind of feel those packages should just have -dev package have a symlinked the whole /doc/ dir to the lib one. [16:28] laney: using the debian policy compatible --doc-main-package=main-package [16:28] (aka compat 11) [16:28] or like --link-doc=package [16:28] sorry, the --link-doc=package option (the doc-main-package is something else) [16:32] stgraber: tku! [16:33] xnox: you mean you want to find all packages that might be affected, and fix them to use link-doc? === lucas_ is now known as lucascastro === rZZZr is now known as RzR === genii is now known as genii-core [22:01] laney: i guess it is all of main, m-a:same which is a lot. [22:02] laney: next question, why is amd64 got processed in a different order from i386? cause normally there are all started in parallel, but maintain a lock file to do certain things in the order that packages appear in debian/control.