[00:00] <mwhudson> ubuntu-archive: can one of you act on the "Source and binary movements to universe" for golang-goprotobuf
[00:22] <vorlon> mwhudson: https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.html says the source should be in main
[00:23] <mwhudson> vorlon: huh
[00:23] <vorlon> mwhudson: so, binary demoted but source left in main which I think dtrt
[00:23] <vorlon> I expect the source is wanted via built-using
[00:23] <mwhudson> vorlon: y tho
[00:23] <mwhudson> oh
[00:23] <vorlon> (which continues to be less than obvious from the reports)
[00:24] <vorlon> so how about golang-github-grpc-ecosystem-grpc-gateway? it also ftbfs and has non-trivial revdeps
[00:26] <mwhudson> vorlon: i'
[00:26] <mwhudson> vorlon: i'm not seeing anyting built-using on golang-goprotobuf in main
[00:26] <mwhudson> grep-dctrl   -n -FBuilt-Using golang-goprotobuf -sSource:Package ~/.chdist/groovy/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_groovy*main*Packages
[00:26] <vorlon> mwhudson: it'll be something only in -proposed
[00:26] <mwhudson> ^ command i ran
[00:27] <vorlon> and also it might be that the revdeps themselves are not yet promoted to main due to MIR
[00:27] <vorlon> anyway I think this is all the google agent MIR and will blindly follow the reports until things migrate
[00:27] <mwhudson> ah ok
[00:29] <mwhudson> if platform.machine() in ["aarch64", "arm64"]:
[00:29] <mwhudson> 	include_dirs.append("sse2neon/")
[00:29] <mwhudson> 	extra_compile_args.extend(['-ftree-vectorize', '-DKSW_SSE2_ONLY', '-D__SSE2__'])
[00:29] <mwhudson> else:
[00:29] <mwhudson> 	extra_compile_args.append('-msse4.1') # WARNING: ancient x86_64 CPUs don't have SSE4
[00:29] <mwhudson> ....
[00:29] <mwhudson> how did this ever build on say ppc64el
[00:30] <vorlon> heh
[00:32] <mwhudson> oh i think the python bit of the package simply wasn't built before
[00:41]  * mwhudson looks at golang-github-grpc-ecosystem-grpc-gateway
[01:05] <mwhudson> uhh now i have this strong desire to go for a walk outside, i'm sure this is just a coincidence
[02:04] <mwhudson> vorlon: i think the problem is mostly that our golang-goprotobuf is now too new
[08:12] <seb128> LocutusOfBorg,hey, are you have any luck with the gstreamer updates?
[08:13] <Laney> waveform: no meta from the common seed, it just gets incorporated into desktop/server
[08:14] <LocutusOfBorg> seb128, I finished yesterday the poppler transition :)
[08:14] <LocutusOfBorg> today/tomorrow is gst
[08:14] <seb128> LocutusOfBorg, thanks
[08:14] <LocutusOfBorg> gdal required lots of pet working
[08:15] <seb128> :-/
[08:15] <seb128> thanks for fixing it though!
[08:16] <seb128> libreoffice seems to finish the remaining arm build, hopefully that's enough to complete the transition now
[08:16] <LocutusOfBorg> yep, waiting for glibc :)
[08:17] <LocutusOfBorg> gdal got trapped by the rpc removal, I had to tweak pkg-config files and configure scripts to let it find tinyrpc correctly
[08:19] <seb128> what's the deal with the new glibc and i386 tests?
[08:21] <Laney> something cross toolchain, rbalint is supposed to be sorting it out
[08:33] <rbalint> doko, i think the cross-toolchain-base needs a new update, at least i think there will not be cross packages for the new libc-dev dependencies, like there will be no rpcsvc-proto-i386-cross package . i'm observing the issue at https://autopkgtest.ubuntu.com/packages/a/acl/groovy/i386
[08:34] <cpaelzer> rbalint: I agree and filed https://bugs.launchpad.net/ubuntu/+source/cross-toolchain-base-ports/+bug/1895632 for the same Issue I guess
[08:34] <rbalint> yes, glibc is waiting for cross toolchain and i'm checking the other failures
[08:35] <Laney> rbalint: did you consider a status update to devel or discourse?
[08:35] <Laney> a quick one
[08:36] <rbalint> cpaelzer, thanks, i should have checked for that! now i added the update-excuse tag to have this bug showing up
[08:36] <seb128> it's a bit disappointing that the ffe was approved without having those problems sorted out
[08:37] <seb128> having the archive disrupted like that for a week getting closer from beta is an issue
[08:40] <seb128> vorlon, ^ btw since you approved the ffe
[08:44] <rbalint> seb128, imagine doing that while other automatic syncs are on and there are other ongoing transitions...
[08:45] <seb128> rbalint, imagine preparing the corresponding cross build packages in a ppa to be uploaded at the same time as the glibc update to avoid blocking the archive by screwing i386 for a week...
[08:45] <cpaelzer> glibc always comes late due to badly aligned release schedules - we had the discussion 5 maybe 6 times now. It will keep re-occuring this way unless we decide once to skip and then would always have the glibc fromt he beginning of the cycle (before syncs/transitions are on) instead of the one at the end.
[08:45] <doko> rbalint: that probably should be fixed in glibc to not create those for the cross builds
[08:45] <seb128> being late is not an excuse to not prepare the packages that need to go with it
[08:46] <doko> calm down
[08:47] <rbalint> seb128, ack, the cross toolchain was on my list to fix and considered fixing it in the archive is ok. next time i'll have it prepared in advance
[08:47] <seb128> thanks, do we have an eta on fixing that? why is it taking so long, anything that can be done to help unblocking things?
[08:50] <cpaelzer> Compared to the past I must say that it now was known to hit around now from https://discourse.ubuntu.com/t/groovy-gorilla-release-schedule/15531 for quite a while.
[08:50] <cpaelzer> And since it always causes some issues that is why we try to plan for a less-effective week when glibc hits (since it occurred multiple times).
[08:51] <seb128> cpaelzer, we shouldn't have to had a week off for other teams because glibc lands though...
[08:51] <rbalint> seb128, _this is the issue we are currently working on, eta is "soon"_
[08:52] <rbalint> seb128, let's have this conversation after glibc went through, i agree that there are improvement needed to make landing it smoother
[08:53] <rbalint> doko, ok, looking at how this could be fixed in glibc
[08:53] <seb128> ack
[09:03] <cpaelzer> doko: for bug 1890435 would it help you if I ry to recreate (for extra debug data) that on armhf canonistack or is that wasted effort?
[09:05] <cpaelzer> Laney: cjwatson: does one of you know what "code 14" wants to tell me on https://autopkgtest.ubuntu.com/packages/s/systemd/groovy/s390x ?
[09:05] <Laney> oh! hi!
[09:06] <cpaelzer> :-) FYI related to retries for 1895576
[09:06] <Laney> cpaelzer: they're documented in the manpage
[09:06] <Laney>  14 erroneous package and at least one test skipped
[09:06] <doko> cpaelzer: ye please, if you can reproduce it
[09:06] <cpaelzer> well that is an easy answer, /me goes looking ...
[09:06] <cpaelzer> doko: ok I'm giving it a try and will let you know later
[09:06] <cpaelzer> thanks Laney, found it
[09:07] <cpaelzer> didn't expect to find it to literal in the Web UI
[09:07] <Laney> usually those are mapped to friendly strings
[09:07] <Laney> but not for all exit codes
[09:07] <Laney> if you want to find a nice emoji to represent that I'd merge a MP :P
[09:08] <Laney> anyway looks like something weird happened with the kernel stuff, IIRC that kernel-testing path is taken when there's linux stuff in the triggers
[09:09] <Laney> https://git.launchpad.net/autopkgtest-cloud/tree/worker/worker#n496
[09:10] <Laney> not sure if this indicates something to do with kernel packaging or if it's a "don't do that then"
[09:14] <cjwatson> cpaelzer: no point tagging me in questions about autopkgtest FWIW - in general I know ~nothing about it
[09:18] <Laney> hmm no, actually, it looks like it's something to do with qemu-system-s390x actually
[09:18] <Laney> actually actually ACTUALLY
[09:25] <Laney> maybe that will sort itself out when the arch:all build is done, but that looks depwait on the cross toolchain stuff
[13:20] <cpaelzer> is there a simple way to get "apt build-dep qemu" to work only for the binary-arch part?
[13:20] <cpaelzer> there are things in Build-Depends-Indep which are not available on armhf which is where I am
[13:58] <ahasenack> hi tjaalton, what do you think about https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1895645 ? It seems to make sense
[13:59] <ahasenack> sssd-common suggests (and not recommends) sssd-tools, so no danger in bringing in all that dbus stack by default
[13:59] <tjaalton> ahasenack: yeah, and matches what the rpm does
[14:00] <tjaalton> adding recommends
[14:00] <ahasenack> so sssd-tools recommends sssd-dbus
[14:00] <tjaalton> yes
[14:00] <ahasenack> agreed
[14:01] <tjaalton> and about the socket activation vs conffile conflict, I guess it should be debugged why having both ends up in misery, since apparently it's not an issue on fedora..
[14:01] <ahasenack> fedora doesn't enable the systemd services by default upon install
[14:01] <tjaalton> huh
[14:01] <tjaalton> ok
[14:01] <ahasenack> it's up to the user to either do systemctl enable, or add the services= line to sssd.conf
[14:02] <ahasenack> if they use realmd, then having it add services= to sssd.conf just makes it work without conflicts
[14:02] <tjaalton> right
[14:04] <tjaalton> hum, wonder if we should do the same, not sure the current state is ideal
[14:08] <ahasenack> tjaalton: I tried some reboots, commands, etc, at most saw a small delay in the response
[14:08] <ahasenack> but of course it's not a good replication of real world scenarios
[14:08] <ahasenack> for how many cycles have we been using socket activation now? two, not counting groovy?
[14:09] <ahasenack> and I didn't get further details in the mailing list about what was breaking in some cases
[14:09] <ahasenack> other than "general practice" advice
[14:10] <ahasenack> as it's probably rare that a system that is using sssd would not use it for a long enough time to have the daemons stop and wait for a connection to startup again
[14:13] <ahasenack> tjaalton: https://salsa.debian.org/sssd-team/sssd/-/merge_requests/9 ?
[14:37] <tjaalton> ahasenack: merged
[14:37] <ahasenack> thx
[14:39] <tjaalton> looks like socket activation has been enabled roughly a year ago
[14:40] <cjwatson> cpaelzer: --arch-only
[14:40] <ahasenack> I think our #DEBHELPER# postinst tries to enable all services, socket or otherwise, but systemd is smart to know when a socket starts a service and handles that
[14:58] <cpaelzer> thanks cjwatson
[14:59] <cpaelzer> ahasenack: the handling of this changed a lot between dh 10/11/12
[14:59] <cpaelzer> I was facing several bugs due to it in libvirt, so it depends what level your package is on
[14:59] <cpaelzer> (behaviour depends)
[14:59] <ahasenack> groovy, so 12 or 13
[16:05] <bdmurray> rbalint: Is there anything that has changed with systemd with apport-autoreport.path or apport-autoreport.service need updating? https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/groovy/apport/ubuntu/files/head:/debian
[16:08] <rbalint> bdmurray, i suspect the .service needs to be updated but i have to check that, there were several changes around .service handling
[16:33] <bdmurray> cpaelzer: How did you generate https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1892358/comments/13 ?
[17:29] <cpaelzer> bdmurray: https://git.launchpad.net/~ubuntu-server/ubuntu-helpers/tree/README.md#n17  https://git.launchpad.net/~ubuntu-server/ubuntu-helpers/tree/cpaelzer/check-autopkgtest-stats.sh
[17:37] <bdmurray> cpaelzer: Neat, is there anything for producing a history of results for the autopkgtest results? I mean not breaking it down by individual tests.
[17:45] <bdmurray> cpaelzer: Oh this looks neat cpaelzer/packageset-subscription-mismatches.sh check but does it check all LTS versions? e.g. something that is still in main for xenial?
[17:48] <bdmurray> Heh and "increas my public shame counter" spelling increase wrong will definitely help with the shame counter
[17:48] <sarnold> shame! shame!
[17:56] <abyssangel> join #ubuntu-devel
[17:56] <bdmurray> you're already here
[17:56] <abyssangel> hello
[18:02] <abyssangel> u guys do a great job with da old ubuntu linux!
[18:06] <bdmurray> thanks, that's nice to hear
[18:06] <abyssangel> thank bdmurray
[18:25] <cpaelzer> bdmurray: the script you asked is something we do at sprints after LTSes to clear out things nor more meant to be maintained
[18:25] <cpaelzer> and the list it creates will also give an ETA when you can drop things
[18:55] <abyssangel> how does #ubuntu-devel work
[18:57] <sarnold> abyssangel: you can see some of the past conversation on https://irclogs.ubuntu.com/latest/%23ubuntu-devel.html
[19:02] <abyssangel> thank u sarnold, bookmarked it
[19:04] <abyssangel> i want to join ubuntu development
[19:04] <sarnold> welcome :) what are you looking to do?
[19:08] <abyssangel> :) i am  a c and c++ programmer, so maybe testing, debugging and contributing code
[19:20] <abyssangel> i am a c and c++ programmer, i would like to do testing, debugging and maybe contribute code
[19:24] <rafaeldtinoco> abyssangel: https://wiki.ubuntu.com/ContributeToUbuntu#Maintaining_Ubuntu
[19:24] <rafaeldtinoco> abyssangel: welcome. read our documentation about how to contribute first, this will guide you through!
[19:26] <abyssangel> thank you rafaeldtinoco, i love to be part of the ubuntu family
[20:23] <abyssangel> how can i dev on ubuntu from source in safe way
[20:26] <sarnold> abyssangel: whenever I need to compile something that didn't come from the ubuntu archives, I use an apparmor profile like this: http://paste.ubuntu.com/p/T7c3RCf6Pv/
[20:29] <abyssangel> ;)
[21:15] <vorlon> seb128: the impact on cross-toolchain-base was non-obvious at the time of ffe approval