/srv/irclogs.ubuntu.com/2021/04/12/#ubuntu-devel.txt

=== cpaelzer__ is now known as cpaelzer
cpaelzerwgrant: cjwatson: hello, last week we talked about riscv64 build fails and you mentioned it might be about a timeout that was switched05:30
cpaelzerwgrant: cjwatson: but the rebuilds have failed again https://launchpad.net/ubuntu/+source/nss/2:3.55-1ubuntu3.1/+build/2136372905:31
cpaelzerand as I said before the very same source upload worked just a bit before https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4522/+build/2135852205:31
cpaelzerI still see "E: Build killed with signal TERM after 150 minutes of inactivity"05:32
cpaelzerSo might there be anything else that changed in between that I need to consider ?05:33
rbasakNeed some help with bug 1916250 please. Unversioned Breaks/Replaces? Unversioned Conflicts/Replaces? Something else?05:52
ubottubug 1916250 in libsignon-glib (Ubuntu) "gir1.2-signon-2.0 needs to declare replace on older releases (Groovy2Hirsute)" [Low,New] https://launchpad.net/bugs/191625005:52
rbasakI wish this case were in https://wiki.debian.org/PackageTransition but I don't think it is.05:52
=== cpaelzer__ is now known as cpaelzer
=== michagogo_ is now known as michagogo
seb128mwhudson, hey, did you see that the ubuntu-drivers-common are failing now with the removed Depends?08:51
xnoxvorlon:  sarnold: i'm not going to unleash a network firewall in, without security review. We would want it in 21.10 to at least have one release before shipping it in 22.04. It will not be ok to ship 22.04 without nftables.08:52
cjwatsoncpaelzer: argh09:13
cjwatsoncpaelzer: looks like I managed to screw up copying the master image over to the second of the two VM hosts, so only half of the builders were fixed09:13
cjwatsoncpaelzer: I'll reschedule that nss build on one of the good builders, and reflash the bad ones properly this time09:14
cpaelzerok it is currently running in a naive "hit rebuild button" from me09:17
cpaelzerfeel free to abort and reschedule it on a better builder09:17
cpaelzercjwatson: ^^09:17
tseliotmwhudson, why?12:35
seb128tseliot, the autopkgtests are failing now due to aplay not existing...12:44
tseliotseb128, I don't see that in the buildlog: https://launchpad.net/ubuntu/+source/ubuntu-drivers-common/1:0.8.912:47
seb128tseliot, the auitopkgtests are not part of the build, see https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#desktop-packages13:02
tseliotseb128, where can I find the test? I would like to see whether that test is still relevant or not13:03
cjwatsoncpaelzer: All the riscv64 builders should actually have the proper timeout now.  Thanks for the note.13:03
jdstrandjuliank: hey, I didn't follow your comment wrt "lxd bridge is broken by that if you enable ufw (need to add extra ufw rules to allow routing traffic to bridge; annoying)'. it is not surprising that ufw needs additional rules for lxd bridge but that shouldn't have anything to do with nft since ufw will follow the system. fwiw, I think nftables should be in main (though I wouldn't be the one doing13:15
jdstrandthe work)13:15
seb128tseliot, in debian/tests from the package13:22
=== smoser1 is now known as smoser
cpaelzerthanks cjwatson, if the old build durations are an indicator it will be another 6.5h until we know if it completes correctly this time13:39
tewardjdstrand: juliank: does `lxd` know to use nftables rules if it doesn't find the traditional iptables legacy stuff, or ufw on it?  Last I checked the `lxd` snap doesn't ship with UFW rules, unless I'm blind and don't see it.14:03
teward(also, nftables is missing a lot of parity with some iptables features, so that's something to keep in mind and consider, also it hasn't passed MIR unless someone on Security's done an assessment of it and hasn't posted the results to the MIR bug.)14:04
juliankjdstrand: teward: lxd setups up its own iptables/nftables rules/chains that override ufw. well, the iptables do, but chaining in nftables works differently14:14
tewardjuliank: right, but i think it depends on the order of where things happen - if the rules aren't in place when you turn on ufw it *could* break those rules, if i'm reading jdstrand's comment14:15
teward(this is why I just wrote my own rule handlers for things into iptables :P)14:15
tewardbut as for `nft` if the rules are in place and chaining is different in nft then that may cause some headaches if nft ends up the default.14:16
teward(Though last I checked it still needs to go through MIR)14:16
juliankteward: ntftables is the default14:16
tewardjuliank: even though it's not passed MIR?14:16
juliankteward: just using the legacy iptables frontend14:16
tewardhow'd *that* happen?14:16
juliankteward: nftables the package is the new CLI14:16
juliankteward: it's different from nftables the kernel side :D14:16
juliankSo we still use iptables tool in user space but in nft mode14:17
tewardso... what's the backend then?  still iptables/netfilter since the kernel side nftables isn't enabled/usable?14:18
teward(FYI: clarify that in the release notes!)14:18
juliankteward: nf_tables kernel module is loaded and used by iptables userspace tool atm14:19
teward*headscratches* I think i missed some release notes then but that's a different issue14:20
tewardin any case, i'm more concerned if lxd doesn't get a chance to properly chain the rules to get its rules in place for the bridges it might cause issues14:20
juliankteward: https://discourse.ubuntu.com/t/hirsute-hippo-release-notes/19221 says "nftables is now the default backend for the firewall.14:20
juliankSo it's there :D14:20
tewardsarnold: ^^ need your thoughts on this14:20
tewardbecause MIR == NotComplete14:20
teward*defers to the SEcurity team for that*14:21
tewardjuliank: irregardless of the backend or not, i think jdstrand's question can be answered (feel free to correct me) as: "If something modifies the FIrewall rules after the LXD rules have been autoadded for the bridges, then the bridges can run into network issues due to the firewall rules having been modified after LXD added the rules"14:21
tewardwhich... is always the case if you try and mix different rulesets together :P14:22
jdstrandjuliank: sure (though, ufw sets up its own chains and iirc, so does lxd and neither strictly interfere with each other (ie, neither will flush the other's chains), but absolutely, if ufw is on, it would need rules to open things up, as you said14:23
jdstrandalso, lxd will perform an algorithm to see what is being used and choose the right backend. ufw the deb just follows the system alternative (the ufw snap will do something like lxd and detect)14:24
jdstrandregardless of ufw or this discussion, I maintain that iptables should remain in main. nftables should be promoted. nftables should not replace iptables and both should be in main for the foreseeable future (in part cause of industry inertia, the iptables nft backend and teward's comments)14:25
jdstrandamurray, sarnold (cc sbeattie): fyi ^14:26
teward> though, ufw sets up its own chains and iirc, so does lxd14:26
tewardjdstrand: except in NAT / mangle tables14:26
tewardthere's rules added14:26
tewardbut not chains (checksum rules among other things)14:26
jdstrandteward: yes, for sure, but they are separate chains from each other14:27
teward'cept UFW does a blast of rules last I checked14:27
tewardincluding NAT, mangle, etc.14:27
tewardwhich i *have* seen cause problems in other deployments (not necessarily LXD)14:27
tewardi can run some tests later but right now i'm putting out fires at work because email is being stupid14:27
jdstrandufw loads its chains into INPUT, FORWARD and OUTPUT and then loads its rules into there. it tries to start early before other things. there are interactions between applications that manage rules, my only point is ufw won't flush lxd's rules (or libvirt's or docker's or ...) but the ordering they were loaded and their interaction need to be accounted for, to be sure14:29
jdstrands/there/those chains/14:29
vorlonxnox, sarnold: ok, then we need to unseed nftables for hirsute15:06
=== ijohnson is now known as ijohnson|lunch
CarlFKhttp://cdimage.ubuntu.com/ubuntu/releases/groovy/release/  Where is amd64?  LIke I would expect to see ubuntu-20.10-live-server-amd64.iso17:51
CarlFKah, over here: https://releases.ubuntu.com/20.10/ubuntu-20.10-live-server-amd64.iso17:53
CarlFKwget http://cdimage.ubuntu.com/daily-canary/current/hirsute-desktop-canary-amd64.iso ... mount iso... pxeboot iso/casper/vmlinuz and initrd - "Detect network hardware" says "no card detected" has lots of drivers, but not for RTL810xE18:58

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