[00:12] <xnox> juliank, postgresql-10-debversion sounds like a broken update, where did you see that?
[00:13] <juliank> xnox: postgresql-debversion/1.0.8-3 autopkgtest on !amd64 triggered by apt/1.6~alpha3
[00:13] <juliank> in failure to setup testbed, of course
[00:14] <nacc> there are a bunch of those pg10 packages that are migrating right now
[00:14] <nacc> so it could be related to all of that
[00:14] <nacc> and the builders catching up, etc.
[00:15] <juliank> It's a bit strange that the autopkgtest failed because the package to be tested was not available, but I guess it can happen
[00:15] <nacc> juliank: rmadison says it should be available, but only in bionic-proposed
[00:15] <nacc> so it might be stuck
[00:15] <juliank> Right, the amd64 retried with all packages from proposed
[00:16] <nacc> juliank: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#postgresql-10 is probably the blocker :/
[00:16] <nacc> juliank: it's on my todo (and cpaelzer's)
[00:16] <juliank> But armhf also retried using all packages from proposed, but could not find it
[00:17] <juliank> Anyway, I saw that with the last transition IIRC, so I'm not worrying too much
[00:17] <nacc> yeah
[05:20] <cpaelzer> juliank: thanks, the upload looks good, I'll push it into the git on Monday to track it properly
[05:21] <cpaelzer> juliank: I'll do some regression checks along the way, but the change seems small and safe
[05:21] <cpaelzer> juliank: also while not upstream yet, the mailing list response so far seems good
[05:29] <cpaelzer> lets see what the weekend can do to these long queues ...
[15:31] <erle-> Why are the commands in /bin now shared objects instead of executable files?
[15:33] <rbasak> erle-: I'm not sure what you mean. They are still executable files.
[15:34] <erle-> rbasak, but they are of time ELF shared object instead of ELF executable
[15:34] <erle-> *of type
[15:34] <rbasak> I'm pretty sure that's just a consequence of the tooling you're using to report on it.
[15:35] <erle-> rbasak, use «file /bin/cp»
[15:35] <erle-> you will see it is shared object in 17.10
[15:35] <erle-> it was executable in 16.04
[15:35] <rbasak> Yes. Like I said it's a consequence of the tooling you're using to report on it.
[15:36] <rbasak> Try copying an executable from 16.04 into a 17.10 system and then see what file says.
[15:39] <erle-> rbasak, I got an answer somewhere else
[15:39] <erle-> they are actually shared objects
[15:39] <erle-> point is that the linker can put them to random locations im memory
[15:39] <erle-> it's about address randomization
[15:40] <jbicha> erle-: https://codywu2010.wordpress.com/2014/11/29/about-elf-pie-pic-and-else/
[15:40] <jbicha> https://wiki.ubuntu.com/Security/Features#pie
[15:42] <erle-> jbicha, thanks
[15:53] <cjwatson> Some were PIE in 16.04 too
[15:53] <cjwatson> $ lsb_release -sr; file /usr/sbin/sshd
[15:53] <cjwatson> 16.04
[15:53] <cjwatson> /usr/sbin/sshd: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=cf2da4087de886767f688f645786229131e4af0c, stripped
[15:54] <cjwatson> It's just got a bit more default in the toolchain
[16:16] <rbasak> erle-: oh, I see. I didn't realise that change would cause a different output from file. Thanks.
[16:17] <infinity> rbasak: PIE binaries are literally type DYN, so yeah, file(1) doesn't know what to do with them.