=== lool- is now known as lool [13:39] Daviey, Laney, ScottK, slangasek: do you still consider multiarching libraries FFE material? (I'd like to merge poppler with Debian to get multiarch) [13:39] At this point I'd say the more the better, but the big question is how it affects rdepends. [13:40] my feeling was that it was FFE material for natty, but now we are confident enough with it [13:44] ScottK: how could it affect rdepends? It's not a special case like gstreamer or gio, it's just a simple .so [13:45] I know when Qt was multiarched since the libraries were it different locations, some of the rdepends installed files in different locations. [13:45] This meant .install files needed updating. [13:45] Usually it was minor (changing a / to /*/), but the trick was finding them. [13:46] I'm not sure if that would be a concern for other libraries or not. [13:46] it's not for standard libs [13:46] we certainly did have this case for e. g. gstreamer plugins [13:46] qt and gtk are special that they have optional .so they can load [13:46] or gst [13:46] or input methods [13:46] but popple doesn't have anything like that [13:47] OK. [13:48] I think it's ok then. [13:48] thanks [13:51] pitti: A core library, *maybe*.. an optiional library doesn't concern me. === bladernr_afk is now known as bladernr_ [14:53] pitti: are you ok with doing GHC ~ [14:53] ~now? [14:53] builders seem as quiet as they'll get [14:56] Laney: seems fine, yes [14:56] the test rebuild is done [14:56] k [14:56] iulian: want to fire ze missiles? [14:56] i'll mail letting everyone to know that it should be done by syncs whenever possible === bjf[afk] is now known as bjf === bladernr_ is now known as bladernr_afk === bladernr_afk is now known as bladernr_ [15:29] pitti: (FYI) bug 931813 reports firewire modules copied to universe instead of main (i verified) [15:29] Launchpad bug 931813 in kernel-sru-workflow "linux-lts-backport-oneiric: 3.0.0-16.29~lucid1 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/931813 [16:11] bjf: fixed, thanks [16:22] pitti: even for standard libs, revdeps that are Doing It Wrong can FTBFS because of the path change [16:23] slangasek: certainly [16:24] slangasek: so would you think we rather stop multiarchification at this point? [16:28] pitti: I think it's subject to FFe :) [16:28] ok [16:28] for things like merges where it's already done in Debian and it would otherwise go in, if it's done early I think we can reasonably make an exception [18:21] Laney: I'd appreciate it if you could take care of uploading GHC. If you're busy, then I can deal with it on Thursday when I get back home. [18:56] iulian: OK I will see what I can do, but I do not think I will have the energy to carry the transition completely through so help is appreciated. I'll mail devel probably. [18:56] the Debian graph is still a fair bit more red than I expected [18:57] http://pkg-haskell.alioth.debian.org/haskell-pkg-graph.pdf [19:03] Laney: I will do as many uploads as I can in the weekend. I just don't have time to work on GHC right now. [19:04] the weekend is pretty bad for me [19:05] running these transitions is pretty emotionally tiresome; I wish computers could just take care of it already [19:06] of course I should put up and implement binNMU in Launchpad rather than complaining [19:06] Indeed. :) [19:07] No worries, we'll be done in no time. [19:07] until the next time [19:07] Only if the buildds can keep up with me. [19:07] fish and chips for dinner will perk me up [19:07] * Laney bikes off into the sunset [19:07] (bbl) [19:07] Later! [19:37] Laney: I'm sure I can help with a GHC transition (and I'm not sure how binNMUs make it particularly simpler, except when someone screws up timing) [20:09] infinity: not having to rev the source revision, build, sign, upload manually [20:09] infinity: smarter depwait would probably help more, granted [20:10] Laney: Yeah, I've never found the uploading bit onerous. Maybe I'm weird. [20:12] having looked at the Debian graph, I think that would be a good place for me to focus my efforts if somebody else will do the merge and initial sync pass(es) [20:12] Laney: If you have a list of what needs merging/uploading, I can certainly help. I've not really been paying attention to GHC since the last transition. [20:14] infinity: merge ghc, haskell-devscripts and then sync everything else in the standard order [20:15] it should really all be syncs in this case because we needed arch:all rebuilds this time [20:15] Do we actually need a ton of syncs, or will rebuilds do? [20:15] Anyhow, the "merge GHC" bit might be touchy (unless it's a simple merge?), but happy to do the rest. [20:16] some will have required patches, but in general either is fine [20:16] If it's not a rocket surgery merge, I'll poke at that this afternoon. [20:16] the GHC diff should not be too hard, some linker stuff from doko [20:17] Oh, the linker stuff is right up my alley. :P [20:17] quite :-) [20:17] It's mostly a "do I have to speak fluent haskell?" thing. Cause Haskell gives me aneurysms. [20:17] oh, no, it's m4 I think [20:17] Sold! [20:40] * micahg can help with rebuilds also [20:41] you saints! [20:53] Uh oh! [22:34] can someone please confirm that the fix for bug 176125 is alright to upload now that we're in FF -- I already included the necessary patch but had forgotten to reset the default value for enabling privacy extensions to TRUE [22:34] Launchpad bug 176125 in network-manager "Ubuntu should activate the IPv6 privacy extension by default (echo 2 >/proc/sys/net/ipv6/conf/all/use_tempaddr)" [Wishlist,Confirmed] https://launchpad.net/bugs/176125 [22:35] it's a regression from what we had a few weeks ago isn't it? [22:35] cyphermox: Please fix it. [22:35] stgraber: yes [22:36] Either way, I think lack of privacy extensions is a bug. [22:36] cyphermox: I agree, bug -> squash it [22:36] it is indeed a regression, with just procps this was already set to use privacy extensions since at least january, perhaps earlier [22:36] cool, just being thorough [22:37] so this I'll upload in a minute with a few other fixes