[01:01] <cjwatson> tumbleweed: u-d-a> done
[04:31] <Tucks> Hello? :O
[07:13] <haraldj> Hello anybody from the SRU and the security team already online?
[07:15] <micahg> haraldj: what's your question?
[07:16] <haraldj> no question, rather a discussion about how to handle security/functionality bugs in package openswan
[07:18] <haraldj> For Hardy there are 4 open security issues (at least according to diff of the Ubuntu/Debian changelogs)
[07:18] <micahg> haraldj: security fixes need to be cherry-picked, see https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation (we could probably fakesync for natty)
[07:19] <tumbleweed> cjwatson: ta
[07:19] <haraldj> micahg: Well it's not only security but also functionality: https://bugs.launchpad.net/ubuntu/+source/openswan/+bug/227294
[07:19] <micahg> haraldj: if there are bugs, they can be SRUd, if you want new functionality, you'll want to look at backports
[07:20] <haraldj> Ähm sorry I guess you misunderstood me: I'm the Debian uploader ;-)
[07:20] <haraldj> And after tackling most of the Debian bugs I'm now trying to catch up with the Ubuntu ones
[07:21] <micahg> haraldj: so, both SRUs and security updates need to be minimal fixes, full backports are possible with testing of the backport and its rdepends
[07:23] <haraldj> micahg: Sure same in Debian the question remains what issues the SRU and security team deem important enough/vs non-invasive to get into
[07:24] <haraldj> micahg: There are for example many calls for fixes for KLIPS which may not be too easy...
[07:25] <haraldj> micahg: I think it would make most sense to present a list (to be made by me) to the people responsible for this decision which details which fixes are missing in each release
[07:25] <haraldj> micahg: But who exactly are these people?
[07:27] <ScottK> haraldj: Fortunately for you, micahg is one of the members of the Ubuntu security team.
[07:28] <haraldj> ScottK: Well I already thought this when reading his comments ;-)
[07:28] <micahg> haraldj: so, for the security fixes, you can discuss with mdeslaur in #ubuntu-hardened after 14:00 UTC, not sure if the SRU people are around, but basically, if it's a small patch and testable, it's probably ok to SRU
[07:29]  * SpamapS is an SRU person
[07:29] <haraldj> micahg: Ok, I will try to come up with a list of fixes needed and will try to test it
[07:30] <micahg> haraldj: well, the fixes will need to be tested after they're uploaded as well, but it's always nice to know if they work beforehand :)
[07:30] <micahg> haraldj: and the security team loves help :)
[07:31] <haraldj> micahg: Well I can only give it small tests as I do not really use Ubuntu but I will try my best
[07:31] <micahg> haraldj: well, I meant that there's a test case that someone can test the fix
[07:31] <haraldj> micahg: Yes I know I've already worked with Moritz Muehlenhoff from Debian security team ;-)
[07:31] <SpamapS> haraldj: typically with the SRU process, you'd want to keep it to one fix at a time, or a group of small related fixes at one time. Otherwise it can be difficult to verify all of the bug fixes, which is required to pass into -updates
[07:32] <haraldj> SpamapS: Well for Hardy there are 4 open security issues (if counted right) and two other issues
[07:33] <SpamapS> haraldj: and for hardy, we'd only do High priority fixes.. things that cause data loss or completely broken software.
[07:33] <micahg> haraldj: I'd suggest going for the security issues first, then SRUing the bug fixes afterwards (security issues go in right away after testing, SRUs require 7 days)
[07:33] <SpamapS> haraldj: yeah, security is micahg's realm. :)
[07:34] <SpamapS> haraldj: and I'd agree with micahg.. get them into security first.
[07:34] <haraldj> SpamapS: could you please take a look at https://bugs.launchpad.net/ubuntu/+source/openswan/+bug/227294 and https://bugs.launchpad.net/ubuntu/+source/openswan/+bug/228274?
[07:34] <haraldj> SpamapS: If they are not suitable please close them with won't fix
[07:34] <SpamapS> haraldj: are these things fixed in later upstream versions?
[07:34] <haraldj> SpamapS: Yes
[07:35] <haraldj> SpamapS: Lucid has a new version which should fix these issues
[07:36] <haraldj> SpamapS: So if they are won't fix please close them (I already applied for ubuntu-bugcontrol for openswan to better care for the package)
[07:37] <SpamapS> haraldj: not much info there. Are there workarounds for these bugs?
[07:37] <SpamapS> haraldj: well they're technically already "closed" as Fix Released (I'm marking them as such). At this point it would be a task only against hardy..
[07:37] <haraldj> haraldj: No not as far as I know - the rundir/subsysdir are just missing $ signs
[07:37] <haraldj> sorry meant SpamapS ;-)
[07:38] <micahg> https://bugs.gentoo.org/show_bug.cgi?id=193824#c0
[07:38] <haraldj> SpamapS: for the ppp bug I will need to take a look at the fix
[07:39] <SpamapS> haraldj: so the rundir/subsysdir .. the software is totally broken for... most, or all, or just some users?
[07:40] <SpamapS> haraldj: let me dig out your bugcontrol app so I can +1 it.. :)
[07:41] <haraldj> SpamapS: the rundir/subsysdir is merely an annoyance I guess
[07:41] <micahg> re bug control app> it doesn't look like it's been moderated yet
[07:41] <haraldj> As long as the dirs already exit
[07:42] <SpamapS> haraldj: ok so thats not a good candidate for a hardy SRU. The other one though, that looks more difficult to work around
[07:43] <haraldj> SpamapS: Well then I think just close the rundir/subsysdir :-)
[07:44] <SpamapS> haraldj: I'll mark it as Won't Fix in Hardy, with a priority of Medium. The other seems High priority, so a patched package would certainly be accepted.
[07:44] <haraldj> SpamapS: Ok the fix for ppp is a two-liner
[07:44] <dholbach> good morning
[07:45] <SpamapS> haraldj: though, if the test case is clear and the patch fo rthe rundir thing is only 2 lines also.. I wouldn't mind it being fixed as well.
[07:45] <micahg> SpamapS: well, cleanup will require a maintainer script fix, the simple SRU would be not to create the dirs anymore
[07:46] <haraldj> SpamapS: Well for the rundir issue I would take the Gentoo patch, for the ppp issue I would take the Debian patch
[07:46] <SpamapS> micahg: a maintainer script that searches the entire filesystem for rundir/subsysdir.. that doesn't seem doable.
[07:46] <haraldj> micahg: Well the dirs would be created but the right way ;-)
[07:47] <haraldj> SpamapS: +1
[07:47] <micahg> haraldj: right, sorry :)
[07:47] <haraldj> SpamapS: would be far to dangerous, think about a package placing a rundir in eg /opt...
[07:47] <SpamapS> micahg: we could have it echo "Sorry we messed with your home dir"
[07:47] <SpamapS> no we're not going to cleanup the mistakes of the past.. ;)
[07:48] <SpamapS> not in that case anyway
[07:48] <haraldj> SpamapS: was an upstream mistake ;-)
[07:48] <SpamapS> Ok, I think I understand the two issues, and both patches are very simple and straightforward...
[07:48] <haraldj> micahg: But we could do a find and tell the user we found them...
[07:48] <haraldj> micahg: They may check and remove if necessary
[07:49] <SpamapS> I would suggest addressing the 4 security issues first, then attaching a debdiff or a merge proposal to one of the other two bugs with uploads for hardy-proposed
[07:49] <micahg> haraldj: I don't think we'd take a maintainer script to do that as an SRU, but IANA SRU team member
[07:49] <SpamapS> haraldj: to be clear, since the fix and test case are so simple, both are acceptible for SRU.
[07:49] <SpamapS> micahg: no, we wouldn't. :)
[07:50] <haraldj> SpamapS: Ok :-) so I will talk with the security guy concerning the patches and then later talk again with you about hardy-proposed, is that ok for you?
[07:52] <SpamapS> haraldj: yeah. I'd suggest actually attaching the debdiff and subscribing ubuntu-sponsors to the bug.. this will allow somebody to get to it quicker, and helps keep the line clear between SRU team members and -proposed uploaders (more eyeballs.. etc. etc.)
[07:52] <SpamapS> haraldj: but by all means, ping me about it
[07:52] <haraldj> haraldj: Ok I will do :-)
[07:53] <micahg> haraldj: so, for the security patches, for natty, you can just fix in squeeze and sync, precise, fix in sid and sync, the other releases will need debdiffs
[07:53] <haraldj> Sorry mistyped again ;-)
[07:53] <haraldj> micahg: precise is ok
[07:53] <SpamapS> haraldj: btw, did you email ubuntu-bugcontrol@lists.launchpad.net ? not seeing your email there
[07:53] <micahg> SpamapS: that list is moderated for non-subscribers
[07:54] <haraldj> micahg: 2.6.37 there is uptodate
[07:54] <haraldj> micahg: squeeze-security has a fixed version, doing the sync may be up to the ones who can do ;-)
[07:54] <micahg> haraldj: yeah, just mention to mdeslaur and he can take care of that
[07:55] <haraldj> micahg: ok
[07:55] <haraldj> SpamapS: another issue: does Ubuntu want to have KLIPS support from openswan?
[07:56] <SpamapS> haraldj: Ubuntu wants everything Debian has to offer.. well.. except insserv. ;)
[07:56] <haraldj> SpamapS: *ggg*
[07:57] <haraldj> SpamapS: Well KLIPS support would mean greater patches, I'm not sure this would be acceptable, maybe if there is a need for it there should rather be backports
[07:57] <SpamapS> haraldj: Oh kernel patches or openswan patches?
[07:58] <haraldj> Ops alioth is down...
[07:58] <SpamapS> we're not going to take kernel patches that aren't upstream
[07:58] <haraldj> SpamapS: In case of Hardy it would be a patch to patch the patch for the kernel ;-)
[07:59] <micahg> also, new functionality isn't allowed in SRUs
[07:59] <SpamapS> we'd like for hardy users to be at least migrated to lucid by now.. so probably no.
[07:59] <haraldj> micahg: Well the functionality isn't new - KLIPS is an alternative IPSec Stack for the kernel which needs to be apadted to compile with newer kernel versions
[08:00] <haraldj> SpamapS: Ok no problem for me :-)
[08:00] <SpamapS> I mean hardy servers will still get critical updates for 2 more years. But, its time to start planning for the hardy->lucid->precise double upgrade in August if you have hardy boxes. :)
[08:00] <micahg> SpamapS: hardy has a little over 15 months of support left
[08:00] <SpamapS> well not 2 more years.. about 21 more months.
[08:00] <haraldj> SpamapS: I think https://bugs.launchpad.net/ubuntu/+source/openswan/+bug/253041 is then a candidate for won't fix
[08:00] <SpamapS> 15?
[08:01] <SpamapS> oh right, 12+3
[08:01] <SpamapS> was doing 24-3 :-P
[08:01] <SpamapS> oi.. its 2012 isn't it? :-P
[08:01] <haraldj> SpamapS: :-) well I do not have any hardy boxes
[08:01]  * SpamapS screams AHHHGGGHH we're all gonna die in Homer's voice
[08:01] <haraldj> SpamapS: Doh
[08:02] <haraldj> SpamapS: so I would think close the above bug if there is no need for KLIPS in Hardy anymore
[08:02] <micahg> does lucid+ have KLIPS already?
[08:03] <haraldj> micahg: Not sure what kernel version has lucid?
[08:03] <StevenK> 2.6.32
[08:03] <SpamapS> sounds like a Fix Released
[08:04] <haraldj> SpamapS: not sure
[08:04]  * haraldj works through Debian and upstream gut
[08:04] <haraldj> git
[08:04] <SpamapS> well 11.10 has 3.0.0
[08:05] <haraldj> SpamapS: openswan 2.6.37 runs on my netbook with 3.2.0-rc7 so no problem with KLIPS here
[08:06] <micahg> so that should at least be Fix Released (precise)
[08:07] <SpamapS> indright, 3.2.0 is precise
[08:07] <haraldj> micahg: Yes
[08:08] <SpamapS> haraldj: closed as Fix Released
[08:08] <haraldj> upstream openswan 2.6.24 contains a commit which fixes KLIPS for kernel 2.6.32
[08:08] <haraldj> SpamapS: which one did you close?
[08:09] <SpamapS> haraldj: KLIPS support
[08:10] <SpamapS> haraldj: btw, thanks very much for tending the bugs.
[08:10] <haraldj> SpamapS: There are 4 or so bugs open for KLIPS support :-) for almost every Release one I guess
[08:11] <haraldj> SpamapS: Well I try my best
[08:11] <SpamapS> haraldj: ahh, if its all just the same request (please add KLIPS) then just mark them all as duplicates
[08:11] <SpamapS> haraldj: or if you can't mark as dupe, then list the #'s and I'll do that
[08:12] <haraldj> SpamapS: I'm not sure this makes sense this way because the fixes are incremental
[08:14] <haraldj> SpamapS: https://bugs.launchpad.net/ubuntu/+source/openswan/+bug/246713 is a similar matter - https://bugs.launchpad.net/ubuntu/+source/openswan/+bug/253041 did talk about the module not included, https://bugs.launchpad.net/ubuntu/+source/openswan/+bug/246713 did talk about the module not compilable
[08:15] <haraldj> SpamapS: https://bugs.launchpad.net/ubuntu/+source/openswan/+bug/253041 says the module is not included -> correct there is only the source for it
[08:16] <haraldj> SpamapS: https://bugs.launchpad.net/ubuntu/+source/openswan/+bug/246713 says it is not compileable -> correct, this is fixed with a patch of me which can be found in Debian Lenny security version
[08:17] <haraldj> SpamapS: So I guess https://bugs.launchpad.net/ubuntu/+source/openswan/+bug/246713 could be close to
[08:18] <haraldj> Ups sorry must do some work now ;-)
[08:40] <robert461> hello any one to chat ? ;-)
[10:01] <tjaalton> still a huge backlog on ppa-builders? 11h as suggested by lp..
[10:01] <tjaalton> was the same last week
[10:12] <MacSlow> Just ran into LP: #894340 "E:Couldn't configure pre-depend libtinfo5 for libncurses5, probably a dependency cycle" while trying to dist-upgrade my desktop-box from oneiric to precise... any hints for a work-around?
[10:16] <MacSlow> seb128, didrocks, pitti: ^^ any idea
[10:20] <seb128> MacSlow, hey, I've personally no clue about this one but maybe mvo would
[10:20] <seb128> or cjwatson
[10:21] <cjwatson> huh, I wonder why that's at all hard; libtinfo5 Pre-Depends: multiarch-support (which you should already have) and Depends: libc6 (>= 2.4) (likewise)
[10:21] <MacSlow> mvo, cjwatson: got a tip for a work-around on LP: #894340 ?
[10:21] <cjwatson> eglibc wasn't uploaded recently or anything
[10:21] <cjwatson> nor was ncurses
[10:23] <cjwatson> MacSlow: i386 or amd64?
[10:23] <MacSlow> cjwatson, amd64
[10:24]  * infinity wonders why ncurses predepends tinfo instead of just a depends.
[10:27] <cjwatson> either way, not sure why it should break
[10:27] <cjwatson> playing around to see if I can restore the apt-clone data from that bug report
[10:28] <infinity>      - Add Pre-dependency on libtinfo5 to libncurses5 to prevent possible
[10:28] <infinity>        symbol lookup errors if libncurses5 is unpacked before libtinfo5.
[10:28] <seb128> somebody else is mentioning the same bug on #ubuntu-bugs
[10:28] <infinity> That seems like a blatant misunderstanding of dependencies.
[10:29] <infinity> I'm sure that dropping the pre-dep to a dep will fix the resolver breakage.  Still curious that it breaks though, yes.
[10:30] <Daviey> Does anyone own/(have access to) trusted boot (intel) hardware?
[10:30] <cjwatson> infinity: wait, that actually seems reasonable to me
[10:30] <infinity> cjwatson: It does?
[10:31] <infinity> cjwatson: Pre-dep is to guarantee a package is configured.  If unpack isn't enough to guarantee symbol lookups, then every binary->library dependency is "wrong".
[10:31] <MacSlow> cjwatson, so should I just wait for the relevant packages to be rebuild?
[10:31] <cjwatson> if unpacking the new libncurses5 is going to break without libtinfo5 on the system, then I can't see any way other than Pre-Depends to enforce libtinfo5 being >= unpacked
[10:31] <cjwatson> MacSlow: huh?
[10:31] <cjwatson> MacSlow: we haven't analysed this yet.
[10:32] <cjwatson> infinity: maybe there are Essential binaries linked to ncurses
[10:32] <cjwatson> it wouldn't overly surprise me
[10:32] <MacSlow> cjwatson, ok
[10:32] <cjwatson> I think Priority: required libraries ought to be able to support that, at least
[10:32] <infinity> cjwatson: Potentially, sure, but ncurses depends on tinfo, I don't see how that can go backward.  There's no dependency loop.
[10:33] <cjwatson> infinity: right - that's why I'm trying to stuff apt-clone data into place in the hope of reproducing it
[10:33] <infinity> cjwatson: (And, indeed, our own version in oneiric was a dep, not a pre-dep, and I don't recall any fallout)
[10:33] <infinity> cjwatson: It was the next Debian revision that promoted that to a pre-dep.
[10:34] <cjwatson> From binaries in Essential packages, fdisk, cfdisk, and pg link to ncurses
[10:34] <Wellark> I'm pretty sure that this is some corner case on my system. otherwise we would be getting duplicates every 5 minutes from people doing the upgrade
[10:35] <cjwatson> It doesn't seem strictly vital but I'd prefer to figure out why apt is eating its own tail rather than reverting the pre-dep
[10:35] <Wellark> could it be some package I've installed is getting the dependency cycles wrong?
[10:35] <Wellark> e.i. confusing the resolver
[10:36] <cjwatson> it's possible; do you have an apt-clone state file somewhere?
[10:36] <cjwatson> what we need to do is to get a chroot on an expert's system configured to reproduce things
[10:37] <Wellark> yes, attached to the bug
[10:37] <cjwatson> ah yes
[10:37] <Wellark> https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/894340/comments/5
[10:37] <cjwatson> give me a few minutes to try to beat things into shape here
[10:37] <Wellark> sure sure
[10:37] <Wellark> I'm not in such hurry
[10:37] <Wellark> after all my system is still in usable state :)
[10:38] <infinity> Wellark: Do you have any ncurses*-dev packages installed?
[10:39] <Wellark> probably, will check
[10:39] <infinity> I note some multiarch mangling in the -dev packages in 5.9-3.  Curious if that could wreak upgrade havoc.
[10:40] <Wellark> hmm.. I've only have lib32ncurses5-dev
[10:40] <Wellark> I thought I had some others, too
[10:40] <Wellark> I remember doing some ncurses stuff couple of months ago
[10:40] <cjwatson> yeah, multiarch is certainly a possible source of trouble
[10:40] <Wellark> oh, but that was with python ncurses
[10:41] <Wellark> hmm.. using apt-rdepends
[10:42] <Wellark> I see that file is needed by wine-dev
[10:43] <infinity> So, you have libncurses5-dev:i386 installed, perhaps?
[10:43] <Wellark> oh, read the output wrong
[10:43] <cjwatson> hah, apt-clone gets pretty confused if you try to restore state into an amd64 chroot in an i386 host system
[10:43] <Wellark> let's see
[10:43] <cjwatson> (with an amd64 kernel - it's physically possible for it to execute the binaries)
[10:43] <infinity> cjwatson: linux64 to the rescue?
[10:44] <infinity> Oh, but amd64 kernel, should be reporting linux64ishly anyway.
[10:44] <cjwatson> infinity: no, I think it's using the system's apt
[10:44] <infinity> Yeah.
[10:44] <infinity> Special.
[10:44] <cjwatson> and forgetting to set APT::Architecture
[10:47] <Wellark> infinity: I've got libncurse5-dev installed
[10:47] <Wellark> and dpkg-query -s says Architecture: amd64
[10:48] <mvo> cjwatson: heh :) never tried that, what is the error?
[10:49] <infinity> Wellark: And nothing for "dpkg -l libncurses5-dev:i386"?
[10:49] <Wellark> no, nothing
[10:49] <cjwatson> mvo: no error but it downloads i386 package lists instead of amd64 and (I think) tries to restore i386 packages which doesn't go so well
[10:50] <cjwatson> well, no error before I noticed what it was doing and C-c
[10:50]  * cjwatson convinces chdist to load that data
[10:51] <mvo> cjwatson: thanks! good to know, probably trivial to fix (like you said already earlier :)
[10:54] <cjwatson> mvo: want a bug?
[10:54] <infinity> Oh, ncurses wasn't multiarch in oneiric, so I guess my questions about having i386 stuff installed are irrelevant.
[10:56] <mvo> cjwatson: I write a note about it, its hopefully quicker to fix than to write a bug
[10:58] <cjwatson> mvo: *nod*
[10:58] <cjwatson> ta
[11:05] <Wellark> cjwatson, infinity: if you come up any ideas, just ping me, ok?
[11:06] <Wellark> I'm off to make some coffee
[11:11] <cjwatson> bah, chdist apt-get dist-upgrade doesn't reproduce this
[11:27] <Riddell> ARM dudes: problem in qtwebkit compile
[11:27] <Riddell> https://launchpadlibrarian.net/90264873/buildlog_ubuntu-precise-armhf.qtwebkit-source_2.2.1-1ubuntu1_FAILEDTOBUILD.txt.gz
[11:27] <Riddell> "/usr/bin/ld: final link failed: Memory exhausted"
[11:27] <Riddell> ideas?
[11:35] <Wellark> Riddell: more swap..
[11:35] <Wellark> qtwebkit can take from 4-8GB of memory on linking stage
[11:35] <Tm_T> Wellark: James Bond: When 16 GiB is not enough
[11:35]  * Tm_T hides
[11:36] <Riddell> Wellark: well yes I could guess that, it's a question of how to get it
[11:38] <Tm_T> Riddell: I wonder if #canonical-sysadmin would help
[11:40] <Wellark> Riddell: or #launchpad as it's build service related
[11:43] <Tm_T> ah, forgot launchpad had their own channel
[11:52] <infinity> Riddell: Waiting on kernel upgrades on the buildds to make that happy.
[11:53] <infinity> Riddell: Once the buildds have shiny new kernels, we'll retry the world.  If you see the same failure on that package again, please scream.
[11:54] <Riddell> infinity: nice thanks
[11:59] <alexbligh> Does software exist (say an apache module) which provides a web-based view of the CONTENTS of a .deb (or even better, an entire repository), and let individual files be downloaded over the web (I know it's an ar file containing 2 x tgz, and I know I could write something in perl myself, but I suspect it's been done before).
[12:07] <beuno> alexbligh, you mean something like this?  http://packages.ubuntu.com/precise/comm/asterisk
[12:09] <alexbligh> beuno, yes, the code behind that (these are .debs we autobuild), save that when you go to (say) http://packages.ubuntu.com/precise/amd64/asterisk/filelist I need to be able to download the files themselves, not just the list of files.
[12:10] <beuno> alexbligh, on the right-hand side, don'y you have the tar.gz file and such?
[12:11] <alexbligh> Yes, but I want to download the files IN the package
[12:11] <beuno> ah, I see
[12:11] <alexbligh> (i.e. the individual files in the .tgz in the .ar)
[12:11] <beuno> I don't know of any websites that have that since the packages are uploaded already compressesed AFAIK
[12:12] <alexbligh> If the source to packages.ubuntu.com is open source, I'd be happy to hack it up so http://packages.ubuntu.com/precise/amd64/asterisk/filelist can be a link
[12:12] <alexbligh> beuno, yes, but you can extract them with a bit of perl and ar and tar file by file.
[12:12] <jpds> alexbligh: http://packages.ubuntu.com/about/
[12:12] <alexbligh> I was just hoping someone had done the work.
[12:13] <alexbligh> jpds, ooh, thanks. That will be a good start.
[12:13] <beuno> right, it may not play super nicely with the servers, though, having to decompress a ton of things on the server-side
[12:13] <alexbligh> beuno, that's true. Perhaps not suitable for public consumption, but this is for internal usage.
[12:14] <beuno> right, go nuts then!
[12:16]  * Sweetshark wants to rebase on debian, but alioth is down :/
[12:32] <Daviey> would someone on foundations like to comment on, bug 913379.. thanks.
[13:17] <tomreyn> hi, i'm just looking at bug #879926 and wonder whether there will likely be a SRU?
[13:19] <seb128> tomreyn, could be, though it seems most bugs were from precise and not oneiric, not sure if that's a real issue in oneiric
[13:20] <seb128> well the code bug is obvious so it's probably is
[13:20] <seb128> do you get the issue?
[13:29] <tomreyn> seb128: yes, i ran into it on oneiric, and the bug is also tagged oneiric
[13:29] <seb128> tomreyn, ok, thanks
[13:31] <scott-work> it appears that the REVU website is down, it also appears that i cannot dput to REVU
[13:31] <scott-work> does anyone have any infomration?
[13:31] <tomreyn> seb128: do you want me to comment on the bug asking for an SRU or will you take it from here?
[13:32] <seb128> tomreyn, I will add it to my list but feel free to comment on the bug if you want, what we will need is somebody who has the issue to confirm the fix after the upload ;-)
[13:34] <tomreyn> okay, i'll comment and watch it.
[13:34] <seb128> thanks
[13:38] <tomreyn> thank you!
[14:08] <cjwatson> alexbligh: http://www.mirrorservice.org/ does that: e.g. http://www.mirrorservice.org/sites/archive.ubuntu.com/ubuntu/pool/universe/a/asterisk/asterisk_1.6.2.9-2ubuntu2_i386.deb%5Bpeek%5D
[14:12] <ogra_> does anyone know if: "Architecture: any-arm" in debian/control should work ?
[14:13] <ndec> hi. i have tried to use Arch = any-arm for some of our packages, and my upload are rejected in this case. If i use Arch = armel armhf, it works as expected, but i got the feeling from the debian policy that any-arm should work. Anyone can advise?
[14:13] <ndec> ah... i didn't see that ogra_ just asked the same question ;-)
[14:14] <ogra_> heh
[14:14] <ndec> any-arm work when building locally with dpkg-buildpackage in armel or armhf root fs. it's just that the upload is rejected by LP
[14:15] <seb128> seems like soyuz doesn't handle that yet
[14:15]  * ogra_ guesses soyuz just knows $(dpkg-architecture -L), any, all
[14:16] <cjwatson> It might be a bit naive about CPU aliases
[14:16] <cjwatson> It does know about any-i386, say, but -arm is a bit different
[14:17] <ndec> so, should I open a bug for any-arm?
[14:17] <ogra_> well, the footnote at http://www.debian.org/doc/debian-policy/footnotes.html#f88 also talks about gnu triplets ... we dont have any plain "arm" triplet either
[14:17] <ogra_> or am i reading that just wrong ?
[14:22] <cjwatson> $ dpkg-architecture -aarmel -iany-arm; echo $?
[14:22] <cjwatson> 0
[14:22] <cjwatson> therefore IMO you should file a bug on Launchpad about this, yes
[14:23] <cjwatson> lib/lp/soyuz/pas.py:determineArchitecturesToBuild doesn't implement the full architecture alias handling
[14:23] <ogra_> aha
[15:02] <ScottK> barry: ping re usb-python.
[15:05] <barry> ScottK: hi
[15:05] <ScottK> Hello barry.  Did you get the more detailed ping I sent yesterday?
[15:05] <barry> ScottK: i didn't
[15:05] <ScottK> OK.  Let me find it.
[15:06] <ScottK> [11:56:17] <ScottK> barry: ping re python-dbus recommends python-gobject.  This pulls python-gobject and a stack of other things into the Kubuntu seeds that aren't otherwise needed.  Do you think it could be dropped?
[15:06] <ScottK> Similar for python3-dbus.
[15:06] <barry> ScottK: it's only a build-dep, right?
[15:06] <ScottK> No, it's a run time Recommends.
[15:06] <ScottK> That's why it gets pulled in.
[15:07] <ScottK> It seems somewhat bogus to me.
[15:07] <ScottK> But you've been in the code, so I wanted to see what you thought.
[15:08] <barry> ScottK: ah right, it's in wheezy that way too.  let me just look at a couple of things
[15:08] <ScottK> Thanks.
[15:14] <barry> ScottK: so, outside of the test suite (and thus the build-dep), it's only imported in dbus/gobject_service.py.  we could probably split that out into a separate binary package and then only that would need python-gobject.  i don't really know what kind of impact that would have for clients of the package (i.e. how much dbus/gobject_service.py is used)
[15:14] <ScottK> Any suggestions on how we could find out?
[15:15] <barry> i guess i could grep through my installed precise *.py to see if i can track down any imports of it
[15:16] <ScottK> Or any reference to ExportedGObject as that and ExportedGObjectType are the only classes in there.
[15:16] <barry> yep, good idea
[15:17] <ScottK> IIRC kees used to have the entire Ubuntu archive unpacked.  Maybe he could do it ...
[15:17] <barry> ScottK: well, just ran the import check.  zero imports
[15:17] <ScottK> Cool.
[15:17] <barry> and all references to ExportedGObject are in dbus itself
[15:18] <ScottK> If it's not used in any packages, then I think it's safe to drop it to suggests.
[15:19] <barry> ScottK: rather than separating it into a new binary package?
[15:19] <ScottK> Yes.
[15:19] <barry> that's an easy change
[15:19] <ScottK> Yeah.
[15:20] <barry> ScottK: i think my latest upload is waiting to be accepted because of the new python-dbus-common binpkg (slangasek rejected it last time due to lintian warnings, since fixed)
[15:20] <barry> ScottK: once that's accepted, i can make that change and upload.  when the new dbus-python is released upstream i had planned on submitting my changes to debian, so i can push the suggests change at that point
[15:21] <ScottK> OK.  I'm going to grab the rdepends and grep them, just to make sure.
[15:21] <barry> cool
[15:32] <stgraber> @pilot in
[15:34] <ScottK> barry: There's one package that's a problem and it looks like it's unmaintained and likely to go away ~soon anyway.  I'll add the python-gobject depends to it and then your change to suggests is safe.  No need to wait to re-upload, BTW, the newer binaries in binary New will just superced the old ones.
[15:35] <barry> ScottK: cool.  i'll make that change now then and upload.  could you submit a bug report in debian about it?  you can even assign it to me, and then i'll remember when the time comes there
[15:35] <ScottK> barry: I take it back, they're all fine.
[15:35] <ScottK> Sure.
[15:36] <barry> ScottK: http://paste.ubuntu.com/807510/
[15:37] <ScottK> barry: What about python3-dbus?
[15:37] <barry> yep, was just there :)
[15:37] <ScottK> (that's what I was hoping for for python-dbus)
[15:37] <ScottK> OK
[15:38] <barry> ScottK: http://paste.ubuntu.com/807512/
[15:38] <ScottK> barry: Yes.  Please.
[15:45] <ScottK> barry: Debian Bug#656230
[15:47] <barry> ScottK: got it
[15:47] <ScottK> Great.
[15:53] <barry> ScottK: uploaded
[15:54] <ScottK> Excellent.
[15:56]  * barry -> reboot
[15:57] <hrw> does someone saw eglibc builds looping?
[16:00] <dholbach> kirkland, hiya, do you think you can have a look at bug 917682?
[16:06] <cjwatson> barry: do you think it would be useful if I packaged the 'six' module?
[16:06] <kirkland> dholbach: i think it's been done
[16:06] <kirkland> dholbach: http://packages.qa.debian.org/b/byobu.html
[16:06] <cjwatson> barry: writing compat layers for cases where wedging 2to3 into the build system is awkward is getting tedious very quickly
[16:06] <kirkland> dholbach: oh, wait ...
[16:06] <dholbach> kirkland, eh?
[16:06] <dholbach> :)
[16:07] <kirkland> dholbach: they want Ubuntu to sync from debian?
[16:07] <kees> ScottK: i just have the archive mirrored; the unpack is relatively fast though.
[16:07] <kirkland> dholbach: no, Ubuntu is upstream here;  Debian byobu is downstream
[16:07] <ScottK> kees: It turned out to be few enough packages that I downloaded them and checked.  Thanks though.
[16:07] <dholbach> kirkland, you're CCed on the bug - I identified a few things that were missing in the Debian packaging - I'll leave the bug to you
[16:08] <kirkland> dholbach: thanks;  the debian maintainer should propose a branch/merge/patch to lp:byobu
[16:08] <kirkland> dholbach: and I'll integrate
[16:08] <Laney> get it on the sync blacklist if this is the case
[16:08] <ScottK> lamont: How goes postfix 2.8.7?
[16:09] <kees> ScottK: cool
[16:09] <lamont> ScottK: actually working on it now
[16:09] <ScottK> lamont: Excellent.  Thanks
[16:11] <barry> cjwatson: it could be useful.  so far i've managed to port code w/o 2to3 or six, which i think isn't too difficult if you only have to target >= 2.6.  but six could perhaps make that even easier or more consistent
[16:15] <cjwatson> barry: right, it's just tedium like iteritems.  I could repeat the compatibility code (but that's so boring), or accept the performance hit in Python 2 of using items (but that involves thought about whether it matters)
[16:16] <barry> cjwatson: right (it rarely does though :) but yeah, i do agree it would be good to promote six as the compatibility layer.  i've been thinking about submitting some code upstream for the other things i've found at both the python and c layers.
[16:17] <barry> cjwatson: and i completely agree it's better than 2to3 :)
[16:22] <cjwatson> heh, yeah
[16:22] <cjwatson> alright, I'll knock a package together
[16:31] <lamont> ScottK: my ppa
[16:31] <ScottK> lamont: I'm trying to remember what we decided on Bug #774500 ?
[16:31] <lamont> ScottK: if you would be so kind as to play with that some?
[16:31] <ScottK> Sure.
[16:32] <lamont> ScottK: I believe we decided that I still have some work to do there
[16:32] <ScottK> OK.
[16:35] <ScottK> barry: https://launchpad.net/ubuntu/+source/dbus-python/0.84.0-2ubuntu3/+build/3099079 urk.
[16:39] <ScottK> lamont: trying.
[16:39] <lamont> ScottK: do you know off the top of your head if libsqlite3-0 is effectively essential?
[16:39] <ScottK> My recollection is we decided it was.
[16:41] <ScottK> It's certainly in minimal.
[16:43] <lamont> ScottK: it's entirely possible that it's fixed in this upload
[16:45] <ScottK> lamont: debc says there's no dict_sqlite.so
[16:47] <ScottK> Might as well leave it for 2.9.0 at this point though.
[16:51] <ScottK> lamont: Tests out fine here.  I say ship it.
[16:54] <ScottK> barry: I'm going to mash retry since you didn't change anything that would affect that.
[17:02] <cr3> cjwatson: quick preseed question: if the same value is being set twice in the same preseed file, like partman-auto/method for example, does the last value always take precedence?
[17:04] <cjwatson> cr3: Yes
[17:04] <cjwatson> cr3: preseed files are declarative not imperative
[17:06] <cr3> cjwatson: thanks!
[17:22] <ScottK> barry: Failed again.  Not sure what's up there.  Over to you.
[17:35] <cjwatson> barry: OK, six is in Debian NEW now
[18:03] <ahasenack> pitti: hey,
[18:03] <ahasenack> pitti: could you release a new postgresql-common for lucid? For the ppa:pitti/postgresql ppa?
[18:04] <ahasenack> pitti: release 128, which has pg_basebackup ;)
[18:12] <broder> barry, ScottK: if you still need it, i have the archive unpacked on my lintian runner
[18:15] <YokoZar> So, I'm working on multiarching Wine and I'm beginning to worry about build daemon skew.  For 32-bit compatibility, I have a few files from wine1.3 split into wine1.3-i386.  wine1.3-i386 is m-a:foreign and builds only on i386, so wine1.3:amd64 installs wine1.3-i386:i386.
[18:15] <YokoZar> My worry is that if I put a depends: wine1.3 (= ${binary:Version}) on wine1.3-i386, then if the archive updates i386 before amd64 (due to faster build or copy) then a user who runs apt-get update has wine1.3:amd64 and wine1.3-i386:i386 will see something screwy, like the suggestion that they remove wine1.3:amd64 and install wine1.3:i386.
[18:16] <YokoZar> *wine1.3 is M-A:allowed and the depends in wine1.3-i386 would be wine1.3:any (= ${binary:Version})
[18:21] <infinity> YokoZar: buildd skew in a development release is somewhat unavoidable.  Users running devel branches need to not trust apt's "removing everything, kay?" solutions without reading.
[18:22] <infinity> YokoZar: It's a non issue in a released dist, since we won't push from proposed to updates until all arches are built.
[18:22] <YokoZar> infinity: That seems reasonable.  And I suppose the archive admins will copy the package set from -proposed to -updates concurrently to avoid that as well.
[18:22] <YokoZar> infinity: Now I'm worried about the launchpad ppa instead, since they have no way of withholding arches currently
[18:23] <Sarvatt> YokoZar: yeah it's a huge problem in xorg-edgers with daily mesa updates where one arch always builds up to a day later than the other
[18:23] <YokoZar> Sarvatt: is there an existing feature request to launchpad to let us tick a box for the PPA somewhere that asks to hold as such?
[18:24] <infinity> YokoZar: The best way to do it in a PPA is to upload to a trunk/devel PPA, and then copy to a release PPA.
[18:24] <infinity> YokoZar: And encourage users to use the latter.
[18:24] <YokoZar> infinity: Ok, but I have the same problem with my daily build recipe PPA, and somehow I don't think having a staging PPA for that is correct ;)
[18:25] <infinity> YokoZar: Perhaps not.
[18:25] <infinity> YokoZar: Have you actually tested to see that it's a problem?
[18:25] <infinity> YokoZar: apt might just hold A back if B isn't in sync, rather than suggest removal.
[18:26] <YokoZar> infinity: it depends on what's marked manually vs automatically installed
[18:26] <YokoZar> I think
[18:44] <ScottK> broder: Thanks.  I ended up downloading the relevant packages.
[19:10] <barry> ScottK: thanks.  we had some ppc failures last time, but rebuilds fixed them.  i'll look at it.
[19:10] <barry> cjwatson: awesome! thanks
[19:11] <om26er> stgraber, hey! can you please sponsor this https://code.launchpad.net/~om26er/ubuntu/oneiric/tomboy/fix-880299/+merge/88910 as well
[19:12] <stgraber> om26er: sure, I was actually wondering if someone would prepare an SRU for it when I saw it land in Precise :)
[19:25] <om26er> stgraber, thx, i got another can you please sponsor it as well https://code.launchpad.net/~om26er/ubuntu/oneiric/compiz/compiz-sru/+merge/85928 :)
[19:31] <stgraber> @pilot out
[19:31] <stgraber> om26er: ok, will do tomboy and that one, then that's it for this shift
[19:32] <om26er> stgraber, thank you :)
[19:34] <stgraber> om26er: hmm, actually I'd better have someone with some kind of compiz knowledge to look at the compiz one. The tomboy one I looked at last week and I know the patch is fine, but compiz I'd rather have a desktop/X person sponsor it
[19:35] <stgraber> om26er: left a comment + review in that direction, hopefully someone will review it soon
[19:36] <om26er> stgraber, seb128 is aware of the compiz sru
[19:36] <om26er> its kind of the official SRU followed by a unity sru
[19:37] <stgraber> seb128: does https://code.launchpad.net/~om26er/ubuntu/oneiric/compiz/compiz-sru/+merge/85928 look good to you? if so, I have it ready for upload here so just let me know and I'll push to -proposed
[19:45] <stgraber> seb128: oh, and btw, you uploaded tomboy at -1ubuntu1.2 to precise instead of -1ubuntu2 which obviously made om26er SRU invalid as 1.2 already existed in the archive... :)
[19:45] <stgraber> seb128, om26er: Will repload the SRU as -1ubuntu1.1.1 instead
[19:47] <om26er> oops, thats all the oneirc/precise system switch :/
[19:47] <stgraber> ok, re-uploaded with a note in the changelog explaining the weird version number :)
[19:49] <om26er> stgraber, if that matters the same compiz is uploaded to the ~desktop-team ppa so you can safely do the upload to -proposed ;-)
[19:49] <om26er> https://launchpad.net/~ubuntu-desktop/+archive/ppa?field.series_filter=oneiric
[19:50] <stgraber> om26er: fine, I'll upload it in 30min or so then ;)
[19:52] <om26er> stgraber, ok, thx for the 3upload :)
[20:06] <seb128> re
[20:06] <stgraber> om26er: have these changes be pushed to Precise?
[20:06] <seb128> stgraber, the compiz SRU is fine yes, we have it in the ubuntu-desktop ppa since before holidays
[20:07] <stgraber> om26er: I just had a quick look and can't find any matching patches or changes in Precise
[20:07] <stgraber> seb128: maybe you can answer that question? ^
[20:07] <seb128> stgraber, don't bother about precise, a new compiz release is due there but is taking some time due to the testing etc
[20:07] <seb128> stgraber, it will land in the next week or so
[20:08] <stgraber> k, as long as I can blame you if someone ask why I uploaded something to proposed without first uploading to Precise, I'm fine :)
[20:08] <seb128> stgraber, sorry about tomboy, I used dch -i
[20:09] <stgraber> I guessed so when I saw the previous entry in the changelog ;) Bah, we'll just have some weird version numbers in oneiric-updates, that's fine :)
[20:10] <stgraber> om26er: compiz uploaded