[00:29] <ogra_> haha, xnox uploaded the cj<tab> fix :)
[02:03] <infinity> ogra_: Hahaha.  I should upload that same default change for irssi.  I set it locally, but never though to do it globally.
[02:04] <ogra_> :)
[02:58] <uki> Hello everyone. I'd like to perform two tasks using apt-get/aptitude. 1. Generate a list of all packages present in the Ubuntu repositories. 2. Given a package name, get a list of the packages it depends on(preferably without having to download the package source),
[02:59] <uki> Could someone help me on how I could go about doing that? Thanks in advance
[03:01] <infinity> uki: See /var/lib/apt/lists and check out dctrl-tools
[03:01] <uki> infinity: will do, thanks!
[03:01] <infinity> uki: (And those sorts of questions probably belong in #ubuntu, not here)
[03:01] <uki> ah okay, sure :)
[03:02] <uki> infinity: Just to confirm, isnt /var/lib/apt/lists a list of packages that have been installed?
[03:04] <infinity> uki: No, that's all the Packages/Sources files from the archive, listing everything you *can* install.
[03:04] <uki> infinity: I see. Thank you!
[03:08]  * infinity curses cmake.
[03:08] <psusi> ohh, I feel as though I may have just had a brilliant stroke of insight...
[03:08] <infinity> psusi: Does it involve why cmake's testsuite fails in raring?
[03:08] <infinity> *hopeful look*
[03:08] <psusi> ok... so the importer storing quilt patches already applied in the bzr branch causes many problems
[03:09] <psusi> but not doing that makes bzr blame a problem
[03:09] <psusi> so how about have the importer replay the quilt patches one at a time into separate commits in a new branch based on the unpatched branch, then merge that branch back into the master
[03:09] <infinity> I didn't think bzr blame was the motivator at all, but just making a checkout the same as an unpacked source package.
[03:10] <psusi> wait, no... maybe I'm drunk
[03:10] <psusi> I just hate the packages already being applied
[03:10] <psusi> patches rather
[03:10] <infinity> I'm not a big fan of the udd workflow at all, so I'm not arguing for or against here. :P
[03:11] <psusi> I find it fantastic when the quilt patches aren't applied
[03:15] <infinity> jbicha: Well, I've transitioned everything for libarchive13 except cmake.  The cmake testsuite is sad in raring, and I'm not sure I want to spend any more of my Sunday trying to figure out why.
[04:08] <jbicha> infinity: thanks again
[04:10] <infinity> jbicha: Also, not to be picky, but actually fixing rdup correctly was easier than ignoring the deprecation warnings. :P
[04:10] <infinity> jbicha: (Uploading the proper fix now and forwarding to Debian)
[04:12] <infinity> jbicha: Was that the only package where you ignored the deprecation warnings?
[04:15] <lifeless> infinity: rdup?
[04:16] <infinity> lifeless: Yes...?
[04:16] <lifeless> infinity: was that a typo for rdep ?
[04:16] <lifeless> infinity: or a package name ?
[04:16] <infinity> lifeless: It was a package name.
[04:17] <infinity> https://launchpad.net/ubuntu/+source/rdup/1.1.11-1ubuntu2
[04:17] <lifeless> heh, its very specific
[04:59] <jbicha> infinity: I think so, I found the proper fix for pixz
[05:08] <infinity> xnox: I know how much you *love* cmake.  I'll give you a shiny nickel if you can figure out why it FTBFS in current raring, but the same source builds fine against quantal.
=== cinerama_ is now known as cinerama
[05:40] <pitti> Good morning
[05:54] <Sarvatt> xnox: so many lols, thanks for fixing xchat that way as someone hit by sa<tab> too much :)
[07:12] <dholbach> good morning
[07:23] <wooo> hey guys I have a doubt about vnode. I think the inode for a specific file system is the vnode for virtual file system. Am I right?
[07:23] <lifeless> wooo: you might get a better answer in #ubuntu-kernel
[07:24] <lifeless> wooo: but - http://www.linuxquestions.org/questions/linux-kernel-70/difference-between-inode-and-vnode-657954/
[07:24] <lifeless> is what google tells me :>
=== doko_ is now known as doko
=== Logan_ is now known as y
[09:13] <xnox> Sarvatt: heh =) well there is no way to auto-migrate people, so existing users will need to change settings. I will be blogging about it ;-)
=== negronjl` is now known as negronjl
=== henrix_ is now known as henrix
[09:52] <seb128> hum
[09:53] <seb128> xnox, Laney, slangasek: is bug #1129157 the whoopsie/nm/ck one? did that got fixed/workedaround?
[09:53] <ubottu> bug 1129157 in lightdm (Ubuntu) "lightdm pausing a long time at boot" [Undecided,Confirmed] https://launchpad.net/bugs/1129157
[09:54]  * xnox thought the whoopsie/nm/ck was bug 1124330
[09:54] <ubottu> bug 1124330 in whoopsie (Ubuntu) "[raring] Latest whoopsie 0.2.13 slows down boot process by 29 seconds!" [High,Confirmed] https://launchpad.net/bugs/1124330
[09:55] <seb128> xnox, I'm asking if the one I pointed at is likely a duplicate or if you think it's a different issue ;-)
[09:55] <xnox> ah.
[09:55] <Laney> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1123798
[09:55] <ubottu> Ubuntu bug 1123798 in whoopsie (Ubuntu) "ubiquity-dm crashed with dbus.exceptions.DBusException in call_blocking(): org.freedesktop.DBus.Error.TimedOut: Activation of org.freedesktop.ConsoleKit timed out" [High,Confirmed]
[09:55] <Laney> I suppose it could be a dupe
[09:55] <seb128> I wonder how many different bugs we have for the issue :p
[09:57] <Laney> I wonder if we should revert that libnm-glib stuff for now
[09:58] <Laney> it was supposed to fix some leak but the problems it introduces seem to be worse
[09:58] <seb128> yeah
[09:58] <seb128> I'm still unsure how it does manage to screw ck though
[09:58] <seb128> it's weird that a buggy dbus service manages to break ck
[09:59] <Laney> ev: ↑
[10:00] <ev> Laney: I'm worried that we're just kicking the can
[10:01] <seb128> ev, well, we can't keep raring broken for users, we either need somebody to focus on it and fix it soon or to revert until we can come with a fix
[10:01] <seb128> it seems like nobody has a good understanding of the issue and that it might take a while so maybe best to revert
[10:02] <ev> fair point
[10:02] <ev> adding it to my todo list for today
[10:03] <jamespage> doko, re the zookeeper FTBFS with gcc-4.8 and glibc-2.17 - I think that is glibc as I've been hitting those same test failures in raring
[10:04] <seb128> ev, thanks
[10:08] <doko> jamespage, ok, could you change the user/usertag ?
[10:10] <jamespage> doko, sure
[10:13] <xnox> doko: ... and you are expecting me to fix all the debian-med gcc4.8 failures?! =))))
[10:13]  * xnox got spammed by doko
[10:15] <Laney> what changed to make my VMs reeeeeeeeallly sloooooooooooooooooooooowww?
[10:16] <diwic> if you'd like one FTBFS less, feel free to sponsor bug 1074673
[10:16] <ubottu> bug 1074673 in ubuntu-nexus7 "JACK server fails to start" [Medium,Triaged] https://launchpad.net/bugs/1074673
[10:16] <Laney> qemu-system-x86 is using all of one core
[10:17] <tumbleweed> no kvm?
[10:17] <Laney> there should be
[10:17] <seb128> diwic, are those fixes including in jackd upstream? Debian has a new version, maybe we should sync that?
[10:19] <diwic> seb128, the FTBFS fix is is upstream. Also in Debian, but I tried the git version, but it has other FTBFSes instead
[10:19] <seb128> diwic, ok
[10:20] <diwic> seb128, the fix for arm is still under debate upstream, but I figure it would be better to have something with a theoretical issue, than not working at all
[10:20] <seb128> diwic, I was just asking in case, I saw that our version is older than the Debian one and was wondering if it would make sense to sync the new one
[10:20] <seb128> diwic, right
[10:20] <diwic> seb128, sure, that's a fair question, I tried that too, first, and it failed with FTBFS even earlier :-)
[10:26] <Laney> yeah "kvm support: disabled"
[10:26] <Laney> permissions on /dev/kvm seem ok
[10:27] <Laney> hmm or maybe not
[10:29] <Laney> ah yes, reboot → correct now
[10:32] <seb128> Laney, :-(
[10:32] <seb128> starting sounding like old time win, stuff don't work, let's reboot
[10:33] <Laney> it's a bug where after you upgrade qemu the permissions of /dev/kvm are set to root:root
[10:33] <Laney> if you get the udev event to fire (e.g. by rebooting) then they are set correctly
[10:33] <Laney> hallyn is trying to fix it
[10:33] <seb128> ok
=== Sweetsha1k is now known as Sweetshark
[10:53] <ev> mpt: the quote on my desk comes from this book: http://www.amazon.com/Controlling-Software-Projects-Management-Measurement/dp/0131717111
[10:54] <ev> was just reading a slide deck that referenced it and remembered that I never gave you a link to the book
[10:54] <ev> I've never read it myself - I came by it via an article he wrote for the IEEE
[11:35] <shakaran> Hi, there are some plan for fix nvidia drivers before to raring release? I am worry for don't get a working driver at time of 13.04 https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/1083925
[11:35] <ubottu> Ubuntu bug 1083925 in nvidia-graphics-drivers-updates (Ubuntu) "nvidia kernel module failed to build on kernel >= 3.7 [error: #error remap_page_range() conftest failed!]" [Undecided,Confirmed]
[12:26] <bdrung> xnox: thanks for fixing bug #189222
[12:26] <ubottu> bug 189222 in xchat (Ubuntu) "Xchat changes focus to new channels after automatic joins on connect and clears highlight" [Low,Fix released] https://launchpad.net/bugs/189222
[12:26] <xnox> bdrung: thank you =)
[12:27]  * xnox feels like a rock-star. This is second Kudos about a single upload on irc ;-)
[12:27] <Laney> next stop LWN
[12:27]  * bdrung looks at the bug again.
[12:27] <xnox> Laney: I'm yet to be featured on LWN =)
[12:27] <bdrung> xnox: ah, you just enabled my workaround :)
[12:28]  * xnox is quite happy with 3 appearances in "3Touch" magazine (the only UK volleyball magazine)
[12:28] <Laney> get you
[12:28] <Laney> (hope you forwarded these changes to debian)
[12:29] <xnox> bdrung: yeah, so no manual migration. But I was sick of that bug to the point of almost switching to *gasp* quassel (no libmessaging) or smuxi (mono/no channel tree view)
[12:29] <xnox> Laney: well....
[12:29]  * xnox has a backlog of stuff to forward.
[12:29]  * Laney glares at (mono)
[12:31] <xnox> My library is in /lib should the dev .so be in /lib or can it stay in /usr/lib ?
[12:31] <xnox> What's the best practice?
[12:31] <xnox> (or it doesn't really matter as long as pkg-config works correctly)
=== _salem is now known as salem_
[13:01] <lool> cjwatson: -proposed migration currently considers installability with Depends/Conflicts etc., but do we have a way to detect that a package misses conflicts/replaces?  I've got an upgrade error with latest gtk+2.0 and am thinking that we ought to have some kind of check to avoid this to users of the rolling release
[13:01] <lool> (this seems to involve :amd64 and :i386 packages on the same system, so might be trickier than just within one arch)
[13:03] <seb128> lool, if you can debug that one I would welcome that, it seems the file that ough to be the same between archs is different
[13:06] <cjwatson> lool: No, there's no code to do that at the moment
[13:06] <cjwatson> (And it's pretty hard)
[13:06] <cjwatson> Multiarch file differences are indeed not a matter of missing Replaces
[13:11] <lool> cjwatson: Yeah, it wasn't actually a conflict/replace issue but rather a difference between files wihch should be identical
[13:11] <lool> cjwatson: I wonder whether we ought to run a separate service generating hints to not allow promotion of broken updates tough
[13:11] <lool> *though
[13:12] <seb128> lool, before that upload in seems like the amd64 binary had a symlink for /usr/share/doc/gtk2-engines-pixbuf/README.gz
[13:12] <seb128> Laney, ^
[13:14] <seb128> -	dh_compress -s -X.sgml -X.devhelp -XNEWS -Xchangelog.Debian -XREADME
[13:14] <seb128> +	dh_compress -s -X.sgml -X.devhelp
[13:14] <seb128> in the update's diff
[13:14] <seb128> not sure why that would lead to that though
[13:14] <lool> -	dh_compress -s -X.sgml -X.devhelp -XNEWS -Xchangelog.Debian -XREADME
[13:14] <lool> +	dh_compress -s -X.sgml -X.devhelp
[13:14] <lool> Yes
[13:14] <lool> seb128: clearly just a change to the arch dep packages rather the arch-indep ones for one
[13:14] <seb128> right
[13:15] <lool> seb128: Funny we've found it at the same time :)
[13:15] <seb128> lool, do you want to fix it or should I?
[13:15] <lool> seb128: I'm happy if you do
[13:16] <seb128> lool, ok
[13:16] <seb128> lool, hum, weird, the -i call is identic
[13:16] <seb128> 	dh_compress -i -X.sgml -X.devhelp
[13:17] <lool> seb128: got changed in r15782
[13:17] <lool> * Apply multiarch patch by Javier Serrano Polo, replacing all
[13:17] <lool>   occurrences of usr/lib by $(LIBDIR). Closes: #468100.
[13:17] <lool> * rules: don't compress .sgml and .devhelp files.
[13:17] <lool> seb128: Sorry, wrong branch
[13:18] <seb128> lool, we had
[13:18] <seb128> -    - Use -XNEWS -Xchangelog.Debian -XREADME to dh_compress calls to
[13:18] <seb128> -      workaround a gzip issue leading to different md5sum between builds
[13:18] <lool> seb128: It seems like a merge error
[13:19] <seb128> but I though that gzip issue got fixed in between
[13:19] <lool> seb128: Was it actually so that it was a gzip issue?
[13:20] <seb128> yes
[13:20] <lool> seb128: perhaps it was hiding this other issue with pkgbinarymangler interfering
[13:20] <seb128> the .gz were getting different md5 on i386 and amd64 for sure
[13:20] <seb128> but maybe it was hiding a second issue as well
[13:20] <xnox> interesting.
[13:21] <lool> seb128: I guess because of the difference of checksums we had -X for a while, but it wouldn't have worked with pkgbinarymangler also interfering and making files to symlinks only in some builds
[13:21] <Laney> it's weird that the symlinke from e.g. libgtk2.0-0 works
[13:21] <seb128> yeah, and symlinks from previous built worked
[13:22] <seb128> builds
[13:23] <Laney> ah
[13:23] <Laney> they're done manually
[13:24] <Laney> see debian/*.links.in
[13:25] <lool> that's even weirder, why wouldn't it have symlinks in one case?
=== AbsintheSyringe2 is now known as AbsintheSyringe
[13:26] <lool> ah I guess they get generated the same, but then pkgbinarymangler outsmarts them
[13:27] <seb128> but why wasn't it doing that before then?
[13:28] <lool> if that's the issue, we could set NO_DOC_PKG_MANGLE to avoid this
[13:28] <seb128> or just drop the .links.in and let pkgbinarymangler does its job?
[13:28] <seb128> do*
[13:29] <lool> seb128: that might be more delta with Debian though
[13:30] <seb128> yeah
[13:30] <seb128> lool, I'm still not sure to understand what's happening exactly there though
[13:31] <seb128> Laney, are you working on it? (no need to be several debugging the issue, I'm happy to let you investigate if you are already doing that)
[13:31] <seb128> I'm over the "read the diff to spot a potential merge error"
[13:31] <seb128> that needs some debugging
[13:32] <Laney> sure I'll look at it
[13:32] <lool> seb128: clearly I see why pkgbinarymangler wouldn't work the same on amd64
[13:32] <seb128> lool, oh, why?
[13:33] <seb128> Laney, thanks
[13:33] <lool> it walks all deps, and skips the ones where test -d ../$dep/usr/share/doc fails
[13:33] <xnox> missing arch_all package build?! but how would that matter.
[13:33] <lool> so it wont go through the same candidates
[13:34] <lool> hmm actually it discards deps on arch: all entirely anyway
[13:34] <seb128> the easiest way seems to add back those files to the dh_compress
[13:35] <seb128> though I'm still unsure if that's this change who leads to the issue, and why we had a compressed file before if we were excluding them from dh_compress
[13:40] <lool> seb128: So one difference between libgtk2.0-0 and gtk-pixbuf is that both have a .links.in file, but dh_installdocs is only called on gtk-pixbuf
[13:40] <lool> *gdk
[13:41] <lool> (search for DH_INSTALLDOCS_FILES in rules)
[13:43] <Laney> bah, I got a symlink in my test build
[13:43] <seb128> Laney, did you build the arch all?
[13:43] <Laney> no
[13:44] <seb128> :-(
[13:44] <Laney> perhaps pkgbinarymangler didnt run though
[13:48] <Laney> ah, whoops I did build with -A (stupid muscle memory)
[13:54] <Laney> that's better
[13:55] <Riddell> doko: I've a probably fix for qtwebkit on powerpc
[13:55] <Riddell> doko: qtwebkit-source_2.3-0ubuntu5.debdiff
[13:55] <Riddell> doko: think I can just upload or does it need testing somehow?
[13:55] <doko> Riddell, just upload
[13:56] <Riddell> doko: can you eye it over for syntax sanity? http://paste.kde.org/680882/
[13:59] <doko> Riddell, ok. just curious why build-webkit is called twice ...
[14:01] <Riddell> doko: I don't even remember, I just know it broke on the first run :(
[14:02] <doko> Riddell, could something similiar be done with qt5?
[14:02] <Riddell> doko: similar to what?
[14:03] <Riddell> doko: it's waiting on qtlocation5-dev
[14:04] <doko> Riddell, yes, building qtlocation5-dev without the js dependency
[14:04] <Riddell> mm qtjsbackend broken
[14:12] <doko> ScottK, are you involved with boost in Debian?
[14:12] <ScottK> doko: No.
[14:12]  * xnox hides
[14:13] <Riddell> doko: hmm syntax failed, it added the ENABLE_JIT=0 on i386 https://launchpadlibrarian.net/132300747/buildlog_ubuntu-raring-i386.qtwebkit-source_2.3-0ubuntu5_FAILEDTOBUILD.txt.gz
[14:14] <doko> Riddell, you asked me to check syntax, not semantices ;-p
[14:15] <Riddell> ifneq (,$(filter $(DEB_HOST_ARCH),powerpc))  that's true on i386?
[14:15] <Riddell> make is scary foo
=== wedgwood_away is now known as wedgwood
[14:28] <seb128> diwic, was there any issue with syncing jackd2 from debian? I saw that bdrung did that rather than using your patch, but this morning you seemed to imply your patch was still needed?
[14:29] <diwic> seb128, argh
[14:29] <seb128> diwic, it built, not sure if it will work
[14:30] <bdrung> i checked the diff and saw that the proposed patches were included
[14:30] <diwic> bdrung, the ARM patch too?
[14:30] <diwic> bdrung, the one with PACKED something
[14:32] <bdrung> diwic: yes, both
[14:35] <diwic> bdrung, ok, found it.
[14:35] <diwic> bdrung, seb128 thanks for looking it up. Let's try this version then and see if it works.
[14:35] <seb128> diwic, thanks
=== kentb-afk is now known as kentb
=== salem_ is now known as _salem
=== _salem is now known as salem_
[15:37] <steven____> hey all
[15:37] <steven____> is this the correct channel for questions about developing applications?
[15:39] <xnox> steven____: #ubuntu-app-devel is a better place =)
[15:39] <steven____> ok, then ill go there
[15:39] <steven____> thx :)
[15:39] <xnox> steven____: #ubuntu-packaging for creating a deb from a ready application
[15:39] <xnox> steven____: np.
[15:41] <steven____> nah, will take some time before its ready to be packed...
=== kentb is now known as kentb-afk
[16:07] <psusi> smoser: I backported the online resize patches to our parted and pushed the branch if you are interested in testing it.  Not sure if it's a little late in the cycle to merge it or not.
[16:08] <smoser> psusi, https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1096999 ?
[16:08] <ubottu> Ubuntu bug 1096999 in util-linux (Ubuntu) "add new partx update and resize upstream features" [Low,Fix released]
[16:09] <smoser> that shows fix-released. ie, i thought i uploaded that for you.
[16:09] <smoser> oh.  *parted*. gotcha.
[16:10] <smoser> psusi, i dont think its too late in the cycle.
[16:10] <smoser> but i'd ask someone else who has been active in parted package.
[16:26] <mterry> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mterry
[16:29] <xnox> smoser: psusi: sounds like we should find resources to port d-i then continuing to backport parted features.
[16:29] <xnox> s/then/than/
[16:30]  * dholbach hugs mterry
[16:35] <psusi> xnox: that would be nice
=== kentb-afk is now known as kentb
=== Elbrus_try_again is now known as Elbrus
=== deryck is now known as deryck[lunch]
=== fginther is now known as fginther|lunch
=== henrix is now known as henrix_
=== henrix_ is now known as henrix
[18:09] <psusi> does anyone know if landscape-client release 13.02 is planned to make it into raring?
[18:10] <xnox> psusi: it should, why do you ask? anything interesting you are after?
[18:11] <SpamapS> Unpacking replacement gtk2-engines-pixbuf:amd64 ...
[18:11] <SpamapS> dpkg: error processing /var/cache/apt/archives/gtk2-engines-pixbuf_2.24.16-1ubuntu1_amd64.deb (--unpack): trying to overwrite shared '/usr/share/doc/gtk2-engines-pixbuf/README.gz', which is different from other instances of package gtk2-engines-pixbuf:amd64
[18:11] <SpamapS> known bug?
[18:13] <Laney> yes
[18:15] <SpamapS> Ok, will just move on. :)
[18:17] <psusi> xnox: yes, I patched it to report the *correct* memory usage.. it was merged upstream, just wondering if I can delete the merge request to ubuntu since upstream will have it next time it releases and is merged
[18:18] <xnox> psusi: if it landed in the upstream branch, there is no need for any other merge proposals / branches.
[18:32] <jbicha> pitti: do you know of a way to enable apport for just specific PPAs? I was just using this basic code http://paste.ubuntu.com/5565457/
=== deryck[lunch] is now known as deryck
=== wedgwood is now known as wedgwood_away
=== wedgwood_away is now known as wedgwood
=== henrix is now known as henrix_
[21:14] <dobey> xorg has SIGABRTed on me 3 times in the last 18 hours or so, so far. :( same crash as a bug report i filed a few weeks ago. who can i bribe to fix it?
[21:14] <tumbleweed> mterry: you can leave Logan_ to upload his own packages now - he just joined MOTU
[21:14] <mterry> tumbleweed, oh nice  :)
[21:15] <mterry> Logan_, congrats; I'll leave you to it
[21:15] <Logan_> Thanks! :)
[21:18] <infinity> dobey: You can bribe me.
[21:18] <infinity> dobey: I won't fix it, but I could use some spending money.
[21:18] <dobey> here's a nickel kid. :)
[21:19] <infinity> dobey: I wonder if that's the same nickel I was offering to get someone to fix cmake's testsuite on raring.  That thing gets around.
[21:19] <mterry> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[21:20] <dobey> could be
[21:20] <infinity> kenvandine: Say, you're TIL on cmake.  Any urge to sort out WTF it doesn't pass its testsuite anymore?
[21:21] <kenvandine> infinity, ugh... not really
[21:21] <kenvandine> i haven't done much with cmake
[21:21] <infinity> kenvandine: Probably more than I have.
[21:21] <kenvandine> just re-applied a patch that someone had accidentally dropped
[21:21] <kenvandine> i can take a look
[21:21] <kenvandine> but no promises :)
[21:22] <infinity> Yeah.  I was doing the same "I'll look, but no promises" thing this week, but clearly someone needs to hunt it down.
[21:22] <infinity> I haven't dug far enough to determine if it's a cmake bug, a testsuite bug, or if something fundamentally broke in the toolchain or a dependency that broke it.
[21:22] <infinity> But a simple rebuild fails now.
[21:23] <infinity> (And it needs a rebuild for the libarchive transition)
[21:23]  * kenvandine grabs the source
[21:24] <infinity> kenvandine: For the record, it's not libarchive that breaks it, cause building against only the release pocket also breaks, no need for proposed to reproduce.
[21:24] <infinity> (Not that I'd expect libarchive to be the culprit, as the test that fails is some xmlrpc submission thing)
[21:25] <infinity> There has been a new version of cURL, which seems a likely candidate.
[21:25] <infinity> mdeslaur: So maybe this is your problem. :P
[21:29]  * infinity has a thought...
[21:29] <xnox> infinity: where do you see cmake not passing it's testsuite ?!
[21:29] <infinity> I wonder if it's double-linking two different libcurls or something.
[21:29] <infinity> xnox: On a rebuild.
[21:29] <xnox> infinity: ah.
[21:30]  * infinity spins up another test build here to save the binaries.
[21:30]  * xnox looks at his +1 maintainance availability and notices that has None =))))
=== fginther|lunch is now known as fginther
[21:41] <infinity> pitti: Around?
[21:56] <mterry> zul, I'm looking at the rtslib MIR.  Why the fb27 version suffix?
[21:59] <barry> tumbleweed: ping
[21:59] <kenvandine> infinity, indeed i libcurl looks suspicious
[22:00] <tumbleweed> barry: yeah?
[22:00] <kenvandine> there is a crash in some xmlrpc test that says libcurl in the output
[22:00] <kenvandine>  Submission problem: libcurl failed to execute the HTTP POST transaction, explaining:  <url> malformed (-504)
[22:01] <barry> tumbleweed: hi.  i just merged a fix to trunk and uploaded to pypi for bug 1132125.  i want to get this into ubuntu, but i am happy to update the debian package to wadllib 1.3.2 first.  you're the maintainer, is this cool with you?
[22:01] <ubottu> bug 1132125 in python-wadllib (Ubuntu Raring) "python-wadllib ftbfs in raring" [High,Fix released] https://launchpad.net/bugs/1132125
[22:01] <tumbleweed> barry: please go ahead
[22:01] <barry> tumbleweed: if you want to review the svn changes first, that's also fine
[22:02] <tumbleweed> happy to review & sponsor it
[22:02] <barry> tumbleweed: awesome, thanks.  i'll ping you after i test the rebuild and commit svn (should be soon-ish)
[22:04] <kenvandine> infinity, although i can't make heads or tails of how to isolate that test right now...
[22:04] <kenvandine> i gotta head out
[22:05] <kenvandine> infinity, make test succeeds in the /Build/Tests/CTestTestFailedSubmits/xmlrpc dir
[22:06] <kenvandine> which looks like where it blew up
[22:06] <mdeslaur> infinity: hum, what now?
[22:06] <mdeslaur> infinity: what'd I break?
[22:14] <infinity> mdeslaur: Shot in the dark, but it seems that the new cURL broke cmake's testsuite somehow.
[22:14] <infinity> mdeslaur: None of us being terribly familiar with cmake or its tests, it's a bit of a learning curve to hunt. :P
[22:14] <mdeslaur> infinity: the cmake that's currently in raring, or a new one from debian?
[22:14] <infinity> kenvandine: Yeah, make test gives the same output as the build log, minus the next bit...
[22:15] <infinity> mdeslaur: The current one in raring.  Rebuilding it breaks.
[22:15]  * mdeslaur tries now
[22:15] <infinity> mdeslaur: And it built fine less than a month ago, so that limits the options for what broke it.
=== salem_ is now known as _salem
=== seb128_ is now known as seb128
[22:44] <jtaylor> barry: mind looking over the patch in https://bugreports.qt-project.org/browse/PYSIDE-145 if you happen to know details about the mechanism and change
[22:45] <jtaylor> barry: a generated file looks like this: http://paste.ubuntu.com/5566184/   *_nonstatic is added
[22:45] <barry> jtaylor: sure.  i'm sitting on my thumbs anyway until svn.debian.org's fail2ban lockout expires ;)
[22:45] <jtaylor> barry: related to bug 1070772
[22:45] <ubottu> bug 1070772 in shiboken (Ubuntu) "modelview_test.py segfaults python" [High,Confirmed] https://launchpad.net/bugs/1070772
[22:47] <jtaylor> barry: the context is shiboken adds some kind of wrapper which works for static and nonstatic overloads
[22:47] <jtaylor> barry:  e.g. obj.exists() calls the nonstatic one, and class.exists('filename') the static one
[22:48] <jtaylor> apparently the nonstatic one is found over the getattro, so I added the new PyDef and used it there
[22:48] <jtaylor> PyMethodDe
[22:53] <barry> jtaylor: i see nothing in py33's Misc/NEWS file about the change (doesn't mean it didn't happen of course).  what exactly is the behavior change?
[22:53] <jtaylor> barry: previously it used the same METH_STATIC function for both and it passed NULL for self in the first case nevertheless
[22:53] <jtaylor> barry: now both calls get NULL
[22:54] <jtaylor> barry: not sure why but its not surprising me, defining a function static is certainly not part up pythons api
[22:54] <jtaylor> so they can break it without documenting
[22:54] <jtaylor> defining static when its not
[22:56] <barry> jtaylor: interesting!
[22:59] <barry> jtaylor: i don't even see any mention of METH_STATIC in upstream `hg -v -b 3.3 log` output
[22:59] <jtaylor> hm
[23:00] <jtaylor> it might have been broken in older python3
[23:00] <jtaylor> I think older versions did not run the testsuite
[23:01] <barry> jtaylor: but definitely a py2/py3 change?
[23:01] <jtaylor> hm no it worked in debian with 3.2
[23:02] <barry> hmm, maybe the change didn't happen in Objects/methodobject.c
[23:05]  * xnox was sure to be able to reproduce the shiboken fail with other pythons.
[23:05]  * xnox quickly scans my local build logs
[23:05] <jtaylor> xnox: the segfaults happens with all
[23:05] <jtaylor> xnox: the static fail only with python3
[23:06] <xnox> ah, ok.
[23:06] <barry> jtaylor: http://paste.ubuntu.com/5566184/
[23:06] <barry> jtaylor: i'm wondering if lines 355-356 should be out side of the if(self) test?
[23:07] <jtaylor> barry: you mean if self is null it should return the static one?
[23:08] <barry> jtaylor: just guessing, but maybe the PyObject_GGA() will dtrt anyway
[23:08] <barry> jtaylor: nm
[23:08] <barry> jtaylor: i'm reading static/nonstatic backwards
[23:09] <barry> _exists is the class version _exists_nonstatic is the instance version
[23:13] <jtaylor> barry:  my irc server seems to be down :/
[23:13] <jtaylor> barry did you say something since line 355-... ?
[23:14] <barry> <barry> jtaylor: nm
[23:14] <barry> <barry> jtaylor: i'm reading static/nonstatic backwards
[23:14] <barry> <barry> _exists is the class version _exists_nonstatic is the instance version
[23:14] <barry>  
[23:14] <barry> jtaylor: so i think it looks sane
[23:15] <barry> jtaylor: the diff in qt-project.org is a bit hard to read due to lack of context and my unfamiliarity with the code, but the generated file doesn't look bad
[23:17] <barry> tumbleweed: r23595
[23:17] <jtaylor> yey im back
[23:18] <jtaylor> the ttests all succeed so the diff is probably ok, the segfault is more problematic
[23:18] <barry> jtaylor: it stops segfaulting after that patch though right?
[23:18] <jtaylor> one could add an intentional memleak or ignore the test, possibly having a broken py3 package
[23:19] <jtaylor> don't know whats better
[23:19] <jtaylor> barry: no that patch fixes to other failures
[23:19] <barry> oh ;)
[23:20] <barry> i hate memleaks, but sometimes those things are really horribly painful to track down.  is it in a high traffic section?  (like, leak 1k every time you type the letter 'e'? ;)
[23:20] <jtaylor> good question, no idea
[23:21] <jtaylor> I wanted to try it, but I fail since ages to install raring
[23:21] <jtaylor> the test is named modelview so its probably a core component
[23:21]  * xnox wants to hear the 1k leak on 'e' story, as it sounds so hilarious that it may have been actually true.
[23:22] <jtaylor> the code is horrible, its full of races even without the crash line
[23:22] <barry> xnox: mostly fictional, but i do have another fun one that is kind of similar.  for another time perhaps :)
[23:22] <barry> jtaylor: that makes me sad
[23:23] <jtaylor> xnox: there is a bug on OS X if you type 8 characters almost every app will crash :) I think its fixed no though
[23:23] <barry> jtaylor: yeah, i think they released a fix for that.  it was like a file://// path typed somewhere
=== jtaylor_ is now known as jtaylor
[23:25] <jtaylor> < offline, lets hope upstream replies to one of the bugs soon :/
[23:26] <jtaylor> barry, thx for the check
[23:27] <xnox> bug 248619 was fun, especially it's consequences of not being able to print on tuesdays, see bug 255161 with "it works today" "it stopped working" "it works yet again!"
[23:27] <ubottu> bug 248619 in file (Ubuntu Karmic) "file incorrectly labeled as Erlang JAM file (OOo does not print on Tuesdays)" [High,Fix released] https://launchpad.net/bugs/248619
[23:27] <ubottu> bug 248619 in file (Ubuntu Karmic) "duplicate for #255161 file incorrectly labeled as Erlang JAM file (OOo does not print on Tuesdays)" [High,Fix released] https://launchpad.net/bugs/248619
[23:35] <xnox> jtaylor: well upstream does mention that all patches should go via geritt code review instance, which has a few old pyside patches lingering.
[23:36] <xnox> I wonder if we can find to poke some people about them.
=== kentb is now known as kentb-out