[00:34] <mac9416> Hello. When I open a deb in an archive manager, then data.tar.gz, I see that the top directory is called "." How is that directory created? I thought "." meant "current directory."
[00:40] <niall_> quit
[00:40] <imbrandon> it does, debs are created with dpkg-buildpackage
[00:42] <mac9416> imbrandon, what is dpkg-deb --build for?
[00:44] <imbrandon> mac9416: there are alot of diffrent alias for the same thing, the debian pacakge guide explains it
[00:44] <mac9416> k
[00:44] <mac9416> Will that guide explain the "." directories?
[00:44] <imbrandon> but building the archive directly isnt really feasable
[00:44] <mac9416> I see.
[00:44] <imbrandon> the . is the current directory
[00:45] <imbrandon> as you said
[00:45] <mac9416> But how does dpkg make such a directory?
[00:45] <mac9416> Rather, why is it visible in an archive manager?
[00:45] <imbrandon> it dosent make it, thats how archive manager is representing it
[00:45] <mac9416> OK
[00:55] <mac9416> imbrandon, u say it wouldn't be feasiable to make a deb by hand. What if it was only a metapackage? No data, only a control file.
[00:56] <mac9416> imbrandon, I'm looking at making a cross-platform metapackage creator, so I kinda want to make a simple deb with Python.
[00:56] <mac9416> I doubt dpkg-buildpackage is cross-platform.
[01:17] <lfaraone> mac9416: it will probably run in any unix enviornment.
[01:24] <mac9416> lfaraone, what about Windows?
[02:16] <mac9416> Is the information here still accurate? http://madabar.com/techblog/2007/07/15/manually-creating-a-deb-package-for-maemo/
[02:17] <mac9416> Because I can read BASH. And if his methos still works, I can do it in Python.
[02:17] <mac9416> *method
[02:29] <imbrandon> mac9416: likely but you'll get a morer definitive response from the dpkg maintainers in debian ( on oftc )
[02:29] <imbrandon> and the dpkg documentation
[02:29] <imbrandon> as that is what you are re-implmenting
[03:17] <imbrandon> dear lazyweb: i'm bored ... that is all.
[04:58] <mirsal> lfaraone, ping
[04:59] <mirsal> (Hello, there ^^)
[06:41] <kobrien> any tips on where to look for help with packaging a java app?
[06:41] <kobrien> docs seem scarce. My app uses ant as buildsystem...
[06:46] <imbrandon> kobrien: http://wiki.debian.org/JavaPackage
[06:47] <imbrandon> kobrien: sorry wrong link
[06:47] <kobrien> kk
[06:47] <imbrandon> kobrien: anyhow the ant build system should be supported just look at any of the programs that currently use it
[06:48] <kobrien> good thinking
[06:50] <kobrien> imbrandon: :) I have my answers. I downloaded a variant of lucene which uses ant to build. thanks
[06:51] <imbrandon> kobrien: :)
[10:37] <defcon> morning
[11:22] <ari-tczew> hello
[11:23] <pochu> quadrispro: hi, isn't simple-scan 2.31.x an unstable series?
[11:25] <ari-tczew> pochu: simple-scan (2.31.1-1) is in unstable
[11:28] <geser> ari-tczew: pochu asks about the upstream versioning. Some upstreams (e.g. Gnome) use even numbers (e.g. 2.30.x) for the stable releases and odd numbers (2.31.x) for development releases
[11:29] <ari-tczew> geser: I know about gnome's versioning
[11:30] <pochu> ari-tczew: I know it's in unstable, hence my question
[11:30] <pochu> if 2.31.1 is an unstable release, having it in unstable is bad (tm)
[11:30] <ari-tczew> yhy
[11:35] <quadrispro> pochu, maybe but it works fine, i didn't find any bug for now
[11:35]  * quadrispro on phone
[11:37] <pochu> quadrispro: well I don't think that's a good enough reason to ship unstable software in a stable release, but YMMV
[11:38] <pochu> but as long as you take care of bugs et al (and you do), I guess it's alright
[11:43] <ari-tczew> does apt-cache policy say true of packages
[11:44] <ari-tczew> component? main/universe etc
[11:45] <geser> yes, for packages from the main archive (PPAs have only a main component)
[11:47] <ari-tczew> geser: because I have a discrepancy. merge sites and apt-cache policy says that package is in universe, but LP show main component...
[11:47] <geser> which one?
[11:48] <ari-tczew> geser: https://launchpad.net/ubuntu/+source/trove
[11:49] <bdrung> ari-tczew: update to lucid!
[11:49] <bdrung> ari-tczew: https://launchpad.net/ubuntu/+source/trove/2.0.4-1ubuntu2 VS https://launchpad.net/ubuntu/+source/trove/2.1.0-1ubuntu1
[11:49] <geser> ari-tczew: ignore the "Component:*" field in the Package section but look instead at the second column in the table below it
[11:50] <ari-tczew> geser, bdrung: heh, some time ago someone told me that this is LP bug
[11:51] <bdrung> :) according to LP this package is moved to main in lucid
[11:52] <ari-tczew> bdrung: is your mailbox full of requests? :P
[11:53] <bdrung> 11 sync requests. you guys are mean to me ;)
[11:53] <geser> bdrung: 2.1.0-1ubuntu1 got demoted again to universe (see https://edge.launchpad.net/ubuntu/+source/trove/+publishinghistory)
[11:53] <bdrung> aha
[12:01] <bdrung> ari-tczew: you could be more verbose. state the changes that can be dropped instead of using "All changes have been incorporated in the Debian package."
[12:02] <ari-tczew> bdrung: I have this sentence saved in my statistic file. :P what could I write instead above^^?
[12:03] <c_korn> where can I find an address to inform google about the problem we (Debian and Ubuntu) have with their design change on code.google.com rendering existing debian/watch files useless and the fact that new watch files would be somehow ugly: http://svn.debian.org/viewsvn/python-apps/packages/sinntp/trunk/debian/watch?revision=5212
[12:03] <bdrung> for example: Debian has merged the Ubuntu changes (see second entry of changelog)
[12:04] <bdrung> c_korn: good questions. next question? ;)
[12:04] <kklimonda> c_korn: I don't think that it's something they would care about
[12:04] <bdrung> c_korn: this issue is currently discussed on the debian-devel mailing list.
[12:05] <c_korn> I know. http://groups.google.de/group/linux.debian.devel/browse_thread/thread/3f9bbca6687dcd27
[12:05] <kklimonda> I like the idea of extending uscan to deal with things like that in a nice and clean fashion
[12:07] <c_korn> yes, but these redirectors are only a workaround in my eyes. and in case of code.google.com the redirector would have to fetch a page. (according to this http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581622#15 )
[12:28] <bdrung> ari-tczew: bug #581228 what do you want to say with "In Ubuntu package is not interesting"?
[12:28] <bdrung> ari-tczew: what to do with debian/patches/0001-Revert-Fix-the-session-is-shutdown-when-the-agent-ex.patch ?
[12:30] <nigelb> bdrung: the fix for the pbuilder bug shuold be synced by now right?
[12:30] <nigelb> so its only a matter of getting the sru in I suppose
[12:30] <bdrung> nigelb: which bug?
[12:31] <nigelb> bdrung: you had commented on an sru bug dont remember the nuber right now
[12:31] <bdrung> nigelb: i comment on too many bugs
[12:31] <nigelb> bdrung: busy core-dev ;)
[12:32] <bdrung> nigelb: ari-tczew and Bhavani Shankar keep me busy.
[12:33] <nigelb> hehe
[12:33] <nigelb> patch review has reduced my motu work
[12:42] <bdrung> nigelb: can you dig out the bug number?
[12:43] <ari-tczew> bdrung: in obexd, the diff /debian/ between ubuntu and debian is changelog, standards version and description package. so I guess that these differents are not very importand
[12:43] <nigelb> bdrung: yep, gimme a minute
[12:44] <bdrung> ari-tczew: and 0001-Revert-Fix-the-session-is-shutdown-when-the-agent-ex.patch?
[12:44] <ari-tczew> bdrung: what's the package or bug number?
[12:44] <bdrung> ari-tczew: the same (obexd)
[12:44] <ari-tczew> bdrung: fixed upstream
[12:45] <ari-tczew> I should write that patch has been fixed upstream
[12:46] <bdrung> ari-tczew: yes. that's one thing that should be in the bug explanation
[12:47] <ari-tczew> sorry
[12:51] <bdrung> ari-tczew: and where did you see that?
[12:52] <ari-tczew> bdrung: what see?
[12:52] <bdrung> ari-tczew: that the patch has been fixed upstream?
[12:56] <ari-tczew> bdrung: tested - I've installed debian package, sent file to my phone and it works, and upstream changelog: 	Fix unneeded reset of session after a CONNECT.
[12:58] <bdrung> ari-tczew: ok. acked this sync request
[13:35] <ari-tczew> bdrung: is merging bzr harder than from debdiffs? (from sponsor point of view)
[13:36] <bdrung> ari-tczew: a little bit. i need to get used to and use the advantages of the VCS.
[13:36] <ari-tczew> yhy
[13:39] <bdrung> ari-tczew: yhy?
[13:39] <ari-tczew> just like aha
[13:40] <ari-tczew> aha, heh, yhy...
[13:40] <ari-tczew> ok
[13:40] <bdrung> aha
[13:41] <bdrung> ari-tczew: how do you pronounce this word without vowels?
[13:43] <ari-tczew> bdrung: without vowels? hmmm "y" is not vowel?
[13:43] <ari-tczew> aa
[13:43] <ari-tczew> I just know! not in english
[13:44] <ari-tczew> in polish  "y" is vowel
[13:44] <ari-tczew> ok so I'll not use in future word "yhy" :-)
[13:46] <bdrung> ari-tczew: interesting: wikipedia says that y can be a vocal in some cases in German.
[13:46] <bdrung> the English wikipedia says: "representing a vowel in most languages that use it"
[13:47] <ari-tczew> :-)
[13:47] <bdrung> ari-tczew: does yhy sound like ihi?
[13:48] <ari-tczew> bdrung: no, doesn't sound like ihi :)
[13:50] <ari-tczew> bdrung: but... maybe. heh, not easy to compare
[13:50] <ari-tczew> bdrung: I think that you're bored. do you want get more syncs to sponsor? :-)
[13:54] <bdrung> ari-tczew: if you can catch up with me :P
[13:57] <mok0> Any hints on how to deal intelligently with an svn-only upstream?
[13:58] <mok0> Creating a tarball seems somewhat old-school
[14:11] <jcfp> mok0: how else? iirc, one cannot assume internet access is available during build.
[14:22] <mok0> jcfp: not during build, but during source package creation
[14:23] <jcfp> get-orig-source in debian/rules?
[14:23] <mok0> jcfp: yeah, I just wondered if something smarter was available
[14:24] <astraljava> mok0: bzr-svn a branch, then use bzr-builder to create the source package? Would that work?
[14:25] <mok0> astraljava: hmm, going via bzr eh? Good idea I'll give it a try
[14:26] <astraljava> mok0: Isn't that where the whole ubuntu dev is going anyway? :)
[14:26] <mok0> astraljava: indeed :-)
[14:27] <mok0> astraljava: ... and it could be done via a LP project of course, it just seems a bit overkill for what I am looking at
[14:27] <mok0> ... which is a one-file python module :-)
[14:27] <astraljava> mok0: Granted, quite a lot of work for that.
[14:28] <jcfp> convincing upstream to create releases is the other obvious way out.
[14:28] <mok0> jcfp: not realistic
[14:29] <mok0> jcfp: I am looking at just one directory of the whole svn.openstreetmap.org repo
[14:29] <jcfp> ayay
[14:31] <bdrung> mok0: use "svn export" and then tar the export
[14:32] <mok0> bdrung: yes, I know that route, I was just wondering if anything smarter was possible
[14:32] <bdrung> mok0: not that i am aware of
[17:11] <fabrice_sp> bdrung, I've update the ack-sync script from your branch, and the script now requires a syncpackage script that is not the one in ubuntu-dev-tools package. where can I find it
[17:51] <bdrung> fabrice_sp: bzr branch lp:ubuntu-dev-tools - it will be in the next upload
[17:52] <fabrice_sp> ok. Thnaks!
[17:55] <bdrung> debfx: regarding bug #581366 - i have no email address for sponsoring your sync request
[17:59] <debfx> bdrung: it's in the last line of the bug description (i.e. changelog entry of 1:0.1.98svn2318-5)
[18:01] <bdrung> ah, ok
[18:01] <bdrung> debfx: it doesn't build
[18:01] <bdrung> due to unmet dependencies
[18:03] <debfx> bdrung: it requires the new gettext package which you've sponsored a few hours ago
[18:03] <bdrung> ah, ok
[18:33] <ari-tczew> I'm working with submittodebian right now, script want got "Please briefly describe your problem", do I need to write something?
[18:35] <kklimonda> ari-tczew: well, I always add a brief description of a patch and rationale (if it's not obvious bugfix)
[18:37] <ari-tczew> of course remove changes related to ubuntu maintainer field?
[18:38] <kklimonda> yes, they are of not use for debian anyway :)
[18:39] <ari-tczew> could be done submittodebian from bzr branch? not debdiff?
[18:42] <fabrice_sp> ari-tczew, AFAIK, you run it from a source directory
[18:43] <DeeJay1> hi, I'm having a problem with dh_repository mainly dh_girepository -pgir1.0-emerillon-0.1 \n dh_girepository: Could not find gir file for Emerillon-0.1.typelib is there a way to debug it somehow?
[18:43] <ari-tczew> I don't know what I have to with this file in diff generated by submittodebian: diff -Nru junitperf-1.9.1/debian/changelog junitperf-1.9.1/debian/changelog
[18:43] <fabrice_sp> just delete the lines
[18:43] <fabrice_sp> (I always delete them)
[18:43] <ari-tczew> ok
[18:45] <pabelanger_> Where can I find information about the Debian import for Maverick? How it is done, and what packages are selected?
[18:45] <ScottK> fabrice_sp: You sponsored the last blends merge.  I was wondering if you could work with the last merger (or do it yourself if they are not around) and get it updated soon.  It's blocking some other merges.
[18:45] <ScottK> pabelanger_: It's all of them except a small list of blacklisted packages.  AFAIK, new packages didn't get brought in yet, but will soon.
[18:45] <fabrice_sp> ScottK, sure. I'll check if the last merger is still active/willing to merge it
[18:46] <ScottK> fabrice_sp: Thanks.
[18:46] <pabelanger_> ScottK: Thanks, is that an automated process or manual?
[18:46] <ScottK> There is a script that has to be manually triggered by an archive admin
[18:46] <ScottK> So once started it's automatic.
[18:47] <ari-tczew> bdrung: when sponsors will start use your sync script?
[18:47] <pabelanger_> ScottK: Roger.  Where is the best place to follow that process?
[18:47] <ScottK> I don't know that there is a good one.
[18:48] <ScottK> It's safe to assume that any package in Debian that's not in Maverick yet will show up.
[18:49] <bdrung> ari-tczew: which one do you refer to? ack-sync or syncpackage?
[18:50] <ari-tczew> bdrung: hmmm syncpackage propably
[18:51] <bdrung> ari-tczew: dunno. i will write a mail to ubuntu-devel to start a discussion about the script and the sync procedure
[18:52] <ari-tczew> ok
[19:14] <ari-tczew> bdrung: is your script ajusted to multiple closing bugs?
[19:15] <bdrung> ari-tczew: multiple closing bugs?
[19:16] <ari-tczew> bdrung: now you give a bug number to script, but what about when sync can fix/close e.g. 3 bugs? does your script can do it?
[19:17] <bdrung> ari-tczew: you can run "syncpackage -b 12345 -b 23456 -b 345678 [...]"
[19:18] <ari-tczew> bdrung: this is it what I'm looking for. thanks for information
[19:18] <bdrung> yw
[19:18] <bdrung> ari-tczew: please check the changes file before uploading
[19:19] <ari-tczew> bdrung: yyyy before uploading?
[19:20] <bdrung> ari-tczew: syncpackage generates a changes file that can be uploaded
[19:20] <ari-tczew> bdrung: but I'm not a sponsor
[19:21] <bdrung> ari-tczew: you don't need to act as sponsor
[19:50] <bdrung> ari-tczew: i sent the mail "The syncing process and syncpackage (or: How to speedup the syncing process)" to ubuntu-devel
[19:51] <ari-tczew> bdrung: nice
[19:51] <bdrung> share your thoughts
[20:16] <DeeJay1> could someone take a look at https://code.edge.launchpad.net/~deejay1/emerillon/lucid? I have trouble getting dh_girepository to work :/
[23:21] <psusi> wtf?  I explicitly told lp to use lucid... I did bzr push lp:~psusi/ubuntu/lucid/parted/dmraid-fix and it comes back and says it created a stacked branch using maverick