[00:00] ubuntu-archive: can one of you act on the "Source and binary movements to universe" for golang-goprotobuf [00:22] mwhudson: https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.html says the source should be in main [00:23] vorlon: huh [00:23] mwhudson: so, binary demoted but source left in main which I think dtrt [00:23] I expect the source is wanted via built-using [00:23] vorlon: y tho [00:23] oh [00:23] (which continues to be less than obvious from the reports) [00:24] so how about golang-github-grpc-ecosystem-grpc-gateway? it also ftbfs and has non-trivial revdeps [00:26] vorlon: i' [00:26] vorlon: i'm not seeing anyting built-using on golang-goprotobuf in main [00:26] 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] mwhudson: it'll be something only in -proposed [00:26] ^ command i ran [00:27] and also it might be that the revdeps themselves are not yet promoted to main due to MIR [00:27] anyway I think this is all the google agent MIR and will blindly follow the reports until things migrate [00:27] ah ok [00:29] if platform.machine() in ["aarch64", "arm64"]: [00:29] include_dirs.append("sse2neon/") [00:29] extra_compile_args.extend(['-ftree-vectorize', '-DKSW_SSE2_ONLY', '-D__SSE2__']) [00:29] else: [00:29] extra_compile_args.append('-msse4.1') # WARNING: ancient x86_64 CPUs don't have SSE4 [00:29] .... [00:29] how did this ever build on say ppc64el [00:30] heh [00:32] 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 === paride0 is now known as paride [01:05] uhh now i have this strong desire to go for a walk outside, i'm sure this is just a coincidence [02:04] vorlon: i think the problem is mostly that our golang-goprotobuf is now too new === Nafallo_ is now known as Nafallo [08:12] LocutusOfBorg,hey, are you have any luck with the gstreamer updates? [08:13] waveform: no meta from the common seed, it just gets incorporated into desktop/server [08:14] seb128, I finished yesterday the poppler transition :) [08:14] today/tomorrow is gst [08:14] LocutusOfBorg, thanks [08:14] gdal required lots of pet working [08:15] :-/ [08:15] thanks for fixing it though! [08:16] libreoffice seems to finish the remaining arm build, hopefully that's enough to complete the transition now [08:16] yep, waiting for glibc :) [08:17] 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] what's the deal with the new glibc and i386 tests? [08:21] something cross toolchain, rbalint is supposed to be sorting it out === Laney changed the topic of #ubuntu-devel to: Archive: Feature Freeze, Debian Import Freeze | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Focal | If you can't send messages here, authenticate to NickServ first | Patch Pilots: [08:33] 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] 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] Launchpad bug 1895632 in glibc (Ubuntu) "builds for libc 2.32 break all cross toolchains - missing libnss-nis--cross" [Undecided,Incomplete] [08:34] yes, glibc is waiting for cross toolchain and i'm checking the other failures [08:35] rbalint: did you consider a status update to devel or discourse? [08:35] a quick one [08:36] cpaelzer, thanks, i should have checked for that! now i added the update-excuse tag to have this bug showing up [08:36] it's a bit disappointing that the ffe was approved without having those problems sorted out [08:37] having the archive disrupted like that for a week getting closer from beta is an issue [08:40] vorlon, ^ btw since you approved the ffe [08:44] seb128, imagine doing that while other automatic syncs are on and there are other ongoing transitions... [08:45] 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] 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] rbalint: that probably should be fixed in glibc to not create those for the cross builds [08:45] being late is not an excuse to not prepare the packages that need to go with it [08:46] calm down [08:47] 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] 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] 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] 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] cpaelzer, we shouldn't have to had a week off for other teams because glibc lands though... [08:51] seb128, _this is the issue we are currently working on, eta is "soon"_ [08:52] seb128, let's have this conversation after glibc went through, i agree that there are improvement needed to make landing it smoother [08:53] doko, ok, looking at how this could be fixed in glibc [08:53] ack [09:03] 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:03] bug 1890435 in gcc-10 (Ubuntu) "gcc-10 breaks on armhf (flaky): internal compiler error: Segmentation fault" [Undecided,New] https://launchpad.net/bugs/1890435 [09:05] 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] oh! hi! [09:06] :-) FYI related to retries for 1895576 [09:06] cpaelzer: they're documented in the manpage [09:06] 14 erroneous package and at least one test skipped [09:06] cpaelzer: ye please, if you can reproduce it [09:06] well that is an easy answer, /me goes looking ... [09:06] doko: ok I'm giving it a try and will let you know later [09:06] thanks Laney, found it [09:07] didn't expect to find it to literal in the Web UI [09:07] usually those are mapped to friendly strings [09:07] but not for all exit codes [09:07] if you want to find a nice emoji to represent that I'd merge a MP :P [09:08] 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] https://git.launchpad.net/autopkgtest-cloud/tree/worker/worker#n496 [09:10] not sure if this indicates something to do with kernel packaging or if it's a "don't do that then" [09:14] cpaelzer: no point tagging me in questions about autopkgtest FWIW - in general I know ~nothing about it [09:18] hmm no, actually, it looks like it's something to do with qemu-system-s390x actually [09:18] actually actually ACTUALLY [09:25] maybe that will sort itself out when the arch:all build is done, but that looks depwait on the cross toolchain stuff === _hc[m] is now known as _hc [13:20] is there a simple way to get "apt build-dep qemu" to work only for the binary-arch part? [13:20] there are things in Build-Depends-Indep which are not available on armhf which is where I am [13:58] hi tjaalton, what do you think about https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1895645 ? It seems to make sense [13:58] Launchpad bug 1895645 in sssd (Ubuntu) "sssd-tools should depend or at least recommend sssd-dbus" [Undecided,New] [13:59] sssd-common suggests (and not recommends) sssd-tools, so no danger in bringing in all that dbus stack by default [13:59] ahasenack: yeah, and matches what the rpm does [14:00] adding recommends [14:00] so sssd-tools recommends sssd-dbus === broder_ is now known as broder === UnivrslSuprBox_ is now known as UnivrslSuprBox === karimsye_ is now known as karimsye === themill_ is now known as themill === sorah_ is now known as sorah === niub0 is now known as niub [14:00] yes === rsalveti_ is now known as rsalveti === beisner_ is now known as beisner [14:00] agreed === nicolasbock_ is now known as nicolasbock === coreycb_ is now known as coreycb === bcm_ is now known as bcm === philroche_ is now known as philroche === michagogo_ is now known as michagogo [14:01] 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.. === balkamos_ is now known as balkamos [14:01] fedora doesn't enable the systemd services by default upon install [14:01] huh [14:01] ok [14:01] it's up to the user to either do systemctl enable, or add the services= line to sssd.conf [14:02] if they use realmd, then having it add services= to sssd.conf just makes it work without conflicts [14:02] right [14:04] hum, wonder if we should do the same, not sure the current state is ideal === ogra_ is now known as Guest47593 [14:08] tjaalton: I tried some reboots, commands, etc, at most saw a small delay in the response [14:08] but of course it's not a good replication of real world scenarios [14:08] for how many cycles have we been using socket activation now? two, not counting groovy? [14:09] and I didn't get further details in the mailing list about what was breaking in some cases [14:09] other than "general practice" advice [14:10] 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] tjaalton: https://salsa.debian.org/sssd-team/sssd/-/merge_requests/9 ? === didrocks999 is now known as didrocks [14:37] ahasenack: merged [14:37] thx [14:39] looks like socket activation has been enabled roughly a year ago [14:40] cpaelzer: --arch-only [14:40] 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 === xnox1 is now known as xnox [14:58] thanks cjwatson [14:59] ahasenack: the handling of this changed a lot between dh 10/11/12 [14:59] I was facing several bugs due to it in libvirt, so it depends what level your package is on [14:59] (behaviour depends) [14:59] groovy, so 12 or 13 === ebarretto_ is now known as ebarretto [16:05] 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] bdmurray, i suspect the .service needs to be updated but i have to check that, there were several changes around .service handling [16:33] cpaelzer: How did you generate https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1892358/comments/13 ? [16:33] Launchpad bug 1892358 in util-linux (Ubuntu Focal) "autopkgtest success rate dropped inhibiting proposed migration" [Undecided,Confirmed] [17:29] 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] 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] 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] Heh and "increas my public shame counter" spelling increase wrong will definitely help with the shame counter [17:48] shame! shame! [17:56] join #ubuntu-devel [17:56] you're already here [17:56] hello [18:02] u guys do a great job with da old ubuntu linux! [18:06] thanks, that's nice to hear [18:06] thank bdmurray [18:25] 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] and the list it creates will also give an ETA when you can drop things [18:55] how does #ubuntu-devel work [18:57] abyssangel: you can see some of the past conversation on https://irclogs.ubuntu.com/latest/%23ubuntu-devel.html [19:02] thank u sarnold, bookmarked it [19:04] i want to join ubuntu development [19:04] welcome :) what are you looking to do? [19:08] :) i am a c and c++ programmer, so maybe testing, debugging and contributing code [19:20] i am a c and c++ programmer, i would like to do testing, debugging and maybe contribute code [19:24] abyssangel: https://wiki.ubuntu.com/ContributeToUbuntu#Maintaining_Ubuntu [19:24] abyssangel: welcome. read our documentation about how to contribute first, this will guide you through! [19:26] thank you rafaeldtinoco, i love to be part of the ubuntu family === Guest25928 is now known as bashfulrobot [20:23] how can i dev on ubuntu from source in safe way [20:26] 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] ;) [21:15] seb128: the impact on cross-toolchain-base was non-obvious at the time of ffe approval === mwhudson_ is now known as mwhudso === mwhudso is now known as mwhudson === ahayzen_ is now known as ahayzen