[05:39] 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] 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] 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] rbasak: I ensured that the sync has all we had before (as usual) [06:15] rbasak: which content would you want to release as new version? [06:16] 5.11 from master I guess seeing you tagging it yesterday [06:18] Well, the tag is enough for upstream as a release I guess. [06:18] Is the problem about making a tarball that matches the old style? [06:18] or about getting a debian/ubuntu upload that is 5.10-1 + the new changes? [06:37] 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] https://gist.github.com/smoser/3cd61fe6e08f0c0955ef949350897d15#file-readme-md is what I followed [06:48] rbasak: TBH for the pkg-upload I'd recommend rebaseing 5.10..5.11 onto pkg/ubuntu/devel [06:49] rbasak: that should content-wise be the same, match the orig tgz and has individual commits [06:49] what else would you want? [06:49] 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] which would allow to re-sync later as usual [06:51] and afterwards you could throw a "align debian/*" commit onto master that unites Debian/Upstream packaging [06:51] but anyway I start to outline my preferred way, you could easily have a different one and that still would be fine [06:51] 5.10 and 5.11 are upstream tags though [06:52] Rebasing the upstream branch onto a packaging branch seems wrong, unless I misunderstand? [06:52] Good morning [06:53] rbasak: it is the same as if you'd import a new orig tarball, but retaining individual commits [06:53] 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] good morning lordievader [06:54] I'm trying to sort it out so there's a straightforward process for the future [06:54] Of course I can easily hack together something for this time [06:54] ah now I see your point, more for future than this upload ... [06:54] Right [06:55] I'd like the process to be quick and mindless [06:55] Right now it really isn't :-/ [06:55] 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] Let's see what Scott thinks [06:56] 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] that would work for me and make this "less special" [06:57] 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] 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] 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] Tuor: https://wiki.debian.org/UnattendedUpgrades, perhaps? [12:05] 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] 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] I guess the hint is to RTFS - sorry don't know a better way [12:08] Which manual?! Where is the manual? I'm asking for the manual and you say I should read it. Really? [12:50] Tuor: I think you want `man unattended-upgrade` and `man 5 apt.conf` [12:52] Wait, apt.conf may not apply. [12:56] Not sure if there are options beyond those in the default `/etc/apt/apt.conf.d/50unattended-upgrades` config. [13:12] Tuor: RTFS as in Source [13:13] odc: it's just perl after all - should be readable [13:14] true [13:14] isnt that actually mutually exclusive ? [13:15] I hate how people say perl isn't readable and seem to have no problem with haskell, rust, c++, etc. [13:15] well, i have tons of perl scripts i wrote myself 10y ago that will take me a day to undersand again 🙂 [13:17] ah yes, that's a common problem ^^ [13:19] * RoyK rather likes perl [13:29] rather like knitting ... knit one, pearl one, drop one, curl one [13:33] lol === ddstreet_away is now known as ddstreet [14:05] Hmm, first time I'll read some perl, lets see how easy it is to read. :D [14:06] perl? looks like python to me, but I have no idea how perl looks.. [14:12] my perl always looks like shell ... but so does my python as well 😛 [14:27] github.com:mvo5/unattended-upgrades.git has a readme :) [14:57] Well, foilks, Ubuntu as a server should get a TON more popular: https://blog.centos.org/2020/12/future-is-centos-stream/ [15:00] damn, oracle will have a huge uptake [15:03] Ya....I mean I am a mixed shop, RH and Ubuntu...but ya [15:17] has the apt package ovirt-guest-agent been named differently in focal or just dropped? [15:22] Tuor can't find it with packages.ubuntu.com :/ [15:54] \o/ [16:01] it seams qemu-guest-agent replaces ovirt-guest-agent... [16:02] at leat the description with apt show qemu-guest-agent looks similar to what apt show ovirt-guest-agent used to look. [16:07] sounds to me that wouldn't be the case, as ovirt is not qemu Tuor [16:14] 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] hmm sad. [16:30] 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. === ijohnson is now known as ijohnson|lunch === denningsrogue4 is now known as denningsrogue [19:55] 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] 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. [20:14] 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] shubjero: it looks like we need to get the ubuntu package patched for queens, stein, and train. ussuri+ already include it. === ijohnson|lunch is now known as ijohnson === vlm_ is now known as vlm [23:04] shubjero: we have that horizon change in progress === vlm_ is now known as vlm