| === cpaelzer__ is now known as cpaelzer | ||
| cpaelzer | wgrant: cjwatson: hello, last week we talked about riscv64 build fails and you mentioned it might be about a timeout that was switched | 05:30 |
|---|---|---|
| cpaelzer | wgrant: cjwatson: but the rebuilds have failed again https://launchpad.net/ubuntu/+source/nss/2:3.55-1ubuntu3.1/+build/21363729 | 05:31 |
| cpaelzer | and 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/21358522 | 05:31 |
| cpaelzer | I still see "E: Build killed with signal TERM after 150 minutes of inactivity" | 05:32 |
| cpaelzer | So might there be anything else that changed in between that I need to consider ? | 05:33 |
| rbasak | Need some help with bug 1916250 please. Unversioned Breaks/Replaces? Unversioned Conflicts/Replaces? Something else? | 05:52 |
| ubottu | bug 1916250 in libsignon-glib (Ubuntu) "gir1.2-signon-2.0 needs to declare replace on older releases (Groovy2Hirsute)" [Low,New] https://launchpad.net/bugs/1916250 | 05:52 |
| rbasak | I 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 | ||
| seb128 | mwhudson, hey, did you see that the ubuntu-drivers-common are failing now with the removed Depends? | 08:51 |
| xnox | vorlon: 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 |
| cjwatson | cpaelzer: argh | 09:13 |
| cjwatson | cpaelzer: 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 fixed | 09:13 |
| cjwatson | cpaelzer: I'll reschedule that nss build on one of the good builders, and reflash the bad ones properly this time | 09:14 |
| cpaelzer | ok it is currently running in a naive "hit rebuild button" from me | 09:17 |
| cpaelzer | feel free to abort and reschedule it on a better builder | 09:17 |
| cpaelzer | cjwatson: ^^ | 09:17 |
| tseliot | mwhudson, why? | 12:35 |
| seb128 | tseliot, the autopkgtests are failing now due to aplay not existing... | 12:44 |
| tseliot | seb128, I don't see that in the buildlog: https://launchpad.net/ubuntu/+source/ubuntu-drivers-common/1:0.8.9 | 12:47 |
| seb128 | tseliot, the auitopkgtests are not part of the build, see https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#desktop-packages | 13:02 |
| tseliot | seb128, where can I find the test? I would like to see whether that test is still relevant or not | 13:03 |
| cjwatson | cpaelzer: All the riscv64 builders should actually have the proper timeout now. Thanks for the note. | 13:03 |
| jdstrand | juliank: 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 doing | 13:15 |
| jdstrand | the work) | 13:15 |
| seb128 | tseliot, in debian/tests from the package | 13:22 |
| === smoser1 is now known as smoser | ||
| cpaelzer | thanks cjwatson, if the old build durations are an indicator it will be another 6.5h until we know if it completes correctly this time | 13:39 |
| teward | jdstrand: 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 |
| juliank | jdstrand: teward: lxd setups up its own iptables/nftables rules/chains that override ufw. well, the iptables do, but chaining in nftables works differently | 14:14 |
| teward | juliank: 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 comment | 14:15 |
| teward | (this is why I just wrote my own rule handlers for things into iptables :P) | 14:15 |
| teward | but 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 |
| juliank | teward: ntftables is the default | 14:16 |
| teward | juliank: even though it's not passed MIR? | 14:16 |
| juliank | teward: just using the legacy iptables frontend | 14:16 |
| teward | how'd *that* happen? | 14:16 |
| juliank | teward: nftables the package is the new CLI | 14:16 |
| juliank | teward: it's different from nftables the kernel side :D | 14:16 |
| juliank | So we still use iptables tool in user space but in nft mode | 14:17 |
| teward | so... 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 |
| juliank | teward: nf_tables kernel module is loaded and used by iptables userspace tool atm | 14:19 |
| teward | *headscratches* I think i missed some release notes then but that's a different issue | 14:20 |
| teward | in 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 issues | 14:20 |
| juliank | teward: https://discourse.ubuntu.com/t/hirsute-hippo-release-notes/19221 says "nftables is now the default backend for the firewall. | 14:20 |
| juliank | So it's there :D | 14:20 |
| teward | sarnold: ^^ need your thoughts on this | 14:20 |
| teward | because MIR == NotComplete | 14:20 |
| teward | *defers to the SEcurity team for that* | 14:21 |
| teward | juliank: 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 |
| teward | which... is always the case if you try and mix different rulesets together :P | 14:22 |
| jdstrand | juliank: 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 said | 14:23 |
| jdstrand | also, 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 |
| jdstrand | regardless 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 |
| jdstrand | amurray, sarnold (cc sbeattie): fyi ^ | 14:26 |
| teward | > though, ufw sets up its own chains and iirc, so does lxd | 14:26 |
| teward | jdstrand: except in NAT / mangle tables | 14:26 |
| teward | there's rules added | 14:26 |
| teward | but not chains (checksum rules among other things) | 14:26 |
| jdstrand | teward: yes, for sure, but they are separate chains from each other | 14:27 |
| teward | 'cept UFW does a blast of rules last I checked | 14:27 |
| teward | including NAT, mangle, etc. | 14:27 |
| teward | which i *have* seen cause problems in other deployments (not necessarily LXD) | 14:27 |
| teward | i can run some tests later but right now i'm putting out fires at work because email is being stupid | 14:27 |
| jdstrand | ufw 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 sure | 14:29 |
| jdstrand | s/there/those chains/ | 14:29 |
| vorlon | xnox, sarnold: ok, then we need to unseed nftables for hirsute | 15:06 |
| === ijohnson is now known as ijohnson|lunch | ||
| CarlFK | http://cdimage.ubuntu.com/ubuntu/releases/groovy/release/ Where is amd64? LIke I would expect to see ubuntu-20.10-live-server-amd64.iso | 17:51 |
| CarlFK | ah, over here: https://releases.ubuntu.com/20.10/ubuntu-20.10-live-server-amd64.iso | 17:53 |
| CarlFK | wget 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 RTL810xE | 18:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!