=== athairus is now known as afkthairus
=== shuduo is now known as shuduo-afk
=== shuduo-afk is now known as shuduo
=== shuduo is now known as shuduo-afk
=== vrruiz_ is now known as rvr
[11:28] <hikiko> slangasek, https://paste.ubuntu.com/15537883/ that's the "crash"
[11:28] <hikiko> xserver is killed
[11:36] <hikiko> maybe xserver is killed by systemd (?)
[11:37] <hikiko> slangasek, that's my syslog http://pastebin.com/VJLsg8Ce
[11:37] <hikiko> (the end of it)
[12:23] <jdstrand> cjwatson: hey, fyi, missing parenthesis: bug #1562827
[12:23] <ubottu> bug 1562827 in debmirror (Ubuntu) "Global symbol "$subdir" requires explicit package name at /usr/bin/debmirror line ..." [Undecided,New] https://launchpad.net/bugs/1562827
=== francisco is now known as Guest15919
=== francisco is now known as Guest32270
=== jgrimm-afk is now known as jgrimm
=== mnepton is now known as mneptok
[17:32] <rharper> are there any packages with daemons which have had to transition their service name (/etc/init.d/<name>) ?  I'm looking for examples, specifically if one can create aliases to aid the transition (existing scripts may refer to one name would fail after upgrading and the service now has a new name)
[17:36] <nacc> rharper: not sure if it helps, but would dpkg-maintscript-helper's dir_to_symlink help? (or possiby the other direction)
[17:37] <rharper> nacc: I'm looking for precedence actually
[17:37] <rharper> I can create the symlink in any number of ways
[17:37] <rharper> but currently find /etc/init.d -type l returns nothing;
[17:37] <rharper> so I don't just want to start doing something without some discussion;
[17:37] <nacc> oh i see
[17:38] <rharper> rbasak already responded to the squid3 bug as someone raised concern that the squid package now uses service-name: squid , instead of squid3;
[17:38] <nacc> right, i was just trying to think of other daemons that might have the version in the name
[17:38] <rharper> the two in-archive cases, squidGuard and squid-deb-proxy are handled AFAICT (they both work post upgrade after fixing up one of the squid postinst scripts w.r.t the name of the service) ;
[17:39] <rharper> nacc: heh, apache2
[17:39] <rharper> but that's a different thing entirely
[17:39] <nacc> yeah :)
[17:51] <nacc> slangasek: luckily there's (alphabetically speaking) a big chunk of just rebuilds coming up, as they are all pear/pecl packages
[18:09] <slangasek> nacc: did you see the follow-up on the phoronix-test-suite bug?
[18:09] <slangasek> (just now)
[18:13] <slangasek> ah, yes you did ;)
[18:18] <nacc> slangasek: yep, will update it, thanks
=== _salem is now known as salem_
=== salem_ is now known as _salem
=== _salem is now known as salem_
=== salem_ is now known as _salem
[21:22] <sarnold> congrats mwhudson :)
[21:23] <mwhudson> sarnold: :-)
[21:41] <nacc> mwhudson: congrats!
[21:45] <nacc> woo, down to 325 packages to modify for php5 dependencies ...
[21:47] <sarnold> \o/
[21:47] <nacc> technically < 300 probably, based upon what's still not hit the reverse-dependencies service (and a set of ~30 auto-rebuilds just submitted)
[21:47] <nacc> i'm learning to hate all php code quite quickly, though :)
[21:49] <jgrimm> \o/
[22:07] <sarnold> ureadahead seems unhappy, this is the second one of these i've seen today https://launchpadlibrarian.net/250163458/UbiquitySyslog.txt
[22:07] <sarnold> e.g. ureadahead:/usr/lib/python3.5/gzip.py: Error retrieving chunk extents: Operation not supported
[22:25] <tsimonq2> is there a way I can use an schroot of archs like armhf, arm64, ppc, etc. on my amd64 machine that I'm on now?
[22:26] <slangasek> nacc: looks like the following packages have failed their no-change rebuild, I haven't looked to see why: phing php-apigen php-console-table phpdox
[22:26] <nacc> slangasek: phing's is weird
[22:26] <nacc> https://launchpadlibrarian.net/250245945/buildlog_ubuntu-xenial-amd64.phing_2.13.0-2build1_BUILDING.txt.gz
[22:26] <nacc> there's a stray parentheses in that help2man command?
[22:27] <tsimonq2> cyphermox: I've been talking to you, would you happen to know an answer ot my question? :)
[22:27] <tsimonq2> *to
[22:27] <nacc> tsimonq2: mk-sbuild takes arch optoins
[22:27] <nacc> tsimonq2: i've had ... mixed results figuring them out :)
[22:27] <tsimonq2> nacc: oh, any notable quirks?
[22:28] <slangasek> nacc: buggy regexp that doesn't cope with Ubuntu-style version numbers
[22:28] <nacc> slangasek: ok, it built fine here with release and proposed pockets, so not sure why it failed in lp
[22:28] <slangasek> nacc: did you update debian/changelog for your test build?
[22:29] <tsimonq2> and on the FTBFS tracker, bug 1547395 is linked for libquvi, but it really points to bug 1546957 , that should be linked instead
[22:29] <slangasek> (he asks, rhetorically ;)
[22:29] <ubottu> bug 1547395 in luasocket (Ubuntu) "MIR: new dependencies for libquvi-scripts / libquvi" [Undecided,New] https://launchpad.net/bugs/1547395
[22:29] <ubottu> bug 1546957 in lua-lpeg (Ubuntu) "[MIR] lua-lpeg, needed by nmap" [High,Incomplete] https://launchpad.net/bugs/1546957
[22:29] <nacc> slangasek: ah, :)
[22:29] <cyphermox> tsimonq2: it depends, arm might work (but slowly), and I don't recall ever making ppc work properly in a schroot unfortunately, but I didn't really try that hard
[22:30] <tsimonq2> cyphermox: thanks, I'll play with it :)
[22:30] <cyphermox> tsimonq2: if you want to make it easy on yourself to get the chroots, I use sbuild-launchpad-chroot which downloads the tarballs straight from launchpad
[22:30] <nacc> slangasek: apologies, i'll retest here
[22:32] <tumbleweed> win 31
[22:35] <nacc> slangasek: looks to be thes ame issue for php-apigen, and two of the others is a missing php-mbstring dep, will fix and submit bugs
[22:38] <slangasek> nacc: build failure also for php-finder-facade
[22:38] <nacc> slangasek: yep that's also mbstring related
[22:38] <tsimonq2> cyphermox: oh cool thanks :)
[22:42] <mwhudson> are there any tricks for lts->lts testing?
[22:42] <mwhudson> i guess i can just create a trusty lxd and run do-release-upgrade in it...
[22:42] <stgraber> not really, make a snapshot before and use do-release-upgrade (straight dist-upgrade isn't supported)
[22:43] <stgraber> you may run into container-specific failures but we're still interested in those (we have fixed a few packages that try to create device nodes and other weird things on upgrade in the past)
[22:48] <cyphermox> mwhudson: if you want desktop instead of server, be aware that there is bug 1555237
[22:48] <ubottu> bug 1555237 in ubuntu-release-upgrader (Ubuntu) "Upgrade from 14.04.4→ 16.04 dies midway taking out the session." [Critical,In progress] https://launchpad.net/bugs/1555237
[22:49] <mwhudson> stgraber: extracting 'xenial.tar.gz'
[22:49] <mwhudson> Must be connected to a terminal.
[22:49] <mwhudson> ?
[22:49] <mwhudson> i guess i can ssh into the container
[22:49] <stgraber> mwhudson: or run things inside a "script /dev/null" session
[22:49] <mwhudson> cyphermox: nah, i don't do anything users interact with, remember? :)
[22:49] <stgraber> some things indeed are picky about having a visible backing pts device
[22:49] <cyphermox> mwhudson: just making sure ;)
[22:49] <mwhudson> stgraber: this is the screen that do-release-upgrade is launching, i think?
[22:50] <mwhudson> cyphermox: yeah, thanks for the tip :)
[22:51] <stgraber> mwhudson: yep
[22:51] <stgraber> mwhudson: screen is unhappy when it can't find its /dev/pts device (in this case because the pts in question is in the host namespace)
[22:52] <stgraber> mwhudson: I made a hackish glibc which fixed that but it needs a bit more work to be sane :)
[22:52] <mwhudson> heh heh
[22:52] <mwhudson> the whole tty/pty business is ... on the complicated side
[22:52] <stgraber> mwhudson: tl&dr is that ttyname() returns an empty string when the controling tty (/proc/self/fd/0) can't be dereferenced, rather than returning the non-derefed (yet perfectly working) path
[22:53] <tsimonq2> !info libcommons-net-java-doc
[22:53] <ubottu> Package libcommons-net-java-doc does not exist in wily
[22:53] <tsimonq2> !info libcommons-net-java-doc xenial
[22:53] <ubottu> libcommons-net-java-doc (source: libcommons-net-java): Apache Commons Net (API documentation). In component universe, is optional. Version 3.4-2ubuntu2 (xenial), package size 285 kB, installed size 7344 kB
[22:53] <stgraber> infinity: if you're bored and feel like fixing a glibc bug ^ :) otherwise whenever I am bored and feel like hacking on glibc, I may send a patch :)
[22:53] <nacc> slangasek: how would you like to handle php-gnupg? upsream has  apatch that makes it work with php7, but it only passes 33% of the tests. They claim that is true for php5 too. I've not found a log for the php5 build yet
[22:57] <tsimonq2> does libcommons-net-java have a MIR? I'm not seeing one and it would solve the FTBFS for commons-vfs. It's also not in the MIR bugs list. Just confirming either way
[22:59] <slangasek> nacc: I am indifferent to most of these individual packages in universe; anything that doesn't work can be removed or left broken, and if php-gnupg's testsuite isn't /regressing/, that's good enough for me
[22:59] <nacc> slangasek: yeah, it's not regressing afaict, but i am unable to find autopkgtest runs for php5-gnupg to confirm?
[22:59] <slangasek> nacc: then nobody cared enough about the package to set it up for autopkgtest, and I don't think we should care either?
[23:00] <nacc> slangasek: ok i didn't realize it needed that step, but now i recall you setting that flag in a control file, so it all becomes a bit clearer
[23:01] <nacc> slangasek: yep, the old build failed the same amount:
[23:01] <nacc> https://launchpadlibrarian.net/228695259/buildlog_ubuntu-xenial-s390x.php-gnupg_1.3.6-1_BUILDING.txt.gz
[23:03] <nacc> so, was that build done somehow with a flag saying failing the build is ok? as for me on my system, the build fails at that point where not all tests are passed?
[23:15] <nacc> slangasek: ok, those 5 build failures should be rsolved now
[23:36] <mwhudson> hmm running do-release-upgrade under ssh in a screen resulted in the ssh connection dropping
[23:36] <mwhudson> er
[23:37] <mwhudson> hmm running do-release-upgrade under ssh in a *lxd container* resulted in the ssh connection dropping
[23:38] <sarnold> mwhudson: was that a fully-updated 14.04 LTS container? or an "initial install" sort of image? that feels vaguely like a a systemd-logind issue I saw..
[23:38] <mwhudson> sarnold: just whatever lxd launch ubuntu-daily:trusty gets you
[23:38] <sarnold> 1543883
[23:38] <mwhudson> bug 1543883
[23:38] <ubottu> bug 1473800 in systemd (Ubuntu Trusty) "duplicate for #1543883 restarting logind during systemd update causes screen to lock" [Medium,Fix committed] https://launchpad.net/bugs/1473800
[23:38] <sarnold> mwhudson: ah then that's probably got this fix already..
[23:39] <mwhudson> i'd assume so
[23:42] <mwhudson> when i ssh back into the lxd everything seems happy
[23:42] <mwhudson> but it's a bit unsettling
[23:43] <sarnold> very
[23:44] <sarnold> especially since not everyone will think to start the upgrade in a shell or tmux
[23:44] <sarnold> sigh screen..
[23:45] <mwhudson> well do-release-upgrade does that for you
[23:45] <mwhudson> but that dies too
[23:45] <mwhudson> it seems
[23:45] <mwhudson> i guess that's even more unsettling :)