[08:01] <dupondje> Somebody can have a look to https://launchpad.net/ubuntu/+source/thunderbird ? Hanging in proposed for some time now
[12:04] <zyga> waveform: hell
[12:04] <zyga> hello :)
[12:05] <waveform> zyga, hi!
[12:05] <zyga> waveform: I'd like to ask you about bug https://bugs.launchpad.net/snapd/+bug/1574103
[12:05] <zyga> I spoke to some developers working on the related part of snapd and I the issue can finally be fixed for everyone in the field
[12:05] <zyga> but it requires an explicit markup in the gadget snap
[12:06] <zyga> I left two comments in the bug, please have a look
[12:06] <waveform> zyga, will do
[12:06] <zyga> waveform: thank you, let me know if you have any questions about this
[12:06] <zyga> waveform: I think it could be one or two liner to fix
[12:11] <waveform> zyga, yup - that's simple enough. I did wonder why those two were configured that way, but just assumed "that's how someone wanted it"
[12:11] <zyga> waveform: you mean the LEDs?
[12:13] <zyga> waveform: I don't know if this is true but I suspect it would also be the first time this functionality was used for public devices
[12:13] <waveform> zyga, yup, the LEDs
[12:14] <waveform> zyga, interesting - pioneering even (sorry, bad pun :)
[12:14] <zyga> hahaha
[12:14] <zyga> it would be a pity if it broke ;)
[12:15] <zyga> waveform: ping me back once you have something for testing, I think it would be a cool story to share
[12:15] <waveform> heh, with all the fun we're having with the classic image at the moment, that doesn't bear thinking about!
[12:15] <waveform> zyga, will do
[12:16] <zyga> popey: ^ FYI (pi gadget updates to fix backwards leds)
[12:41] <cpaelzer> if a package wants to ship binary+manpage (ok) and a symlink to the binray for ease of use to be also available under antother name lintian rightfully complains "W: mdevctl: binary-without-manpage"
[12:41] <cpaelzer> what is the common pattern to resove this, also ln -s the manpage OR copy the manpage OR some flagging/metadata for man to recognize the one file being responsible for both binary paths
[13:10] <cjwatson> ln -s the man page
[13:10] <cjwatson> cpaelzer: ^-
[13:11] <cjwatson> while it's possible to put metadata in the man page itself, it's better to have it in the filesystem
[13:11] <cjwatson> you should mention both possible names in the NAME section of the man page, ideally.  See lexgrog(1) for the correct formatting
[13:24] <cpaelzer> thanks cjwatson, will do so
[13:53] <cpaelzer> cjwatson: worked and even followed it up to name the symlink .gz when it packed the actual manpage - but it made a link with a leading / which is broken
[13:53] <cpaelzer> I might need to experiment with ln options on that
[13:53] <cpaelzer> tried "-s -r ./orig ..." and ""-s -r orig ...""
[13:53] <cpaelzer> both end up as "-> /orig" which isn#t what I'd need
[13:54] <cpaelzer> dropping -r for a test of that ...
[13:57] <cpaelzer> got it - "ln -s orig full-path-to-new-in-builddir" did it
[13:57] <cjwatson> Or you could just use dh_link which should DTRT
[13:58] <cpaelzer> I'd want to do it in the upstream makefile to upstream it
[13:58] <cpaelzer> which is what I did now
[14:19] <xnox> doko:  https://bileto.ubuntu.com/excuses/3845/focal.html is the bileto results for python3-defaults pointing at v3.8
[14:21] <xnox> so 198+ packages regressed in release pocket, at least. Tests are still running
[14:31] <doko> xnox: "regressed in release pocket" is misleading. we already have all these in the release pocket, where didn't try building/testing with 3.8
[14:42] <xnox> doko:  it's not misleading. it's the packages that would regress their autopkgtests if python3-defaults pointing at v3.8 migrates =) which obviously it will be blocked from doing so.
[14:43] <xnox> doko:  i don't know if your concern is around the language i used, but this is approximately how the things will look like if we sync python3-defaults from experimental to focal-proposed
[14:43] <doko> xnox: well, yes, but some of those are already regressed without the upcoming upload
[14:43] <xnox> ah
[14:44] <doko> but anyway, we have to fix all these
[14:44] <xnox> doko:  should i make a bileto PPA with a no-change rebuild of python3-defaults, python3.8, python3.7 to trigger things as is?
[14:44] <xnox> because fixing those things is more urgent, as they would start creeping up in the dep chains?
[14:44] <doko> no, that doesn't have any value now, I think, unless somebody wants to work on these now
[15:08] <seb128> cpaelzer, rbasak, do you know if anyone is looking at the postgresql-12 autopkgtest failures on focal?
[15:19] <cpaelzer> seb128: we have been looking and resolving them down from ~40 -> 23 (custom test triggers) and then with more effort (fixes) down to 11
[15:19] <cpaelzer> seb128: the remaining 11 are all cases were the upstreams have to wake up and actually push e.g. a new version
[15:19] <cpaelzer> to not do all of that on our shoulders we ahve decided about a week ago to wait a bit (allowing upstreams the time to release that)
[15:20] <cpaelzer> and then will pick it up again
[15:20] <cpaelzer> seb128: it is postponed intentionally, but not un-noticed :-)
[15:20] <cpaelzer> does that answer the question enough seb128?
[15:21] <seb128> cpaelzer, sort of, my next question is what are we supposed to do for items blocked on those? just skip and let migrate? (e.g libxml2)
[15:24] <seb128> cpaelzer, thx for the reply in any case!
[17:10] <cpaelzer> seb128: my plan was to get back after DPDK (~1-2 weeks from now) and then check upstreams
[17:11] <cpaelzer> I wsa in touch with myon (Debian postgres maintainer) and synced on these open cases
[17:11] <cpaelzer> seb128: if things are blocked we might let them pass
[17:11] <cpaelzer> eventually there are two cases a) real issues and b) obvious non-related issues like if libxml fails due to the wrong DB being installed
[17:11] <cpaelzer> if it is easy to decide I'd let them pass
[17:12] <cpaelzer> but otherwsise if things can wait the 2 weeks I'd wait
[17:12] <cpaelzer> then once we know more we can do much better decisions
[21:12] <mwhudson> what am i doing wrong here?
[21:12] <mwhudson> (xenial-1.38)mwhudson@anduril:~/src/pkg/rustc$ ~/src/ubuntu/ubuntu-archive-tools/trunk/copy-package -s xenial --from ppa:ubuntu-toolchain-r/ubuntu/ppa --to ppa:mwhudson/ubuntu/rust-stuff -b gcc-7
[21:12] <mwhudson> Copy candidates:
[21:12] <mwhudson> Could not find source 'gcc-7/None' in xenial
[21:13] <mwhudson> oh wrong ppa
[21:30] <infinity> mwhudson: Might be the wrong PPA.  Hope that helps.
[21:31] <mwhudson> infinity: you hero
[21:31] <infinity> I live to give.