[04:40] <bbigras__> Is it wrong that bug #786491 has 'Status tracked in Oneiric' if it only affects Natty and Maverick?
[04:41] <ubottu> Launchpad bug 786491 in lfm (Ubuntu Natty) "lfm crashes at startup, because of UnicodeDecodeError" [Undecided,Confirmed] https://launchpad.net/bugs/786491
[04:42] <micahg> bbigras__: no, there's an oneiric task open so that makes sense, do you need a task for maverick?
[04:42] <bbigras__> micahg: Yes please.
[04:42] <micahg> bbigras__: done, thanks
[04:43] <bbigras__> micahg: thanks!
[05:21] <shayonj> how do i know the section of program for the debian/control file
[05:22] <shayonj> ?
[05:22] <Rhonda> By reading the section descriptions and deciding yourself.
[05:23] <shayonj> where can i find that or in the apt-repo description, you mena ?
[05:23] <shayonj> mean*
[05:26] <Rhonda> It's in the policy.
[05:27] <Rhonda> ah, and that refers to the packages site. "neat" :)
[05:27] <Rhonda> shayonj: http://packages.ubuntu.com/oneiric/ - or in the package tool of your choice
=== almaisan-away is now known as al-maisan
[05:29] <shayonj> Rhonda, oh alright. thanks :)
=== al-maisan is now known as almaisan-away
[05:43] <shayonj> is using apt-rdepends is a good idea to find the dependencies of a package ?
[05:45] <shayonj> actually i dont think so. thanks anyways :0
[05:46] <shayonj> :) *
[05:46] <RAOF> apt-get rdepends $X does the opposite: it finds the packages which depend on $X.
[05:53] <Rhonda> the r stands for reverse :)
[06:06] <shayonj> RAOF, Rhonda .. right. So do you guys know, what should I be using to check the dependencies as i believe dh_make doesnt do that on its own, right
[06:07] <Rhonda> Use pbuilder/cowbuilder/some chrooted build environment with the minimal set of packages installed
[06:07] <Rhonda> That will fail if you don't give it all the needed Build-Depends and you can work on from that point, iteratively
[06:08] <shayonj> Rhonda, right, but for pbuilder i need .dsc and i am building this package from scratch
[06:09] <shayonj> its like i want list dependencies in the control file
[06:09] <Rhonda> So?
[06:10] <Rhonda> .dsc is easy. dpkg-source -b and done
[06:10] <Rhonda> You want to have *Build-*Dependencies in the control file. The dependencies should be figured out by dpkg-shlibdeps
[06:11] <shayonj> oh i see
[06:11] <shayonj> and does  dpkg-shlibdeps list them automatically in the control file later ?
[06:12] <shayonj> i have the build dependencies in the control filoe
[06:12] <shayonj> file*
[06:12] <Rhonda> That's what the placeholder is there for
[06:12] <Rhonda> The ${shlibs:Depends} will get filled in by dpkg-shlibdeps
[06:12] <shayonj> right right
[06:13] <shayonj> ugh.. thanks Rhonda :D
[06:13] <Rhonda> So for the Depends in the binary package, you only need to add stuff that can't be automatically get figured out. For most parts, don't worry.
[06:14] <shayonj> yep. its interesting, just taking a while to understand the working. Thanks Rhonda :)
[06:36] <shayonj> what is a good packaging license any recommendations/suggestions ?
[06:37] <RAOF> Generally one uses the same license as the rest of the code, although any free license is ok.
[06:37] <shayonj> do i need to do any kind of registration for that or just list it ?
[06:42] <RAOF> You're the author of the packaging; you just document what license you're releasing it under.
[06:42] <shayonj> cool.
[06:43] <shayonj> okay one more question, this package is licensed under GNU but it is not present here /usr/share/common-licenses/ . so should i just copy the text from its copyright file (from the source)
[06:43] <shayonj> ?
[06:44] <shayonj> i am sorry i meant, copy from the license file of the source*
[06:44] <RAOF> Your debian/copyright file needs the full text of the license, yes.
[06:45] <shayonj> okay.
[06:46] <shayonj> yeah, i read it in the guide but thought it would a good idea if i just cleared the doubt before moving ahead. better to be on the safe side.
[06:53] <shayonj> how do i find out the authors copyright ? or is the same as rest of it
[06:55] <RAOF> I'm not sure what the question is.  The code you're packaging presumably has a license attached (if it doesn't, then it's not redistributable, and we can't put it in the archive).
[06:56] <shayonj> RAOF, yes it does have a license attached to it. but here https://wiki.ubuntu.com/PackagingGuide/Complete#copyright it says "Copyright:" and thats where the authors copyright goes in, right ? so i am asking where do i get that info from
[06:57] <shayonj> it says this - Copyright:
[06:57] <shayonj>         Copyright (C) {Year(s)} by {Author(s)} {Email address(es)}
[06:58] <RAOF> Hm.  That documentation should be updated to point to http://dep.debian.net/deps/dep5/
[06:58] <shayonj> okay.
[06:58] <shayonj> thanks for that !
[07:06] <shayonj> been a long day. time to stretch. night guys
=== almaisan-away is now known as al-maisan
=== al-maisan is now known as almaisan-away
=== almaisan-away is now known as al-maisan
=== medberry is now known as med_out
=== Quintasan_ is now known as Quintasan
[13:30] <ScottK> RAOF: DEP-5 is not required.
[13:31] <ScottK> It seems like a lot of non-requirements to point people at.
[14:24] <whelmingbytes> Hi, I am in need of some help enabling desktop effects when logging in with Ubuntu Classic after installing gnome-panel. Any one have any ideas?
[14:25] <nigelb> whelmingbytes: You should probably ask in #ubuntu, which is the support channel. This channel is for development of universe packages.
[14:25] <whelmingbytes> ah ok thanks!
=== lenios__ is now known as lenios_
=== al-maisan is now known as almaisan-away
=== bulldog98_ is now known as bulldog98
[18:27] <gador> hi, I have a question: I want to pack a package containing a script compiled by node package manager (npm). But by doing a npm install <package> it checks whether there is a new version, but the build environment doesn't have a internet connection. How can I build and install the package without an internet connection? (Reference: bug 861219)
[18:27] <ubottu> Launchpad bug 861219 in Ubuntu "[needs-packaging] forever" [Wishlist,New] https://launchpad.net/bugs/861219
[18:37] <tumbleweed> gador: do you actually need to do any building? Can you not just copy the js library to /usr/lib/nodejs/$pkg ?
[18:38] <gador> tumbleweed, I could try that, but yes, by doing a sudo npm install forever -g, it does compile things
[18:40] <tumbleweed> oh, so there are c extensions
[18:40]  * tumbleweed knows nothing about node packages
[18:41] <gador> tumbleweed, see http://paste.ubuntuusers.de/403177/ it is the output of the install
[18:42] <gador> if I cut internet connection, it complains about not being able to connect to the main node server to check for a newer version
[18:43] <gador> tumbleweed, too bad you don't know so much about node..
[18:45] <tumbleweed> gador: I'd ask these guys: http://wiki.debian.org/Teams/pkg-javascript
[18:45] <gador> tumbleweed, thanks I'll do that
[18:53] <tumbleweed> gador: looking at the forever source tree, i don't see anything that isn't javascript. The stuff that's being compiled must be in the dependencies
[18:54] <gador> tumbleweed, yes it seems the daemon package needs to be compiled (which is a dependency of forever as stated in package.json)
[18:56] <tumbleweed> gador: you'll have to package all the dependancies first
[18:57] <gador> tumbleweed, ah, ok. So I will have to pack "daemon" first, install it and then install forever?
[19:10] <tumbleweed> gador: correct (and any other forever dependencies that aren't packaged)
[19:12] <gador> tumbleweed, so I would have to pack all 12 dependencies first, get them installed and then install forever..?
[19:14] <tumbleweed> gador: yes
[19:14] <gador> tumbleweed, great ;-)
[19:18] <gador> tumbleweed, thanks for your help! I think I'll get back to that tomorrow and go to bed now ;-)
[19:44] <m4n1sh> there is a 1 line patch for a universe package in oneiric
[19:44] <m4n1sh> can it be accepted at this time?
[19:44] <tumbleweed> yes, if it's important
[19:45] <m4n1sh> I don't think it is an important package
[19:45] <m4n1sh> but yeah people do use it
[19:45] <m4n1sh> not sure about the popularity
[19:45] <m4n1sh> it is gnome-activity-journal
[19:46] <m4n1sh> right now it does not work
[19:46] <m4n1sh> due to a method which blocks loading of the UI
[19:46] <tumbleweed> no I mean an important pant
[19:46] <tumbleweed> patch
[19:46] <m4n1sh> well, don't know how you define important
[19:46] <m4n1sh> but without that patch the application is right now broken
[19:46] <m4n1sh> useless
[19:46] <micahg> m4n1sh: that package is fine for bug fixes
[19:47] <tumbleweed> making a not working package work is pretty important :)
[19:47] <m4n1sh> micahg: tumbleweed right now that is completely broken
[19:47] <m4n1sh> look at this askubuntu question for more info http://askubuntu.com/questions/64021/gnome-activity-journal-stalls/64105
[19:47] <m4n1sh> micahg: tumbleweed or just this image http://i.stack.imgur.com/sZlC8.png
[19:48] <micahg> it has no reverse depends, so bug fixes would be fine, no working is an RC bug and that's fine too :)
[19:48] <tumbleweed> m4n1sh: go ahead
[19:48] <m4n1sh> so shall I update this branch?
[19:48] <m4n1sh> https://code.launchpad.net/~ubuntu-branches/ubuntu/oneiric/gnome-activity-journal/oneiric
[19:48] <m4n1sh> means a merge request?
[19:49] <m4n1sh> and 0.8.0-1 becomes? 0.8.0-2?
[19:49] <tumbleweed> m4n1sh: or provide a debdiff. 0.8.0-1 becomes 0.8.0-1ubuntu1
[19:50] <m4n1sh> never created a debdiff though, you people have merge right?
[19:50] <tumbleweed> m4n1sh: not sure what the question is, but yes, you can create a merge request
[19:51] <m4n1sh> thanks
[19:51] <m4n1sh> doing it now
[20:24] <m4n1sh> I created a patch directory
[20:24] <m4n1sh> and put the series file
[20:24] <m4n1sh> which contains the name of the patch
[20:24] <m4n1sh> and put the patch in the patch file
[20:25] <m4n1sh> now the problem is that when I look at the build log
[20:25] <m4n1sh> it shows
[20:25] <m4n1sh> dpkg-source: info: applying disable_set_background.patch
[20:25] <m4n1sh> dpkg-source: info: applying debian-changes-0.8.0-1ubuntu1
[20:25] <m4n1sh> the second patch comes out of nowhere and reverses the patch
[20:25] <m4n1sh> how to solve this?
[20:25] <tumbleweed> you didn't have the patch applied at build time
[20:26] <m4n1sh> how can I do that
[20:26] <tumbleweed> that behavior has changed in newer versions of dpkg, bt
[20:26] <tumbleweed> btw
[20:26] <tumbleweed> now it'll just abort
[20:27] <m4n1sh> wont putting the patch under debian/patches be enough
[20:27] <m4n1sh> for debuild to pick it up?
[20:28] <tumbleweed> yes, so I'm assuming there's something else going on too
[20:29] <m4n1sh> tumbleweed: you want the branch? or the build log?
[20:29] <jtaylor> whats in debian-chages-0.8...?
[20:29] <tumbleweed> m4n1sh: branch
[20:29] <m4n1sh> tumbleweed: lp:~manishsinha/gnome-activity-journal/fixes-831436-gaj-notloading-oneiric
[20:29] <m4n1sh> jtaylor: the exact opposite of the patch I added
[20:29] <m4n1sh> it reverses it, don't know how it is getting created
[20:30] <jtaylor> it gets created automatically by dpkg from the diff to the orig tarbal
[20:31] <m4n1sh> yes
[20:31] <m4n1sh> how to stop this in this case?
[20:32] <m4n1sh> jtaylor: I looked at how Jo handled patch in zeitgeist-sharp and did in the same way
[20:32] <tumbleweed> m4n1sh: your branch looks fine
[20:32] <jtaylor> that branach has a stray debian changes in it
[20:32] <jtaylor> remove it, clean your bzr tree
[20:32] <jtaylor> then it should work
[20:33] <jtaylor> debian/patches/series
[20:33] <m4n1sh> you mean series needs to be there?
[20:33] <m4n1sh> that file?
[20:33] <tumbleweed> yes it needs to be there
[20:33] <jtaylor> yes
[20:33] <jtaylor> but without the extra entry
[20:34] <tumbleweed> right, it was fine once I removed that entry :)
[20:34] <m4n1sh> which extra entry?
[20:34] <jtaylor> debian-changes...
[20:34] <m4n1sh> ah
[20:35] <m4n1sh> even I removed that, but it gets created on the fly
[20:35] <jtaylor> clean your tree
[20:35] <jtaylor> bzr revert; bzr clean-tree
[20:35] <jtaylor> but beware that removes uncommited stuff
[20:35] <m4n1sh> debian/patches/series is there in the branch. Right tumbleweed ?
[20:35] <tumbleweed> yes, it's there
[20:35] <jtaylor> yes but incorrect
[20:36] <m4n1sh> ah
[20:36] <m4n1sh> that gets added
[20:36] <m4n1sh> :(
[20:40] <m4n1sh> trying, will take a min
[20:41] <m4n1sh> yes, works
[20:43] <tumbleweed> cool
[20:43] <m4n1sh> here is the merge req https://code.launchpad.net/~manishsinha/gnome-activity-journal/fixes-831436-gaj-notloading-oneiric/+merge/78005
[20:43] <tumbleweed> m4n1sh: btw, I suggest reading a quilt howto at some point (e.g. http://pkg-perl.alioth.debian.org/howto/quilt.html ) you probably want to use the quilt command most of the time, rather than playing with patches by hand
[20:44] <m4n1sh> tumbleweed: thanks a lot, bookmarked it :)
[20:44] <m4n1sh> will read tomorrow
[20:44] <m4n1sh> so do I need to subscribe some release of desktop or motu team to that bug?
[20:45] <tumbleweed> m4n1sh: no, the branch will appear in the sponsor queue, but seeing as I've already looked at it, I'll deal with it now
[20:45] <m4n1sh> thanks a lot
[20:45] <m4n1sh> tumbleweed: I have overwritten the branch
[20:45] <m4n1sh> so you might want to pull again
[20:45] <tumbleweed> otoh, the sponsor queue is quite long right now, so making a noise about it helps :)
[20:46] <tumbleweed> m4n1sh: you didn't close the bug in the changelog entry
[20:46] <m4n1sh> so that is important? do I need to make that change now?
[20:46] <tumbleweed> m4n1sh: and it's always helpful to document your patches: http://dep.debian.net/deps/dep3/
[20:46] <tumbleweed> yes, please
[20:48] <tumbleweed> is there any disadvantage to not setting the background there? I assume upstream will take a slightly different approach?
[20:48] <m4n1sh> so changeing "* Add patch to disable setting the background which was blocking AJ" to
[20:48] <m4n1sh> "* Add patch to disable setting the background which was blocking AJ (Closes: LP #831436)"
[20:48] <ubottu> Launchpad bug 831436 in gnome-activity-journal (Ubuntu) "Upon opening GNOME Activity Journal never gets past "Loading journal"" [Undecided,In progress] https://launchpad.net/bugs/831436
[20:48] <m4n1sh> tumbleweed: it was just a cosmetic thing
[20:48] <tumbleweed> no, you need a : after LP
[20:49] <tumbleweed> Usually we don't use Closes for lp bugs, just LP: #XXXX
[20:49] <tumbleweed> Closes: is for Debian bugs
[20:50] <m4n1sh> esp about that changing background
[20:50] <m4n1sh> that was just a cosmetic change
[20:50] <m4n1sh> which created more of a problem
[20:50] <m4n1sh> and the person who has done that is on leave (studies I suppose)
[20:50] <tumbleweed> yeah, functionality is more important :)
[20:53] <m4n1sh> tumbleweed: updated that
[20:59] <m4n1sh> tumbleweed: I think everything is done. Please look at it whenever you got time
=== Lutin is now known as Guest47024
=== med_out is now known as med
=== med is now known as medberry
=== Guest47024 is now known as Lutin
=== NCommander is now known as Guest45434
=== al-maisan is now known as almaisan-away
=== medberry is now known as med_out
=== Guest45434 is now known as NCommander
=== NCommander is now known as Guest61019
=== NCommand1r is now known as NCommander
=== Guest16725 is now known as StevenK