=== tacocat is now known as e[_]
=== e[_] is now known as c[_]
=== c[_] is now known as e[_]
=== e[_] is now known as tacocat
[07:13] <seb128> hum, some autopkgtest seem to be failing due to 'rules extract failed with exit code 1' errors, does anyone know what's that's about? e.g https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/amd64/s/systemd/20191008_021409_ed1a2@/log.gz
[07:13] <seb128> Laney, juliank, vorlon, ^ do you know?
[07:13] <seb128> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/amd64/f/flatpak-builder/20191007_190748_9c67a@/log.gz is another one with another package
[07:14] <juliank> seb128: looking
[07:14] <seb128> hey juliank, thx
[07:17] <juliank> seb128: I can't find that phrase in the code, ugh
[07:17] <juliank> so I'm confused :D
[07:18] <juliank> ah found i
[07:18] <juliank> it's rules %s failed
[07:18] <seb128> what is a rule in this context?
[07:18] <seb128> it seems to just want to unpack a source from the archive
[07:20] <juliank> seb128: it's a complex shell/awk script combo that's embedded int he autopkgtest code
[07:21] <seb128> did it change recently?
[07:22] <juliank> seb128: i see a change from ddstreet on sep 26 for https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/1845157
[07:22] <ubottu> Launchpad bug 1845157 in autopkgtest (Ubuntu) "runner/autopkgtest fails to setup env with binary packages moved to another packge, and different source/binary versions" [Undecided,Fix committed]
[07:23] <juliank> seb128: this commit https://salsa.debian.org/ci-team/autopkgtest/commit/020ec6285a836d20ab799742649712f7224d61c8
[07:24] <seb128> pitti, ^ is that a regression from that commit
[07:25] <juliank> I really should make it print the output of the failing script
[07:29] <pitti> seb128: bonjour, ça va ?
[07:29] <juliank> seb128: acked in debugging, rerunning
[07:29] <seb128> pitti, salut, très bien et toi ?
[07:29] <pitti> seb128: Dan indeed found a regression, he sent a follow-up to fix it
[07:29] <seb128> juliank, thx
[07:29] <seb128> pitti, ah, would it match those  'rules extract failed with exit code 1' errors I mentioned before?
[07:30] <pitti> seb128: je vais bien aussi ! on a passé un grand week-end dans les Alps
[07:30] <seb128> ah, chouette :)
[07:30] <pitti> seb128: hmm, I don't think so -- he sent https://salsa.debian.org/ci-team/autopkgtest/merge_requests/64
[07:30] <pitti> which would be about grabbing a binary package from the wrong source
[07:31] <seb128> ah
[07:31] <seb128> pitti, the error I saw are like https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/amd64/s/systemd/20191008_021409_ed1a2@/log.gz
[07:31] <juliank> ok https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/ppc64el/s/systemd/20191008_073006_b5371@/log.gz
[07:31] <seb128> 'autopkgtest [02:13:58]: @@@@@@@@@@@@@@@@@@@@ apt-source systemd
[07:31] <seb128> blame: systemd
[07:31] <seb128> badpkg: rules extract failed with exit code 1'
[07:31] <seb128> juliank, ah
[07:31] <seb128> pkgs=
[07:31] <seb128> not good :p
[07:32] <juliank> So the awk returns no result
[07:33] <pitti> I don't think that systemd has that complex "same binary from different sources on different architectures" structure
[07:33] <pitti> I merged Dan's fix in the meantime
[07:34] <pitti> I suggest running the command locally with -d, to see what it's doing
[07:34] <pitti> the log has the exact command line for that reason
[07:35] <seb128> pitti, julian just did that in the url he shared
[07:36] <seb128> seems like he's debgging now so let's see if he figures out why the awk call is return an empty set
[07:36] <juliank> I cherry picked that commit, and will retry now
[07:39] <juliank> the binaries are all linux-any so it makes sense they fail
[07:39] <juliank> sort of
[07:40] <juliank> also that's what was discussed in #ubuntu-release last night
[07:48] <seb128> juliank, let me know if/when you test if that fixes it so I can retry other things :)
[07:49] <juliank> seb128: well, systemd on ppc64el is still running, so it seems fine
[07:49] <seb128> juliank, it's taking longer than the previous try for sure, good sign then :)
[08:03] <juliank> seb128, Laney: I rebased our branch in https://code.launchpad.net/~juliank/autopkgtest/+git/development/+merge/373801 and pushed that to the (cloud) worker, please reset branch to it
[08:03] <juliank> seb128: FWIW, I need to apply this on armhf lxd builder too
[08:03] <Laney> yeah they were fixing that when I left off last night
[08:03] <juliank> and done
[08:03] <Laney> good that it got done :>
[08:04] <juliank> I forwarded both workers to that branch
[08:05] <Laney> the branch format that LP generates
[08:06] <Laney> with a : separating the repository and branch name
[08:06] <Laney> is it possible to paste that into git somehow?
[08:06] <juliank> no
[08:07] <juliank> you gotta replace the : with a space and then pass it to git fetch
[08:07] <juliank> or pull
[08:07] <Laney> right
[08:07] <Laney> that's what I do
[08:07] <Laney> I was just wondering if there was some trick I didn't know, which is why LP renders it in that way
[08:17] <cjwatson> No, I picked that format as a concise way to represent the repository/branch combination that also made sense when rendering things like lists of merge proposals
[08:18] <cjwatson> IIRC GitHub uses a similar format
[08:18] <cjwatson> git has no native equivalent that doesn't involve awkward spaces so it was a compromise
[08:27]  * Laney nods
[08:48] <jamespage> doko: looking that that pbr test regression for python-defaults - python-stestr py2 support was dropped via autosync from debian afaict
[08:48] <jamespage> which is blocking the autopkgtest and rebuilding the package
[09:04] <jamespage> choices are - drop py2 support from pbr (lots of reverse-depends still, near release so discounted), drop py2 testing from python-pbr (minimal change, unblocks proposed)
[09:14] <doko> jamespage: I'd say reduce the testing ...
[09:24] <jamespage> doko: agreed - its the minimal impact change for this point in the cycle - just uploaded
[09:25] <jamespage> I'm not quite sure how python-stestr got into the release pocket bearing in mind there where still reverse-build-depends
[09:25] <jamespage> but hey ho
=== cpaelzer__ is now known as cpaelzer
[09:53] <cjwatson> I don't think proposed-migration considers build-depends
[10:22] <doko> and autopkg test dependencies either
[10:23] <mwhudson> i don't think britney looks at Sources at all does it?
[10:24] <mwhudson> oh no, it does
[10:24] <mwhudson> not sure what for, mind
[10:55] <RikMills> jibel: LP: #1847228
[10:55] <ubottu> Launchpad bug 1847228 in ubiquity (Ubuntu) "Installer crashes at partitioning stage" [Undecided,New] https://launchpad.net/bugs/1847228
[10:56] <RikMills> looks like impact of the xfs changes on KDE front end
[10:56] <RikMills> s/xfs/zfs
[10:58] <jamespage> doko: we're seeing https://bugs.python.org/issue38368 from python-pysnmp4 under the 3.7 rc in eoan
[10:59] <jamespage> sahid: I've updated https://bugs.launchpad.net/ubuntu/+source/python3.7/+bug/1847036 with those details
[10:59] <ubottu> Launchpad bug 1847036 in python3.7 (Ubuntu) "changeme.py crashed with SIGSEGV" [Undecided,New]
[10:59] <doko> ok
[11:00] <jamespage> doko: https://bugs.launchpad.net/ubuntu/+source/python3.7/+bug/1847036 covers it
[11:00] <ubottu> Launchpad bug 1847036 in python3.7 (Ubuntu) "changeme.py crashed with SIGSEGV" [Undecided,New]
[11:01] <doko> jamespage: yes, I also something similar in python-ipaddress
[11:03] <RikMills> jibel: in kubuntu, the minimal install option has also vanished
[11:06] <Laney> known
[11:07] <Laney> we've been discussing it in #ubuntu-desktop
[11:10] <RikMills> Ah, I missed that. Sorry. There has been a lot of chat in there this morning
[11:14] <Laney> stupid installers /o\
[11:25] <mwhudson> maybe we can just ship ssds with ubuntu on to everyone
[11:26] <Laney> mail -s "great idea to reduce installer development costs" mark@ubuntu.com
=== ricab is now known as ricab|lunch
[13:16] <rbasak> xnox: another claimed fallout from the OpenSSL Bionic update: bug 1832998. Please could you take a look?
[13:16] <ubottu> bug 1832998 in pure-ftpd (Ubuntu) "Pure-FTPd Breaks with OpenSSL v1.1.1" [Undecided,Confirmed] https://launchpad.net/bugs/1832998
[13:18] <xnox> rbasak:  sure
[13:19] <rbasak> Ta!
[13:30] <xnox> rbasak:  upstream refactored and fixed everything in .48, fedora disabled tlsv1.3 at first, and then backported all the fixes.
[13:30] <xnox> rbasak:  not sure if those backports apply cleanly to 46
[13:31] <xnox> rbasak:  i am thinking to just disable tlsv1.3 with a smalish patch
[13:31] <rbasak> xnox: sounds reasonable
[13:31] <rbasak> Especially to fix the regression - if someone wants to work harder to enable it later, then we could do that as a separate future upload
[13:32] <rbasak> mdeslaur: ^ any opinion please?
[13:39] <mdeslaur> disabling tlsv1.3 sounds reasonable to me too
[13:39] <rbasak> Thanks!
[14:10] <paride> cpaelzer, what do you think of qemu-system-X recommending (=> installing by default) qemu-system-gui, which in turn has a bunch of GUI related dependencies (gtk, fonts, x11 stuff...)?
=== ricab|lunch is now known as ricab
[14:19] <cpaelzer> paride: I think that is how we recently do it
[14:19] <cpaelzer> paride: there was a bug, it sounds familiar
[14:20] <paride> cpaelzer, found it https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1789670
[14:21] <ubottu> Launchpad bug 1789670 in qemu (Ubuntu) "qemu-system-* Recommends qemu-system-gui" [Wishlist,Won't fix]
[14:21] <cpaelzer> yep, the default is make it work nice
[14:21] <cpaelzer> people interested in minimizing can remove it (as it is a recommends)
[14:21] <cpaelzer> wow was that discussion that long ago ...
[14:22] <paride> almost 1 year :)
[16:07] <rcj> Can I get a sponsor for https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1847300 as I can't do the merges/uploads?
[16:07] <ubottu> Launchpad bug 1847300 in livecd-rootfs (Ubuntu) "[backport] magic-proxy: dump proxy log to stdout on failure" [Undecided,New]
[16:08] <rcj> Can I get a sponsor for https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1847300 as I can't do the merges/uploads?
[16:08] <rcj> whoops (sorry on the double post)
[16:16] <rbasak> thedac: o/
[16:16] <rbasak> thedac: any chance you can retest from my PPA please?
[16:16] <rbasak> thedac: this one is very close to my intended upload to the archive today/tomorrow for Eoan.
[16:17] <thedac> rbasak: Sure, I'll kick off a test right now.
[16:20] <rbasak> Thanks!
[16:24] <Odd_Bloke> Can packages in main Recommend packages in universe, or does that prompt promotion of the Recommend'ed package?
[16:27] <Laney> The second one :(
[16:30] <Odd_Bloke> Thanks!
[16:50] <infinity> Odd_Bloke: Recommends prompts promotion because we install recommends by default, and we don't want the behaviour to change depending on if you did or didn't enable universe.
[16:51] <infinity> Odd_Bloke: Suggests doesn't prompt promotion because it's not installed by default.
[16:51] <Odd_Bloke> Yep, makes sense!
[16:51] <Odd_Bloke> Thanks! :)
[16:53] <infinity> rcj: Why have you not at the very least applied for PPU for livecd-rootfs by now? (or, roll up your sleeves, get a little dirtier in the archive in general, and go for core-dev)
[16:53] <infinity> rcj: Which is to say, sure I can look at those MPs and sponsoring, but also, SLAAAAACKER.
[16:59] <thedac> rbasak: 8.0.17-0ubuntu2~dev2 for mysql-server-8.0 and mysql-router looks good to me. My tests pass.
[17:14] <rcj> infinity: thank you on both counts
[17:15] <infinity> rcj: I've never been thanked for calling someone a slacker before.  This is new territory.
[17:23] <rcj> I keep telling myself that I've been too busy but it's annoying me and I just need to make time.
[17:24] <rcj> And if I had PPU for livecd-rootfs I wouldn't be wasting you on sponsorship when I need an SRU for this infinity ;)
[18:51] <vorlon> infinity, kees, stgraber, mdeslaur: TB meeting in 10?  (we have agenda items)
[18:51] <mdeslaur> ack!
[18:56] <kyrofa> Hey juliank, we chatted a few weeks back about https://bugs.launchpad.net/ubuntu/+source/urdfdom-headers/+bug/1817595 . It should be in a better state now, and Jose is a DM and is happy to help with any autopkgtest regressions that may pop up with it
[18:56] <ubottu> Launchpad bug 1817595 in urdfdom-headers (Ubuntu Bionic) "[SRU] urdfdom-headers and urdfdom should not use locale dependent parsing for floating point numbers" [Undecided,Confirmed]
[19:26] <juliank> kyrofa: sponsored
[19:33] <kyrofa> Thank you juliank :)
[19:40] <Odd_Bloke> rcj: You still need the SRU team and AAs even with PPU, so it's not a surefire way of avoiding infinity. ;)
[19:41] <rcj> Odd_Bloke: I don't want to avoid infinity, I just don't want to waste him unnecessarily.  Also, I'd like to scratch my own itches.
[19:51] <seb128> cking, hey, would be nice if you reported your gnome-calendar/disk issue upstream on https://gitlab.gnome.org/GNOME/gnome-calendar/issues
[20:26] <mwhudson> can i get a core-dev review on https://code.launchpad.net/~mwhudson/livecd-rootfs/+git/livecd-rootfs/+merge/373789
[20:36] <juliank> mwhudson: lgtm
[21:09] <rbasak> xnox: here's another one incoming via ddstreet: bug 1799345
[21:09] <ubottu> bug 1799345 in sylpheed (Ubuntu Eoan) "Sypheed not (or no longer) using SNI for SSL connections" [Medium,In progress] https://launchpad.net/bugs/1799345
[21:10] <rbasak> Do we have a tag for these? I'd like to create one if not. "bionic-openssl-1.1" OK?
[21:41] <xnox> rbasak:  "IMAP connection to imap.gmail.com over SSL returns self-signed certificate." ergh whaaaaaat?!
[21:42] <xnox> ha
[21:42] <xnox> that's neat
[21:42] <xnox> "connecting to imap.gmail.com over SSL, I get a warning embedded in the SSL certificate: "Subject: /OU=No SNI provided; please fix your client./CN=invalid2.invalid ""
[21:44] <xnox> rbasak:  anyway, providing SNI is the right thing to do, and that's in unapproved queue already?!
[21:54] <Unit193> Yeah, I've seen that before.
[22:04] <sarnold> cute :)
[22:15] <Unit193> https://repo.or.cz/alpine.git/commit/08fcd1b86979b422eb586e56459d6fe15333e500 would likely fix it, but that doesn't directly apply I don't think.