[00:29] <lfaraone> nhandler: yes, that's correct, that should be reflected in that I merged in the changes from Debian, commited, and then made the changes for Ubuntu in http://bazaar.launchpad.net/~lfaraone/ubuntu/lucid/autokey/merge0.61.5-1ubuntu1/revision/10
[00:29] <lfaraone> nhandler: rev 10 is the only ubuntu-specific change in the package.
[00:34] <lfaraone> nhandler: yes, that is the upstream changelog. Upstream keeps their changelog in debian/changelog in their svn tree. The real debian changelog is at http://packages.debian.org/changelogs/pool/main/a/autokey/autokey_0.61.5-1/changelog , the upstream changelog I attached (from SVN trunk) is at http://code.google.com/p/autokey/source/browse/branches/autokey-combined/debian/changelog
[02:38] <psusi> holy moly... lp says it's goign to take 2 days to build my patched parted in my ppa
[02:39] <micahg> psusi: some PPA builders have probably been temporarily reappropriated
[05:31] <fabrice_sp> Hi. Could someone try building scala (http://ftp.debian.org/debian/pool/main/s/scala/scala_2.7.7.dfsg-4.dsc) for bug 545975: it FTBFS here, but with a strange error
[05:33] <AnAnt> Hello, could someone sponsor this patch LP 544296
[05:42] <fabrice_sp> AnAnt, let me check
[05:44] <fabrice_sp> it seems you forget to run update-maintaner
[05:44] <AnAnt> oh yes
[05:45] <AnAnt> fabrice_sp: ok, can you also check LP 543679
[05:45] <AnAnt>  ?
[05:46] <fabrice_sp> I can check, but not upload right now: my build desktop is quite broken
[05:47] <fabrice_sp> (caused by a self destruction of my motherboard)
[05:48] <AnAnt> ok
[05:49] <fabrice_sp> it's a new package: you should get an ack from the Release team, no? Or explain why you don't need it
[05:50] <AnAnt> fabrice_sp: I didn't know wether I should subsribe -sponsors or -release
[05:52] <fabrice_sp> I would say first -release, because of Feature Freeze, and document the FFe
[05:52] <fabrice_sp> and as soon as you get the ack from  -release, subscribe -sponsors
[05:54] <AnAnt> ok
[05:55] <AnAnt> I updated the patch for zekr
[05:56] <fabrice_sp> ok. Sponsors are subscribed, so it should be ok. As soon as I xcan build and upload a package, I'll upload it (if nobody did it before)
[05:57] <fabrice_sp> I'll also unsubscribe -sponsors from 543679
[06:02] <AnAnt> ok
[07:18] <dholbach> good morning
[08:32] <AnAnt> dholbach: hello
[08:32] <dholbach> hey AnAnt
[08:32] <AnAnt> how are you ?
[08:33] <dholbach> good good - how are you?
[08:33] <AnAnt> fine
[08:33] <AnAnt> not sure wether to close that long time bug or what
[08:34] <dholbach> do it if you think it's been fixed. you can still ask people to test it and reopen the bug if necessary
[08:34] <AnAnt> ok
[08:34] <AnAnt> dholbach: can you sponsor this patch: LP 544296
[08:36] <dholbach> having a look
[08:36] <IntuitiveNipple> Could someone sponsor bug #546108 debdiff please?
[08:36] <ara> is wiki.ubuntu down?
[08:37] <dholbach> ara: it works for me
[08:39] <ara> dholbach, weird, it times out for me
[08:40] <dholbach> ara: does the traceroute look funny for you?
[08:41] <ara> dholbach, it just times out... it might be my internet connection
[08:41] <dholbach> ara: maybe if you run    mtr wiki.ubuntu.com    it shows you a where it's broken
[08:42] <ara> dholbach, it is indeed my internet connection
[08:42] <dholbach> ok
[08:42] <ara> *sigh*
[08:42] <dholbach> AnAnt: uploaded, I ran 'update-maintainer' for you
[08:43] <AnAnt> dholbach: I ran it already in the 2nd patch
[08:43] <AnAnt> thanks anyways
[08:43] <dholbach> not in http://launchpadlibrarian.net/41931707/zekr_0.7.5~beta3%2Brepack-1ubuntu1.debdiff :)
[08:43] <dholbach> but anyway :)
[08:43] <dholbach> it's all good
[08:45] <johe|work> hi there, is there any way coova-chilli (coova.org) could be part of the ubuntu repository, maybe someone could add it, or maybe somone could teach me how to add it :-)
[08:45] <AnAnt> slangasek: thanks !
[08:45] <dholbach> AnAnt: شكرا
[08:46] <AnAnt> dholbach: ah ! you still remember
[08:46] <dholbach> AnAnt: one of the very few I didn't forget :)
[08:47] <AnAnt> AnAnt: erm, it was probably the only one
[08:48] <dholbach> might be ;)
[09:31] <joaopinto> good morning
[10:04] <suji11> hi
[10:07] <suji11> how to write rules file?
[10:22] <brijith> Hi all , how can I change the permission of a folder in side rules file while packaging?
[10:26] <suji11> how to write rules file?
[10:39] <brijith> suji11:http://videos1.showmedo.com/ShowMeDos/extras/linuxJensMakingDeb/from_py_to_deb.pdf
[12:21] <ejat> can someone help me with this : http://paste.ubuntu.com/401749/
[13:06] <bobbo> zul, ping
[13:06] <zul> bobbo: pong
[13:06] <bobbo> zul, I noticed you've filed an MIR for python-formencode but it currently FTBFS
[13:07] <zul> bobbo: yeah im working on it
[13:07] <AnAnt> Hello, I'm not sure wether to ask this question here or in #ubuntu+1, I have a closed-source software here that crashes when I use lucid (yet it works funny with debian unstable), yet when I strace that software, it doesn't crash, what would be the possible reason for this ?
[13:07] <AnAnt> s/funny/fine
[13:07] <bobbo> zul, okay, I have a patch for it but I'll hold off on uploading it if you're working on it :)
[13:07] <zul> bobbo: thanks
[13:17]  * POX doesn't understand most of Ubuntu changes in python-formencode
[13:32] <ScottK> POX: Since the last two revisions didn't build, I suspect they can be ignored.
[13:33] <POX> ScottK: not really: http://packages.ubuntu.com/lucid/all/python-formencode/filelist (WTF?)
[13:34] <ScottK> POX: rmadison says ubuntu1 is the last one that built.
[13:36] <POX> ScottK: well, right now I'm not really motivated to contribute in Ubuntu, so I'll just say that formencode and gaupol should be checked
[13:37] <ScottK> POX: Are you  satisfied with python-formencode with Python 2.6 in Debian as it is?
[13:38] <POX> yes
[13:38] <ScottK> Good enough for me.
[13:38] <ttx> There is a MIR in progress for python-formencode, FWIW
[13:39] <POX> someone enabled tests in ubuntu and they probably failed as locales are not installed at build time so they installed .po files for... every single Python version
[13:39] <ttx> zul ^
[13:39] <ScottK> ttx: It ought to at least build and dropping python-dns from depends with no rationale is just wrong.
[13:40] <ScottK> POX: Thanks.
[13:40] <POX> python-dns is probably removed as it's not in main
[13:40] <zul> i just uploaded the FTBFS fix
[13:40] <ttx> I'm trying to avoid duplicating work :)
[13:40] <zul> and removed python-dns as well
[13:40] <ScottK> POX: Yes, but we aren't supposed to just drop depends willy nilly.
[13:40] <ScottK> zul: Why?
[13:41] <zul> because its not in main
[13:41] <ScottK> zul: That's not a proper rationale.
[13:41] <zul> and the testsuite ran fine without it
[13:41] <ScottK> And so that means there's no impact?
[13:41] <zul> didnt appear to any to me
[13:43]  * POX will move python-dns to Recommends
[13:43] <POX> zul: see validators.py
[13:44] <ttx> POX: the question is more how useful python-dns is to python-formencode
[13:44] <POX> see validators.py
[13:44] <ttx> if its optional, should be a suggests, if its required for 90% of the cases, then recommends (anbd pushing it to main) is the way to go
[13:45] <ttx> (mind you, I've no clue what python-formencode does)
[13:45] <ScottK> I just left a comment in the MIR bug that I don't think "the test suite works" is sufficient investiation before dropping a depends.
[13:45] <POX> ttx: take a look at line 1362
[13:46] <POX> asserts are disabled only with -O (and python packages do not use that)
[13:46] <POX> so if self.resolve_domain is set to true, it will fail
[13:48] <ttx> but it's only set if you explicitely set resolve_domain=True
[13:48] <ttx> as explained on line 1257
[13:48] <ttx> it's clearly optional
[13:49] <ttx> If you pass ``resolve_domain=True``, then it will try to resolve the domain name to make sure it's valid.  This takes longer, of course. You must have the `pyDNS <http://pydns.sf.net>`__ modules installed to look up DNS (MX and A) records.
[13:49] <ttx> default is False
[13:49] <ScottK> So the question would  be do the redepends set it to True?
[13:49] <ttx> so I would downgrade it to Suggests
[13:50] <ttx> ScottK: yes
[13:50] <ttx> if they do, Recommend/MIR is in order :)
[13:51] <ttx> hm. do the buildds install recommends ?
[13:51]  * POX will not downgrade it to Suggests as all applications that use resolve_domain will fail without pydns
[13:51] <ttx> POX: well, they could depend on python-dns if they require it
[13:52] <ttx> it all depends on how prevalent usage of resolve_domain=True is
[13:52] <ttx> if every consumer of pyhton_formencode sets it, I tend to agree with you. But the default value seems to tell a different story.
[13:53] <ScottK> I think that Recommends is more appropriate, but we are in the realm where if the in archive rdepends doesn't set it True, downgrading to Suggests in Ubuntu to save disk space is not wildly inappropriate.
[13:53] <sistpoty|work> ttx: buildds don't install recommends
[13:54] <sebner> huhu sistpoty|work :)
[13:54] <sistpoty|work> hi sebner
[13:54] <ttx> sistpoty|work: Ii seemed to remeber that :)
[13:54] <ttx> ScottK: I agree with you, we need to have a look at those rdepends.
[14:01] <ttx> commented.
[14:39] <lfaraone|really> nhandler: I added a debdiff between the attached branch in bug 546139 and the current Debian revision.
[14:41] <nhandler> lfaraone|really: And what was the reason (with you being the DM) for not having the transitional package install the gtk version in debian?
[14:43] <lfaraone|really> nhandler: because in Debian we're transitioning from autokey to autokey-qt, since that's what we've been shipping in testing for a while now.
[14:44] <lfaraone|really> nhandler: it's been in section: KDE since Aug 2009, but we shipped it in section GTK in karmic.
[14:46] <lfaraone|really> lfaraone|really: I discussed this with my sponsor as well as upstream, and we all agreed this would be the best plan.
[14:47] <lfaraone|really> nhandler: I discussed this with my sponsor as well as upstream, and we all agreed this would be the best plan. *
[14:47] <nhandler> lfaraone|really: I ACKed the FFe ;)
[14:48] <lfaraone|really> nhandler: thanks :)
[14:53] <jcfp> nhandler: could you unsubscribe ubuntu-release from #545610 for now?
[14:53] <nhandler> Bug 545610
[14:54] <nhandler> jcfp: Done
[14:54] <jcfp> thanks :)
[15:00] <lfaraone|really> nhandler: okay, I subscribed ~ubuntu-sponsors
[15:36] <duanedesign> working on a FFe, building the new upstream source I am getting two(2) warnings.  http://paste.ubuntu.com/401850/
[15:43] <jcastro> directhex: he what tasque is in debian?
[15:43] <jcastro> .8 or .9?
[15:44] <ScottK> jcastro: rmadison -u debian tasque
[15:44] <jcastro> ScottK: omg. I could have used that trick like 5 years ago
[15:44] <jcastro> thanks for that
[15:44] <ScottK> You're welcome.
[15:46] <directhex> "-u qa" is quicker to type
[16:26] <nigelb> trying to build the cheese package, and I get this error "make: *** No rule to make target `/usr/share/gnome-pkg-tools/1/rules/gnome-get-source.mk'.  Stop."
[16:26] <nigelb> all I did was add an apport hook
[16:27] <ScottK> Is gnome-pkg-tools a build-dep?
[16:28] <nigelb> yes
[16:29] <ScottK> Does it still provide that file?
[16:30] <nigelb> oh, if I install that package, this might work?
[16:32] <ScottK> Yep
[16:33] <ScottK> You need to install all the build-depends.
[17:33] <mpt> Ubuntu Software Center v2 has a "Developer Tools" > "Mono" section, but Monodevelop isn't in it. The fix is a really simple packaging change: http://launchpad.net/bugs/546936
[17:36] <mpt> There are similar one-line-fix bugs that would be ideal for someone getting started in packaging: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=metadata
[17:39] <micahg> I just saw bug 545563 was fixed
[17:40] <micahg> but it pulls in 268MB of docs as a depends?  should it be doing this?
[17:43] <micahg> mpt: I see you're famiiliar with the categories for the software center, can I ask you a qeustion?
[18:11] <ari-tczew> how can I build package by pbuilder when I have lucid and I want to build on intrepid?
[18:14] <prefrontal_> pbuilder-satisfydepends-dummy depends on * ; however: package * is not installed
[18:14] <prefrontal_> isn't the point of pbuilder to simulate building my package on a system that doesn't even have the right dependencies yet?
[18:15] <ari-tczew> prefrontal_ did you update pbuilder?
[18:15] <sistpoty|work> ari-tczew: pbuilder --create --distribution=intrepid [--basetgz /var/cache/pbuilder/intrepid.tar.gz]
[18:15] <sistpoty|work> maybe --distribution intrepid one of the two should work
[18:16] <prefrontal_> ari-tczew, i just created a new pbuilder env
[18:16] <ari-tczew> sistpoty|work: Unknown option [--distribution=intrepid] was specified
[18:16] <sistpoty|work> ari-tczew: then try without =
[18:17] <sistpoty|work> prefrontal_: if you put "foobar" in build-depends, and there is no package foobar, pbuilder cannot install it
[18:18] <sistpoty|work> prefrontal_: or if you build-depend on a package in universe but have only a line for main in the pbuilder's sources.list
[18:18] <prefrontal_> really? it can't find the debhelper package then
[18:18] <ari-tczew> sistpoty|work: okay, your command succeful, so then what;s the command I need to build package on intrepid?
[18:18] <sistpoty|work> ari-tczew: simply tell pbuilder to use that tar.gz with --basetgz <locationoftargz>
[18:19] <sistpoty|work> pbuilder --build --basetgz some.tar.gz foobar.dsc
[18:19] <ari-tczew> thanks!
[18:19] <ripps> I prefert to use the cowbuilder mod of pbuilder, seems alot faster.
[18:20] <sistpoty|work> oh, I've been told that there is better magic called pbuilder-dist or so, not too sure where that lives (maybe in ubuntu-dev-tools)
[18:26] <ari-tczew> sistpoty|work: E: File intrepid.tar.gz does not exist
[18:28] <ScottK> You need to create the new pbuilder chroot first
[18:29] <ari-tczew> ...
[18:29] <ari-tczew> does someone can expand pbuilder to easy build on other releases?
[18:30] <ari-tczew> to use pbuilder by using command-option like --dist=jaunty
[18:30] <sistpoty|work> ari-tczew: you'll need to specify exactly the base tarball that you created with --create
[18:30] <sistpoty|work> ari-tczew: if you omited --basetgz at --create, then it should be in /var/cache/pbuilder/base.tar.gz
[18:30] <sistpoty|work> (or base.tgz, don't recall that atm)
[18:31] <ScottK> ari-tczew: pbuilder-dist intrepid create
[18:31] <ScottK> Then pbuild-dist intrepid build ....
[18:32] <ari-tczew> sistpoty|work: so actually 'pbuilder build *.dsc' will build on intrepid instead jaunty? :-/
[18:32] <sistpoty|work> ari-tczew: pbuilder build will use the standard tarball. It will build with whatever is inside that tarball
[18:33] <sistpoty|work> ari-tczew: the distribution is only specified by what packages are in the tarball and what apt sources line is in the tarball. pbuilder --build knows nothing about the distribution
[18:33] <MTecknology> How can I see packages that are waiting to be uploaded into lucid?
[18:35] <ari-tczew> sistpoty|work: do you mean tarball as .diff.gz ?
[18:35] <sistpoty|work> MTecknology: define "waiting to be uploaded" (as in stuck in binary/source new, or waiting to get sponsored, or anything else?)
[18:35] <MTecknology> sistpoty|work: stuck in binary/source new
[18:35] <sistpoty|work> ari-tczew: no the base tarball from pbuilder (which is actually just a tarball of a chroot)
[18:36] <ari-tczew> ehh, I'll use ScottK propose, because I think that this is it, what I'm looking for
[18:36] <sistpoty|work> MTecknology: https://launchpad.net/ubuntu/lucid/+queue
[18:36] <ScottK> There are other ways to do it, but that works.
[18:36] <MTecknology> sistpoty|work: thanks :)
[18:36] <sistpoty|work> yw
[18:38] <prefrontal_> how do I handle using pbuilder to build a package that depends on another package that i created and isn't in the repos
[18:43] <sistpoty|work> prefrontal_: quick and dirty: pbuilder --login --safe-after-login
[18:43] <sistpoty|work> prefrontal_: that should print you a path were the chroot is extracted
[18:44] <sistpoty|work> prefrontal_: copy the deb over there
[18:44] <sistpoty|work> prefrontal_: and install it inside pbuilder
[18:44] <prefrontal_> then what?
[18:44] <sistpoty|work> prefrontal_: that's it. package is then installed in the chroot and hence available once you unpack it again
[18:45] <sistpoty|work> prefrontal_: however that also means that it's there when you don't expect it and want a clean env
[18:45] <prefrontal_> oh, i thought that the chroot was inside the base.tar.gz which is decompressed and then recompressed every time i run pbuilder
[18:46] <sistpoty|work> prefrontal_: yes, but with pbuilder --login --safe-after-login you can decompress it and do things inside it
[18:46] <prefrontal_> ok, then how do i recompress it afterwards
[18:46] <sistpoty|work> prefrontal_: --safe-after-login takes care of it
[18:46] <prefrontal_> ok, thanks
[18:47] <sistpoty|work> prefrontal_: cleaner approach would be to use a local repository and add that to the apt-sources line inide the chroot (but I can't provide details for that)
[18:56] <MTecknology> So, when something should be uploaded into ludid, it winds up at launchpad.net/ubuntu/lucid. How does it get there and what happens from there?
[18:56] <MTecknology> I'm guessing only motu can upload there, so is revu where a motu can accept a users package and push it into lp.net/ubuntu/lucid ?
[18:58] <sistpoty|work> MTecknology: it gets there only if in freeze, or if the source package is new (source new) or if the source package produces a new binary package
[18:58] <MTecknology> sistpoty|work: so that's a queue for exceptions?
[18:59] <sistpoty|work> MTecknology: in regards to freeze? no, we just turn the archive down to manual when in freezes (e.g. betafreeze) since an uncoordinated upload could mean that iso have to be rebuilt (and hence mean lots of lost time)
[19:00]  * sistpoty|work heads home now... cya
[19:00] <MTecknology> ttyl
[19:02] <MTecknology> I'm just trying to understand the process packages take to get into ubuntu; so far I understand how a package gets into debian and then from there's it's just a sync into ubuntu; i get how the version numbers work to keep syncs in line. It's the others paths that confuse me. Not from my side but rather yours
[19:04] <geser> what confuses you?
[19:05] <MTecknology> geser: if I upload someting to motu and motu decide it's a good package, what happens to it?
[19:05] <geser> what you mean with "upload to motu"?
[19:06] <MTecknology> upload to revu*
[19:06] <ari-tczew> upload to universe?
[19:06] <MTecknology> revu.ubuntuwire.com
[19:08] <geser> MTecknology: when you upload your package to revu, it gets reviewed -> comments with mistakes -> fix & reupload -> review -> ... -> it the package is good, it gets advocated (by a developer) -> when it has two advocates, it gets uploaded to the archive (usually done by the developer who did the 2nd advocate)
[19:08] <geser> that's the workflow in theory
[19:09] <MTecknology> geser: and that upload goes to launchpad.net/ubuntu/version_name ?
[19:10] <geser> yes, LP doesn't distinguish syncs (from Debian) and uploads (merges, bug fixes, new packages)
[19:11] <MTecknology> how does the sync happen?
[19:11] <MTecknology> a script runs, checkes versions, if debian_ver > ubuntu_ver :then upload to lp?
[19:12] <geser> yes
[19:12] <MTecknology> is that script built into launchpad or something somebody has running on a server?
[19:14] <MTecknology> I suppose that part doesn't matter so much
[19:14] <geser> both, some part is done by scripts run by an archive admin (see lp:ubuntu-archive bzr branch) and some parts build into LP
[19:14] <MTecknology> oh
[19:15] <MTecknology> so.. what does dput look like for the upload queue?
[19:17] <geser> dput only uploads some files (.changes, .dsc, .diff.gz, ...) to an ftp-server and a part of LP scans this directory periodically and processes the files/uploads it finds there
[19:17] <MTecknology> oh
[19:18] <geser> nothing magic :)
[19:18] <MTecknology> so almost just like launchpad or revu, just different server?
[19:19] <geser> both have an FTP server for the uploads
[19:19]  * geser is losing context. what "different server"?
[19:19] <MTecknology> So, there's a status of New,Accepted,Rejected,Done,Unapproved - the names are pretty self explanatory, but how are those handled?
[19:20] <MTecknology> geser: I meant other than launchpad for upload - your answer answered it
[19:21] <MTecknology> and is a sync'ed package from debian ever rejected? - and how would that be handled
[19:23] <geser> for uploads: the upload processor checks the signature if the person can upload or not (Accepted or Rejected email), then it gets into the queue (https://edge.launchpad.net/ubuntu/lucid/+queue) where I've to pass as I don't know the details how those different status get assigned and work
[19:24] <MTecknology> If I'm asking too many questions feel free to slap me, I'm waiting for an upload marked "Done" to get into the archives and sync so I can install it. It may have the patch to an irritating bug
[19:25] <geser> for syncs: as they are done on the canonical servers, I'm not sure how exactly it gets done (but you can dig through the LP code if you are interested)
[19:26] <MTecknology> I was just about to peak
[19:26] <geser> I know only of rejects for syncs which has to pass through the (source) NEW queue (i.e. the first sync of the package into Ubuntu when it gets reviewed by the archive admins)
[19:27] <MTecknology> New is for new packages, not updates?
[19:27] <geser> yes
[19:28] <prefrontal_> pbuilder is too slow. it keeps downloading all the same packages from scratch every time
[19:28] <prefrontal_> takes me like 20 minutes to make a minor change and find out if it works
[19:28] <geser> packages that got accepted once get auto-accepted on the following uploads/syncs (modulo freezes when the archive is on manual)
[19:28] <ScottK> Which can include new binary packages in existing source packages
[19:28] <MTecknology> then when uploaded it winds up in either accepted or rejected and if accepted it waits until uploaded and then it windws up in done?
[19:29] <ScottK> It moves from accepted to done when it's published.
[19:29] <james_w> prefrontal_: you can set and apt cache dir to prevent that. I thought it was set by default.
[19:29] <ScottK> The publisher runs once an hour at :03 after.
[19:29] <MTecknology> and when it's in done that means it's in the archives and just needs to sync?
[19:30] <ScottK> It generally takes about 40 minutes to finish, so at :45 after the results are on archive.ubuntu.com and then can be mirrored
[19:30] <ScottK> Yes.
[19:30] <geser> after a (successful) upload the source gets published (once an hour), then the source package gets distrbuted to the buildds, the build debs gets put into the queue (same procedure as for sources), and published on the next publisher run
[19:30] <prefrontal_> james_w its the whole download + install process that is redundant..
[19:31] <geser> prefrontal_: usually pbuilder caches the .debs it downloads for re-use
[19:31] <prefrontal_> ok but how can i get it to stop starting over from scratch every time
[19:31] <james_w> don't use pbuilder then!
[19:31] <ScottK> prefrontal_: The install process is to make sure you start with a clean chroot.
[19:31] <prefrontal_> ok but that is making it very difficult to debug..
[19:31] <james_w> it's designed to ensure a clean environment
[19:31] <prefrontal_> a clean chroot is not essential.
[19:31] <ScottK> prefrontal_: temporarily you can use pbuilder login and work within the chroot.
[19:32] <prefrontal_> that's a particular debugging technique that i dont need right now..
[19:32] <ScottK> Then exit when you're done.
[19:32] <MTecknology> and when it's rejected because it's new, somebody needs to upload the source somewhere, then the rest can be uploaded?
[19:32] <prefrontal_> ok but i don't know what pbuilder build *dsc does..
[19:33] <prefrontal_> do you see what i mean? i would like for pbuilder build to try and build my package, but i don't need it to start from the beginning every time
[19:34] <ScottK> pbbuilder login
[19:34] <ScottK> apt-get build-dep packagename
[19:34] <ScottK> apt-get install fakeroot devscripts
[19:34] <ScottK> apt-get source packagename
[19:34] <ScottK> cd into the package dir
[19:34] <ScottK> debuild -us -uc
[19:34] <ScottK> It'll build
[19:35] <ScottK> prefrontal_: ^^
[19:35] <prefrontal_> thank you ScottK
[19:36] <geser> MTecknology: new (source or binary) packages get put on hold (in the NEW queue) until an archive admin looks at them and give a go (accepted) or a no-go (rejected)
[19:36] <MTecknology> oh
[19:36] <prefrontal_> ScottK, how will apt know where my package is? i usually pass pbuilder a .dsc file
[19:37] <geser> pbuilder has some scripts which look at the .dsc file and extract from there the build-dependencies to install and only tell apt (inside the pbuilder) to install them
[19:38] <MTecknology> geser: so what's the actual purpose of a motu? just making sure syncs happen correctly, watching the quality of debian/, dealing with new/updated packages, and helpin anyone that wants to contribute to ubuntu?
[19:38] <prefrontal_> ok but how can a command like 'apt-get build-dep packagename' work when packagename is not in a repository.
[19:39] <prefrontal_> its in /tmp of my workstation
[19:39] <prefrontal_> my package doesn't build in pbuilder yet..i'm trying to debug that
[19:41] <geser> MTecknology: almost, merge/syncing packages from Debian, fixing bugs (e.g. by applying patches from LP), fixing FTBFS, keeping the packages installable (unmet dependencies, caused e.g. by transitions), helping here, sponsoring, and probably some more tasks
[19:42] <MTecknology> !ftbfs
[19:42] <MTecknology> geser: what is ftbfs?
[19:43] <geser> Failed To Build From Source
[19:44] <MTecknology> oh
[19:45] <MTecknology> so if a person creates 500 high quality packages for ubuntu and developed half of them, they're still not a candidate for being motu but they'll now have a whole lot of experience to get themselves there?
[19:48] <geser> yes, a MOTU has to "show" packaging skills, knowledge of the Ubuntu processes (merges, syncs, freezes) and to be able to work in a team (with the other MOTUs)
[19:54] <MTecknology> geser: so assuming I completely understood everything you told me (i think i do), how much of the process would I now understand?
[19:57] <ScottK> prefrontal_: In that case you need to manually copy the package into the chroot (it lives in /var/cache/pbuilder/build) and apt-get install the list of build-deps by hand
[19:58] <geser> the detail knowledge of the working of the archive is not something which is expected to be known from a MOTU, more how (and when) syncs should be done, how a merge is done, when and how a freeze exception should be requested
[19:59] <prefrontal_> ScottK, i got this now, thanks.
[19:59] <prefrontal_> much easier doing all this by hand
[20:00] <MTecknology> geser: so when I think I'm far enough along I should ask for a mentor.. I'm not sure when I'll consider myself far enoguh along
[20:04] <lfaraone|really> Four of my uploads recently ( https://launchpad.net/ubuntu/+source/dvi2ps/4.1j-3 , https://launchpad.net/ubuntu/+source/choosewm/0.1.6-1 , https://launchpad.net/ubuntu/+source/debian-edu-artwork/0.0.30-4 , and https://launchpad.net/ubuntu/+source/mgp/1.13a+upstream20090219-2) have FTBFS on armel, but build fine elsewhere. Is something up with the buildslaves?
[20:04] <lfaraone|really> (build fine on other archs)
[20:05] <MTecknology> geser: thanks for all the info :)
[20:05] <ScottK> lfaraone|really: You'd have to look at the build logs and see why they failed.  I'm not aware of anything.
[20:06] <geser> MTecknology: just start working (e.g. with bug fixes) and when stuck ask here, at some point in the future you will have enough knowledge to become a MOTU
[20:08] <arand> debfx: Assuming you're the one to turn to for vbox in ubuntu... would you mind/have time to look at patches in Bug #510571 for a possible SRU?
[20:08] <MTecknology> geser: I made one bug fix that's in ubuntu now and i've been trying to make the perfect debian/ dir for a package i want to get into debian. I've been learning a lot
[20:10] <prefrontal_> can someone clarify for me - every time i do pbuilder create ... it deletes my current default pbuilder env and starts from scratch?
[20:11] <geser> pbuilder create is only to setup a pbuilder from fresh
[20:11] <prefrontal_> ok but what i'm not clear on is whether it makes an additional pbuilder or nukes my old one first
[20:12] <geser> you do "pbuilder create" only once, and later only "pbuilder update" (to update it), "pbuilder build" to build a package, etc.
[20:12] <prefrontal_> but what if i login and then install a bunch of packages and then exit?
[20:12] <prefrontal_> then i have tainted it right
[20:12] <geser> no
[20:12] <prefrontal_> oh
[20:13] <prefrontal_> all clear, thanks
[20:14] <geser> pbuilder creates a "base.tgz" (in /var/cache/pbuilder), "pbuilder login" unpacks this base.tgz below /var/cache/pbuilder/build and removes this "copy" when you're done (log out from pbuilder)
[20:14] <ScottK> prefrontal_: If you want a persistent change in the pbuilder chroot you do login --saver-after-login.  It's hard to do by accident.
[20:22] <debfx> arand: you need to target DIST-proposed (e.g. karmic-proposed) for SRUs
[20:23] <arand> debfx: Ah for the debdiffs? More things I should look over?
[20:25] <MTecknology> so a new version of a package was uploaded and is marked as Done; how long does it usually take before that's reflected in packages.ubuntu.com?
[20:26] <debfx> arand: yes, looks fine otherwise
[20:27] <MTecknology> oh.. on http://archive.ubuntu.com/ubuntu/ - what are the different directories for?
[20:27] <MTecknology> jackass.canonical.com ??
[20:28] <debfx> arand: then you need to subscribe ubuntu-sru
[20:29] <arand> debfx: Oops, facepalm, though I'd already done that...
[20:29] <sistpoty> MTecknology: dists contains package files for each distribution. pool is the package pool (there's only one for all distributions, meaning that there can be only one package with the same version per distribution)
[20:30] <sistpoty> s/per distribution/for all distributions/
[20:30] <MTecknology> so pool/ is the latest and greatest of all?
[20:30] <sistpoty> MTecknology: every binary and source package is in there, yes :)
[20:31] <prefrontal_> what happens to my .deb after pbuilder build makes it?
[20:31] <prefrontal_> it seems to not have copied it to the directory i started pbuilder in
[20:31] <geser> prefrontal_: look in /var/cache/pbuilder/results
[20:32] <sistpoty> prefrontal_: default is /var/cache/pbuilder/result (overridable with --buildresult)
[20:32] <sistpoty> hi geser
[20:32] <geser> Hi sistpoty
[20:33] <prefrontal_> thanks.
[20:34] <MTecknology> sistpoty: oh... so everything just exists in pool/ and Packages.bz2 is the list of what you can install from that repository?
[20:34] <geser> yes
[20:35] <sistpoty> prefrontal_: btw.: took me some time to find out I could put this in ~/.pbuilderrc: BUILDRESULT=$(pwd)/result/
[20:35] <MTecknology> so is debian run about the same way, just that ubuntu tries to make things much easier for others to contribute and find their place to contribute?
[20:36] <sistpoty> MTecknology: I wouldn't exactly state that it's that much easier to contribute in Ubuntu
[20:37] <sistpoty> MTecknology: what's different is that debian is organized democratically (at least formally), while ubuntu is based on a dictatorship (officially referred to as meritocracy)
[20:38] <MTecknology> sistpoty: I'm not much of a politicts person so that just went over my head :P
[20:38] <sistpoty> heh
[20:39] <MTecknology> I know who my president is for once, that's about the extent of it
[20:40] <xhaker_> hi sistpoty. can you please sync postgis 1.5.1-1 from unstable?
[20:40] <sistpoty> xhaker_: sorry, not an archive admin, so I can't sync. Does it need an FFe? If so, bug number?
[20:41] <MTecknology> sistpoty: btw - i didn't mean anything bad about debian, just seems like ubuntu focuses on making things pretty and easy
[20:42] <sistpoty> MTecknology: didn't understand it in a way that is bad in regards to Debian ;)
[20:42] <MTecknology> ok :)
[20:43] <xhaker_> sistpoty: it's in universe. though motu-release members could sync
[20:43] <xhaker_> s/though/thought/
[20:44] <sistpoty> xhaker_: there's no motu-release any longer, only ubuntu-release (teams have joined). However being a member of -release doesn't mean that I can do a sync, only ack a FFe requesting a sync ;)
[20:44] <MTecknology> how long does it normally take archive.ubuntu.com to sync to us.archive.ubuntu.com ?
[20:45] <sistpoty> MTecknology: no idea, you could eventually ask elmo on -devel, he'd certainly know. My personal experience between a.u.c and de.a.u.c is between 8 hours and one day backlog
[20:46] <MTecknology> sistpoty: oh- thanks
[20:48] <MTecknology> hrm....
[20:49] <MTecknology> I just switched my mirror to archive.ubuntu.com and I still can't get the new package
[20:50] <mpt> micahg, you had a question?
[20:51] <mpt> (Sorry, Lucid crashed for me, didn't see it until just now when I checked irclogs.ubuntu.com:-)
[21:19] <prefrontal_> when I sign my package using debuild -S it asks me for my gpg password twice and then says success. but when i use pbuilder build on that it says it fails to verify my signature
[21:22] <sistpoty> prefrontal_: can you pastebin the message from pbuilder?
[21:23] <geser> I assume it's because gpg inside the pbuilder doesn't know the key
[21:27] <micahg> mpt: yeah, I wanted to make sure I did the right thing to get Thunderbird to shwo up in the software center
[21:28] <mpt> micahg, USC (almost exactly) follows the table and algorithm given here: https://wiki.ubuntu.com/SoftwareCenter#Genre
[21:28] <mpt> micahg, so the way to get Thunderbird into "Mail" is to set the .desktop category to "Email"
[21:29] <micahg> mpt: k, that's what I did, so when does that refresh
[21:30] <mpt> micahg, I *think* USC updates its catalogue whenever you do apt-get update or equivalent
[21:30] <mpt> But I'm not an expert on that, mvo would know more.
[21:30] <mpt> oh, wait
[21:30] <mpt> change to .desktop file
[21:30] <mpt> That requires a change in app-install-data
[21:30] <mpt> -ubuntu
[21:31] <micahg> mpt: k, so I just wait for the update after I push the .desktop change
[21:32] <mpt> micahg, once you've uploaded a fixed version, I think someone needs to set off a process that updates app-install-data-ubuntu. But again, that's is a bit outside my area of expertise. :-)
[21:33] <mpt> mvo or, probably, anyone on the Desktop team would know.
[21:33] <micahg> mpt: k, thanks
[21:33] <mpt> thanks for fixing it
[21:33] <micahg> mpt: I'll bug chris coulson about it
[21:33] <mpt> k
[21:34] <prefrontal_> my workstation is running karmic, but my pbuilder is lucid. when i run debuild -S to create my source package i get an E (error) from lintian that says bad-distribution-in-changes-file lucid
[21:34] <prefrontal_> i have to be on lucid to make a source package for lucid?
[21:35] <geser> ignore that (lintian from karmic doesn't know of lucid)
[21:35] <sistpoty> prefrontal_: you can ignore that error, lintian on karmic just won't know about lucid. Nonetheless at this point for the release, I'd highly recommend to test the package on a real lucid system
[22:08] <nixternal> hrmm, custom package here, kubuntu-docs, and I have desktop files that need translating, so I am using the .desktop.in stuff....if I add the langpack.mk to the rules and do a dh_install, will it understand what to do?
[22:08] <nixternal> I am a bit confused with the translation stuff, running in circles looking at different packages for ideas
[22:35] <RainCT> nixternal: Hey
[22:35] <nixternal> howdy
[22:36] <RainCT> nixternal: About the mail you've just send to ubuntu-devel@ about the .desktop files, what build system are you using there?
[22:36] <nixternal> cdbs
[22:36] <nixternal> but I could always change that if debhelper is easier
[22:36] <RainCT> nixternal: I mean upstream (or are those .desktop files in debian/)?
[22:36] <nixternal> we use cdbs for all kubuntu packages, so that is why it is being used
[22:37] <nixternal> oh, building with a custom makefile
[22:37] <nixternal> so the makefile builds the docs to kubuntu-docs/build/kubuntu and the rules file installs from tehre
[22:39] <RainCT> nixternal: OK. You can use "intltool-merge -d po/ <name>.desktop.in <name>.desktop" to generate the .desktop file from the .desktop.in, incorporating any translations
[22:39] <nixternal> use that in my makefile?
[22:39] <nixternal> or use it in rules?
[22:40] <RainCT> nixternal: well you can use it in either of them, but I guess doing it in the Makefile would make the most sense
[22:41] <RainCT> brb
[22:41] <nixternal> right, ok...i will go with that then...thanks a ton
[22:42] <sebner> huhu RainCT :D
[23:13] <RainCT> nixternal: sure, no problem :)
[23:13] <RainCT> hi sebner
[23:13] <RainCT> well I'm off to bed, Ubuntu Global Jam tomorrow.. cya
[23:16] <arand> debfx: Are pulling the pathed packages into -proposed yours or the sru-teams area? (Bug #510571 again)
[23:16] <arand> s/pathed/patched/
[23:21] <debfx> arand: ubuntu-sru needs to ACK the SRU request and then you need a sponsor who uploads the package
[23:22] <debfx> arand: I can't do any of that as I'm not a motu
[23:22] <arand> debfx: Right-o, waiting time then.
[23:38] <micahg> in a changelog, the entries go by release order or time order on a merge?
[23:38] <micahg> nm, I found my answer in the merge script :)
[23:44] <mr_pouit> micahg: if you have some time some day, could you give a look at gnome-chemistry-utils in lucid? It ftbfs (imo) because of xulrunner 1.9.2 (built fine a month ago with 1.9.1), and I can't finish a transition (goffice) because of that.
[23:44] <micahg> mr_pouit: yes, I'll try to get to it next week
[23:46] <mr_pouit> micahg: nice, thanks! Just ping me if you need more info at that time.
[23:47] <micahg> mr_pouit: ok