[06:32] <alkisg> Hi all. Could someone be so kind and sync ltsp from unstable to focal? I uploaded a one-bug/security fix release to unstable, but I don't yet have rights to upload it to focal...
[06:35] <Unit193> Ah, aka: https://github.com/ltsp/ltsp/commit/ecca725849f4653db06d625b4d9d903b7afb943b
[06:35] <alkisg> Righto :)
[06:36] <Unit193> alkisg is your LP username?
[06:36] <alkisg> Yes
[06:36] <Unit193> Done.
[06:36] <alkisg> Thank you Unit193, have a great day!
[06:36] <Unit193> You as well.
[08:34] <tarzeau> what are the chances to get in hpx if it gets an ACCEPT from ftp-master into debian? https://repology.org/project/hpx/versions (it's important for HPC users)
[10:04] <doko> tarzeau: file a FFe
[10:27] <ginggs> FFe not needed for new packages https://wiki.ubuntu.com/FreezeExceptionProcess#FeatureFreeze_for_new_packages
[10:27] <ginggs> tarzeau: i think you'll just need to file a sync request (or run requestsync)
[10:29] <tarzeau> great infos, thanks.
[11:15] <rbalint> doko, i've filed LP: #186854 , could you please take a look? i can add more of the template if needed
[11:16] <rbalint> LP: #1868542
[14:09] <ddstreet> Laney unfortunately, i am able to reproduce the systemd failure using the main autopkgtest server, but when i test with my own autopkgtest setup, the tests pass :(
[14:11] <ddstreet> rbalint do you have any idea what might be causing the systemd-upstream autopkgtest failures?  they all seem to hang right after/during installing the newly-built systemd packages
[14:15] <rbalint> ddstreet, no, sorry, seems like an infra issue :-(
[14:17] <ddstreet> yeah, unfortunately it does, it may need Laney or someone with access to the autopkgtest instances to debug :(
[14:18] <ddstreet> for reference, here is the log from a run using my upstream ppa build on the main autopkgtest servers, that fails: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic-ddstreet-systemd-upstream/bionic/amd64/s/systemd/20200322_213630_1f1b6@/log.gz
[14:19] <ddstreet> and a log with the same upstream ppa build, but on my own autopkgtest deployment, that passes: https://swift-proxy.bos01.canonistack.canonical.com:8080/v1/AUTH_c14f9cd6e857495990d3438d775fa4a9/autopkgtest-bionic-ddstreet-systemd-upstream/bionic/amd64/s/systemd/20200322_232851_fdf06@/log.gz
[14:25] <gpiccoli> o/ bdmurray - I received an email about increase in libvirt crash reports after a release with a patch from me reached -updates, hence stopping phasing
[14:26] <gpiccoli> It points a link with a chart, etc..but I cannot see any of those crash. I'd like to have access to data to try correlate those crashes with my (small and non-intrusive) patch, or discard the correlation
[14:26] <gpiccoli> This is the link: https://errors.ubuntu.com/?release=Ubuntu%2018.04&package=libvirt&version=4.0.0-1ubuntu8.15&period=week
[14:26] <ahasenack> cpaelzer: some assistance please? I'm failing to understand why dpkg-gensymbols wants me to add the 0ubuntu1 suffix to the symbols file: https://paste.ubuntu.com/p/GRrg7jvdcP/
[14:26] <gpiccoli> I cannot open the crash reports though, it says I don't have permission. If you or anybody here can help me on this, I appreciate
[14:26] <ahasenack> cpaelzer: and lintian says the binary deb has them, and complains about that:
[14:26] <ahasenack> $ lintian -I --pedantic
[14:26] <ahasenack> E: libcbor0.6: symbols-file-contains-current-version-with-debian-revision on symbol _cbor_alloc_multiple@Base and 230 others
[14:27] <ahasenack> cpaelzer: d/libcbor0.6.symbols: https://paste.ubuntu.com/p/kvgprG3qQj/
[14:27] <gpiccoli> [please ping my nick whenever talking back to me, I'll detach the channel! =) ]
[14:27] <ahasenack> maybe it's related to old debhelper? The package is using 9, I intend to update it
[14:28] <ddstreet> gpiccoli i have access to the error reports, i'll take a look
[14:29] <Laney> ddstreet: feel free to file an RT to get access temporarily in order to let you look at it interactively there
[14:30] <gpiccoli> Thanks a lot ddstreet =)
[14:30] <Laney> 'infra issue' could mean a lot of things couldn't it
[14:32] <gpiccoli> I'm not sure if cpaelzer highlights on libvirt, but I guess worth highlight him for awareness
[14:32] <cpaelzer> ahasenack: reading ..
[14:32] <cpaelzer> gpiccoli: I'm highlighting on it :-)
[14:33] <cpaelzer> ahasenack: you are right not to add the ubuntu1 suffix
[14:34] <cpaelzer> ahasenack: your file has "libcbor.so.0.6.0 libcbor0.6 #MINVER#"
[14:34] <ahasenack> oh
[14:34] <gpiccoli> hehe cool cpaelzer =)
[14:34] <cpaelzer> but needs "libcbor.so.0.6 libcbor0.6 #MINVER#"
[14:34] <ahasenack> it's soname, and package
[14:34] <cpaelzer> ahasenack: the rest you can keep as-is
[14:34] <ahasenack> got it
[14:34] <ahasenack> thanks
[14:34] <cpaelzer> ahasenack: did this have a symbols file before?
[14:35] <ahasenack> yes
[14:35] <cpaelzer> ahasenack: if yes could you keep all symbols that existed before at the version they were before?
[14:35] <ahasenack> they were kept
[14:35] <ahasenack> oh
[14:35] <ahasenack> at 0.5.0 you mean
[14:35] <cpaelzer> yes
[14:35] <ahasenack> ok
[14:35] <cpaelzer> that will give you a list of only a few that are added on 0.6.0
[14:35] <cpaelzer> that helps dh_shlibs and such tools to make better dependencies
[14:36] <cpaelzer> e.g. >= 0.5.0 if it only uses symbols out of that
[14:36] <cpaelzer> now with you gpiccoli
[14:36] <cpaelzer> gpiccoli: you have to wait for the data to load
[14:36] <cpaelzer> (usually)
[14:37] <ddstreet> gpiccoli in that error report i'm only seeing a small number of captured errors, and none of them are new; they've all been seen on previous versions of libvirt
[14:37] <gpiccoli> exactly ddstreet, that was my impression too
[14:37] <gpiccoli> Not related with the new versions
[14:38] <gpiccoli> cpaelzer, it seems there are files I could get...but I don't have permissions
[14:38] <ddstreet> i'll let bdmurray decide if they can be ignored when he gets in, but it seems like they probably can
[14:38] <gpiccoli> nifty ddstreet, I hope so
[14:38] <cpaelzer> this happens quite often on packages that are installed a lot and have services
[14:38] <ddstreet> yeah, do ask him if you can have access to the error tracker, it's useful
[14:38] <cpaelzer> service gets restarted and due to local config breakage an old error is crashing it (again)
[14:39] <gpiccoli> oh, so it explains what happens cpaelzer, ty!
[14:39] <cpaelzer> and I agree to ddstreet none of these look "new" like "added with your patch"
[14:40] <gpiccoli> outstanding, thank you both for that! let's then discuss with bdmurray when he gets in =)
[14:40] <cpaelzer> gpiccoli: I usually reply to the mail send it to bdmurray and explain why it can be ignored
[14:41] <cpaelzer> with some more words than what we had here, but still similar in content
[14:41] <cpaelzer> e.g. comparing the signatures seen with what the patch changed
[14:41] <gpiccoli> cpaelzer, but I didn't feel comfortable in ignoring that without looking those reports
[14:41] <cpaelzer> yep gpiccoli and reaching out was the right choice
[14:41] <cpaelzer> thank you
[14:42] <gpiccoli> thank you for the information Christian!
[14:50] <ahasenack> cpaelzer: did you ping someone about the builders being sluggish?
[14:50] <ahasenack> you mentioned dep8 before I think, but I'm noticing something wrong with the builders too
[14:52] <ahasenack> I just pinged ops
[15:16] <cpaelzer> ahasenack: I had no issue with builders yet
[15:16] <cpaelzer> ahasenack: just a long test queue
[15:16] <cpaelzer> and it wasn't slow, just a long queue
[15:16] <cpaelzer> something big must have appeared in focal
[17:53] <ahasenack> I'm always confused by this statement in the debian policy: "The package build should be as verbose as reasonably possible,"
[17:53] <ahasenack> does that mean d/rules should always have DH_VERBOSE=1?
[17:54] <ahasenack> rbasak: any opinion on that? ^
[18:03] <cjwatson> I don't think that's the usual interpretation
[18:03] <cjwatson> It generally means showing compiler commands and such
[18:04] <cjwatson> It's not necessarily an unreasonable interpretation, but it's not the usual one
[18:04] <ahasenack> ok, thanks
[19:00] <rbasak> ahasenack: if someone said to me that policy means that DH_VERBOSE=1 be set in all debian/rules files, I'd argue that debhelper should have its default changed.
[19:00] <rbasak> (if that were true)
[19:00] <rbasak> So to me it doesn't follow that we should set that in the usual case.
[19:00] <rbasak> !dmb-ping
[21:44] <GunnarHj> Hi bdmurray, There are a few verified SRU proposals at bug #1844853. There are also some minor autopkgtest failures, but our suggestion is to disregard those. My question is if the autopkgtest failures cause those items to not show up as 'ready to be considered' to the SRU team.
[21:46] <bdmurray> GunnarHj: On the pending SRU report you can see the regressions are called out there, so yes we consider them not ready. https://people.canonical.com/~ubuntu-archive/pending-sru.html
[21:48] <bdmurray> Any suggestion about disregarding tests should be made in one of the SRU bugs
[22:33] <GunnarHj> bdmurray: But we have already done that. In comment #30 and #31 at bug #1844853 (where the verification was documented) I referred to L_aney's suggestions to disregard them. So now I'm trying to call the SRU team's attention to it. :)
[22:43] <LocutusOfBorg> GunnarHj, did you ask me about unicode-data?
[22:44] <LocutusOfBorg> I remember somebody asking, but forgot who
[22:44] <LocutusOfBorg> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3989/+packages
[22:44] <LocutusOfBorg> in case, please upload there ^^
[22:44] <GunnarHj> LocutusOfBorg: Nope. I just made a note on the bug that I think it's a good idea.
[22:45] <bdmurray> GunnarHj: got it
[22:46] <GunnarHj> bdmurray: Do you possibly have time to look at it?
[22:49] <bdmurray> GunnarHj: everything but Eoan based on L_aney's comment right?
[22:51] <GunnarHj> bdmurray: eoan also, see https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1850932/comments/12 (but let's drop disco...)
[22:51] <LocutusOfBorg> mmm strange, I can't find anymore the log here
[22:52] <LocutusOfBorg> GunnarHj, I meant, ibus merge, that was depending on unicode-data
[22:53] <bdmurray> GunnarHj: Yes, I can have a look shortly
[22:54] <GunnarHj> LocutusOfBorg: That's correct. I have a proposed upload at https://launchpad.net/~gunnarhj/+archive/ubuntu/ibus, and if you can take that into account it would be great.
[22:55] <GunnarHj> bdmurray: Great, TIA!
[22:57] <LocutusOfBorg> uploaded thanks
[22:57] <LocutusOfBorg> will go in as soon and if release team acks the unicode transition
[22:59] <GunnarHj> LocutusOfBorg: Nice!