[00:13] <blizzkid> Would https://edge.launchpad.net/~mcielen/+archive/ppa/+build/1195292 be something that could be included in Ubuntu?
[00:14] <blizzkid> And how would I get it included?
[00:33] <blizzkid> ok, found it, and filed a bug
[03:14] <LLStarks> yo
[03:14] <LLStarks> i need a motu immediately
[03:18] <ScottK> LLStarks: You need air to breathe.  You don't need a MOTU.
[03:18] <LLStarks> wrong.
[03:18] <ScottK> OK, then I'm probably not the one you want.
[03:18] <LLStarks> i need a motu to fix a grand injustice imposed on the karmic community.
[03:18] <LLStarks> https://bugs.launchpad.net/ubuntu/+source/wine1.2/+bug/412195
[03:23] <LLStarks> so...
[04:58] <jedc> Hi, could anyone give me a quick rundown on what in the default debian/rules file is needed or unneeded if the package I'm compiling in not written in c and does not use a makefile? Must I use make? just some pointers in the write direction would be appreciated.
[04:58] <jedc> right direction
[04:58] <maco> afaik, dh7 lets you just have a 1-line rules by default and then you can throw in some overrides
[04:58] <maco> i forget the one line though :(
[04:59] <nhandler> maco: http://paste.ubuntu.com/261741/
[04:59] <maco> oh ok. 2 lines.
[05:00] <nhandler> Although, that may or may not work for what jedc wants to do. It all depens on the application
[05:02] <jedc> thats all you need? i thought you needed targets for build clean and everything because the utilities all use them
[05:03] <ScottK> dh 7 provides that behind the scenes.
[05:03] <ScottK> For many standard applications it just works like that.
[05:03] <ScottK> Sometimes you have to over-ride the standard config.
[05:04] <jedc> the default rules generated by dh_make has a lot of stuff in it
[05:05] <ScottK> Yes.  That is what was needed before dh 7.
[05:05] <ScottK> You can still do it that way if you want.
[05:07] <nhandler> jedc: If you do decide to use the newer style, make sure you have an accurate debhelper Build-Depends version in debian/control. http://pkg-perl.alioth.debian.org/debhelper.html has some information about what version a few debhelper functions require
[05:08] <jedc> thanks guys, that looks a lot simpler
[06:50] <RAOF> So, my membership of ~motu is expiring soon.  What's currently happening the launchpad teams?  Is this the team-membership I should renew, or should I let it lapse?
[06:50] <lifeless> just renew
[06:51] <lifeless> can always discard it later
[07:09] <wgrant> RAOF: ~motu is the current universe/multiverse upload privileges team. ~ubuntu-dev is meant to end up with no direct memberships. All this will change within months post-archivereorg.
[07:10] <RAOF> wgrant: Thanks.
[07:55] <pzico> hi, what channel may I get advices related to making setup.py files?
[08:01] <Ademan> entirely out of curiosity, does anyone know where opengl shader source code would best be placed according to the FHS?  I commonly see it thought of as "media" making /usr/share a candidate, however shaders are in fact executable, though by the gpu, making /usr/lib a good placement, I think people would find /usr/lib a bit funny, however I think that's what I lean towards.  anyone else have an opinion?
[08:14] <RAOF> Ademan: I'd treat them as program data, as they're loaded by programs and then shuttled off to the GPU (hence /usr/share).  An alternative way to looking at them is: are they (CPU) architecture-specific?  If not, /usr/share is probably a better spot.
[11:10] <Zhenech> bdrung, I got mail, didnt reply yet (was on VAC)
[11:19] <somaunn> hello everyone
[11:40] <Zhenech> bdrung, replied
[11:58] <shiki-> hi all..anyone can help me with dh / Makefile / package building? :/
[12:00] <Zhenech> if you ask a specific question one could try to :)
[12:00] <dktrkranz> shiki-: just ask :)
[12:01] <shiki-> well.. its a package.. without ./configure.. a really.. uhm FUBAR one?..so to say..
[12:01] <shiki-> http://launchpadlibrarian.net/31005900/buildlog_ubuntu-jaunty-i386.fotoxx_8.2.2.1-1~jaunty7~ppa1_FAILEDTOBUILD.txt.gz
[12:01] <shiki-> this is the build log..
[12:01] <shiki-> well. it always fails at "No rule to make target 'build-stamp' ...
[12:02] <shiki-> Im not sure where to start.. tried to edit Makefile, that didnt give me any result
[12:02] <Zhenech> how does your debian/rules look like?
[12:02] <dktrkranz> do you have a "build: build-stamp" target in your debian/rules, and no build-stamp target?
[12:03] <shiki-> eeeeeh.. I overlooked this one
[12:03] <shiki-> ty
[12:03] <shiki-> trivial mistake
[12:04] <shiki-> will try to rebuild it ASAP
[12:04] <dktrkranz> just an advice, use pbuilder for local tests, using PPAs is a waste of buildd time
[12:05] <shiki-> okay..ty
[12:05] <shiki-> (I was confused about how to test it before uploading)
[12:05] <shiki-> thanks.
[12:05] <dktrkranz> you're welcome ;)
[12:23] <pzico> I have trouble running python setup.py sdist. The packet I get doesn't install. I have only one source file that can be run directly with python in src/gui folder.
[12:23] <pzico> I'm trying to learn making setup.py and packages, but I'm stuck with this simple problem.
[12:23] <pzico> Do I have to add that only py file in manifest?
[12:24] <dktrkranz> pzico: have you already looked at distutils online documentation?
[12:24] <pzico> yes I have
[12:24] <shiki-> ehm..pbuilder is not really handy on a vm :/
[12:24] <pzico> I was following it.
[12:25] <Zhenech> shiki-, pbuilder does not need a vm
[12:25] <dktrkranz> could you please paste your setup.py?
[12:25] <shiki-> ehm...
[12:25] <pzico> I also tried to add path the way described in documentation, but for some reason can't get it work.
[12:25] <dktrkranz> !paste
[12:26] <Zhenech> shiki-, pbuilder creates a chroot and builds there, so you can build debian on ubuntu and ubuntu on debian etc
[12:26] <pzico> #!/usr/bin/env python
[12:26] <pzico> from distutils.core import setup
[12:26] <pzico> setup(name='surem',
[12:26] <pzico>       version='0.1.1',
[12:26] <pzico>       description='program',
[12:26] <pzico>       author='I am',
[12:26] <pzico>       author_email='el@gmail.com',
[12:26] <pzico>       packages={'surem' : ['src/gui/board_ui.py']},
[12:26] <pzico>     )
[12:27] <pzico> that board_ui.py is the only thing the program needs
[12:27] <shiki-> Zhenech, still, I cant install it on arch linux :)
[12:28] <Zhenech> shiki-, oh, well, technically you could :)
[12:28] <Zhenech> but yes, this makes it more difficult
[12:28] <Zhenech> but a chroot is still better than a VM imho
[12:28] <shiki-> well.. it works in vmware
[12:28] <shiki-> hmm.. beats me
[12:28] <shiki-> its more comfortable to work in an Ubuntu completely
[12:29] <Zhenech> your point :)
[12:30] <pzico> here is also pastebin link: http://paste.ubuntu.com/261917/
[12:32] <sistpoty> hi folks
[12:32] <dktrkranz> pzico: look at the one from oggconvert, it's very simple and should match your case perfectly
[12:32] <dktrkranz> hey sistpoty
[12:32] <sistpoty> hi dktrkranz
[12:35] <pzico> oggconvert is based on setup.py running a script, like is terminator program used in python packaging example. They load the script from the install folder directly.
[12:36] <pzico> I don't know what to figure out of that, unless to try learn make such script system myself
[12:38] <pzico> I think the question is, if I have a file helloworld.py in folder foo/bar/
[12:38] <pzico> how to make setup.py?
[12:38] <dktrkranz> well, "scripts" are single files, "packages" are modules
[12:38] <pzico> but why are the scripts assumed to be in the same folder with install?
[12:39] <pzico> and if my program gets bigger in future, it's not one single file anymore
[12:39] <pzico> It's a bit frustrating to go over reorganising files/folders in version control
[12:39] <pzico> just for setup program assuming all single files scripts..
[12:40] <dktrkranz> IIRC, you can pass a third parameter specifying where to get scripts from
[12:41] <pzico> or should I make it module nevertheless and the just call the main function from script?
[12:41] <pzico> I guess that's how it's done in that oggconvert
[12:41] <dktrkranz> yes
[12:42] <pzico> ok, good to know.. is there some name or keyword for this method using script calling modules, in case I want to learn more about it
[12:42] <dktrkranz> also look at this one: http://bazaar.launchpad.net/%7Edktrkranz/debomatic/debomatic.dev/annotate/head%3A/setup.py
[12:43] <dktrkranz> it also calls data_files
[12:43] <pzico> interesting, I guess I'm starting to understand this
[12:45] <pzico> that is a good example. thanks!
[12:46] <dktrkranz> np :)
[12:59] <shiki-> I ..dont..get..it
[12:59] <shiki-> pbuilder build *.dsc builds the package completely fine
[12:59] <shiki-> upload to PPA, it dies
[12:59] <shiki-> :/
[13:01] <Zhenech> shiki-, with what sort of an error?
[13:01] <shiki-> same Makefile problem with before
[13:01] <shiki-> but..thats it.. I removed that part from Makefile, used pbuilder
[13:03] <Zhenech> mh
[13:24] <shiki-> oh lol.. I made a small mistake.. yet it was fatal
[13:39] <c_korn> how can I get all files which cause this warning ? W: stone-soup source: patch-system-but-direct-changes-in-diff source/rltiles/tile-dngn.html and 8 more
[13:39] <Zhenech> c_korn, diffstat on diff.gz?
[13:40] <c_korn> Zhenech: oh, thanks. I was looking for a lintian option
[13:41] <Zhenech> no idea if it will do so in verbose mode or so
[13:41] <Zhenech> I just use diffstat for such things
[13:47] <shiki-> how can I make pbuilder as strict as the buildbots?
[13:47] <shiki-> I mean..buildbot dies, pbuilder works
[13:49] <sistpoty> shiki-: you could install pkgbinarymangler... but a failed buildlog might give more clue
[13:50] <shiki-> well..it was a patch problem. But thats it... I simply overlooked it since pbuilder created the builds
[14:03] <bdrung> Zhenech: thx
[14:39] <aladin_> hello, i have a big problem.. someone can tell to me the equivalent to "dpkg --force all" in apt?
[14:43] <andv> aladin_, usually if you have some deps problems you should give an apt-get -f install
[14:43] <aladin_> it'snt equivalent
[14:43] <aladin_> :(
[14:43] <andv> aladin_, what are you trying to do?
[14:43] <aladin_> overwrite file issue
[14:43] <andv> why are you trying to force something?
[14:44] <aladin_> but if i run the installation via "dpkg -i --force all" work fine, and if i use apt-get -f install do not work
[14:44] <aladin_> :\
[14:44] <andv> apt-get -f install fix for you deps problems
[14:44] <andv> and install the package you were trying to install without success (cause deps missing(
[14:45] <aladin_> it'snt depends issue.
[14:45] <aladin_> it's file overwrite!
[14:45] <andv> can't get what you mean sorry
[14:45] <aladin_> dpkg: error processing /var/cache/apt/archives/linux-image-2.6.30.5_2.6.30.5-10.00.Custom_i386.deb (--unpack):  trying to overwrite `/lib/firmware/whiteheat.fw', which is also in package linux-image-2.6.29.4 dpkg-deb: subprocess paste killed by signal (Broken pipe)
[14:46] <aladin_> if i use dpkg -i --force all package.deb work all fine
[14:46] <aladin_> but if i use apt-get -f install package.deb do not work
[14:46] <aladin_> so my question is, where is the equivalent to dpkg -i --force all in apt?
[14:47] <andv> aladin_, giving a --force all option is not the right way to go
[14:47] <aladin_> yes it it in my case.
[14:47] <andv> so if it worked why are you asking the apt equivalent?
[14:47] <aladin_> andv: have you solution about my issue or not ?
[14:48] <aladin_> because i need to do it via apt.
[14:48] <aladin_> -.-
[14:48] <arvind_k> hi, there is a bug in the notify-osd of karmic, the notification comes in the centre in the of the screen, why isnt it being fixed?
[14:48] <aladin_> arvind_k: check launchpad
[14:50] <aladin_> adnv ?
[14:50] <andv> aladin_, I guess there is no equivalent
[14:50] <aladin_> ok
[14:50] <aladin_> i will wait mvo
[14:50] <andv> aladin_, apt-get --help
[14:50] <arvind_k> aladin_, i have checked it, what am asking is, why isnt changes being reflected in the upstream version?
[14:51] <ScottK> arvind_k: It's on purpose.
[14:51] <ScottK> It's by design and not a bug.
[14:51] <ScottK> arvind_k: #ayatana is their channel.
[14:53] <arvind_k> ScottK, thanks ... :)
[14:57] <jedc> do i have to use make with debian/rules or can just run a custom install script from it? would it be easier to just make a makefile?
[14:58] <maxb> jedc: Give a bit more context to your question
[14:59] <jedc> maxb, i am trying to package a compiler, and i have a script that builds it for me, i wasnt using makefiles. Do i need to use make from debian/rules or can i just have the rules file run the script?
[15:00] <maxb> debian/rules is itself a makefile, but nothing at all says you have to have it run make to build your program
[15:02] <jedc> maxb ok, thanks, i think most of my confusion stems from most of the examples being tailored for packaging c/c++ programs
[15:04] <maxb> It's true that because very many programs follow the ./configure make make install pattern that the examples often use that. Just remember that those are only examples.
[16:40] <c_korn> hm, I wrote a gconf schema and it gets installed in /schemas/apps... by the postinst script but why doesn't it get installed in /apps/... so I can change the values ?
[16:41] <RainCT> Heya
[18:04] <Dyllan> Is there a way to install pre-deps from a .deb i have created? I specify the pre.dep in the control file, but gdebi just fails to install and complains that the pre-dep is needed which makes perfect sense, but i would like for it to be installed automatically if possible?
[18:06] <joaopinto> my question was not about wether you wanted to use text tools, but to identify wether it's a gdebi limitation for which you will need to file a bug report :)
[18:06] <joaopinto> and btw, why do you need pre-depends instead of depends ?
[18:08] <joaopinto> Dyllan, are the pre-depend debs available when you try to install the package ?
[18:08] <joaopinto> Dyllan, gdebi works with single packages, using regular APT methods, it will not attempt to satisfy depedencies from other external .deb packages, if that was your question
[18:09] <Dyllan> joaopinto: I would think that it could be a gdebi limitation, however i am sure it is setup that way for good reason.
[18:10] <Dyllan> joaopinto: yes, that was basically mu question. GDebi complains that it cannot install because of a pre-dep, so that makes sense because i set the pre-deb, but you have answered my question, GDebi cannot handle dependencies so then it is a GDebi limitation unfortunately.
[18:11] <Dyllan> I guess what  I could do is add a check into my program that checks to see if they dependency is installed and if not it installs it.. .
[18:21] <joaopinto> Dyllan, gdebi is very limited, for mutli .debs your best option is to use  a repository/PPA
[18:21] <joaopinto> with an apt-url link for the install
[18:21] <Dyllan> alright, thanks for the help.
[18:24] <joaopinto> np :)
[18:53] <kees> ScottK: can I get a FFe for ubuntu-dev-tools?  It looks like the current bzr contains a mess of fixes, but it just never got uploaded (0.76).
[18:54] <ScottK> Shouldn't be a problem.
[18:54] <kees> okay, cool, thx.
[19:12] <RainCT> nhandler: uhm.. is pull-revu-source looking for the URL of the .dsc file searching in revu.ubuntuwire.com/p/<pkg>? (don't really understand that perl stuff)
[19:23] <ScottK> Dear everyone: Please work on NBS: http://people.canonical.com/~ubuntu-archive/NBS/
[19:23]  * geser awaits the bug reports for the recent ubuntu-dev-tools upload
[19:47] <ryanakca> Is there a way to make sbuild drop to a shell in the schroot if a build fails?
[20:19] <nhandler> RainCT: Yes. I merely ported apachelogger's script to Perl. I plan on cleaning up the script later this week
[20:22] <RainCT> nhandler: You know about http://revu.ubuntuwire.com/dsc.py?package=X?
[20:23] <RainCT> nhandler: err, http://revu.ubuntuwire.com/dsc.py?url&package=X
[20:23] <nhandler> RainCT: I probably did at one point (just forgot). I'll fix it now
[20:25] <apachelogger> RainCT: I suppose that should be documented some place?
[20:26] <RainCT> apachelogger: Well, it isn't that interesting other than for scripting. Maybe what I should implement is something like  revu.ubuntuwire.com/download/X.{dsc,diff.gz,orig.tar.gz} so that you can just dget
[20:27] <sebner> RainCT: there is now a pull-revu-source though
[20:27] <nhandler> sebner: That is why RainCT was making his comments ;)
[20:27] <sebner> heh ^^
[20:28] <apachelogger> RainCT: possibly, though, I think that ?dsc.py is enough
[20:29] <apachelogger> also, IMHO downloading files individually does not have much of a use case for revu as for released sources
[20:29] <apachelogger> where one might just want the tar.gz because the packaging is in a no-full-source branch and needs to be merged with the source by builddeb
[20:32] <RainCT> apachelogger: I'm not sure I understand.  dget ../dsc.py?package=X doesn't work (it will get the .dsc and fail for the other files)
[20:32] <nhandler> RainCT: The URL returned by dsc.py is the path to the .dsc from /srv on spooky. It is not a valid URL
[20:33] <apachelogger> RainCT: dget only requires the dsc file?
[20:33] <apachelogger> so why would one need the other files :)
[20:33] <RainCT> apachelogger: Why would you want only a .dsc file? It's useless
[20:33] <apachelogger> nah
[20:33] <RainCT> nhandler: if you use ?url
[20:34] <nhandler> RainCT: Yes. For example, I get: http://revu.ubuntuwire.com/var/revu/revu1-incoming/nucleo-0905052003/nucleo_0.7.3-0ubuntu1.dsc
[20:34] <RainCT> nhandler: yeah, so then you can dget that
[20:34] <apachelogger> dsc.py returns url of most recent upload of $package as would be available in the regular UI
[20:34] <nhandler> That should probably not have the /var/revu part on it
[20:34] <apachelogger> so you run dget $URL and get the dsc and the diff.gz and the orig.tar.gz
[20:34] <RainCT> nhandler: err right, I'm fixing that right now
[20:34] <apachelogger> which is pretty much why one woud use dget and not wget anyway ;-)
[20:34] <nhandler> Thanks RainCT
[20:35]  * nhandler is fixing pull-revu-source
[20:50] <RainCT> nhandler: ok it's working now
[20:52] <nhandler> RainCT: pull-revu-source has been updated
[20:52] <RainCT> nhandler: cool, thx
[20:53] <nhandler> Thank *you* RainCT ;)
[21:21] <RoAkSoAx> DktrKranz, ping?
[21:35] <DktrKranz> hey RoAkSoAx
[21:41] <RoAkSoAx> how's it going DktrKranz
[21:41] <DktrKranz> fine, and you?
[21:42] <RoAkSoAx> DktrKranz, pretty good but kinda bored xD
[21:43] <DktrKranz> package something NEW ;)
[21:43] <RoAkSoAx> DktrKranz, hey I wanted to ask you, why would this error was showed to him by lintian and not to us when reviewing the package: https://bugs.launchpad.net/ubuntu/+source/lekhonee/+bug/419759
[22:21] <ScottK> RoAkSoAx: What version of lintian were you using?
[22:22] <RoAkSoAx> ScottK, I did not report the bug, slangasek did :). That bug is invalid right?
[22:22]  * ScottK didn't read the bug yet.
[22:23] <ScottK> Looks possibly valid to me.
[22:23] <ScottK> Is python-support needed in the clean rule?
[22:24] <ScottK> BTW, RoAkSoAx: Did you undertsand why I changed your patch before I uploaded lekhonee?
[22:27] <ScottK> Although I don't get it with the current lintian.
[22:27] <ScottK> slangasek: Are you sure you filed 418759 against the right package?  I can't replicate that lintian complaint.
[22:28] <RoAkSoAx> ScottK, I'm guessing that the change on the patch is because  /usr/bin/env python will figure out the correct location of python?
[22:28] <RoAkSoAx> ScottK, and I cant replicate the lintian complaint that's why I was thinking this is an actual invalid bug
[22:28] <ScottK> RoAkSoAx: If you read the Python Policy you'll find that we don't like /usr/bin/env python because it's easy to have it point at the wrong Python.
[22:29] <ScottK> RoAkSoAx: You may be right.  I've pinged slangasek, so  we'll wait and see.
[22:31] <RoAkSoAx> ScottK, ahh I see, so we should always try to use /usr/bin/python to avoid pointing to the wrong python. gotcha! :) thanks for explaining that to me
[22:31] <ScottK> You're welcome.
[22:32] <ScottK> We keep Python pretty up to date, so that's sufficient.  I know a lot of people on RHEL that always use their own Python in /usr/local so the env trick is useful for them.
[22:32] <ScottK> We'd rather be more deterministic.
[22:34] <RoAkSoAx> I see.
[22:57] <DktrKranz> RoAkSoAx: I used latest lintian from unstable
[22:57] <DktrKranz> and python-support is not involved in clean target
[23:02] <RoAkSoAx> DktrKranz, ok so this bug should be invalid then. I wonder why slangasek got that lintian error
[23:03] <DktrKranz> Dunno either
[23:06] <RoAkSoAx> weird
[23:20]  * ScottK guesses he was reviewing a number of packages and filed it on the wrong one.
[23:36] <ScottK> Next time someone sees quadrispro, please whack him with a hammer and remind him we are post feature freeze.
[23:39] <mrooney> Anyone know a guide for grabbing the appropriate theme colors in gtk to use in an app (or a more appropriate channel)?
[23:51] <DktrKranz> ScottK: ?
[23:51] <DktrKranz> what did he do?
[23:51] <ScottK> DktrKranz: https://launchpad.net/ubuntu/karmic/+source/zbar/0.8+dfsg-3ubuntu1
[23:52] <DktrKranz> UGH!