=== almaisan-away is now known as al-maisan [06:57] good morning === al-maisan is now known as almaisan-away [10:55] tumbleweed: can i do a udt release? [10:57] bdrung: yup, I picked off the low hanging fruit a day or two ago [10:57] tumbleweed: or do you want to do the upload? [10:57] * tumbleweed doesn't care too much [10:57] thanks for sorting out devscripts dch [11:02] tumbleweed: it needed some thought to work on all distributions correctly [11:03] it does feel like distro-info is going to need some re-architecting when we have more distros [11:05] tumbleweed: yes, but as long as every distro has a different release model, it makes no sense [11:05] yup [11:12] tumbleweed: when can we drop reverse-build-depends? [11:14] when reverse-depends gets an offline mode? [11:14] Laney: reverse-build-depensd is a reverse-depends wrapper [11:15] oh [11:15] i thought it was a standalone command [11:15] or was it before? [11:15] it used to be [11:15] i see [11:16] don't see why it needs removing then [11:16] bug 910420 [11:16] Launchpad bug 910420 in ubuntu-dev-tools (Ubuntu) "[reverse-build-depends] Vanished" [Wishlist,Fix released] https://launchpad.net/bugs/910420 [11:16] give it another release or two... [11:16] doesn't cause any harm ... [11:17] it results in a lintian complaint, because there isn't a manpage [11:17] then i want a man page [11:17] hahaha [11:37] uploaded [13:33] I am merging vim from unstable for quantal, but get an error from debuild because of a locally modified po file: http://pastebin.com/raw.php?i=Ht1Qefmi Any hint why that is? [13:33] debuild output: http://pastebin.com/raw.php?i=JfHH9RTN [13:35] Probably because the po files get rebuild in a different way than upstream does..?! [14:02] blueyed: I usually merge vim by hand (apply the Ubuntu delta) and handle the few patch rejects by hand (usually only debian/changelog) [14:02] and don't bother with updated po-files (I don't know where it comes from in the first place) === almaisan-away is now known as al-maisan [15:50] http://paste.ubuntu.com/1054482/ [15:51] Hello [15:51] subscribes you to your uploads for X days [15:52] Do I get it right that dh_make only debianizes the extracted upstream tarball directory? [15:52] i.e. it only create debian/ ? [15:53] yes [16:00] Ah, it created orig.tar.gz as well... [16:02] that sounds like something you don't want [16:02] take the .tar.gz you got from upstream and rename it [16:02] 'man dh_make' says: "Then dh_make proceeds to generate a "debian" subdirectory and the necessary control files in the program source directory." What do "necessary control files" refer to? [16:03] the things inside debian [16:11] Ok thanks! [16:12] I don't want to use dh_make since it confirms settings before it debianizes (thus causing me not being ble to automate with a bash script). [16:13] s/ble/able [16:14] why are you automating this? [16:15] packaging something is something you do once. you keep the package and incrementally improve/update it [16:16] Upstream devs want a script that automates local deb creation. So that they can build locally (ideally after every commit). [16:17] keep enough packaging in the trunk then? [16:17] For PPA, I'll be using incremetally update model (UDD?) [16:17] LP daily builds are also great for this kind of thing [16:17] anyawy, dh_make gives you a tempalte. It doesn't give you packaging that's going to work (necessarily) [16:18] Yes, that's why I can use a script to automate what dh_make does. [16:18] you might find pkgme does a better job [16:19] I will keep debian/ in a separate repo. My bash script branches upstream/ AND upstream-debian/ and copies debian/ to upstream/ [16:19] * AmberJ_ googles pkgme [16:19] that sounds like a very sensible approach. It's essentially how one usually does LP daily builds [16:20] Does "LP daily builds" mean "PPAs"? [16:21] AmberJ_: https://help.launchpad.net/Packaging/SourceBuilds [16:22] ok. upstream devs want a script to build locally (on their server) after every commit. LP builds tend to be in queue for hours before they are built. [16:22] you can use it locally [16:22] But I didn't knew about LP daily builds. Thank you very much! [16:22] yes reading === al-maisan is now known as almaisan-away [16:24] it does require you to use bzr, though [16:25] yes, upstream uses bzr/launchpad [17:07] https://bazaar.launchpad.net/~laney/+junk/lp-subscribe-uploads/view/head:/lp-subscribe-uploads [17:07] could/should something like that go in udt? [17:07] wasn't thinking about that when I was writing it, so maybe it needs some adjustment [17:11] I see subscription and unsubscription, but no actions [17:12] actions? [17:12] something that tells you about bugs [17:12] it doesn't do that [17:12] it subscribes you so that LP sends you them [17:13] oh, duh [17:29] Laney: sorry, got distracted. But, yes (lptools would also be a plausible home, but this is more ubuntu-specific I think) [18:05] somebody with chromium installed here ? [18:06] if so, please surf to www.hln.be , also getting white screen ? [19:05] slangasek: ping === ashams_ is now known as ashams [19:44] FernandoMiguel: hi [19:44] slangasek: hi. sorry to bother you [19:44] I'm trying to dig into why last night updates broke both my systems [19:45] one I got back by just installing ia32 libs [19:45] but this laptop is still broken [19:45] The following packages have unmet dependencies: [19:45] ia32-libs : Depends: ia32-libs-multiarch but it is not installable [19:46] FernandoMiguel: the error at the bottom of the log you sent me shows you have a broken version of dpkg installed and are affected by bug #1015329. You'll need to follow the recovery instructions posted in that bug description. [19:46] Launchpad bug 1015329 in dpkg (Ubuntu) "dpkg fails to run after update (error: file triggers record mentions illegal package name `libgtk2.0-0' (for interest in file `/usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules'): ambiguous package name 'libgtk2.0-0' with more than one installed instance)" [Critical,Fix released] https://launchpad.net/bugs/1015329 [19:47] thank you [19:47] ill have a look [19:52] slangasek: thank you once again. that did the trick === ashams_ is now known as ashams === yofel_ is now known as yofel [20:47] us [21:17] https://help.launchpad.net/Packaging/SourceBuilds/BzrBuilder#Running_commands_in_recipes says: "Note: Launchpad does not support the run command. " [21:18] How do we specify that I need to run tools such as cmake or autotools for LP daily builds? [21:19] s/we/I [21:21] in debian/rules [21:23] If I have a rule in debian/rules, do I need to specify run command in package.recipe ? I guess no (but then why does link above explicitly mentions about 'run autotools') [21:24] Or maybe, I don't get it right [21:24] no idea [21:24] quite pointless when launchpad does not support it [21:24] Ok, let me try building locally on my system without adding 'run autotools'. [23:39] Err... this is weird. Upstream compiles fine if I run: 'cmake .' and then 'make'. But if fails on PPA as well as locally (when using debuild). [23:39] Here's the PPA buildlog: http://paste.ubuntu.com/1055180/ (please scroll down to line 3883) [23:40] I don't understand why the build exits with error when using debuild. It builds fine when using 'make'.