[00:05] <mwhudson> is there an easy way for me to install the kernel and libc headers for another architecture?
[06:42] <pitti> Good morning
[07:55] <dholbach> good morning
[08:02] <pitti> 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] <xnox> brainwash: sigh, thanks.
[10:31] <xnox> 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] <xnox> Noskcaj: encfs -> synced, let's see if it builds everywhere.
[10:45] <xnox> hm, i ponder how to ping tseliot on irc =)
[10:46] <xnox> is he by any chance on the other IRC network?
[10:48] <xnox> Noskcaj: encfs built fine. all good.
[10:52] <netdef> build stated :) naaha
[10:52] <netdef> does ideviceinstaller works  on ios 8.1.1?
[10:53] <netdef> i installed from ubuntu repository which i don't know exact version. I'm new to this libimobile
[10:53] <netdef> but it does not work and says can't start installer or someting
[11:02] <netdef> /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] <netdef> /usr/local/lib/libxml2.a: error adding symbols: Bad value
[11:03] <netdef> collect2: error: ld returned 1 exit status
[11:03] <netdef> what is this error
[11:04] <maxb> An error instructing you to recompile with -fPIC
[11:05] <netdef> I'm so sorry but I dont know how to
[11:05] <netdef> can u teach me?
[11:05] <netdef> how to put -fPIC?
[11:07] <mgedmin> I think #ubuntu might be a better channel for this, netdef
[11:09] <netdef> but i soved by my self
[11:36] <netdef> the problem happens when ubuntu try to compile application in 32 bit using 64bit libaray on 64 bit os machine.
[11:37] <dholbach> @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] <netdef> just keep reference when you try to compile
[11:43] <netdef> ye!!!! compiled my expectaion was collect
[11:43] <netdef> libplist was not good
=== _salem is now known as salem_
[13:12] <dholbach> xnox, can you take a look at https://bugs.launchpad.net/ubuntu/+source/ntfs-3g/+bug/1291827?
[13:12] <ubottu> 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] <dholbach> it looks like there was a small bit of delta between ubuntu and debian - can the patch be dropped?
[13:17] <smb> 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] <ubottu> bug 790558 in dahdi-linux (Ubuntu) "dahdi kernel module built for wrong kernel version" [High,Fix released] https://launchpad.net/bugs/790558
[13:20] <pitti> 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] <apw> smb, done
[13:31] <smb> apw, thanks
[13:32] <xnox> dholbach: that package is in sync in vivid.
[13:32] <xnox> https://launchpad.net/ubuntu/+source/ntfs-3g
[13:32] <dholbach> xnox, right
[13:33] <dholbach> xnox, Ari thought there was a patch worth keeping in Ubuntu
[13:33] <dholbach> and since you synced, I thought you might have an opinion on the bug report :9
[13:33] <xnox> 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] <dholbach> thanks, I'll follow up on the bug report
[13:34] <xnox> dholbach: well the bug can be closed now, no?
[13:34] <dholbach> yes
[13:34] <dholbach> that's what I was going to do
[13:34] <dholbach> ... with some explanation
[13:52] <cyphermox> good morning!
[13:53] <cyphermox> @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] <cyphermox> rbasak: hey!
[13:58] <rbasak> cyphermox: hi!
[13:58] <cyphermox> rbasak: just curious what exactly there was to do atm with bug 1257082? :)
[13:58] <ubottu> 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] <rbasak> 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] <cyphermox> k
[14:24] <rbasak> cyphermox: Debian have said that they'd accept patches.
[14:24] <cyphermox> right
[14:24] <rbasak> So no reason to introduce an Ubuntu delta here if we can help it.
[14:25] <cyphermox> 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] <rbasak> cyphermox: yeah - provided that it works for all stakeholders, which assumes I've understood the multiple problems here correctly.
[14:26] <cyphermox> if you're still looking after it, I'll just let that bug be for now :)
[14:26] <rbasak> cyphermox: I'm happy to look after it, but I need a response from Jorge here really.
[14:26] <rbasak> niedbalski: ^^
[14:27] <cyphermox> cool :)
=== _salem is now known as salem_
=== salem_ is now known as _salem
[15:38] <dholbach> @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] <rbasak> 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] <rbasak> There's /run/shm, which is presumably evil to use thisi way but might be available.
[16:17] <rbasak> 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] <bdmurray> 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] <ubottu> 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] <mlankhorst> bdmurray: basically I had to backport an awful lot of patches for that
=== timrc-afk is now known as timrc
[19:22] <tjaalton> bdmurray: I've unverified that one, will double-check tomorrow but iirc there wasn't anything
[19:24] <bdmurray> tjaalton: okay, thanks!
[19:24] <bdmurray> tkamppeter: Could you have a look at bug 1348384? It seems to be related to an SRU you did.
[19:25] <ubottu> 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] <infinity> tjaalton: Hey, who's doing the lts-utopic X stack this time around?
[20:19] <infinity> mlankhorst: ^
[20:23]  * dobey can't wait for new kernel/x/intel
[20:23] <infinity> dobey: New kernel is there.  Someone seems to be slacking on the new X bit, though. :)
[20:23] <dobey> infinity: there == in proposed, or in updates?
[20:24] <infinity> dobey: updates.
[20:24] <dobey> ooh
[20:24]  * dobey makes a note to install it
[20:24] <dobey> infinity: i guess new intel drivers aren't in yet though?
[20:24] <infinity> dobey: Not any userspace component of such.
[20:25] <dobey> i wonder if those will come with the updated xorg
[20:28] <infinity> 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] <mlankhorst> infinity: oh I've had x-stack in canonical-x/x-staging for ages
[20:35] <infinity> mlankhorst: Perhaps that's not the best place for it if we want it to actually make the point release? ;)
[20:36] <mlankhorst> https://launchpad.net/~canonical-x/+archive/ubuntu/x-staging/+packages
[20:36] <mlankhorst> yeah, I guess it's SRU time
[20:37] <mlankhorst> I need xtrans, x11proto-core, x11proto-fonts, and libdrm updated
[20:37] <mlankhorst> llvm-toolchain-3.5 should be new
[20:39] <dobey> 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] <tjaalton> infinity: right, it's been on that ppa for a while, now would be the time to get them to the archive
[21:33] <infinity> tjaalton: A few weeks ago might have been the time, but now's really the time. :)
[21:34] <tjaalton> 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] <ricotz> Trevinho, hi, mesa-git-builds in xedgers should support mir now
[22:57] <Logan_> infinity: wanna do me a favor? :D
[22:57] <Logan_> it's not much of a favor
[22:57] <Logan_> I just need a no-change rebuild of a package in main
[22:59] <infinity> Logan_: Sure.
[23:00] <Logan_> one sec, doing a test build
[23:01] <Logan_> infinity: please do a no-change rebuild of gst0.10-python with the following changelog entry:
[23:01] <Logan_> No-change rebuild against new binutils to fix istanbul FTBFS on ppc64el.
[23:03] <ari-tczew> "Generated at 2014-12-06 20:13:15 UTC."
[23:03] <infinity> Logan_: That... Might need some explaining.
[23:03] <ari-tczew> cjwatson: MoM seems to be broken. ^
[23:03] <Logan_> infinity: sure - so you know the change that was made to binutils to properly support ppc64el in Debian?
[23:03] <Logan_> the one we talked about a few weeks ago
[23:04] <Logan_> it turns out that is does more than just fix FTBFS without autoreconf; it also fixes some shared libraries
[23:04] <infinity> Logan_: I feel like either you had this conversation with someone else, or I'm losing my mind. ;)
[23:04] <Logan_> oops, well, in any case
[23:05] <Logan_> istanbul currently FTBFS on ppc64el because it can't find the gst0.10-python library
[23:05] <Logan_> and that was shown in the build log on Debian
[23:05] <Logan_> but, after rebuilding gst0.10-python against the new binutils and then rebuilding istanbul in Debian, it found the library properly
[23:05] <Logan_> so we should do the same
[23:06] <infinity> 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] <infinity> checking whether the gcc linker (/usr/bin/ld -m elf64ppc) supports shared libraries... no
[23:07] <infinity> The usual suspect.
[23:07] <Logan_> right, but rebuilding it should produce the shared library
[23:07] <Logan_> because of the binutils change
[23:07] <infinity> Let me verify that.
[23:07] <infinity> And also, still not happy with that binutils change.
[23:07] <infinity> Seems too magic to me.
[23:07] <Logan_> seems to work, though
[23:08] <Logan_> it definitely produces the shared libraries properly, without an autoreconf in most cases
[23:08] <Logan_> 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] <Logan_> you need apt-fast
[23:10] <Logan_> or something.
[23:11] <infinity> checking whether the gcc linker (/usr/bin/ld -m elf64ppc) supports shared libraries... yes
[23:11] <infinity> Looks promising.
[23:11] <Logan_> you have a ppc64el porter box?
[23:11] <infinity> Yeah.
[23:11] <Logan_> like, physical?
[23:11] <infinity> It's not imaginary.
[23:12] <Logan_> :)
[23:12] <infinity> -rw-r--r-- root/root     18336 2014-12-08 23:11 ./usr/lib/gstreamer-0.10/libgstpython.so
[23:12] <infinity> Handy.
[23:13] <Logan_> oh cool, you can get a ppc64el VM for free here: http://openpower.ic.unicamp.br/minicloud/
[23:13] <Logan_> I might just do that
[23:13] <infinity> Uploaded.
[23:14] <Logan_> sweet, thanks
[23:15] <tkamppeter> bdmurray, thanks. I have CCed the author of the SRU patch for bug 1242678, Marek, Kasik.
[23:15] <ubottu> bug 1242678 in evince (Ubuntu Trusty) "evince cannot render some EPS files" [Undecided,Triaged] https://launchpad.net/bugs/1242678