[04:51] <cpaelzer> rbasak: I saw the effect of gpsd re-import - looks fine to me
[04:52] <cpaelzer> LP showed odd-diffs on existing MPs, but they at least still existed
[04:52] <cpaelzer> I could easily rebase from old to new without anyy problem
[07:51] <mitya57> wgrant, doko: Hi, we get internal compiler error when building qtbase 5.14 for riscv64, see https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4057/+build/19293614
[07:52] <mitya57> We retried it two times, it fails each time in a different file, but early enough in the build process, so there is little hope that further retries will help.
[07:53] <mitya57> Do you know what I can do about this? A similar thing happens in Debian (experimental).
[07:53] <wgrant> mitya57: Ugh, thanks for the poke, I thought that was fixed with new qemu etc. Sounds like I'll have to downgrade the buildds again
[07:53] <wgrant> Oh, interesting
[07:53] <wgrant> Oh experimental is still on qemu iirc
[07:53] <wgrant> So it could be the same thing
[07:54] <wgrant> There's a bug in either the new qemu, OpenSBI or Linux that seems only break really heavy g++ runs
[07:54] <wgrant> But at least this one seems to repro quickly enough
[07:55] <mitya57> Debian's buildd name is rv-rr44-01, looks like it's also used for sid.
[07:57] <wgrant> Oh interesting, that one is real hardware.
[07:57] <wgrant> So maybe this isn't the thing we saw a month ago which was fixed by the qemu downgrade
[07:58] <wgrant> There was also a potential issue with Linux 5.4 over 5.3, but I wasn't able to reproduce it. Which kernel is the Debian one running?
[08:00] <mitya57> I wonder how I can check that
[08:01] <wgrant> mitya57: We print it at the top of our build logs, but I forget if Debian does
[08:03] <mitya57> wgrant: found it, Kernel: Linux 5.6.3+ #1 SMP Thu Apr 16 06:33:06 UTC 2020 riscv64 (riscv64)
[08:05] <mitya57> wgrant: The last successful build was with 5.0.0+, and the first failing build was with 5.5.0-1-riscv64.
[08:06] <mitya57> And the last successful build in Ubuntu was with 5.3.0-13-generic, so it may confirm your hypothesis.
[08:07] <wgrant> Ubuntu also has a new qemu and firmware, so it's not definitive, but I definitely saw at least one similar crash that I believe I isolated to the new kernel
[08:08] <wgrant> Will try to run a few scenarios tomorrow, including on hardware, and see what turns up
[08:09] <mitya57> wgrant: ok, thanks
[08:31] <LocutusOfBorg> wgrant, do you think we can backport qemu to support riscv64 on bionic?
[08:46] <wgrant> LocutusOfBorg: Ubuntu Cloud Archive contains backports of qemu. https://wiki.ubuntu.com/OpenStack/CloudArchive#Ussuri is what's running on the prod builders atm
[09:49] <LocutusOfBorg> wgrant, thanks a lot! I tried to backport it by myself but it was needing too much effort
[09:58] <LocutusOfBorg> wgrant, looks like the same issue I faced  qemu-block-extra : Depends: libssh-4 (>= 0.8.4) but 0.8.0~20170825.94fa1e38-1ubuntu0.6 is to be installed
[09:58] <LocutusOfBorg> how can I install something like that?
[09:59] <wgrant> LocutusOfBorg: Hm, is that not in the PPA too?
[10:02] <LocutusOfBorg> nope, not in sudo add-apt-repository cloud-archive:ussuri
[10:02] <LocutusOfBorg> I think I can fix via sudo add-apt-repository ppa:ubuntu-cloud-archive/ussuri-staging
[10:02] <LocutusOfBorg> or sudo add-apt-repository ppa:openstack-ubuntu-testing/ussuri
[10:03] <LocutusOfBorg> but its ok, I already have the new qemu now :) thanks!
[10:04] <wgrant> Huh, maybe that's not fully done yet. But yeah, I actually used ussuri-staging
[10:04] <LocutusOfBorg> I'm already creating a riscv64 chroot now :) thanks!
[10:06] <wgrant> LocutusOfBorg: Nice, let me know if you run into any trouble.
[10:06] <wgrant> LocutusOfBorg: Are you using the image from https://people.ubuntu.com/~wgrant/riscv64/ or building your own?
[10:17] <LocutusOfBorg> building myself
[10:17] <LocutusOfBorg> pbuilder-dist groovy riscv64 create
[10:17] <LocutusOfBorg> I don't like pre-built stuff ;)
[10:17] <wgrant> LocutusOfBorg: Oh, I meant to boot the system
[10:17] <wgrant> On the chroot, yes, I agree
[10:17] <LocutusOfBorg> I don't care about booting, I care about debugging build issues for now!
[10:18] <wgrant> Oh, qemu-user, right
[10:18] <LocutusOfBorg> yay
[10:19] <LocutusOfBorg> it has been successfully created thanks!
[10:19] <LocutusOfBorg> now I lost my interest in upgrading bionic to focal, thanks to you :p
[12:14] <cpaelzer> fighting with i386 a bit and dependencies - is there a md->man converter that is available on Ubuntu i386?
[12:15] <cpaelzer> the project I look at by default uses pandoc, but that isn't on Ubuntu i386
[12:15] <cpaelzer> is there an established common way to go on i386 build deps for md->man?
[12:35] <juliank> cpaelzer: can you build that on amd64?
[12:36] <juliank> nobody should need docs on i386
[12:36] <juliank> you can't just switch out pandoc for something else, that's not going to work - markdown syntax is specific to the tool
[12:37] <wgrant> There are a scary number of things that need pandoc for their arch build, though you'd think those could mostly end up in -common or -doc :(
[12:37] <wgrant> You can get basically nowhere with an arch bootstrap without pandoc
[12:38] <juliank> wgrant: I feel like i386 builders should have amd64 as a foreign architecture, so it can use amd64 pandoc
[12:38] <wgrant> (and pandoc brings in several hundred deps)
[12:38] <juliank> it's m-a foreign after all
[12:38] <wgrant> Making ports not self-hosting is a non-trivial decision.
[12:39] <cpaelzer> making an arch neutral -doc package was my next best guess already
[12:40] <cpaelzer> seems you confirm these thoughts (and destroy my hope of an easier way out)
[12:40] <juliank> heh or just don't build the docs on i386 or fake pandoc
[12:40] <cpaelzer> "just don't build the docs on i386" is what we do atm - but strictly speaking that is against the policy
[12:40] <wgrant> Yeah, I suppose a -dev without docs on i386 wouldn't be the end of the world.
[12:41] <cpaelzer> I need to get this to Debian which still cares about i386
[12:41] <juliank> don't get it there and carry a delta
[12:41] <juliank> it depends on whether it makes sense splitting out doc or not
[12:42] <cpaelzer> I can ask if they'd be open to split it
[12:42] <juliank> I've had ftpmaster reject packages because they were too small
[12:42] <cpaelzer> this is the only delta the pkg has, so dropping it would make it a sync again and reduce the maintenance-toll
[12:43] <juliank> ack
[12:43] <cpaelzer> thanks for your hints juliank and wgrant - I'll give it a try and ask
[12:43] <cpaelzer> asking never hurts
[12:44] <wgrant> We already have to carry a bunch of deltas for the partial port
[12:44] <kanashiro> hi, I have a build failure on riscv and I'd like to reproduce it. What is the best way to setup a riscv build environment locally? I found this Debian doc: https://wiki.debian.org/RISC-V#Setting_up_a_riscv64_virtual_machine
[12:45] <kanashiro> wgrant: ^
[12:45] <wgrant> kanashiro: https://people.ubuntu.com/~wgrant/riscv64
[12:45] <wgrant> Has images and instructions
[12:45] <wgrant> Which is the failure?
[12:46] <kanashiro> wgrant: https://launchpadlibrarian.net/479313809/buildlog_ubuntu-groovy-riscv64.ruby2.7_2.7.1-3_BUILDING.txt.gz
[12:46] <kanashiro> the same in Focal
[12:47] <kanashiro> https://launchpad.net/ubuntu/+source/ruby2.7/2.7.0-5ubuntu1.1/+build/19295534/+files/buildlog_ubuntu-focal-riscv64.ruby2.7_2.7.0-5ubuntu1.1_BUILDING.txt.gz
[12:47] <wgrant> That might be the same thing that qtbase ran into, which seems to be some kind of bug in the new kernel or qemu
[12:47] <wgrant> They've all been upgraded since the final focal builds, and there are a couple of new mysterious failures in some heavy gcc runs
[12:50] <kanashiro> yeah I was considering something like that because I am quite sure the changes in the package did not trigger the failure
[12:50] <wgrant> Good to have another test case. I'll hopefully investigate it tomorrow, or just downgrade all the VMs again and see if they work
[12:51] <kanashiro> thanks wgrant
[13:29] <rbasak> cpaelzer: on bug 1873415
[13:30] <rbasak> I'm not convinced that this change is justified in an SRU, even if bundled in other changes - because of the conffile prompt issue
[13:30] <cpaelzer> rbasak: yeah of the three bugs in this SRU this is the least important
[13:30] <rbasak> I'm willing to be persudaded
[13:30] <cpaelzer> not worth on its own, but along the others it will help users
[13:30] <cpaelzer> rbasak: starting persuasion
[13:30] <rbasak> But my feeling is that if it's the mere knowledge of existence of the tunable is the reason, that's not worth a conffile prompt for users who tune
[13:31] <cpaelzer> rbasak: lets's break into the potential cases that might happen
[13:31] <rbasak> And that documentation elsewhere would be more suitable
[13:31] <cpaelzer> rbasak: this file is not commonly modified, so the majority will not get a conffile prompt
[13:31] <cpaelzer> rbasak: as checksums will match
[13:31] <rbasak> Agreed, though the same is generally true of all conffile prompts
[13:31] <cpaelzer> oh wait
[13:31] <rbasak> The file mentions dpkg-reconfigure
[13:32] <cpaelzer> I have too many SRUs in flight
[13:32] <cpaelzer> this default file
[13:32] <cpaelzer> no it is actually rather common to have that one modified
[13:32] <rbasak> So "checksums" alarms me a little. Should debconf be being used in the usual way, so no maintainer script managed checksums present?
[13:32] <cpaelzer> to set the device you want it to operate on
[13:33] <cpaelzer> rbasak: you know what - I wanted to help the users with that - if you think it violated the SRU policy let me strip it
[13:33] <cpaelzer> rbasak: the important ones are the others
[13:33] <rbasak> No specific policy here
[13:33] <rbasak> TO be clear
[13:33] <cpaelzer> rbasak: could you cancel the upload from -unapproved and I'll push a new one in a minute?
[13:33] <rbasak> Just a user impact concern
[13:33] <rbasak> Sure, if you prefer
[13:34] <cpaelzer> it is a corner case in a not too common package - not worth having us discuss 20 minutes longer
[13:34] <rbasak> I don't mind talking it through though. I'm still open to more details and persuasion :)
[13:34] <rbasak> OK
[13:34] <cpaelzer> I'll not waste my SRU persuade credits on this case
[13:36] <rbasak> The apparmor changes looked fine to me
[13:36] <cpaelzer> to me as well :-)
[13:36] <cpaelzer> rbasak: I'm ready to re-upload
[13:36] <rbasak> I'll double check but they seem appropriate, even though there's also a conffile prompt risk there!
[13:36] <cpaelzer> rbasak: did you cancel the old one already?
[13:36] <rbasak> I've rejected but you don't need to wait for that anyway :)
[13:37] <cpaelzer> rbasak: I have to wait - othersiw I'll get the "version is already there" reject
[13:37] <rbasak> Really?
[13:37] <rbasak> Is that a new thing?
[13:37] <cpaelzer> I did in the past and since then avoid it
[13:38] <cpaelzer> haven't retried
[13:38] <cpaelzer> rbasak: new upload should be in the queue
[13:38] <rbasak> I was fairly sure that this doesn't happen. I will experiment at the next opportunity :)
[13:38] <cpaelzer> rbasak: and on the apparmor change - the conffile-prompt there exists but isn't a blocker of any sort
[13:38] <cpaelzer> otherwise we'd never fix aa profiles :-)
[13:38] <rbasak> Yes - it will stop the fix if somebody has their own changes
[13:39] <cpaelzer> also the gain by the fix is much much higher than the one we had on the USBAUTO variable
[13:39] <cjwatson> cpaelzer: I believe you are mistaken
[13:39] <rbasak> But the request for the merge is correct and the user will have .dpkg-new there in that case and that's the best we can do
[13:39] <cpaelzer> cjwatson: am I, ok maybe it is bad memory
[13:39] <cjwatson> cpaelzer: It's an extremely long-standing bug (arguably) that what you describe *doesn't* happen.  https://bugs.launchpad.net/launchpad/+bug/62976
[13:39] <cpaelzer> cjwatson: you'd expect the new upload to overwrite the old one?
[13:39] <cpaelzer> oh duplicate
[13:39] <cpaelzer> thanks for the info cjwatson
[13:40] <cjwatson> It's not completely clear what should happen, but the current situation permits results that are very confusing
[13:40] <cpaelzer> I still perfer to properly cancel and then upload it then - to avoid any ambiguity
[13:40] <rbasak> cjwatson: personally I find the current behaviour useful, as it doesn't block the uploader from superseding and the person processing the queue can easily enough sort it out with no real extra effort
[13:40] <cjwatson> rbasak: I tend to think that uploaders should be able to self-reject, which would help with that, I think
[13:40] <rbasak> Agreed
[13:41] <rbasak> If you change things, please enable that first :)
[13:41] <cpaelzer> rbasak: ping me if you find anything worth to discuss on the apparmor changes then
[13:41] <rbasak> ack
[13:41] <cjwatson> Right, it certainly needs systemic thought rather than just changing that one thing.  I'll make a note in the bug
[13:41] <rbasak> Thanks!