[00:14] <nacc> xnox: cyphermox: am i correct in understanding htat in a working environment (which I have yet to consistenly make), the scopes for lxdbr0 would be DNS LLMNR/IPv4 LLMNR/IPv6? Does everyone else just have working host -> container lookups of their LXDs and not hit this at all? :)
[00:14] <nacc> stgraber: --^ :)
[00:18] <nacc> xnox: cyphermox: i wonder if this is all because lxd itself doesn't start a boot ... so possibly that boot-time race i saw earlier was just relative to when the dns records were cached/recorded?
[00:27] <Unit193> mwhudson: There's regressions http://people.canonical.com/~ubuntu-archive/proposed-migration/artful/update_excuses.html#golang-github-jacobsa-crypto
[00:28] <sarnold> that line-wrapped here at cry\npto and my brain turned that into "cry potato"
[00:30] <Unit193> Heh, it just pushed the url to its own line for me, I think I like your version better though.
[00:30] <Unit193> Also, you lost identification to services during the splits.
[00:30] <sarnold> :(
[00:31] <sarnold> wait how am I here? I thought this channel forbid joins by unregistered?
[00:31] <Unit193> That was disabled since the spam hadn't been hitting elsewhere.
[00:34] <sarnold> ah nice :) it was always annoying to discover I'd been parted from this channel for a day or several
[00:34] <Unit193> More so since ubuntulog did too.
[01:13] <sarnold> bdmurray: interesting, the cancer spreads beyond openssl -- 1699630 -- openssl has trouble, and then nothing else makes sense, and then other packages get stuck half-way too
[07:45] <bigon> is ubuntu somehow shipping a  policy-rc.d file by default? I'm asking because of https://bugs.launchpad.net/ubuntu/+source/audit/+bug/1646015
[08:02] <pitti> bigon: mk-sbuild does, but certainly not normal installs
[08:08] <bigon> idd
[08:08] <bigon> apparently it's a docker thing (after some quick googleing)
[08:48] <cpaelzer> mitya57: ping
[08:48] <mitya57> o/
[08:48] <cpaelzer> mitya57: saw you replying so you are awake :-)
[08:48] <cpaelzer> mitya57: tell me how I could help once you read my reply to the s390x issues
[08:49] <mitya57> oh, thanks a lot
[08:49]  * mitya57 reads
[08:51] <mitya57> cpaelzer, how difficult is it to get the stack trace of the hung process?
[08:51] <cpaelzer> mitya57: like while hanging - or in advance while it runs into it ?
[08:52] <mitya57> while hanged
[08:52] <cpaelzer> easy I'd think, let me rekick it into the case
[08:52] <cpaelzer> but it doesn't seem to spin so we likely get only one - the poll it is hanging on
[08:53] <cpaelzer> anyway - it started - I'll ping you once it is hanging so we can joint debug it then
[08:54] <cpaelzer> mitya57: and nobody on the mail said no - but at least from my experience I have not seen s390x specific hangs so far on any other builds
[08:55] <Laney> cpaelzer: actually I noticed one yesterday ;-)
[08:55] <Laney> https://launchpad.net/ubuntu/+source/clutter-1.0/1.26.0+dfsg-4/+build/12556836
[08:55] <mitya57> cpaelzer, also it would be even more interesting to check https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2819/+build/12784776, there all Qt test processes have exited, so the hang happens in make or some other part of the build system.
[08:56] <cpaelzer> mitya57: sure I just picked the first one in your set of links
[08:57] <cpaelzer> mitya57: once we looked at the strace of the one now runnign I can trigger the multimedia one
[08:57] <cpaelzer> interesting Laney - and also on/after tests
[08:57] <mitya57> cpaelzer, thank you again! The first one is also interesting, maybe it will uncover some bug in Qt…
[08:58] <xnox> nacc, dns only starts with the first container....
[08:58] <Laney> cpaelzer: yeah, although this is the first upload of that pkg where tests are run
[08:58] <cpaelzer> Laney: mitya57: maybe something in whatever test framework they use changed and now hangs (almost) all test son s390?
[08:59] <mitya57> cpaelzer: Our test frameworks are completely different.
[08:59] <cpaelzer> :-/
[08:59] <cpaelzer> so much for the theory
[08:59] <Laney> could be a coincidence
[09:00] <mitya57> One thing in common is the GLib main loop, though.
[09:01] <Laney> it didn't hang in debian but all the tests failed early there: https://buildd.debian.org/status/fetch.php?pkg=clutter-1.0&arch=s390x&ver=1.26.0+dfsg-4&stamp=1494334721&raw=0
[09:04] <cpaelzer> mitya57: the strace isn't great because we don't see the actual call of the program but instead that it was stopped and continued http://paste.ubuntu.com/24923578/
[09:04] <cpaelzer> which means I'd need a way to atatch earlier :-/
[09:04]  * Laney tries some backports
[09:05] <seb128> Laney, you should try some hangout :-)
[09:05] <Laney> ffs
[09:05] <cpaelzer> maybe with follow forks to an interim one that stays a while
[09:05] <seb128> we are waiting for you :p
[09:05] <mitya57> cpaelzer, maybe you can attach gdb instead of strace?
[09:05] <Laney> :/
[09:05] <Laney> wait a minute
[09:05] <mitya57> cpaelzer, actually by stacktrace, I meant one from gdb
[09:07] <mitya57> (though it may be also not very interesting)
[09:08] <cpaelzer> mitya57: it is just as borked http://paste.ubuntu.com/24923590/
[09:09] <cpaelzer> whatever it is it already happened
[09:10] <cpaelzer> I'm starting the qtmultimedia one to avoid this being a complex red herring
[09:10] <mitya57> :(
[09:11] <mitya57> cpaelzer, yes, maybe qtmultimedia would be different
[09:16] <cpaelzer> Attached strace with -ff and such to  "/usr/bin/dh build" while it was running /usr/bin/dh_auto_build
[09:16] <cpaelzer> That way it should track whatever follows
[09:16] <cpaelzer> And it is now in debian/rules override_dh_auto_test-arch - so who knows maybe we find something
[09:16] <cpaelzer> but obviously this is a huge slowdown-fest now :-)
[09:18] <cpaelzer> mitya57: hmm maybe - does that match your qtmultimedia hang http://paste.ubuntu.com/24923618/ ?
[09:18] <cpaelzer> hmm seems similar - this time ./tst_qdeclarativemultimediaglobal
[09:18] <mitya57> cpaelzer, yes, it does
[09:19] <cpaelzer> full process chain http://paste.ubuntu.com/24923623/
[09:20] <mitya57> cpaelzer, I wonder how make[4] has exited if a child process is still running?
[09:20] <mitya57> Do you have the full log? (stdout/stderr, not strace)
[09:22] <cpaelzer> well I have my console and buildlog
[09:22] <cpaelzer> so yes
[09:23] <cpaelzer> in any case the follow fork strace workd here FYI http://paste.ubuntu.com/24923638/
[09:23] <cpaelzer> that is the haning pid
[09:23] <cpaelzer> here also the build log so far http://paste.ubuntu.com/24923644/
[09:23] <sil2100> Laney: hey! I'm a bit of an autopkgtest noob - I triggered a test run through an explicit command through the request.cgi URL, I saw the test running and now that it's finished, where can I see the logs for it? I don't see it in http://autopkgtest.ubuntu.com/packages/matlab2tikz/artful/amd64
[09:24] <Laney> sil2100: for a PPA?
[09:25] <sil2100> Laney: yeah
[09:25] <mitya57> cpaelzer, thanks, so maybe the issue is actually somewhere in Qt test runner.
[09:25] <Laney> https://wiki.ubuntu.com/ProposedMigration/#Testing_against_a_PPA
[09:25]  * sil2100 reads up
[09:25] <sil2100> Laney: thanks!
[09:25] <mitya57> here we also have this:
[09:25] <mitya57> QWARN  : QDeclarativeMultimediaGlobal::test_convertVolume() file:///usr/lib/s390x-linux-gnu/qt5/qml/QtTest/TestCase.qml:1781: TypeError: Cannot read property 'tag' of undefined
[09:26] <cpaelzer> mitya57: the gdb backtrace looks just the same
[09:26] <cpaelzer> as in the former case
[09:28] <mitya57> If the test runner was in C++, I would like to add a breakpoint on the line where that TypeError is printed, but it is in QML so that would be difficult.
[09:29] <cpaelzer> FD 5 which it polls on seems to be eventfd
[09:30] <mitya57> That doesn't say anything to me :(
[09:31] <cpaelzer> I wonder that the full starce has no open/socket/... that returns =5
[09:31] <cpaelzer> usually that is what I expect for those FDs
[09:31] <mitya57> cpaelzer, what do you think about trying valgrind? bad idea?
[09:32] <cpaelzer> bad idea
[09:32] <cpaelzer> valgrind needs to rewrite code so you need to atatch upfront
[09:32] <cpaelzer> if I would set that up working I'd attach gdb
[09:32] <cpaelzer> the hard part is to "catch" it in between all the build systems complexity
[09:32] <cpaelzer> that is why the strace -ff was neat to track at least a bit
[09:32] <mitya57> cpaelzer, I can tell you how to run the test process directly
[09:32] <cpaelzer> well lets try
[09:33] <mitya57> Then you should be able to set up gdb
[09:33] <cpaelzer> but for that I'll first kill my sbuild and do a debian/rules build locally in the dir
[09:33] <cpaelzer> I hope that this hangs as well then
[09:33] <mitya57> You can use the already built files
[09:34] <cpaelzer> this is the most default sbuild setup - not sure if it leaves something around if I kill it now
[09:34] <mitya57> You can chroot to it?
[09:34] <cpaelzer> already searching the id
[09:37] <cpaelzer> hrm the mountpoint it had in the buildlog is gone
[09:37] <cpaelzer> and I don't want it to still hang with the sbuilds hanging processes
[09:37] <cpaelzer> even cleanup is not set and it said it didn't
[09:37] <cpaelzer> weird
[09:37] <cpaelzer> but that reproduces pretty fast - I should soon have one ready
[09:39] <cpaelzer> making build deps and all that avail ...
[09:39] <cpaelzer> I'll ping you then mitya57
[09:39] <cpaelzer> once ready or once I've given up to screw my system into a non working state :-)
[09:40] <mitya57> cpaelzer, thanks once again for your efforts :)
[09:40]  * cpaelzer has a mainframe heart
[09:40] <mitya57> cpaelzer, in any case, something like this http://paste.ubuntu.com/24923708/ should allow you to run the test directly
[09:40] <mitya57> (replace PKGBUILDDIR with /path/to/qtmultimedia-opensource-src-5.9.0/)
[09:41] <mwhudson> Unit193: ugh
[09:41] <cpaelzer> ok will let you know then
[09:52] <cpaelzer> ah 12 cpus, now this should be faster :-)
[09:54] <cpaelzer> mitya57: if that is any relive - at least repro-wise - /usr/bin/debuild -eDEB_BUILD_OPTIONS=parallel=12 -us -uc runs just into the same hang
[09:54] <cpaelzer> so all the sbuild is not needed to trigger - ehading to try the test manually now
[09:57] <cpaelzer> mitya57: ok all complete I can trigger jsut the broken test now
[09:58] <mitya57> \o/
[09:59] <cpaelzer> gdb atatched and running
[10:00] <cpaelzer> mitya57: http://paste.ubuntu.com/24923770/
[10:01] <cpaelzer> I might need to make the libs debuggable
[10:01] <cpaelzer> did you have dbgsyms in your ppa enabled?
[10:03] <mitya57> cpaelzer, not much interesting, the dbgsyms won't help.
[10:03] <cpaelzer> mitya57: I'll have a longer lunch break soon'ish - you can then plan what you'd need from me when I'm back
[10:04] <cpaelzer> anything that would help to make that plans to exec immediately?
[10:04] <mitya57> I don't have many ideas :(
[10:04] <mitya57> Maybe my question about valgrind again?
[10:04] <cpaelzer> It is too QT'y for me to have much ideas - most thing look like "Uh desktop?" to me
[10:05] <Laney> cpaelzer: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2835/+packages looks like s390x is hanging on zesty and artful but passing earlier
[10:05] <cpaelzer> I can run it, although I'd not expect a lot from valgrind here - we are not looking for leaks do we?
[10:05] <mitya57> cpaelzer, Or maybe catch writes to stderr and get a stacktrace of the point where the warning is print?
[10:05] <mitya57> *printed
[10:06] <cpaelzer> you mean the one about the tag?
[10:06] <mitya57> Yes
[10:06] <cpaelzer> yeah - can try that after lunch
[10:06] <mitya57> Sure
[10:06] <mitya57> Laney, interesting, with Qt we didn't get anything like this on Zesty.
[10:07] <Laney> although...
[10:07] <Laney> again on y and x the tests are just failing
[10:07] <Laney> mitya57: I guess something different
[10:08] <cpaelzer> valgrind also thinks the program is exited yet hangs
[10:09] <cpaelzer> maybe the main thread went away
[10:09] <cpaelzer> pasting valgrind log for you and then back after lunch
[10:09] <cpaelzer> mitya57: http://paste.ubuntu.com/24923957/
[10:09] <cpaelzer> if we want other valgrind tools later let me know
[10:12] <mitya57> I would expect some invalid read/write warnings right before that QWARN, but there are none
[10:15] <mitya57> cpaelzer, a question for after lunch: can you edit /usr/lib/s390x-linux-gnu/qt5/qml/QtTest/TestCase.qml? Maybe some debug prints there would give more information
[10:21] <Judge> Hi everyone. How can I see how an application in an Ubuntu package was compiled?
[10:22] <Judge> ... or configured for compilation?
[10:24] <pitti> Judge: easiest is to check the build log
[10:26] <pitti> e. g. https://launchpad.net/ubuntu/+source/cockpit -> select version -> select architecture -> buildlog
[10:32] <xnox> Judge, pull-lp-source $srcpackage -> read debian/rules that should clearly show any non-default options.
[10:32] <xnox> and patches applied from debian/patches
[10:33] <Judge> pitti: Perfect, thanks
[11:04] <cpaelzer> mitya57: is there anything in qt like a "set -x" in shell?
[11:05] <mitya57> good question
[11:06] <mitya57> *maybe* QT_FATAL_WARNINGS=1
[11:07] <mitya57> But with that variable it will fail on the "JIT is disabled for QML. Property bindings and animations will be very slow." warning
[11:07] <Unit193> mwhudson: Thanks for looking into it. :>
[11:10] <mitya57> cpaelzer, the debug symbols in my PPA are enabled, so you can install libqt5core5a-dbgsym and break on QMessageLogger::warning
[11:11] <mitya57> cpaelzer, but first please tell me if you can edit /usr/lib/s390x-linux-gnu/qt5/qml/QtTest/TestCase.qml
[11:12] <cpaelzer> mitya57: already adding the 7th debug statement
[11:12] <mitya57> haha
[11:13] <mitya57> cpaelzer, for reference, this is how successful test output looks like: http://paste.ubuntu.com/24924174/
[11:14] <mitya57> It somehow passes for linear -> linear and linear -> cubic, but does not like linear -> logarithmic even though it is very similar.
[11:15] <cpaelzer> the row object is non existant in the error case
[11:15] <cpaelzer> the subsequent access to an element under that object makes it hang
[11:15] <cpaelzer> it doesn't reach the line afterwards
[11:15] <cpaelzer> is there a "is_defined" or anything like it?
[11:16] <cpaelzer> might need to skip the whole thing
[11:16] <cpaelzer> in case it is not existing
[11:16] <mitya57> try “foo !== undefined”
[11:16] <cpaelzer> but also - why is this arch dependent
[11:16] <mitya57> it may be endianness dependent, as s390x is the only big endian arch in Ubuntu
[11:17] <cpaelzer> code uses "[11:17] <cpaelzer> will go with that
[11:17] <mitya57> yes, !== is the opposite to [11:18] <cpaelzer> seems reasonbale :-)
[11:18] <cpaelzer> it goes into table[index] and gets an undefined
[11:18] <cpaelzer> so isn't that an out-of-bounds in some way
[11:18] <cpaelzer> need to check what that table holds
[11:21] <mitya57> right
[11:22] <cpaelzer> seems to hold about 100 entries (the tests parameters I guess)
[11:22] <cpaelzer> but on index 10 it breaks
[11:22] <cpaelzer> from the good test is the order of the testcases up to that the same?
[11:23] <mitya57> Yes, the same
[11:23] <cpaelzer> -1.0 from linear to logarithmic
[11:23] <cpaelzer> that is what we would expect
[11:23] <mitya57> cpaelzer, the table should contain the entries defined in tst_qdeclarativemultimediaglobal.qml from line 68
[11:23] <mitya57> yes
[11:24] <mitya57> cpaelzer, what is table.length?
[11:25] <mitya57> It should be 88 if I count right.
[11:25] <cpaelzer> 88
[11:25] <cpaelzer> all index above 10 are undefined
[11:26] <cpaelzer> I can "finish" the tests by skipping
[11:26] <cpaelzer> mitya57: http://paste.ubuntu.com/24924216/
[11:29] <mitya57> cpaelzer, and what does that print?
[11:30] <cpaelzer> just a sec, modifying the testcase def to see its influence
[11:31] <cpaelzer> mitya57: http://paste.ubuntu.com/24924234/
[11:31] <cpaelzer> that is with two tests taken out of the def
[11:32] <cpaelzer> and it proves it is not the definition of the case
[11:32] <cpaelzer> but always test #10
[11:32] <cpaelzer> so I have a table of length 88 that I can only access 0-9
[11:33] <cpaelzer> the other issues might just as well be such out of bounds access
[11:33] <mitya57> cpaelzer, that is very strange, but also very interesting
[11:34] <cpaelzer> and it seems it can survive the first out of bounds - asnering with an undefined object
[11:34] <cpaelzer> but the access to an element  of that undefined object then kills it
[11:34] <cpaelzer> it creates the QWARN we saw and hangs on there
[11:37] <cpaelzer> mitya57: the fact that these lists are broken might be arch specific (maybe endiness as you suggested) - and the other part that the error hangs might be whatis new in artful
[11:37] <mitya57> cpaelzer, if you change the order of tests in tst_qdeclarativemultimediaglobal.qml, is behavior the same?
[11:37] <cpaelzer> mitya57: yes
[11:37] <cpaelzer> mitya57: always #10
[11:37] <cpaelzer> mitya57: so it depends on size if anything
[11:40] <cpaelzer> mitya57: http://paste.ubuntu.com/24924267/
[11:40] <cpaelzer> updated debug code
[11:41] <mitya57> cpaelzer, minor nit: you need to wrap the two lines after “if (!row.tag)” in {...} otherwise the second line does not belong to if.
[11:41] <cpaelzer> it is wrapped in the updaet
[11:41] <cpaelzer> update
[11:42] <cpaelzer> I got that a few minutes ago
[11:42] <mitya57> No…
[11:42] <cpaelzer> ah this one
[11:42] <cpaelzer> yeah same logic - right
[11:42] <mitya57> I think we already have enough material that I can report to Qt upstream.
[11:43] <cpaelzer> yeah that is the only thing that comes to my mind
[11:43] <cpaelzer> mitya57: let me make updates diffs and output
[11:43] <cpaelzer> that you can then report
[11:43] <mitya57> But maybe it will be a good idea to try creating a normal array and checking if indices >=10 work there.
[11:43] <cpaelzer> mitya57: you can write some basic code that I can run while I collect the logs
[11:43] <mitya57> cpaelzer, try adding this somewhere:
[11:43] <cpaelzer> mitya57: be aware that it might dpeend on the size of the elements
[11:44] <mitya57> I think it is an linked list rather than a vector
[11:44] <cpaelzer> what ot add somewhere?
[11:45] <mitya57> So how about this? var a = [0,1,2,3,4,5,6,7,8,9,10,11]; warn(a[10])
[11:47] <mitya57> and also warn(a["10"])
[11:48] <mitya57> When you use “for (var i in array)” construct, i is a string rather than a number
[11:48] <mitya57> cpaelzer, ^^
[11:49] <cpaelzer> yeah just on that
[11:49] <cpaelzer> I found iteration examples and will use those
[11:50] <cpaelzer> just a fe wmins
[11:50] <mitya57> Ok
[11:50] <cpaelzer> for (var i = 0; i < states.length; i++)
[11:50] <cpaelzer> like that is the recommende daccess
[11:51] <cpaelzer> That is it mitya57
[11:51] <cpaelzer> let me send latest diff and output
[11:51] <cpaelzer> the fix becomes clear now
[11:51] <mitya57> cpaelzer, In this case i would be an integer. But in the TestCase.qml index is a string. *That* might be broken.
[11:51] <cpaelzer> http://paste.ubuntu.com/24924309/ http://paste.ubuntu.com/24924307/
[11:52] <cpaelzer> mitya57: look at the arr iteration
[11:52] <cpaelzer> with the for i in it is broken as soon as it is double digit
[11:52] <cpaelzer> and with the alternative iteration on numbers it works
[11:52] <mitya57> Oh oh oh we found the bug!
[11:52] <cpaelzer> yeah
[11:52] <mitya57> Thanks a lot!
[11:52] <cpaelzer> I'll code up the fix for this case and try with that
[11:52] <cpaelzer> you likely can apply that to about everywhere you block then
[11:53] <mitya57> I think I can try to write a patch myself.
[11:54] <cpaelzer> fix: http://paste.ubuntu.com/24924317/ - good case log http://paste.ubuntu.com/24924318/
[11:54] <cpaelzer> mitya57: done
[11:54] <mitya57> \o/
[11:54] <cpaelzer> mitya57: but as I said this has to be fixed in many places for sure - maybe way more than the few hangs you had
[11:55] <cpaelzer> mitya57: you can use all the output I pastebinit'ed before as example on your upstream contrib then
[11:55] <mitya57> Either I or Qt upstream should figure out why array["10"] does not work — it should be supported
[11:55] <cpaelzer> I think I reply our IRC log of the last hours onto the ML so that nobody spends time about thinking what might be wrong on LP-infra or s390x
[11:55] <cpaelzer> mitya57: are you ok with that?
[11:56] <mitya57> cpaelzer, OK!
[11:56] <mitya57> But I still have no idea why this bug does not occur on Debian s390x
[11:56] <cpaelzer> array["10"] really might be the place where endieness hits
[11:56] <cpaelzer> I assume the warning for them is not having this blocking behaviour
[11:56] <cpaelzer> mitya57: do they have the QWARN in their log?
[11:57] <mitya57> cpaelzer, no
[11:57] <cpaelzer> uuuh
[11:57] <cpaelzer> ok well, I need to go on to the next package
[11:57] <cpaelzer> glad I could help that far mitya57
[11:57] <mitya57> cpaelzer, sure, your debugging helped me a *lot*
[12:10] <cpaelzer> back to my beloved systemd/ntp error again ...
[12:29] <mitya57> cpaelzer, tsimonq2: FYI https://bugreports.qt.io/browse/QTBUG-61579
[12:30] <cpaelzer> thanks for the info mitya57
[15:05] <nacc> xnox: right, I understand that -- but it doesn't *always* do that, even then (it seems).
[15:06] <slangasek> infinity: #ubuntu-meeting?
[15:55] <juliank> xnox: Does it even make sense that you self-assign the apt tasks when I already uploaded everything? Seems a bit odd ;)
[15:56]  * juliank should probably have assigned that some time ago.
[15:56] <juliank> But it certainly makes sense for you to do the u-u part :)
[15:58] <xnox> juliank, yes it is odd.
[15:58] <xnox> juliank, i was doing that, such that people keep asking me for updates on it.
[15:58] <xnox> juliank, and such that it disappears from many reports of un-assigned bugs.
[15:58] <xnox> thus it's mostly cosmetic change to pacify reports.
[15:58] <juliank> :)
[16:00] <juliank> We should also open another bug for improved reliability of network availability (apt-helper wait-online and automatic restart of service).  I think I know what to write, but we need a tracking bug for that anyway.
[16:01] <juliank> I guess Ill do that once I'm on my laptop again.
[16:02] <juliank> xnox: We especially have to pick a nice exit value for the helper.
[16:02] <juliank> ;9
[16:02] <juliank> exit(42) or something
[16:25] <rbasak> slangasek: would you mind commenting on bug 1690228 please? I remember you saying that you considered ethtool to be deprecated, but I'm not sure I understand exactly why.
[16:25] <rbasak> (or did I misunderstand?)
[16:47] <nacc> rbasak: fyi, not sure if you saw, but folks are saying LP: #1590799 is not actually fixed
[16:48] <rbasak> Thanks nacc
[16:48] <rbasak> tinoco: ^ could you investigate please?
[16:49] <tinoco> rbasak: sure, adding to my list (next week most likely)
[16:49] <nacc> tinoco: thanks -- had a user in #ubuntu also hit it (most likely)
[16:49] <tinoco> i'm afraid it is another race (not the initial one) hopefully i'll reproduce (or will just ask for systemd logs)
[16:49] <rbasak> Thanks. Yeah it looks like it may be multiple bugs.
[16:51] <juliank> xnox: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1699850
[16:53] <juliank> Summary: Wait for up to 30 s for network connectivity, and retry every 15 minutes if not online yet.
[16:55] <xnox> juliank, this might be easier on ubuntu, than on debian. in e.g. artful. by calling networkd-wait-online.
[16:56] <juliank> xnox: That might have network online but no internet connectivity or stuff. The apt-helper will check if the hosts we actually need are online.
[16:59] <juliank> xnox: The pseudo code is effectively optimized for the case where the first host is reachable, BTW.
[17:00] <juliank> I assume there's no non-blocking alternative to getaddrinfo()?
[17:01] <juliank> (Then we could just issue all DNS requests at once, potentially reducing wait time if first host is permanently offline - but how likely is that anyway)
[17:03] <mitya57> What is the status of checkbox-converged? Currently it seems to be the only package in main still using ubuntu-ui-toolkit. Will it be ported?
[17:03] <juliank> xnox: I'm unsure if we should just wait for one remote host, or maybe a majority
[17:04] <juliank> If you configured localhost or something it might come up to early
[17:04] <juliank> I guess we can exclude loopback addresses, though
[17:05] <juliank> So, exclude 127.* and the IPv6 equivalent, and 1 successful connection, and we should be good to go IMO
[17:07] <juliank> We'll try http hosts on port 80 or specified, https on 443 or specified, and either ignore the other ones (ftp, rsh, torrent, whatever) or just try 80 or something (or well, only DNS)
[17:11] <slangasek> rbasak: what is this about it not being installed by default?  it's in the server and cloud-image seeds
[17:13] <slangasek> rbasak: I think we may have talked about moving it out a layer or two in the packagesets from where it was earlier, but doesn't seem to have been moved any farther than that
[17:23] <juliank> tkamppeter: I was looking for you recently. I got a Brother HL-2130 and that's working mostly fine with HL-2140 drivers (hpijs-pcl5e or hl2150, slightly different rendering). Maybe it's worth it adding them as HL-2130 ones too?
[17:23] <nacc> slangasek: aiui, it shouldn't matter that user is netbooting to install ubuntu server vs. iso installing, as far as the packages that get installed, right?
[17:23] <juliank> tkamppeter: You might have seen a message from me in a Debian bug about the device
[17:24] <juliank> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635157
[17:25] <juliank> Stuff like manual duplex is not working (duplex checkbox does nothing), and one of the drivers fails at the highest setting (1200x600), but apart from that, it seems to work fine.
[17:26] <juliank> (That's why I bought it in the first place, thanks to the Arch wiki, and it only costing me 25€ used with a toner with unknown capacity included)
[17:36] <nacc> slangasek: rbasak: ok, that's the root cause of this bug, I'll respond in-bug
[17:42] <slangasek> nacc: the netboot image isn't a "server" image, it's a generic "d-i" image, so comes with no default task selection
[17:49] <gpiccoli> nacc, slangasek, rbasak : just commented there on LP 1690228
[17:49] <gpiccoli> Not sure if got mirrored already...
[17:49] <gpiccoli> I'm here too, if you prefer more dynamic conversation than launchpad posts heh
[17:50] <gpiccoli> slangasek, so what is a generic "d-i" image?
[17:50] <gpiccoli> If iproute2 got installed, why ethtool shouldn't be, for example?
[17:55] <cjwatson> iproute2 is in the minimal set (i.e. what debootstrap installs) but ethtool isn't; that's not a statement of intent, just an observation of current reality
[17:56] <cjwatson> but I would hope developers would think hard before adding feature creep to minimal
[17:57] <cjwatson> it isn't in general intended for the output of debootstrap to contain everything you might need to operate a server
[17:58] <cjwatson> and personally I don't think it's a bug when the result of a netboot install is missing just about any package you might name; netboot installs are intended to be absolute bare minimum, and you can add more packages by preseeding or whatever
[18:04] <gpiccoli> cjwatson, thanks! I partially agree with you
[18:04] <gpiccoli> I agree with the part: " I don't think it's a bug when the result of a netboot install is missing just about any package you might name"
[18:04] <gpiccoli> Problem is that: after the boot, how could I fix this, I mean, install this package, if I have no network?
[18:04] <gpiccoli> hehehe
[18:05] <gpiccoli> egg/chicken issue...you might need the troubleshoot tooling to allow you fix network in order to use machine
[18:05] <cjwatson> Except if netboot works at all then by definition it can install things from the network.
[18:05] <cjwatson> So that isn't valid.
[18:06] <gpiccoli> Sometimes, the 'issue' is on switch you don't have access, like it's refusing some configuration your NIC sends...ethtool might come handy to fix this, by configuring NIC
[18:06] <cjwatson> It must always be possible to nominate additional packages using preseeding, at the very least.
[18:06] <gpiccoli> Yes, makes sense
[18:06] <gpiccoli> but then, we can raise the follow-up discussion: would it make sense to have ethtool on installer itself?
[18:07] <cjwatson> I agree it's useful to have some minimal set of configuration utilities; every additional package has incremental cost, so it's a judgement call.
[18:07] <gpiccoli> For netboot installers, I do believe we need it. If not, we might not be able to progress the installation
[18:07] <gpiccoli> cool cjwatson, agree with you
[18:07] <gpiccoli> let's what will be this judgement heheh
[18:08] <cjwatson> If it's needed in d-i, then I think it needs some thought to define exactly what the possible requirements might be in order that netcfg could support them.
[18:08] <cjwatson> Just the tool being present is only of limited use.
[18:08] <cjwatson> Note that netcfg already contains an ethtool-lite.
[18:09] <cjwatson> Which is very cut-down and I think mostly read-only; but I think that indicates a design direction, i.e. just have netcfg implement the ioctls it needs to do the job rather than shipping ethtool.
[18:10] <cjwatson> (netcfg's ethtool-lite is mostly just for detecting link presence at the moment, I think.)
[18:11] <nacc> slangasek: ack, just commented to the same effect after thinking about it in the bug
[18:15] <gpiccoli> oh, i wasn't aware of this ethtool-lite
[18:18] <cjwatson> Like I say it's mostly just link presence, but I think it would be weird to end up in a situation where we had both ethtool-lite and ethtool in the installer - it would indicate not having thought things through globally, IMO.
[18:23] <gpiccoli> exaclty, it makes sense
[18:23] <gpiccoli> no need for ethtool0lite if we can have the full ethtool
[18:23] <gpiccoli> By the way, how do I invoke ethtool-lite cjwatson ?
[18:23] <gpiccoli> during installer, I mean
[18:24] <cjwatson> also no need for ethtool if we work out the relevant bits and add them to ethtool-lite.  ethtool has a bunch of quite sophisticated stuff that won't be needed during installation.
[18:25] <cjwatson> (or add them to netcfg directly.  whatever.)
[18:25] <cjwatson> I don't recall, sorry.
[18:25] <cjwatson> Look at the netcfg source package
[18:26] <gpiccoli> yes, we might add the features to ethtool-lite..could be difficult though to map all stuff we need
[18:28] <nacc> gpiccoli: but for making a core change that is absolutely what is going to be required
[18:28] <nacc> gpiccoli: it can't be hand-wavy we need ethtool because we need ethtool :)
[18:31] <cjwatson> Yep.  And in order to add installer UI it will be necessary to define the specific features that are needed.
[18:32] <cjwatson> Seems that if we ended up with a system where we knew that some people were going to have to drop to a shell to use ethtool in the middle of the installation, we'd only have done half the job at best.
[18:32] <gpiccoli> "it can't be hand-wavy we need ethtool because we need ethtool" <- what do we need to justify here?
[18:32] <gpiccoli> Help me wording the request hehehe
[18:33] <sarnold> a list of features that are preventing you frmo installing? :)
[18:33] <cjwatson> Specific features that are currently provided only by ethtool that might be strictly required in order to get a system's network up.
[18:33] <gpiccoli> for me, miss a tool to configure NICs in a small installer that only can work if network is fine, is a dangerous thing
[18:33] <cjwatson> Most systems don't require ethtool.
[18:33] <nacc> gpiccoli: just be specific as to what you can't do now
[18:33] <gpiccoli> cjwatson and sarnold, thanks a lot! I'll raise such list
[18:33] <nacc> gpiccoli: it can't be a theoretical list (IBM historical problem :)
[18:33] <cjwatson> Try to keep it minimal.
[18:33] <gpiccoli> great nacc, it's a good point!
[18:33] <cjwatson> Don't just go over the man page and enumerate everything that looks kind of useful.
[18:34] <cjwatson> It has to be actual things that definitely hit real systems.
[18:34] <gpiccoli> I'll keep minimal, of course I won't say "I cannot see statistics of how much packets delayed more than X ms, so I cannot install" hahah
[18:34] <cjwatson> And I would recommend a solution-neutral problem statement.
[18:35] <gpiccoli> yes, I have a use case already, for i40e. i'll improve it
[18:35] <gpiccoli> solution-neutral aka not say "I-need-ethtool-please" ?
[18:35] <gpiccoli> heheh
[18:35] <cjwatson> In each case, there might be some other sensible solution that doesn't involve people having to drop to a shell mid-install to use ethtool: kernel sorting it out by default, installer UI to configure things, embedding a couple of ioctls in some other tool, ...
[18:36] <cjwatson> Having to manually configure network devices is pretty 1990s and we should be able to do better.
[18:36] <gpiccoli> ok cjwatson, it does make sense. i got your point here, all you folks said are really valid and I'll take into account. Thanks a lot for the great feedback
[18:36] <cjwatson> Thanks for listening :)
[18:36] <gpiccoli> 90s was the best, I'm oldschool =D
[18:37] <gpiccoli> Yw, thanks for your patience!
[23:10] <mwhudson> watching vim build is hard on the eyes
[23:11] <nacc> mwhudson: fyi, LP: #1571967 seems relevant to our earlier *.lxd discussions
[23:12] <nacc> mwhudson: i've yet to actually get what we both wanted to 'just work', but stgraber's suggestion in there does make ssh work, at least
[23:14] <mwhudson> wow that ssh suggestion is both awesome and terrible :)
[23:15] <nacc> mwhudson: :)
[23:15] <Unit193> mwhudson: Oh hi!  Are you active in the server team?  Do you know why python-moinmoin is needed in main?
[23:15] <mwhudson> Unit193: i'm foundations theses days, and, no
[23:16] <Unit193> OK.
[23:16] <mwhudson> doesn't seem to have any rdeps in main though...
[23:16] <mwhudson> so i guess it's seeded?
[23:16] <nacc> mwhudson: not that i can see
[23:19] <Unit193> (LP 586492 didn't say specifically why it was needed.)
[23:20] <nacc> Unit193: oh good thinking -- if moin can be in universe, then parsedatetime would migrate?
[23:21] <Unit193> nacc: They'd both have to go to universe, but yep.  And I don't see why moin is in main anyway.
[23:22] <Unit193> 22371 seems to be as close as it gets, discusses main.
[23:22] <nacc> Unit193: yeah that's the bug i was just reading
[23:22] <nacc> slangasek: --^ are you able to help us determine this?
[23:23] <nacc> Unit193: I *wonder* if the ubuntu wiki or something is moin
[23:24] <nacc> Unit193: and so it's manually being held in main by request
[23:24] <Unit193> nacc: Ubuntu wiki is moinmoin.
[23:24] <nacc> Unit193: that might be why?
[23:24] <nacc> Unit193: presumably we'd want to support our own infra :)
[23:26] <Unit193> nacc: Heh, well by the name I thought it was a python module for interacting with it, would have expected the source to be 'moinmoin'.  Didn't look too closely at that.  We should just move to mediawiki to solve this then! :P
[23:27] <nacc> Unit193: I am curious where that gets expressed. I wonder if it's an AA thing
[23:27] <Unit193> nacc: So, this sounds like a problem then.
[23:27] <nacc> Unit193: ok, moin shows up here: http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.artful/all+extra.sources
[23:29] <nacc> Unit193: foudn it ... supported-misc-servers seed http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.artful/supported-misc-servers.seed
[23:29] <nacc> now why didn't seeded-in-ubuntu tell me that?
[23:29] <Unit193> Because it doesn't like you.
[23:30] <Unit193> nacc: But yes, we did find out why.  Now, how does one move forward?
[23:31] <nacc> Unit193: i think we need to look at MIR'ing python-future -- that was the revdep, right?
[23:31] <Unit193> Yeah, new parsedatetime also builds python3-parsedatetime too.
[23:34] <infinity> MIRing python-future seems like a sane thing to do.
[23:35] <infinity> Actually a bit shocked it's avoided main this long.
[23:35] <nacc> infinity: yeah, i think it seems reasonable
[23:35] <nacc> Unit193: do you want to file the MIR?
[23:35] <Unit193> nacc: That'd be better coming from a team member, wouldn't it?
[23:36] <nacc> Unit193: well, it was your upload request :)
[23:36] <nacc> Unit193: i can file it, though, probably not til tmrw
[23:38] <Unit193> nacc: Correct, but I'm not in the team so can't subscribe them to the bug mail, and making a MIR request on behalf of a team that I've not discussed it with seems bad form.
[23:38] <nacc> Unit193: which team do you mean?
[23:38] <Unit193> Server team.
[23:38] <nacc> Unit193: oh, i am :)
[23:39] <nacc> Unit193: i am in that team, i mean
[23:40] <nacc> infinity: is it normal that seeded-in-ubuntu doesn't show the misc-server seed? e.g., above it didn't show that python-moinmoin and it's not showing me, e.g. that src:nagios3 has several packages seeded in supported-misc-servers
[23:42] <Unit193> nacc: FYI, this is all for the new gcalcli, which my sponsor is interested in pushing it to unstable rather than experimental.  It was ported to py3.
[23:43] <nacc> Unit193: sure, but this other revdep path shows that the new parsedatetime would have gotten stuck anyways (and so python-future needs the promotion). So given that, I'll file the MIR :)
[23:44] <Unit193> nacc: Right, which was why I wasn't too stressed about my request for it.
[23:44] <infinity> nacc: It's normal that seeded-in-ubuntu isn't a perfect tool, I believe.  I'm sure the folks who run it would appreciate patches.
[23:44] <Unit193> I thought all Ubuntu tools were perfect and ported to py3. :3
[23:45] <infinity> Unit193: Fairly sure neither of those things is true.
[23:45] <Unit193> infinity: Yep. :)
[23:45] <Unit193> (https://bugs.launchpad.net/ubuntu/+source/ubuntu-dev-tools/+bug/1099537)
[23:46] <nacc> infinity: sure, i just noticed that particular quirk. I'm happy to work on it! :)
[23:46] <nacc> infinity: and sometimes what i perceive as a quirk is really PEBKAC
[23:46] <infinity> nacc: I have a 100% track record for blaming myself when the software's at fault, and vice versa.
[23:47] <nacc> infinity: heh
[23:48] <slangasek> nacc, Unit193, infinity: FTR, branch archaeology tells me moin is grandfathered into main from the original server seed and that this was last revisited only in 2009 when we moved it from server CD to supported.  It may be worth asking IS and/or the product manager if it still belongs
[23:48] <nacc> slangasek: yep, i've filed a note to review that whole misc-servers seed
[23:48] <nacc> slangasek: as there are some other old entries in there
[23:50] <Unit193> Might be nice to get pdt into universe, yeah.
[23:51] <nacc> Unit193: yep, i've made a trello card (our newer tracking mechanism) for server and i'll review it with the team
[23:51] <Unit193> nacc: Thanks!
[23:51] <nacc> https://trello.com/c/rr2vMcsr for documentation publicly
[23:58] <nacc> rbasak: doing some more refactoring to `git ubuntu build` but i should have a pristine-tar version working tmrw, i think