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