[00:07] bdrung: daily builds back to normal again [00:10] ooh, a shiny 'cancel build' button. Seems to only apply to queued builds, though. It can't euthenase builds in progress... [00:43] any idea why you could be getting errors like: /home/psusi/btrfs-progs/scrub.c:1342: undefined reference to `pthread_create', despite the fact that you are compiling with -lpthread? [00:44] psusi: is that a link error or a compile error? [00:44] looks like a linker error. [00:44] yep, link error [00:45] i would be inclined to think that you're missing libpthread.so? [00:45] psusi: is it a -as-needed error? [00:45] (i.e. do you need to move -lpthread further down the command line?) [00:45] huh? [00:47] with --as-needed, the order of the libraries is significant [00:47] I seem to have /lib/x86_64-linux-gnu/libpthread.so.0, which points to libpthread-2.13.so [00:47] --as-needed doesn't appear to be on the command line [00:47] it's implicit on oneiric/precise [00:48] psusi: maybe pasting the full build log will help [00:48] ohh.. so what does that do? [00:48] https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition [00:49] http://paste.ubuntu.com/738814/ [00:50] (also, OT, but IIRC one should use -pthread instead of -lpthread. -pthread acts as both a preprocessor and linker flag) [00:50] hmm does it? [00:50] Hi [00:50] Can partner repos be integrated with local ubuntu mirror using deb mirror ? [00:50] psusi: push -lpthread to the back of the gcc command and see if that helps [00:51] psusi: yeah, put your -pthread after all the .o s [00:51] hrm.... so which is it, use -pthread, or move the -lpthread? [00:51] psusi: move it [00:51] the using -pthread thing was orthogonal. It popped into my head when I saw -lpthread [00:52] so.. why does the order matter? I mean hasn't everyone who has ever written a makefile assumed they can put the -l flags first? [00:53] psusi: there was some explanation in that wiki page link I pasted [00:54] there's more on Debian's page: http://wiki.debian.org/ToolChain/DSOLinking [00:56] well, reordering the arguments seems to do it... as fubar as that is... [01:35] Hi guys, I made a small change to Studio's desktop seed. Do we need to request a SRU for this to become effective? The change adds a new package, previously we only had indicator-sound but that isn't enough to see the volume icon in the Indicator Plugin. I added the -gtk2 package that does that. [01:36] Oh sorry, this was for ubuntustudio.oneiric seeds. [04:31] astraljava: you just need to get a bug in the sponsorship queue [06:44] micahg: I was hoping for such an answer. Thanks! I'll get on it. [06:45] astraljava: no need for a debdiff, just give a link to the branch with the seed in the bug [07:36] micahg: Excellent. Thanks so much! [08:02] good morning [08:09] morning === dholbach_ is now known as dholbach === sagaci_ is now known as sagaci [10:02] tumbleweed: it's %prog not %progname for optparse [10:02] "Usage: reverse-dependsname [options] package" ;-) [10:33] Laney: thanks [10:34] btw, we are still seeing uploads fall through the gap, I must work out why... [10:34] * Laney is making use of reverse-depends -b to subscribe to all haskell packages [10:35] did you find out how getPublishedSources works? [10:45] Laney: nobody replied to me [10:45] sadness [10:46] would an upper limit have any problems? [10:46] that's what I'm currently using [10:53] oh lord, won't you give me, some changes mboxes [10:59] tumbleweed: what are you trying to find out? [10:59] Laney: are you parsing mboxes? [11:00] not any more [11:01] good! :) [11:01] that actually worked rather reliably [11:01] Although i am suprised LP api exposes everything you need as a replacement. [11:01] Laney: sure, just slow and cumbersome, not to mention that -changes mailing list hasn't quite been reliable. [11:02] it doesn't get all uploads [11:02] but it wasn't very cumbersome, there are some alright libraries to parse mboxes [11:03] using lp has its own problems - publications don't correspond directly to uploads [11:03] and we haven't found out how to not miss some publications yet [11:03] Laney: Yes, i was using one to generate upload history for a given user. [11:04] Took 2 hours to do a posh grep of historic -changes.:/ [11:04] you didn't use my shiny UDD table? :-( [11:05] Laney: this predated your UDD magic. [11:05] aha [11:05] bug 610491 is a pain for me. [11:05] Launchpad bug 610491 in Launchpad itself "[API] Please expose getPublishedSources(package_creator,package_signer)" [Low,Triaged] https://launchpad.net/bugs/610491 === sagaci_ is now known as sagaci [11:07] Daviey: yeah, trying to find out how to use getPublishedSources reliably [11:09] tumbleweed: what is it missing for you? [11:09] is the problem that things can go from pending to published? [11:11] Laney: I considered that. We may want to cut off timestamp - 1hr or something [11:12] Daviey: it's hard to do multiple runs and not either get duplicates, or missing items [11:12] we should probably also have lock files [11:13] hmm, no, we don't ask for only Published records [11:34] Daviey: not being able to search by package_creator,package_signer is why I set up http://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi [11:40] tumbleweed: Oooo, nice [11:52] it'd be good if PPAs could be NotAutomatic [12:02] * tumbleweed wonders why the znc backport doesn't show up on https://launchpad.net/ubuntu/natty/+queue?queue_state=3 === azeem_ is now known as azeem [14:36] dear bzr branch, please to being faster, thanks [14:42] broder: i got some notice about the znc backport being accepted... does that mean that the bug that was blocking it was resolved? Or did they grab the binaries from the PPA? [14:56] I have what I suppose is a UDD question. According to https://launchpad.net/ubuntu/+source/btrfs-tools, the upstream for the package is Btrfs Tools => trunk, which is auto imported from the upstream git repo... [14:57] looking at the bzr history however, this appears to be false. The actual upstream appears to be debian, which is tarball auto imported from debian source packages... ergo, you can't do a bzr merge from the Btrfs Tools trunk because they have no common ancestry [14:57] isn't this borked? [15:02] UDD branches aren't in general mergeable from upstream; that's a later phase of the UDD plan [15:03] they should in general (not necessarily always) be mergeable from the Debian branch, which is where in practice we do nearly all our merging from [15:03] it was a question of priorities [15:05] so shouldn't launchpad be saying that the debian branch is upstream? [15:06] and is there a way to work around this and merge from upstream upstream? I'm thinking that it will require rebasing all of the debian/ubuntu changes onto upstream... [15:06] which would then break the ability to merge from the debian branch... [15:08] is there a plan to include firefox8 into the official repositories ? === yofel_ is now known as yofel [15:35] hrm... what if you were to find the correct upstream revision that the debian tarball came from, and then do a merge from there into the debian branch? It would be a no change merge, but then would provide the common ancestor allowing us to merge directly from upstream in the future, wouldn't it? [15:36] ohh, but you couldn't do that merge because of no common ancestor... argh. [15:48] well, launchpad is saying what the upstream *project* is. I don't know if it points to the upstream *branch* somewhere [15:48] merging from upstream would require a full rebase of both Debian and Ubuntu, yes [15:49] and given that most packaging work of that form is cherry-picking into debian/patches/ anyway, it's a relatively low priority for a lot of packages [15:49] https://wiki.ubuntu.com/DistributedDevelopment/Specification is the overall phased plan BTW [15:50] it's a huge project; we're more or less at the end of phase 2 [16:13] debfx, hi! :) [16:15] l3on: hi [16:15] debfx, hi... I read your reply to mrtg merge :)= [16:15] and you're right [16:15] I'm rebuilding it .. :) [16:16] great :) [16:22] debfx, do you suggest to append a dep3 header at patch ? [16:22] l3on: yes, always [16:28] debfx, sorry for annoying you :P... [16:28] these are my first merges,, so ... :P [16:28] In Origin: what you suggest ? [16:28] There is no specific page in changelog when patch was introduced the first time... [16:28] s/page/lp bug [16:30] in this case Description and Author is enough [16:31] oki.. author I set: Soren Hansen [16:31] it's the first guy introduced patch [16:31] mrtg has had that delta for so long [16:31] why isn't it upstream? [16:34] what is it even for, can we get rid of it? [16:35] boh :/ [16:44] debfx, ok.. I sent new patches [16:44] mmm LP does not work well with mail :/ what a mess in that reply! [17:13] Resistance: no. it means that the upload of znc itself was accepted, but the build will fail because swig hasn't been backported and the issue has not yet been resolved [17:43] hmm, somehow I don't get ppa build order … [17:44] broder: ah, i see. but it *will* be backported once that bug has been resolved? [17:45] Resistance: znc itself has been backported, but it won't be able to build until swig is backported and the bug is fixed [17:45] it's stuck in something of a purgatory state called "depwait" because its dependencies aren't all there [17:45] ah [17:45] see https://launchpad.net/ubuntu/+source/znc/0.202-1~natty1/+build/2926769 [17:45] so the status of the bug is accurate, if a bit deceptive [18:07] natty was build quite quickly, but the others aren't catching up at all [18:07] https://launchpad.net/~rhonda/+archive/wesnoth-devel/+packages [18:07] oh, one needs to complain, oneiric started building :) [18:08] i assume you're aware of why complaining is bad? [18:08] FWIW... i think the builders are just being slowish [18:09] It depends on how you define "complaining" and how it is worded. I don't think mine was that unreasonable, actually rather a question on what might be happening. === Quintasan_ is now known as Quintasan [18:24] hey all [18:45] l3on, Laney: I have no recollection of that patch, to be honest, but I don't see any reason why I didn't get it upstream. === jcfp is now known as Guest56906