[02:13] <micahg> should we remove sources for packages that don't build any binaries on arches we support?
[02:19] <MTecknology> "What about the rdepends?"
[02:19] <MTecknology> How can I answer this?
[02:19] <micahg> MTecknology: what's the question?
[02:20] <MTecknology> How do I know if a new package affects rdepends?
[02:21] <micahg> MTecknology: apt-rdepends -r BINARYPKGNAME
[02:21] <micahg> MTecknology: and reverse-build-depends BINARYPKGNAME
[02:21] <MTecknology> apt-utils supplies those commands?
[02:22] <micahg> MTecknology: no
[02:23] <MTecknology> oh.. ubuntu-dev-tools
[02:31] <MTecknology> rdepends are packages that depend on this package, right?
[02:31] <micahg> MTecknology: yep
[02:32] <MTecknology> thanks :)
[05:39] <ScottK> micahg: No.  Just ignore sources that don't build for our archs.  Removing them bloats the sync blacklist to no purpose (they don't hurt anything).
[06:13] <micahg> ScottK: right, thanks
[06:29] <c2tarun> !git
[06:36] <c2tarun> !svn
[06:36] <micahg> !msgthebot > c2tarun
[06:37] <c2tarun> micahg: sorry, I was not knowing this is also a way :( sorry
[06:37] <micahg> c2tarun: no problem, now you can query the bot all you want :)
[06:37] <c2tarun> micahg: yup :)
[06:38] <c2tarun> micahg: its still getting displayed here.
[06:39] <jmarsden> c2tarun: Yes, but noone except you can see it now :)
[06:39] <c2tarun> jmarsden: oh.... :) got it.
[06:39] <jmarsden> :)
[06:40] <artfwo> how can I tell quilt, that I want to rename a file in a patch?
[06:40] <artfwo> I am not sure, that "quilt add oldname newname && mv oldname newname" is the right way to do it
[06:41] <c2tarun> artfwo: add that new filename to patch and then rename old one. then refresh
[06:41] <micahg> artfwo: there's a quilt rename command as well
[06:42] <c2tarun> micahg: thats for reaming patch I guess not for renaming files.
[06:42] <micahg> ah, right
[06:42] <artfwo> yes, rename is for patches
[06:43] <c2tarun> artfwo: try how I told, and tell me if it works.
[06:44] <artfwo> c2tarun, it works, but I thought there may be a smarter solution :)
[06:44] <c2tarun> artfwo: ya there may be :) please tell me if you find one.
[07:11] <c2tarun> what is trunk?
[07:17] <jmarsden> c2tarun: In the context of animals, it is the nose of an elephant :)  In the context of version control systems, it is the main stream of code from which other secondary streams of development can branch off.
[07:18] <c2tarun> jmarsden: ok, so it means that git get branch of from trunk?
[07:18] <jmarsden> I do not know what context you are seeing the word "trunk" in, so I can't answer that :)
[07:19] <hyperair> a trunk is a suitcase.
[07:19]  * hyperair hides
[07:19] <jmarsden> c2tarun: You should probably read more about version control systems and bzr and git to get a good understanding of this stuff
[07:19]  * micahg finds hyperair hiding behind a trunk
[07:19] <jmarsden> c2tarun: You should probably ignore hyperair :)
[07:20] <c2tarun> jmarsden: I was looking on project neon, there I am getting these words very frequently like svn/git trunk. :/
[07:20] <jmarsden> c2tarun: OK, so read up on distributed version control systems a little and then come back to what you are doing.
[07:22] <c2tarun> jmarsden: is there any wiki page for this?
[07:23] <jmarsden> Probably... I'll see what I can find...
[07:24] <jmarsden> Try http://learn.github.com/p/intro.html for a tutorial about git
[07:25] <jmarsden> c2tarun: And maybe http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/ for a more general into to distributed version control.
[07:26] <c2tarun> jmarsden: these links are awesome :) thanks
[07:26] <jmarsden> c2tarun: You're welcome.
[07:28] <c2tarun> one more help please, earlier when I was using ubuntu lucid when buffering of any video ends then I can copy that video from /tmp folder, but since I switched to kubuntu maverick there are no such videos in that tmp folder. why?
[07:30] <jmarsden> That's not a MOTU-ish packaging-related question... I don't generally watch videos on Ubuntu... sounds like the software you are using to watch videos has been fixed to tidy up after itself and delete the temp files it uses -- but that is just a guess.
[07:41] <hyperair> c2tarun: are you talking about Flash videos?
[07:43] <hyperair> the current version of Flash seems to create a /tmp/FlashXXXXXX file, keep the file descriptor open, and then delete it.
[07:44] <hyperair> meaning that if you do lsof -n | grep Flash, you'll see which file descriptor points at this deleted file. then you can go to /proc/$pid/fd/$fd (specifically, cat /proc/$pid/fd/$fd > /path/to/newfile
[07:45] <hyperair> i frequently also just run mplayer on the partially-buffered file the same way =p
[08:15] <c2tarun> hyperair: ping
[08:37] <hyperair> c2tarun: pong
[08:38] <c2tarun> hyperair: this channel is not for discussing Flash problem :( can I PM you?
[08:38] <hyperair> sure
[12:20] <c2tarun> If a package has newer version in debian and no watch file, how can I get it from debian?
[12:28] <micahg> c2tarun: pull-debian-source in ubuntu-dev-tools
[12:47] <c2tarun> there is package tracked by ftbfs tracker, its newer version in debian claims in its changelog that it fixed the ftbfs problem, but package still fails to build on natty, what can I do? I know how to fix, but how can I close same debian bug in two changelog entries?
[12:49] <Bachstelze> c2tarun: a lot of things can cause FTBFS, if it is fixed in debian doesn't mean it is in Ubuntu, you should probably file a new ftbfs bug
[12:50] <Bachstelze> c2tarun: what's the package?
[12:50] <c2tarun> Bachstelze: bfm
[12:50] <c2tarun> Bachstelze: some errors mentioned in debian's bug error log are same
[12:50] <c2tarun> i'll brb
[12:51] <c2tarun> Bachstelze: yup I am back :) you looked at the package?
[12:52] <Bachstelze> looking at it now
[12:52] <Bachstelze> you can't do these things in 30 seconds ;)
[12:53] <c2tarun> Bachstelze: sorry :)
[13:05] <Bachstelze> c2tarun: what's the debian bug number?
[13:05] <c2tarun> Bachstelze: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=553959
[13:06] <Bachstelze> debian bug 553959
[13:07] <Bachstelze> c2tarun: that's the prefered way ;)
[13:07] <c2tarun> oh ... :) sorry
[13:11] <c2tarun> Bachstelze: found something?
[13:13] <Bachstelze> c2tarun: the new versions adds -lX11, but all the -l flags are still in the wrong place
[13:13] <Bachstelze> they should be after the .c files, not before
[13:14] <Bachstelze> on the command line
[13:14] <c2tarun> Bachstelze: so what should I do, file a new bug into debian?
[13:15] <Bachstelze> it's related, so report in the same bug
[13:15] <Bachstelze> and see what the maintainer says
[13:15] <Bachstelze> but wait a bit, I'll see if that's really the problem
[13:16] <c2tarun> sure
[13:16] <micahg> Debian might not have all the default flags that we do on
[13:18]  * Bachstelze nods
[13:18] <Bachstelze> --as-needed is probably the culprit here
[13:25] <c2tarun> Bachstelze: what should I do
[13:32] <c2tarun> I have problem with one more package, there is a package named btnx in that ftbfs bug tracker, its ubuntu1 version failed to build, should this error be reported to debian?
[13:35] <Bachstelze> what's ubuntu1 for?
[13:36] <c2tarun> I mean  btnx_0.4.11-3ubuntu1 version failed, as this incorporated the changes for ubuntu so I asked.
[13:38] <Bachstelze> yes
[13:38] <Bachstelze> I meant what changes does ubuntu1 bring opver the version in Debian?
[13:38]  * c2tarun looking
[13:39] <c2tarun> Bachstelze: something related to source code. must be necessary
[13:39] <Bachstelze> yeah
[13:40] <c2tarun> Bachstelze: so what should I do? report it to debian?
[13:40] <Bachstelze> so report it to both, we need an Ubuntu-specific patch anyway since we have already diverted
[13:40] <Bachstelze> there is no newer revision in Debian
[13:40] <c2tarun> Bachstelze: no there is no newer revision in debian + there is no patch as well. package doesn't follow any patch system
[13:43] <Bachstelze> c2tarun: http://paste.ubuntu.com/576463/
[13:43] <Bachstelze> bfm builds fine with this
[13:43] <Bachstelze> see how the LIBS must be after the SRCS
[13:44] <Bachstelze> last part
[13:45] <Bachstelze> or after the OBJS, depending on what you're doing
[13:45] <Bachstelze> but always at the end of the command line
[13:46] <c2tarun> I would have also done same thing but not in that proffesional way :( why you remove line 7 from comment?
[13:46] <Bachstelze> I only did the last part
[13:47] <Bachstelze> line 7 is already in 0.6.4-4
[13:48] <c2tarun> Bachstelze: not getting what do you mean by last part? if its in last part how come its in debdiff?
[13:48] <Bachstelze> it's not a debdiff
[13:48] <c2tarun> i mean diff
[13:48] <Bachstelze> it's part of the .diff.gz for my fixed package
[13:49] <c2tarun> Bachstelze: ohh..... got it :)
[13:49] <Bachstelze> you normally don't submit debdiffs to debian, only patches
[13:49] <c2tarun> Bachstelze: so submittodebian submits patch like this?
[13:50] <Bachstelze> no idea, I have never used it
[13:50] <c2tarun> Bachstelze: so submittodebian submits creates patch like this?
[13:50] <c2tarun> Bachstelze: then how do you submit to debian?
[13:52] <Bachstelze> the old way, by email
[13:52] <c2tarun> Bachstelze: oh... :)
[15:22] <koenig> ive got question ive a deb package and i want to add this to the official ubuntu repostorys how can i do this
[15:22] <koenig> can sombody helpme pls ????
[15:23] <kklimonda> !revu | koenig
[15:25] <koenig> thanks for quick reply
[16:38] <c2tarun> Bachstelze: ping
[16:42] <Bachstelze> c2tarun: pong
[16:42] <c2tarun> Bachstelze: you remember that bfm package we discussed?
[16:43] <Bachstelze> yes
[16:43] <c2tarun> Bachstelze: dont you think bfm package is in condition for merge ( debian has a newer version which needs some change for building on ubuntu)
[16:47] <Bachstelze> c2tarun: we haven't diverted, so it would not be a merge, just a sync
[16:48] <Bachstelze> and we can apply the fix for --as-needed to the new debian revision
[16:48] <c2tarun> diverted means?
[16:49] <Bachstelze> it means that the apckage is different in Ubuntu and in Debian, denoted by ubuntuX appended to the version number
[16:51] <c2tarun> Bachstelze: so change for --as-needed can not be considered as a change enough for merge?
[16:51] <Bachstelze> the change is not commited to ubuntu yet, right ?
[16:53] <ScottK> If the package currently fails to build on Ubuntu due to --as-needed then we want that fixed in Ubuntu.
[16:53] <Bachstelze> can't we sync the new debian revision at the same time ?
[16:54] <Ampelbein> Bachstelze: that is called a merge.
[16:54] <Bachstelze> only if we have diverted
[16:54] <Bachstelze> we have not, or not yet at least
[16:54] <ScottK> Bachstelze: We still call it a merge if the package is different when uploaded even if it wasn't before.
[16:54] <Bachstelze> ok
[16:54] <Ampelbein> Bachstelze: it's still a merge if we introduce a change only now.
[16:54] <ScottK> The key point about a merge is we have to manually upload to Ubuntu.
[16:58] <c2tarun> ok, so I will file a bug for merge than
[18:28] <ari-tczew> c2tarun: FYI, output messages on lucas merges are outdated, you have to copy log from http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20110125-natty.html
[18:35] <c2tarun> ari-tczew: what log?
[18:35] <ari-tczew> c2tarun: when you create a bug on launchpad, you copy FTBFS log to description, right?
[18:36] <c2tarun> ari-tczew: that was not from lucas log, that was the actual error I got
[18:36] <ari-tczew> c2tarun: odd, in some cases I got another error than you
[18:37] <c2tarun> ari-tczew: what case?
[18:37] <c2tarun> I mean which casse
[18:37] <ari-tczew> wgrant: could you give me a link to latest rebuild of archive?
[18:38] <ari-tczew> c2tarun: bug 729118
[18:38] <ari-tczew> c2tarun: I got undefined reference to HMAC or something
[18:39] <ari-tczew> c2tarun: and please add
[18:39] <ari-tczew> Debian bug to this one
[18:39] <ari-tczew> on launchpad
[18:41] <c2tarun> ari-tczew: how to add debian bug?
[18:42] <ari-tczew> c2tarun: Also affects distribution
[18:44] <c2tarun> ari-tczew:  can you please check, is it fine now?
[18:47] <ari-tczew> c2tarun: yes, it's fine. when you receive message from bug tracker about fixed bug in Debian, it's sign to check whether we can drop changes in package.
[19:59] <m4n1sh> is watch file mandatory while packaging?
[20:00] <Bachstelze> m4n1sh: no
[20:00] <m4n1sh> Bachstelze: thanks
[20:00] <Bachstelze> http://www.debian.org/doc/debian-policy/ch-source.html#s-debianwatch
[20:00] <Bachstelze> says it's recommended, though
[20:01] <Ampelbein> m4n1sh: but it's considered good practice to include one and many reviewers will complain if its not there.
[20:03] <m4n1sh> Ampelbein: the problem is that I am taking an upstream codebase
[20:03] <m4n1sh> which does not have autotools support
[20:03] <m4n1sh> so I took the codebase, added build support
[20:03] <m4n1sh> and hosting it myself
[20:03] <m4n1sh> and working side by side :(
[20:03] <Bachstelze> how is upstream supposed to be built thenN
[20:03] <Bachstelze> ?*
[20:04] <m4n1sh> it is a Visual Studio solution
[20:04] <m4n1sh> hosted at json.codeplex.com
[20:04] <m4n1sh> it is a .NET library
[20:04] <m4n1sh> works on mono also
[20:04] <Bachstelze> hmm
[20:04] <m4n1sh> but does not have any linux build system support
[20:04] <m4n1sh> it is a great library, since mono as of now doesnt have good json support
[20:05] <Bachstelze> not sure how to handle such cases, I think you should list yourself as upstream, since the source tarball is modified
[20:06] <Ampelbein> m4n1sh: and you need a get-orig-source target if you modify the source tarball
[20:06] <m4n1sh> Ampelbein: in which file
[20:06] <Ampelbein> m4n1sh: debian/rules
[20:06] <m4n1sh> Bachstelze: I just added the build system but no codebase changes
[20:08] <Ampelbein> m4n1sh: are you repacking the orig.tar.gz?
[20:08] <m4n1sh> Ampelbein: the upstream is a zip file with source and binaries and blobs
[20:08] <m4n1sh> i mean upstream release
[20:08] <m4n1sh> stripping out everything
[20:09] <m4n1sh> and adding build support
[20:09] <m4n1sh> is what I am doing in my case
[20:09] <m4n1sh> and finally I am done
[20:09] <m4n1sh> and now trying to package it
[20:10] <Ampelbein> m4n1sh: the point is, 'wget <upstreamsource>, tar xfz <debian-diff>' must result in the source that can be built. if it is not, you need a get-orig-source target.
[20:11] <Ampelbein> m4n1sh: so if you repack the .zip to .tar.gz, you need to make a rule for that.
[20:11] <m4n1sh> Ampelbein: okay. I have hosted my packagign in gitorious
[20:11] <m4n1sh> will release it
[20:11] <m4n1sh> and add that in watch
[20:11] <m4n1sh> still I need a rule?
[20:12] <Ampelbein> m4n1sh: since debian only allows gz, bz2 and xz, yes, you need a rule to repack the tarball.
[20:13] <m4n1sh> Ampelbein: the tarball I am releasing is tar.gz
[20:13] <m4n1sh> which I work  upon after taking the source from upstream
[20:14] <Bachstelze> m4n1sh: the point is that someone can take the package and use it with any new source release
[20:14] <Bachstelze> so that people can take over if you can't maintain the package antmore
[20:14] <Bachstelze> anymore*
[20:15] <m4n1sh> yes, but right now I am acting in the middle between the package and the upstream newtonsoft-json author
[20:15] <m4n1sh> since he does not support the build systems
[20:15] <m4n1sh> the upstream release files are a zip file
[20:15] <m4n1sh> with no LICENSE
[20:15] <m4n1sh> or README
[20:15] <m4n1sh> anything
[20:16] <Bachstelze> that's what get-orig-source is for
[20:17] <m4n1sh> hmm
[20:17] <Bachstelze> http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules
[20:17] <m4n1sh>  get-orig-source should point to upstream one?
[20:17] <Bachstelze> you should make it fetch thz zip, do the changes and repack it as .tar.Gz
[20:17] <m4n1sh> says
[20:18] <m4n1sh> This target fetches the most recent version of the original source package from a canonical archive site (via FTP or WWW, for example), does any necessary rearrangement to turn it into the original source tar file format described below, and leaves it in the current directory.
[20:18] <m4n1sh> actually writing a script to do this is tough
[20:18] <m4n1sh> it has to be done manually
[20:18] <m4n1sh> tested and then can be released
[20:18] <Ampelbein> m4n1sh: if there is no LICENSE, you might have other problems to consider first.
[20:18] <m4n1sh> Ampelbein: the LICENSE is not shipped with the tarball
[20:19] <m4n1sh> but when downloading it shows properly
[20:19] <Bachstelze> it should be
[20:19] <m4n1sh> I am checking agai
[20:19] <m4n1sh> when I click Download it says "Do you agree to this license"
[20:19] <Bachstelze> doesn't matter
[20:20] <Ampelbein> m4n1sh: the license must be included in the debian package
[20:20] <Bachstelze> the license must accompany the code
[20:20] <m4n1sh> I checked the upstream zip file
[20:21] <m4n1sh> it contains a readme.txt file
[20:21] <m4n1sh> upper part is readme
[20:21] <m4n1sh> below part contains license
[20:21] <m4n1sh> and the debian package has that license
[20:22] <Ampelbein> m4n1sh: good. be sure to mention that in debian/copyright
[20:22] <m4n1sh> checked again
[20:22] <m4n1sh> I have updated it
[23:28] <micahg> gilir: you know xulrunner-1.9.2 is going away in natty, right?
[23:33] <gilir> micahg, there are still some packages depending on it, you plan to do the migration so late in the cycle ?
[23:33] <micahg> gilir: whatever is left at teh end of the cycle, we're going to drop
[23:34] <micahg> we can't support multiple xulrunners
[23:35] <micahg> gilir: is gecko-mediaplayer an npapi plugin?
[23:35] <gilir> so why not removing it right now ? it's still in the archive
[23:35] <micahg> gilir: to give people a chance to port and still have the app useable :)
[23:36] <micahg> but I'll bring up dropping it for beta
[23:37] <gilir> micahg, I don't know, it installs a .so in the same place than flash and java
[23:37] <micahg> gilir: is upstream not active?
[23:38] <gilir> micahg, it is, only the ususal ubuntu/debian maintainer is not
[23:39] <micahg> gilir: is it just a matter of packaging the new upstream?
[23:40] <kklimonda1> micahg: why the hell are upstream devs depending on mozjs if it doesn't provide a stable API?
[23:40] <kklimonda1> micahg: is it the same with v8?
[23:40] <gilir> micahg, no, according to upstream, it's already compatible with 2.0
[23:40] <micahg> kklimonda1: idk about v8, but mozjs should be stable soon
[23:40] <micahg> gilir: ok, I'll try to have a look this week
[23:41] <kklimonda1> micahg: stable as in they will provide stable API for years?
[23:41] <RAOF> micahg: Oh, really?  Mozilla will commit to an ABI in the near future?  Sweet.
[23:41] <micahg> kklimonda1: which upstream are you frustrated with now
[23:41] <kklimonda1> micahg: mongodb ;)
[23:41] <micahg> RAOF: they're thinking about trying at least :)
[23:41] <kklimonda1> sweet
[23:41] <micahg> kklimonda1: yep, are you trying to port to xul-2.0?
[23:42] <kklimonda1> micahg: I know nothing of xul 2.0 API changes, nor about mongodb internals. I may take a look at it this week, but I wouldn't hold my breath :)
[23:50] <gilir> micahg, thanks :)