[05:06] <jamespage> cpaelzer__: when you're around - both of those MIR's are required for uploads already in disco-proposed (nova and neutron) (also commented on bug)
[05:07] <jamespage> thanks for the reviews
[05:36] <cpaelzer__> jamespage: ok, good to know
[05:36] <cpaelzer__> jamespage: are there others still open blocking you?
[05:36] <jamespage> cpaelzer: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#ubuntu-openstack
[05:36] <jamespage> https://bugs.launchpad.net/ubuntu/+source/websockify/+bug/1108935 is as well
[05:43] <cpaelzer> there is more history to be read on that one for sure ...
[05:45] <cpaelzer> jamespage: this actually is ok already IMHO
[05:45] <cpaelzer> in comment #8 you got the MIR ACK
[05:46] <cpaelzer> in comment #11 and #12 you got the conditional security ack
[05:46] <cpaelzer> and you later adressed these conditions
[05:46] <jamespage> cpaelzer: yup that summarises it nicely!
[05:47] <cpaelzer> OTOH this review stretched 6 years now :-/
[05:47] <cpaelzer> well the active part 2.5 years
[05:47] <cpaelzer> Given that former versions where seucrity acked I'll do a full recheck with that in mind
[05:47] <cpaelzer> most likely that will unblock it for you then
[05:48] <cpaelzer> but I had no breakfast yet, so first things first :-)
[05:48] <jamespage> cpaelzer: breakfast sounds like the priority to me
[06:52] <cpaelzer> jamespage: which openstack exactly does (or would) add the websockify dependency?
[06:52] <cpaelzer> if not yet in a d/control somewhere which entry for depends/recommends did you have in mind?
[06:52] <jamespage> cpaelzer: coreycb added the depends for this cycle I think
[06:52] <jamespage> the version in proposed def runtime depends on it
[06:56] <cpaelzer> python3-websockify I see in nova
[06:56] <cpaelzer> ok
[06:57] <cpaelzer> from python3-nova
[06:57] <cpaelzer> I was concerned since e.g. websockify binary itself still depends on python2 bits
[06:57] <cpaelzer> let me make sure in a contianer it does not pull in py2
[07:03] <cpaelzer> jamespage: websockify itself is good
[07:04] <cpaelzer> jamespage: but spice-html5 needs a check now, doing that next
[07:09] <jamespage> cpaelzer: looking at it we've not seeded nova-spiceproxy
[07:09] <jamespage> so spice-html5 is not being pulled to main
[07:18] <cpaelzer> oh
[07:18] <cpaelzer> jamespage: could you put that as an answer to https://bugs.launchpad.net/ubuntu/+source/websockify/+bug/1108935/comments/24 ?
[07:19] <jamespage> I have
[07:20] <cpaelzer> jamespage: you should at some point add nova-spiceproxy as a suggest to some other package in there
[07:20] <cpaelzer> or people won't even know
[07:20] <jamespage> yah
[07:21] <cpaelzer> jamespage: so should I abort the spice-html5 review as you do't need it?
[07:21] <cpaelzer> jamespage: or do you need it to actually make use of that function, yet only the dependency to pull it in is missing?
[07:21] <jamespage> latter
[07:21] <cpaelzer> ok thanks, going on then
[07:21] <jamespage> but I'll really need a release team +1 to add that as a seeded package
[07:22] <cpaelzer> sure
[07:22] <cpaelzer> but no matter how early or late that review needs to be done in case more follow on actionsare identified
[07:31] <jamespage> cpaelzer: lets push the spice-html5 to next cycle - sounds like we need to re-review anyway
[07:31] <jamespage> thankyou for your review...
[07:51] <cpaelzer> jamespage: you have an ack under constraints for spice-html5
[07:51] <cpaelzer> jamespage: doing it next cycle seems wise, please put the tasks I outlined on your teams list
[07:52] <cpaelzer> you can now self-resolve this to be promotable to main next cycle
[07:52] <jamespage> ok
[07:52] <jamespage> thanks!
[07:52] <cpaelzer> yw
[13:25] <Kolargol00> Hi there! Can someone help me by sponsoring/reviewing a SRU and a backport requests?
[13:25] <Kolargol00> https://launchpad.net/bugs/1822069, https://launchpad.net/bugs/1821888
[13:55] <LeoBras> Hello, I want to fix a bug on libvirt* that is already fixed on mainline (it's a backport to bionic). Where is the right place to get the source code?
[14:14] <LeoBras> For me, it seems that getting the code from 'apt-get source' is different from 'pull-lp-source' even if they are both from bionic
[14:17] <LeoBras> And both are different from the git repo
[14:18] <LeoBras> which one is the right one to fix bugs for?
[14:25] <Eickmeyer> LeoBras: https://launchpad.net/ubuntu/+source/libvirt
[14:25] <Eickmeyer> If you file the bug and have a fix, include the patch.
[14:26] <LeoBras> It points to the git repo, i was right to patch towards this. I need to test the patch first, but building seems to fail when using 'fakeroot debian/rules binary'
[14:27] <LeoBras> (I am trying to build for ppc64el)
[14:27] <LeoBras> (i had done a build-dep before building)
[14:29] <Eickmeyer> LeoBras: What I linked is where the bugs get reported and patches get included. That's where it's done for Ubuntu. If it's fixed upstream and hasn't been merged yet, then that's up to the core developers since the package is in the "Main" repo.
[14:31] <LeoBras> Well, ok, but I can't build even the repository as is using 'fakeroot debian/rules binary'
[14:31] <LeoBras> how am I supposed to test my patch?
[14:32] <Eickmeyer> LeoBras: In order to do that, you need to be able to package it for Ubuntu and test it that way.
[14:32] <LeoBras> what does it mean 'to be able to package it for Ubuntu' ?
[14:32] <Eickmeyer> http://packaging.ubuntu.com/
[14:33] <Eickmeyer> "Debian/rules" isn't a binary, it's part of the packaging. fakeroot is a tool used for packaging.
[14:36] <LeoBras> what should I use to build the package so?
[14:37] <Eickmeyer> LeoBras: The instructions are what I just linked you to.
[14:37] <Eickmeyer> I'm afraid I can't help you any further.
[14:38] <LeoBras> on this guide, it says to get the source code using 'pull-lp-source', and that source differs from the source on https://code.launchpad.net/ubuntu/+source/libvirt
[14:39] <LeoBras> is ther e a reason for it to be different?
[14:49] <cpaelzer> LeoBras: you need to make sure to get the right version(s)
[14:49] <cpaelzer> https://code.launchpad.net/~usd-import-team/ubuntu/+source/libvirt/+git/libvirt/+ref/ubuntu/bionic-devel should match what "pull-lp-source libvirt bionic" gives you right now
[14:51] <cpaelzer> LeoBras: or you can use https://snapcraft.io/git-ubuntu and just run "git ubuntu clone libvirt"
[14:51] <cpaelzer> LeoBras: could you sent me a sneak peak to the upstream change please?
[14:53] <LeoBras> cpaelzer, oh I cloned https://code.launchpad.net/ubuntu/+source/libvirt and the only bionic branch was origin/ubuntu/bionic-4.0
[15:00] <LeoBras> cpaelzer, about building the change locally on a ubuntu package, how to do it?
[15:02] <LeoBras> cpaelzer, oops, sorry, I accidentally cloned git://git.launchpad.net/~libvirt-maintainers/ubuntu/+source/libvirt my mistake
[15:13] <LeoBras> cpaelzer, oh the upstream commit is 55ce6564
[15:14] <LeoBras> cpaelzer, The bug is being migrated from our bugzilla to launchpad soon
[15:21] <LeoBras> cpaelzer, it seems the patch is already applied, but the git history seems to not describe this single patch
[17:32] <wxl> cyphermox: @tsimonq2 suggested i get in touch with you. as you know, lubuntu uses calamares installer. for encryption, it uses the latest cryptsetup, which defaults to luks2.. which is incompatible with grub2. apparently there's a compile-time option to set the default version to luks1. as i read it, this would not eliminate the abilitity of others to use luks2 (although it's a bit impractical given the
[17:32] <wxl> state of grub). do you think we could make this the default?
[18:48] <pedahzur> Trying to walk https://bugs.launchpad.net/ubuntu/+source/adcli/+bug/1821242 through the fix process, and am reading https://wiki.ubuntu.com/StableReleaseUpdates. Is there a "First timer HOWTO doc" somewhere out there?  This is all really new to me. :)
[19:07] <rbasak> pedahzur: thank you for working on that. I'm sorry the documentation isn't any better. You're in the right place to ask though, and I and others would be happy to walk you through it here.
[19:07] <rbasak> It's late in the evening for me and I'm about to disappear though, sorry.
[19:08] <pedahzur> It's not *terribly* time crucial, as we have a local build with the fix, but I would like to see this fixed in the official package. I'll hit you up Monday morning (my time) and we can see if we can walk through it.
[19:09] <pedahzur> rbasak: Hopefully that will hit your "afternoon" and we have an hour or two of overlap. :)
[19:09] <rbasak> Sure. Thanks!