[07:37] <jibel> vorlon, thanks, chroot: cannot change root directory to 'chroot': No such file or directory
[07:37] <jibel> I'll have a look
[07:47] <alkisg> teward: good morning, are there any parted builds available for me to test? Incidentally, I'm doing a seminar in half an hour, where 15 teachers will need fat resizing..
[08:30] <doko> xnox: see https://bugs.python.org/issue35998 for the SSL TLS1.3 issue. for freebsd they run it with:
[08:30] <doko>        if sys.platform.startswith('freebsd'):
[08:30] <doko>             # bpo-35031: Some FreeBSD buildbots fail to run this test
[08:30] <doko>             # as the eof was not being received by the server if the payload
[08:30] <doko>             # size is not big enough. This behaviour only appears if the
[08:30] <doko>             # client is using TLS1.3.
[08:30] <doko>             client_context.options |= ssl.OP_NO_TLSv1_3
[08:32] <doko> so not sure why it succeeds on some arm platforms
[08:37] <doko> xnox: the bug report says, that this is seen with both 1.1.1a and 1.1.1b
[09:18] <cpaelzer> kstenerud: php7.2 might have hit autopkgtest failures after your rebuild (succeeded?)
[09:18] <cpaelzer> doko: ^^
[09:18] <cpaelzer> please make sure to sort them out
[09:18] <cpaelzer> doko: let kstenerud know if there is extra info to pass
[09:19] <kstenerud> I've kicked off a new build and am waiting for it
[10:59] <theBeliever> Hello, I am new to this IRC
[11:01] <theBeliever> Hello.. I am wondering how software standalone installation packages are made.  I have a open-source repository on github, primarily written in python and cython. To build/run the repo, first user has to install C compiler and make a python environment with all the required dependencies and then issue the commands like "make", which can be lengthy and troublesome depending upon the OS for inexperienced users.  I am looking 
[11:01] <theBeliever> installation workflow
[12:19] <kstenerud> cpaelzer @doko Re-running the build failed in the tests:
[12:19] <kstenerud> TEST 3443/14261 [ext/curl/tests/bug48203_multi.phpt]
[12:19] <kstenerud> E: Caught signal ‘Terminated’: terminating immediately
[12:19] <kstenerud> Only the amd64 build fails. All other succeed
[12:19] <kstenerud> https://launchpad.net/~kstenerud/+archive/ubuntu/disco-php7.2-fix-0050/+packages
[12:20] <doko> kstenerud: I was looking at the autopkg test failures
[12:22] <doko> LocutusOfBorg, ahasenack: see you in the sbuild changelogs ... sbuild-update --keygen isn't anymore. is this by intent and is there a replacement?
[12:23] <ahasenack> I didn't touch that, I fixed a tet
[12:23] <ahasenack> test*
[12:23] <kstenerud> I'm running sbuild manually to see what's going on
[12:24] <doko> ahh, removed in 0.77
[12:27] <ahasenack> kstenerud: the last test that it ran in that build is
[12:27] <ahasenack> TEST 3443/14261 [ext/curl/tests/bug48203_multi.phpt]^ME: Caught signal ‘Terminated’: terminating immediately
[12:28] <ahasenack> still 11000 tests to go?
[12:28] <ahasenack> what happened in the other builds, which worked?
[12:29] <kstenerud> Not sure. I remember it getting a lot farther when I ran locally, so Im doing another run
[12:30] <xnox> doko, right. the last time when we passed all tests, things were racy under load, and didn't excercise any/much of tls1.3 stuff. fun
[12:31] <ahasenack> kstenerud: you can check in https://launchpad.net/~kstenerud/+archive/ubuntu/disco-php7.2-fix-0050/+packages
[12:31] <ahasenack> the other builds are there, no?
[12:32] <kstenerud> There's only one build of that partiular PPA
[12:32] <kstenerud> But I remember doing a local build before
[12:32] <ahasenack> kstenerud: i386, arm64, armhf, ppc, s390, all passed
[12:32] <kstenerud> yes
[12:32] <ahasenack> so check them, see if they ran past that test
[12:32] <ahasenack> you are looking at changes in behavior now: set "A" worked, set "B" failed, both built the same package
[12:40] <kstenerud> Yup, the others ran through all the tests without problems
[12:40] <theBeliever> Hello, new member here
[12:41] <kstenerud> It's an odd test to be crashing on...
[12:41] <kstenerud> PASS Variation of bug #48203 with curl_multi_exec (Crash when file pointers passed to curl are closed before calling curl_multi_exec) [ext/curl/tests/bug48203_multi.phpt]
[12:46] <ahasenack> kstenerud: do the others crash? IT's not clear to me if the test is expecting a crash (odd) or not
[12:46] <ahasenack> probably not
[12:46] <kstenerud> This is the only case in all of the different builds where it crashes
[12:47] <ahasenack> might be a real issue then? :)
[12:47] <alkisg> theBeliever: hi, this channel is about the development of ubuntu itself, not about development in ubuntu in general.
[12:47] <alkisg> You might want to search for some other channel for questions for personal repositories etc; I don't know which one, have a look at https://wiki.ubuntu.com/IRC/ChannelList
[12:47] <ahasenack> conversation should continue in #ubuntu-server
[12:50] <theBeliever> thanks alkisg and ahasenack
[12:51] <alkisg> theBeliever: you're welcome, although I don't think ahasenack was talking to you, so don't continue your question in ubuntu-server, it's not related :)
[12:51] <ahasenack> right, I was talking to kstenerud, sorry :)
[12:52] <theBeliever> thanks, haha
[13:30] <LocutusOfBorg> oSoMoN, thanks for helping poppler, I did upload my package instead of your, just by mistake
[13:30] <LocutusOfBorg> It was meant to go on ppa, not the archive...
[13:30] <LocutusOfBorg> anyway, news wrt dropping llvm-4.0 from thunderbird and firefox?
[13:45] <oSoMoN> LocutusOfBorg, wrt llvm-4.0, it's done for firefox
[13:46] <oSoMoN> thunderbird is next
[13:46] <oSoMoN> LocutusOfBorg, I'm lacking context, what package did you upload to the archive instead of  a PPA?
[13:57] <LocutusOfBorg> oSoMoN, gdcm or I don't recall now
[13:58] <oSoMoN> ah, no worries
[13:58] <oSoMoN> we were both working on it at the same time, so not very efficient, but no harm done
[14:41] <LocutusOfBorg> thanks!
[15:54] <vorlon> jibel: I may have regressed livecd-rootfs for the layered case when trying to fix the ubuntustudio image build failures; look for the divert_grub stuff, and probably just revert that
[16:00] <Eickmeyer> vorlon: Speaking of which, my removing the update-grub line from the plymoth theme postinst seems to have worked. Our images are building again.
[16:00] <Eickmeyer>  I moved it to a metapackage that is used if someone wishes to rebrand their install for whatever reason.
[16:00] <Eickmeyer> Not installed by default.
[16:10] <vorlon> Eickmeyer: ok
[16:51] <teward> alkisg: I'm not normally awake at 3:47AM.  I got a message this morning that it was finally 'accepted' but there was a keyserver issue that delayed it.  Let me check.
[16:52] <teward> alkisg: there are packages at https://launchpad.net/~teward/+archive/ubuntu/build-tests for testing, I was going to test as well.
[16:55] <alkisg> teward: thanks; sorry I didn't know your timezone :)
[16:55] <alkisg> The seminar went fine with the package from cosmic
[16:55] <teward> alkisg: Eastern US timezone, UTC-4 during DST
[16:55] <teward> alkisg: indeed.  You can still test though :p
[16:55] <teward> if it works I'll put the debdiff up :P
[16:55] <alkisg> Sure
[16:57] <seb128> I looked at the firewalld autopkgtest issues in disco that are blocking quite some other things
[16:57] <seb128> there were a bunch of fallover from linux 5 in the test and ipset that needed to be updated, which I think I got resolved now
[16:58] <seb128> but there is also an issue that looks like an iptables one that is fixing upstream but sort of new feature and require new things in libnftnl
[16:58] <seb128> I put the details on bug #1820317
[16:58] <seb128> unsure who would feel like picking up the issue?
[16:58] <seb128> jdstrand, ^ security team owns iptables it looks like?
[16:59] <seb128> otherwise I would recommend we skip the firewalld tests failures for now
[17:31] <jdstrand> seb128: we were discussing iptables yesterday. we need to work with joe and amurray on who will work on this
[17:33] <jdstrand> joemcmanus: fyi, I gave you a paste of seb128's and my conversation
[17:57] <jdstrand> seb128: joemcmanus and I discussed. I'll take a look at it next week
[17:57] <jdstrand> Odd_Bloke: you might be interested in ^
[17:57] <seb128> jdstrand, thx (sorry dropped offline when communiting back from where I was working in the afternoon)
[17:58] <jdstrand> seb128: oh heh, we discussed it elsewhere, you didn't miss anything
[18:02] <Laney> seb128: jdstrand: so I could badtest the version of firewalld that's in disco-release?
[18:02] <Laney> less sure about the one in proposed though
[18:08] <Laney> actually I'm confused as to why e.g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/f/firewalld/20190313_204532_a9818@/log.gz failed (this used iptables 1.6, and I thought you were saying it's an issue introduced by 1.8)
[18:09] <jdstrand> Laney: please do not. I believe it is exposing a bug in the iptables new netfilter backend (it is supposed to be 100% replacement for iptables 1/6)
[18:09] <jdstrand> 1.6
[18:09] <Laney> vorlon: ^- I've got to go --- could you maybe work with those two to figure out the right set of hints for firewalld please?
[18:09] <Laney> (if there is one)
[18:10] <jdstrand> vorlon: nothing to see here :)
[18:10] <Laney> jdstrand: right, but iptables 1.8 is only in proposed, so that wouldn't normally be present for test runs
[18:10] <Laney> unless added explicitly
[18:10] <jdstrand> I may change my tune next week, but for now, I believe it is legitimate regression
[18:11] <jdstrand> Laney: oh, in *release*. I have no comment
[18:11] <jdstrand> I just assume let me have a closer look which I'll do next week
[18:11] <jdstrand> maybe we want to add a hint. don't know yet
[18:12] <Laney> Bugs in 1.8 make sense to me and certainly shouldn't be hinted over, but what's going on in release with 1.6 - less sure
[18:12] <Laney> At least one of the test failures seems to be because the kernel dropped a module that it was grepping for in lsmod
[18:13] <Laney> not trivial enough for me to figure out right now, sorry seb128 :(
[18:13] <seb128> Laney, yeah, that can wait for monday
[18:13] <seb128> it's probably not a good idea to unblock things just on w.e anyway
[18:13] <seb128> speaking of which, need to go, have a good one!
[18:14] <teward|drone> alkisg: let me know when you've tested, my bouncer is offline at the moment but I'm still here ;p
[18:17] <Laney> (I'll skiptest gtk+3.0, it's clearly nothing to do with that at any rate)
[18:21] <jdstrand> Laney: re 1.6> sure. to be clear, I'm only tasked with fixing iptables, not firewalld in general so if you see stuff, do what you will
[18:34] <sarnold> is our zfs installer in a state that would benefit from testing? how can I try it out? :) thanks
[18:36] <vorlon> jdstrand, Laney: the log shows that the dependencies couldn't be resolved pulling only firewalld from -proposed, so the test was retried using all available packages from -proposed.  And firewalld blocks on the new version of iptables in -proposed due to library dependencies, so there's no point in trying to test against the release version of iptables
[18:37] <alkisg> teward|drone: probably tomorrow, it's late in the evening here :) thanks!
[18:38] <teward|drone> yep
[19:08] <alkisg> teward|drone: late evening testing results: all good, fat32 works fine after the resize
[19:08] <teward|drone> I'd test but I don't keep Windows computers here at home :P
[19:08] <alkisg> teward|drone: the second test is good enough even without windows
[19:08] <alkisg> I.e. file -s /dev/loop0p1
[19:34] <ahasenack> hi, I'm debugging a build error in launchpad (ppa, but algo blocking a migration from disco-proposed). It's a test that only fails there (not dep8), locally it works. I'm zeroing in on the failed test, and noticed that it usees supplementary groups,
[19:34] <ahasenack> and the lp user has a nameless supplementary group:
[19:35] <ahasenack> uid=2001(buildd) gid=2501(buildd) groups=2501(buildd),110,117(sbuild)
[19:35] <ahasenack> 110
[19:35] <ahasenack> I'm just wondering if that is expected, or indicative of some other problem in the builder, that doesn't affect anybody else
[19:38] <teward|drone> alkisg: i got it to show more similar output to the same as initially... but different
[19:39] <teward|drone> says its unlabeled and recognizes it as MSWIN4.1 and different sector sizes
[19:39] <teward|drone> can't *test* to see whether it worked on Windows though
[19:48] <alkisg> teward|drone: I think it's good enough to get uploaded for the bionic-verification-needed step
[19:48] <alkisg> I'll do a lot more tests and report then
[19:48] <teward|drone> ack
[19:48] <teward|drone> i'll put the debdiff up
[19:49] <alkisg> thanks!
[19:49] <teward|drone> but i will have to wait for the sponsors and SRU team :P
[19:49] <alkisg> Sure
[19:49] <alkisg> There's no hurry; it's just good to have that in an lts release
[19:51] <teward|drone> yep
[19:52] <cjwatson> ahasenack: Which architecture(s)?
[19:54] <ahasenack> cjwatson: the test fails in all, but atm I'm testing in amd64 and i386, and I inspect the logs in which ever finishes first, so both show that
[19:55] <ahasenack> s/testing/troubleshooting/
[19:57] <cjwatson> ahasenack: Odd - no sign of this mysterious supplementary group in the disco amd64 base chroot
[19:58] <ahasenack> cjwatson: https://launchpadlibrarian.net/415286483/buildlog_ubuntu-disco-amd64.zeromq3_4.3.1-3ubuntu1~ppa11_BUILDING.txt.gz search for "DEBUG:"
[19:58] <cjwatson> I believe you, just trying to work out what the source could possibly be
[19:58] <ahasenack> maybe a build-dep adds that user/group
[19:59] <cjwatson> Or could be sbuild itself?
[19:59] <ahasenack> no, sbuild is 117
[19:59] <ahasenack> uid=2001(buildd) gid=2501(buildd) groups=2501(buildd),110,117(sbuild)
[19:59] <cjwatson> Sure, but the buildd user isn't in the sbuild group in the chroot, so sbuild is doing something
[19:59] <ahasenack> ah
[20:00] <cjwatson> Also there's a stray bit in /etc/group in the chroot which could be relevant
[20:00] <cjwatson> buildd:x:2501:lamont
[20:00] <cjwatson> Maybe something sees the nonexistent user and makes up a UID?
[20:00] <cjwatson> If it's that, then it'll be fixed by the new clean chroots that we'll hopefully be switching to in not very long (oh hi infinity)
[20:01] <cjwatson> But it's Friday evening and I have other things to do - could you file a bug against launchpad-buildd?
[20:01] <ahasenack> about lamont being a member of buildd?
[20:02] <cjwatson> Just about the problem in general
[20:02] <cjwatson> We don't yet know for sure exactly where it is
[20:02] <cjwatson> I'm just speculating that the stray user might be a problem
[20:02] <ahasenack> and I also don't know for sure the test is failing because of this nameless group
[20:02] <ahasenack> it's just a hint
[20:02] <ahasenack> running test_filter_with_supplemental_process_owner_gid
[20:02] <ahasenack> bounce: rc=-1, errno=11, attempt=0: Resource temporarily unavailable
[20:02] <cjwatson> Well, what I really want is not to be looking into it on Friday night.  I don't mind exactly how you leave a note to look into it later :)
[20:03] <ahasenack> sure
[20:13] <teward|drone> alkisg: debdiff attached to the bug, and sponsors subscribed; once it's uploaded it needs to go through SRU processes :P
[20:15] <alkisg> Great, thanks again teward|drone
[20:38] <ilmaisin> hello
[20:39] <ilmaisin> i can't find any recent info about the wayland plans, is it soon going to be the default?
[20:40] <ilmaisin> gnome 3.32 will have fractional scaling, but it needs wayland to do it...
[21:08] <wxl> ilmaisin: https://discourse.ubuntu.com/t/the-road-to-disco-what-features-might-go-in-what-features-actually-hit-the-repos/9347/41
[21:16] <ilmaisin> wxl: so probably not in 19.04, but maybe after that? i'm wondering whether it will make it into the next lts
[21:19] <wxl> ilmaisin: probably best to ask the desktop team, which is who's chatting there. you can also try #ubuntu-desktop
[22:48] <jibel> vorlon, I see what the problem is with layered images. I'll propose a patch.
[22:50] <jibel> there is no chroot/ after calling lb chroot_layered, the original chroot should be restored
[23:02] <Laney> vorlon: don't see that in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/f/firewalld/20190313_204532_a9818@/log.gz sorry, what's the string to search for? (I'd have thought I'd see iptables getting upgraded, in that case)
[23:02] <Laney> jdstrand: yeah, seb128's fixing the rest of it :>
[23:03] <Laney> anyway, not really here, feel free to ignore me until next week
[23:04]  * teward ignores Laney per request.  :P
[23:04] <seb128> Laney, stop working, it's w.e time!