[07:57] <TJ-> 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] <alkisg> 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] <alkisg> So I think you could just grep for Build-Depends:.bison. in /var/lib/apt/lists/*source...
[08:02] <alkisg> *not "source reverse build-depends"
[08:03] <alkisg> Eeeh OK I phrased it terribly but I think you get my meaning
[08:04] <TJ-> yeah, but that requires quite a lot of awk pre-post processing!
[08:05] <TJ-> actually, not so much! awk '/^Package:/{P=$2} /^Build-Depends:.*bison/{print P}' /var/lib/apt/lists/*source*
[08:05] <mitya57> TJ-: "reverse-depends -b packagename" with ubuntu-dev-tools installed
[08:06] <TJ-> thanks ... I'm sure there's a tool that does this too. build-rdeps in devscripts
[08:07] <TJ-> 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] <TJ-> mitya57: that one too, thanks
[08:10] <TJ-> now for the interesting one ... the intersection of packages that reverse build-depend on both bison and flex !
[08:11] <TJ-> 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] <TJ-> also seems like reverse-depends is sending to stderr not stdout
[08:13] <alkisg> Intersection with shell? `comm -3` can help...
[08:14] <alkisg> Eeh, `comm -1 -2`
[08:15] <TJ-> looks like 'reverse-depends -b flex' will fail due to circular dependencies, but 'bison' is fine
[08:16] <TJ-> reverse-depends --list ... solves the recursion issue
[08:19] <TJ-> ok, so finally: " comm -3  <(reverse-depends -lb bison 2>&1 | sort) <(reverse-depends -lb flex 2>&1 | sort) "
[08:20] <TJ-> oops, wrong, alkisg  :)
[08:20] <TJ-> " 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] <TJ-> most annoying is reverse-depends writing to stderr!
[08:23] <alkisg> TJ-: not sure if this workflow will also match packages that build-depend on "bison | flex" though (OR instead of AND)
[08:23] <alkisg> ...but I guess that doesn't make sense... maybe some other variant
[08:25] <TJ-> 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] <TJ-> Now I have 444 packages to consider :s
[08:29] <cjwatson> TJ-: You might find grep-dctrl useful
[08:29] <cjwatson> If you have the necessary Sources file inputs handy then it makes a lot of these sorts of queries fairly easy
[08:30] <TJ-> cjwatson: bingo! thanks, with the AND operator
[08:32] <TJ-> " grep-dctrl -s Package -F Build-Depends,Build-Depends-Indep bison --and flex /var/lib/apt/lists/*Sources " seems to do it
[08:33] <TJ-> although... with my former 'comm' the result is 444 lines whereas with grep-dctrl 540
[08:33] <TJ-> still it'll do for what I want it for :)
[08:36] <cjwatson> BTW I normally add -w to avoid accidental substring matches
[08:36] <cjwatson> And I think you probably want --and -F Build-Depends,Build-Depends-Indep flex, not just --and flex
[08:37] <cjwatson> That probably explains the excess matches
[08:37] <TJ-> ahhh, thanks, didn't realise it was filter-specific
[08:38] <cjwatson> There might also be some duplicates due to release vs. updates etc., so run through sort -u afterwards
[08:38] <TJ-> haha, reduced by 1! :)
[08:38] <TJ-> and ... 451 - thanks cjwatson  :)
[08:38] <alkisg> 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] <TJ-> amazing how even after 16 7 years hacking on code you can learn something new like this :)
[08:39] <TJ-> alkisg: they're not; I need actual real usage examples. The tutorials are too basic for me
[08:39] <alkisg> 👍️
[08:40] <TJ-> 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] <alkisg> 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] <alkisg> 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...
[10:18] <laney> https://bugs.launchpad.net/ubuntu/+source/heimdal/+bug/1934936
[10:18] <laney> this seems legitimate
[10:18] <laney> laney@raleigh> md5sum changelog.Debian.gz*
[10:18] <laney> 9d8317066f8048a9efae252f5bb41f39  changelog.Debian.gz-amd64
[10:18] <laney> ebd19e846a9942d0a1c4366c03d45934  changelog.Debian.gz-i386
[10:19] <laney> wonder what's going on there
[10:23] <laney> ah the changelog truncation/symlinking stuff has broken it, good good
[11:06] <xnox> 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] <juliank> xnox: all looks good to me
[11:10] <juliank> 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] <juliank> ./download-signed shim current shim signed
[11:10] <juliank> Downloading http://archive.ubuntu.com/ubuntu/dists/impish/main/signed/shim-amd64/15.4-0ubuntu7/SHA256SUMS ... found
[11:10] <juliank> It works for me :)
[11:12] <juliank> I sure hope it doesn't cache the 404s
[11:13] <cjwatson> I don't think the squid config is that bad
[11:15] <juliank> Wondering if I need to URL quote + characters or stuff
[11:16] <juliank> arguably they don't appear in shim versions, so meh
[11:17] <xnox> juliank:  i like that.
[11:17] <xnox> juliank:  i used to have that, but it was pain to constantly bump numbers, hence switched to current.
[11:18] <juliank>  xnox ack, will upload :)
[11:18] <xnox> cjwatson:  is there a header we can set "X-Squid-Please-Fetch-Latest: yes" ?
[11:18] <juliank> Filed https://bugs.launchpad.net/ubuntu/+source/shim-signed/+bug/1936640 for SRU tracking purposes :)
[11:18] <juliank> xnox: We can actually set cache-control headers, yes, but this works more nicely I think
[11:18] <xnox> or i think we should adjust expiry on signed.gpg tarballs.
[11:18] <xnox> or i think we should adjust expiry on signed tarballs.
[11:19] <cjwatson> xnox: "Pragma: no-cache" does that, but I think versioning the URL is better if possible
[11:19] <xnox> ack
[11:20] <cjwatson> (or should do that - I haven't actually tested in this particular case but it would be usual)
[11:20] <juliank> If that squid cached 404s for multiple hours, that would be a bug anyway IMO
[11:20] <cjwatson> I think that is unlikely
[11:21] <cjwatson> 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] <juliank> We'll see if it works when the SRUs build :)
[11:22] <xnox> 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] <cjwatson> juliank: URL quoting: you should do Python urllib.parse.quote or equivalent
[11:24] <juliank> I'll leave that to a future cycle I suppose
[11:24] <juliank> We never get any special characters in those shim versions because they always upload to devel and get binary copied anyway
[11:24] <juliank> I wish I could also binary-copy the signing tarballs
[11:24] <cjwatson> Yeah, but it's good software engineering to do quoting properly
[11:30] <xnox> at the moment we generate new signing in -proposed, -updates, -release pockets.
[11:31] <xnox> and different series could have different EFI keys.
[11:31] <juliank> cool
[11:31] <xnox> and different GPG archive publishing signing keys
[11:31] <xnox> 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] <juliank> 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] <juliank> either way, it was wrong before when we explictly passed version instead of current anyway
[11:42] <xnox> just don't introduce and epoch
[11:42] <xnox> just don't introduce an epoch
[11:42] <cjwatson> The correct point to quote is when assembling the URL
[11:49] <juliank> I don't know, I think the correct point is to quote each path component
[11:49] <juliank> e.g. "%s/%s" % (quote a, quote b) vs "http://server" + quote("%s/%s" % (a,b))
[11:56] <juliank> xnox: Do you remember what grub2-signed I need for SBAT; i.e. is >= 1.167~ enough?
[11:57] <juliank> I guess so
[11:59] <juliank> 1.167 was ubuntu44, and ubuntu42 added SBAT
[12:11] <cjwatson> juliank: each path component> yes, that's what I meant, just at the stage of assembling the URL
[12:11] <cjwatson> obviously not quoting the full URL, that just wouldn't work
[12:11] <juliank> cjwatson: yeah, we build the path first and not sure if we use it outside the URL, so meh
[12:11] <juliank> 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] <juliank> I think I got everything right, though
[12:13] <juliank> Basically replaced everything with 1.50 and then backported it :D
[12:13] <juliank> maybe should have called it 1.50~18.04.0
[12:13] <juliank> anyhow, it works :)
[12:23] <xnox> looks good.
[12:23] <xnox> juliank:  and my grub2 build failed in PPA. glad I uploaded it into the ppa.
[12:23] <juliank> very good
[14:54] <laney> xnox: opinions on skipping changelog symlinking for MA: same packages?
[15:26] <rafaeldtinoco> stgraber: is there a place images for old fedoras (already EOL) are moved to (instead of being fully removed from images repo) ?
[15:27] <rafaeldtinoco> fedora 30/31/32...
[15:27] <rafaeldtinoco> btw lxd rocks: https://usercontent.irccloud-cdn.com/file/MSgXxmlB/image.png
[15:29] <rafaeldtinoco> the virtiofs integration is super smooth
[16:23] <stgraber> 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] <xnox> laney:  urgh. i bet it is unpredictable because we build different number of packages on i386 vs amd64.
[16:27] <xnox> 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] <xnox> laney:  using the debian policy compatible --doc-main-package=main-package
[16:28] <xnox> (aka compat 11)
[16:28] <xnox> or like --link-doc=package
[16:28] <xnox> sorry, the --link-doc=package option (the doc-main-package is something else)
[16:32] <rafaeldtinoco> stgraber: tku!
[16:33] <laney> xnox:  you mean you want to find all packages that might be affected, and fix them to use link-doc?
[22:01] <xnox> laney:  i guess it is all of main, m-a:same which is a lot.
[22:02] <xnox> 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.