[00:05] is there an easy way for me to install the kernel and libc headers for another architecture? [06:42] Good morning [07:55] good morning [08:02] wgrant, dpm: odd, latest utopic (and vivid) translation export lost "libc"; I just approved the template on https://translations.launchpad.net/ubuntu/utopic/+source/glibc/+imports?field.filter_status=all&field.filter_extension=pot but I wonder how we lost that in the first place [10:29] brainwash: sigh, thanks. [10:31] Noskcaj: i don't know about abiword - test it make sure it doesn't regress do the merge if you wish. I do not have time, nor interest to merge abiword. Thus i gave the merge up for adoption. [10:32] Noskcaj: encfs -> synced, let's see if it builds everywhere. [10:45] hm, i ponder how to ping tseliot on irc =) [10:46] is he by any chance on the other IRC network? [10:48] Noskcaj: encfs built fine. all good. [10:52] build stated :) naaha [10:52] does ideviceinstaller works on ios 8.1.1? [10:53] i installed from ubuntu repository which i don't know exact version. I'm new to this libimobile [10:53] but it does not work and says can't start installer or someting [11:02] /usr/bin/ld: /usr/local/lib/libxml2.a(encoding.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC [11:03] /usr/local/lib/libxml2.a: error adding symbols: Bad value [11:03] collect2: error: ld returned 1 exit status [11:03] what is this error [11:04] An error instructing you to recompile with -fPIC [11:05] I'm so sorry but I dont know how to [11:05] can u teach me? [11:05] how to put -fPIC? [11:07] I think #ubuntu might be a better channel for this, netdef [11:09] but i soved by my self [11:36] the problem happens when ubuntu try to compile application in 32 bit using 64bit libaray on 64 bit os machine. [11:37] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach [11:43] just keep reference when you try to compile [11:43] ye!!!! compiled my expectaion was collect [11:43] libplist was not good === _salem is now known as salem_ [13:12] xnox, can you take a look at https://bugs.launchpad.net/ubuntu/+source/ntfs-3g/+bug/1291827? [13:12] Launchpad bug 1291827 in ntfs-3g (Ubuntu) "Merge ntfs-3g 1:2014.2.15AR.2-1 (main) from Debian unstable (main)" [High,Confirmed] [13:12] it looks like there was a small bit of delta between ubuntu and debian - can the patch be dropped? [13:17] apw, could you accept my nominations on bug 790558, please. It is quite old but I found we still did it wrong when I did the merge from Debian. [13:17] bug 790558 in dahdi-linux (Ubuntu) "dahdi kernel module built for wrong kernel version" [High,Fix released] https://launchpad.net/bugs/790558 [13:20] cjwatson: did you do the systemd integration into openssh? if so, is there a reason why we have both a .service which is started in multi-user.target *and* a .socket? wouldn't the .socket be sufficient and more efficient? [13:30] smb, done [13:31] apw, thanks [13:32] dholbach: that package is in sync in vivid. [13:32] https://launchpad.net/ubuntu/+source/ntfs-3g [13:32] xnox, right [13:33] xnox, Ari thought there was a patch worth keeping in Ubuntu [13:33] and since you synced, I thought you might have an opinion on the bug report :9 [13:33] dholbach: i've changed with colin here and we decided it's not worth keeping the compat with pre-2011 wubi installs or something like that. [13:34] thanks, I'll follow up on the bug report [13:34] dholbach: well the bug can be closed now, no? [13:34] yes [13:34] that's what I was going to do [13:34] ... with some explanation [13:52] good morning! [13:53] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: cyphermox, dholbach [13:55] rbasak: hey! [13:58] cyphermox: hi! [13:58] rbasak: just curious what exactly there was to do atm with bug 1257082? :) [13:58] bug 1257082 in ntp (Ubuntu Trusty) "MAAS does not use NTP servers specified in DHCPD options" [Undecided,In progress] https://launchpad.net/bugs/1257082 === salem_ is now known as _salem [14:24] cyphermox: I wanted a conversation around my comments 21-23, to work out the best way to do this so we don't diverge from Debian. [14:24] k [14:24] cyphermox: Debian have said that they'd accept patches. [14:24] right [14:24] So no reason to introduce an Ubuntu delta here if we can help it. [14:25] then it seems like your idea to just have the small change in the script sounds like a good way to address this, and something that can be easily upstreamed [14:26] cyphermox: yeah - provided that it works for all stakeholders, which assumes I've understood the multiple problems here correctly. [14:26] if you're still looking after it, I'll just let that bug be for now :) [14:26] cyphermox: I'm happy to look after it, but I need a response from Jorge here really. [14:26] niedbalski: ^^ [14:27] cool :) === _salem is now known as salem_ === salem_ is now known as _salem [15:38] @pilot out === udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: cyphermox [15:38] * dholbach hugs cyphermox === roadmr is now known as roadmr_afk === _salem is now known as salem_ === salem_ is now known as _salem [16:17] Is there a tmpfs that we can use in package builds and dep8 tests? Looking to speed up mysql tests, and they can make use of a tmpfs if there is one mounted somewhere. [16:17] There's /run/shm, which is presumably evil to use thisi way but might be available. [16:17] Is there a better place or mechanism to get this? === roadmr_afk is now known as roadmr === _salem is now known as salem_ === timrc is now known as timrc-afk [18:30] tjaalton: in bug 1386620, which you verified, there is mention of a potential regression regarding modesetting. Can you comment on your testing of that? [18:30] bug 1386620 in xorg-server (Ubuntu Vivid) "re-enable rotation for the intel driver in optimus mode" [Critical,New] https://launchpad.net/bugs/1386620 [18:37] bdmurray: basically I had to backport an awful lot of patches for that === timrc-afk is now known as timrc [19:22] bdmurray: I've unverified that one, will double-check tomorrow but iirc there wasn't anything [19:24] tjaalton: okay, thanks! [19:24] tkamppeter: Could you have a look at bug 1348384? It seems to be related to an SRU you did. [19:25] bug 1348384 in okular (Ubuntu) "evince and okular do not render eps files correctly resulting in a black background" [Undecided,Confirmed] https://launchpad.net/bugs/1348384 [20:19] tjaalton: Hey, who's doing the lts-utopic X stack this time around? [20:19] mlankhorst: ^ [20:23] * dobey can't wait for new kernel/x/intel [20:23] dobey: New kernel is there. Someone seems to be slacking on the new X bit, though. :) [20:23] infinity: there == in proposed, or in updates? [20:24] dobey: updates. [20:24] ooh [20:24] * dobey makes a note to install it [20:24] infinity: i guess new intel drivers aren't in yet though? [20:24] dobey: Not any userspace component of such. [20:25] i wonder if those will come with the updated xorg [20:28] dobey: Usually seems to work that way. === timrc is now known as timrc-afk [20:31] * dobey goes to order a displayport 1.2 cable === roadmr is now known as roadmr_afk [20:35] infinity: oh I've had x-stack in canonical-x/x-staging for ages [20:35] mlankhorst: Perhaps that's not the best place for it if we want it to actually make the point release? ;) [20:36] https://launchpad.net/~canonical-x/+archive/ubuntu/x-staging/+packages [20:36] yeah, I guess it's SRU time [20:37] I need xtrans, x11proto-core, x11proto-fonts, and libdrm updated [20:37] llvm-toolchain-3.5 should be new [20:39] mlankhorst: are you updating intel-gup-tools, libdrm-intel and xserver-xorg-video-intel too? === salem_ is now known as _salem === cmagina_ is now known as cmagina [21:32] infinity: right, it's been on that ppa for a while, now would be the time to get them to the archive [21:33] tjaalton: A few weeks ago might have been the time, but now's really the time. :) [21:34] heh, indeed === olerem_ is now known as olerem === roadmr_afk is now known as roadmr === txspud|afk is now known as txspud === timrc-afk is now known as timrc [22:51] Trevinho, hi, mesa-git-builds in xedgers should support mir now [22:57] infinity: wanna do me a favor? :D [22:57] it's not much of a favor [22:57] I just need a no-change rebuild of a package in main [22:59] Logan_: Sure. [23:00] one sec, doing a test build [23:01] infinity: please do a no-change rebuild of gst0.10-python with the following changelog entry: [23:01] No-change rebuild against new binutils to fix istanbul FTBFS on ppc64el. [23:03] "Generated at 2014-12-06 20:13:15 UTC." [23:03] Logan_: That... Might need some explaining. [23:03] cjwatson: MoM seems to be broken. ^ [23:03] infinity: sure - so you know the change that was made to binutils to properly support ppc64el in Debian? [23:03] the one we talked about a few weeks ago [23:04] it turns out that is does more than just fix FTBFS without autoreconf; it also fixes some shared libraries [23:04] Logan_: I feel like either you had this conversation with someone else, or I'm losing my mind. ;) [23:04] oops, well, in any case [23:05] istanbul currently FTBFS on ppc64el because it can't find the gst0.10-python library [23:05] and that was shown in the build log on Debian [23:05] but, after rebuilding gst0.10-python against the new binutils and then rebuilding istanbul in Debian, it found the library properly [23:05] so we should do the same [23:06] Logan_: Right, so istanbul has nothing to do with this. gst0.10-python just plain doesn't have a shared library in it, and it should have FTBFS because of it but didn't. [23:06] checking whether the gcc linker (/usr/bin/ld -m elf64ppc) supports shared libraries... no [23:07] The usual suspect. [23:07] right, but rebuilding it should produce the shared library [23:07] because of the binutils change [23:07] Let me verify that. [23:07] And also, still not happy with that binutils change. [23:07] Seems too magic to me. [23:07] seems to work, though [23:08] it definitely produces the shared libraries properly, without an autoreconf in most cases [23:08] I've been dropping our autoreconf delta when it builds properly in Debian on ppc64el [23:09] * infinity taps his foot waiting on build-deps to install. [23:10] you need apt-fast [23:10] or something. [23:11] checking whether the gcc linker (/usr/bin/ld -m elf64ppc) supports shared libraries... yes [23:11] Looks promising. [23:11] you have a ppc64el porter box? [23:11] Yeah. [23:11] like, physical? [23:11] It's not imaginary. [23:12] :) [23:12] -rw-r--r-- root/root 18336 2014-12-08 23:11 ./usr/lib/gstreamer-0.10/libgstpython.so [23:12] Handy. [23:13] oh cool, you can get a ppc64el VM for free here: http://openpower.ic.unicamp.br/minicloud/ [23:13] I might just do that [23:13] Uploaded. [23:14] sweet, thanks [23:15] bdmurray, thanks. I have CCed the author of the SRU patch for bug 1242678, Marek, Kasik. [23:15] bug 1242678 in evince (Ubuntu Trusty) "evince cannot render some EPS files" [Undecided,Triaged] https://launchpad.net/bugs/1242678