[03:16] * micahg wishes people would ask for review of description changes before uploading [03:20] tumbleweed: flashplugin-nonfree is blacklisted from importing from Debian [05:23] Hi! Would anyone like to review/sponsor a patch for bug 614896? [05:23] Launchpad bug 614896 in avidemux (Ubuntu) "FTBFS on all architectures (maverick)" [Undecided,New] https://launchpad.net/bugs/614896 [05:30] * stalcup looks [06:19] artfwo: nice work, uploaded [06:20] stalcup, thanks! [06:20] thank you for your contribution [07:11] is misc:depends required on transitional packages? [07:17] I don't think so, but lintian won't understand that [07:17] so I just give lintian what it wants :) [07:44] I'd like to fix the package "openbios-sparc", which has no installation candidate and only exists as a source package in Ubuntu. The source-package has "Failed to build" for every release from Hardy to Maverick, but I think I know why [07:44] weedar: this is the part where you either make a branch where it works or make a debdiff [07:47] weedar: ever modified a package before? [07:48] maco: I can't say that I have [07:50] weedar: ok so im going to go through the shiny new ubuntu way with you... first: sudo apt-get install bzr ubuntu-dev-tools bzr-builddeb [07:52] could someone review/advocate http://revu.ubuntuwire.com/details.py?package=thawab ? [07:54] maco: downloading/installing those now [07:54] k [07:54] There are also two issues.. Firstly: the version in Lucid and Karmic,v1.0-1 (which is svn revision 463), is possible to compile but still doesn't really work - svn revisions 569 and 640 (this is the version in Maverick) do,however - so I'd like to provide one of those instead of making changes to the old (revision 464) one - is that a problem? [07:55] weedar: does maverick's compile? [07:56] i mean, does the package build? [07:56] if so, then a backport could be used [07:56] instead of you having to make changes to each [07:57] SRU might be possible since it's FTBFS ATM [07:57] yeah ive done that before [07:59] which brings me to the second issue: This package won't build for i386 "out-of-the-box", since it is a SPARC-based firmware (you can use it to run a SPARC-guest on an i386-system), you need cross-compiling support for sparc32 and sparc64 [08:00] weedar: sparc is about to be dropped from Ubuntu [08:00] micahg: Ah, just like it is for Debian then :( [08:01] weedar: debian's dropping it too? [08:01] debian drops archs EVER? [08:03] I'll have to look around for the source to my claim, but I read it somewhere while looking into the problems with this package [08:05] But even if I'm wrong about this, what is SPARCs future in Ubuntu? In the case of this package the package is meant to be (able to) run on i386, so technically it is a i386-package [08:07] weedar: unless someone steps up to maintain the toolchain, should be dropped shortly [08:07] Ah, here's where I read about SPARC-in-Debian: http://www.aurel32.net/info/debian_sparc_qemu.php - The line reading "Please note that Debian dropped SPARC32 support with Lenny, and that QEMU doesn't support (yet) SPARC64 targets." [08:08] incidentally that is the website of the debian-maintainer of the package I want to fix :) [08:10] micahg: Would that mean that this package would also be dropped? [08:10] weedar: only if it's not maintained [08:11] like you said it's an i386 package [08:12] Hopefully I can pick it up then :) [08:15] maco: You asked if maverick's version compiles..I will try that now [08:15] well just check whether there's a binary for maverick [08:17] maco: , no it's FTBFS since hardy [08:17] ohok [08:17] id say fix up maverick and then sru it backwards [08:21] maco and weedar: There's no point in trying to fix Maverick. Karmic, Lucid, and Maverick sparc flat out don't work. I know there are sparc boxen running Hardy, so that might be worthwhile. [08:22] ScottK: but its a i386 package.... [08:23] maco: Yes, but cross-compiling for sparc on a release where sparc doesn't work doesn't make a lot of sense to me. [08:23] ScottK: the purpose of the package is to let you run SPARC-guests in qemu on an i386-system [08:24] Does it need a working sparc kernel? [08:24] I guess the guests could be anything, so nevermind. [08:24] I wouldn't even need the package if it hadn't been decided to strip the openbios-binaries from qemu in Ubuntu [08:25] OK. Nevermind what I said then. [08:35] tumbleweed: you see my note before? [08:36] micahg: yes I assume this is re forwarding papercut description stuff [08:36] micahg: I forgot it was a permanent fork [08:37] tumbleweed: hi , thanks for uploading those .. on a related note, i'v always had a doubt, why does the changelog mentioned by the janitor switch my name and email fields? it does the same thing always.. but when i view changelogs it is the same way i have uploaded them [08:37] could someone review/advocate http://revu.ubuntuwire.com/details.py?package=thawab ? [08:39] vish: aah I was trying to remember where that issue was. Can you give me a bug number? [08:40] tumbleweed: ex: Bug 602717 , but this is the same even for the humanity icon theme where i use bzr [08:40] Launchpad bug 602717 in amule (Debian) "Description: aMule" [Unknown,New] https://launchpad.net/bugs/602717 [08:42] vish: It's because LP pulls information from your LP account, it doesn't just use what was uploaded. I've no idea on what planet that seemed like a good idea. [08:43] ScottK: hmm , but my lp account doesnt have my full name [08:44] same when i used bzr: Bug #540135 [08:44] I'm not sure then as in my case it tends to use information from my account that's not what I uploaded. [08:44] Launchpad bug 540135 in humanity-icon-theme (Ubuntu) ""Getting things GNOME!" icon" [Wishlist,Fix released] https://launchpad.net/bugs/540135 [08:44] Maybe it uses some mix. [08:47] depends on the bug, if it's an upload, it uses whatever is in the upload, if it's a sync, it uses the LP info AFAIK [08:48] The source-package in Maverick doesn't build, because debian/rules demands you use native SPARC for compiling and doesn't try cross-compiling [08:48] weedar: do you know how to fix that in the debian/rules? [08:52] maco: I can fix that, but it still won't build..I'm trying to see why - if I check out the same revision from the openbios svn-repository it compiles just fine [08:52] I don't know if it's possible: on Ubuntu we always build arch-all packages on i386, in debian maintainers can build it on whichever arch they need (because they do a binary upload) [08:54] I've also noticed that debian seems to offer some cross-compilation support directly, for example by having the package dpkg-cross - which doesn't exist in Ubuntu === yofel_ is now known as yofel [11:12] Anyone want to fix some FTBFS? [11:13] gdk-pixbuf/gdk-pixbuf.h: No such file or directory ← ones like that are due to incorrect/no use of gtk+-2.0.pc [11:13] should be fixable [11:14] Laney: what package? [11:16] lots [11:16] http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi see here [11:17] Laney: they just need to be retried [11:18] oh, maybe not [11:19] that was the libtool: link: `/usr/lib/libgdk_pixbuf-2.0.la' is not a valid libtool archive error that just needs a retry [11:30] http://pastebin.com/rWLRgAfJ here's an example diff for gpppon [11:49] micahg: free? [11:51] * Laney will sponsor any such fixes btw [11:52] Laney: bug #614927 [11:52] Launchpad bug 614927 in python-virtualenv (Ubuntu) "Sync python-virtualenv 1.4.9-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/614927 [11:54] bilalakhtar: was that one of those ftbfs? [11:54] nope [11:54] Laney: nope [11:54] that's what I meant [11:54] but I'll look anyway [11:54] Laney: thanks [12:00] Laney: I am going, comment on bug if any problem comes [12:00] bilalakhtar: I don't see that those changes have been taken [12:00] Laney: --distribute has been added [12:01] Laney: And test build worked [12:01] http://bazaar.launchpad.net/~barry/ubuntu/lucid/python-virtualenv/debsync-1.4.5-1/revision/7 this diff [12:01] none of that stuff is in it [12:01] Laney: so we need merge? [12:01] oops [12:02] I didn't see this [12:02] looks like it [12:02] Instead, I thought this diff was for debian/rules [12:02] Laney: ok, I will merge later [12:02] please forward to debian too when you do [12:05] wow, sbuild managed to bring my machine down [12:05] Not removing build depends: cloned chroot in use [12:05] E: 15killprocs: Segmentation fault [12:53] bilalakhtar: hi [12:55] micahg: hi [12:56] micahg: free? [12:56] bilalakhtar: for what? [12:57] micahg: sponsorship? [12:57] bilalakhtar: if it's in my package set [12:57] micahg: universe [12:57] bilalakhtar: no, I can only upload the mozilla package set [12:58] what's wrong with the queue? [12:58] micahg: fine [12:58] Laney: the queue is loooooooong [12:58] jumping it doesn't seem very nice [13:00] fine [13:01] what queue ? :) [13:02] ps. please make sure to forward changes to Debian [13:03] why is the sponsor queue not sortable any more? [13:04] debfx: is your proposed wormux package the same as in git? [13:42] Does anyone here have access to the Debian armel porter? [13:44] LucidFox: you can be given access if you email the porters afaik [14:32] LucidFox: armel works quite nicely with qemu-static [14:32] tumbleweed> The build problem I ran into only occurs in buildds, I can't reproduce it in qemu [14:32] LucidFox: aah [14:32] it also occurs in porter [14:34] Laney: I'd had the opposite experience, it wasn't sortable, so I requested dholbach to upgrade it so sorttable v2. Now it's sortable for me. I have another pending request to use a stable sort. What browser are you using? [14:37] tumbleweed: firefox [14:38] Laney: works for me. shift-reload? [14:39] nothing doing [14:40] :/ [15:37] Laney: yes, it's the same as in git [15:43] debfx: what was your problem finding a sponsor? [15:43] Ideally we avoid an ubuntu specific upload here [15:49] Laney: my sponsor experienced a wormux crash on sparc but hasn't had time to debug it [17:12] gilir: ping bug 575397 [17:12] Launchpad bug 575397 in nautilus-image-converter (Ubuntu) "Hungarian translation" [Undecided,New] https://launchpad.net/bugs/575397 [17:24] gilir: I look forward to your answer via launchpad. [17:45] Can I reject a patch for failing to be properly tagged? [17:46] who summitted the patch? a known contributor or an unknown one? [17:47] is the patch itself correct? [18:23] geser: Somebody who I've been tasked to intergrete into the community, and yes. [18:23] geser: So, a known contributor. [18:25] hi. is something wrong with launchpad? adding translations and viewing bzr branches doesn't work (neither edge nor stable) [18:25] are patch headers now a requirement or still nice-to-have? [18:25] nice-to-have afaik. [18:25] geser: I try to encourage people to do nice headers. If they were to say no, I'd be ok with it [18:26] geser: its an autogenerated quilt patch, even. [18:27] * tumbleweed rejects those [18:28] http://launchpadlibrarian.net/52759136/sugar-0.88_0.88.1-2ubuntu1.debdiff :) [18:28] anyway, I'll bbl, plane flight. [22:00] how is chromium so broke it can't get to amazon.com "WAITING FOR CACHE" [22:00] but can get to amazon.com/wheres-my-stuff [22:25] bluefoxicy: check all your tabs [22:25] bluefoxicy: there is a prompt on one of them [22:26] lifeless: no, it always does this. If I go anywhere where it decides to call on cache, it waits forever for cache [22:26] It seems to be senseless about it. [22:27] bluefoxicy: 'waiting for cache' - every time I've had that, there has been a prompt in another tab/window [22:27] e.g. a ssl cert prompt [22:27] or a password prompt [22:36] lifeless: doesn't seem to ever be the case for me [22:36] interesting [22:37] which components are enabled by default on server? [22:37] it also seems to only happen to specific sites (amazon.com, etrade.com)