| === 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 | ||
| hikiko | slangasek, https://paste.ubuntu.com/15537883/ that's the "crash" | 11:28 |
|---|---|---|
| hikiko | xserver is killed | 11:28 |
| hikiko | maybe xserver is killed by systemd (?) | 11:36 |
| hikiko | slangasek, that's my syslog http://pastebin.com/VJLsg8Ce | 11:37 |
| hikiko | (the end of it) | 11:37 |
| 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 | 12:23 |
| === 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 | ||
| 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:32 |
| nacc | rharper: not sure if it helps, but would dpkg-maintscript-helper's dir_to_symlink help? (or possiby the other direction) | 17:36 |
| 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:37 |
| 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:38 |
| rharper | nacc: heh, apache2 | 17:39 |
| rharper | but that's a different thing entirely | 17:39 |
| nacc | yeah :) | 17:39 |
| nacc | slangasek: luckily there's (alphabetically speaking) a big chunk of just rebuilds coming up, as they are all pear/pecl packages | 17:51 |
| slangasek | nacc: did you see the follow-up on the phoronix-test-suite bug? | 18:09 |
| slangasek | (just now) | 18:09 |
| slangasek | ah, yes you did ;) | 18:13 |
| nacc | slangasek: yep, will update it, thanks | 18:18 |
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| sarnold | congrats mwhudson :) | 21:22 |
| mwhudson | sarnold: :-) | 21:23 |
| nacc | mwhudson: congrats! | 21:41 |
| nacc | woo, down to 325 packages to modify for php5 dependencies ... | 21:45 |
| 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:47 |
| jgrimm | \o/ | 21:49 |
| 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:07 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| tumbleweed | win 31 | 22:32 |
| 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:35 |
| 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:38 |
| 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:42 |
| 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:43 |
| 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:48 |
| 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:49 |
| mwhudson | cyphermox: yeah, thanks for the tip :) | 22:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:57 |
| 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? | 22:59 |
| 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:00 |
| 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:01 |
| 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:03 |
| nacc | slangasek: ok, those 5 build failures should be rsolved now | 23:15 |
| mwhudson | hmm running do-release-upgrade under ssh in a screen resulted in the ssh connection dropping | 23:36 |
| mwhudson | er | 23:36 |
| mwhudson | hmm running do-release-upgrade under ssh in a *lxd container* resulted in the ssh connection dropping | 23:37 |
| 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:38 |
| mwhudson | i'd assume so | 23:39 |
| mwhudson | when i ssh back into the lxd everything seems happy | 23:42 |
| mwhudson | but it's a bit unsettling | 23:42 |
| sarnold | very | 23:43 |
| sarnold | especially since not everyone will think to start the upgrade in a shell or tmux | 23:44 |
| sarnold | sigh screen.. | 23:44 |
| 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 :) | 23:45 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!