| cpaelzer | rbasak: I saw the effect of gpsd re-import - looks fine to me | 04:51 |
|---|---|---|
| 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 | 04:52 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| mitya57 | Debian's buildd name is rv-rr44-01, looks like it's also used for sid. | 07:55 |
| 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:57 |
| 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? | 07:58 |
| mitya57 | I wonder how I can check that | 08:00 |
| wgrant | mitya57: We print it at the top of our build logs, but I forget if Debian does | 08:01 |
| mitya57 | wgrant: found it, Kernel: Linux 5.6.3+ #1 SMP Thu Apr 16 06:33:06 UTC 2020 riscv64 (riscv64) | 08:03 |
| mitya57 | wgrant: The last successful build was with 5.0.0+, and the first failing build was with 5.5.0-1-riscv64. | 08:05 |
| mitya57 | And the last successful build in Ubuntu was with 5.3.0-13-generic, so it may confirm your hypothesis. | 08:06 |
| 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:07 |
| wgrant | Will try to run a few scenarios tomorrow, including on hardware, and see what turns up | 08:08 |
| mitya57 | wgrant: ok, thanks | 08:09 |
| LocutusOfBorg | wgrant, do you think we can backport qemu to support riscv64 on bionic? | 08:31 |
| 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 | 08:46 |
| === Nafallo_ is now known as Nafallo | ||
| LocutusOfBorg | wgrant, thanks a lot! I tried to backport it by myself but it was needing too much effort | 09:49 |
| 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:58 |
| wgrant | LocutusOfBorg: Hm, is that not in the PPA too? | 09:59 |
| 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:02 |
| LocutusOfBorg | but its ok, I already have the new qemu now :) thanks! | 10:03 |
| 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:04 |
| 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:06 |
| 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:17 |
| wgrant | Oh, qemu-user, right | 10:18 |
| LocutusOfBorg | yay | 10:18 |
| LocutusOfBorg | it has been successfully created thanks! | 10:19 |
| LocutusOfBorg | now I lost my interest in upgrading bionic to focal, thanks to you :p | 10:19 |
| cpaelzer | fighting with i386 a bit and dependencies - is there a md->man converter that is available on Ubuntu i386? | 12:14 |
| 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:15 |
| juliank | cpaelzer: can you build that on amd64? | 12:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| cpaelzer | making an arch neutral -doc package was my next best guess already | 12:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:50 |
| kanashiro | thanks wgrant | 12:51 |
| rbasak | cpaelzer: on bug 1873415 | 13:29 |
| ubottu | 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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 |
| ubottu | Launchpad bug 62976 in Launchpad itself "Soyuz should not allow duplicated packages in NEW/UNAPPROVED queue" [High,Triaged] | 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:39 |
| 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:40 |
| 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! | 13:41 |
| === 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 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!