[00:45] <RAOF> infinity: You win a “netinst is broken on quantal, works on precise” award!
[04:10] <infinity> RAOF: Just what I always wanted.  And a bit disappointed because, in theory, we have people testing and QAing this stuff. :/
[05:06] <vibhav> I was having a look at http://people.canonical.com/~ubuntu-archive/NBS/libsclang1 and saw that debian/control file of supercollider (which is listed in reverse-depends) does not have libsclang1 as any Dependency. Does this mean that the package is auto-selected and we just need a rebuild for the transition?
[05:27] <infinity> vibhav: Probably, yes.  Most library dependencies are a product of the build, not hard-coded.
[05:28] <infinity> vibhav: In that case, the problem is that supercollider is FTBFS on arm and powerpc.
[05:30] <infinity> vibhav: Looks like a new upstream coming "soon" will fix it.
[06:40] <dholbach> good morning
[07:09] <dholbach> didrocks, salut mon ami!
[07:09] <didrocks> hey hey dholbach!
[07:09] <dholbach> didrocks, are you going to join us in #ubuntu-arb? :)
[07:09] <didrocks> yep, coming :)
[07:14] <vibhav> infinity: So should I file abug for transition or wait for a new upstream vversion?
[07:15] <infinity> vibhav: The latter.
[07:15] <infinity> vibhav: A bug won't magically make the package build, it'll just make someone mstakenly reupload it and it'll fail again. :P
[07:16] <vibhav> infinity: Yeah, I meant filing a bug and providing a debdiff. But anyways, lets wait for the next upstream version
[07:16] <infinity> vibhav: A debdiff for what?
[07:17] <vibhav> infinity: transition. We just need a rebuild
[07:17] <infinity> vibhav: No.
[07:17] <infinity> vibhav: Look more closely, this is what I've been telling you.
[07:17] <infinity> vibhav: It's already been rebuilt and transitioned on i386 and amd64, but it failed to build on arm and powerpc.
[07:17] <vibhav> infinity: ah, I didnt see that
[07:17] <infinity> vibhav: No matter how many times you reupload it, it won't magically start working.
[07:18] <vibhav> infinity: I didnt know it had FTBFSed on arm and powerpc
[07:18] <vibhav> anyways, thanks
[07:18] <infinity> vibhav: I did mention it previously. :P
[07:19] <vibhav> infinity: yeah *slaps forhead*
[07:19] <vibhav> Strange, netinst doesnt seem to work in the daily builds
[07:19] <infinity> On which arch?
[07:20] <vibhav> i386
[07:20] <vibhav> ah wait, its my internet connection
[07:22] <vibhav> infinity: On which arch did you break netinst?
[07:23] <infinity> vibhav: I didn't, personally, but I hear it's broken on ARM.  But it's a long weekend for me, so I'm deep in "not caring" mode today. ;)
[07:29] <nigelb> infinity: Canada? :)
[07:30] <infinity> nigelb: *waves flag*
[07:31] <vibhav> hah
[09:25] <cjwatson> Sweetshark: https://dogfood.launchpad.net/~cjwatson/+archive/dogfood-copy-target/+packages - libreoffice copied in there using +copy-packages.  This isn't doable on production yet but I thought you might like to know that we're getting there
[09:25] <Sweetshark> cjwatson: you seem to be reading my mind!
[09:26] <Sweetshark> cjwatson: I would need your help with copying binaries again I guess. https://launchpad.net/~libreoffice/+archive/ppa/+builds?build_state=building is running out of discspace again, leaving people on amd64 with a half (arch-indep only) update. Can you copy https://launchpad.net/~bjoern-michaelsen/+archive/libreoffice-precisetest-20120327/+sourcepub/2532414/+listing-archive-extra to https://launchpad.net/~libreoffice/+archive/ppa so that peopl
[09:26] <cjwatson> cut off at "so that peopl"
[09:26] <Sweetshark> ... so that people dont run into that anymore?
[09:27] <cjwatson> Sweetshark: I'm not sure I can, since it's already building
[09:27] <Sweetshark> cjwatson: or would this fail as there is such a package in the target ppa?
[09:27] <cjwatson> LP will reject the copy attempt since there's a conflict
[09:28] <Sweetshark> cjwatson: will it help to remove the package from the target ppa?
[09:29] <Sweetshark> cjwatson: (likely the i386 would need to be removed anyway)
[09:29] <cjwatson> Probably eventually, but I don't know how long it would take to remove it completely enough to allow a re-copy
[09:29] <cjwatson> A version bump would definitely fix it; whether you want to do that ...
[09:30] <cjwatson> So why doesn't it run out of disk space in your own archive?
[09:30] <cjwatson> Surely it uses a deterministic amount of space
[09:30] <Sweetshark> cjwatson: different buildd I guess ...
[09:31] <cjwatson> Hm - actually, no, I don't think that deleting will help
[09:31] <Sweetshark> cjwatson: so a version bump would mean another buildd -- and again a possible fail because of discspace.
[09:31] <cjwatson> The test is "ever been published"
[09:32] <Sweetshark> cjwatson: guessed so.
[09:32] <cjwatson> If you have a buildd known to work, I can force it onto that
[09:32] <cjwatson> With coordination
[09:32] <cjwatson> Probably might as well just do that with the build in ~libreoffice/+archive/ppa at this point, once that fails
[09:33] <Sweetshark> cjwatson: that would be great (doing it without a bump)
[09:34] <Sweetshark> cjwatson: however, that buildd currently doesnt really fail. it just hangs indefinitelty.
[09:34] <Sweetshark> cjwatson: If I cancel it, I am not sure I would be able to retry it.
[09:34] <cjwatson> Probably not
[09:34] <cjwatson> Really indefinitely, or just a long time?
[09:37] <Sweetshark> cjwatson: its hanging for days without any change in the build log preview. unless launchpad times it out I dont think it will.
[09:38] <Sweetshark> cjwatson: do you have any administrative way to force "kill the build" which doesnt imply canceling?
[09:42] <Sweetshark> seb128: btw: see backlog
[09:43] <tumbleweed> Sweetshark: re debian bug 679700. why isn't unopkg in /usr/bin on ubuntu?
[09:45] <cjwatson> Sweetshark: I'll ask ops for it.
[09:48] <hrw> hi
[09:48] <hrw> does someone work on merging aptitude 0.6.8?
[09:51] <Sweetshark> tumbleweed: dont know, if there is a explicit reason for that. However, since for example soffice is symlinked from /usr/bin, I would assume doing the same for unopkg to be more apporpriate than PATH-adding.
[09:51] <tumbleweed> Sweetshark: debian has had it that way for ages, so I assumed it was intentional...
[09:54] <Sweetshark> tumbleweed: I pinged _rene_ about it ...
[09:55] <tumbleweed> Sweetshark: please reply on the debian bug too, then. it's a little invalid
[09:58] <Sweetshark> tumbleweed: btw using the word "ubuntu" on renes debian bugs might make you get ignored quickly.
[09:58]  * tumbleweed thought you had a good relationship with him? :)
[10:02] <cjwatson> Sweetshark: the build is failed now; I have to go out for a bit now, but when I get back I'll try to force it onto a known-good builder.  Probably best to leave it alone in the meantime
[10:03] <seb128> is anyone using chromium on precise and could help to verify bug #992352
[10:03] <Sweetshark> cjwatson: awesome!
[10:16] <seb128> cjwatson, do you think you could verify bug #998492 if you ever get some spare cycles? ;-) the SRU is in proposed for 32 days, it would be good to get it moved to -updates
[11:00] <hrw> uf. looks like aptitude 0.6.8-1ubuntu1 builds
[11:14] <cjwatson> seb128: yeah, I've been trying and failing to verify that for a little while actually, because I keep running into unrelated problems
[11:15] <cjwatson> seb128: I'll give it another go ...
[11:21] <seb128> cjwatson, thanks
[12:25] <hrw> Can someone take a look at aptitude 0.6.1-1ubuntu1 at http://marcin.juszkiewicz.com.pl/~hrw/ubuntu/ - bug 824708
[12:32] <Sweetshark> cjwatson: https://launchpad.net/~libreoffice/+archive/ppa/+build/3609969 <- is now failed. can you give me a good buildd for a retry?
[12:46] <larsduesing> Hmmm... could anybody sponsor SRU https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1007408 please?
[12:56] <ahasenack> hi, is there some place I can check for the SRU queue, to see where my request stands?
[13:09] <larsduesing> ahasenack: good question... afaik there is no..
[13:10] <ahasenack> larsduesing: do you know where to see all pending requests? I think there is a list somewhere
[13:11] <ahasenack> http://reqorts.qa.ubuntu.com/reports/sponsoring/ hmm found this
[13:11] <larsduesing> sec
[13:11] <ahasenack> but mine isn't there
[13:11] <ahasenack> I did subscribe sru-sponsors
[13:15] <larsduesing> ohm
[13:15] <larsduesing> strange...
[13:15] <tumbleweed> who is sru-sponsors?
[13:15] <larsduesing> ahasenack: could you please tell me which bug you mean?
[13:15] <tumbleweed> you want ubuntu-sponsors
[13:16] <ahasenack> larsduesing: bug #1004678
[13:16] <ahasenack> tumbleweed: https://launchpad.net/~ubuntu-sru this team
[13:16] <tumbleweed> ahasenack: they don't sponsor, they review SRUs
[13:16] <ahasenack> tumbleweed: sorry I got the name wrong above
[13:16] <tumbleweed> you want ubuntu-sponsors
[13:17] <ahasenack> tumbleweed: when does ubuntu-sru get involved?
[13:17] <tumbleweed> they review the upload in the archive's queue
[13:17] <ahasenack> tumbleweed: so first ubuntu-sponsors, and once it's in proposed, then ubuntu-sru?
[13:17] <tumbleweed> so, after it's been uploaded, they accept the upload
[13:17] <tumbleweed> the sponsor should subscribe ubuntu-sru if you haven't
[13:17] <ahasenack> tumbleweed: it's weird: "after it's uploaded, they accept the upload"
[13:18] <ahasenack> tumbleweed: they accept it after the fact?
[13:18] <tumbleweed> yes
[13:18] <tumbleweed> it gets held in the queue https://launchpad.net/ubuntu/precise/+queue?queue_state=1
[13:19] <ahasenack> tumbleweed: does ubuntu-sponsors take into account it's an sru, with different rules? Or does only the ubuntu-sru team do that?
[13:19] <tumbleweed> the sponsor is lending you their upload rights
[13:19] <tumbleweed> so yes, they'll take SRU rules into account
[13:20] <tumbleweed> but it's not within their right to accept the upload, it still needs SRU team approval
[13:20] <ahasenack> tumbleweed: what if ubuntu-sponsors and ubuntu-sru don't agree?
[13:20] <ahasenack> tumbleweed: I'm thinking it might make sense for the sru team to review first
[13:20] <tumbleweed> what if an uploader and ubuntu-sru don't agree, it's the same thing
[13:20] <ahasenack> tumbleweed: ah, I guess I have this different perspective because I'm not an uploader then
[13:20] <tumbleweed> ubuntu-sru gets to make teh final decision, and not every SRU involves sponsorship
[13:22] <cjwatson> ahasenack: if you try to make the sru team review things first, you will probably only slow things down for yourself.  it's easier for the sru team to review once it's in their queue
[13:23] <Laney> we used to have a review-first workflow, and it was a big bottleneck
[13:23] <ahasenack> ok
[13:25] <ahasenack> ok, can you guys take a look at the bug and do a quick check if I subscribed the right team and so on, so that it's visible now?
[13:50] <Kalidarn> hmm what's the best way to debug an ATI fglrx kernel panic.
[13:50] <Kalidarn> and is it even possible with closed-sourced proprietary drivers.
[13:51] <Kalidarn> i considered https://wiki.ubuntu.com/Kernel/KernelDebuggingTricks#Serial_Console
[13:51] <Kalidarn> i do have http://www.tripplite.com/en/products/model.cfm?txtSeriesID=849&txtModelID=3914 but yeah.
[13:53] <Kalidarn> or would it be recommended to follow this approach https://wiki.ubuntu.com/Kernel/CrashdumpRecipe
[13:59] <Kalidarn> come to think of it #ubuntu-kernel is probably a better channel to ask in
[14:17] <tjaalton> jbicha: heh, thanks for syncing the 389ds/freeipa bits from debian, beat me to it ;)
[14:26] <Kalidarn> hmm not really any point in bothering to debug it, the error trace appearing on the screen is exactly the same as comment #4 of bug 750437
[14:26] <Kalidarn> which i guess there's little i can do about that.
[14:27] <directhex> oh, i get that
[14:28] <Kalidarn> yand it's damn annoyinga
[14:28] <Kalidarn> cos my filesystems unmount uncleanly
[14:28] <Kalidarn> i wonder if updating to the latest proprietary drivers might fix it.
[14:29] <Kalidarn> my friend says he never has it happen with is card.
[14:29] <directhex> the post-release fglrx option in jockey is broken
[14:29] <directhex> doesn't install properly
[14:30] <Kalidarn> hmm, yeah i'm using the ubuntu supplied fglrx driver
[14:35] <johnp_> How do I add a folder choose widget in glade? There is one for file chooser only.
[14:37] <Kalidarn> directhex: if it happens for you can you click "affects me"
[14:46] <johnp_> How do I add a folder choose widget in glade? There is one for file chooser only.
[14:48] <Kalidarn> johnp_: try in #ubuntu-app-devel
[15:07] <PaoloRotolo> Hi all!
[15:33] <cjwatson> Sweetshark: OK, sorry for the delay; attempting rebuild on radon now
[15:56] <Sweetshark> cjwatson: thanks a lot
[16:49] <mterry> barry, heyo.  I uploaded update-notifier trunk with a bad depend (python3-debian which isn't available) and didn't notice.  Is there a branch for the python3 port of that yet, or shall I look into making one?
[16:51] <cjwatson> mterry: There's a Debian bug; I plan to NMU in the next few days
[16:51] <cjwatson> mterry: (The Debian bug has an extensive patch series from me)
[16:51] <mterry> cjwatson, awesome.  I figured someone had something ready to go, or the port of update-notifier wouldn't have hit trunk already
[16:52] <cjwatson> It will take a little while though, so I suggest reverting to py2 for now
[16:52] <cjwatson> Unless that's particularly painful
[16:52] <mterry> hrm.  OK, will look
[16:53]  * cjwatson thinks that landing things on trunk that would break if uploaded to the archive is distinctly unwise.
[16:53] <slangasek> yep, sorry
[16:53] <slangasek> I think when I landed it I assumed python3-debian was Coming Soon <tm>
[17:02] <mterry> It's simple enough to undo.  Will upload shortly.  Sorry for not testing well enough!
[17:07] <cjwatson> I missed the Debian freeze which won't help, so I may have to beg -release
[17:07] <cjwatson> Hopefully will catch up on that tomorrow ...
[17:42] <ScottK> Does the FSF position on GPLv3 and GRUB2 stated in https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/whitepaper.pdf mean that the non-GRUB2 approach might be reconsidered?
[18:15] <BenC> chrisccoulson: Are you planning to use the patches I sent you to get thunderbird building on ppc?
[18:26] <jono> cjwatson, slangasek did you see https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/whitepaper-web ?
[18:30] <chrisccoulson> BenC, sorry, only had a quick glance so far. but they both have fixes upstream too
[18:31] <BenC> chrisccoulson: Then will you pull those fixes for quantal?
[18:33] <chrisccoulson> BenC, the larger patch might introduce crashes, because it adds additional members to JSContext when ENABLE_ASSMEBLER is defined, but not every consumer of jscntxt.h defines that
[18:34] <chrisccoulson> BenC, i'm not sure there's much point in backporting patches. we upgrade to the next version again in a couple of weeks, and then another version 6 weeks after that
[18:34] <BenC> chrisccoulson: The large patch is the same one from precise, just fixes the merge conflicts
[18:34] <chrisccoulson> BenC, right, there was a reason it's not in precise any more
[18:35] <BenC> chrisccoulson: can it be conditionally applied for ppc only?
[18:35] <micahg> well, the advantage is to enable PPC support again in the stable releases sooner
[18:35] <chrisccoulson> it could, but we should just use the upstream fix
[18:35] <chrisccoulson> but this doesn't solve the problem that every new firefox release fails to build on ppc
[18:35] <BenC> chrisccoulson: I guess I'm still wondering when that will happen
[18:36] <chrisccoulson> i honestly think we should just stop building firefox on ppc, and stick iceweasel or something in universe just for that
[18:36] <BenC> chrisccoulson: And to that end, I have to ask, why the problem that plagued ppc-precise still affected ppc-quantal…I remember it being said that would have it permanently fixed
[18:36] <BenC> chrisccoulson: I would argue not to do that
[18:37] <chrisccoulson> BenC, well, upstream don't support ppc, which means it's down to us to keep it going. so, most releases we push out won't build on powerpc
[18:37] <BenC> The past two dev cycles, every time I try to get things fixed, the feedback is "it's fixed upstream"
[18:37] <cjwatson> There is non-trivial complexity involved in building different sets of packages on different architectures - what you'd effectively be doing is outsourcing complexity to other people, but not really reducing the net complexity of Ubuntu overall - in fact very probably increasing it
[18:37] <BenC> But then why isn't it upstream?
[18:38] <chrisccoulson> BenC, powerpc is not an architecure that is supported by mozilla
[18:38] <micahg> hrm, I thought with the patches in 15 PPC should start working again normally
[18:38] <BenC> chrisccoulson: but you said it was fixed upstream, or upstream said it was fixed…but it isn't
[18:38] <BenC> I'm not asking about support, I'm just wondering why this "its' fixed upstream" never materializes
[18:39] <chrisccoulson> BenC, yes, that particular problem is fixed upstream in the next version
[18:39] <cjwatson> jono,ScottK: Yes, it came up on the internal uefi list - I don't know the answer yet but I certainly hope it means we can reconsider
[18:39] <BenC> chrisccoulson: does that mean it will get into quantal?
[18:39] <chrisccoulson> but each new version brings a new powerpc build failure
[18:39] <BenC> chrisccoulson: The last build failure was super trivial
[18:39] <cjwatson> but I'm not in a position to speak for Canonical or Ubuntu on it yet
[18:39] <BenC> I fixed it in a couple lines of diff
[18:39] <BenC> I'd hardly call that a problem worth dropping ppc for
[18:39] <jono> cjwatson, understoof
[18:39] <ScottK> cjwatson: OK.  Thanks.
[18:39] <jono> understood
[18:42] <BenC> chrisccoulson: Also, the fact is, I'm putting in the time and energy to keep ppc building, but it's all being tossed aside "because it will be fixed upstream" when it never shows up ubuntu
[18:42] <micahg> chrisccoulson: if BenC is willing to help with PowerPC support, I'd like to take the fixes as distro patches (assuming they're sane)
[18:42] <BenC> chrisccoulson: Can you just take my patches and have them apply conditionally for ppc and I'll continue to maintain them :)
[18:42] <chrisccoulson> BenC, well, they do end up in ubuntu. but they end up alongside new issues
[18:43] <BenC> chrisccoulson: That's false…there was only one new issue, and I sent you a super small patch to fix it
[18:43] <stokachu> seb128: re bug #890928, does QA do anything to verify this or should I do some QA on it?
[18:43] <chrisccoulson> BenC, one new issue in this version. what about the next version? and the version after that?
[18:43] <BenC> And if issues do arise, I will fix them as well
[18:44] <BenC> I said that during precise dev, and my offer was ignored and the patch I worked on was dropped and ppc-precise has no working thunderbird/firefox :/
[18:45] <BenC> All I'm asking is that my "community" effort be useful…it's kind of hard to justify people putting in community work if that work gets ignored and dismissed so easily
[18:49] <chrisccoulson> BenC, sorry, i don't want you to think that i'm dismissing your effort. if you want to backport this change to apply to the current version in quantal, then i'll add it as a distro patch: https://hg.mozilla.org/mozilla-central/rev/f5a3a7b9c6b0
[18:50] <chrisccoulson> (which is the version of your larger patch which was committed upstream)
[18:51] <seb128> stokachu, not sure, check with the SRU team ( slangasek, SpamapS, RAOF, bdmurray, ScottK) what they require to validate it as SRU verified
[18:54] <BenC> chrisccoulson: Excellent, will do, thanks. Should I email it when done, and if so, where is best?
[18:55] <chrisccoulson> BenC, you can just use the same mail as before
[18:55] <chrisccoulson> also, it might be worth trying to build a nightly every now and again. if you find issues there, it means it might be possible to fix it without having to carry patches :)
[18:56] <BenC> chrisccoulson: Where is there info on the source for the nightly and how best to build it?
[18:57] <chrisccoulson> BenC, you could probably just grab a package from https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa/ and try building that
[18:57] <stokachu> seb128: will do thanks
[19:00] <SpamapS> stokachu: I believe the comments suggest the way to enable proposed and verify the bug fix.
[19:11] <stokachu> SpamapS: well i patched it and built it myself.. would you say thats enough then
[19:17] <SpamapS> stokachu: it was already patched and fixed in precise-proposed .. it just needs testing
[19:18] <SpamapS> stokachu: https://bugs.launchpad.net/ubuntu/+source/libxkbfile/+bug/890928/comments/17
[19:18] <stokachu> SpamapS: right so it was missing an sru and https://bugs.launchpad.net/ubuntu/+source/libxkbfile/+bug/890928/comments/7 already stated it works
[19:24] <SpamapS> stokachu: Not sure what you are saying there. We have to test the actual binaries in proposed.
[19:24] <stokachu> is there a daily install build that tests installing x86 packages on 64bit
[19:24] <cjwatson> Not that I can think of
[19:24] <cjwatson> Make a chroot and try it
[19:25] <stokachu> was thinking we could automate these without having to wait for someone to physically install the package
[19:25] <cjwatson> It'd take ten minutes
[19:25] <cjwatson> to just try it out by hand - no need to wait for the reporter
[19:25] <cjwatson> Second time round it would take two minutes
[19:25] <cjwatson> Especially if you left the chroot around for the next test
[19:26] <infinity> schroot -c precise-amd64 -u root apt-get install blah?
[19:27] <slangasek> stokachu: bug #890928> we shouldn't expect the QA team to do the verification here.  Per RAOF's comment #18, it looks to me that we ought to have some regression testing of the reverse-dependencies?  or at least some code inspection to make sure they're not doing stupid things like dlopen()ing the library?
[19:27] <infinity> Although, I need to write some hooks to enable/disable pockets and components.
[19:27] <infinity> cjwatson: Do you have any fancy to do the above, or do you just log in and mangle sources.list?
[19:27] <stokachu> slangasek: yea i mean this is more than just install the package and see if it croaks
[19:29] <cjwatson> infinity: I just log in
[19:31] <infinity> cjwatson: Yeah, me too.  If I find the motivation to automate that, I'll be sure to share.
[19:34] <mhall119> highvoltage: would you like to do another workshop hangout with me tomorrow?
[19:34] <mhall119> giving packaging support
[19:35] <mhall119> it'll be mostly technical Q+A
[19:37] <highvoltage> mhall119: yeah I'll try to be a bit more prepared too :)
[19:37] <highvoltage> mhall119: what time?
[19:38] <Daviey> slangasek: Hey, who is on point for signing off an SRU today?
[19:40] <slangasek> Daviey: no one, because infinity is celebrating Canada's independence from Mexico
[19:40] <infinity> Daviey: It would be me, but... See above.
[19:40] <infinity> Daviey: If it's urgent, I can throw on a community hat and still care.  'Sup?
[19:44] <mhall119> highvoltage: 1700 UTC
[19:46] <Daviey> infinity: well, another team will want to do an update of a package tomorrow.. and they need to know if they should base it on the -proposed package or current release/-updates.
[19:46] <infinity> Daviey: That's delightfully vague.
[19:46] <Daviey> So, i need it ACK'd or NACK'd before tomorrow.
[19:46] <highvoltage> mhall119: great. see you then.
[19:46] <ScottK> It would be useful to know what "It" is.
[19:56] <mhall119> highvoltage: cool, thanks
[19:57] <stokachu> seb128: ok verified re: 890928
[19:59] <spaetz> mmh, nouveau leads to a black screen with tons of errors in dmesg, and nvidia-current requires and old xserver-abi which is not available. All thin quantal
[20:00] <spaetz> all this in quantal
[20:00] <spaetz> and yes, I'll file a nouveau bug.
[20:00] <seb128> stokachu, thanks
[20:01] <stokachu> seb128: np :D
[20:01] <seb128> is anyone using chromium on precise and could help to verify the SRU on bug #992352 so it can move to -updates?
[20:03] <stokachu> seb128: im running it with no problems
[20:03] <seb128> stokachu, can you comment on the bug saying that?
[20:04] <stokachu> yea lemme try on a fresh install again just to verify
[20:07] <stokachu> seb128: ok done
[20:07] <seb128> stokachu, thanks
[20:07] <stokachu> sure ting
[20:07] <stokachu> thing*
[20:08] <spaetz> thanks, Timo Aaltonen for just uploading the fixed nvidia package :)
[20:09] <spaetz> tjaalton: that would have been you, I guess. Thanks :)
[20:11] <seb128> ev, cjwatson: could somebody in the installer team look at https://errors.ubuntu.com/bucket/?id=/usr/lib/ubiquity/bin/ubiquity:ValueError:watch_debconf_fd_helper:process_input:wait:cleanup:preseed:%3Clambda%3E:command
[20:11] <seb128> it's in the most reported issues on e.u.c (645 report since yesterday)
[20:14] <Dr_Who> infinity, ping
[20:16] <micahg> Dr_Who: he's off today, you might want to use a more contentful ping
[20:16] <Dr_Who> no worries , guessing me might be off this week
[20:16] <micahg> which actually isn't bad advice in general :)
[20:17] <Dr_Who> doko_, don't support you're around?  re: update for libjpeg-turbo
[20:18] <micahg> really, the whole thing should just go into Debian (debian 612341)
[20:31] <dobey> how do i see crashes on errors.ubuntu.com for a specific package version? i don't see any bugs in launchpad for it that are marked as dup on the main bug, and the hash links aren't helpful
[20:32] <Dr_Who> micahg, quite the lengthy bug for something so simple but yes that's really the thing long term,  time to jump on that I guess
[20:33] <micahg> Dr_Who: fabo is the owner there, maybe ask how you can help
[20:33] <micahg> we've got time for quantal (just don't forget about it :))
[20:33] <Dr_Who> micahg, yeah shall do. fabo was the one that picked up what I had done for ubuntu and was pushing to debian
[20:35] <Dr_Who> but also would be nice to get what I have in q so it's at least there and really precise should be updated as well tho it's not the end of the world tho some have tripped over the lack of checking in jpeg headers which would be one reason to get the update into precise
[21:33] <infinity> doko_: Your gcc-4.5 update reverted the armel bits from the previous upload.
[21:34] <infinity> doko_: Specifically, http://launchpadlibrarian.net/108530671/gcc-4.5_4.5.3-12ubuntu2_4.5.3-12ubuntu3.diff.gz
[21:34] <infinity> doko_: I'm going to re-apply that now, but you might want to get it in your Debian branch so it doesn't revert again.
[21:35] <infinity> doko_: (Or add me to the appropriate alioth group and I'll do it myself)
[21:43] <micahg> infinity: hrm, I thought Debian was killing gcc-4.5...
[21:45] <infinity> micahg: Oh, indeed.  But I suspect doko still maintains ours in the Debian SVN. :P
[21:47] <micahg> well, Debian fixed mysql, so, can we kill it :)
[21:47] <micahg> "fixed"
[21:48] <doko_> infinity, thanks, fixing for debian. please care about q
[21:55] <cousteau> nvidia-96 is not installable because of broken dependency on xorg-video-abi-10 which doesn't exist on precise
[21:55] <infinity> doko_: Already uploaded for Q.
[21:56] <cousteau> (however I recall being able to install this on the live cd...  what happened?)
[21:56] <infinity> micahg: Fixing MySQL by disabling the tests isn't much of a fix.
[21:56] <micahg> infinity: hrm, I thought they built with 4.4 on i386 until it can be fixed
[21:56] <infinity> micahg: Oh, I may have missed that development.
[21:57] <micahg> cousteau: is there a bug?
[21:57] <cousteau> yes, a non-existant dependency
[21:57] <micahg> cousteau: no, I mean in launchpad, I see the issue :)
[21:57] <cousteau> oh
[21:59] <cousteau> Bug #948053 and Bug #941325
[21:59] <cousteau> also there's a bug on ubottu when reporting 2 bugs on the same --er never mind
[22:00] <cousteau> 2nd line was the same as 1st one but it said "duplicate"
[22:02] <micahg> bryceh: ^^ can you poke tseliot about that?
[22:04] <slangasek> Sweetshark: I'm trying to see if I can spot the problem with bug #1017125, but I don't think I have enough context for how to run this test case - maybe you could pass me a binary I could use for reproducing?
[22:04] <slangasek> Sweetshark: also, the upstream bug only shows backtraces from before your latest change... would be good to have the current backtrace when building without cxx0x, which we know we have to do
[22:14] <seb128> slangasek, not sure but I think the builds are on https://launchpad.net/~libreoffice/+archive/libreoffice-prereleases/+packages
[22:15] <ignacio_> hola
[22:35] <bryceh> micahg, will do
[23:08] <hallyn> so i'm looking into FTBFS for nvidia-settings.  if i dpkg-source -x then debian/rules build, it works.  but if i dpkg-source -x then debian/rules build-arch, it fails.  there is a build: rule which explicitly builds a needed .a file.  there is no build-arch rule
[23:09] <hallyn> i don't know the right way to fix this.  do ijust add a build-arch rule which builds that .a file then does dh build-arch ?
[23:12] <micahg> hallyn: maybe it should be broken out to its own rule rather than duplicated
[23:14] <infinity> hallyn: It just sounds like debian/rules has some ordering issues, then.
[23:14] <hallyn> ok, i guess at this point i'll just open a bug.  revisit it when i get back thursday if it hasn't been addressed by the maintainers
[23:14] <micahg> shouldn't build be called before binary-arch?
[23:15] <hallyn> there is a binary-arch rule, but this is build-arch
[23:15] <hallyn> is there a list of the predefined targets and their order?
[23:16] <hallyn> i suppose i can do a libSTAMP
[23:16] <infinity> hallyn: The problem is that they inserted at the end
[23:16] <infinity> %:
[23:16] <infinity>         dh $@
[23:16] <infinity> hallyn: So, for build, it's calling the explicit build rule, for build-arch, it's calling the implicit build rule.
[23:16] <infinity> hallyn: The quick fix would just be a "build-arch: build" rule.
[23:16] <cousteau> not sure if perl or makefile...
[23:17] <infinity> hallyn: (more correct is probably renaming build to build-arch, and then making build: build-arch.
[23:17] <infinity> )
[23:17] <hallyn> hm ok
[23:17]  * infinity tests this.
[23:17] <infinity> I'll just upload if this works. :P
[23:18] <micahg> :q
[23:18] <micahg> oops
[23:19] <micahg> infinity: that package wouldn't fly in Debian as the binary name is created at build time
[23:20] <micahg> do we have a similar rule?
[23:20] <infinity> The part where it ships random binary blobs doesn't concern you?
[23:21] <micahg> well, that's by design isn't it?
[23:21] <infinity> micahg: The package name is created at clean time, not build time.
[23:22] <infinity> micahg: So, assuming the uploader cleans before building, debian/control is right.
[23:22] <micahg> infinity: it's done both times from what I can tell :P
[23:22] <infinity> micahg: There's no policy against control.in, it's in half the desktop packages (though, not used this way).
[23:22] <infinity> micahg: Well, sure, it's re-done, since that's the joy of running clean during the build, but whatever.
[23:22] <infinity> Oh, and I see, build-arch also depends on the same target.  That's just sloppy.
[23:23] <infinity> But whatever.
[23:23] <micahg> infinity: there are certain rules, no mangling build-dependencies, and I just saw that binary names shouldn't change either
[23:23] <micahg> no mangling during the build that is
[23:23] <infinity> micahg: Sure, so the only real bug here is that that's done twice.  But it's a harmless bug, at least.
[23:24] <micahg> infinity: assuming clean was run before uploading
[23:24] <infinity> micahg: Right, but every control.in-using package assumes that.
[23:24] <infinity> micahg: (Which I'd prefer wasn't the case, but it's rather common)
[23:24] <micahg> that's fine as long as the build doesn't mangle it though :)
[23:32]  * micahg still wonders why MOTU is the maintainer for a restricted package :)
[23:38] <StevenK> RAOF: Wow, a Xid error without my screen becoming unusable.
[23:38] <RAOF> Yeah, they do happen.