[02:45] <mwhudson> ok pop quiz time what is going on here https://launchpadlibrarian.net/448056138/buildlog_ubuntu-focal-amd64.python-gevent_1.3.7-1build2_BUILDING.txt.gz
[02:53] <Unit193> Looks like a build failure.
[02:55] <mwhudson> +1 insightful
[03:07] <Unit193> That looks fun, same file is in python3-greenlet-dbg and python3-greenlet.
[03:08] <Unit193> Specifically if you look at https://launchpadlibrarian.net/447991806/python-greenlet_0.4.15-2_0.4.15-2ubuntu1.diff.gz
[03:08] <Unit193> See why that'd be bad? :P
[03:12] <mwhudson> oh yay
[03:12] <mwhudson> thanks for chasing :)
[03:16] <Unit193> Sure.  I guess I can't just make a sarcastic comment. :3
[07:23] <mitya57> sil2100: hi, can you add focal support to bileto please?
[07:52] <sil2100> mitya57: ah! Yes, let me bump the cache
[07:55] <sil2100> mitya57: should be enabled in up to 30 minutes
[08:47] <mitya57> sil2100: it works now, thanks a lot!
[08:48] <LocutusOfBorg> Eickmeyer, hello, how can somebody sponsor a fix for LP: #1849168 if 1) there is no indication about which series are affected 2) there is no patch to sponsor ?
[08:49] <sil2100> yw!
[09:01] <LocutusOfBorg> mwhudson, Unit193 do I have greenlet greenlight to upload a fix for it?
[09:01] <LocutusOfBorg> doko, ^^
[09:02] <Unit193> I just pointed out what went wrong.
[09:03] <LocutusOfBorg> yes sure bug greenhighlighting you doesn't hurt!
[09:04] <mwhudson> LocutusOfBorg: i'm all for fixing it, i guess doko can always reject it from the queue if he doesn't like it :)
[09:04] <LocutusOfBorg> mwhudson, I think I already crafted a fix
[09:20] <LocutusOfBorg> mwhudson, https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+sourcepub/10667371/+listing-archive-extra
[09:20] <LocutusOfBorg> if you agree
[09:20] <mwhudson> LocutusOfBorg: lgtm
[09:21] <LocutusOfBorg> still have to debdiff debs
[09:24] <LocutusOfBorg> feel free to upload if you like it, or I can do it and credit you :)
[09:24] <LocutusOfBorg> I'm also going to update the debian bug report
[09:42] <LocutusOfBorg> mwhudson, ping :) I have to replace keyboard and reboot laptop... please let me know if you want me to do it or not
[09:44] <mwhudson> LocutusOfBorg: eh just update it, getting late here
[09:44] <mwhudson> *upload
[09:44] <LocutusOfBorg> thanks :D
[09:44] <mwhudson> LocutusOfBorg: sorry if i was being ambiguous earlier
[09:45] <LocutusOfBorg> I "just" woke up :D
[10:35] <cgm____> Hi all, is there somewhere I can find the commands used to build the official Ubuntu netboot ISOs? Specifically the xorriso arguments
[11:18] <rbasak> rafaeldtinoco: o/
[11:18] <rbasak> rafaeldtinoco: Josh suggested I ask you to arrange a seed change so you can get familiar
[11:18] <rafaeldtinoco> rbasak: morning o/
[11:18] <rafaeldtinoco> rbasak: awesome, I read the docs already
[11:18] <rbasak> Great! I want to get mysql-router seeded in Focal
[11:18] <rafaeldtinoco> alright, let me go through it
[11:18] <rafaeldtinoco> and ask you whenever I have questions
[11:19] <rbasak> Actually, I should tell you what I really need, rather than presuppose a solution
[11:19] <rbasak> What I need is mysql-router in main in Focal :)
[11:20] <rafaeldtinoco> yep I thought it was that #)
[11:20] <rafaeldtinoco> rbasak: do u have a MIR already ?
[11:21] <rbasak> src:mysql-8.0 is in main already, and mysql-router is built from that
[11:21] <rbasak> That's the closest we have to an approved MIR
[11:22] <rafaeldtinoco> alright
[11:26] <rbasak> cpaelzer: thank you for the uvtool reviews. I'm working on your emulation branch next.
[11:26] <rbasak> I have a rebased/squashed version locally.
[12:30] <cpaelzer> rafaeldtinoco: you reported a FTBFS on disco
[12:30] <cpaelzer> rafaeldtinoco: I wonder what might have changed as the last build worked
[12:30] <cpaelzer> and that was an SRU, there surely was no full bump of gcc in Disco since then
[12:31] <cpaelzer> did you check what the reason whas that this now triggers?
[12:31] <cpaelzer> or is that a local build, and not one in a "normal" build environment?
[12:32] <rafaeldtinoco> cpaelzer: it was a local build indeed
[12:32] <cpaelzer> then chances are this is "not-a-bug" (in disco)
[12:32] <rafaeldtinoco> it can be related to an enabled (in my env) Werror of somesort
[12:32] <cpaelzer> yes
[12:32] <cpaelzer> you remember that if .ig tthen switch on developer mode thing
[12:32] <cpaelzer> .git
[12:32] <rafaeldtinoco> I noticed also that DEB_HOST_XXX variables are not set
[12:33] <rafaeldtinoco> so it only works with dpkg-buildpackage basically
[12:33] <rafaeldtinoco> i tried manually dh build, debian/rules build
[12:33] <rafaeldtinoco> and always got errors
[12:33] <rafaeldtinoco> and yes, there are chances of a false alarm
[12:33] <rafaeldtinoco> sorry if that is
[12:33] <rafaeldtinoco> i was more focused in the backport
[12:34] <rafaeldtinoco> didnt think about being my build env, yes
[12:34] <rafaeldtinoco> (or my build environment is broken, dont tell me that pls)
[12:36] <cpaelzer> manual dh_... always calls for issues
[12:37] <cpaelzer> build in sbuild, if it fails you can login, if it doesn't \o/ and it will always be clean made fresh for you
[12:37] <cpaelzer> (if you have/want to build local)
[12:39] <cpaelzer> rafaeldtinoco: I have thrown it into a PPA, if it doesn't fail I'll mark it won't fix
[12:39] <rafaeldtinoco> yep, will do. thx and sorry if its just a noise
[12:50] <cpaelzer> np rafaeldtinoco, I created enough nose with my quad-haproxy MPs going back and forther through two force pushes
[12:50] <cpaelzer> so I flooded all your inboxes, we are even I guess :-)
[12:51]  * rafaeldtinoco looks at thunderbird and thx proper filters
[12:51] <cpaelzer> if paelzer then ->trash ?
[12:51] <rafaeldtinoco> cpaelzer: it also has "conversation" extension, showing only 1 mail per thread for me
[12:51] <rafaeldtinoco> #)
[12:52] <rafaeldtinoco> and diff syntax highlight and compare extension
[12:52] <rafaeldtinoco> thunderbird is pretty neat nowadays #)
[12:52] <cpaelzer> isn't grouping threads the default everywhere these days?
[12:52] <rafaeldtinoco> cpaelzer: yes, but not showing single lines per subject
[12:52] <rafaeldtinoco> w/ no threads at all
[12:53] <rafaeldtinoco> like google does
[12:53] <rafaeldtinoco> cpaelzer: btw, i was checking qemu-arm folder
[12:53] <rafaeldtinoco> there wasn't a closure on the barrier subject, right ?
[12:53] <cpaelzer> not yet
[12:53] <cpaelzer> stuck on upstream discussion
[12:53] <cpaelzer> I haven't seen a major breakthrough
[12:53] <rafaeldtinoco> my assumption is that marvell is still investigating
[12:53] <cpaelzer> the last active participant was Jan Glauber IIRC
[12:53] <rafaeldtinoco> why the data alignment caused mitigation (or not)
[12:54] <rafaeldtinoco> (changing u32int -> u64int and so)
[12:54] <cpaelzer> I had that on my radar as "waiting on upstream / waiting on partner" or is/was there pressure on you to go haead?
[12:54] <rafaeldtinoco> no pressure, just missed the discussion
[12:55] <rafaeldtinoco> i re-thought "maybe some conclusion happened and Im not aware of "
[12:55] <rafaeldtinoco> lol
[12:55] <rafaeldtinoco> but reading last emails, all I can see is that memory alignment changes behavior (likely because of cache alignment and cpu <-> coherency)
[12:55] <cpaelzer> yep, they invalidate separately then
[12:55] <rafaeldtinoco> causing more overhead for the HW sync (or less overhead) and making it more or less frequently
[12:55] <rafaeldtinoco> yep
[12:55] <cpaelzer> but that is not "a solution"
[12:55] <rafaeldtinoco> exactly
[12:56] <rafaeldtinoco> ok, my understanding is right then
[12:56] <rafaeldtinoco> thx
[12:56] <cpaelzer> yw
[13:06] <cpaelzer> doko: you asked for python-tornado yesterday as it triggers issues with python 3.8 rebuilds
[13:06] <cpaelzer> I think it is important to see that there is a newer 6.x but that was turned back to allow dependencies to follow
[13:06] <cpaelzer> never the less look at the changelog https://metadata.ftp-master.debian.org/changelogs//main/p/python-tornado/python-tornado_6.0.3+really5.1.1-1_changelog
[13:07] <cpaelzer> good old mwhudson has a change that sounds rather related "Bump ASYNC_TEST_TIMEOUT when running the autopkgtests as well"
[13:08] <cpaelzer> or do we have that already ...
[13:09] <cpaelzer> oh yeah, :-/ our Delta has that already
[13:09] <cpaelzer> grml, I thought this might be easy ...
[13:09] <Eickmeyer> LocutusOfBorg: 1) It's tagged eoan, and 2) Doesn't really need sponsorship as I have PPU on the package. Just needs the green light.
[13:12] <cpaelzer> coreycb: he pinged you as well, please tell me that you have looked more at it and know what it is :-)
[13:12] <coreycb> cpaelzer: hey sorry I've not had a chance to look yet
[13:13] <coreycb> cpaelzer: let me wrap a few things up and look
[13:15] <cpaelzer> sure, thanks for looking as well then
[13:15] <cpaelzer> if you also don't see what might be going on let me know, then we can bang our head against the wall together
[13:23] <LocutusOfBorg> Eickmeyer, this is not usually how SRU are done
[13:23] <LocutusOfBorg> 1) you have to first fix focal
[13:24] <LocutusOfBorg> 2) you have to correctly use "target to series"
[13:24] <Eickmeyer> LocutusOfBorg: Upload is in queue for focal.
[13:24] <LocutusOfBorg> ok so please wait for it to migrate before uploading to eoan
[13:24] <LocutusOfBorg> [Regression Potential]
[13:24] <LocutusOfBorg>  * None, simply adds a build dependency and patch to existing package
[13:24] <Eickmeyer> Ok. I don't have the ability to target to series.
[13:25] <LocutusOfBorg> meh, adding a new dependency has a lot of side effects
[13:25] <LocutusOfBorg> e.g. enables code that wasn't built, changes behaviour and so on
[13:25] <LocutusOfBorg> you might change this to "the current package is completely broken", adding the dependency makes it less sucky
[13:25] <LocutusOfBorg> if this is true
[13:25] <LocutusOfBorg> or try to see what changes in the build system in case the dependency is found
[13:26] <cpaelzer> coreycb: I tried a few local build (maybe that helps you to find the right start): 6.0.3@unstable (worked), 5.1.1@eoan (worked), 5.1.1@focal (the reported timeouts), 5.1.1@focal-proposed (the reported timeouts), 6.0.3@focal-proposed (dependency issues)
[13:28] <LocutusOfBorg> e.g. you could change it with something like "adding libsndfile enable the detection of various new plugins, otherwise unsupported, with the HAVE_SNDFILE preprocessor directive
[13:28] <Eickmeyer> LocutusOfBorg: Unfortunately, that's not the case. It simply allows certain synthesizer plugins to actually make sound, which they weren't before.
[13:28] <LocutusOfBorg> this list includes: aif aifc aiff au bwf flac htk iff mat4 mat5 oga ogg paf pvf pvf5 sd2 sf snd svx vcc w64 wav xi
[13:30] <LocutusOfBorg> Eickmeyer, in any case, please try to be more verbose on the regression potential task, because it makes easier for release team to ack/nack the change
[13:30] <LocutusOfBorg> in any case, LGTM
[13:30] <Eickmeyer> LocutusOfBorg: Thanks.
[13:37] <cpaelzer> coreycb: but since doko disabled the tests to be gating yo'll have to switch these back if you want to break on them
[13:37] <cpaelzer> they are always triggered, just no more making the build fail
[14:18] <rbasak> cpaelzer: when you have a couple of minutes, I'd like to chat about next steps for your armhf emulation branch please. More a process for adjustments since I'm juggling branches. Discussion of the technical details we can discuss in the MP.
[14:19] <cpaelzer> rbasak: is the standup hangout ok ?
[14:19] <rbasak> Sure
[14:22] <cpaelzer> coreycb: in a failing build env you can switch between good/bad behavior by switching /usr/bin/python3 between 3.7 and 3.8
[14:22] <rbasak> cpaelzer: you mean now or at standup time?
[14:22] <coreycb> cpaelzer: ok thanks. sorry working on charm release as well.
[14:22] <coreycb> cpaelzer: just starting to dig in
[14:23] <cpaelzer> coreycb: no problem, I just though I kept you posted on how far I get working a bit on it in background
[14:23] <cpaelzer> coreycb: to allow you a head start later on
[14:23] <cpaelzer> If I find the time to do more I'll ping yu again
[14:36] <tseliot> tjaalton, hi, I have updated nvidia 430 and 435 for this SRU. The nvidia-settings package is not ready yet, unfortunately
[14:36] <tseliot> tjaalton, but I think I'll hold that off until the next nvidia update
[14:40] <tjaalton> tseliot: was this a request to review them? :)
[14:41] <tseliot> tjaalton, yes please, also, since you asked me about the SRU the other day
[14:42] <tjaalton> right
[14:42] <tjaalton> 435 is in new, also the previous upload
[14:45] <tseliot> tjaalton, oh, so that was never approved
[14:46] <tjaalton> or looked at
[14:46] <tseliot> :/
[14:46] <tseliot> vorlon, ^^
[14:47] <tjaalton> actually
[14:47] <tjaalton> I was able to ack it from the new queue, the old one
[14:47] <tjaalton> now it should show a diff for the new upload :P
[14:49] <tseliot> good, thanks
[15:13] <blackboxsw> hi folks: probably a newbie schroot issue... I'm trying to share a directory into my schroot for collecting and sharing data after I destroy/clean the chroot for post-processing during an SRU test.   From `schroot --config` I can see my chroot base directory from the host and I `sudo mkdir ./host-data/subdir  $CHROOT_DIR/data; sudo mount -o bind ./host-data  $CHROOT_DIR/data; schroot -c <my-schroot> -- ls
[15:13] <blackboxsw> /data`
[15:14] <blackboxsw> The issue ^ is that I don't see the "subdir" from within the chroot's "/data" and any files i write there are also not persisted outside on the hostfs/host-data dir
[15:31] <vorlon> tseliot: sorry, I can't tell from context what the request is
[15:35] <LocutusOfBorg> cpaelzer, did you try the newer vbox for audio issues?
[15:35] <LocutusOfBorg> I mean, https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1840749
[15:35] <LocutusOfBorg> maybe my prod to upstream worked
[15:44] <cpaelzer> LocutusOfBorg: I didn't yet as  6.0.12 was failing hard
[15:44] <cpaelzer> LocutusOfBorg: is there a newer one or a rebuild of 6.0.12 that is worth trying?
[15:51] <cpaelzer> rbasak: I have tested the uvtool branch, found two needs for fixups but now it is good
[15:51] <cpaelzer> rbasak: https://code.launchpad.net/~paelzer/uvtool/+git/uvtool/+merge/367641 contains what you need
[15:51] <cpaelzer> it is your branch + the two fixups
[15:51] <cpaelzer> That I think you can merge now
[15:51] <cpaelzer> test results in the MP
[15:51] <ahasenack> Laney: hi, is there a way to get the logs for the arm64 test that says "always failed" in this bileto ticket? https://bileto.ubuntu.com/excuses/3830/trusty.html
[15:51] <ahasenack> it's not showing up in /running
[15:52] <cpaelzer> LocutusOfBorg: I see 6.0.14 I'll give it a try after dinner
[15:55] <Laney> ahasenack: "(always failed)" there means that there's no previous passes so it can't be a regression no matter what this run results in: http://autopkgtest.ubuntu.com/packages/ubuntu-advantage-tools
[15:55] <ahasenack> Laney: but is there a current result?
[15:56] <Laney> I dunno, britney should show that if there is
[15:56] <ahasenack> maybe I should trigger it again, then the previous run will be this current one, and then it can show me something?
[15:57] <ahasenack> switched the lander signoff to failed and back to approved
[15:57] <Laney> how long has it been since it ran?
[15:57] <ahasenack> Laney: I queued it at 14:51utc
[15:57] <Laney> from the timestamp in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-trusty-ci-train-ppa-service-3830/trusty/amd64/u/ubuntu-advantage-tools/20191023_151338_fe98b@/log.gz I'm thinkning you should be a little bit more patient
[15:57] <ahasenack> when it actually started I don't know
[15:58] <ahasenack> ok
[15:59] <Laney> you can do some URL hacks though
[15:59] <Laney> e.g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-trusty-ci-train-ppa-service-3830/?format=plain&prefix=trusty/
[15:59] <Laney> leads you to https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-trusty-ci-train-ppa-service-3830/trusty/arm64/u/ubuntu-advantage-tools/20191023_153416_fe98b@/log.gz
[15:59] <ahasenack> so arm64 is done and green
[16:00] <Laney> looks like it
[16:00] <Laney> but proposed-migration will get that next time
[16:02] <ahasenack> ok, thanks
[16:03] <LocutusOfBorg> cpaelzer, TBH there is also a 5.2.34 in unapproved queue
[16:04] <LocutusOfBorg> https://launchpad.net/%7Ecostamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+delete-packages
[16:04] <LocutusOfBorg> or here
[16:11] <blackboxsw> ok, figured out the schroot bind mount problem  on my end. I was using mk-sbuild to create the schroot which sources /etc/schroot/sbuild/fstab config to setup mounts within the schroot instead of the typical /etc/schroot/default/fstab. Adding proper bind mount fstab declarations in /etc/schroot/sbuild/fstab got me the proper bind mounted /data dir in the sbuild-created schroot.
[16:20] <doko> #if !defined(X86) && !defined(X86_64)
[16:20] <doko> #   if defined(__x86_64__) || defined(__x86_64)
[16:20] <doko> #       define X86_64
[16:20] <doko> #   elif defined(__i386__) || defined(__i386) || defined(_M_I86) || defined(_M_IX86)
[16:20] <doko> #       define I386
[16:20] <doko> #   else
[16:20] <doko> #       error Unrecognized architecture!
[16:20] <doko> #   endif
[16:20] <doko> #endif
[16:20] <doko> so 2019 ...
[16:28] <xnox> followed by inefficient assembly ?
[17:55] <coreycb> cpaelzer: python-tornado 6.0.3-1 package runs py38 tests successfully on focal without the missing dependency python-sphinxcontrib.asyncio. I'll check with Julien to see if he knows if that package is in the works.
[17:59] <coreycb> doko: are there any plans for backporting python 3.8 to bionic?
[18:14] <doko> coreycb: yes, see #1835737. but the interpreter only. and I'm currently busy with the archive opening
[18:14] <doko> jamespage also asked for it
[18:20] <coreycb> doko: thanks in advance, that'll be very helpful. he'd mentioned it briefly. and no rush.
[18:23] <kyrofa> Hey folks, quick question about rmadison: if it says "bionic/universe" it's pretty obvious that's in universe. Can someone confirm that if it just says "bionic" that means it's main? Any other component will be <repo>/<component>?
[18:56] <infinity> kyrofa: Indeed, no component is main, all others will list one.  See, eg: nvidia-driver-430 in focal/restricted.
[18:57] <infinity> kyrofa: This mirrors what you find in "Section" in the Packages headers (ie: apt-cache show $foo | grep ^Section), where main just shows the section, and others show component/section.
[18:58] <infinity> I've been tempted to change rmadison to be explicit about main (not the first time this has been asked :P), but I'm pretty sure that would break any number of home-grown scripts I don't know about, so best not to.
[19:00] <infinity> kyrofa: Arguably, this makes a lot more sense in Debian, where "main" is "basically everything" and "contrib" and "non-free" are "some bits we don't really care about because ew, licenses". :P
[19:01] <infinity> But we use the same tools, and I don't think it occurred to any of us that the presentation should be different for Ubuntu until it was too late to change it.
[19:03] <kyrofa> infinity, makes total sense, thank you!
[20:56] <mwhudson> xnox, doko: so um, it turns out numpy builds have been ignoring test suite results for years, both in debian and ubuntu :/
[20:56] <doko> \o/
[20:57] <mwhudson> i guess it's reportbug -B debian time
[20:57] <mwhudson> after coffee and meeting
[20:57] <doko> please both numpy and python-numpy
[20:58] <mwhudson> ah yeah
[20:58] <doko> python-numpy (1:1.9.2~rc1-1) experimental; urgency=medium
[20:59] <doko>   * debian/rules
[20:59] <doko>     - don't ignore failures when running unittests; Closes: #721100
[21:02] <mwhudson> well
[21:04] <mwhudson> let's say i'm not convinced that is true
[22:24] <xnox> mwhudson:  yes, but this one is very bad =)
[22:24] <mwhudson> xnox: indeed
[22:25] <xnox> mwhudson:  as in there clearly is s390x regression there. I did open a bug about it.
[22:25] <xnox> mwhudson:  you find it, right?
[22:25] <mwhudson> xnox: yes
[22:25] <xnox> cool
[22:25] <xnox> that's all there is for now =)
[22:25] <mwhudson> well the report yes, bug no
[22:26] <mwhudson>     x2 = np.array([0.0, 1.0, 2.0], ndmin=2)
[22:26] <mwhudson> E   ValueError: ndmin bigger than allowable number of dimensions NPY_MAXDIMS (=32)
[22:26] <mwhudson> uhuh
[22:27] <mwhudson> at least if it's that simple to reproduce it shouldn't be too hard to diagnose, surely
[22:32] <xnox> yes
[22:32] <xnox> clearly 2 is miss-endianed
[22:32] <xnox> or something else inside
[22:33] <xnox> git bisect would be nice here
[22:41] <LocutusOfBorg> mitya57, how is the bootstrap going? looks like idle?
[22:42] <mwhudson> oh
[22:42] <mwhudson> -    int ndmin = 0, nd;
[22:42] <mwhudson> +    int nd;
[22:42] <mwhudson> +    npy_intp ndmin = 0;
[22:42] <mwhudson> i presume npy_intp is going to turn out to not be an int
[22:43] <mwhudson> we can pass a long pointer to something expecting an int* right? it'll be fiiiine
[22:43] <sarnold> "oh that compiler warning doesn't mean anything go ahead and ignore that"
[22:44] <mwhudson> well luckily this is all passed to a variadic function
[22:44] <mwhudson> so no pesky compiler warnings at all!!
[22:46] <sarnold> ooh clever way to Improve Development Velocity!
[22:48] <mwhudson> yeah npy_intp ends up being intptr_t
[22:49] <mwhudson> hey hey guess what the offending commit message is!
[22:49] <mwhudson> "MAINT: Minor fixes and cleanups"
[22:52] <sarnold> well discovered :)
[23:08] <mwhudson> upstream bug https://github.com/numpy/numpy/issues/14767
[23:15] <mwhudson> testing patch in my ppa now