=== doko_ is now known as doko
[03:44] <shadeslayer> is pm-utils still required on the ISO?
=== timrc-afk is now known as timrc
=== timrc is now known as timrc-afk
=== BruceMa is now known as BruceMa-afk
[05:52] <pitti> Good morning
[05:57] <doko> pitti, I'm annoyed about autopkg tests
[05:57] <doko> why is the aspcud test run when gcc-4.8 gets uploaded?
[05:59] <pitti> doko: was it? AFAICS it was run because 1:1.8.0-1 landed in trusty-proposed on Jan 11, and that introduced an autopkgtest
[05:59] <pitti> (which fails, like almost every new autopkgtest that we get *sigh*)
[06:00] <pitti> I got another slew of failures over the weekend, going through them todya
[06:03] <doko> pitti, pretty please can we ignore results for new autopkg tests until they get reviewed
[06:03] <doko> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735138
[06:03] <ubottu> Debian bug 735138 in aspcud "autopkg test always failing" [Serious,Open]
[06:04] <pitti> doko: yes, jibel said he's working on that, to only hold back packages if the test ever succeeded
[06:04] <pitti> doko: until then, if something is held back by them (not gcc-4.8 though), the release team can set a "known broken" tag
[06:04] <doko> good to know
[06:04] <pitti> gcc-4.8 isn't even in -proposed
[06:05] <doko> pitti, it was, asked infinity to ignore the test. but it's annoying that I have to care about these
[07:36] <Logan_> infinity: why did most of the ppc64el FTBFSes disappear overnight
[07:36] <Logan_> I am so confused
[07:38] <Logan_> wait they were all reset to "needs building"
[07:38] <Logan_> but why
[07:38] <Logan_> doko: is this because of your mass rebuild?
[07:40] <doko> Logan_, he did give back the packages, they should reappear soonish
[07:40] <Logan_> who did?
[07:40] <Logan_> I'm so confused :P
[07:40] <dholbach> good morning
[07:41] <Logan_> hey Daniel
[07:41] <dholbach> hey Logan_
[07:41] <dholbach> how's life over there?
[07:42] <Logan_> It's going. :P
[07:42] <Logan_> It is also approaching 3 AM, so I should probably get to sleep.
[07:42] <dholbach> that sounds like a good idea :)
[07:43] <Logan_> doko: I'm still confused though. :( Who is "he," and to whom is he giving back the packages? :P
[07:43] <doko> infinity,
[07:43] <doko> to the buildds
[07:44] <Logan_> Ah.
[07:44] <Logan_> So it is Adam's fault. :P
[07:44] <Logan_> I am so intuitive.
[07:46] <Logan_> I also have to forward like 20 ppc64el patches to Debian. So tedious.
[07:46] <doko> Logan_, are you user-tagging these?
[07:47] <Logan_> infinity and I were discussing that yesterday with juliank.
[07:47] <Logan_> I don't think we came to a conclusion about what the usertag(s) should be and if my bugs even need one.
[07:48] <Logan_> Because the dh-autoreconf/autotools-dev are more futureproofing than necessarily fixing FTBFSes on a specific architecture.
[07:48] <Logan_> But they do serve an immediate purpose, though.
[07:48] <Logan_> Hi Jackson.
[07:48] <Noskcaj> hey Logan_
[07:49] <Logan_> doko: Please let me know if I should use something, though.
[07:50] <doko> call-autoreconf
[07:50] <Logan_> ...and, if so, if I have to retroactively apply it to all ~120 other ppc64el patches I've submitted.
[07:51] <Logan_> Well, some of those are config.{sub,guess} updates with autotools-dev. I guess that whittles that number down a bit. :P
[07:52] <doko> you can do that with a control message
[07:52] <Logan_> Okay. Is this usertag going to be a standard?
[07:52] <doko> maybe use debian-devel@lists.debian.org as the user, but let's ask others about that first, like cjwatson
[07:53] <Logan_> Hmm.
[07:55] <Logan_> There should probably be a larger discussion about this, yeah.
[08:01] <MacSlow> Greetings folks!
=== BruceMa-afk is now known as BruceMa
[08:34] <pitti> dobey: hey Rodney, how are you?
[08:35] <pitti> dobey: mvo approved https://code.launchpad.net/~pitti/software-center/deprecated-ctors/+merge/201158, would you mind merging this? thanks!
=== jodh` is now known as jodh
[08:58] <rbasak> jdstrand: are you aware of bug 1262710, please?
[08:58] <ubottu> bug 1262710 in nginx (Ubuntu) "[MIR] nginx" [Undecided,Confirmed] https://launchpad.net/bugs/1262710
[09:01] <Noskcaj> dholbach, What do i do to fix the test failure i just made? I barely know enough C to make a "hello world"
[09:02] <Noskcaj> And do test failures make the build crash locally and i missed it or has something broke since?
[09:03] <dholbach> Noskcaj, no the test worked out fine for me locally - I did a test build
[09:03] <dholbach> Noskcaj, if you don't get very far with your own investigations, you could ask in here, or on ubuntu-devel@ for some help
[09:03] <dholbach> and if that doesn't help, you could ask upstream
[09:05] <Noskcaj> ok, will do.
[09:05] <Noskcaj> Although tomorrow, since i'm not meant to be on the internet
[09:06] <dholbach> Noskcaj, see you! :)
[09:06] <Noskcaj> bye, thanks for the tips
[09:58] <doko> jodh, there is no libnuma-dev on arm64 and armhf
[09:59] <jodh> doko: yes, I saw that and was wondering how to define that in debian/control as I've already specified some arch restrictions on that package.
[09:59] <doko> jodh, or you try to build it on these archs ;p
[10:01] <dholbach> seb128, does Laney's comment on 1268097 make sense?
[10:02] <jodh> doko: I have been waiting since November for Debian to approve my request to access their porter boxes for that exact reason
[10:03] <doko> jodh, well, you have access to armhf, and debian doesn't have access to arm64 either
[10:05] <jodh> doko: sure. I'm trying to keep the process for myself as simple as possible as procenv builds differently on every arch and there are lots to support :) Wouldn't it be great if it was possible to test this out on mentors rather than via an upload? So, do you know how I would build-depend on libnuma-dev for (linux-all - arm64 - armhf)?
[10:07] <jodh> doko: ... - armel - arm64 :)
[10:09] <doko> jodh, enumerate the libnuma-dev architectures explicitly
[10:23] <shadeslayer> could somene look at https://launchpadlibrarian.net/162316715/buildlog_ubuntu-trusty-ppc64el.kubuntu-meta_1.297_FAILEDTOBUILD.txt.gz
[10:23] <shadeslayer> Can't open desktop-ppc64el: No such file or directory at /usr/bin/dh_germinate_metapackage line 78.
[10:25] <shadeslayer> nvm
[10:31] <doko> shadeslayer, you need to add it in kubuntu-meta
[10:31] <shadeslayer> doko: yep, missing arch in update.cfg
[10:45] <TJ-> Anyone familiar with apparmor internals? Specifically whether it is supposed to truncate the logged process name in syslog, e.g. comm="qemu-system-x86" instead of comm="qemu-system-x86_64" - looks like a truncate-on-underscore bug unless its deliberate
[11:02] <cjwatson> doko: I really don't care what the usertag is; pick one :)
[11:03] <cjwatson> doko: though using debian-devel@ seems to imply a consensus there, which isn't clear
[11:03] <cjwatson> shadeslayer: I was deliberately not adding it until more of the rest of Kubuntu is built on ppc64el
[11:03] <Mirv> mitya57: hi! dok_o confirmed that the aarc64 Qt patches are not needed anymore with 5.2
[11:03] <shadeslayer> cjwatson: oh .... how do I check that ? :S
[11:04] <doko> well, we could use one of our own email addresses
[11:04] <cjwatson> shadeslayer: http://qa.ubuntuwire.org/ftbfs/ppc64el.html has a section for it
[11:04] <shadeslayer> I see
[11:04] <cjwatson> http://qa.ubuntuwire.org/ftbfs/ppc64el.html#kubuntu in fact
[11:04] <mitya57> Mirv: great, drop them then :)
[11:05] <Mirv> will do
[11:05] <doko> fyi, I demoted trac-bzr to -proposed. is there anybody I should explicitely tell about it?
[11:05] <shadeslayer> cjwatson: ack
[11:08] <directhex> is there a way for mortals to developer for aarch64 yet?
[11:10] <shadeslayer> cjwatson: ugh, eigen is FTBFS
[11:12] <cjwatson> shadeslayer: can't help you with that one, I don't speak enough C++
[11:18] <doko> shadeslayer, eigen?
[11:19] <brendand> where can i get newer versions of pulseaudio?
[11:19] <shadeslayer> doko: https://launchpad.net/ubuntu/+source/eigen2/2.0.17-1/+build/5345503
[11:23] <shadeslayer> cjwatson: while you're here, any ideas if pm-utils will go away?
[11:26] <seb128> dholbach, commented on the bug btw ;-)
[11:27] <seb128> dholbach, readonly is not really an issue there, we don't want people to have to adb to sudo cp files to add a ringtone, we can do better than that ;-)
=== MacSlow is now known as MacSlow|lunch
[11:30] <cjwatson> shadeslayer: no idea
[11:51] <doko> zul, beanstalkd ftbfs
[12:13] <pitti> shadeslayer: not anytime soon, as long as there are still laptops out there which need suspend quirks
=== _salem is now known as salem_
[12:14] <pitti> shadeslayer: it's optional these days (meaning that logind will work without it), and we don't install it on phones, but we still want it on desktops
[12:15] <mpt> ev, was the fix for bug 1033902 ever backported to 12.04? From the bug report it seems not.
[12:15] <ubottu> bug 1033902 in Apport "Application thread crash shows application crash error alert" [High,Fix committed] https://launchpad.net/bugs/1033902
[12:17] <mpt> …Though the bug description is filled out as if it was meant to be.
[12:17] <pitti> no, it wasn't
=== MacSlow|lunch is now known as MacSlow
[13:19] <arges> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 1 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: arges
[13:24] <kentb> xnox: sorry about the mixup with sblim-sfcc...all my fault. I'll work on getting it cleaned up today
=== ara is now known as Guest58013
[13:37] <caribou> slangasek: I have a question for you regarding http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706655
[13:37] <ubottu> Debian bug 706655 in kdump-tools "kexec-tools: Please consider including integration for kdump auto-dumping" [Wishlist,Open]
[13:39] <caribou> slangasek: we no longer use the script in kexec-tools. It has been overriden by the kdump-tools since Raring :
[13:39] <caribou> https://blueprints.launchpad.net/ubuntu/+spec/servercloud-r-kdump-tool
=== timrc-afk is now known as timrc
[13:46] <jdstrand> TJ-: re apparmor, I believe that for "comm" that is by design. you'd likely have more luck asking on #apparmor on OFTC
[13:46] <mlankhorst> chrisccoulson: ping?
[13:48] <TJ-> jdstrand: OK... I've logged a bug report since it's useless if the reported process name can't be given to aa-complain/aa-disable
[13:51] <jdstrand> TJ-: normally you use the path to the profile name for that and the path used for binary attachment is "name" not "comm"
[13:52] <jdstrand> TJ-: reading 'man apparmor', while the text is quite old, it says there is a 15 byte limitation on the process name due to Berkeley process accounting
[13:52] <psivaa> cjwatson: doko: a precise-alternate issue after 20140111: http://pastebin.ubuntu.com/6744680/ unmet deps.
[13:53] <psivaa> nothing urgent here for me.. but just letting you know if in case it interests you. and apologies if it doesn't :)
[13:54] <TJ-> jdstrand: which would explain it... thanks! Caught me out trying to solve an issue with libvirt/qemu-system-x86_64 being denied access to /dev/sr0
[13:54] <doko> tjaalton, ^^^ could you look at psivaa message? I think you did update precise
[13:55] <cjwatson> doko,tjaalton,psivaa: I suspect it's a CD-building problem and that tjaalton is going to be a bit stuck
[13:56] <cjwatson> I'll look at it, but not this afternoon, am going to be offline for a few hours
[13:56] <tjaalton> hum
[13:56] <tjaalton> mlankhorst: ^
[13:56] <tjaalton> missing packages I think?
[13:56] <cjwatson> no
[13:56] <tjaalton> ok
[13:57] <cjwatson> both the enablement stack and the original stack are trying to be installed for some reason
[13:57] <tjaalton> ah
[13:57] <tjaalton> sounds familiar
[13:57] <mlankhorst> yeah
[13:57] <mlankhorst> maybe some egl drivers are tried?
[13:59] <cjwatson> the desktop-common seed pulls in the old stack, which is reasonable for the seed in general but the images will need to figure out how to override it
[13:59] <mlankhorst> oh
[13:59] <cjwatson> I'll look at it but as I say not this afternoon
[13:59] <mlankhorst> cjwatson: libtxc-dxtn-s2tc0 is in universe
[13:59] <mlankhorst> at least for precise
[13:59] <cjwatson> which no doubt contributes but isn't the sole problem
[13:59] <cjwatson> at least I doubt it
[14:00] <cjwatson> I mean it's only a Recommends, it can't be breaking things
[14:00] <cjwatson> mlankhorst: but I can move s2tc to main in precise-updates if that's what you folks need
[14:00] <mlankhorst> yes please
[14:01] <cjwatson> done
[14:01] <cjwatson> like I say, though, won't fix this
[14:01] <mlankhorst> yeah something causes the main stack to be installed
[14:02] <mlankhorst> cjwatson: what image btw?
[14:03] <cjwatson> precise alternate, as psivaa said
[14:06] <mlankhorst> I think the snippet is too small to say anything sane about it
[14:06] <mlankhorst> would need a bigger log
[14:06] <cjwatson> I agree, need to dig into it in more detail.  we don't need a libglu1-mesa-lts-saucy, do we?
[14:06] <mlankhorst> no
[14:07] <cjwatson> though that might just move the problem one level up, anyway
[14:07] <mlankhorst> libglu split off from mesa after 8.0
[14:07] <psivaa> mlankhorst: http://pastebin.ubuntu.com/6744772/ is the full install log
[14:08] <cjwatson> I don't think we're going to get the reason out of logs
[14:08] <mlankhorst> Jan 13 13:36:45 in-target: invoke-rc.d: policy-rc.d denied execution of start.
[14:09] <mlankhorst> Jan 13 13:37:20 in-target: Reading package lists...
[14:09] <mlankhorst> nope, missing the install command :/
[14:09] <cjwatson> wouldn't do you any good anyway, it's just installing a task, and the definition of the task will be image-specific
[14:10] <mlankhorst> hm maybe the unrenamed packages are still part of the task?
[14:10] <cjwatson> no doubt
[14:10] <cjwatson> which is why this is an image-building problem to debug
[14:10] <cjwatson> I doubt it's your problem
[14:11] <mlankhorst> indeed
[14:12] <cjwatson> mlankhorst: mind you - shouldn't libglamor-ltss0's depends prefer libgl1-mesa-glx-lts-saucy rather than libgl1-mesa-glx?
[14:13] <mlankhorst> oh, it should..
[14:13] <cjwatson> mlankhorst: that's the reason germinate's giving me at the moment
[14:13] <mlankhorst> but the package rename script should have taken care of that..
[14:13] <mlankhorst> hm
[14:14] <cjwatson> it's the only match in grep-dctrl -FSource:Package lts-saucy --and -FDepends 'libgl1-mesa-glx '
[14:15] <cjwatson> so fixing that will either help or will expose the next problem :)
[14:16] <mlankhorst> it shouldn't be fatal at least... no idea why it wants libgl1-mesa-glx explicitly either
[14:17] <cjwatson> it's fatal in this case because task construction is not always entirely deterministic and essentially depends on which one of a set of alternatives it sees first
[14:17] <cjwatson> so right now that's what causes libgl1-mesa-glx to be pulled into the ubuntu-desktop task on the alternate image
[14:17] <mlankhorst> fun
[14:18] <mlankhorst> looks like I may need to explicitly depend on libgl1-mesa-glx-lts-saucy in build-depends then or something
[14:20] <mlankhorst> cjwatson: oh, it seems to be because of shlibs in libgl1-mesa-glx-lts-saucy
[14:20] <cjwatson> ah
[14:21] <mlankhorst> I would rather not change that, can I override the shlibs:Depends for glamoregl?
[14:21] <mlankhorst> hm maybe adding libgl1-mesa-glx-lts-saucy in front is enough
[14:21] <cjwatson> probably won't be
[14:21] <cjwatson> worst case you can sed the substvars file
[14:22] <mlankhorst> it should be enough
[14:22] <arges> xnox: do you mind if I review this merge? https://code.launchpad.net/~louis-bouchard/ubuntu/trusty/backuppc/backuppc-merge/+merge/200536
[14:22] <cjwatson> I'd really prefer you didn't take that approach
[14:22] <cjwatson> I'm not quite sure whether germinate will DTRT with that and it's confusing
[14:23] <cjwatson> sed -i 's/libgl1-mesa-glx /libgl1-mesa-glx-lts-saucy /' debian/libglamor-ltss0.substvars after dh_shlibdeps should work
[14:23] <cjwatson> anyway, have to go out
[14:49] <jamespage> OK - so I'm trying to figure out how to introduce a new libmysqlclient for mysql-5.6 into the archive without causing a transition
[14:49] <jamespage> the mysql-5.5 client version is 18.0 and the mysql-5.6 client version is 18.1  - is it possible to have two such closely versioned libraries installed at the same time and everything still work?
[14:52] <chrisccoulson> hi mlankhorst
[14:52] <mlankhorst> chrisccoulson: do you have some easy way to reproduce bug 1267893
[14:52] <ubottu> bug 1267893 in Oxide "Shutdown crash due to possible mesa race at startup" [Critical,Triaged] https://launchpad.net/bugs/1267893
[14:52] <chrisccoulson> mlankhorst, not unless you want to build oxide (which is pretty heavy) ;)
[14:53] <zul> doko:  building now
[14:53] <chrisccoulson> mlankhorst, and it obviously doesn't happen every time too
[14:53] <geser> jamespage: different packagename (and so-version) of the library or same?
[14:53] <mlankhorst> chrisccoulson: oh was curious if the patch Sarvatt attached fixes it
[14:53] <chrisccoulson> mlankhorst, yeah, that patch will fix it. i can tell that without even trying it :)
[14:54] <chrisccoulson> but it doesn't fix the underlying cause, which is that the glx extension gets registered twice. not sure if there are other effects from that
[14:55] <jamespage> geser, I was thinking libmysqlclient18 (for mysql-5.5) providing libmysqlclient.so.18 and libmysqlclient18.1 (for mysql-5.6) providing libmysqlclient.so.18.1 - just trying to think if there are any gotchas
[14:55] <mlankhorst> probably not
[14:55] <chrisccoulson> mlankhorst, so in that case, that patch should be fine
[14:55] <mlankhorst> my guess is maybe some small extra allocation until close
[14:56] <jamespage> like if I install the 5.6 client library, does all client use which to the 18.1 version
[14:57] <geser> jamespage: no, only those which link against it (which would be at first the mysql 5.6 client and server itself)
[14:57] <jamespage> geser, well those statically link the client - but it sounds like it should be OK then
[14:59] <geser> jamespage: then for the client it would be even easier, but other programs which are linked against it request specifically libmysqlclient.so.18 (or libymsqlclient.so.18.1 if linked against mysql 5.6)
[15:00] <jamespage> geser, excellent - thanks for confirming that behaviour
[15:00] <jamespage> that's what I thought but it felt weird
[15:00] <geser> just make sure that there is no file conflict between those two library packages
[15:00] <jamespage> geser, ack
[15:01] <geser> jamespage: what about the -dev package? are you going to version it to not break linking/building with libmysqlclient-dev (from mysql 5.5)
[15:02] <jamespage> geser, I think its OK for the -dev package from 5.6 to conflict with the 5.5 version - it only makes sense to ever have one installed
[15:03] <geser> jamespage: yes, but if mysql 5.6 builds libmysqlclient-dev now then you can only build other packages against 5.6 as it will replace libmysqlclient-dev from 5.5 in the archive
[15:03] <jamespage> geser, mysql 5.6 would build libmysqlclient18.1-dev for now
[15:04] <geser> ok, so no problem then
[15:04] <jamespage> hope not
[15:04] <jamespage> :-)
[15:24] <mlankhorst> chrisccoulson: I was hoping for some official confirmation though, so I could merge the patch into mesa
=== dames is now known as thedac
[16:09] <slangasek> caribou: Debian bug #706655> ok, can you provide a patch to the Ubuntu kexec-tools package to get rid of whatever bits are no longer required, so we can reduce the delta with Debian and I can close out that report?
[16:09] <ubottu> Debian bug 706655 in kdump-tools "kexec-tools: Please consider including integration for kdump auto-dumping" [Wishlist,Open] http://bugs.debian.org/706655
[16:09] <caribou> slangasek: ok, arges was pinging me about the kexec-tools merge earlier today
[16:10] <caribou> slangasek: I will see with him so we get rid of anything that is no longer needed
=== Sweetsha1k is now known as Sweetshark
[17:06] <stgraber> tseliot: bug 1259237 was automatically marked verification-failed, can you take a look?
[17:06] <ubottu> bug 1259237 in nvidia-prime (Ubuntu Precise) "Hybrid graphics enablement in 12.04.4" [Medium,In progress] https://launchpad.net/bugs/1259237
[17:07] <stgraber> we're trying to round up the last few bits for 14.04.4 and there appears to be a dozen packages related to that bug which are targeted at 14.04.4, so the sooner we can have this sorted out the better
[17:09] <tseliot> stgraber: I worked on a fix (now in 14.04) and I attached a deb package in LP: #1268027 to see if that solves the issue. I can also upload to precise-proposed if you want
[17:09] <ubottu> Launchpad bug 1268027 in nvidia-settings (Ubuntu) "nvidia-settings crashes on exit" [Medium,Triaged] https://launchpad.net/bugs/1268027
[17:20] <jjohansen> jdstrand: since you where dealing with this earlier. I've answered bug 1268546
[17:20] <ubottu> bug 1268546 in apparmor (Ubuntu) "comm process name log entry truncated at underscore" [Undecided,New] https://launchpad.net/bugs/1268546
[17:21] <jdstrand> jjohansen: ack, thanks
[17:22] <jdstrand> jjohansen: not saying you have to do it, but man, the ERRORS section of the man page is pretty out of date (I'm not sure I recall ever seeing a log message like the one in the man page :)
[17:22] <jjohansen> heh I bet, the man page needs some love
[17:22] <jdstrand> I can send a patch to the list
[17:22] <sbeattie> ah, yeah, I bet.
[17:22] <sbeattie> jdstrand: that'd be great
[17:33] <cjwatson> switching libtool back to M-A: foreign as discussed last week
[17:34] <cjwatson> I'll also work on testing the results of the debian-devel discussion so that we can have a more permanent solution
[17:34] <cjwatson> (though probably not today)
[17:44] <infinity> cjwatson: The proposed option 1 seemed san.
[17:44] <infinity> cjwatson: sane, too.
[17:51] <cjwatson> infinity: Yeah.  But I have only proven it correct, not tested it, as the saying goes.
[18:04] <infinity> cjwatson: Indeed.  It's obviously not harmful to native builds, but I guess some cross-testing (since that's what we're attempting to "fix") would be in order.
[18:06] <cjwatson> Yes.  Ideally I need an example of something that's actually trying to use /usr/bin/libtool ...
[18:06] <cjwatson> (That we haven't shotgunned yet)
[18:07] <cjwatson> I'm not short of normal libtool examples
[18:10] <infinity> cjwatson: There are a large number of packages (though I can't think of one off the top of my head) that test for /usr/bin/libtool and then don't use it. :P
[18:10] <infinity> cjwatson: Those all worked fine in the M-A:foreign unsplit case, of course.
[18:11] <infinity> I don't actually know of a package that *calls* libtool, though there must be a few.
[18:50] <dobey> infinity: any library that is built with autotools using libtool, will probably call /usr/bin/libtool during the build
[18:50] <infinity> dobey: That's generally not true.
[18:51] <infinity> dobey: Anything properly libtoolized has its own local copy of libtool.m4, etc, and configure generates a fresh local libtool that ends up being called.
[18:52] <infinity> Most of the cases of /usr/bin/libtool usage I've seen have actually just been "-f /usr/bin/libtool" tests and then calling libtoolize. :P
[18:54] <dobey> infinity: the local libtool in the tree is a shell script, that can call /usr/bin/libtool, iirc
[18:56] <jtaylor> may I ask what the motivation for ppc64el is? it seems to divert a lot of manpower before the lts.
[18:56] <jtaylor> I don't recall it being explained on the mailing list
[18:56] <infinity> (For the record, we just did a test rebuild with a libtool that didn't ship /use/bin/libtool, and it proved your assertion false, I'm not just guessing)
[18:57] <jtaylor> I just found the debian report which was mostly negative to adding it
[18:58] <infinity> jtaylor: Which report is this?
[18:58] <jtaylor> https://lists.debian.org/debian-powerpc/2013/09/msg00045.html
[18:58] <jtaylor> probably not negative, but I also saw no good reason to add it
[18:58] <infinity> Anyhow, the short answer is "to have Ubuntu run on POWER8 with IBM's recommended configuration".  No community members are being forced to do any work, so I'm not sure what the complaint would be.
[18:59] <jtaylor> just discussion about ibm management :/
[18:59] <jtaylor> I'm not complaining, just curious
[19:02] <jtaylor> xnox: any news on when qemu arm64 will be fixed?
[19:03] <infinity> jtaylor: You want hallyn for that question, probably.
[19:03] <jtaylor> oh sorry
=== tkamppeter_ is now known as tkamppeter
[19:10] <hallyn> jtaylor: is qemu arm64 broken?
[19:11] <hallyn> later this week i will push a new qemu that shoudl have kvm support for qemu-system (but not the qemu-user-aarch64)
[19:11] <hallyn> but not today, hitting deadlines
[19:13] <jtaylor> hallyn: some of xnoxs arm64 changes in 1.5 were reverted in 1.7 merge
[19:13] <jtaylor> we discussed it about a week ago here
[19:18] <hallyn> i don't recall xnox making any changes, but if you're referring to the suse patchset then the latest estimate i know if would be a little over a month to get the new patchset upstream, and i'll pull it in as quick as i can after that
[19:18] <hallyn> if there is another patch/fix you're referring to, then maybe i just messed up
=== cr3_ is now known as cr3
=== cr3 is now known as Guest30001
=== fire is now known as hack
=== Guest24574 is now known as LoganCloud
=== cr3_ is now known as cr3
=== cr3 is now known as Guest76553
=== salem_ is now known as _salem
[20:40] <kentb> I've got a package for sponsorship review if anyone would like to take a look. Thanks in advance: https://bugs.launchpad.net/ubuntu/+source/openwsman/+bug/1268707
[20:40] <ubottu> Ubuntu bug 1268707 in openwsman (Ubuntu) "Please upgrade openwsman in universe to latest upstream for Trusty (2.4.3)" [Undecided,New]
[20:41] <arges> kentb: well i'm piloting today so I'd be glad to look at it
[20:41] <kentb> arges: ok. thanks!
[20:47] <arges> kentb: the debdiff doesn't apply cleanly to the version already in trusty
[20:47] <arges> kentb: 2 out of 2 hunks FAILED -- saving rejects to file cmake/modules/FindRuby.cmake.rej
[20:48] <kentb> arges: ok. I know which patch that was
[20:49] <kentb> arges: I took it out when building the package...it is in patches/cmake-findruby.patch
[20:50] <arges> kentb: its not in the series file
[20:51] <arges> all that's there is the cmake-pythone-includes.patch
[20:53] <kentb> arges: sorry. I think I got mixed up here with what you were telling me.  When I originally built the package using the upstream source, there was a cmake-findruby.patch included in the 2.3.6 debian.tgz file.  That patch was no longer needed.  I removed it and also took it out of the series file so it would build.  Does that make sense?
[20:55] <arges> kentb: even with that patch removed, it still fails to apply your debdiff
[20:55] <arges> kentb: do this ' pull-lp-source openwsman trusty; cd openwsman-2.3.6; patch -p1 < patch.debdiff'
[20:55] <arges> that fails
[20:55] <arges> for me
[20:56] <kentb> arges: yeah. it just did for me too
[20:57] <arges> kentb: ok cool. Yea just fix that up, and re-attach that debdiff, and I'll give it another look. Thanks!
[20:59] <kentb> arges: will do. sorry about that
[20:59] <arges> kentb: its not a problem  : )
[21:05] <jtaylor> hallyn: http://launchpadlibrarian.net/157807141/qemu_1.6.0%2Bdfsg-2ubuntu3_1.6.0%2Bdfsg-2ubuntu4.diff.gz
[21:06] <hallyn> jtaylor: yeah i don't think you can have that patch without having  qemu-user-aarch64
[21:07] <jtaylor> xnox: didn't you have something working at some point ^?
[21:08] <jtaylor> I think in irc he mentioned that that was dropped in the merge too
[21:31] <infinity> hallyn: The first half of that patch is specifically about arch combinations that don't need virt.
[21:31] <infinity> The second half, sure, is about what might need virt, and that won't work until qemu-user works, but future proofing scripts never hurts.
[21:32] <infinity> But the second part was wrong.
[21:32] <infinity> Since it needs to map arm64 to aarch64.
[21:33] <hallyn> infinity: are you saying the first half of the patch woudl still be appropriate?
[21:34] <infinity> hallyn: Yeahp.  And should also have amd64-x32 and x32-amd64 added.
[21:34] <hallyn> if so, xnox could you send me a debdiff for the good part?  (or upload if you prefer, but lemme know and i'll push it to my git repo)
[21:35] <infinity> (And probably i386-x32/x32-i386 too... Starting to highlight how that little case doesn't really scale)
[21:42] <hggdh> micahg: hi, someone from the DMB must accept the invite for ubuntu-uploaders to join bugcontrol
[21:58] <kentb> arges: okay. got it sorted this time. file is openwsman-latest.debdiff
[21:58] <arges> kentb: ok
[22:20] <arges> kentb: do you need two different changelog entries for this upload? or could they be combined?
[22:20] <arges> kentb: and i couldn't find this in debian, is it not included there yet?
[22:21] <kentb> arges: they can be combined.  debian does not have this yet, although I'm going to try and work on that on the side so we just sync in the future
[22:21] <arges> cool
[22:23] <arges> kentb: everything else looks good, and it builds fine for me
[22:24] <arges> kentb: uploaded
[22:25] <kentb> arges: awesome. thank you, sir!
[22:25] <arges> np
[22:25] <arges> kentb: thank you for getting all this stuff updated
[22:25] <kentb> my pleasure. it's been a good learning experience :-)
[22:26] <arges> and that ends my day
[22:26] <arges> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 1 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[22:28] <cjwatson> dobey: I've just gone through the local libtool in one of my projects, and there's no evidence that it would ever call /usr/bin/libtool.  It'd be extremely peculiar and pointless for it to be set up that way, so I doubt it ever happens.  I'm pretty sure any instances of this are failures to generate a package-local libtool script at configure time.
[22:30] <Logan_> When will apport start reporting to Launchpad by default in this cycle?
[22:30] <Logan_> Isn't it usually around Alpha 1 or something?
[22:34] <jtaylor> doesn't it now go to errors.ubuntu.com?
[22:59] <Logan_> jtaylor: But that's been disabled during development cycles. At some point.
[22:59]  * Logan_ pokes pitti. ^
[23:01] <sarnold> Logan_: it's a bit late/early for pitti, try again in six or seven hors..
[23:03] <robert_ancell> cjwatson, looking at out of date ttf-indic-fonts package (bug 958345). Don't suppose you can remember back to 2010 and know if any of the changes you made there are still relevant?
[23:03] <ubottu> bug 958345 in ttf-indic-fonts (Ubuntu) "ttf-indic-fonts packages is not updated for last 2 years" [Wishlist,Triaged] https://launchpad.net/bugs/958345
[23:04] <Logan_> sarnold: Will do. :P
[23:04] <robert_ancell> I think the only change we need is the ttf-indic-fonts-core package which is just a default set to save install/download time?
[23:45] <cjwatson> robert_ancell: I'm pretty sure I've looked at that before and it's been quite a lot of work to merge - needs an equivalent of the -core stuff
[23:45] <cjwatson> robert_ancell: I can have another go at it this week
[23:48] <ochosi> robert_ancell: i managed to implement the XSetScreensaver timeout stuff we talked about yesterday in the gtk-greeter by the way (rev180). (it just won't work with nouveau for some reason :D)