[01:50] <xnox> most things seem to work, but riscv builders are having Unable to connect to ftpmaster.internal:http: others are doing fine so far.
=== ebarretto_ is now known as ebarretto
=== cjwatson changed the topic of #ubuntu-devel to: Archive: Beta Freeze, Feature Freeze, Debian Import Freeze | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Focal | If you can't send messages here, authenticate to NickServ first | Patch Pilots:
[08:34] <cjwatson> (last night, but I forgot the topic change here)
[08:34] <cjwatson> riscv64 is being fixed
[09:39] <slyon> rbasak: hey! If you're doing some SRUs today, I'd be glad if you could have a look at netplan 0.100 (stuck in Focal unnaproved queue), LP: #1894197
[09:39] <ubottu> Launchpad bug 1894197 in netplan.io (Ubuntu) "[SRU][FFe] Update to netplan.io 0.100" [High,In progress] https://launchpad.net/bugs/1894197
[10:15] <rbasak> tdaitx: I'm reviewing pdfsam/libsejda-java again now. Your pdfsam upload is missing a bug reference. Could you fix that up if you're around please while I continue reviewing? Or else I can do it.
[10:15] <rbasak> slyon: I'll get to that next
[10:16] <rbasak> tdaitx: oh, I'm sorry
[10:16] <rbasak> I see what you did. Interesting.
[10:16] <rbasak> I think I'd prefer it to have been more explicit but it's fine as it is.
[10:17] <slyon> thank you!
[10:30] <rbasak> slyon: disabling build time tests on riscv64 would be a regression on Focal from what we previously had. Can you do better by only skipping the irrelevant tests, rather than the whole test suite?
[10:34] <slyon> rbasak: its not really broken... but "temporary" disabled, due to a missing openvswitch build in Focal/riscv64... the OVS 2.13.1-0ubuntu0.20.04.1 SRU should actually fix it and we could re-enable all tests again
[10:34] <slyon> I just didn't want to block on OVS release, as riscv isn't widely used
[10:35] <rbasak> How is it that it worked previously?
[10:36] <slyon> older netplan didn't have OVS support and thus didn't need the openvswitch dependency
[10:37] <rbasak> Do all your test require OVS, or just some of them?
[10:37] <rbasak> Presumably just the new ones?
[10:37] <rbasak> So can't you add a skip on just those ones instead of disabling the rest of the test suite with it?
[10:38] <xnox> all three users of riscv64 agree to watch out for netplan regressions =)
[10:39] <slyon> yeah not all of them... but I would need to adopt test test suite to skip test depending on architecture. Which seems overkill right now. I'd rather like to re-enable all test again with the next upload once OVS is available for Focal/riscv64
[10:41] <rbasak> I don't like the lack of care for an architecture just because we don't think it's an important enough architecture. Apparently Ubuntu considered it important enough to release with it, and so I think we need to use that standard.
[10:41] <rbasak> Adding new features like this is predicated on having good test coverage, and so it seems wrong to me just to turn that off for one architecture
[10:42] <rbasak> Skipping some tests based on architecture really shouldn't be difficult unless I'm missing something - and as straightforward to review as the current patch
[10:42] <rbasak> So I think we should either do that, or wait on OVS support on Focal
[10:43] <rbasak> I'm happy to seek wider SRU team opinion if you like
[10:45] <slyon> I totally get your point... sil2100 already ack'ed that patch, but didn't want to work on the SRU, as he sponsored it
[10:47] <rbasak> How would you like to proceed?
[10:47] <slyon> The cleanest solution would probably be to wait for OVS support on Focal, and then just running all tests as it should be :-/ Although I think that most test are skipped anyways for riscv64 on the infrastructure
[10:48] <slyon> So I guess we should wait and I'll prepare a new upload with all tests enabled... sorry for pushing on this
[10:49] <xnox> mvo:  the more i dig into the grub configuration test case, the more scary it looks. As if the image is built & has grub-pc (bios) installed. Yet debconf is configured to never attempt updating grub. When clearly it is using the bios bootloader to boot.
[10:49] <xnox> mvo:  meaning that system, will forever have out of date bootloader installed in mbr =(
[10:49] <rbasak> OK. That's fine with me. I'll make a note in the bug, and then as this won't go in as-is then I'll reject it from the queue.
[10:50] <slyon> Alright
[10:51] <rbasak> It just seems to me that as we're trying to make riscv64 both in original bringup and on an ongoing basis, disabling stuff like this is a step backwards - and doubly so to regress this in an SRU.
[10:53] <slyon> You're right. I wanted to take a temporary shortcut there, which is not the correct thing to do.
[11:10] <mvo> xnox: :( fun (not!)
[11:12] <rbasak> slyon: one more question. Does the new openvswitch build dependency cause any runtime packages dependencies to be added?
[11:12] <rbasak> And if so, how significant are they?
[11:18] <sil2100> rbasak, slyon: as per my original patch review, I was fine with the tests temporarily disabled on riscv - being quite unfortunate, but my rationale was: since we do not care about riscv64 autopkgtests, which are essentially important, I didn't feel like unit-testing issues like this should block an important netplan milestone as well
[11:20] <sil2100> But I respect your opinion and rejection decision as an SRU member
[11:33] <sil2100> I would certainly not want to wait for OVS focal riscv64 support as we could be waiting a while, with everyone being busy as is
[11:34] <sil2100> We'd have to ask James if they have plans for that
[11:37] <rbasak> FWIW I don't think that it's necessary to block on OVS on riscv64. I'd be happy with more specific test skips
=== rs20092 is now known as rs2009
[11:52] <sil2100> rbasak: sure, we can look into that
[11:53] <sil2100> rbasak: anyway, to finalize my rationale: we recently started defaulting in groovy to 'nocheck' for riscv64, which also felt like another sign that coverage on that arch is not a blocking issue
[11:54] <sil2100> Sure, we didn't on focal, but not because of principle
[11:55] <sil2100> Just saying, all these things simply attributted to me going +1 on not wasting time on this, as we have really much important things to work on
[12:16] <slyon> rbasak: no new runtime dependencies are needed for netplan 0.100. It only needs the OVS dependency if OVS features are to be used, but not in a normal setup
[12:24] <slyon> I'll be looking into more specific test skips then, to not block on OVS on riscv64
[12:28] <ahasenack> any sphinx experts out there? cyrus-sasl2 is an FTBFS because it uses an old sphinx extension to build its docs, and this extension no longer works with sphinx shipped in groovy
[12:28] <ahasenack> my plan b is to disable doc building, and ship the pre-built files (part of the tarball)
[12:28] <ahasenack> https://bugs.launchpad.net/bugs/1894907
[12:28] <ubottu> Launchpad bug 1894907 in cyrus-sasl2 (Ubuntu) "FTBFS with sphinx 3.2" [Undecided,Triaged]
[12:57] <mvo> xnox: fwiw, I reviewed/approved your grub-multi-install PR
[13:03] <xnox> mvo:  tah
[13:04] <xnox> mvo:  so, that should fix the dead-end that said machine has encounter.
[13:04] <xnox> mvo:  however, after testing all that, i would recommend to do dpkg-reconfigure grub-pc and pick a drive which the machine is booted off, to install grub into the MBR
[13:05] <xnox> i will try to launch machines there too, to see if things are always broken for everyone on that cloud. or if it was an accident.
[14:20] <coreycb> bryce: thanks for the heat fix. I've pushed that to the Vcs-Git repo so that we don't lose it.
[14:21] <xnox> cpaelzer:  so we have a better rpi-eeprom in the archive now https://bugs.launchpad.net/ubuntu/+source/rpi-eeprom/+bug/1895137 what's the next step there? still security review, or do you need to re-review it?
[14:21] <ubottu> Launchpad bug 1895137 in rpi-eeprom (Ubuntu) "[MIR] rpi-eeprom" [Undecided,Triaged]
[14:23] <cpaelzer> xnox: hiho
[14:23] <cpaelzer> xnox: keep it on security as-is I'll still re-review if all my concerns were adressed or if any are left
[14:23] <cpaelzer> thanks for the ping
[14:24] <waveform> cpaelzer, I *think* I've addressed all your concerns - but we'll see :)
[14:24] <cpaelzer> thanks
[14:24] <cpaelzer> waveform: xnox: while I have you here I was  today made aware of https://bugs.launchpad.net/ubuntu/+source/linux-firmware-raspi2/+bug/1867813
[14:24] <ubottu> Launchpad bug 1867813 in linux-firmware-raspi2 (Ubuntu) "[MIR] linux-firmware-raspi2 to restricted" [High,New]
[14:25] <cpaelzer> I'll give it a review as it seems doko didn't get to it, but @xnox usually unassigning should come with some sort of comment why (usually a review being done)
[14:29] <cpaelzer> doko: for you (or anyone else who might know) I have a very different question out of looking into the recent groovy rebuilds
[14:29] <cpaelzer> doko: I've seen a few wrong packages which had headers doinf define without "external"
[14:29] <cpaelzer> doko: that seemed to have worked before but now failed with the linker coplaining abut "multiple definitions"
[14:29] <cpaelzer> so far so good, adding external is the fix
[14:30] <cpaelzer> but how abut this in a header
[14:30] <cpaelzer> #define __shared __asm__ ( "_shared_bss" ) __aligned
[14:30] <cpaelzer> that is also failing for "multiple definition of `_shared_bss'"
[14:30] <cpaelzer> but it was meant to be used by all linked drivers as far as I understand the code
[14:30] <cpaelzer> doko: what would be the "right" way to do this now with the new toolchain?
[14:31] <xnox> yeah, no idea about the linking.
[14:32] <xnox> cpaelzer:  i unassigned doko, because he has mentioned multiple times that he cannot review binary blobs. As there is no clear path on how to do RIR (restricted inclusion report)
[14:32] <xnox> cpaelzer:  in practice some some of agreement between AA and MIR teams need to be made, to promote that one. The blobs are legit, and come from RPI foundation and we don't have restrictions on redistributing them.
[14:32] <cpaelzer> he didn't mention that on the bug, so others were left out
[14:33] <cpaelzer> in general I agree this is a lack of a defined process
[14:33] <cpaelzer> but we can do as much (bit) that applies and leave it to the AAs eventually who so far have done it
[14:33] <cpaelzer> I linked the related bugs already
[14:34] <cpaelzer> xnox: next time just drop a note why the unassign happened along the change - that would be nice
=== rs20090 is now known as rs2009
[15:26] <bryce> coreycb, sure no prob.  If the package gets stuck in migration again due to test failure, I suspect you may want to bump up the timeout on the service startup test.
[16:00] <coreycb> bryce: ok I'll keep an eye on it
[17:12] <rbasak> rafaeldtinoco: "the settings unit value "s", is being ignored. force me to set the timeout to 10000 to get a 10 second timeout" --> if that's being fixed in this SRU, that'll regress anyone who has worked around this with a really long timeout, won't it?
[17:14] <rafaeldtinoco> rbasak: that was the reporter assumption
[17:14] <rafaeldtinoco> everything was broken
[17:14] <rafaeldtinoco> not only using s or not
[17:14] <rafaeldtinoco> sorry if I did not make that explicit (since he mentioned that in the bug description)
[17:14] <rbasak> I'm still trying to understand what is going on
[17:14] <rbasak> I'll continue reading
[17:15] <rafaeldtinoco> rbasak: TL;DR is: a code change took place during development cycle, and they forgot to fix the other half of it (because of a tag miss in the commit)
[17:15] <rafaeldtinoco> so I took the other half and brought it to the released version
[17:15] <rafaeldtinoco> that is the general idea
[17:16] <ahasenack> so if someone had "10s", that actually meant 10ms
[17:17] <ahasenack> and if that person then updated it to 10000s, once the fix lands, that will become 10 thousand seconds?
[17:30] <arnatious> rbasak can we pop https://bugs.launchpad.net/ubuntu/+source/python-flake8/+bug/1883175 back into proposed? Or should I get a sponsor to re-upload and retrigger whatever automation is needed?
[17:30] <ubottu> Launchpad bug 1883175 in python-flake8 (Ubuntu Focal) "missing support for python3.8 language features" [Low,Confirmed]
[17:31] <rafaeldtinoco> ahasenack: problem would happen if person did not use units
[17:31] <rafaeldtinoco> but then the person would be workarounding a bug with something wrongly set
[17:32] <rafaeldtinoco> the patches here are basically fixing a bug: considering ms for the started clock (only >1 sec clocks were "started" before)
[17:33] <rafaeldtinoco> systemd support needs clock_gettime() because it starts right away (despite the service has been started, the commands returns)
[17:33] <rafaeldtinoco> there is some mitigation for that in the code (I havent read that part)
[17:34] <rafaeldtinoco> (disabling ftime() and obligating clock_gettime to have systemd support)
[17:34] <rafaeldtinoco> and we had it all before, anyway (because we were enabling clock_gettime)
[17:34] <rafaeldtinoco> rbasak: ^ fyio
[17:42] <rbasak> arnatious: I don't think that's possible but I'm not certain. If I'm right, you'd need to re-upload with a bumped version number.
[17:42] <rbasak> Archive admins may know more.
[17:43] <rbasak> rafaeldtinoco: problem would happen if person did not use units> sure, and I'm not saying that means we can't SRU it, but if it's true then we should document that we understood this and how we weighed it up to proceed anywya
[17:44] <rafaeldtinoco> rbasak: I can add a warning saying that timeouts configured *without* units for systemd resources should be reviewed.
[17:45] <rafaeldtinoco> or just.. that timeouts in general should be reviewed if, after upgrade, timeouts are being faced
[17:45] <Laney> rbasak: You (anyone who can upload) can copy removed packages back using copy-package --force-same-desination --include-binaries
[17:45] <Laney> Don't know what any SRU tools will do with that, though, if that matters
[17:51] <rbasak> Laney: thanks!
[17:52] <rbasak> I don't see why SRU tooling would break with it once it's back in proposed. Nothing is stateful AFAIK.
[17:52] <rbasak> arnatious: ^ so it sounds like we can. Can you propose what you're planning in the bug please?
[17:55] <Laney> rbasak: It'll be a sync in the queue then