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