[05:39] <cpaelzer> good morning
[05:41] <utkarsh2102> \o
[06:39] <cpaelzer> sergiodj: ahasenack: I have brougth https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1951490 a bit further
[06:40] <cpaelzer> after talking to mdeslaur it isn't really a security triggerd regression, so the upload would be a normal SRU (and a jammy fix btw)
[06:40] <cpaelzer> could one of you please have a look after that from here?
[07:47] <paride> o/
[08:52] <paride> I just noticed that mailman3 has been removed from Jammy
[08:54] <lotuspsychje> paride: i see a mailman3-web in my apt-cache
[08:55] <paride> lotuspsychje, https://bugs.launchpad.net/ubuntu/+source/mailman3/+bug/1960547
[10:03] <athos> the libreoffice builds in proposed we were using to get pkgs to merge was superseeded yesterday and is being rebuilt for a few hours now
[10:03] <athos> I will re-trigger nss tests once this is done: https://launchpad.net/ubuntu/+source/libreoffice/1:7.3.1~rc2-0ubuntu1
[10:03] <athos> good morning o/
[10:10] <utkarsh2102> \o
[11:38] <utkarsh2102> hey
[11:38] <utkarsh2102> how do we merge from experiemental?
[11:39] <utkarsh2102> I mean, how do we start the process?
[11:39] <utkarsh2102> i.e. the git-ubuntu one
[11:43] <utkarsh2102> cpaelzer, paride, rbasak, athos^
[11:47] <paride> utkarsh2102, I think by specifying `onto` in `git ubuntu merge start`
[11:48] <paride> utkarsh2102, see `onto` in `git ubuntu merge --help`, it says "If not specified, debian/sid is used."
[12:12] <utkarsh2102> paride: I read that, but that doesn't seem to work 
[12:35] <mirespace> Hi, May I ask for a review on this? Thanks :) https://code.launchpad.net/~mirespace/ubuntu/+source/lto-disabled-list/+git/lto-disabled-list/+merge/416029
[12:35] <mirespace> it's disabling lto for wireshark on arm64 and s390x
[13:21] <paride> cpaelzer, as you are reviewing mirespace's branch above, one question for you: do we have a way to do sponsored uploads that make the importer merge the proposed branch using the extra fields in the .changes file?
[13:23] <cpaelzer> hi paride
[13:23] <paride> I think `git ubuntu prepare-upload --remote` can _almost_ do it, but it tries to push to the sponsored user remote, and that can't succeed of course
[13:24] <paride> hi :-)
[13:24] <cpaelzer> by default it will try to use your name and your remote (= the sponsors)
[13:25] <cpaelzer> and yes --remote will push to someone elses branch which will fail
[13:25] <cpaelzer> paride: so you are asking for a "do not push, but take it as-is from this remote" right?
[13:25] <cpaelzer> instead of pushing it could then verify that the head of that remote is matching the local tree
[13:25] <paride> cpaelzer, basically yes. or "do not push, only check that remote is up to date"
[13:26] <cpaelzer> yep that is what I just added
[13:26] <cpaelzer> valid feature request I'd say, I do not think it exists yet
[13:28] <paride> ty
[15:46] <bryyce> good morning
[16:03] <sergiodj> utkarsh2102: hi, I noticed you picked both openvpn and vsftpd MPs.  just checking to see how's the progress on those
[16:04] <sergiodj> given that today's feature freeze and all...
[16:06] <utkarsh2102> sergiodj: i'mma do this before my EOD 
[16:06] <utkarsh2102> that is, in the next hour or two 
[16:06] <sergiodj> ACK, thanks
[16:06] <utkarsh2102> sergiodj: also, hi! :)
[16:06] <sergiodj> hi :)
[17:13] <ahasenack> hello server devs, if I could get a review on adcli please: https://code.launchpad.net/~ahasenack/ubuntu/+source/adcli/+git/adcli/+merge/416042
[17:24] <athos> I will take it :)
[17:28] <ahasenack> \o/
[17:30] <betuxy> hey guys  I was wondering  how to prevent apache to just take the first vhost instead of  maybe showing an error when a site is  not accesible? do I need an extra vhost for this?
[17:32] <sdeziel> betuxy: you can create a(nother) vhost, make it the default and have it return an error
[17:54] <bryyce> doctrine built successfully and several packages passed; down to 3 packages failing tests for php8.1.2
[18:15] <bryyce> rbasak, so the style of problem I'm trying to figure out, that I mentioned in standup, is FTBFS due to invalid dependency version, e.g.: https://launchpadlibrarian.net/587742329/buildlog_ubuntu-jammy-amd64.symfony_5.4.4+dfsg-1ubuntu2_BUILDING.txt.gz
[18:16] <bryyce> the log provides a list of dependencies it pulls in, and then an error that a subdependency of one of those packages is the wrong version, but the log does not connect the dots to which dependency pulled in that subdependency.  And the log also does not indicate what package versions it pulled in
[18:17] <bryyce> I was able to figure that out with doctrine via a bit of brute force, but it took some time and seems like something a tool ought to be able to calculate for me
[18:18] <bryyce> I looked at chdist-if-migrated but this seems to address dep8 failures rather than ftbfs
[18:20] <lvoytek> sdeziel: Do you have any additional suggestions for the swtpm apparmor profile merge request? Also would you be willing to sponsor the upload? Thanks!
[18:20] <lvoytek> https://code.launchpad.net/~lvoytek/ubuntu/+source/swtpm/+git/swtpm/+merge/415813
[18:22] <sdeziel> lvoytek: I don't have the necessary rights, I was just doing a drive-by review ;)
[18:22] <lvoytek> Ah fair, thanks
[18:23] <sdeziel> lvoytek: regarding the Apparmor profile itself, is the dac_override thing needed for the @{HOME} rule?
[18:24] <lvoytek> The dac_override addition ended up being needed for some of the swtpm-controlled files in /tmp
[18:26] <sdeziel> interesting, I'm now sure how that plays with the `owner` prefix
[18:27] <sdeziel> is there a specific reason why the @{HOME} rule doesn't have the `owner` prefix?
[18:28] <lvoytek> Ah no I guess it would be best to have the owner prefix there too
[18:31] <athos> ahasenack: just replied to the adcli mp; sorry for the delay ;) Let me know when you get to it (I know we are in a tight schedule here); do note that the item regarding the package version there is a question, not a RFC :)
[18:33] <sdeziel> lvoytek: https://git.launchpad.net/ubuntu/+source/swtpm/tree/debian/swtpm-tools.postinst shows the user's home is /var/lib/swtpm which won't be covered by the @{HOME} rule. As such I don't understand what's the purpose of that rule
[18:36] <ahasenack> athos: thanks, looking
[18:40] <lvoytek> sdeziel: The rule was meant for certain use cases where that folder may be used when running swtpm but it may be a bit too specific. I think it'd be reasonable to remove that rule here and have programs/users add it to the local config if needed
[18:40] <rbasak> bryyce: ah so for this case I think you can use plain chdist
[18:41] <rbasak> hcdist jammy-proposed apt-get -s install php-symfony-console php-psr-log
[18:41] <rbasak>  php-symfony-console : Breaks: php-psr-log (>= 3) but 3.0.0-1 is to be installed
[18:41] <rbasak> So that reproduces the issue
[18:42] <bryyce> rbasak, ah so indeed.  thanks
[18:42] <bryyce> heh, unfortunately does not tell me what I don't already know.  At least it's fast
[18:43] <sdeziel> lvoytek: OK, lgtm then
[18:43] <rbasak> bryyce: try hcdist jammy-proposed apt-cache policy php-symfony-console php-psr-log
[18:43] <rbasak> So then you have the versions
[18:43] <lvoytek> sdeziel: thanks!
[18:43] <rbasak> bryyce: based on that I try: hcdist jammy-proposed apt-get -s install php-symfony-console=5.4.4+dfsg-1ubuntu1 php-psr-log=3.0.0-1
[18:43] <rbasak> So that's "everything from proposed"
[18:44] <rbasak> And I get the same thing
[18:44] <rbasak> $ hcdist jammy-proposed-only grep-dctrl-packages -XP php-symfony-console -sBreaks
[18:44] <bryyce> rbasak, you get something different from "E: Unable to locate package php-symfony-console"?
[18:44] <rbasak> Breaks: php-psr-log (>= 3), php-symfony-dependency-injection (<< 4.4~~), php-symfony-dotenv (<< 5.1~~), php-symfony-event-dispatcher (<< 4.4~~), php-symfony-lock (<< 4.4~~), php-symfony-process (<< 4.4~~)
[18:45] <rbasak> bryyce: yes I see php-symfony-console 5.4.4+dfsg-1ubuntu1 in jammy-proposd
[18:45] <sdeziel> lvoytek: you are welcome, thank you too
[18:45] <bryyce> oh I see, needs sources.list updated
[18:45] <rbasak> bryyce: so it looks like php-symfony-console 5.4.4+dfsg-1ubuntu1 explicitly says Breaks: php-psr-log (>= 3), but php-psr-log is 3.0.0-1 in jammy-proposed
[18:46] <rbasak> So is there a newer php-symfony-console? Why the Breaks?
[18:46] <bryyce> I *think* the breaks is something auto-added, there's not an explicit breaks
[18:47] <bryyce> what's going on here is that one of the dependencies of this package is built against php-psr-log 2.x
[18:47] <ahasenack> athos: replied
[18:48] <bryyce> many of the "php-symfony-*" pieces are binaries of symfony
[18:49] <rbasak> There's something circular going on
[18:49] <bryyce> exactly
[18:49] <rbasak> The build depends of symfony is indirectly requiring a binary produced by the symfony build itself.
[18:49] <rbasak> So it's as if it needs itself to build
[18:49] <bryyce> correct
[18:50] <rbasak> So I guess we need to break that loop somehow ;-/
[18:51] <bryyce> there have been several of these little circular dependencies, both for php 8.1.0 and now for php 8.1.2
[18:52] <bryyce> most of those were just due to running the testsuites during build, but symfony appears to be a bit different
[18:53] <bryyce> doctrine was in a similar situation, and the brute force approach I used there appears to have broken the loop, so I am going to try doing the same for symfony
[18:54] <bryyce> chdist looks like it may be useful in helping trim down the time that was taking, so thanks for pointing that out
[19:00] <rbasak> bryyce: I wonder if the problem has since been fixed in the archive
[19:00] <rbasak> hcdist jammy-proposed apt-get -s satisfy "$(hcdist jammy-proposed-only grep-dctrl-sources -XP symfony -nsBuild-Depends)"
[19:00] <rbasak> That works
[19:02] <athos> ahasenack: ack; +1'd
[19:02] <ahasenack> cheers
[19:04] <rbasak> bryyce: and it doesn't seem to want php-psr-log
[19:04] <rbasak> So AFAICT there is a solution to the build depends as it stands right now that can be met entirely from the current jammy-proposed
[19:04] <rbasak> Maybe try a rebuild?
[19:04] <bryyce> rbasak, cool.  Maybe getting doctrine sorted out has cleared that.  I'll try a nochange rebuild.
[19:04] <rbasak> If it FTBFS, you should be able to hit the rebuild button rather than uploading a no-change changelog
[19:06] <bryyce> no, I already tried that an hour ago
[19:06] <bryyce> https://launchpad.net/ubuntu/+source/symfony/5.4.4+dfsg-1ubuntu2/+build/23170795
[19:06] <rbasak> Uploading a no-change would theoretically make no difference to hitting the rebuild button.
[19:07] <rbasak> Are you sure something hasn't changed in the archive since you last tried it?
[19:07] <bryyce> I haven't uploaded anything, but it's possible some dep8 tests resolved
[19:07] <ahasenack> utkarsh2102: hi, will you still get to https://code.launchpad.net/~sergiodj/ubuntu/+source/vsftpd/+git/vsftpd/+merge/415985 today? It's feature freeze day
[19:07] <bryyce> can't hurt to try another rebuild though.
[19:07] <rbasak> I would hit the button again.
[19:07] <rbasak> Yeah let's try.
[19:08] <rbasak> Because this time we know some additional results are definitely true before trying
[19:08] <rbasak> FWIW, I just tried a satisfy on the merged build-depends from that failure log, and that didn't work:
[19:08] <rbasak> The following packages have unmet dependencies:
[19:08] <rbasak>  command line argument : Depends: composer but it is not going to be installed
[19:08] <rbasak>                          Depends: php-doctrine-orm but it is not going to be installed
[19:08] <ahasenack> sergiodj: I'll start a review of vsftpd too
[19:08] <rbasak> E: Unable to correct problems, you have held broken packages.
[19:08] <ahasenack> as a backup
[19:08] <rbasak> But that doesn't really mean anything if it's out of date.
[19:08] <bryyce> composer still has a ftbfs, due to symfony
[19:09] <bryyce> p-d-orm is a binary of doctrine
[19:13] <rbasak> OK, same result :(
[19:13] <rbasak> Might need to use sbuild to reproduce exactly the same resolver
[19:15] <bryyce> what I did for doctrine was go through each individual dependency, recursively, look up their build logs, and see what version of psr-log it built against.  Then rebuild whatever turns up.
[19:17] <bryyce> the other thing was to do the same, but identify if the subdependency has a ftbfs against it.
[19:18] <bryyce> but that will point to stuff like php-twig and composer that are ftfbs due to symfony, so yet more circles...
[19:18] <rbasak> sbuild locally does reproduce what Launchpad is doing
[19:21] <rbasak> Ah
[19:22] <rbasak> I missed Build-Depends-Indep
[19:22] <rbasak> hcdist jammy-proposed apt-get -s satisfy "$(hcdist jammy-proposed-only grep-dctrl-sources -XP symfony -nsBuild-Depends-Indep)"
[19:22] <rbasak> That reproduces with chdist locally
[19:22] <bryyce> do you have hcdist aliased to chdist?
[19:22] <rbasak> Not the same error but I suspect it's essentially the same thing but the solver is going in a different direction
[19:22] <rbasak> Yeah hcdist just reverses the first two terms
[19:25] <rbasak> hcdist jammy-proposed apt-get -o Debug::pkgProblemResolver=1 -s satisfy "$(hcdist jammy-proposed-only grep-dctrl-sources -XP symfony -nsBuild-Depends-Indep)"
[19:25] <rbasak> https://paste.ubuntu.com/p/8wkd4m27Ww/
[19:27] <rbasak> OK so composer is just uninstallable currently
[19:28] <rbasak> It depends on php-psr-log directly, and on php-symfony-console
[19:29] <bryyce> locally in my lxc container it installs composer (2.1.12-1ubuntu3) ok
[19:29] <rbasak> With proposed enabled?
[19:29] <rbasak> $ hcdist jammy-proposed apt-get -s install composer 
[19:29] <rbasak> ...
[19:29] <bryyce> yeah
[19:29] <rbasak> The following packages have unmet dependencies:
[19:29] <rbasak>  composer : Depends: php-symfony-console but it is not going to be installed
[19:29] <rbasak> E: Unable to correct problems, you have held broken packages.
[19:29] <bryyce> but running console --version triggers a failure
[19:29] <bryyce> PHP Fatal error:  Uncaught Error: Failed opening required 'Symfony/Console/autoload.php' (include_path='.:/usr/share/php') in /usr/share/php/Composer/autoload.php:16
[19:30] <bryyce> interesting.  I had to disable p-s-console to resolve the ftbfs for composer, but looks like it does need that in order to operate
[19:30] <rbasak> For me composer is fine in the release pocket but it's uninstallable with proposed enabled.
[19:31] <rbasak> AFAICT the problem is src:symfony Build-Dep composer, composer Dep php-psr-log and php-symfony-console, and php-symfony-console Breaks (version of php-psr-log in proposed)
[19:32] <bryyce> hrm, so composer requires symfony to build, symfony requires composer to build.
[19:32] <rbasak> I guess that's the loop, yes.
[19:33] <bryyce> I wonder if symfony's dependence on composer is soft and could be disabled
[19:33] <rbasak> I think that's the sort of thing that's been done in the past to bootstrap
[19:34] <rbasak> Every time this comes up I suggest using build profiles to fix this properly, but I appreciate that's hard :-/
[19:34] <bryyce> yeah, I've had to do the inverse with other packages that needed symfony for tests, so may make sense to need to do same for symfony against other stuff
[19:35] <bryyce> I'll see locally if I can build symfony without composer
[19:44] <ahasenack> sergiodj: vsftpd is +1
[19:45] <ahasenack> taking a look at openvpn
[19:56] <utkarsh2102> uh, i was about to 
[19:56] <utkarsh2102> I am in midst, though, ahasenack 
[19:57] <ahasenack> utkarsh2102: openvpn?
[19:57] <utkarsh2102> but thank you 
[19:57] <utkarsh2102> ahasenack: yep, both
[19:57] <ahasenack> ok, continue :)
[19:57] <ahasenack> feature freeze is in a few hours
[19:58] <utkarsh2102> yeah, I'm try to get virglrenderer and exim4, done too 
[20:02] <sergiodj> ahasenack: thanks
[20:05] <utkarsh2102> sergiodj: hey, approved vsftpd with a quick comment.
[20:05] <utkarsh2102> about update-maintainer
[20:07] <sergiodj> utkarsh2102: thanks
[20:10] <ahasenack> odd, dpkg for me doesn't even build a package with an ubuntu version if the maintainer wasn't updated
[20:10] <ahasenack> ah, I got it from a ppa
[20:10] <ahasenack> 1.20.9ubuntu2.1
[20:11] <ahasenack> utkarsh2102: do you still want to mp exim4 and virglrenderer?
[20:30] <utkarsh2102> ahasenack: yep, exim4 is up 
[20:30] <utkarsh2102> could you please review?
[20:30] <ahasenack> yep
[20:35] <sergiodj> ahasenack: I'm looking into the backuppc failure with samba
[20:36] <ahasenack> oh, thanks
[20:36] <ahasenack> I found some old bugs talking about using a different debug setting in smbclient (really old)
[20:36] <ahasenack> which tells me it's very sensitive to the output of smbclient
[20:36] <ahasenack> and one guy said he went back to an older smbclient
[20:36] <sergiodj> yeah
[20:36] <sergiodj> I found them too
[20:36] <ahasenack> with 4.13 it still worked
[20:37] <ahasenack> I tried -d 5, still failed
[20:38] <sergiodj> I'm setting up a container to reproduce the problem here
[20:38] <utkarsh2102> sergiodj, ahasenack: hey, do you know a way to merge a package from experimental using git-ubuntu 
[20:38] <ahasenack> yes
[20:38] <sergiodj> utkarsh2102: yes
[20:38] <ahasenack> add pkg/debian/experimental at the end
[20:38] <ahasenack> git ubuntu merge start pkg/ubuntu/devel pkg/debian/experimental
[20:39] <ahasenack> for example
[20:39] <sergiodj> git ubuntu merge start pkg/ubuntu/devel pkg/debian/experimental
[20:39] <utkarsh2102> wow, you guys are on fire. Thank you very much! 
[20:39] <ahasenack> it's not the middle of the night here yet
[20:39] <ahasenack> :D
[20:39] <utkarsh2102> :D
[20:50] <ahasenack> utkarsh2102: +1
[20:53] <bryceh>  php-psr-link | 1.1.1-1 | jammy/universe 
[20:53] <bryceh> php-psr-link | 2.0.1-1       | experimental
[20:53] <bryceh> rbasak, ^^ might be what's linking to the old psr
[20:56] <bryceh> ...hmm nope doesn't link against any other psr packages
[21:02] <utkarsh2102> ahasenack, sergiodj: virglrenderer MP is up!
[21:05] <ahasenack> hm, I'm not familiar at all with this package
[21:05] <ahasenack> isn't this one of christian's?
[21:06] <ahasenack> ah, I see christian filed a bug
[21:06] <ahasenack> https://bugs.launchpad.net/ubuntu/+source/virglrenderer/+bug/1959175
[21:14] <ahasenack> utkarsh2102: +1, do you know how qemu uses this, and if yes, did you do a quick smoke test?
[21:29] <ahasenack> happy FF day, cya tomorrow
[21:33] <utkarsh2102> ahasenack: hey, I did a super quick smoke test but not with or around qemu. 
[22:26] <sergiodj> ahasenack: managed to find what's going on, but I still don't know why the smbclient behaviour changed.  but I got the test passing at least
[22:39] <sergiodj> found some interesting things.  I'll leave a comment in the bug later; have to go now
[22:56] <ahasenack> nice
[22:56] <ahasenack> I kind of think it's mixing up status info with the actual data it's transferring