=== cpaelzer__ is now known as cpaelzer [07:37] vorlon, thanks, chroot: cannot change root directory to 'chroot': No such file or directory [07:37] I'll have a look [07:47] 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] xnox: see https://bugs.python.org/issue35998 for the SSL TLS1.3 issue. for freebsd they run it with: [08:30] if sys.platform.startswith('freebsd'): [08:30] # bpo-35031: Some FreeBSD buildbots fail to run this test [08:30] # as the eof was not being received by the server if the payload [08:30] # size is not big enough. This behaviour only appears if the [08:30] # client is using TLS1.3. [08:30] client_context.options |= ssl.OP_NO_TLSv1_3 [08:32] so not sure why it succeeds on some arm platforms [08:37] xnox: the bug report says, that this is seen with both 1.1.1a and 1.1.1b [09:18] kstenerud: php7.2 might have hit autopkgtest failures after your rebuild (succeeded?) [09:18] doko: ^^ [09:18] please make sure to sort them out [09:18] doko: let kstenerud know if there is extra info to pass [09:19] I've kicked off a new build and am waiting for it [10:59] Hello, I am new to this IRC [11:01] 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] installation workflow === ricab is now known as ricab|lunch [12:19] cpaelzer @doko Re-running the build failed in the tests: [12:19] TEST 3443/14261 [ext/curl/tests/bug48203_multi.phpt] [12:19] E: Caught signal ‘Terminated’: terminating immediately [12:19] Only the amd64 build fails. All other succeed [12:19] https://launchpad.net/~kstenerud/+archive/ubuntu/disco-php7.2-fix-0050/+packages [12:20] kstenerud: I was looking at the autopkg test failures [12:22] 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] I didn't touch that, I fixed a tet [12:23] test* [12:23] I'm running sbuild manually to see what's going on [12:24] ahh, removed in 0.77 [12:27] kstenerud: the last test that it ran in that build is [12:27] TEST 3443/14261 [ext/curl/tests/bug48203_multi.phpt]^ME: Caught signal ‘Terminated’: terminating immediately [12:28] still 11000 tests to go? [12:28] what happened in the other builds, which worked? [12:29] Not sure. I remember it getting a lot farther when I ran locally, so Im doing another run [12:30] 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] kstenerud: you can check in https://launchpad.net/~kstenerud/+archive/ubuntu/disco-php7.2-fix-0050/+packages [12:31] the other builds are there, no? [12:32] There's only one build of that partiular PPA [12:32] But I remember doing a local build before [12:32] kstenerud: i386, arm64, armhf, ppc, s390, all passed [12:32] yes [12:32] so check them, see if they ran past that test [12:32] you are looking at changes in behavior now: set "A" worked, set "B" failed, both built the same package [12:40] Yup, the others ran through all the tests without problems [12:40] Hello, new member here [12:41] It's an odd test to be crashing on... [12:41] 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:41] bug 48203 in EasyUbuntu "Installed packages not deselected" [Wishlist,Fix committed] https://launchpad.net/bugs/48203 [12:46] kstenerud: do the others crash? IT's not clear to me if the test is expecting a crash (odd) or not [12:46] probably not [12:46] This is the only case in all of the different builds where it crashes [12:47] might be a real issue then? :) [12:47] theBeliever: hi, this channel is about the development of ubuntu itself, not about development in ubuntu in general. [12:47] 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] conversation should continue in #ubuntu-server [12:50] thanks alkisg and ahasenack [12:51] 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] right, I was talking to kstenerud, sorry :) [12:52] thanks, haha === ricab|lunch is now known as ricab [13:30] oSoMoN, thanks for helping poppler, I did upload my package instead of your, just by mistake [13:30] It was meant to go on ppa, not the archive... [13:30] anyway, news wrt dropping llvm-4.0 from thunderbird and firefox? [13:45] LocutusOfBorg, wrt llvm-4.0, it's done for firefox [13:46] thunderbird is next [13:46] LocutusOfBorg, I'm lacking context, what package did you upload to the archive instead of a PPA? [13:57] oSoMoN, gdcm or I don't recall now [13:58] ah, no worries [13:58] we were both working on it at the same time, so not very efficient, but no harm done [14:41] thanks! [15:54] 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] 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] I moved it to a metapackage that is used if someone wishes to rebrand their install for whatever reason. [16:00] Not installed by default. [16:10] Eickmeyer: ok [16:51] 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] alkisg: there are packages at https://launchpad.net/~teward/+archive/ubuntu/build-tests for testing, I was going to test as well. [16:55] teward: thanks; sorry I didn't know your timezone :) [16:55] The seminar went fine with the package from cosmic [16:55] alkisg: Eastern US timezone, UTC-4 during DST [16:55] alkisg: indeed. You can still test though :p [16:55] if it works I'll put the debdiff up :P [16:55] Sure [16:57] I looked at the firewalld autopkgtest issues in disco that are blocking quite some other things [16:57] 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] 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] I put the details on bug #1820317 [16:58] bug 1820317 in iptables (Ubuntu) "The firewalld autopackage tests fail due to iptables" [High,New] https://launchpad.net/bugs/1820317 [16:58] unsure who would feel like picking up the issue? [16:58] jdstrand, ^ security team owns iptables it looks like? [16:59] otherwise I would recommend we skip the firewalld tests failures for now [17:31] seb128: we were discussing iptables yesterday. we need to work with joe and amurray on who will work on this [17:33] joemcmanus: fyi, I gave you a paste of seb128's and my conversation [17:57] seb128: joemcmanus and I discussed. I'll take a look at it next week [17:57] Odd_Bloke: you might be interested in ^ [17:57] jdstrand, thx (sorry dropped offline when communiting back from where I was working in the afternoon) [17:58] seb128: oh heh, we discussed it elsewhere, you didn't miss anything [18:02] seb128: jdstrand: so I could badtest the version of firewalld that's in disco-release? [18:02] less sure about the one in proposed though [18:08] 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] 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] 1.6 [18:09] 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] (if there is one) [18:10] vorlon: nothing to see here :) [18:10] jdstrand: right, but iptables 1.8 is only in proposed, so that wouldn't normally be present for test runs [18:10] unless added explicitly [18:10] I may change my tune next week, but for now, I believe it is legitimate regression [18:11] Laney: oh, in *release*. I have no comment [18:11] I just assume let me have a closer look which I'll do next week [18:11] maybe we want to add a hint. don't know yet [18:12] 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] 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] not trivial enough for me to figure out right now, sorry seb128 :( [18:13] Laney, yeah, that can wait for monday [18:13] it's probably not a good idea to unblock things just on w.e anyway [18:13] speaking of which, need to go, have a good one! [18:14] alkisg: let me know when you've tested, my bouncer is offline at the moment but I'm still here ;p [18:17] (I'll skiptest gtk+3.0, it's clearly nothing to do with that at any rate) [18:21] 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] is our zfs installer in a state that would benefit from testing? how can I try it out? :) thanks [18:36] 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] teward|drone: probably tomorrow, it's late in the evening here :) thanks! [18:38] yep [19:08] teward|drone: late evening testing results: all good, fat32 works fine after the resize [19:08] I'd test but I don't keep Windows computers here at home :P [19:08] teward|drone: the second test is good enough even without windows [19:08] I.e. file -s /dev/loop0p1 [19:34] 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] and the lp user has a nameless supplementary group: [19:35] uid=2001(buildd) gid=2501(buildd) groups=2501(buildd),110,117(sbuild) [19:35] 110 [19:35] 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] alkisg: i got it to show more similar output to the same as initially... but different [19:39] says its unlabeled and recognizes it as MSWIN4.1 and different sector sizes [19:39] can't *test* to see whether it worked on Windows though [19:48] teward|drone: I think it's good enough to get uploaded for the bionic-verification-needed step [19:48] I'll do a lot more tests and report then [19:48] ack [19:48] i'll put the debdiff up [19:49] thanks! [19:49] but i will have to wait for the sponsors and SRU team :P [19:49] Sure [19:49] There's no hurry; it's just good to have that in an lts release [19:51] yep [19:52] ahasenack: Which architecture(s)? [19:54] 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] s/testing/troubleshooting/ [19:57] ahasenack: Odd - no sign of this mysterious supplementary group in the disco amd64 base chroot [19:58] cjwatson: https://launchpadlibrarian.net/415286483/buildlog_ubuntu-disco-amd64.zeromq3_4.3.1-3ubuntu1~ppa11_BUILDING.txt.gz search for "DEBUG:" [19:58] I believe you, just trying to work out what the source could possibly be [19:58] maybe a build-dep adds that user/group [19:59] Or could be sbuild itself? [19:59] no, sbuild is 117 [19:59] uid=2001(buildd) gid=2501(buildd) groups=2501(buildd),110,117(sbuild) [19:59] Sure, but the buildd user isn't in the sbuild group in the chroot, so sbuild is doing something [19:59] ah [20:00] Also there's a stray bit in /etc/group in the chroot which could be relevant [20:00] buildd:x:2501:lamont [20:00] Maybe something sees the nonexistent user and makes up a UID? [20:00] 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] But it's Friday evening and I have other things to do - could you file a bug against launchpad-buildd? [20:01] about lamont being a member of buildd? [20:02] Just about the problem in general [20:02] We don't yet know for sure exactly where it is [20:02] I'm just speculating that the stray user might be a problem [20:02] and I also don't know for sure the test is failing because of this nameless group [20:02] it's just a hint [20:02] running test_filter_with_supplemental_process_owner_gid [20:02] bounce: rc=-1, errno=11, attempt=0: Resource temporarily unavailable [20:02] 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] sure [20:13] alkisg: debdiff attached to the bug, and sponsors subscribed; once it's uploaded it needs to go through SRU processes :P [20:15] Great, thanks again teward|drone [20:38] hello [20:39] i can't find any recent info about the wayland plans, is it soon going to be the default? [20:40] gnome 3.32 will have fractional scaling, but it needs wayland to do it... [21:08] 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] 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] ilmaisin: probably best to ask the desktop team, which is who's chatting there. you can also try #ubuntu-desktop [22:48] vorlon, I see what the problem is with layered images. I'll propose a patch. [22:50] there is no chroot/ after calling lb chroot_layered, the original chroot should be restored [23:02] 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] jdstrand: yeah, seb128's fixing the rest of it :> [23:03] anyway, not really here, feel free to ignore me until next week [23:04] * teward ignores Laney per request. :P [23:04] Laney, stop working, it's w.e time!