[00:00] Rhonda: you can try running an x86 guest OS with qemu on your PowerPC notebook ;) [03:43] can someone please give back minitube on armel and powerpc: https://edge.launchpad.net/ubuntu/+source/minitube/1.1-1 [03:47] I'm stuck trying to run debuild on a package I grabbed using bzr ( bzr branch lp:ubuntu/gnome-system-tools ) [03:48] dpkg-source: error: can't build with source format '3.0 (quilt)': no orig.tar file found [03:48] funkyHat: you need to use bzr-builddeb [03:49] micahg: ah thanks ⡈) [03:49] funkyHat: np [03:51] ooh, that's a little broken (or I'm doing something else wrong) [03:52] bzr-buildpackage on its own failed, and bzr-buildpackage -S has no way to specify that I don't want to sign it, so that fails too [03:52] But it's ok, running bzr-buildpackage pulled down the orig.tar.gz so I can do it with debuild now ;D [03:53] funkyHat: it should actually generate the .orig.tar.gz from the bzr repo if pristine-tar is used [03:53] Oh, well it did perhaps do that [03:54] But the orig.tar.gz was there, which is the important thing ;D [04:00] micahg: lamont will run a script to resurrect all the failed builds once gcc 4.5 is done building on both archs. Probably tomorrow or monday. [04:01] ScottK: k, I won't worry about it then, thanks [04:08] ScottK: does that only apply to those archs, gnome-system-tools needs a rebuild I think, just testing [04:09] ? [04:09] funkyHat: Just powerpc and armel. We had a breakage yesterday and today in gcc that made almost all builds on those two archs fail. [04:10] ScottK: ok, I'll carry on filing this bug+branch then ⡈) [05:36] anybody here using pbuilder together with custom hooks? I'm trying to use the $BUILDRESULT variable in one of my hooks, but for some reason the variable is empty or not set to any value. The script itself is called just fine. /usr/lib/pbuilder/hooks/B10-test: http://paste.debian.net/87862/ [05:37] Output of that script from a pbuilder run is just "BUILDRESULT is set to ", so the variable seems to be not set to any value. I thought it was one of the "official" variables that I could use freely? [05:54] The pbuilder package has some example scripts in it. I'd check those. [05:55] ScottK: good suggestion [05:55] In fact I already looked at them [05:55] But there are none that use the BUILDRESULT variable, it seems [05:56] Actually, I have specified what BUILDRESULT should be in /etc/pbuilderrc and that's where the resulting debs are indeed put. [08:59] JanC: Sure, and learn to appreciate the speed of a c64 again? [09:14] funkyHat: bzr bd -S -- -us -uc (or any other debuild options you need) [09:33] tumbleweed: Thanks for that merge! [12:54] Hey everyone, I just uploaded my package to REVU. Would anyone check it out please. [12:56] OwaisL: what package? [12:56] gmailwatcher [12:56] it's in a ppa too [12:56] ppa:loneowais/ppa [13:28] why ubuntu maintainers never generate a .pot files in source packages? [13:45] * 52AACAD66 is away: Zurzeit abwesend === xfaf is now known as zul [14:03] DktrKranz: ping re: gtk-sharp-beans [14:03] and congrats on the point release ;) [14:07] * 52AACAD66 is back. [14:07] why ubuntu maintainers never generate a .pot files in source packages? [14:09] we don't translate universe packages in ubuntu [14:12] I have a question, since I'm writing my own app using GSettings [14:13] st__: Because there is nothing generated in the source package by ubuntu maintainers - that would be an upstream job to do. [14:13] At what stage are GSettings schemas compiled into the binary format? I've looked at evince, but the debs only install the XML files [14:13] and I can find no postinst commands or anything === 52AACAD66 is now known as ximion_ === freeflyi1g is now known as freeflying [14:57] Laney: will do after dinstall run is finished [14:57] cheers [15:27] AnAnt: السلام علئكم Thanks for that endorsement! But its incomplete! [15:28] bilalakhtar: yes, that is my first, I still didn't finish it [15:45] Laney: done [15:46] DktrKranz: thanks so much! [15:46] didrocks: we are nearly over the finish line [16:13] can someone sponsor bug 629495? [16:13] Launchpad bug 629495 in hamster-applet (Ubuntu) "Update hamster-applet to 2.31.90 in 10.10" [Undecided,New] https://launchpad.net/bugs/629495 [16:17] kklimonda: don't you need Ffe? [16:17] or is it just bug fix :) [16:19] Yes, I'd say that needs a freeze exception [16:22] Well, it's part of gnome and I've asked seb128 whether it's fine to go with it but I can always request an official FFe [16:22] please post that in the bug then [16:23] (that it has been approved) [16:25] mhm, done === paul__ is now known as Elbrus [17:46] I just added a debdiff to bug 621905, and subscribed ubuntu-sponsors, but I am not sure if that is correct with regard to any freeze [17:46] Launchpad bug 621905 in lazarus (Ubuntu) "lazarus in repo demands "Build Lazarus", that is not true." [Undecided,New] https://launchpad.net/bugs/621905 [17:47] or if ubuntu-sponsors was the right group to subscribe (the subscription went one step to quick where I wanted to verify) [18:04] hey, I uploaded my first ever package to REVU today. Got some errors warnings, anyone got time to guide me through? http://revu.ubuntuwire.com/details.py?upid=858 [18:07] Hmm, now I wonder why it says lucid and not maverick? [18:08] OwaisL: You sure about that number? It's archived since may 2008? [18:09] what's happening to me... [18:09] today [18:09] here it is [18:09] http://revu.ubuntuwire.com/details.py?upid=8582 [18:16] Which warning are you wondering about? [18:17] * RainCT updates REVU's config file (lucid->maverick) [18:17] RainCT: That's helpful indeed. :) [18:17] ok, the warning is gone now [18:18] Or wait a month and switch it directly to nattie? ;) [18:18] Heh. Hey, things don't change by themselves if nobody complained about them :P [18:19] OwaisL: Cool. You could start by looking at the warnings REVU is showing you [18:24] OwaisL: are you upstream for that app? [18:26] RainCT: Oh, I didn't notice. [18:26] Yes, I am. [18:38] OwaisL: Okay, I've left a review. By the way, are you aware that you can't get the package into Ubuntu until Maverick is released? [18:38] RainCT: yes, i know that. === yofel_ is now known as yofel [19:41] RainCT: Just two warnings left now. [19:42] RainCT: http://revu.ubuntuwire.com/p/gmailwatcher [21:01] o/ Laney [21:01] hoi [21:02] ok, bit of context for others before we carry on [21:02] !blogtk [21:02] !info blogtk [21:02] blogtk (source: blogtk): GTK Weblogging client. In component universe, is optional. Version 1.1-2ubuntu3 (lucid), package size 68 kB, installed size 572 kB [21:03] blogtk does not run in maverick, it fails because of a lack of python-gtkhtml2 which has been deprecated [21:03] AlanBell: ugh, I should fix that, we missed that in Lucid [21:03] the dependency was removed, but not the code, which left it non-starter in lucid and maverick [21:03] upstream is on launchpad here https://launchpad.net/blogtk [21:04] and the dependency is properly fixed, it runs, seems nice. [21:05] The upstream bzr and tar.gz includes a /debian directory and does not seem to be quite as expected when following the python packaging guide [21:11] thanks tumbleweed === yofel_ is now known as yofel [21:12] micahg: np [21:12] would it be best to create a new branch from lp:blogtk/2.0 without the /debian directory? or try to use what is there? I am not sure how to proceed === jrib1 is now known as jrib [21:14] AlanBell: why does it matter what thye have in bzr? Is there no release since fixing this? [21:15] tumbleweed: the tar.gz has /debian in it too [21:15] http://launchpad.net/blogtk/2.0/2.0/+download/blogtk-2.0.tar.gz [21:15] AlanBell: source format 3 deletes /debian in upstream source when unpacking [21:16] (3.0 quilt, that is) === warp11 is now known as warp10 === nhandler1 is now known as nhandler [21:16] ok, so that could be a good .tar.gz to start from then, excellent [21:16] * AlanBell is new to this packaging stuff === nhandler is now known as Guest53292 [21:17] yes, you should be able to use it [21:19] ok, should I be following the python packaging guide or is there a better document I should use? [21:19] s/better/more appropriate/ [21:20] AlanBell: are we abandoning the existing packaging? [21:21] oh, I see it was removed from debian [21:21] hmm, not sure. I checked the debian/patches directory and looked at the current source, most seem to have been applied upstream (or rewritten differently) [21:21] yeah, it is no longer in debian [21:21] tumbleweed: only because it was abandoned upstream [21:21] debian 551005 [21:21] Debian bug 551005 in wnpp "RFP: blogtk -- client for weblog systems" [Wishlist,Open] http://bugs.debian.org/551005 [21:21] and debian 443133 [21:21] Debian bug 443133 in ftp.debian.org "RM: blogtk -- RoQA; orphaned; dead upstream; few users; RC-buggy" [Normal,Open] http://bugs.debian.org/443133 [21:22] yeah, just read those [21:23] ok, the existing packaging isn't *that* bad [21:23] AlanBell: python-support's README is a reasonable guide for what's needed [21:23] so is the way forward to try and get it back in debian? or put it directly in Ubuntu? [21:24] is the project really alive again? [21:24] last commit 12 weeks ago... [21:24] trunk was last touched 12 weeks ago [21:25] the maintainer has ppa packages https://launchpad.net/~jayreding/+archive/ppa === tm__ is now known as tm [21:26] I'm just sceptical about including something which has been removed before [21:26] the 2.0 release was a year ago [21:27] it looks to me like development moved from sourceforge to launchpad and debian was waiting for the sourceforge one to be updated [21:27] Laney: we should either update it to 2.0 or drop it from maverick [21:27] Laney: it's currently in maverick, so if an update can save it from deletion, that sound sensible [21:28] micahg: right [21:28] http://blogtk.jayreding.com/blog/ [21:28] but yes, longer term it should either get back into debian or go away [21:28] tumbleweed: is it? No sense reviving unmaintained stuff [21:29] Laney: depends how unmaintained and how much revival is required [21:30] something which manages to release broken and then remain in that state for a further 3 months doesn't seem particularly maintained to me === Guest53292 is now known as nhandler [21:30] at the moment in maverick it is unstartable [21:30] but yes if someone is actually volunteering to take care of it [21:30] the problem is updating to 2.0 is that MOTU or its replacement would be obligated to support it for 18 months even if upstream is dead [21:30] then I'm all for fixing it… [21:31] the blog has quite a lot of posts about development updates going back to 2008 on a fairly regular basis [21:31] it's not just upstream, there has to be a distribution maintainer too [21:32] which is a continual problem with MOTU packages that we don't get from debian [21:32] right [21:32] I don't know if you're aware of my views on this. :) [21:33] * tumbleweed isn't. but personally I'm impressed by how bad they are whenever I come across one of those [21:33] basically don't do it [21:34] * micahg would suggest dropping from maverick, if someone is interested, go through the RFP in Debian, sync to natty and backport [21:40] erk. if any ubuntu-release people are here, please unsubscribe your team from bug 367990 [21:40] Launchpad bug 367990 in PyRoom 0.4 "Program crashes on startup" [Medium,Confirmed] https://launchpad.net/bugs/367990 [21:42] so the RFP is debian bug 551005 and the latest on that in January was that they were waiting for a 2.0.1 release [21:42] Debian bug 551005 in wnpp "RFP: blogtk -- client for weblog systems" [Wishlist,Open] http://bugs.debian.org/551005 [21:43] that being after the 2.0 release from 2009-09-22 I guess means they were not happy with the state of the 2.0 [21:43] AlanBell: ask DktrKranz === ScottK2 is now known as ScottK [21:47] DktrKranz: we are looking at blogtk which is currently broken in Ubuntu and not in Debian, you mentioned on debian bug 551005 that you were waiting for a 2.0.1 release, is that a blocker for the RFP? [21:47] Debian bug 551005 in wnpp "RFP: blogtk -- client for weblog systems" [Wishlist,Open] http://bugs.debian.org/551005 [22:22] any core devs? here's a main package that looks good (but listed under unseeded): https://code.edge.launchpad.net/~rsalveti/ubuntu/maverick/x-loader/fix-628243/+merge/34325 [23:07] Hi there, I am the author of Shutter. Is there anything I can do to get an update of Shutter into maverick? I've already requested an update here: Bug #626704 [23:07] Launchpad bug 626704 in shutter (Ubuntu) "[Update package] Shutter 0.86.3" [Undecided,New] https://launchpad.net/bugs/626704 [23:07] mario-kemper: I suggest you mail the Debian maintainer [23:08] Already done - he is not responding currently [23:10] I'll open another bug in the debian bug tracker to get his attention [23:48] bah, I like pixelize from 0.86.0 release but at this point it would require a Feature Freeze exception and a good soul to sponsor it ;) [23:49] kklimonda: that's newer than 1.0.0-1? [23:50] kklimonda: I well reasoned FFe that include "Upstream asked us to update" and a good draft package has a reasonable chance of getting an FFe for Universe. [23:50] ScottK: I can probably prepare one then [23:51] micahg: what do you mean? [23:52] kklimonda: even dapper has pixelize 0.9.2, 1.0.0-1 has been around since karmic [23:53] ajmitch: pixelize as in the feature of 0.86.0 release where you can hide parts of screenshot unde.. pixels ;) [23:53] I was just checking the changelog of shutter :) [23:54] ok, shutter.. you hadn't mentioned the package name, so we assumed that you meant pixelize :) [23:54] ajmitch: yeah, I can see that now :)