User1: xevious, seen our video?  https://www.youtube.com/watch?v=f6UHXkND4Sc
User2: WAIT Canvas rotation??
User2: Great video! Thanks for the link
User3: ddstreet, hey, could you commit your network-manager fixes to the vcs?
User4: seb128 sure, i forgot again, sorry
User3: ddstreet, np!
User5: Hey. Has Focal been left out from https://changelogs.ubuntu.com/meta-release-lts on purpose, perhaps waiting for the first point release?
User5: Laney, maybe you know this bit ^^
User6: LTS to LTS usually is available at the first point release.
User5: Hi Unit193 :) I thought that was the reason. Yet I think it prevents `do-release-upgrade -d` from upgrading from focal to groovy
User5: Maybe Focal should be put in meta-release, and put in meta-release-lts after .1 is out?
User6: I believe you can change the prompt in /etc/update-manager/* to 'normal'
User5: Unit193, yeah, that doesn't work
User5: actually I quite remember it working on my laptop just a few days after the Focal release, now I can't get it working anymore, and can easily reproduce it on a Focal LXD container
User6: Development usually takes a month or two for a normal upgrade, I *think*.  I could be wrong.
User5: OK, maybe everything is just as it should be
User6: The LTS choice obviously won't ever offer groovy.
User6: If you want to hop, you can use the Debian way.
User5: That works, I'm already using Focal on my laptop, but now I wanted to upgrade a development machine and I was surprised of not being able to do so using do-release-upgrade
User5: this with Prompt=normal in /etc/update-manager/release-upgrades
User7: Hi, I have a very weird FTBFS in bionic that still worked 4 weeks ago, after tracking down what I thought to be the root cause I'm kind of lost - there must be a rootier one that I still miss.
User7: it comes down to a puzzling 'warning: "sizeof" is not defined, evaluates to 0 [-Wundef]'
User8: User5 It's really a bdmurray thing, but it's in meta-release-lts-development which I think is normal
User7: shouldn't that be part of the language - how can it be missing?
User8: for upgrading to *groovy*, perhaps we want groovy in meta-release-development, not sure
User7: to make it more weird, not only did it work a few weeks ago - it also works in a bionic-VM but fails in a bionic-sbuild chroot
User5: Laney, thanks, I missed the -development one. Let's wait for bdmurray then.
User7: doko: ^^ would you have any idea why sizeof could be considered missing?
User9: User7 I think anyone looking at this is going to need more context
User7: I didn't want to drop too much text into IRC, but you are right cjwatson - anyone needing more context can find it in https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1847361/comments/55 and later comments
User10: Launchpad bug 1847361 in qemu (Ubuntu Eoan) "Upgrade of qemu binaries causes running instances not able to dynamically load modules" [Undecided,Fix committed]
User5: juliank, hi. On https://bugs.launchpad.net/ubuntu/+source/rust-ripgrep/+bug/1868517 , it seems to me that fd-find *does* include the file
User10: Launchpad bug 1868517 in rust-fd-find (Ubuntu) "Stray /usr/.crates2.json file" [Undecided,Incomplete]
User11: User5 where?
User5: /usr/lib/cargo/.crates2.json as the others
User11: User5 I looked at the deb on amd64, and it's not in there
User5: oops that's the normal place for that file to be?
User11: User5 huh, now i see it
User11: Not sure what happened, sorry
User11: User5 Ah, I guess it installs into a different place
User11: User5 The others install into /usr/.crates2.json, this installs to /usr/lib/cargo/.crates2.json
User5: not sure on the reason for the difference, but I think we want it rebuilt too
User11: Also dotenv needs rebuild too
User11: User5 I basically piped apt-file find /usr/.crates2.json output to rebuild-for script, hence did not notice /usr/lib/cargo ones
User11: Building rebuilds
User5: that was certainly a good idea. I didn't notice some packages put that file elsewhere
User5: thanks!
User11: rebuilds uploaded
User11: I think some stuff is FTBFS
User5: :/
User11: Yeah rust-sniffglue
User11: sbuild-build-depends-rust-sniffglue-dummy : Depends: librust-syscallz-0.12+default-dev
User11: not sure what's going on there
User11: as the matching librust-syscallz is in proposed
User11: provided by librust-syscallz-dev 0.12.0-1 (= 0.12.0-1)
User11: it's also not in dep-wait, which you'd expect if the dep were missing
User12: anyone able to review https://code.launchpad.net/~chad.smith/ubuntu/+source/sbuild-launchpad-chroot/+git/sbuild-launchpad-chroot/+merge/382529 and comment on bug 1872163 ?
User10: bug 1872163 in sbuild-launchpad-chroot (Ubuntu) "focal chroots broken due to change in sources.list" [Undecided,Confirmed] https://launchpad.net/bugs/1872163
User12: how is it that sbuild-launchpad-chroot can be so busted?
User13: User15 here's the fix for your bug: https://code.launchpad.net/~racb/usd-importer/+git/usd-importer/+merge/383513
User13: If you fancy reviewing it, but if not I guess bryce will get to it?
User13: I'm going to hold on announcing 0.10 and put this in a 0.10.1 instead.
User14: User12 It's in universe, who would you expect to be making sure it isn't busted?
User15: User13 ok for 0.10.1
User15: yeah, I'll let him review
User12: User14 I honestly thought that package specifically was used by developers.
User12: so... "everyone".
User12: it really is the easiest way to get a launchpad-like build environment locally.
User14: User12 I wasn't aware of it until I joined the server team, FWIW.
User12: i didn't use it until i was aware of it either.
User12: and i had some list of "create and  maintain schroot" commands
User12: that never exactly mimic'd what was on launchpad
User12: and were a pita to set up
User13: User7 reimport of qemu, chrony and gpsd in progress. They will be force pushed as they complete. I'll let you know.
User7: thanks rbasak
User16: hi, could someone please sponsor this upload to groovy https://code.launchpad.net/~ack/ubuntu/+source/maas/+git/maas/+merge/383411 ?
User13: User7 gpsd done. qemu still in progress. chrony failed - more on that after I investigate.
User13: I've just spotted a potential problem in the gpsd reimport
User13: Only minor but will cause hash mutation, so I may have to reimport again after fixing it
User16: juliank, hi, any chance you could take a look at the MP above? ^
User11: User16 not today likely
User16: juliank, ok, no worries. it's not super-urgent
User11: User16 If still needed, ping me tomorrow at 9 CEST?
User11: Or I can look myself
User11: s/at/after|around/
User16: juliank, yeah sure, thanks
User7: ok rbasak
User7: png me once done
User17: waveform, FYI https://ograblog.wordpress.com/2020/05/06/using-the-new-12mp-pi-cam-for-video-conferencing-on-your-desktop/ ... the new cam works really well on UbuntuCore18 !
User18: is there a command line tool to print out your own launchpad ppas?
User13: User18 lp-shell -c'print("\n".join(ppa.web_link for ppa in lp.me.ppas_collection))'
User13: Or if you want something other than the web_link, choose from https://launchpad.net/+apidoc/devel.html#archive
User19: User20 Looks like a nasty dep-wait on inkscape for i386. I talked to vorlon about it, and he said it was another component that is FTBFS causing the problem?
User19: I had to remove inkscape from Ubuntu Studio
User19: Temporarily
User13: User7 bug found and fix proposed: https://code.launchpad.net/~racb/usd-importer/+git/usd-importer/+merge/383522
User13: User7 qemu is still going. I'll cancel it.
User13: User7 so the current status is: qemu and chrony: no changes yet, until I land a bugfix. gpsd is reimported, but I'm afraid I'll have to do it again after the bugfix lands. Sorry.
User13: And thank you for letting me test on you!
User18: User13 nice, thanks
 * rharper finds lptools
User20: Eickmeyer, should we keep inkscape/i386? vorlon ^
User20: ?
User21: User20 yes, the germinate output will tell you why.
 * Eickmeyer has no objections to removing inkscape/i386
User20: I'm not sure I know that germinate link
User20: https://people.canonical.com/~ubuntu-archive/germinate-output/ ?
User21: https://people.canonical.com/~ubuntu-archive/germinate-output/i386.groovy/
User20: pacemaker
User20: https://people.canonical.com/~ubuntu-archive//germinate-output/i386.groovy/rdepends/inkscape/inkscape
User20: and game-data-packager
User20: sigh
User19: Well, wonderful.
User20: I wanted to fix riscv64, and looks like I got it right
User19: Yeah, so far so good.
User20: next step after I finish this bootstrap is to look at it
User20: https://bileto.ubuntu.com/#/ticket/4042
User19: The issue with inkscape/i386 is gtkmm3.0/i386 which is FTBFS, looks like it will need some work that is way over my head.
User22: rbasak, I think I know what's going on with the git-ubuntu u-boot merge
 * ahasenack thinks under the water
User22: rbasak, the thing that got committed as the 2019.07+dfsg-1 commit wasn't *quite* 2019.07+dfsg-1; there's several files in there that shouldn't be
User22: rbasak, specifically the rpi patches (and u-boot-rpi.postinst) which are unique to us; I must've done something wrong in that rebase, and it didn't get caught. Anyway it means that there's no commit there that can be accurately marked as import/2019.07+dfsg-1
User22: rbasak, if you want to fix up the history by burning the manually imported commits there I'm okay with that?
User13: User22 thanks; I'll look at it later if that's OK
User23: apt-get install libclang-9-dev
User23: The following packages have unmet dependencies:
User23: lib32gcc1 : Depends: gcc-10-base (= 10-20200425-1ubuntu2) but 10-20200502-1ubuntu1 is to be installed
User23: doko: ? ^
User22: rbasak, sure - no prob - ping me if you need any details
User24: User5 thanks for the review on my sbuild-launchpad-chroot branch & smoser for continued efforts there
ubuntu-devel
Ubuntu IRC