| mwhudson | gtest-nux-windowcompositor.cpp:143:40: error: field ‘wnd_thread’ has incomplete type ‘boost::shared_ptr<nux::WindowThread>’ | 00:47 |
|---|---|---|
| mwhudson | i don't wanna now | 00:47 |
| mwhudson | oh just a missing #include probably | 00:51 |
| === helio|afk is now known as heliocastro | ||
| ogra | juliank, tickle ... i'm trying something hackish over here to inject a packageproxy into an lxd container before the first "apt update" runs ... this seems to work fine for the "apt update" but the next apt comand doesnt find any packages then and i can see that sources.list was reverted when i enter the container ... is there some special apt feature that re-sets it or am i hitting some lxd issue ? | 11:49 |
| ogra | here is a log https://paste.ubuntu.com/p/6tVQNvMpnv/ of the container output | 11:49 |
| juliank | ogra: you have to wait until cloud-init is done, basically | 11:49 |
| juliank | ogra: or well, set the proxy via cloud-init | 11:49 |
| ogra | well, i'm not aware that i'm running cloud-init at all in that container | 11:49 |
| ogra | is that a new default ? | 11:50 |
| juliank | ogra: I only know that the lxd images run cloud-init | 11:50 |
| ogra | bah | 11:50 |
| ogra | not at all what i want (and nothing in the output indicates cloud-init running) | 11:51 |
| juliank | ogra: so you can configure your lxd profile in https://paste.ubuntu.com/p/x8Sgd7z7fv/ | 11:51 |
| juliank | s/in/like this/ | 11:51 |
| juliank | That's what I have in my default profile to configure all (Ubuntu) lxd containers to use my squid-deb-proxy | 11:51 |
| ogra | yeah, i know how to mangle cloud-init ... i neither want it installed nor do i want it to run though ... thanks for the pointer ... i'll talk to stephane | 11:52 |
| juliank | I understand, it causes some annoyances like these | 11:52 |
| ogra | (i was assuming somehow that the minimal images are actually minimal 🙂 ) | 11:52 |
| juliank | It's quite useful though, I have a dev lxd profile that automatically adds a user with my name that way (and has $HOME mounted into the container, and UID/GID mapped accordingly) | 11:53 |
| juliank | So, yeah not sure I like or not like | 11:54 |
| ogra | right, but i'm building an lxd based ubuntu core appliance image which means my lxd config is hardcoded in the gadget snap ... and i want to be able to define the proxy dynamically when starting a build ... | 11:55 |
| juliank | ack | 12:01 |
| ogra | well, changing both files fixes it ... ugly but works for my little hack for the moment | 12:01 |
| === Eighth_Doctor is now known as Conan_Kudo | ||
| === Conan_Kudo is now known as Eighth_Doctor | ||
| === Eighth_Doctor is now known as Eleventh_Doctor | ||
| === Eleventh_Doctor is now known as Eighth_Doctor | ||
| rbasak | xnox: your requested reimiports are complete. Please keep an eye out for any apparent errors and let me know. It'd be good to spot any problem now before we declare the repos stable. | 13:08 |
| xnox | rbasak: thanks! on it. | 13:30 |
| === cpaelzer_ is now known as cpaelzer | ||
| === heliocastro is now known as helio|afk | ||
| rbasak | xnox: for bug triage/cleanup purposes, are you tracking https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1861177? | 16:30 |
| ubottu | Launchpad bug 1861177 in libseccomp (Ubuntu) "seccomp_rule_add is very slow" [High,Triaged] | 16:30 |
| rbasak | Is it OK to remove any action for the server team there? | 16:30 |
| xnox | rbasak: no, foundations is not aware of that bug report at all. | 16:39 |
| xnox | rbasak: and we are not tracking it at all. | 16:39 |
| xnox | rbasak: security team maintains libseccomp. | 16:39 |
| xnox | rbasak: and normal process is to use rls-gg-incoming or some such. | 16:39 |
| xnox | rbasak: but i advise to ping security team about it | 16:40 |
| * xnox tags it "Public Security" they seem to react to such changes ;-) | 16:40 | |
| rbasak | OK, thanks | 16:40 |
| xnox | (or rather change the "type" of the bug) | 16:40 |
| rbasak | Right now the implication in the bug is that you will work on it, so you might want to deny that to make it clear ;) | 16:40 |
| rbasak | Oh | 16:40 |
| rbasak | Unless they mean a different Dimitri? | 16:40 |
| xnox | rbasak: how? why? | 16:41 |
| rbasak | Nope I think they mean you | 16:41 |
| rbasak | xnox: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1861177/comments/7 | 16:41 |
| ubottu | Launchpad bug 1861177 in libseccomp (Ubuntu) "seccomp_rule_add is very slow" [High,Triaged] | 16:41 |
| xnox | rbasak: there are multiple libseccomp issues inflight | 16:41 |
| xnox | rbasak: there is inflight backport of new seccomp | 16:41 |
| xnox | rbasak: it was reverted / patched / reintroduced / etc | 16:41 |
| rbasak | Anyway, I'm just triaging here :) | 16:42 |
| xnox | rbasak: amurray or somesuch are dealing with it | 16:42 |
| xnox | rbasak: i think you should remove server-next and move on =) | 16:42 |
| rbasak | Yep :) | 16:42 |
| xnox | it is being worked on by the security team, and it's not "high" any more | 16:42 |
| xnox | (there were things done to ensure it is not "high") | 16:42 |
| xnox | rbasak: updated status closer to reality "medium" and "inprogress" | 16:43 |
| rbasak | Thanks! | 16:43 |
| === ijohnson is now known as ijohnson|lunch | ||
| jdstrand | rbasak (cc amurray, xnox): a 2.4.3 SRU is in flight (by amurray), but looking at https://github.com/seccomp/libseccomp/pull/180 (the fix for the bug), https://github.com/seccomp/libseccomp/issues/187 (2.4.3 backports), and code inspection, the fix for the bug is not in 2.4.3 and will come in 2.5 | 16:50 |
| xnox | hm, right | 16:50 |
| xnox | jdstrand: unless we cherrypick it into groovy, and when we do the next libseccomp backport we do it then? | 16:50 |
| jdstrand | xnox: we are not currently working on it. That could be changed via the stakeholder process | 16:53 |
| jdstrand | it will come at some point | 16:53 |
| jdstrand | 2.5 will have riscv64 support and we are looking to update libseccomp more refularly | 16:54 |
| jdstrand | (we aren't doing the riscv64 stuff, but that would be nice for focal) | 16:54 |
| jdstrand | rbasak: once 2.4.3 lands everywhere, bryce's patch should be easy enough to apply, but would need extensive testing. I suggest reaching out to joeubuntu, CC'ing amurray and myself if you want us to prioritize that | 16:57 |
| jdstrand | rbasak: or if your team wanted to do it, we could perhaps help with testing. ie, there are options to discuss :) | 16:57 |
| rbasak | jdstrand: I think the only reason Bryce flagged it is because it's a contributed patch and we try to prioritise those. I don't know that there's any other need to prioritise from the server team end. | 16:59 |
| rbasak | (and I removed the flag as it doesn't look like it'd be the server team sponsoring anyway) | 17:00 |
| jdstrand | rbasak: ack, thanks (amurray, perhaps we discuss that ^ with joeubuntu?) | 17:00 |
| rbasak | FWIW, I don't think we'd prioritise it any more anyway even if we were sponsoring - unless the contributor was willing to take on the effort of the extensive testing,e tc. | 17:01 |
| jdstrand | I don't think the contributor would be up for doing the testing as it relates to snap | 17:11 |
| jdstrand | but that is good info | 17:11 |
| kyrofa | I'm trying to understand why libceres1 isn't available on arm64. Is it because of this test failure? https://launchpad.net/ubuntu/+source/ceres-solver/1.14.0-4ubuntu1/+build/19091179 | 17:37 |
| kyrofa | Err, for focal, sorry | 17:37 |
| kyrofa | Specifically: if I SRU a fix for that test failure, will that be enough to get libceres1 and libceres-dev on arm64 in focal? | 17:45 |
| tumbleweed | kyrofa: yes | 17:47 |
| kyrofa | Thanks for the confirmation tumbleweed | 17:48 |
| === ijohnson|lunch is now known as ijohnson | ||
| ahasenack | https://code.launchpad.net/update-notifier/+git is out of sync with what's in groovy, does someone check that periodically and updates the master branch? | 19:50 |
| ahasenack | bdmurray: specifically your groovy 3.192.31 upload isn't in https://code.launchpad.net/update-notifier/+git | 19:51 |
| bdmurray | ahasenack: that's because somebody converted update-notifier to git without notifying the foundations team and didn't update the update-notifier project in Launchpad | 19:54 |
| bdmurray | notifying or consulting | 19:55 |
| ahasenack | bdmurray: I followed the Vcs-Git header, it's currently pointing at git, let me check when that was changed | 19:55 |
| bdmurray | ahasenack: I know who the somebody was and haven't gotten around to talking to them about it | 19:56 |
| ahasenack | bdmurray: but going forward, it's git? | 19:57 |
| ahasenack | or tbd | 19:57 |
| bdmurray | ahasenack: tbd as its in focal but I think the change was premature | 19:58 |
| ahasenack | bdmurray: foundations has a meeting on thursday? This could be brought up there | 19:58 |
| bdmurray | ahasenack: sure | 19:59 |
| vorlon | sbeattie: hey, would it be possible for the security team to help us out with an archive search to find out if anything is still using the GetConnectionAppArmorSecurityContext bus method in dbus as of focal, to determine whether we can drop the Ubuntu delta in groovy? (That the Security Team introduced ;-) | 21:09 |
| tyhicks | vorlon, sbeattie: I'm pretty sure that it was only Ubuntu phone stuff that used the old method but an archive search would be a good idea | 21:22 |
| vorlon | yeah that was also my expectation, but some of the phone stuff did get dual-purposed onto the unity desktop, so | 21:22 |
| sbeattie | sarnold: can you take the above ^^^ | 21:31 |
| sarnold | sbeattie: yeah | 21:32 |
| sbeattie | thanks! | 21:33 |
| tyhicks | sarnold: to give a little background, GetConnectionAppArmorSecurityContext() was the initial attempt at allowing a dbus client to get another peer's AppArmor label | 21:36 |
| jdstrand | sbeattie: I think we need to do more than focal when considering snapd since snaps can stage things from xenial | 21:36 |
| jdstrand | sarnold: ^ | 21:36 |
| jdstrand | hey tyhicks :) | 21:36 |
| tyhicks | sarnold: upstream dbus opted to go with a more generic mechanism: GetConnectionCredentials() which is documented at https://dbus.freedesktop.org/doc/dbus-specification.html#bus-messages-get-connection-credentials | 21:36 |
| jdstrand | sarnold: since a snap staging something from xenial might be running on focal and expect the api | 21:36 |
| tyhicks | hey jdstrand :) | 21:37 |
| jdstrand | xenial dropped a lot of the unity8 stuff iirc correctly, so hopefully we are ok | 21:37 |
| tyhicks | I'd be very surprised if xenial or newer has anything using that old method | 21:38 |
| jdstrand | hopefully that's the case | 21:38 |
| jdstrand | we'll know soon enought though! :) | 21:39 |
| jdstrand | enough* | 21:39 |
| sarnold | luckily/unluckliy, actually restricting a search to a subset of the archive is pretty difficult for me; "search everything" is my usual approach (unless we can get lucky and search only eg .c or .py or similar..) | 21:39 |
| jdstrand | sarnold: are you using forarchive? | 21:39 |
| sarnold | jdstrand: no.. I've never quite gotten the hang of the N layers of indirection.. (and that machine doesn't have any credentials or git trees on it at all..) | 21:45 |
| jdstrand | sarnold: ok, cause I have some recipes for it I would've shared :) fyi, I just extracted the single tool from git and plopped it on there-- mine also doesn't have git trees, etc, etc | 21:46 |
| sarnold | jdstrand: ooohhhh, well please do share, I'll see if I can get them to work out here :) | 21:47 |
| jdstrand | sarnold: I'll share that with you in a bit | 21:49 |
| sarnold | yay thanks | 21:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!