[00:32] <plars> ogra: vorlon: this is a newer image than the one I tested a few weeks ago? I'm at a sprint in Taipei right now btw, so my tz is different from the normal
[00:35] <mwhudson> plars: i'm not sure i remember your tz ever being normal :)
[00:36] <plars> mwhudson: it's all a matter of perspective
[01:35] <vorlon> plars: yes, this is newer, http://cdimage.ubuntu.com/ubuntu-core/16/stable/20181109.4/
[01:55] <plars> vorlon: I'm looking at it now. Do you know what all changed in it? I don't see a fix for the ethernet LED issue yet on rpi3b+, but I know that's not really a regression since 3b+ wasn't supported previously on 16
[01:56] <vorlon> plars: it should be the same as the previous image, just validating that the image still DTRT now that the snaps are promoted to stable
=== JanC_ is now known as JanC
[10:47] <cpaelzer> Hi, I have an odd case and hope somebody might have a hint
[10:48] <cpaelzer> I build in sbuild and it fails on dh_install
[10:48] <cpaelzer> it complains about this
[10:48] <cpaelzer> dh_install
[10:48] <cpaelzer> cp: cannot open 'debian/tmp/usr/lib/x86_64-linux-gnu/libgps.so.24' for reading: Too many levels of symbolic links
[10:48] <cpaelzer> dh_install: cp --reflink=auto -a debian/tmp/usr/lib/x86_64-linux-gnu/libgps.so.24 debian/tmp/usr/lib/x86_64-linux-gnu/libgps.so.24.0.0 debian/libgps24//usr/lib/x86_64-linux-gnu/ returned exit code 1
[10:48] <cpaelzer> but
[10:48] <cpaelzer> it actually is not on insane symlinks
[10:48] <cpaelzer> ls -laF debian/tmp/usr/lib/x86_64-linux-gnu/libgps.so*
[10:48] <cpaelzer> lrwxrwxrwx 1 paelzer paelzer     16 Nov 16 09:48 debian/tmp/usr/lib/x86_64-linux-gnu/libgps.so -> libgps.so.24.0.0*
[10:48] <cpaelzer> lrwxrwxrwx 1 paelzer paelzer     16 Nov 16 09:48 debian/tmp/usr/lib/x86_64-linux-gnu/libgps.so.24 -> libgps.so.24.0.0*
[10:48] <cpaelzer> -rwxrwxr-x 1 paelzer paelzer 630408 Nov 16 09:48 debian/tmp/usr/lib/x86_64-linux-gnu/libgps.so.24.0.0*
[10:48] <cpaelzer> and even more so, if I chroot into the build env and just do the copy command
[10:48] <cpaelzer> then it works
[10:49] <cpaelzer> anyone an idea what I might look for?
[11:16] <cpaelzer> the same build (with the issue described above) works for cosmic, but fails for disco and debian-unstable
[12:42] <cpaelzer> on the above issue with the so not able to be copied - it fails also in launchpad. But it behaves different per archietcture
[12:42] <cpaelzer> ppc fails https://launchpadlibrarian.net/397834496/buildlog_ubuntu-disco-ppc64el.gpsd_3.18.1-1_BUILDING.txt.gz
[12:42] <cpaelzer> s390x works https://launchpadlibrarian.net/397834398/buildlog_ubuntu-disco-s390x.gpsd_3.18.1-1_BUILDING.txt.gz
[12:42] <cpaelzer> they build the same thing
[12:42] <cpaelzer> the same args
[12:43] <cpaelzer> why would one have a different symlink depth ?!?
[12:43] <cpaelzer> ahasenack: I trade the review for your MP for a good idea here :-)
[12:44] <ahasenack> something related to usr-merge?
[12:47] <cpaelzer> I was in the chroot, it works fine
[12:47] <cpaelzer> it almost seems like a racy thing
[12:47] <cpaelzer> that works soon after
[12:48] <cpaelzer> I've thrown it into https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3522/+packages
[12:48] <cpaelzer> soem work some fail
[12:48] <cpaelzer> I'm tempted to believe that on rebuilds they might even work/fail differently
[12:49] <cpaelzer> ahasenack: checked, no usrmerge symlink in that path
[12:49] <ahasenack> cpaelzer: link to a failed build?
[12:50] <ahasenack> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3522/+build/15668073/+files/buildlog_ubuntu-disco-ppc64el.gpsd_3.18.1-1_BUILDING.txt.gz ?
[12:50] <ahasenack> (just got an email about that one)
[12:52] <ahasenack> cpaelzer: perhaps you will have to do some debugging builds. Like overriging dh_install and adding a ls -la to it, something like that
[12:53] <ahasenack> or what's that other command that shows all path components, I forgot its name
[12:53] <ahasenack> namei
[12:56] <cpaelzer> ahasenack: yearh a good idea
[12:57] <cpaelzer> ahasenack: I could also add a sync call to test my theory on too much FS laziness
[12:57] <cpaelzer> also I did the review
[12:58] <ahasenack> thanks
[13:01] <cpaelzer> suspicious that debian-testing and cosmic work
[13:01] <cpaelzer> and the same in disco and unstable fai
[13:01] <cpaelzer> l
[13:01] <cpaelzer> unless my race has a love for making up its chances to set me on false tracks
=== fenris is now known as ejat
[13:54] <acheronuk> tianon: hi. there are now disco tars @ https://partner-images.canonical.com/core/disco/
[13:54] <acheronuk> do you know when docker images will come?
[15:17] <ejat> hi, who to safely remove python2.7 from cosmic without removing dependencies ?
[15:17] <ejat> how*
[15:22] <cjwatson> err, if there are still things depending on it that you aren't happy to remove in turn, then you can't safely remove it
[15:22] <cjwatson> sort of the definition of dependencies :)
[17:32] <rbasak> bug 1781529 is ready to be approved now I think - blocks mysql-5.7 migration now.
[17:32] <ubottu> bug 1781529 in mecab (Ubuntu) "[MIR] mecab" [High,In progress] https://launchpad.net/bugs/1781529
[17:38] <vorlon> rbasak: promoting
[18:18] <rbasak> Thanks!
[18:19] <rbasak> vorlon: did you miss mecab-ipadic?
[18:20] <rbasak> (difference source package, same upstream project, same bug)
[18:24] <vorlon> rbasak: I didn't miss it, I don't see it listed on either http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed or http://people.canonical.com/~ubuntu-archive/component-mismatches
[18:26] <rbasak> Oh
[18:26] <rbasak> I'll look into that, sorry.
[18:27] <rbasak> Skuggen: ^ do you remember where the dependency on mecab-ipadic should be coming from?
[18:29] <sarnold> "mecab depends on mecab-ipadic. Other dependencies are in main"  https://bugs.launchpad.net/ubuntu/+source/mecab/+bug/1781529
[18:29] <ubottu> Launchpad bug 1781529 in mecab-ipadic (Ubuntu) "[MIR] mecab" [Undecided,Fix committed]
[20:17] <tsimonq2> Unit193: Where is the code for udevbot?
[20:26] <tsimonq2> I just can't find where it's kept, hm.
[20:26] <tsimonq2> Maybe internally at Canonical?
[21:57] <tianon> acheronuk: nice catch; mwhudson usually handles that but he's probably swamped on his other ever-increasing responsibilities so I've opened https://github.com/tianon/docker-brew-ubuntu-core/pull/139 to get the ball rolling