[00:06] hello [00:06] Hello marcin_ant [00:07] is there any packaging guru that could answer me few questions? [00:07] I'd suggest going ahead and asking instead of asking if you can ask :) [00:08] ok I'll shoot [00:09] I think that debian policy and ubuntu packaging guide are pretty weird and I really don't understand it's policy according to non-native packages [00:09] I got an example [00:09] I want to package application that is available as upstream tar.gx [00:09] gz [00:11] but inside this tar there is a bunch of directories let's say dira dirb dirc [00:12] I want to create few packages from this upstream let's call it test-dira, test-dirb, test-dirc === asac_ is now known as asac [00:12] so I created directory named test-dira-1.0 then directory named debian [00:12] in it [00:13] and in debian dir I created all required files and watch file with required path [00:13] I also added get-orig-source target with uscan script [00:14] marcin_ant: if you have one orig.tar.gz, you have one source package and one debian/ directory. then from that source package you can create multiple binary packages [00:14] then I returned to test-dira-1.0 and: debian/rules get-orig-source [00:14] Adri2000: please read carefully what I write [00:15] Adri2000: I understand that I got one source package and I understand that I can create multiple packages from it [00:15] Adri2000: but this "story" is not about it [00:15] marcin_ant: well you're not doing it correctly [00:15] and that's what Adri2000 is trying to tell you. [00:16] it's unclear from your abstract example exactly what you are trying to do [00:16] what are dira, dirb, and dirc in relation to the orig.tar.gz? [00:16] just few words [00:17] jdong: problems are: 1. orig.tar.gz doesn;t have single directory inside it has 3 directories called dira, dirb, dirc [00:17] you've said that. [00:17] anyway I'll just finish [00:17] I asked what specifically are a b and c? [00:17] and what would you like to turn them into? [00:17] so I run debian/rules get-orig-source [00:18] then get-orig-source downloads upstream package to parent of debian [00:18] this is the place where should upstream orig.tar.gz go [00:19] so I got: [00:19] ~/dira.orig.tar.gz [00:19] ~/test-dira-1.0/ [00:19] why do you have dira.orig.tar.gz? [00:19] I thought you said orig.tar.gz contained dira, dirb, and dirc? [00:20] jdong: because it is upstream name [00:20] ok, then what are dirb, and dirc for? [00:20] are they supporting libraries / dependenices? [00:20] related binaries? [00:20] jdong: read again - they are inside of dira.orig.tar.gz [00:21] *YOU SAID THAT* [00:21] I am saying your abstract example is too vague for me to say anything useful. [00:22] I'm trying to understand why upstream has three directories inside a source tarball for a project where one name is dominant [00:22] jdong: get this upstream: http://plone.org/products/archetypes/releases/1.4.6/archetypes-1-4-6-final-bundle-tar.gz [00:22] lol ok that's annoying enough upstream made a bundle that's a tarbomb [00:24] jdong: or maybe better 1.4.5 release because 1.4.6 has bug in it's name... [00:24] http://plone.org/products/archetypes/releases/1.4.5 [00:24] anyway take a look what is inside [00:25] yeah I am looking at it right now [00:25] upstream's site is timing out right now (45s and counting), is the software available in an unbundled tarball? [00:25] it seems like the sub-directories are distinct python modules (packages) [00:26] apt-get source zope-archetypes [00:26] you will get orig.tar.gz 1.4.2 version (afair) [00:27] ok, cool, so it has already been packaged [00:27] jdong: packaged 1.4.2 current from 1.4 branch is 1.4.6 [00:28] ok, so you just need to update it to the latest upstream version [00:28] jdong: ok but now we can talk about something less abstract ;) [00:28] so, it uses the one "source package generates multiple binary packages" paradigm [00:29] jdong: ok but let's say that I want to make few changes in /debian directory [00:29] the alternate case is repacking the source tarball into several distinct source packages [00:29] alright? [00:29] jdong: ok propably - but it's not a problem for me to produce multiple binaries from this source tar [00:29] jdong: problem is different [00:29] continue :) === woody86- is now known as woody86 [00:30] jdong: I really don't understand what to do with it's internal directory structure [00:30] NB: zope-archetypes was removed from debian, replaced by zope-plone3 [00:30] marcin_ant: what ajmitch is probably relevant now [00:30] marcin_ant: but at any rate, to answer your original question [00:31] marcin_ant: so the orig.tar.gz file is simply the same thing as the tar.gz you get from upstream [00:31] jdong: right [00:31] marcin_ant: the diff.gz file from Debian is a patch to the extracted .tar.gz directory [00:31] marcin_ant: it primarily is supposed to add the debian/ directory [00:31] marcin_ant: roughly what's done when you apt-get source is "tar xzvf orig.tar.gz; cd orig-folder; zpatch -p1 < ../diff.gz" [00:31] jdong: and if I will run tar zxvf on it I will get a bunch of directories instead of single dir [00:32] marcin_ant: in this case, there's a notable exception that the upstream tarball is a tarbomb [00:32] i.e. it blows up into multiiple directories in the current directory :) [00:32] marcin_ant: dpkg-source (the extractor) is smart enough to detect this situation [00:32] jdong: right [00:32] marcin_ant: it automagically creates a sourcepackage-1.2.3 directory first and then unpacks inside of there [00:33] hey guys, I am trying to do the debian/watch part of the packaging guide, and usan is not finding anything at the url I am putting in [00:33] marcin_ant: if you want to make a change and build a source package again, you simply run debuild -S [00:33] jdong: ok but let's use this as an example [00:33] marcin_ant: the system will be smart enough to detect what you changed, use the orig.tar.gz and update the diff.gz [00:33] marcin_ant: if you want to update to a new version, you need to use the uupdate tool [00:34] marcin_ant: it takes a tarball for the new upstream version as an argument, and correctly rebases the existing diff.gz on top of the new orig.tar.gz [00:34] jdong: let's say that I want to do this from scratch let's forget about 1.4.2.deb etc [00:34] marcin_ant: ok, if you want to do it from scratch, in this case [00:34] marcin_ant: you'd first make a archetypes-1.4.2 directory [00:35] marcin_ant: then you'd unpack the orig.tar.gz into there [00:35] jdong: zope-archetypes-1.4.2 [00:35] marcin_ant: yeah, you get my point [00:35] jdong: ok and that is a problem(!) [00:35] marcin_ant: then you can run dh_make inside there, letting it know where your orig.tar.gz is [00:35] jdong: orig.tar.gz will not unpack into this directory [00:36] marcin_ant: why not? [00:36] jdong: https://wiki.ubuntu.com/PackagingGuide/Complete says that: [00:36] mkdir ~/hello && cd ~/hello && wget http://ftp.gnu.org/gnu/hello/hello-2.1.1.tar.gz [00:37] marcin_ant: the packaging guide is written under the assumption upstream isn't retarded and packages their product as a tarbomb. [00:37] jdong: so in our case I should: mkdir ~/zope-archetypes-1.4.2 [00:37] marcin_ant: so yes, in our case we have an exceptional case where upstream is retarded [00:37] jdong: cd zope-archetypes-1.4.2 [00:37] jdong: ok I get it [00:37] jdong: but another thing [00:38] jdong: this upstream is really nightmare [00:38] marcin_ant: note that the orig.tar.gz doesn't get wgetted into ~/zope-archetypes-1.4.2 :) [00:38] marcin_ant: so it'd be more like mkdir ~/zope; cd ~/zope; mkdir z-a-1.4.2; wget tar.gz, cd z-a-1.4.2; tar xzvf ../*.tar.gz, and so on [00:38] but you get my point [00:38] jdong: yes I noticed and this is a part of my next question [00:39] jdong: there is a lot of packages that have single directory inside tarball [00:39] yep, that's the way it's supposed to be, in fact [00:40] jdong: but these direcories have different name [00:40] jdong: let's say that we want to create package zope-archetypes and got zope-archetypes.orig.tar.gz [00:40] jdong: with single dir inside called Archetypes [00:41] marcin_ant: the dpkg-source helpers that handle the orig.tar.gz for you are generally smart enough to figure this out [00:41] marcin_ant: they work around most of the quirks with packaging conventions [00:41] jdong: then I just can untar and create debian dir inside this Archetypes directory - right? [00:41] marcin_ant: correct [00:41] marcin_ant: note for dh_make to work you must rename that dir to archetypes-1.4.2 [00:41] jdong: ok so last thing [00:42] marcin_ant: dh_make requires the current directory to be in format (name)-(upstream version) [00:42] jdong: let's say that I don't have upstream tarball yet [00:42] * pangloss pokes nhandler [00:42] jdong: or I want to create new upstream version [00:43] jdong: I got: ~/zope-archetypes/zope-archetypes-1.4.2/debian [00:43] jdong: I create all required files in debian dir and I also watch file with url to upstream and get-orig-source [00:44] jdong: then I cd to ~/zope-archetypes/zope-archetypes-1.4.2 and run debian/rules get-orig-source [00:45] jdong: it will download tar.gz for me and this will be renamed to orig.tar.gz and will go to: ~/zope-archetypes (parent of zope-archetypes-1.4.2) [00:46] jdong: so far so good but it's not good because zope-archetypes-1.4.2.orig.tar.gz will not untar sources to zope-archetypes-1.4.2 (where debian directory is) [00:46] marcin_ant: that's okay [00:46] jdong: it will untar sources to Archetypes.... and what should I do with this? [00:46] marcin_ant: dpkg-source doesn't just blindly run an untar [00:47] marcin_ant: the actual dpkg-source command that unpacks a Debian source figures this out [00:47] marcin_ant: I'll give you an example from your archetypes package: [00:47] marcin_ant: go back to "apt-get source zope-archetypes" like we did before [00:47] marcin_ant: if you notice, it fetches three files: .dsc, .diff.gz, .orig.tar.gz [00:47] jdong: ok I need to test it [00:47] marcin_ant: if you look at the .orig.tar.gz, it's the same 5-different-directory source archive [00:48] jdong: right [00:48] marcin_ant: but when apt-get source runs "dpkg-source -x foo.dsc", it gets unpacked into zope-archetypes-1.4.2/ [00:48] marcin_ant: that's what I'm saying -- dpkg-source -x takes care of this discrepancy for you [00:48] it's something that you don't have to worry about [00:48] jdong: what if it;s initial release? [00:48] I need to untar this manually to zope-archetypes-1.4.2? [00:49] marcin_ant: ok so let's say we're dh_making manually because this is the first release [00:49] marcin_ant: remember how we just got over how to manually unpack the tar.gz to the right directory, then run dh_make? [00:50] marcin_ant: well, after you do that *once* , run dh_make, and tweak debian/* to be the way you like it [00:50] then you run debuild -S [00:50] that builds the orig.tar.gz, .diff.gz, and .dsc file in ../ [00:52] jdong: ok I (propably) get it ;) [00:52] marcin_ant: alright, cool. hopefully that was a bit helpful :) [00:52] marcin_ant: it takes some time to sink in, and a lot of practice ;-) [00:53] jdong: it's weird and it's NOT described at all in CompleteGuide(!) [00:53] I also might suggest starting off trying your first package with something that goes by the rules a bit better [00:53] marcin_ant: Over my entire course of packaging software for Fedora, Ubuntu, and Gentoo this is about the 3rd time I've seen a tarbomb from upstream [00:53] marcin_ant: it is by far the minority of cases :) [00:53] it's not my first package it's first that has so ugly upstream [00:54] marcin_ant: but I think the key point to take from this is that dpkg-source's extractor and builder has a bunch of magical rules built in that try to intelligently work around these inconsistencies [00:54] jdong: I got bad luck as always ;) [00:54] in general that stuff will work if you trust your tools :) [00:54] otherwise a bit of digging through manpages and script sources might get you a more concrete understanding [00:54] I admit that I'm not in the latter group :) [00:55] I just blindly use my tools and scream loudly here when they don't work! [00:55] jdong: to be honest I really would like just download tar and put it untarred in package and then use tarball.mk from cdbs and it would work without any problem :) [00:55] :) [00:56] holy crap who exploded in my launchpad account? [00:56] I've got 50 new bugmail [00:56] jdong: thank you very much [00:56] Heh [00:57] marcin_ant: you're absolutely welcome :) [01:02] Hi, I am submitting a new version of my Package (Easycrypt) I need to update both Hardy and Ibex - do I submit 2 bugs? [01:09] How can I get involved? [01:10] Thayle: see link in topic [01:11] Oh, hehe, didn't notice that... [01:11] no probs, let us know if you have any specific questions that doesn't address :) [01:11] Alright, thanks jdong. [01:31] asac: stupid question: How do you start firefox with a different profile but NOT have it remember that profile the next time you invoke a firefox? [01:32] asac: i.e. I have a "default" and "appliance" profile. How do I make Firefox use profile "default" unless I explicitly start it with the "appliance" profile? [01:33] playing around it seems like FF is pretty good at remember the last profile you told it to use [01:46] hi Any MOTUS abot o check https://bugs.edge.launchpad.net/ubuntu/+source/easycrypt/+bug/293903 [01:46] Launchpad bug 293903 in easycrypt "Candidate revision easycrypt_0.2.3.0-0ubuntu" [Undecided,Confirmed] [01:55] jdong: err not sure ;) -P ? [01:56] yeah just -P and then select the profile without "remember" ;) [01:56] maybe not the best solution cant really remember that it remembers the last used if you specify it at command line [01:56] if it does that then -P is most likely the only workaround [01:58] asac: hope I have given enough info on bug 83229 [01:58] Launchpad bug 83229 in firefox "could not close window with ctrl-W until I clicked on the background" [Undecided,Incomplete] https://launchpad.net/bugs/83229 [02:00] asac: lol ha like there's a "remember" option ;-) [02:08] Hi Jazzva [02:09] Hello nhandler [02:58] Is MoM being updated? It only goes up to 'm' right now [02:58] there was an issue [03:00] yes [03:00] lol [03:02] * jdong gives himself stupidity cookie. [03:02] /usr/bin/skype: "cd /usr/lib/skype && skype" [03:02] 5 minutes and 10 gigs of swap later. D'OH [03:03] huh? [03:03] coppro: think about it. [03:03] * coppro is not that familiar with skype... [03:03] coppro: /usr/bin/skype runs "cd /usr/lib/skype && skype" [03:04] oh [03:04] that would be a problem [03:04] :) [03:04] ./ much? [03:04] ouch. [03:04] coppro: yeah yeah :P [03:05] coppro: that's revision ~crack2 :P [03:09] Anyone having any issues uploading to REVU? [03:09] NCommander: I don't think so [03:09] * NCommander had one of his uploads rejected [03:09] nope, I'm good [03:10] the update for http://revu.ubuntuwire.com/details.py?package=metakit worked fine [03:10] NCommander: is it set to jaunty? I've had some issues related to that (not with REVU, but other package tools) [03:10] Yeah [03:11] NCommander: you don't deserve to upload yet? [03:11] .... [03:11] * NCommander whacks ajmitch with a stick of DOOM [03:11] where do the crontab logs end up on spooky? [03:13] spooky? [03:13] coppro: The server hosting REVU [03:13] oh [03:58] TheMuso, I have two merges that needs uploading, cegui-mk2, and midori [03:59] NCommander: Do you have bugs for them, or do you just have some files I can grab from somewhere? [03:59] I can kick the changesets onto mentors since REVU is kinda broken ATM [03:59] NCommander: Whereever is easiest for you. [04:01] TheMuso, http://mentors.debian.net/debian/pool/main/m/midori/midori_0.1.0-1ubuntu1.dsc [04:03] grabbing. [04:05] NCommander: revu ought to work... sort of [04:05] ajmitch, its been fixed? [04:05] (or hit with a big enough hammer?) [04:05] heh [04:05] NCommander: I said that before [04:05] mkdir /root/.gnupg to work around it for now [04:06] untested with running it from cron, but it should have accepted your upload [04:07] the directory just has to exist, it doesn't even need to put anything in there [04:07] oh good, I can stop using mentors [04:07] s/using/abusing/ [04:07] lol [04:07] nothing in mentors ToS says it has to be used for Debian review work [04:07] Or more specifically, nothing outlaws Ubuntu reviewers from using it [04:08] I doubt that the admins want the bandwidth & diskspace used for such a purpose [04:08] * NCommander notes he uses REVU for Debian package reviewing [04:08] and mentors for Ubuntu ... [04:08] Go figure [04:14] NCommander: re midori, since it is a merge, you have dropped all prior changelog entries. I.e the only changelog entry you have is the merge entry, and no other entries from previous ubuntu changes. [04:15] I swore I didn't do that ... [04:15] Argh [04:15] TheMuso, hold on [04:15] np [04:17] TheMuso, there [04:17] Fixed and reuploading [04:17] NCommander: Ok. [04:17] NCommander: on mentors? [04:18] no, REVU, since that's working now [04:18] oh ok. [04:18] not on front page yet. [04:22] * ajmitch refreshes & hopes that it shows up [04:22] hm.. [04:23] the directory exists [04:23] ajmitch, its working [04:24] I just didn't see it on the revu frontpage [04:24] ajmitch, its in updated packages [04:24] (since its not new) [04:25] good [04:28] NCommander: test building midori. [04:30] NCommander: uploaded. [04:31] yay for my first jaunty upload [04:31] NCommander: And your second merge? Is that ready for review/upload? [04:31] yup [04:31] * ajmitch needs to find something to merge [04:31] ok [04:31] ajmitch, MoM [04:31] NCommander: MoM doesn't have its main/universe lists generated at the moment, either [04:31] ajmitch, yes it does [04:32] so it's digging through package directories [04:32] http://merges.ubuntu.com/ <-- do you see universe.html there? [04:32] Oh [04:32] Hrm [04:32] Where'd it go [04:32] It was there less than an hour ago [04:32] ran off with DaD [04:32] I see it not on revu... [04:33] NCommander: cegui-mk2 doesn't seem to be on revu. [04:33] yeah [04:33] Odd [04:33] Oh [04:33] bah [04:33] its on its way [04:34] ok. [04:42] Upload complete [04:42] ok. [04:42] ajmitch, run move_uploads.sh for me [04:42] * jdong starts debdiffing marillat [04:45] Grabbing. [04:52] StevenK: Would you be around and able to do a sync for me to fix a security bug? [04:53] ScottK: Possibly [04:54] StevenK: Would you be up for syncing libspf2 out of incoming. The Debian Maintainer nicely left the LP reference in debian/changelog and everything. [04:55] 8/c [04:56] ScottK: Version in Intrepid/Jaunty is -0ubuntu1. Do you have a sync bug? :-) [04:57] I'm writing it as we speak. [04:58] StevenK: Bug #293956 [04:58] Launchpad bug 293956 in libspf2 "Please sync libspf2 1.2.9-1 from Debian Unstable (Main)" [Undecided,New] https://launchpad.net/bugs/293956 [04:59] Is it unstable, or incoming? [04:59] Incoming [04:59] It's aimed at Unstable. [05:00] StevenK: ^^ [05:02] Hi all.Can we already request syncs for Jaunty? I've just updated Bug #275534. [05:02] Launchpad bug 275534 in enblend "[sync request]Please sync enblend 3.2 from Debian experimental" [Wishlist,Confirmed] https://launchpad.net/bugs/275534 [05:04] fabrice_sp: You can, but you shouldn't mark it confirmed unless you are MOTU and have confirmed it is ready. [05:05] ScottK: ok. So I'll let him as NEW. Thanks. [05:05] ScottK: Synced [05:06] StevenK: Thanks. [05:06] * StevenK adds one to the beer tally [05:06] Interestingly enough he nicely said "merge changes from Ubuntu" and left the Ubuntu changelog entries in. [05:06] That's more generous than I usually see. [05:07] ScottK, most debian developers like to forget we exist [05:07] * ScottK is still not going to UDS, so keep the list in a safe palce. [05:08] wgrant: I thought you might enjoy Bug 293950 [05:08] Launchpad bug 293950 in launchpad "Software related to ... page lists wrong "Uploaded to" for packages in Testing/Unstable" [Undecided,New] https://launchpad.net/bugs/293950 [05:10] ScottK: Its presence in Lenny or Sid is unrelated to Ubuntu. [05:10] But yes, it's still wrong. [05:10] wgrant: True. Feel free to pile on. [05:11] It might just be because gina was run over Lenny first,. [05:11] So it should be fine for future packages. [05:11] wgrant: The why isn't my problem. [05:11] I'll be able to tell once auto-sync runs. [05:12] I'm not sure if the autosync is going to be using NSS yet, so that might well be irrelevant. [05:13] NSS? [05:14] Which would the autosyncer using Name Service Switch? [05:14] Native source syncing [05:14] Oh [05:15] NCommander: cegui-mk2 uploaded. [05:15] \p/ [05:15] uh [05:15] \o/ [05:17] * StevenK is trying to understand native source syncing [05:18] why would it be differnet [05:18] just don't copy a base tarball [05:18] or rather, only copy [05:20] StevenK, new LP interface/CLI? [05:21] NCommander: Huh? [05:22] StevenK, I take it some sorta new launchpad interface for doing native source syncing? [05:22] NCommander: I have no idea [05:23] Is it active yet? [05:23] NCommander: I don't know anything about it myself [05:23] Ah [05:24] https://blueprints.launchpad.net/soyuz/+spec/native-source-syncing [05:30] persia: As is usual for a LP spec the useful information isn't available "You are not allowed to view this page." [05:31] ScottK, Certainly, although it helps make it clear that "native" is about native-to-Soyuz, rather than being about native packages. [05:32] persia: Perhaps for you. From the small crumbs the customers are allowed to see it's not clear how that relates to syncing at all to me. [05:33] Huh? I don't see anything different than you. [05:33] https://dev.launchpad.net/ - it will be here soon enough [05:33] persia: Yes, but it sounds like you (or someone) is making a connection that I'm not understanding. [05:34] NCommander: It's already past the promised date for it. [05:34] NCommander: sorry, I was out, hopefully revu did the right thing for you [05:35] ScottK, Oh. That's me. As I read it, it's about having some shiny button that lets one sync sources directly, rather than having someone run the syncpackage script. [05:35] ScottK, ? [05:36] Should address the Hobbsee-can't-sync issue. [05:37] OK. I don't see that in the snipper, but we'll see someday I guess. [05:39] Well, I could be mistaken, but as I understand it, the archive-admins just run a script to work around it missing in Soyuz now, and "natively" means to me "inside Soyuz". [05:39] (at least in the context of a Soyuz spec) [05:41] Right and I read it as mashing stuff from one Ubuntu pocket to another. No idea if that's at all right. [05:47] Ah. The difference being that I've also looked at the summaries for https://blueprints.launchpad.net/soyuz/+spec/sync-workflows and have seen glimpses of an apparent Debian archive import on staging in the past. [05:58] hmm? [06:01] Hobbsee, native-source-syncing possibly meaning you get a button to perform syncs (as I believe that's one of the archive-admin tasks that doesn't work for you). [06:07] oh, that would be nice! [06:07] any ETA, or? [06:07] just that they're planning it? [06:08] i hope the button is shiny. shiny buttons are always more exciting [06:08] No. The spec just came up in conversation, and the spec is private, so I was guessing as to the effect. [06:10] hmm. That looks old to me. [06:10] Rather old. Yes. Still desired by many. [06:11] that's irrelevant, surely :P [06:11] a whole lot of them are sitting with 1.2.x milestones, which, afaik, has long passed, so it certainly doesn't look anywhere near current. [06:12] Threrefore, no point at all getting excited. [06:12] Hobbsee: NSS is being implemented. That's why we have Debian imported into LP now. [06:13] wgrant: yes, that one is. That affects a lot more people. [06:13] wgrant: doesn't necessarily mean that anything's happening on related bits. [06:13] Perhaps. [06:13] Hrm? Doesn't NSS mean a shiny button for archive-admins? A shiny button for the rest of us would be nice, but I thought that was sync-workflows [06:14] persia: via command line, yes. [06:14] It makes the shiny button possible to implement. [06:14] wgrant: What is NSS. [06:14] ScottK: Native Source Syncing. [06:15] wgrant: I know what the acronym is. I don't know what that translates to in the system. [06:15] ScottK: copy-package.py, but for Debian packages too, basically. [06:16] So copying the package within Soyuz. [06:16] ScottK: means you can do stuff like copy packages from -proposed to -updates and such, too. [06:16] Rather than downloading it from Debian and falsifying a changes file. [06:16] or from ppa directly to ubuntu, etc. [06:16] Right, pocket copies are part of it. [06:16] Hobbsee: I got that, I'm just having trouble with how it affects syncing. [06:16] can you copy from backports->updates? [06:16] NCommander: Yes. [06:17] oh good [06:17] ScottK: Since they now run gina over sid and lenny, they can use copy-package.py on it just like they can PPAs or other pockets. [06:17] That's been possible for some time. [06:17] That will make it easy to do an SRU of Xfce 4.4.3 [06:17] NCommander: Look at KDE 3.5.10 [06:17] That was released to SUR? [06:17] *SRU? [06:18] Yep. It's in -updates now. [06:29] I was trying to build gnome-games from source.. I have built most of the dependencies.. but still i get this error.. http://paste.ubuntu.com/67751/ can someone have a look at it? [06:31] krishna, Are you working from upstream sources or Ubuntu sources? [06:33] persia: upstrean [06:33] *upstream [06:34] persia: but how does it really matter? [06:34] OK. Take a look at what gets done before running ./configure in the gnome-games debian/rules from the Ubuntu sources. It looks to me like you're missing some preparation steps. [07:45]