[05:39] <rbasak> cpaelzer: o/ I notice you synced ssh-import-id last week. I just did a new "upstream" release and have been trying to follow smoser's release process, which involved maintaining a VCS branch. But since it's now synced, that branch is out of date and has a different history to the synced package. I'm not sure how to resolve this while also doing it exactly as smoser did. Any suggestions?
[05:39] <rbasak> Maybe it's time to ditch ssh-import-id "upstream"'s packaging branch now, since there's one in Salsa, and we're in sync.
[05:40] <rbasak> Then if a delta is required, I can do it without VCS or with just git-ubuntu, on the assumption that it should stay relatively small.
[06:15] <cpaelzer> rbasak: I ensured that the sync has all we had before (as usual)
[06:15] <cpaelzer> rbasak: which content would you want to release as new version?
[06:16] <cpaelzer> 5.11 from master I guess seeing you tagging it yesterday
[06:18] <cpaelzer> Well, the tag is enough for upstream as a release I guess.
[06:18] <cpaelzer> Is the problem about making a tarball that matches the old style?
[06:18] <cpaelzer> or about getting a debian/ubuntu upload that is 5.10-1 + the new changes?
[06:37] <rbasak> cpaelzer: the latter. I can easily construct an upload of course, but I want to fit it into ssh-import-id's existing process for Ubuntu VCS maintenance which I think means changing it
[06:37] <rbasak> https://gist.github.com/smoser/3cd61fe6e08f0c0955ef949350897d15#file-readme-md is what I followed
[06:48] <cpaelzer> rbasak: TBH for the pkg-upload I'd recommend rebaseing 5.10..5.11 onto pkg/ubuntu/devel
[06:49] <cpaelzer> rbasak: that should content-wise be the same, match the orig tgz and has individual commits
[06:49] <cpaelzer> what else would you want?
[06:49] <cpaelzer> and also yes, given that Debian seems to now care about it you could propose just the same change to them as well
[06:49] <cpaelzer> which would allow to re-sync later as usual
[06:51] <cpaelzer> and afterwards you could throw a "align debian/*" commit onto master that unites Debian/Upstream packaging
[06:51] <cpaelzer> but anyway I start to outline my preferred way, you could easily have a different one and that still would be fine
[06:51] <rbasak> 5.10 and 5.11 are upstream tags though
[06:52] <rbasak> Rebasing the upstream branch onto a packaging branch seems wrong, unless I misunderstand?
[06:52] <lordievader> Good morning
[06:53] <cpaelzer> rbasak: it is the same as if you'd import a new orig tarball, but retaining individual commits
[06:53] <cpaelzer> rbasak: what I wanted to say above, this probably should not be over-thought. Do it the way that you like and nothing bad will happen.
[06:54] <cpaelzer> good morning lordievader
[06:54] <rbasak> I'm trying to sort it out so there's a straightforward process for the future
[06:54] <rbasak> Of course I can easily hack together something for this time
[06:54] <cpaelzer> ah now I see your point, more for future than this upload ...
[06:54] <rbasak> Right
[06:55] <rbasak> I'd like the process to be quick and mindless
[06:55] <rbasak> Right now it really isn't :-/
[06:55] <rbasak> I was hoping to just put Scott's gist into VCS and follow it exactly, so I wouldn't have to change anything, but AFAICT that won't work.
[06:56] <rbasak> Let's see what Scott thinks
[06:56] <rbasak> Right now I think my suggestion is to stop using a packaging branch at all, stop maintaining a debian/ directory in upstream master, and rely on Salsa and git-ubuntu for the packaging and Ubuntu delta.
[06:57] <cpaelzer> that would work for me and make this "less special"
[06:57] <cpaelzer> and maybe leave a Readme explaining that we'd want to avoid to maintain debian/* in two or three places and therefore this is how it now works
[06:58] <rbasak> We're agreed then I think. Let's wait for Scott. On the Readme, my plan is to take Scott's gist and check it in to master, and I can add an explanation there.
[11:31] <Tuor> Hi, I trying to find documentation on the unattended_upgrades configuration. I know where I have to change options, but the man doesn't explain the options and doesn't list the available options.
[12:01] <RoyK> Tuor: https://wiki.debian.org/UnattendedUpgrades, perhaps?
[12:05] <Tuor> RoyK: sort of. But it's not complete. I'm more looking to know all possible options that can be configured and what they do.
[12:05] <Tuor> In the default config comming with the package, there are comments for a lot of options. Is the default config listing every available option?
[12:06] <RoyK> I guess the hint is to RTFS - sorry don't know a better way
[12:08] <Tuor> Which manual?! Where is the manual? I'm asking for the manual and you say I should read it. Really?
[12:50] <lordievader> Tuor: I think you want `man unattended-upgrade` and `man 5 apt.conf`
[12:52] <lordievader> Wait, apt.conf may not apply.
[12:56] <lordievader> Not sure if there are options beyond those in the default `/etc/apt/apt.conf.d/50unattended-upgrades` config.
[13:12] <RoyK> Tuor: RTFS as in Source
[13:13] <RoyK> odc: it's just perl after all - should be readable
[13:14] <odc> true
[13:14] <ogra> isnt that actually mutually exclusive ?
[13:15] <odc> I hate how people say perl isn't readable and seem to have no problem with haskell, rust, c++, etc.
[13:15] <ogra> well, i have tons of perl scripts i wrote myself 10y ago that will take me a day to undersand again 🙂
[13:17] <odc> ah yes, that's a common problem ^^
[13:19]  * RoyK rather likes perl
[13:29] <TJ-> rather like knitting ... knit one, pearl one, drop one, curl one
[13:33] <ogra> lol
[14:05] <Tuor> Hmm, first time I'll read some perl, lets see how easy it is to read. :D
[14:06] <Tuor> perl? looks like python to me, but I have no idea how perl looks..
[14:12] <ogra> my perl always looks like shell ... but so does my python as well 😛
[14:27] <Tuor> github.com:mvo5/unattended-upgrades.git has a readme :)
[14:57] <Ussat> Well, foilks, Ubuntu as a server should get a TON more popular:  https://blog.centos.org/2020/12/future-is-centos-stream/
[15:00] <quadrathoch2> damn, oracle will have a huge uptake
[15:03] <Ussat> Ya....I mean I am a mixed shop, RH and Ubuntu...but ya
[15:17] <Tuor> has the apt package ovirt-guest-agent been named differently in focal or just dropped?
[15:22] <quadrathoch2> Tuor can't find it with packages.ubuntu.com :/
[15:54] <luna_> \o/
[16:01] <Tuor> it seams qemu-guest-agent replaces ovirt-guest-agent...
[16:02] <Tuor> at leat the description with apt show  qemu-guest-agent looks similar to what apt show ovirt-guest-agent used to look.
[16:07] <quadrathoch2> sounds to me that wouldn't be the case, as ovirt is not qemu Tuor
[16:14] <cpaelzer> Tuor: they are different things - ovirt-guest-agent talks with oVirt manager; qemu-guest-agent exposes other things (like freeze/thaw hooks, shutdown, ...)
[16:15] <Tuor> hmm sad.
[16:30] <Tuor> My Red Hat Virtualization is happy with qemu-guest-agent with ubuntu 20.04 and was not happy with the package with the same name under 18.04, with 18.04 I had to install ovirt-guest-agent.
[19:55] <shubjero> coreycb: Do you know when we might expect the updated openstack-dashboard packages for CVE-2020-29565 for http://ubuntu-cloud.archive.canonical.com/ubuntu bionic-updates/train ?
[19:55] <ubot3> An issue was discovered in OpenStack Horizon before 15.3.2, 16.x before 16.2.1, 17.x and 18.x before 18.3.3, 18.4.x, and 18.5.x. There is a lack of validation of the "next" parameter, which would allow someone to supply a malicious URL in Horizon that can cause an automatic redirect to the provided malicious URL. <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-29565>
[20:14] <coreycb> shubjero: typically the ubuntu security team handles CVE fixes but I can see if we can get that moving along to help them out
[20:15] <coreycb> shubjero: it looks like we need to get the ubuntu package patched for queens, stein, and train. ussuri+ already include it.
[23:04] <coreycb> shubjero: we have that horizon change in progress