[00:03] <broder> l3on: actually, it looks like there have been a handful of uploads to the debian clang package. would you mind looking at this and seeing if they're worth merging?
[00:03] <broder> ugh, including a soname bump
[00:04] <l3on> broder, what you mean? :) I'm new in merging :P
[00:05] <broder> me too :-P
=== yofel_ is now known as yofel
[00:06] <broder> ok, it looks like the new version of clang is being held in debian unstable because of unmet dependencies, so let's hold off on that and just fix the package for now
[00:07] <l3on> great :)
[00:10] <l3on> broder, should I send my patch somewhere?
[00:15] <broder> l3on: probably. i would start by trying to figure out if upstream clang has any multiarch-awareness. if it does, that'd be the place to send the patch
[00:15] <broder> if not, grab the latest package from debian unstable, update its ubuntu support, and file a debian bug asking very nicely if they'd take the patch
[00:17] <andersk> l3on: Have you tested that patch?  The equivalent patch didn’t work in oneiric, and I don’t see any reason for it to work in precise either.
[00:17] <broder> andersk: really? i can link simple executables with oneiric's clang package out of box
[00:17] <l3on> andersk, me too...
[00:18] <l3on> I mean... I built a package in oneiric, that fail in precise
[00:19] <l3on> bug 896668
[00:19] <ubottu> Launchpad bug 896668 in forked-daapd (Ubuntu) "Please merge forked-daapd 0.19gcd-2 (universe) from Debian unstable " [Undecided,In progress] https://launchpad.net/bugs/896668
[00:20] <andersk> Interesting.  It was still failing for me in oneiric as of 2011-10-14.  But I’ve since upgraded to precise, and I can’t reproduce on oneiric anymore.
[00:21] <broder> i'm planning to test-build and test the packages before i upload, so i'll be sure it works
[00:21] <andersk> Anyway, can we write this patch in such a way that it doesn’t automatically break every six months?
[00:22] <broder> andersk: i'm open to suggestions
[00:22] <broder> l3on: by the way, the debdiff you uploaded is missing a trailing newline, and it confuses patch. i'll work around it, just fyi
[00:23] <l3on> is it the last line, right ?
[00:23] <broder> yeah, there's no newline at the end
[00:23] <broder> andersk: but i think a long-term fix should be discussed with upstream or at least debian, and i don't think fixing the package as it exists now should block on that
[00:24] <andersk> Like, if the distributor is Ubuntu but the codename is not one of warty, hoary, …, oneiric, precise, then it must be a future Ubuntu release, so we should assume it behaves the same as precise until we learn otherwise.
[00:24] <l3on> it's strange.. when I use gmail to send patch, if the last line is empty on LP line is replaced with a blank space... strange.
[00:24] <broder> l3on: ^ you want to try and do that?
[00:24] <andersk> See http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-June/015545.html for my last attempt to argue with upstream about this stupidity.
[00:26] <l3on> broder, I'll try ... :)
[00:26] <broder> l3on: ok. i'll wait to upload then
[00:26] <l3on> let me collect idea :D
[00:26] <l3on> mmm... upstream o debian?
[00:28] <andersk> Both.
[00:45] <l3on> andersk, broder → http://paste.ubuntu.com/750929/
[00:45] <l3on> what do you think about ?
[00:45] <l3on> that's the text I'll file as bug in upstream
[00:47] <andersk> Include a reference to my cfe-dev thread?  http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-June/015545.html
[00:49] <andersk> I’m pretty convinced that the right upstream solution is to switch back to calling gcc as a linker wrapper, like clang 2.8 did.
[00:51] <l3on> well andersk it seems you know more then me :D
[00:51] <l3on> And I'm a bit confused about what write :P
[01:00] <l3on> broder, could you merge the clang bugs ?
[01:00] <broder> l3on: merge? we don't have bug merges, we have duplicate bugs
[01:00] <l3on> just to make a note about patch ...
[01:00] <l3on> ah ok... :)
[01:01] <l3on> anyway... bug filed in upstream and linked in LP discussion
[01:01] <l3on> we'll see
[01:01] <l3on> :)
=== EvilJackyAlcine is now known as JackyAlcine
[02:51] <andersk> No matter what happens upstream, we should probably try to get Debian to do something about this.
[02:53] <andersk> The LLVM 3.0 release is scheduled in 4 days and probably won’t have this fixed.  Debian probably won’t have 3.0 for a while after that, and 3.1 for an even longer while after that.
=== mfisch` is now known as mfisch
=== mfisch is now known as Guest24696
[05:50] <broder> ScottK: can i get you to add backportbot to ubuntu-backporters?
[05:53] <micahg> broder: umm, I wouldn't be so happy about that once ubuntu-backporters has archive perms
[05:54] <broder> micahg: it's entirely under my control
[05:54] <broder> it's equivalent to giving me access, and i'm not planning to login anywhere i wouldn't login myself
[06:02] <micahg> broder: I didn't realize we had so many old open backport requests
[06:03] <broder> neither did i until today :)
[06:03] <broder> at some point i'm also going to go through and do something with requests matching /from (dapper|edgy|feisty|gutsy|intrepid|etc)/
[06:04] <broder> (i'd mark them as incomplete if we expired bugs. as it is, i'm not sure what i'm going to do; i'm inclined to mark won't fix and encourage people to re-open)
[06:05] <micahg> broder: the thing with the bot is that it's always on (usually on a server), so if that server is somewhere that's open to the world, there's a higher level of risk involved than a personal system which is probably either not always connected or behind some type of firewall/router
[06:06] <micahg> broder: won't fix seems appropriate for the task since it's a backport per project instead of series
[06:07] <micahg> also, if we can get people to use the new requestbackport tool, that would be a win as well
[06:08] <broder> is it possible for the bot to get bug triaging powers without adding it to ubuntu-backporters?
[06:10] <micahg> well, that would require making a new bug supervisor team for the backport projects with ubuntu-backporters + whoever as members (might not be a bad idea anyways)
[06:11] <micahg> but best to discuss with ScottK when he's available
=== yofel_ is now known as yofel
[11:37] <l3on> Debian bug 646350
[11:37] <ubottu> Debian bug 646350 in src:mupdf "mupdf: FTBFS with -Werror=format-security" [Normal,Open] http://bugs.debian.org/646350
=== Quintasan_ is now known as Quintasan
[13:34] <jtaylor> what happened with this backport: https://launchpad.net/ubuntu/+source/pyzmq/2.1.7-1~natty1
[13:35] <jtaylor> i386 is "building" since weeks and others never started
[13:39] <Ampelbein> Quick question about sponsor-patch. I want to use it to acknowledge sync request in bug 896849 but all I get is http://paste.ubuntu.com/751396/. What am I doing wrong?
[13:39] <ubottu> Launchpad bug 896849 in transgui (Ubuntu) "Sync transgui 3.2-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/896849
[13:39] <tumbleweed> jtaylor: hrm, I get an OOPS when I try and look at the build record
[13:39] <tumbleweed> jtaylor: but IIRC, it was blocked on backports building against backports
[13:39] <jtaylor> me too
[13:39] <tumbleweed> Ampelbein: -s
[13:40] <tumbleweed> I guess we should improve that error...
[13:40] <jtaylor> the armel log looks weird too
[13:41] <Ampelbein> tumbleweed: Thanks. I guess there is no way to skip test building (I've done that manually before).
[13:41] <tumbleweed> were the builds killed maybe?
[13:42] <tumbleweed> Ampelbein: -u ubuntu
[13:42] <tumbleweed> (instead of -s(
[13:44] <tumbleweed> broder: Any reason backport-helper doesn't link to the tracking bug in the changelog?
[13:44] <Ampelbein> tumbleweed: Thanks. Apparently I was mistaken about what sponsor-patch does for syncs.
[13:45] <tumbleweed> ack-sync used to syncpackage
[13:45] <Ampelbein> tumbleweed: I thought it would either set bug to confirmed and add a comment like "Sync acked" OR use the lp function to sync the package from debian.
[13:45] <tumbleweed> (well, at some point we made it not do that any more)
[13:46] <tumbleweed> yeah, we aren't doing native syncs in it, because natvie syncs can't indicate sponsorship yet
[13:46] <Ampelbein> I see.
[13:47] <tumbleweed> so, yes it just adds a comment
[13:47] <tumbleweed> but leaves poking archive admins to you :)
[13:47] <Ampelbein> Hmm, ok. ;-)
[13:48] <l3on> hi all.. someone could tell me which tags I should add at debian bug 650180 ?
[13:48] <ubottu> Debian bug 650180 in metis-edf "metis-edf: FTBFS - missing link at math" [Normal,Open] http://bugs.debian.org/650180
[13:49] <Ampelbein> Btw, this could be improved, too: http://paste.ubuntu.com/751409/
[13:50] <jtaylor> some add-needed tags
[13:50] <jtaylor> one moment
[13:50] <l3on> tnx :)
[13:50] <jtaylor> http://wiki.debian.org/ToolChain/DSOLinking#Not_resolving_symbols_in_indirect_dependent_shared_libraries
[13:51] <jtaylor> does it fail in debian?
[13:52] <l3on> jtaylor, what do you mean?... if in debian build fails ?
[13:53] <jtaylor> ah no its not add-needed
[13:53] <l3on> I'm started work with build fail in Ubuntu, as reported here: https://launchpadlibrarian.net/83736713/buildlog_ubuntu-precise-i386.metis-edf_4.1-2-1_FAILEDTOBUILD.txt.gz
[13:54] <jtaylor> its actually underlinking which causes problem with as-needed, http://wiki.debian.org/ToolChain/DSOLinking#Only_link_with_needed_libraries
[13:54] <l3on> submitted the fist debian bug 650178
[13:54] <ubottu> Debian bug 650178 in metis-edf "metis-edf: FTBFS with -Werror=format-security" [Normal,Open] http://bugs.debian.org/650178
[13:54] <l3on> and then the second one :)
[13:56] <tumbleweed> Ampelbein: that simply looks like a bug (the non-test-building code paths not getting enough testing)
[13:57] <jtaylor> who do I have to talk to to get that backport issue resolved? #launchpad?
[14:00] <tumbleweed> jtaylor: I don't know what happned there, but there's no point worrying about it until bug 888665 is solved
[14:00] <ubottu> Launchpad bug 888665 in Launchpad itself "Backports can't build-depend on other backports" [Critical,Triaged] https://launchpad.net/bugs/888665
[14:00] <jtaylor> ah ok
[14:24] <l3on> tumbleweed, one week has gone... debian bug 649322
[14:24] <ubottu> Debian bug 649322 in clearsilver "clearsilver: FTBFS with -Werror=format-security" [Normal,Open] http://bugs.debian.org/649322
[14:25] <l3on> should we adopt changes in ubuntu ?
[14:26] <jtaylor> no too early
[14:27] <jtaylor> we should first wait for the toolchain to be fixed
[14:28] <l3on> ok :)
[14:35] <tumbleweed> l3on: an hour after you left the channel, after filing that:
[14:35] <tumbleweed> 02:16 < cjwatson> clearsilver, in scrollback: please don't touch that
[14:36] <tumbleweed> 02:17 < cjwatson> I've contacted the security team about that one
[14:36] <tumbleweed> 02:18 < cjwatson> sigh, public bug report, I suppose it's too late
[14:37] <l3on> mmm... so I did something wrong?
[14:37] <l3on> security-issue ?!
[14:37] <tumbleweed> there's a reason we made those fail builds, yes
[14:37] <tumbleweed> many of them aren't dangerous, that one probably is
[14:38] <jtaylor> I don't see an issue with a public bug though, its a thing gcc can detect since years, anyone who wants to use that knows about it anyway already
[14:38] <tumbleweed> jtaylor: yeah, it was there for anyone who was looking for it
[14:39] <tumbleweed> l3on: you did nothing wrong. You could have contacted the security team in private, if you'd realised the security risks with it, but maybe someone else would have come along and filed a bug...
[15:05] <cjwatson> l3on: clearsilver> that was an exploitable security hole, yes
[15:06] <cjwatson> l3on: I sent mail to security teams with (IIRC) the same patch, before you looked at it; haven't heard anything back though
[15:06] <cjwatson> because I thought it might benefit from a coordinated release
[15:06] <cjwatson> it's true that anyone looking for it could have found it
[15:07] <jtaylor> might be worse increasing the severty of the bug then?
[15:07] <cjwatson> jtaylor: "we should first wait for the toolchain to be fixed" - what fix would that be then?
[15:07] <jtaylor> cjwatson: fixed in the sense that it does not change anymore
[15:07] <jtaylor> I heard error=format-security may be disabled depending on the next rebuild
[15:09] <cjwatson> I think you're out of date - I already disabled it in dpkg-buildpackage, but dpkg-buildflags still exports it
[15:09] <cjwatson> in any case, that's no reason to delay a package upload
[15:09] <cjwatson> I'll bump that Debian bug to grave now
=== stalcup is now known as what
[15:10] <cjwatson> oh, huh, I didn't send a patch, silly me
=== what is now known as v
[15:12] <cjwatson> l3on: anyway, sorry, I didn't mean to snark really, you had no way of knowing I'd already looked at that
[15:32] <Laney> how far back can we use .orig.tar.bz2?
[15:32] <l3on> cjwatson, sorry, that was my fault ... I'm not so good understanding severity of bugs ... I need more practice :D
[15:33] <tumbleweed> l3on: erm, nothing here is your fault at all :)
[15:34] <l3on> :)
[15:38] <cjwatson> Laney: anything that supports 3.0 (quilt), so dpkg (>= 1.14.17), i.e. >= intrepid
[15:38] <Laney> cheers
[17:30] <broder> tumbleweed: that's not a backport-helper thing; it's happening at a lower level (i think mass-sync? but i'm not sure). i don't know why it's done that way
[17:30] <tumbleweed> ah, right
[17:30] <broder> probably because there's a fair amount of shared code with syncs
[17:32] <tumbleweed> of course, this is something else that LP will have to implement natively before our archive admins can lose shell access
[17:33] <broder> actually, at the TB meeting, we talked about just using backportpackage and uploading directly
[17:33] <broder> but that would block on backporters being able to process the queue
[17:33] <tumbleweed> yeah
[18:41] <Ampelbein> tumbleweed: Can you test something for me: 'lp-shell staging' and then do 'lp.bugs[851798].subscriptions[1].canBeUnsubscribedByUser()' Does that result true or false?
[18:42] <tumbleweed> True
[18:42] <Ampelbein> ok, thanks.
[18:42] <tumbleweed> err that's ubuntu-release
[18:42] <tumbleweed> ah, I was'nt on staging
[18:42] <Ampelbein> tumbleweed: Huh?
[18:42] <Ampelbein> ah
[18:43] <tumbleweed> right, still True
[18:43] <tumbleweed> I think the problem here was that PersonTeam is a wrapper around the launchpadlib object
[18:43] <tumbleweed> so == was never true
[18:44] <Ampelbein> Aye. The problem should be gone with the variable.
[18:45] <Ampelbein> There was another problem, if the sponsors team wasn't sub[0], a "Couldn't unsubscribe" would have been issued anyways.
[18:52] <Ampelbein> tumbleweed: ok, pushed a fix. It works for me now.
=== micahg_ is now known as micahg
=== EvilJackyAlcine is now known as JackyAlcine
=== Guest89395 is now known as Zic