xnoxmost things seem to work, but riscv builders are having Unable to connect to ftpmaster.internal:http: others are doing fine so far.01:50
=== 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:
cjwatson(last night, but I forgot the topic change here)08:34
cjwatsonriscv64 is being fixed08:34
slyonrbasak: 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: #189419709:39
ubottuLaunchpad bug 1894197 in netplan.io (Ubuntu) "[SRU][FFe] Update to netplan.io 0.100" [High,In progress] https://launchpad.net/bugs/189419709:39
rbasaktdaitx: 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
rbasakslyon: I'll get to that next10:15
rbasaktdaitx: oh, I'm sorry10:16
rbasakI see what you did. Interesting.10:16
rbasakI think I'd prefer it to have been more explicit but it's fine as it is.10:16
slyonthank you!10:17
rbasakslyon: 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:30
slyonrbasak: 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 again10:34
slyonI just didn't want to block on OVS release, as riscv isn't widely used10:34
rbasakHow is it that it worked previously?10:35
slyonolder netplan didn't have OVS support and thus didn't need the openvswitch dependency10:36
rbasakDo all your test require OVS, or just some of them?10:37
rbasakPresumably just the new ones?10:37
rbasakSo can't you add a skip on just those ones instead of disabling the rest of the test suite with it?10:37
xnoxall three users of riscv64 agree to watch out for netplan regressions =)10:38
slyonyeah 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/riscv6410:39
rbasakI 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
rbasakAdding 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 architecture10:41
rbasakSkipping some tests based on architecture really shouldn't be difficult unless I'm missing something - and as straightforward to review as the current patch10:42
rbasakSo I think we should either do that, or wait on OVS support on Focal10:42
rbasakI'm happy to seek wider SRU team opinion if you like10:43
slyonI totally get your point... sil2100 already ack'ed that patch, but didn't want to work on the SRU, as he sponsored it10:45
rbasakHow would you like to proceed?10:47
slyonThe 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 infrastructure10:47
slyonSo I guess we should wait and I'll prepare a new upload with all tests enabled... sorry for pushing on this10:48
xnoxmvo:  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
xnoxmvo:  meaning that system, will forever have out of date bootloader installed in mbr =(10:49
rbasakOK. 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:49
rbasakIt 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:51
slyonYou're right. I wanted to take a temporary shortcut there, which is not the correct thing to do.10:53
mvoxnox: :( fun (not!)11:10
rbasakslyon: one more question. Does the new openvswitch build dependency cause any runtime packages dependencies to be added?11:12
rbasakAnd if so, how significant are they?11:12
sil2100rbasak, 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 well11:18
sil2100But I respect your opinion and rejection decision as an SRU member11:20
sil2100I would certainly not want to wait for OVS focal riscv64 support as we could be waiting a while, with everyone being busy as is11:33
sil2100We'd have to ask James if they have plans for that11:34
rbasakFWIW I don't think that it's necessary to block on OVS on riscv64. I'd be happy with more specific test skips11:37
=== rs20092 is now known as rs2009
sil2100rbasak: sure, we can look into that11:52
sil2100rbasak: 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 issue11:53
sil2100Sure, we didn't on focal, but not because of principle11:54
sil2100Just 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 on11:55
slyonrbasak: 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 setup12:16
slyonI'll be looking into more specific test skips then, to not block on OVS on riscv6412:24
ahasenackany 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 groovy12:28
ahasenackmy plan b is to disable doc building, and ship the pre-built files (part of the tarball)12:28
ubottuLaunchpad bug 1894907 in cyrus-sasl2 (Ubuntu) "FTBFS with sphinx 3.2" [Undecided,Triaged]12:28
mvoxnox: fwiw, I reviewed/approved your grub-multi-install PR12:57
xnoxmvo:  tah13:03
xnoxmvo:  so, that should fix the dead-end that said machine has encounter.13:04
xnoxmvo:  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 MBR13:04
xnoxi 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.13:05
coreycbbryce: thanks for the heat fix. I've pushed that to the Vcs-Git repo so that we don't lose it.14:20
xnoxcpaelzer:  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
ubottuLaunchpad bug 1895137 in rpi-eeprom (Ubuntu) "[MIR] rpi-eeprom" [Undecided,Triaged]14:21
cpaelzerxnox: hiho14:23
cpaelzerxnox: keep it on security as-is I'll still re-review if all my concerns were adressed or if any are left14:23
cpaelzerthanks for the ping14:23
waveformcpaelzer, I *think* I've addressed all your concerns - but we'll see :)14:24
cpaelzerwaveform: xnox: while I have you here I was  today made aware of https://bugs.launchpad.net/ubuntu/+source/linux-firmware-raspi2/+bug/186781314:24
ubottuLaunchpad bug 1867813 in linux-firmware-raspi2 (Ubuntu) "[MIR] linux-firmware-raspi2 to restricted" [High,New]14:24
cpaelzerI'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:25
cpaelzerdoko: for you (or anyone else who might know) I have a very different question out of looking into the recent groovy rebuilds14:29
cpaelzerdoko: I've seen a few wrong packages which had headers doinf define without "external"14:29
cpaelzerdoko: that seemed to have worked before but now failed with the linker coplaining abut "multiple definitions"14:29
cpaelzerso far so good, adding external is the fix14:29
cpaelzerbut how abut this in a header14:30
cpaelzer#define __shared __asm__ ( "_shared_bss" ) __aligned14:30
cpaelzerthat is also failing for "multiple definition of `_shared_bss'"14:30
cpaelzerbut it was meant to be used by all linked drivers as far as I understand the code14:30
cpaelzerdoko: what would be the "right" way to do this now with the new toolchain?14:30
xnoxyeah, no idea about the linking.14:31
xnoxcpaelzer:  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
xnoxcpaelzer:  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
cpaelzerhe didn't mention that on the bug, so others were left out14:32
cpaelzerin general I agree this is a lack of a defined process14:33
cpaelzerbut we can do as much (bit) that applies and leave it to the AAs eventually who so far have done it14:33
cpaelzerI linked the related bugs already14:33
cpaelzerxnox: next time just drop a note why the unassign happened along the change - that would be nice14:34
=== rs20090 is now known as rs2009
brycecoreycb, 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.15:26
coreycbbryce: ok I'll keep an eye on it16:00
rbasakrafaeldtinoco: "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:12
rafaeldtinocorbasak: that was the reporter assumption17:14
rafaeldtinocoeverything was broken17:14
rafaeldtinoconot only using s or not17:14
rafaeldtinocosorry if I did not make that explicit (since he mentioned that in the bug description)17:14
rbasakI'm still trying to understand what is going on17:14
rbasakI'll continue reading17:14
rafaeldtinocorbasak: 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
rafaeldtinocoso I took the other half and brought it to the released version17:15
rafaeldtinocothat is the general idea17:15
ahasenackso if someone had "10s", that actually meant 10ms17:16
ahasenackand if that person then updated it to 10000s, once the fix lands, that will become 10 thousand seconds?17:17
arnatiousrbasak 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
ubottuLaunchpad bug 1883175 in python-flake8 (Ubuntu Focal) "missing support for python3.8 language features" [Low,Confirmed]17:30
rafaeldtinocoahasenack: problem would happen if person did not use units17:31
rafaeldtinocobut then the person would be workarounding a bug with something wrongly set17:31
rafaeldtinocothe patches here are basically fixing a bug: considering ms for the started clock (only >1 sec clocks were "started" before)17:32
rafaeldtinocosystemd support needs clock_gettime() because it starts right away (despite the service has been started, the commands returns)17:33
rafaeldtinocothere is some mitigation for that in the code (I havent read that part)17:33
rafaeldtinoco(disabling ftime() and obligating clock_gettime to have systemd support)17:34
rafaeldtinocoand we had it all before, anyway (because we were enabling clock_gettime)17:34
rafaeldtinocorbasak: ^ fyio17:34
rbasakarnatious: 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
rbasakArchive admins may know more.17:42
rbasakrafaeldtinoco: 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 anywya17:43
rafaeldtinocorbasak: I can add a warning saying that timeouts configured *without* units for systemd resources should be reviewed.17:44
rafaeldtinocoor just.. that timeouts in general should be reviewed if, after upgrade, timeouts are being faced17:45
Laneyrbasak: You (anyone who can upload) can copy removed packages back using copy-package --force-same-desination --include-binaries17:45
LaneyDon't know what any SRU tools will do with that, though, if that matters17:45
rbasakLaney: thanks!17:51
rbasakI don't see why SRU tooling would break with it once it's back in proposed. Nothing is stateful AFAIK.17:52
rbasakarnatious: ^ so it sounds like we can. Can you propose what you're planning in the bug please?17:52
Laneyrbasak: It'll be a sync in the queue then17:55

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!