[02:45] 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] Looks like a build failure. [02:55] +1 insightful [03:07] That looks fun, same file is in python3-greenlet-dbg and python3-greenlet. [03:08] Specifically if you look at https://launchpadlibrarian.net/447991806/python-greenlet_0.4.15-2_0.4.15-2ubuntu1.diff.gz [03:08] See why that'd be bad? :P [03:12] oh yay [03:12] thanks for chasing :) [03:16] Sure. I guess I can't just make a sarcastic comment. :3 [07:23] sil2100: hi, can you add focal support to bileto please? [07:52] mitya57: ah! Yes, let me bump the cache [07:55] mitya57: should be enabled in up to 30 minutes [08:47] sil2100: it works now, thanks a lot! [08:48] 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:48] Launchpad bug 1849168 in carla (Ubuntu) "[SRU] Missing build dep libsndfile1-dev discovered" [Undecided,Fix committed] https://launchpad.net/bugs/1849168 [08:49] yw! [09:01] mwhudson, Unit193 do I have greenlet greenlight to upload a fix for it? [09:01] doko, ^^ [09:02] I just pointed out what went wrong. [09:03] yes sure bug greenhighlighting you doesn't hurt! [09:04] 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] mwhudson, I think I already crafted a fix [09:20] mwhudson, https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+sourcepub/10667371/+listing-archive-extra [09:20] if you agree [09:20] LocutusOfBorg: lgtm [09:21] still have to debdiff debs [09:24] feel free to upload if you like it, or I can do it and credit you :) [09:24] I'm also going to update the debian bug report [09:42] 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] LocutusOfBorg: eh just update it, getting late here [09:44] *upload [09:44] thanks :D [09:44] LocutusOfBorg: sorry if i was being ambiguous earlier [09:45] I "just" woke up :D [10:35] Hi all, is there somewhere I can find the commands used to build the official Ubuntu netboot ISOs? Specifically the xorriso arguments [11:18] rafaeldtinoco: o/ [11:18] rafaeldtinoco: Josh suggested I ask you to arrange a seed change so you can get familiar [11:18] rbasak: morning o/ [11:18] rbasak: awesome, I read the docs already [11:18] Great! I want to get mysql-router seeded in Focal [11:18] alright, let me go through it [11:18] and ask you whenever I have questions [11:19] Actually, I should tell you what I really need, rather than presuppose a solution [11:19] What I need is mysql-router in main in Focal :) [11:20] yep I thought it was that #) [11:20] rbasak: do u have a MIR already ? [11:21] src:mysql-8.0 is in main already, and mysql-router is built from that [11:21] That's the closest we have to an approved MIR [11:22] alright [11:26] cpaelzer: thank you for the uvtool reviews. I'm working on your emulation branch next. [11:26] I have a rebased/squashed version locally. [12:30] rafaeldtinoco: you reported a FTBFS on disco [12:30] rafaeldtinoco: I wonder what might have changed as the last build worked [12:30] and that was an SRU, there surely was no full bump of gcc in Disco since then [12:31] did you check what the reason whas that this now triggers? [12:31] or is that a local build, and not one in a "normal" build environment? [12:32] cpaelzer: it was a local build indeed [12:32] then chances are this is "not-a-bug" (in disco) [12:32] it can be related to an enabled (in my env) Werror of somesort [12:32] yes [12:32] you remember that if .ig tthen switch on developer mode thing [12:32] .git [12:32] I noticed also that DEB_HOST_XXX variables are not set [12:33] so it only works with dpkg-buildpackage basically [12:33] i tried manually dh build, debian/rules build [12:33] and always got errors [12:33] and yes, there are chances of a false alarm [12:33] sorry if that is [12:33] i was more focused in the backport [12:34] didnt think about being my build env, yes [12:34] (or my build environment is broken, dont tell me that pls) [12:36] manual dh_... always calls for issues [12:37] 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] (if you have/want to build local) [12:39] rafaeldtinoco: I have thrown it into a PPA, if it doesn't fail I'll mark it won't fix [12:39] yep, will do. thx and sorry if its just a noise === ricab is now known as ricab|lunch [12:50] np rafaeldtinoco, I created enough nose with my quad-haproxy MPs going back and forther through two force pushes [12:50] so I flooded all your inboxes, we are even I guess :-) [12:51] * rafaeldtinoco looks at thunderbird and thx proper filters [12:51] if paelzer then ->trash ? [12:51] cpaelzer: it also has "conversation" extension, showing only 1 mail per thread for me [12:51] #) [12:52] and diff syntax highlight and compare extension [12:52] thunderbird is pretty neat nowadays #) [12:52] isn't grouping threads the default everywhere these days? [12:52] cpaelzer: yes, but not showing single lines per subject [12:52] w/ no threads at all [12:53] like google does [12:53] cpaelzer: btw, i was checking qemu-arm folder [12:53] there wasn't a closure on the barrier subject, right ? [12:53] not yet [12:53] stuck on upstream discussion [12:53] I haven't seen a major breakthrough [12:53] my assumption is that marvell is still investigating [12:53] the last active participant was Jan Glauber IIRC [12:53] why the data alignment caused mitigation (or not) [12:54] (changing u32int -> u64int and so) [12:54] 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] no pressure, just missed the discussion [12:55] i re-thought "maybe some conclusion happened and Im not aware of " [12:55] lol [12:55] but reading last emails, all I can see is that memory alignment changes behavior (likely because of cache alignment and cpu <-> coherency) [12:55] yep, they invalidate separately then [12:55] causing more overhead for the HW sync (or less overhead) and making it more or less frequently [12:55] yep [12:55] but that is not "a solution" [12:55] exactly [12:56] ok, my understanding is right then [12:56] thx [12:56] yw [13:06] doko: you asked for python-tornado yesterday as it triggers issues with python 3.8 rebuilds [13:06] 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] 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] good old mwhudson has a change that sounds rather related "Bump ASYNC_TEST_TIMEOUT when running the autopkgtests as well" [13:08] or do we have that already ... [13:09] oh yeah, :-/ our Delta has that already [13:09] grml, I thought this might be easy ... [13:09] 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] coreycb: he pinged you as well, please tell me that you have looked more at it and know what it is :-) [13:12] cpaelzer: hey sorry I've not had a chance to look yet [13:13] cpaelzer: let me wrap a few things up and look [13:15] sure, thanks for looking as well then [13:15] 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] Eickmeyer, this is not usually how SRU are done [13:23] 1) you have to first fix focal [13:24] 2) you have to correctly use "target to series" [13:24] LocutusOfBorg: Upload is in queue for focal. [13:24] ok so please wait for it to migrate before uploading to eoan [13:24] [Regression Potential] [13:24] * None, simply adds a build dependency and patch to existing package [13:24] Ok. I don't have the ability to target to series. [13:25] meh, adding a new dependency has a lot of side effects [13:25] e.g. enables code that wasn't built, changes behaviour and so on [13:25] you might change this to "the current package is completely broken", adding the dependency makes it less sucky [13:25] if this is true [13:25] or try to see what changes in the build system in case the dependency is found [13:26] 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] 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] LocutusOfBorg: Unfortunately, that's not the case. It simply allows certain synthesizer plugins to actually make sound, which they weren't before. [13:28] 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] 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] in any case, LGTM [13:30] LocutusOfBorg: Thanks. [13:37] 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] they are always triggered, just no more making the build fail === ricab|lunch is now known as ricab [14:18] 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] rbasak: is the standup hangout ok ? [14:19] Sure [14:22] 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] cpaelzer: you mean now or at standup time? [14:22] cpaelzer: ok thanks. sorry working on charm release as well. [14:22] cpaelzer: just starting to dig in [14:23] coreycb: no problem, I just though I kept you posted on how far I get working a bit on it in background [14:23] coreycb: to allow you a head start later on [14:23] If I find the time to do more I'll ping yu again === ricab is now known as ricab|bbl [14:36] tjaalton, hi, I have updated nvidia 430 and 435 for this SRU. The nvidia-settings package is not ready yet, unfortunately [14:36] tjaalton, but I think I'll hold that off until the next nvidia update [14:40] tseliot: was this a request to review them? :) [14:41] tjaalton, yes please, also, since you asked me about the SRU the other day [14:42] right [14:42] 435 is in new, also the previous upload [14:45] tjaalton, oh, so that was never approved [14:46] or looked at [14:46] :/ [14:46] vorlon, ^^ [14:47] actually [14:47] I was able to ack it from the new queue, the old one [14:47] now it should show a diff for the new upload :P [14:49] good, thanks [15:13] 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 -- ls [15:13] /data` [15:14] 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] tseliot: sorry, I can't tell from context what the request is [15:35] cpaelzer, did you try the newer vbox for audio issues? [15:35] I mean, https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1840749 [15:35] Launchpad bug 1840749 in virtualbox (Ubuntu) "Sound problems since 5.2.18" [Wishlist,Confirmed] [15:35] maybe my prod to upstream worked [15:44] LocutusOfBorg: I didn't yet as 6.0.12 was failing hard [15:44] LocutusOfBorg: is there a newer one or a rebuild of 6.0.12 that is worth trying? [15:51] rbasak: I have tested the uvtool branch, found two needs for fixups but now it is good [15:51] rbasak: https://code.launchpad.net/~paelzer/uvtool/+git/uvtool/+merge/367641 contains what you need [15:51] it is your branch + the two fixups [15:51] That I think you can merge now [15:51] test results in the MP [15:51] 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] it's not showing up in /running [15:52] LocutusOfBorg: I see 6.0.14 I'll give it a try after dinner [15:55] 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] Laney: but is there a current result? [15:56] I dunno, britney should show that if there is [15:56] maybe I should trigger it again, then the previous run will be this current one, and then it can show me something? [15:57] switched the lander signoff to failed and back to approved [15:57] how long has it been since it ran? [15:57] Laney: I queued it at 14:51utc [15:57] 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] when it actually started I don't know [15:58] ok === ricab|bbl is now known as ricab [15:59] you can do some URL hacks though [15:59] e.g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-trusty-ci-train-ppa-service-3830/?format=plain&prefix=trusty/ [15:59] 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] so arm64 is done and green [16:00] looks like it [16:00] but proposed-migration will get that next time [16:02] ok, thanks [16:03] cpaelzer, TBH there is also a 5.2.34 in unapproved queue [16:04] https://launchpad.net/%7Ecostamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+delete-packages [16:04] or here [16:11] 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] #if !defined(X86) && !defined(X86_64) [16:20] # if defined(__x86_64__) || defined(__x86_64) [16:20] # define X86_64 [16:20] # elif defined(__i386__) || defined(__i386) || defined(_M_I86) || defined(_M_IX86) [16:20] # define I386 [16:20] # else [16:20] # error Unrecognized architecture! [16:20] # endif [16:20] #endif [16:20] so 2019 ... [16:28] followed by inefficient assembly ? [17:55] 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] doko: are there any plans for backporting python 3.8 to bionic? [18:14] coreycb: yes, see #1835737. but the interpreter only. and I'm currently busy with the archive opening [18:14] jamespage also asked for it [18:20] doko: thanks in advance, that'll be very helpful. he'd mentioned it briefly. and no rush. [18:23] 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 /? [18:56] kyrofa: Indeed, no component is main, all others will list one. See, eg: nvidia-driver-430 in focal/restricted. [18:57] 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] 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] 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] 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] infinity, makes total sense, thank you! [20:56] xnox, doko: so um, it turns out numpy builds have been ignoring test suite results for years, both in debian and ubuntu :/ [20:56] \o/ [20:57] i guess it's reportbug -B debian time [20:57] after coffee and meeting [20:57] please both numpy and python-numpy [20:58] ah yeah [20:58] python-numpy (1:1.9.2~rc1-1) experimental; urgency=medium [20:59] * debian/rules [20:59] - don't ignore failures when running unittests; Closes: #721100 [21:02] well [21:04] let's say i'm not convinced that is true [22:24] mwhudson: yes, but this one is very bad =) [22:24] xnox: indeed [22:25] mwhudson: as in there clearly is s390x regression there. I did open a bug about it. [22:25] mwhudson: you find it, right? [22:25] xnox: yes [22:25] cool [22:25] that's all there is for now =) [22:25] well the report yes, bug no [22:26] x2 = np.array([0.0, 1.0, 2.0], ndmin=2) [22:26] E ValueError: ndmin bigger than allowable number of dimensions NPY_MAXDIMS (=32) [22:26] uhuh [22:27] at least if it's that simple to reproduce it shouldn't be too hard to diagnose, surely [22:32] yes [22:32] clearly 2 is miss-endianed [22:32] or something else inside [22:33] git bisect would be nice here [22:41] mitya57, how is the bootstrap going? looks like idle? [22:42] oh [22:42] - int ndmin = 0, nd; [22:42] + int nd; [22:42] + npy_intp ndmin = 0; [22:42] i presume npy_intp is going to turn out to not be an int [22:43] we can pass a long pointer to something expecting an int* right? it'll be fiiiine [22:43] "oh that compiler warning doesn't mean anything go ahead and ignore that" [22:44] well luckily this is all passed to a variadic function [22:44] so no pesky compiler warnings at all!! [22:46] ooh clever way to Improve Development Velocity! [22:48] yeah npy_intp ends up being intptr_t [22:49] hey hey guess what the offending commit message is! [22:49] "MAINT: Minor fixes and cleanups" [22:52] well discovered :) [23:08] upstream bug https://github.com/numpy/numpy/issues/14767 [23:15] testing patch in my ppa now