[01:56] <bryceh> https://autopkgtest.ubuntu.com/packages/n/node-caniuse-db/jammy/i386 --- what does "code 14" mean?
[02:19] <sarnold> darktable in #ubuntu had a hirsute -> impish upgrade blow up, and usrmerge seems to have been involved somehow, https://pastebin.com/AnVB5zJv  -- while trying to walk him through piecing his system back together, some of us found we've got /bin -> /usr/bin symlinks, and some of us don't have such symlinks.. what's the long-term plan for harmonizing everyone's setups?
[02:19] <sarnold> (sigh, darktrick, not darktable)
[02:45] <DarkTrick> I added a persistent question here: https://askubuntu.com/questions/1379811/usrmerge-of-bin-sbin-lib-how-is-the-system-supposed-to-be
[02:46] <DarkTrick> I hope I got the details right. I hope for a quick answer to straighten out my system :)
[03:08] <mwhudson> sarnold: using do-release-upgrade vs editing /apt/sources.list directly?
[03:09] <sarnold> mwhudson: do-release-upgrade, heh, that was my first question :)
[03:09] <sarnold> oh hah DarkTrick's in here, too :) I guess I'm not super-observant
[03:10] <mwhudson> although usrmerge is recommended by ubuntu-minimal now so you'd have to try moderately hard not to have it?
[03:12] <sarnold> mwhudson: hmnm, maybe; I certainly went through an awkard enough install process myself that I'm not surprised I don't have the usrmerge package installed, but I *do* have the /bin -> /usr/bin etc symlinks. (I don't understand it.)
[03:12] <mwhudson> sarnold: well either your system came that way or you had it and uninstalled it i guess?
[03:12] <sarnold> mwhudson: bashing-om probably didn't go to much effort to avoid usrmerge, but he doesn't have the symlinks; he's probably got an old install upgraded a few times though
[03:13] <sarnold> mwhudson: my system is the ubuntu root on zfs with luks guide, who knows what exactly that is :) that's why I'm so surprised I've got the symlinks..
[03:13] <mwhudson> sarnold: which version did you start with?
[03:14] <sarnold> mwhudson: oh that's an excellent question. do you know off-hand where apport gets that from? :)
[03:15] <mwhudson> sarnold: /var/lib/something/media-info
[03:15] <mwhudson> or something
[03:15] <mwhudson> ah v
[03:15] <mwhudson> /var/log/installer/media-info
[03:16] <mwhudson> of course i can't remember when we started making merged images so
[03:17] <sarnold> mwhudson: thanks, not on this system :( bummer.
[03:17] <sarnold> mwhudson: my memory is something like 19.10 but .. it's a very fuzzy memory.
[03:19] <mwhudson> sarnold: debian enabled merged-usr by default in jun 2018 it seems, not sure about ubuntu
[03:19] <DarkTrick> Just for reference, I started with 18, I think
[03:19] <mwhudson> (default in debootstrap)
[03:20] <DarkTrick> mwhudson, that means I should've had a merged dir from the beginning, but I don't ....
[03:20] <mwhudson> DarkTrick: 18.what?
[03:20] <sarnold> mwhudson: oh! that'd do it.. my install was debootstrap :)
[03:20] <mwhudson> 18.04 wouldn't
[03:20] <mwhudson> 18.10 might have?
[03:20] <DarkTrick> mwhudson, the LTS version
[03:20] <mwhudson> yeah that's 18.04
[03:21]  * DarkTrick was sooo close...
[03:21] <mwhudson> ah i think disco / 19.04 + were merged by default
[03:22] <mwhudson> maybe?
[03:22] <mwhudson> somewhere around then
[03:25] <DarkTrick> mwhudson, so I understand it's rather recommended to have usrmerge (?) and if not I should get it
[03:26] <DarkTrick> what about symlinks for individual files VS symlinks of the whole directory, like sarnold has?
[03:26] <mwhudson> DarkTrick: yes i think for impish+ the idea is that unmerged is no longer supported, not sure though
[03:26] <mwhudson> DarkTrick: uh no, symlinks from /bin to /usr/bin etc is the expectation
[03:26] <mwhudson> there are long and tedious arguments on debian-devel about this
[03:27] <DarkTrick> mwhudson, so, the whole directory, right?
[03:27] <mwhudson> yea
[03:27] <DarkTrick> is this what would be done if I'd call `usrmerge` ?
[03:27] <DarkTrick> (the program)
[03:27] <mwhudson> well it
[03:28] <mwhudson> well it's all done by installing the package
[03:28] <mwhudson> it does all the stuff in it's maintainer scripts i think
[03:28] <DarkTrick> mwhudson, I have the package, but it's not merged
[03:28] <mwhudson> if your system is already wedged i don't know if it's going to work though
[03:28] <mwhudson> DarkTrick: uhh
[03:28]  * mwhudson checks some confidently made assertions
[03:29] <DarkTrick> worst case would be to manually move all non-links to /usr/* and create a symlink to the folder?
[03:29] <mwhudson> DarkTrick: congratulations, i guess?
[03:30] <mwhudson> DarkTrick: /usr/lib/usrmerge/convert-usrmerge is the script that does the deed
[03:30] <DarkTrick> so either I break my system now or I fix it :D
[03:30] <mwhudson> i'm not sure i'd be brave enough to do this by hand
[03:31] <DarkTrick> who needs a casino, I have Ubuntu xD
[03:31] <mwhudson> there are going to be moments during the process where the system is in a very strange state i assume
[03:31] <mwhudson> like /lib64/ld-linux-x86-64.so.2 being a dangling symlink
[03:32] <sarnold> maybe start a root sash or busybox first? enable all tools? something like that..
[03:33] <mwhudson> reboot with break=bottom, run chroot /root /usr/lib/usrmerge/convert-usrmerge ?
[03:33] <mwhudson> anyway good luck!
[03:35] <sarnold> mwhudson: wat
[03:35] <mwhudson> sarnold: doing it all from the initrd
[03:35] <sarnold> mwhudson: google's giving me nothing but swimwear photos
[03:36] <sarnold> https://sources.debian.org/src/debirf/0.38/src/debirf/?hl=219#L219
[03:36] <sarnold> what the heck is debirf? :)
[03:39] <sarnold> here we go, this is more like it https://sources.debian.org/src/initramfs-tools/0.140/init/?hl=254#L159
[03:40] <mwhudson> sarnold: "build a kernel and initrd to run Debian from RAM"
[03:40] <mwhudson> not heard of that one
[03:41] <sarnold> mwhudson: ohhh hmm that might be useful, I've wondered before if my power9 system would be more reliable if I ran it from tmpfs or ramdisk.. (*sniff*)
[10:11] <juliank>   File "/snap/git-ubuntu/660/usr/lib/python3/dist-packages/gitubuntu/prepare_upload.py", line 112, in push
[10:11] <juliank>     assert gitubuntu.importer.VCS_GIT_URL_VALIDATION.fullmatch(
[10:11] <juliank> hooray?
[10:36] <juliank> The reason for this is I had insteadOf configured for launchpad so it always uses ssh to talk to it
[12:07] <rbasak> juliank: ah - so git-ubuntu is unable to determine what URL to put in the changes file for you that doesn't use insteadOf.
[12:08] <juliank> rbasak: basically same cause as https://bugs.launchpad.net/usd-importer/+bug/1942985
[12:09] <rbasak> I'm not sure if git-ubuntu should expand insteadOf or not. It'd be nice if it did, but I'm not keen on chasing that functionality. It'd be nice if git could expand it for us.
[12:09] <juliank> rbasak: well, a fix for that will fix mine too; though maybe insteadOf is easier to fix itself by an option somewhere to not follow insteadOf
[12:09] <rbasak> No, I think it's a different bug.
[12:09] <juliank> rbasak: No, the issue is that insteadOf expands the normal https:// url that git-ubuntu configured to ssh://
[12:09] <juliank> s/expands/replaces/
[12:09] <rbasak> Oh, OK.
[12:09] <rbasak> So there's another failure case here too.
[12:10] <juliank> And pygit2 follows insteadOf apparently when you calculate the uri
[12:10] <rbasak> If someone uses insteadOf to create a virtual alias such as lp:, then that won't work either.
[12:10] <juliank> right, I have
[12:10] <juliank> [url "git+ssh://juliank@git.launchpad.net/"]
[12:10] <juliank> insteadOf = lp:
[12:10] <juliank> insteadOf = https://git.launchpad.net/
[12:11] <juliank> so pygit2 returned git+ssh:// instead of whatever git-ubuntu actually configured in .git/config
[12:12] <rbasak> "git-ubuntu clone" configures https://git.launchpad.net/...
[12:12] <rbasak> (for fetch; git+ssh for push)
[12:12] <juliank> yes
[12:12] <juliank> didn't want to write it :)
[12:12] <rbasak> I agree then that Christian's bug fixed will also fix your issue.
[12:13] <rbasak> Sort of by accident though. I think git-ubuntu should indeed be using the actual URL used. But this one can be special cased.
[12:56] <DarkTrick> mwhudson, sarnold: Just back from work. I thought I'd follow up on my problem: usrmerge did only help half way: if two files exist it will report that one, single file, you have to solve it by hand, run again and wait for the next error to occur and handle. I ended up changing the usrmerge script to rename files instead of throw errors. So far everything seems ok.
[14:14] <mapreri> ddstreet, teward: I wrote up a core-dev application.  I'd be happy if you could write something about me ^^ https://wiki.ubuntu.com/MattiaRizzolo/CoreDevApplication
[19:42] <sarnold> DarkTrick: oh! that's a clever fix to make it run reasonable speed :)
[19:43] <Unit193> mapreri: G'luck!
[20:58] <Unit193> ahasenack: Looks like it's all merged, so I guess that's good then.
[20:59] <ahasenack> I proposed a PR in salsa too, but I have to update it with what I have actually uploaded
[20:59] <ahasenack> there was some review feedback on the ubuntu side that made me change it a bit
[21:18] <Unit193> Yeah, saw that bit about tests failing not actually failing the build and all.