=== xnox is now known as doko_
=== doko_ is now known as xnox
=== Ursinha-afk is now known as Ursinha
=== Ursinha-afk is now known as Ursinha
[04:44] <pabs3> hi all. on the Debian wiki we use launchpadlib to check if Ubuntu bugs and annotate the wiki with bug closed/open/title/etc info. we are finding launchpadlib to be very crashy. I recently started collecting these crashes. we have 577 unique (bug, crash) combinations, representing 197 unique crashes. I was wondering where would be the best place to send these? I don't really want to file all of them on launchpadlib because some look like launchpad ops i
[04:44] <pabs3> ssues
[04:44] <wgrant> pabs3: What sort of crashes?
[04:45] <pabs3> all sorts (everything from SSL errors to infinite recursion), let me publish a tarball, one sec
[04:47] <wgrant> The weird crashes that a lot of people used to run into were caused by using a non-threadsafe cache between threads or processes.
[04:48] <wgrant> But the default launchpadlib cache is threadsafe nowadays.
[04:48] <pabs3> http://people.debian.org/~pabs/tmp/errors.tar.xz
[04:48] <pabs3> which version is that fixed in?
[04:49] <pabs3> we are using launchpadlib in a wasgi app: http://anonscm.debian.org/gitweb/?p=collab-maint/wiki.debian.org.git;a=blob_plain;f=bin/launchpad
[04:50] <wgrant> Hah
[04:51] <wgrant> Note that it has a partial workaround for that bug
[04:51] <wgrant> If the login throws an exception at all, it nukes the cache.
[04:51] <pabs3> yeah, I wrote that particular one
[04:51] <pabs3> we were finding the cache corrupted often
[04:52] <wgrant> pabs3: You may be interested in https://launchpad.net/ubuntu/+source/lazr.restfulclient/0.12.0-1ubuntu1.1
[04:52] <wgrant> http://launchpadlibrarian.net/141870723/lazr.restfulclient_0.12.0-1ubuntu1_0.12.0-1ubuntu1.1.diff.gz is the diff
[04:53] <wgrant> It was fixed upstream in lazr.restfulclient 0.12.1
[04:53] <pabs3> great, I'll propose that for the next Debian stable release
[04:54] <wgrant> The SSL crashes look more like there's some transient network issue.
[04:54] <wgrant> But the Unicode errors etc. are very plausibly from concurrent use of a non-threadsafe cache.
[04:54] <wgrant> And the login issues as well -- the WADL is often a good target for corruption.
[04:54] <pabs3> from what I could google, the ssl things seem to be related to using front-end ssl accelerators or something
[04:55] <wgrant> FWIW, I run an awful lot of launchpadlib-using cronjobs and only see SSL errors on the rare occasion that a datacentre has a seizure
[04:59] <wgrant> pabs3: If you run into any more issues after that patch is applied, throw them at me and I'll have a look.
[04:59] <pabs3> ok
[05:00] <pabs3> poked the maintainer of lazr.restfulclient. any other potential issues come to mind?
[05:04] <wgrant> pabs3: The version in wheezy is fine apart from that patch.
[05:04] <pabs3> ok cool
=== jalcine is now known as doge_
=== doge_ is now known as jalcine
=== jalcine is now known as doge_
=== doge_ is now known as jalcine
=== chandankumar is now known as ciypro
=== BradCrittenden is now known as bac
[14:57] <tachyons> hi
[14:57] <tachyons> I successfully build my first ppa for a qt5 app
[14:58] <tachyons> it worked for 13.04(x86 and amd64) and 13.10(x86)
[14:58] <tachyons> but failed in 13.10 amd 64
[14:58] <tachyons> can anyone help for the cause of the error
[15:00] <geser> have you a link?
[15:01] <tachyons> geser, https://launchpad.net/~aboobackervyd/+archive/olam
[15:02] <tachyons> geser, https://launchpadlibrarian.net/160213273/buildlog_ubuntu-saucy-amd64.olam_1.1-1ubuntu1_FAILEDTOBUILD.txt.gz
[15:10] <cjwatson> tachyons: the problem here is that it's using the default build system, which assumes that Makefile is good enough, but that's a Makefile configured for a particular platform
[15:10] <cjwatson> tachyons: I suggest changing "dh $@" in debian/rules to "dh $@ --buildsystem qmake"
[15:11] <cjwatson> tachyons: that should cause it to reconfigure itself properly
[15:11] <cjwatson> (untested)
[15:11] <tachyons> cjwatson, just for my curiosity, then how it worked for x86 version :-)
[15:13] <cjwatson> tachyons: because the prebuilt Makefile in the tarball is built for i386
[15:13] <cjwatson> (I don't know how it worked for 13.04, I haven't checked the package there)
[15:15] <tachyons> cjwatson, I did'nt changed make file , only thing I did is added
[15:15] <tachyons> unix {
[15:15] <tachyons>     INSTALLS += target data icon desktopfile
[15:15] <tachyons>     target.files = $$TARGET
[15:15] <tachyons>     target.path = /usr/bin
[15:15] <tachyons>     data.files = db
[15:15] <tachyons>     data.path = /usr/share/olam
[15:15] <tachyons>     icon.files = misc/olam.png
[15:15] <tachyons>     icon.path = /usr/share/icons
[15:15] <tachyons>     desktopfile.files = misc/olam.desktop
[15:15] <tachyons>     desktopfile.path = /usr/share/applications
[15:15] <tachyons>     QMAKE_CXXFLAGS += -DVISRULED_DATADIR=$$data.path
[15:15] <tachyons> }
[15:15] <tachyons> to .pro file
[15:15] <dobey> tachyons: are you creating the .tar.xz upstream tarball on a 32-bit system?
[15:16] <tachyons> dobey, It is my package, no upstream :-)
[15:16] <cjwatson> tachyons: nevertheless, "--buildsystem qmake" is almost certainly the correct fix
[15:16] <cjwatson> or at least the start of it
[15:16] <dobey> tachyons: you are the upstream
[15:16] <dobey> yes, you need --buildsystem qmake
[15:17] <cjwatson> tachyons: you probably shouldn't be distributing the Makefile in your orig tarball
[15:17] <dobey> it probably worked on 13.04 because of magic
[15:17] <dobey> your orig tarball has a Makefile that was generated on an i386 ubuntu, which references the i386 qmake; which will of course be problematic on other architectures when not regenerating the Makefile
[15:18] <tachyons> I will try, I am still wondering how it worked, I don't belive in magic :-)
[15:18] <cjwatson> I don't have time to check, sorry
[15:18] <tachyons> dobey, yes,
[15:19] <tachyons> cjwatson, No problem , you already spend your valuable time for me, Thanks :-)
[15:29] <tachyons> dobey, cjwatson after changing rule , both x86 and amd64 versions failed
[15:30] <tachyons> https://launchpad.net/~aboobackervyd/+archive/olam/+packages
[15:31] <cjwatson> are you in a position to regenerate the upstream tarball without including Makefile in it?  that's really the best answer
[15:31] <cjwatson> the Makefile is platform-dependent and shouldn't be in your source tarball
[15:32] <cjwatson> (you still need "--buildsystem qmake", that was correct, just not complete)
[15:42] <tachyons> cjwatson, how to do It? can you give a guide link
=== Ursinha-afk is now known as Ursinha
=== tsmithe_away is now known as tsmithe
=== tsmithe is now known as tsmithe_away
=== tsmithe_away is now known as tsmithe
[20:54] <cristian_c> Hi
[20:54] <cristian_c> I've opened this bug report much time ago: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/972604
[20:55] <ubot5> Ubuntu bug 972604 in linux (Ubuntu) "168c:001c [Compaq Presario C700 Notebook PC] Wireless led button doesn't switch colors" [Low,Incomplete]
[20:55] <cristian_c> I was told to download and try the daily build
[20:56] <cristian_c> to verify the permanence of the bug
[20:57] <cjwatson> cristian_c: This channel is for issues with the software running on launchpad.net itself - we can't really offer help with the specific projects that are hosted on Launchpad.  You're probably better off asking somewhere like #ubuntu-kernel.
[20:58] <cristian_c> I've created the live installer, but when I boot from the device, only a blinking cursor remains  on the screen
[20:59] <cristian_c> cjwatson, ok, but I don't know how to deal with who wrote the comment
[21:00] <dobey> if you want to reply to a comment on a bug report, then do it on the bug report
[21:00] <cjwatson> Nor do we :-)  You're really better off asking #ubuntu-kernel for advice
[21:00] <cjwatson> It wasn't a comment from the site administrators or anything like that
[21:00] <cjwatson> It was just another Launchpad user
[21:01] <cristian_c> he didn't foretold this case
[21:02] <cristian_c> cjwatson, ok, but it can go a year since the last comment as last time
[21:02] <cjwatson> That's as may be ... that isn't up to the Launchpad developers
[21:02] <cristian_c> cjwatson, can I also put things like this before?
[21:02] <cjwatson> honestly, we can't possibly get involved with each of the million bugs in Launchpad
[21:03] <cristian_c> tags, etc...
[21:03] <cjwatson> if you want to know what's appropriate for an Ubuntu kernel bug, you really need to ask the people who deal with Ubuntu kernel bugs
[21:03] <cjwatson> we don't dictate policy to them
[21:04] <cjwatson> #ubuntu-kernel should be able to offer advice if anyone's around on a Friday evening this close to the Christmas break
[21:04] <cristian_c> ok, but someone manages the policy in launchpad
[21:04] <dobey> cristian_c: you need to ask in #ubuntu or #ubuntu-kernel
[21:04] <cristian_c> ok
[21:04] <dobey> policy is a per-project/distro basis
[21:05] <cjwatson> really per-package, in this case since the kernel is so complex and has so many bug reports
[21:05] <dobey> if you want help on a project or distro you need to ask them about it. this channel is for help on launchpad itself, not the policies of the projects hosted on it
[21:05] <cjwatson> even as an Ubuntu developer I wouldn't presume to say how they best manage their bugs
[21:05] <dobey> right
[21:05] <cjwatson> since I don't do more than a tiny bit of kernel work
[21:06] <dobey> and the last commentor on that bug isn't a developer. he's just a random volunteer helping with bug triage
[21:06] <cristian_c> like someone who puts his hand to open reports from users, add/remove tags, change status , assignee, ecc...
[21:07] <cristian_c> change titles, etc...
[21:07] <cristian_c> dobey, ah, ok
[21:07] <cristian_c> 'random volunteer helping with bug triage'
[21:07] <dobey> yes that has nothing to do with launchpad itself. as we said, you need to ask #ubuntu-kernel for help about a kernel bug
[21:08] <cristian_c> maybe I should ask to who manages the volunteers
[21:08] <cjwatson> right, personally I think he's probably going over the top, but I haven't really looked at a broad sample of his comments to make sure
[21:08] <cjwatson> you could try #ubuntu-bugs for that
[21:08] <cristian_c> ok
[21:08] <cristian_c> thanks, fine
[21:08] <cjwatson> he's not in obvious banning territory or anything, maybe "take it easy"
[21:09] <cristian_c> :)
[21:09] <cristian_c> perfect
[21:09] <cjwatson> (and for all I know maybe his net impact is positive - like I say, haven't checked)
[21:09] <dobey> cjwatson: right, i've had a problem with him previously on a bug i filed, but i managed to get him to leave the bug well enough alone
[21:09] <cristian_c> perfect, I'll ask in #ubuntu-bugs, or #kernel
[21:09] <cjwatson> I did have somebody mail me asking if I could advise him to tone it down
[21:10] <cjwatson> but I've been busy this week and haven't had a chance to look into it properly
[21:13] <dobey> cjwatson: my problem was that he was very insistent that bios updates from intel might magically fix my bug, regardless of whether the release notes mentioned any changes to video, or whether the video option rom was changed. and testing whether my bug is fixed or not is a very tedious process, so updating the bios on a whim every time one is released (which has been fairly often for this board), is quite problematic. and it was d
[21:13] <dobey> cjwatson: so yeah, a good "tone it down" please would probably help, if he could be made to understand he's going a bit overboard with the requests
[21:21] <cjwatson> dobey: right, though I don't know if it should be from "site staff" as it were, maybe just Ubuntu bug admins
[21:22] <dobey> cjwatson: right. that makes sense.
[21:22]  * cjwatson is all for delegation :)
=== beisner is now known as beisner_
=== beisner_ is now known as beisner
=== beisner is now known as beisner_
=== beisner_ is now known as beisner
=== Logan__ is now known as Logan_