=== zyga is now known as zyga-afk === allquixotic_ is now known as allquixotic [01:01] tumbleweed: u-d-a> done === retoaded_afk is now known as retoaded_gftd === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates [04:31] Hello? :O === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates [07:13] Hello anybody from the SRU and the security team already online? [07:15] haraldj: what's your question? [07:16] no question, rather a discussion about how to handle security/functionality bugs in package openswan [07:18] For Hardy there are 4 open security issues (at least according to diff of the Ubuntu/Debian changelogs) [07:18] haraldj: security fixes need to be cherry-picked, see https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation (we could probably fakesync for natty) [07:19] cjwatson: ta [07:19] micahg: Well it's not only security but also functionality: https://bugs.launchpad.net/ubuntu/+source/openswan/+bug/227294 [07:19] Ubuntu bug 227294 in openswan (Ubuntu) "defaultroute with PPP does not work" [Undecided,Confirmed] [07:19] haraldj: if there are bugs, they can be SRUd, if you want new functionality, you'll want to look at backports [07:20] Ähm sorry I guess you misunderstood me: I'm the Debian uploader ;-) [07:20] And after tackling most of the Debian bugs I'm now trying to catch up with the Ubuntu ones [07:21] 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] 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] micahg: There are for example many calls for fixes for KLIPS which may not be too easy... [07:25] 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] micahg: But who exactly are these people? [07:27] haraldj: Fortunately for you, micahg is one of the members of the Ubuntu security team. [07:28] ScottK: Well I already thought this when reading his comments ;-) [07:28] 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] micahg: Ok, I will try to come up with a list of fixes needed and will try to test it [07:30] 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] haraldj: and the security team loves help :) [07:31] micahg: Well I can only give it small tests as I do not really use Ubuntu but I will try my best [07:31] haraldj: well, I meant that there's a test case that someone can test the fix [07:31] micahg: Yes I know I've already worked with Moritz Muehlenhoff from Debian security team ;-) [07:31] 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] SpamapS: Well for Hardy there are 4 open security issues (if counted right) and two other issues [07:33] haraldj: and for hardy, we'd only do High priority fixes.. things that cause data loss or completely broken software. [07:33] 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] haraldj: yeah, security is micahg's realm. :) [07:34] haraldj: and I'd agree with micahg.. get them into security first. [07:34] 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] Ubuntu bug 227294 in openswan (Ubuntu) "defaultroute with PPP does not work" [Undecided,Confirmed] [07:34] Ubuntu bug 228274 in openswan (Ubuntu) "openswan creates "rundir" and "subsysdir"" [Undecided,Confirmed] [07:34] SpamapS: If they are not suitable please close them with won't fix [07:34] haraldj: are these things fixed in later upstream versions? [07:34] SpamapS: Yes [07:35] SpamapS: Lucid has a new version which should fix these issues [07:36] 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] haraldj: not much info there. Are there workarounds for these bugs? [07:37] 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: No not as far as I know - the rundir/subsysdir are just missing $ signs [07:37] sorry meant SpamapS ;-) [07:38] https://bugs.gentoo.org/show_bug.cgi?id=193824#c0 [07:38] bugs.gentoo.org bug 193824 in Applications "net-misc/openswan-2.4.9 creates errant directories "rundir", "subsysdir"" [Normal,Resolved: fixed] [07:38] SpamapS: for the ppp bug I will need to take a look at the fix [07:39] haraldj: so the rundir/subsysdir .. the software is totally broken for... most, or all, or just some users? [07:40] haraldj: let me dig out your bugcontrol app so I can +1 it.. :) [07:41] SpamapS: the rundir/subsysdir is merely an annoyance I guess [07:41] re bug control app> it doesn't look like it's been moderated yet [07:41] As long as the dirs already exit [07:42] 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] SpamapS: Well then I think just close the rundir/subsysdir :-) [07:44] 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] SpamapS: Ok the fix for ppp is a two-liner [07:44] good morning [07:45] 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] SpamapS: well, cleanup will require a maintainer script fix, the simple SRU would be not to create the dirs anymore [07:46] SpamapS: Well for the rundir issue I would take the Gentoo patch, for the ppp issue I would take the Debian patch [07:46] micahg: a maintainer script that searches the entire filesystem for rundir/subsysdir.. that doesn't seem doable. [07:46] micahg: Well the dirs would be created but the right way ;-) [07:47] SpamapS: +1 [07:47] haraldj: right, sorry :) [07:47] SpamapS: would be far to dangerous, think about a package placing a rundir in eg /opt... [07:47] micahg: we could have it echo "Sorry we messed with your home dir" [07:47] no we're not going to cleanup the mistakes of the past.. ;) [07:48] not in that case anyway [07:48] SpamapS: was an upstream mistake ;-) [07:48] Ok, I think I understand the two issues, and both patches are very simple and straightforward... [07:48] micahg: But we could do a find and tell the user we found them... [07:48] micahg: They may check and remove if necessary [07:49] 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] haraldj: I don't think we'd take a maintainer script to do that as an SRU, but IANA SRU team member [07:49] haraldj: to be clear, since the fix and test case are so simple, both are acceptible for SRU. [07:49] micahg: no, we wouldn't. :) [07:50] 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] 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] haraldj: but by all means, ping me about it [07:52] haraldj: Ok I will do :-) [07:53] 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] Sorry mistyped again ;-) [07:53] micahg: precise is ok [07:53] haraldj: btw, did you email ubuntu-bugcontrol@lists.launchpad.net ? not seeing your email there [07:53] SpamapS: that list is moderated for non-subscribers [07:54] micahg: 2.6.37 there is uptodate [07:54] micahg: squeeze-security has a fixed version, doing the sync may be up to the ones who can do ;-) [07:54] haraldj: yeah, just mention to mdeslaur and he can take care of that [07:55] micahg: ok [07:55] SpamapS: another issue: does Ubuntu want to have KLIPS support from openswan? [07:56] haraldj: Ubuntu wants everything Debian has to offer.. well.. except insserv. ;) [07:56] SpamapS: *ggg* [07:57] 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] haraldj: Oh kernel patches or openswan patches? [07:58] Ops alioth is down... [07:58] we're not going to take kernel patches that aren't upstream [07:58] SpamapS: In case of Hardy it would be a patch to patch the patch for the kernel ;-) [07:59] also, new functionality isn't allowed in SRUs [07:59] we'd like for hardy users to be at least migrated to lucid by now.. so probably no. [07:59] 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] SpamapS: Ok no problem for me :-) [08:00] 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] SpamapS: hardy has a little over 15 months of support left [08:00] well not 2 more years.. about 21 more months. [08:00] SpamapS: I think https://bugs.launchpad.net/ubuntu/+source/openswan/+bug/253041 is then a candidate for won't fix [08:00] 15? [08:00] Ubuntu bug 253041 in openswan (Ubuntu) "KLIPS module not included with openswan" [Undecided,Confirmed] [08:01] oh right, 12+3 [08:01] was doing 24-3 :-P [08:01] oi.. its 2012 isn't it? :-P [08:01] 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] SpamapS: Doh [08:02] SpamapS: so I would think close the above bug if there is no need for KLIPS in Hardy anymore [08:02] does lucid+ have KLIPS already? [08:03] micahg: Not sure what kernel version has lucid? [08:03] 2.6.32 [08:03] sounds like a Fix Released [08:04] SpamapS: not sure [08:04] * haraldj works through Debian and upstream gut [08:04] git [08:04] well 11.10 has 3.0.0 [08:05] SpamapS: openswan 2.6.37 runs on my netbook with 3.2.0-rc7 so no problem with KLIPS here [08:06] so that should at least be Fix Released (precise) [08:07] indright, 3.2.0 is precise [08:07] micahg: Yes [08:08] haraldj: closed as Fix Released [08:08] upstream openswan 2.6.24 contains a commit which fixes KLIPS for kernel 2.6.32 [08:08] SpamapS: which one did you close? [08:09] haraldj: KLIPS support [08:10] haraldj: btw, thanks very much for tending the bugs. [08:10] SpamapS: There are 4 or so bugs open for KLIPS support :-) for almost every Release one I guess [08:11] SpamapS: Well I try my best [08:11] haraldj: ahh, if its all just the same request (please add KLIPS) then just mark them all as duplicates [08:11] haraldj: or if you can't mark as dupe, then list the #'s and I'll do that [08:12] SpamapS: I'm not sure this makes sense this way because the fixes are incremental [08:14] 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:14] Ubuntu bug 246713 in openswan (Ubuntu) "openswan-modules-source pkg does not compile with m-a" [Undecided,Confirmed] [08:14] Ubuntu bug 253041 in openswan (Ubuntu) "KLIPS module not included with openswan" [Undecided,Fix released] [08:15] 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:15] Ubuntu bug 253041 in openswan (Ubuntu) "KLIPS module not included with openswan" [Undecided,Fix released] [08:16] 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:16] Ubuntu bug 246713 in openswan (Ubuntu) "openswan-modules-source pkg does not compile with m-a" [Undecided,Confirmed] [08:17] SpamapS: So I guess https://bugs.launchpad.net/ubuntu/+source/openswan/+bug/246713 could be close to [08:17] Ubuntu bug 246713 in openswan (Ubuntu) "openswan-modules-source pkg does not compile with m-a" [Undecided,Confirmed] [08:18] Ups sorry must do some work now ;-) [08:40] hello any one to chat ? ;-) === zyga-afk is now known as zyga [10:01] still a huge backlog on ppa-builders? 11h as suggested by lp.. [10:01] was the same last week [10:12] 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] seb128, didrocks, pitti: ^^ any idea [10:20] MacSlow, hey, I've personally no clue about this one but maybe mvo would [10:20] or cjwatson [10:21] 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] mvo, cjwatson: got a tip for a work-around on LP: #894340 ? [10:21] eglibc wasn't uploaded recently or anything [10:21] nor was ncurses [10:23] MacSlow: i386 or amd64? [10:23] cjwatson, amd64 [10:24] * infinity wonders why ncurses predepends tinfo instead of just a depends. [10:27] either way, not sure why it should break [10:27] playing around to see if I can restore the apt-clone data from that bug report [10:28] - Add Pre-dependency on libtinfo5 to libncurses5 to prevent possible [10:28] symbol lookup errors if libncurses5 is unpacked before libtinfo5. [10:28] somebody else is mentioning the same bug on #ubuntu-bugs [10:28] That seems like a blatant misunderstanding of dependencies. [10:29] 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] Does anyone own/(have access to) trusted boot (intel) hardware? [10:30] infinity: wait, that actually seems reasonable to me [10:30] cjwatson: It does? [10:31] 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] cjwatson, so should I just wait for the relevant packages to be rebuild? [10:31] 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] MacSlow: huh? [10:31] MacSlow: we haven't analysed this yet. [10:32] infinity: maybe there are Essential binaries linked to ncurses [10:32] it wouldn't overly surprise me [10:32] cjwatson, ok [10:32] I think Priority: required libraries ought to be able to support that, at least [10:32] cjwatson: Potentially, sure, but ncurses depends on tinfo, I don't see how that can go backward. There's no dependency loop. [10:33] infinity: right - that's why I'm trying to stuff apt-clone data into place in the hope of reproducing it [10:33] cjwatson: (And, indeed, our own version in oneiric was a dep, not a pre-dep, and I don't recall any fallout) [10:33] cjwatson: It was the next Debian revision that promoted that to a pre-dep. [10:34] From binaries in Essential packages, fdisk, cfdisk, and pg link to ncurses [10:34] 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] 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] could it be some package I've installed is getting the dependency cycles wrong? [10:35] e.i. confusing the resolver [10:36] it's possible; do you have an apt-clone state file somewhere? [10:36] what we need to do is to get a chroot on an expert's system configured to reproduce things [10:37] yes, attached to the bug [10:37] ah yes [10:37] https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/894340/comments/5 [10:37] Ubuntu bug 894340 in update-manager (Ubuntu) "Release Upgrade Fails: depency cycle for libtinfo5/libncurses5" [Undecided,Confirmed] [10:37] give me a few minutes to try to beat things into shape here [10:37] sure sure [10:37] I'm not in such hurry === kklimonda_ is now known as kklimonda [10:37] after all my system is still in usable state :) [10:38] Wellark: Do you have any ncurses*-dev packages installed? [10:39] probably, will check [10:39] I note some multiarch mangling in the -dev packages in 5.9-3. Curious if that could wreak upgrade havoc. [10:40] hmm.. I've only have lib32ncurses5-dev [10:40] I thought I had some others, too [10:40] I remember doing some ncurses stuff couple of months ago [10:40] yeah, multiarch is certainly a possible source of trouble [10:40] oh, but that was with python ncurses [10:41] hmm.. using apt-rdepends [10:42] I see that file is needed by wine-dev [10:43] So, you have libncurses5-dev:i386 installed, perhaps? [10:43] oh, read the output wrong [10:43] hah, apt-clone gets pretty confused if you try to restore state into an amd64 chroot in an i386 host system [10:43] let's see [10:43] (with an amd64 kernel - it's physically possible for it to execute the binaries) [10:43] cjwatson: linux64 to the rescue? [10:44] Oh, but amd64 kernel, should be reporting linux64ishly anyway. [10:44] infinity: no, I think it's using the system's apt [10:44] Yeah. [10:44] Special. [10:44] and forgetting to set APT::Architecture [10:47] infinity: I've got libncurse5-dev installed [10:47] and dpkg-query -s says Architecture: amd64 [10:48] cjwatson: heh :) never tried that, what is the error? [10:49] Wellark: And nothing for "dpkg -l libncurses5-dev:i386"? [10:49] no, nothing [10:49] 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] well, no error before I noticed what it was doing and C-c [10:50] * cjwatson convinces chdist to load that data [10:51] cjwatson: thanks! good to know, probably trivial to fix (like you said already earlier :) [10:54] mvo: want a bug? [10:54] Oh, ncurses wasn't multiarch in oneiric, so I guess my questions about having i386 stuff installed are irrelevant. [10:56] cjwatson: I write a note about it, its hopefully quicker to fix than to write a bug [10:58] mvo: *nod* [10:58] ta [11:05] cjwatson, infinity: if you come up any ideas, just ping me, ok? [11:06] I'm off to make some coffee [11:11] bah, chdist apt-get dist-upgrade doesn't reproduce this === doko__ is now known as doko [11:27] ARM dudes: problem in qtwebkit compile [11:27] https://launchpadlibrarian.net/90264873/buildlog_ubuntu-precise-armhf.qtwebkit-source_2.2.1-1ubuntu1_FAILEDTOBUILD.txt.gz [11:27] "/usr/bin/ld: final link failed: Memory exhausted" [11:27] ideas? === _salem is now known as salem_ [11:35] Riddell: more swap.. [11:35] qtwebkit can take from 4-8GB of memory on linking stage [11:35] Wellark: James Bond: When 16 GiB is not enough [11:35] * Tm_T hides [11:36] Wellark: well yes I could guess that, it's a question of how to get it [11:38] Riddell: I wonder if #canonical-sysadmin would help [11:40] Riddell: or #launchpad as it's build service related [11:43] ah, forgot launchpad had their own channel [11:52] Riddell: Waiting on kernel upgrades on the buildds to make that happy. [11:53] 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. === MacSlow is now known as MacSlow|lunch [11:54] infinity: nice thanks === TREllis_ is now known as TREllis [11:59] 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] alexbligh, you mean something like this? http://packages.ubuntu.com/precise/comm/asterisk [12:09] 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] alexbligh, on the right-hand side, don'y you have the tar.gz file and such? [12:11] Yes, but I want to download the files IN the package [12:11] ah, I see [12:11] (i.e. the individual files in the .tgz in the .ar) [12:11] I don't know of any websites that have that since the packages are uploaded already compressesed AFAIK [12:12] 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] beuno, yes, but you can extract them with a bit of perl and ar and tar file by file. [12:12] alexbligh: http://packages.ubuntu.com/about/ [12:12] I was just hoping someone had done the work. [12:13] jpds, ooh, thanks. That will be a good start. [12:13] right, it may not play super nicely with the servers, though, having to decompress a ton of things on the server-side [12:13] beuno, that's true. Perhaps not suitable for public consumption, but this is for internal usage. [12:14] right, go nuts then! [12:16] * Sweetshark wants to rebase on debian, but alioth is down :/ [12:32] would someone on foundations like to comment on, bug 913379.. thanks. [12:32] Launchpad bug 913379 in ntp (Ubuntu) "Migrate ntp from SystemV to Upstart" [Wishlist,New] https://launchpad.net/bugs/913379 === retoaded_gftd is now known as retoaded === calc is now known as Guest36731 [13:17] hi, i'm just looking at bug #879926 and wonder whether there will likely be a SRU? [13:17] Launchpad bug 879926 in Evince "evince crashed with SIGSEGV in g_param_spec_pool_lookup()" [Critical,New] https://launchpad.net/bugs/879926 [13:19] 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] well the code bug is obvious so it's probably is [13:20] do you get the issue? [13:29] seb128: yes, i ran into it on oneiric, and the bug is also tagged oneiric [13:29] tomreyn, ok, thanks [13:31] it appears that the REVU website is down, it also appears that i cannot dput to REVU [13:31] does anyone have any infomration? [13:31] seb128: do you want me to comment on the bug asking for an SRU or will you take it from here? [13:32] 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] okay, i'll comment and watch it. [13:34] thanks [13:38] thank you! === MacSlow|lunch is now known as MacSlow [14:08] 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 === ion_ is now known as ion [14:12] does anyone know if: "Architecture: any-arm" in debian/control should work ? [14:13] 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] ah... i didn't see that ogra_ just asked the same question ;-) [14:14] heh [14:14] 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] seems like soyuz doesn't handle that yet [14:15] * ogra_ guesses soyuz just knows $(dpkg-architecture -L), any, all [14:16] It might be a bit naive about CPU aliases [14:16] It does know about any-i386, say, but -arm is a bit different [14:17] so, should I open a bug for any-arm? [14:17] 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] or am i reading that just wrong ? [14:22] $ dpkg-architecture -aarmel -iany-arm; echo $? [14:22] 0 [14:22] therefore IMO you should file a bug on Launchpad about this, yes [14:23] lib/lp/soyuz/pas.py:determineArchitecturesToBuild doesn't implement the full architecture alias handling [14:23] aha === zyga is now known as zyga-food === bladernr_afk is now known as bladernr_ [15:02] barry: ping re usb-python. [15:05] ScottK: hi [15:05] Hello barry. Did you get the more detailed ping I sent yesterday? [15:05] ScottK: i didn't [15:05] OK. Let me find it. [15:06] [11:56:17] 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] Similar for python3-dbus. [15:06] ScottK: it's only a build-dep, right? [15:06] No, it's a run time Recommends. [15:06] That's why it gets pulled in. [15:07] It seems somewhat bogus to me. [15:07] But you've been in the code, so I wanted to see what you thought. [15:08] ScottK: ah right, it's in wheezy that way too. let me just look at a couple of things [15:08] Thanks. [15:14] 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] Any suggestions on how we could find out? [15:15] i guess i could grep through my installed precise *.py to see if i can track down any imports of it [15:16] Or any reference to ExportedGObject as that and ExportedGObjectType are the only classes in there. [15:16] yep, good idea === mfisch` is now known as mfisch [15:17] IIRC kees used to have the entire Ubuntu archive unpacked. Maybe he could do it ... [15:17] ScottK: well, just ran the import check. zero imports [15:17] Cool. === mfisch is now known as Guest39817 [15:17] and all references to ExportedGObject are in dbus itself [15:18] If it's not used in any packages, then I think it's safe to drop it to suggests. [15:19] ScottK: rather than separating it into a new binary package? [15:19] Yes. [15:19] that's an easy change [15:19] Yeah. [15:20] 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] 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] OK. I'm going to grab the rdepends and grep them, just to make sure. [15:21] cool [15:32] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: stgraber [15:34] 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] 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] barry: I take it back, they're all fine. [15:35] Sure. [15:36] ScottK: http://paste.ubuntu.com/807510/ [15:37] barry: What about python3-dbus? [15:37] yep, was just there :) [15:37] (that's what I was hoping for for python-dbus) [15:37] OK [15:38] ScottK: http://paste.ubuntu.com/807512/ [15:38] barry: Yes. Please. === 20QAAK923 is now known as jbicha [15:45] barry: Debian Bug#656230 [15:47] ScottK: got it [15:47] Great. [15:53] ScottK: uploaded [15:54] Excellent. [15:56] * barry -> reboot [15:57] does someone saw eglibc builds looping? [16:00] kirkland, hiya, do you think you can have a look at bug 917682? [16:00] Launchpad bug 917682 in byobu (Ubuntu) "Sync byobu 5.3-1 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/917682 === dendrobates is now known as dendro-afk [16:06] barry: do you think it would be useful if I packaged the 'six' module? [16:06] dholbach: i think it's been done [16:06] dholbach: http://packages.qa.debian.org/b/byobu.html [16:06] barry: writing compat layers for cases where wedging 2to3 into the build system is awkward is getting tedious very quickly [16:06] dholbach: oh, wait ... [16:06] kirkland, eh? [16:06] :) [16:07] dholbach: they want Ubuntu to sync from debian? [16:07] ScottK: i just have the archive mirrored; the unpack is relatively fast though. [16:07] dholbach: no, Ubuntu is upstream here; Debian byobu is downstream === dendro-afk is now known as dendrobates [16:07] kees: It turned out to be few enough packages that I downloaded them and checked. Thanks though. [16:07] 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] dholbach: thanks; the debian maintainer should propose a branch/merge/patch to lp:byobu [16:08] dholbach: and I'll integrate [16:08] get it on the sync blacklist if this is the case [16:08] lamont: How goes postfix 2.8.7? [16:09] ScottK: cool [16:09] ScottK: actually working on it now [16:09] lamont: Excellent. Thanks [16:11] 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 === zyga-food is now known as zyga [16:15] 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] 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] cjwatson: and i completely agree it's better than 2to3 :) [16:22] heh, yeah [16:22] alright, I'll knock a package together === dendrobates is now known as dendro-afk [16:31] ScottK: my ppa [16:31] lamont: I'm trying to remember what we decided on Bug #774500 ? [16:31] ScottK: if you would be so kind as to play with that some? [16:31] Launchpad bug 774500 in postfix (Ubuntu) "postfix build does not have documented support of sqlite" [Wishlist,Confirmed] https://launchpad.net/bugs/774500 [16:31] Sure. [16:32] ScottK: I believe we decided that I still have some work to do there [16:32] OK. [16:35] barry: https://launchpad.net/ubuntu/+source/dbus-python/0.84.0-2ubuntu3/+build/3099079 urk. [16:39] lamont: trying. [16:39] ScottK: do you know off the top of your head if libsqlite3-0 is effectively essential? [16:39] My recollection is we decided it was. [16:41] It's certainly in minimal. [16:43] ScottK: it's entirely possible that it's fixed in this upload [16:45] lamont: debc says there's no dict_sqlite.so [16:47] Might as well leave it for 2.9.0 at this point though. [16:51] lamont: Tests out fine here. I say ship it. [16:54] barry: I'm going to mash retry since you didn't change anything that would affect that. === deryck is now known as deryck[lunch] [17:02] 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] cr3: Yes [17:04] cr3: preseed files are declarative not imperative [17:06] cjwatson: thanks! === m4n1sh__ is now known as manish === bladernr_ is now known as bladernr_afk [17:22] barry: Failed again. Not sure what's up there. Over to you. === jcastro_ is now known as jcastro [17:35] barry: OK, six is in Debian NEW now === kalosaurusrex is now known as albriga === albriga is now known as albrigha === deryck[lunch] is now known as deryck [18:03] pitti: hey, [18:03] pitti: could you release a new postgresql-common for lucid? For the ppa:pitti/postgresql ppa? [18:04] pitti: release 128, which has pg_basebackup ;) [18:12]