rbasakcpaelzer: 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
rbasakMaybe 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:39
rbasakThen 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.05:40
cpaelzerrbasak: I ensured that the sync has all we had before (as usual)06:15
cpaelzerrbasak: which content would you want to release as new version?06:15
cpaelzer5.11 from master I guess seeing you tagging it yesterday06:16
cpaelzerWell, the tag is enough for upstream as a release I guess.06:18
cpaelzerIs the problem about making a tarball that matches the old style?06:18
cpaelzeror about getting a debian/ubuntu upload that is 5.10-1 + the new changes?06:18
rbasakcpaelzer: 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 it06:37
rbasakhttps://gist.github.com/smoser/3cd61fe6e08f0c0955ef949350897d15#file-readme-md is what I followed06:37
cpaelzerrbasak: TBH for the pkg-upload I'd recommend rebaseing 5.10..5.11 onto pkg/ubuntu/devel06:48
cpaelzerrbasak: that should content-wise be the same, match the orig tgz and has individual commits06:49
cpaelzerwhat else would you want?06:49
cpaelzerand also yes, given that Debian seems to now care about it you could propose just the same change to them as well06:49
cpaelzerwhich would allow to re-sync later as usual06:49
cpaelzerand afterwards you could throw a "align debian/*" commit onto master that unites Debian/Upstream packaging06:51
cpaelzerbut anyway I start to outline my preferred way, you could easily have a different one and that still would be fine06:51
rbasak5.10 and 5.11 are upstream tags though06:51
rbasakRebasing the upstream branch onto a packaging branch seems wrong, unless I misunderstand?06:52
lordievaderGood morning06:52
cpaelzerrbasak: it is the same as if you'd import a new orig tarball, but retaining individual commits06:53
cpaelzerrbasak: 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:53
cpaelzergood morning lordievader06:54
rbasakI'm trying to sort it out so there's a straightforward process for the future06:54
rbasakOf course I can easily hack together something for this time06:54
cpaelzerah now I see your point, more for future than this upload ...06:54
rbasakI'd like the process to be quick and mindless06:55
rbasakRight now it really isn't :-/06:55
rbasakI 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:55
rbasakLet's see what Scott thinks06:56
rbasakRight 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:56
cpaelzerthat would work for me and make this "less special"06:57
cpaelzerand 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 works06:57
rbasakWe'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.06:58
TuorHi, 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.11:31
RoyKTuor: https://wiki.debian.org/UnattendedUpgrades, perhaps?12:01
TuorRoyK: 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
TuorIn the default config comming with the package, there are comments for a lot of options. Is the default config listing every available option?12:05
RoyKI guess the hint is to RTFS - sorry don't know a better way12:06
TuorWhich manual?! Where is the manual? I'm asking for the manual and you say I should read it. Really?12:08
lordievaderTuor: I think you want `man unattended-upgrade` and `man 5 apt.conf`12:50
lordievaderWait, apt.conf may not apply.12:52
lordievaderNot sure if there are options beyond those in the default `/etc/apt/apt.conf.d/50unattended-upgrades` config.12:56
RoyKTuor: RTFS as in Source13:12
RoyKodc: it's just perl after all - should be readable13:13
ograisnt that actually mutually exclusive ?13:14
odcI hate how people say perl isn't readable and seem to have no problem with haskell, rust, c++, etc.13:15
ograwell, i have tons of perl scripts i wrote myself 10y ago that will take me a day to undersand again 🙂13:15
odcah yes, that's a common problem ^^13:17
* RoyK rather likes perl13:19
TJ-rather like knitting ... knit one, pearl one, drop one, curl one13:29
=== ddstreet_away is now known as ddstreet
TuorHmm, first time I'll read some perl, lets see how easy it is to read. :D14:05
Tuorperl? looks like python to me, but I have no idea how perl looks..14:06
ogramy perl always looks like shell ... but so does my python as well 😛14:12
Tuorgithub.com:mvo5/unattended-upgrades.git has a readme :)14:27
UssatWell, foilks, Ubuntu as a server should get a TON more popular:  https://blog.centos.org/2020/12/future-is-centos-stream/14:57
quadrathoch2damn, oracle will have a huge uptake15:00
UssatYa....I mean I am a mixed shop, RH and Ubuntu...but ya15:03
Tuorhas the apt package ovirt-guest-agent been named differently in focal or just dropped?15:17
quadrathoch2Tuor can't find it with packages.ubuntu.com :/15:22
Tuorit seams qemu-guest-agent replaces ovirt-guest-agent...16:01
Tuorat leat the description with apt show  qemu-guest-agent looks similar to what apt show ovirt-guest-agent used to look.16:02
quadrathoch2sounds to me that wouldn't be the case, as ovirt is not qemu Tuor16:07
cpaelzerTuor: they are different things - ovirt-guest-agent talks with oVirt manager; qemu-guest-agent exposes other things (like freeze/thaw hooks, shutdown, ...)16:14
Tuorhmm sad.16:15
TuorMy 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.16:30
=== ijohnson is now known as ijohnson|lunch
=== denningsrogue4 is now known as denningsrogue
shubjerocoreycb: 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
ubot3An 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>19:55
coreycbshubjero: typically the ubuntu security team handles CVE fixes but I can see if we can get that moving along to help them out20:14
coreycbshubjero: it looks like we need to get the ubuntu package patched for queens, stein, and train. ussuri+ already include it.20:15
=== ijohnson|lunch is now known as ijohnson
=== vlm_ is now known as vlm
coreycbshubjero: we have that horizon change in progress23:04
=== vlm_ is now known as vlm

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