[00:03] <lamalex> c_korn: I've got a sample Makefile.am that does that if you want to look at it
[00:03]  * sistpoty goes to bed... gn8 everyone
[00:03] <c_korn> lamalex: would be nice
[00:03] <lamalex> c_korn: it might be easier f you just branch lp:gnome-do
[00:04] <lamalex> then you can see the full picture
[00:04] <lamalex> the toplevel Makefile.am and data/Makefile.am are the ones to look at
[00:04] <c_korn> bzr: ERROR: Invalid url supplied to transport: "lp:gnome-do": No such project: gnome-do
[00:05] <lamalex> sorry
[00:05] <lamalex> lp:do
[00:10] <c_korn> lamalex: ok the data/Makefile.am looks similar to mine. but I have no po directory. that is why @INTLTOOL_SCHEMAS_RULE@ fails
[00:11] <lamalex> so remove that
[00:11] <lamalex> ?
[00:11] <lamalex> or just create a po directory
[00:11] <c_korn> so I just replaced it with the empty rule "%.schemas: %.schemas.in". but then it fails with this make[4]: *** No rule to make target `indicator-session.schemas', needed by `all-am'.  Stop.
[00:11] <lamalex> why not just create a po directory?
[00:11] <lamalex> translations are ftw
[00:12] <c_korn> the po directory is all which has to be created ?
[00:14] <lamalex> i think you ned a POTFILES.in file, but it can probably just be empty
[00:19]  * c_korn presses all thumbs he has
[00:20] <c_korn> grep: po/Makefile.in: No such file or directory
[00:20] <c_korn> config.status: error: po/Makefile.in.in was not created by intltoolize.
[00:20] <c_korn> the file po/Makefile.in.in has been created
[00:21] <c_korn> I create an empty POTFILES.in there and try again
[00:21] <lamalex> yah, I odn't have any Makefiles in my po dir, so idk
[00:22] <c_korn> not even a Makefile.in ?
[00:23] <c_korn> it has been created by autogen.sh
[00:23] <c_korn> ok, this is weird: config.status: error: po/Makefile.in.in was not created by intltoolize.
[00:23] <c_korn> it was created by intltoolize actually.
[00:26] <lamalex> I'd look for other errors/warnings higer up in the output
[00:27] <c_korn> there is also: grep: po/Makefile.in: No such file or directory
[00:27] <c_korn> this is correct. the file does not exist
[00:31] <c_korn> need to sleep
[00:31] <c_korn> lamalex: thanks for your help
[00:38] <lamalex> I've got a question about patching stable debs, do I have to apt-get source twice to create a diff or is there a way to diff against the orig.tar.gz
[00:41] <jmarsden|work> lamalex: Maybe I am misunderstanding the question.  debuild should create a diff.gz for you... why would you need to diff against the orig.tar.gz by hand?  Similarly cdbs-edit-patch or whatever patch tool will create patches for you...
[00:41] <Laney> what are you trying to do?
[00:43] <lamalex> jmarsden|work: I'm just learning about debian packaging, so I'm sure there's a simple answer to this that I'm just totally ignorant to
[00:43] <jmarsden|work> lamalex: OK... so Laney's question is very relevant... what specifically are you trying to do?
[00:44] <lamalex> Laney: in jolicloud we need to patch Janty's gnome-power-manager and I need to make some changes to the source and repackage them back up
[00:44] <Laney> so you want to learn about patch systems then
[00:46] <Laney> run "what-patch" to see which one it uses
[00:46] <jmarsden|work> lamalex: Have you read through and understood https://wiki.ubuntu.com/PackagingGuide/Complete  (part 4 and part 7.1 seem very relevant to you)
[00:47] <lamalex> jmarsden|work: I will bookmark this, thanks
[00:47] <jmarsden|work> No problem.
[00:50] <lamalex> Laney: so will these allow me to alter the source in the source dir when i apt-get source?
[00:52] <x1250> Guys, I (naively) named a ffmpeg PPA version as: 5:0.5+svn19732-ppa2. The problem is that this packages *breaks* a lot of things (http://paste.ubuntu.com/261214/) and also, when trying to build a package that depends on this custom ffmpeg it fails to build because of unmet dependencies.
[00:52] <x1250> here you can see: http://launchpadlibrarian.net/30922495/buildlog_ubuntu-karmic-i386.mlt_1%3A0.4.4-84-g676f7ec%2Bppa1_FAILEDTOBUILD.txt.gz
[00:53] <Laney> lamalex: yeah a patch system is a way of managing the changes you make to the upstream release
[00:53] <directhex> lamalex, when you apt-get source, as long as you add a changelog entry to make the version number higher (dch -i) then any changes you make to the source package will be represented in the "new" source package when you run "debuild -S"
[00:55] <lamalex> directhex: but shouldn't they really go in a patch/ dir?
[00:55] <directhex> lamalex, essentially the .diff.gz file contains any changes compared to orig. how best to manage that is where things like patch systems come into play - but the diff.gz file is produced when you build the source package (with debuild -S) and represents all changes not in the orig - whether yours or from the previous packager
[00:55] <Laney> right, the .diff.gz is itself a patch system
[00:56] <lamalex> beautiful
[00:56] <Laney> albeit one that doesn't scale well
[00:57] <lamalex> and if the project already uses a different patch system?
[00:57] <directhex> then continue to use it, ideally
[00:57] <lamalex> for instance g-p-m uses quilt
[00:58] <Laney> yep
[00:58] <Laney> add your own patches into the mix
[00:59] <lamalex> I guess I'll read up on quilt
[00:59] <lamalex> thanks for your help guys :)
[01:03] <lamalex> you guys aren't debian developers are you? I'm lookin for a sponsor for a package ;)
[01:03] <Laney> what is it?
[01:04] <Laney> I suggest you find the appropriate team
[01:04] <lamalex> http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=tictactoe-ng
[01:05] <Laney> python right?
[01:05] <lamalex> yah
[01:05] <Laney> try PAPT
[01:06] <lamalex> what's/who's papt
[01:06] <Laney> python applications packaging team
[01:06] <Laney> i think
[01:06] <lamalex> ah
[01:18] <kees> siretart: congratz :)
[01:35] <ScottK> lamalex: This is mostly about the Python modules team, but it and PAPT are run essentially the same way: https://wiki.ubuntu.com/Debian/PythonModulesTeam
[01:35] <lamalex> ScottK: thanks
[01:35] <lamalex> you guys are super helpful
[01:35] <lamalex> ah, i dont have a module i have an application
[01:36] <lamalex> so i need the python applications team
[01:36] <ScottK> It's the same people/places, just a different svn repo.
[01:37] <lamalex> gotcha
[02:22] <YokoZar> ScottK: is there a reason r-cran-dosnow was never synced from Debian?  The changelog seems to indicate it's basically the same.
[02:23] <YokoZar> (writing Feature Freeze Exception request...which is looking more like a sync request for that package)
[02:26] <bankix> Hello.
[02:27] <bankix> I created two debian packages for ubuntu which are currently not listed in the repositories, afaik.
[02:28] <bankix> I would like to contribute them. Am I on the right channel here?
[02:35] <ScottK> YokoZar: Probably I didn't notice it.
[02:37] <ScottK> bankix: You are, but you are just slightly too late.  We had our feature freeze for the next release yesterday.
[02:38] <ScottK> bankix: Normally at the start of our development cycle new packages in Debian are automatically sync'ed, so you should need to do approximately nothing to get them in.
[02:38] <bankix> Oh, no problem for me. I'm not too keen on having it into Karmic.
[02:38] <bankix> I've got time.
[02:39] <bankix> These two packages are not avaiable in Debian either.
[02:39] <ScottK> Oh.  I mis-understood.
[02:39]  * ScottK didn't notice Debian/debian.
[02:39] <bankix> NP.
[02:40] <ScottK> Yes, this is the place, but not until after Karmic is released.
[02:40] <ScottK> You're welcome to help out with stuff in the meantime and make Ubuntu better.
[02:40] <bankix> Okay, I can wait for Karmic.
[02:41] <bankix> I just created a new distro based on ubuntu for home banking purposes.
[02:42] <bankix> There I included some finance software based on Java, called Hibiscus.
[02:42] <bankix> Capable of HBCI.
[02:43] <bankix> Therefore, I built two .deb packages and put them into my own repository. But they'll install on every Jaunty as well.
[02:43] <bankix> So I thought of contributing them.
[02:44] <bankix> I'll switch to Karmic as well, so I'll create new packages when needed for Karmic, when it's out. So no hurry in getting it into Karmic.
[02:46] <bankix> I'll get back here in two or three month then, when Karmic is released.
[02:46] <bankix> Thanks for info.
[03:03] <zooko> Is there a document about how to file a Feature Freeze Exception request?
[03:05] <zooko> Any users of ipython here?
[03:11] <white> bankix: maybe try and get them into debian first and then they'll be synced later?
[03:12] <bankix> white: Maybe. What do I use best for creating Debian packages? lenny?
[03:12] <zooko> Found it: http://fridge.ubuntu.com/
[03:13] <zooko> https://wiki.ubuntu.com/FreezeExceptionProcess
[03:13] <ScottK> bankix: You can make a Sid pbuilder chroot and use it for testing.
[03:13] <white> bankix: yeah, i'd recommend using sid
[03:13] <ScottK> bankix: I maintain a number of package in Debian this way.
[03:13] <ScottK> We'd rather get it from them so more people benifit too.
[03:14] <bankix> Hmm, any link how to set up such a pbuilder chroot?
[03:15] <white> bankix: there should be some documentation in the pbuilder/cowdancer packages
[03:15] <bankix> Ah, pbuilder is a package? Okay.
[03:15] <wgrant> https://wiki.ubuntu.com/PbuilderHowto
[03:16] <bankix> Oh, I should have read it before building my packages for ubuntu, I realize.
[03:17] <bankix> Thanks.
[08:00] <hyperair> what's the appropriate procedure for getting packages rebuilt?
[08:00] <hyperair> due to ABI changes or whatnot
[08:07] <RAOF> hyperair: Uploading a packge with "no change rebuild for libfoo2->libfoo3 transition" as the changelog, basically.
[08:20] <RAOF> hyperair: Oh, and using the "-xbuild1" suffix if the package currently doesn't have any Ubuntu changes.
[08:24] <hyperair> RAOF: aha. that's what i was looking for, thanks
[08:24] <hyperair> the -xbuild1 =)
[08:47] <hyperair> who do i subscribe for package removal requests?
[08:52] <wgrant> hyperair: The sponsors team if you need sponsorship.
[08:52] <wgrant> Otherwise ubuntu-archive.
[08:53] <hyperair> okay
[08:55] <hyperair> thanks
[10:35] <Id2ndR> Hi everybody. I'm a metee of didrocks. I think it would be a relatively easy task to package the florence program (onscreen keyboard), so I'd like a little help to start to do this.
[10:40] <Id2ndR> I'm not familiar with bazar so I don't know how to use PPA to build package. I don't know if I should first make a package independently of the PPA or not
[10:41] <lifeless> bazaar is just a way to record the work you do
[10:41] <lifeless> so that other people can build on it
[10:42] <Id2ndR> Ok, so I should try without bazar first ?
[10:43] <lifeless> no
[10:43] <lifeless> you should understand it doesn't alter interactions with PPA or anything else
[10:43] <lifeless> [this is a slight simplification, however it will get you going in the right direction]
[10:44] <nicoInattendu> Hi , The package luciole was uploaded : https://edge.launchpad.net/ubuntu/+source/luciole
[10:45] <Id2ndR> Ok, am I right saying that bazar and PPA aren't necessary linked ?
[10:45] <nicoInattendu> But i dont know if the assciated LP bug sholud be set so fix commited or fix released ?
[10:45] <lifeless> nicoInattendu: fix released if its fixed in karmic right now
[10:46] <geser> nicoInattendu: fix released
[10:46] <nicoInattendu> ok
[10:48] <joaopinto> Id2ndR, bazar and PPA are not linked, you really should try to get some overview on what both are before trying to do something that needs them
[10:49] <Id2ndR> thanks lifeless and joaopinto
[10:50] <joaopinto> Id2ndR, if you are new to packaging, you should be focused on the packaging process, PPA's and bazar can get into play later
[10:50] <Id2ndR> joaopinto: I just started to read the wiki about that :). I already have package some rpm but nothing about deb
[11:52] <Id2ndR> I've got a strange problem while running debuild : http://pastebin.com/m5af2950e
[11:54] <Id2ndR> Can this be related to the "fakeroot" used in debuild ?
[12:00] <joaopinto> what is the default chartset recommended for debian/control, UTF-8 ?
[12:03] <Id2ndR> joaopinto: I'm not sure to understand the question. I know that i was able to compile the program on jaunty (I didn't try to package it in jaunty), and now I'm trying to package it in karmic
[12:04] <joaopinto> Id2ndR, my question was not for you , was for the chan :)
[12:04] <lifeless> joaopinto: yes, if you need nonascii
[12:05] <joaopinto> lifeless, ok tks
[12:05] <Id2ndR> joaopinto: ok, sorry ;)
[12:25] <Id2ndR> Please, does anybody knows some tips about packaging program that install gconf schemas ?
[12:26] <pochu> Id2ndR: use dh_gconf
[12:28] <Id2ndR> pochu: I'll look at this tool, thanks :)
[12:39] <Laney> hmm
[15:24] <christoph_debian> Heya! I guess it's to late now to fix #346926 as it's feature-freeze time?
[15:25] <christoph_debian> my bad, the bug's actually already fixed but not closed
[15:27] <lfaraone> I have a package, rainbow, which requires libnss-rainbow2 to be installed and *enabled-in-/etc/nsswitch.conf* in order to function. Is there some maintainer script of nss I can use to manipulate nsswitch.conf?
[15:34] <sistpoty> hi folks
[15:49] <coolbhavi> hello
[15:49] <coolbhavi> anyone has an idea how to call cmake during build in rules file
[15:51] <coolbhavi> here is the rules file http://pastebin.com/d12d02e8c
[15:52] <coolbhavi> I build depend on cmake
[15:53] <sistpoty> coolbhavi: maybe you change line 10 to "cd app && cmake" ?
[15:53] <coolbhavi> here is control file sistpoty http://pastebin.com/d574f47fd
[15:54] <sistpoty> coolbhavi: same goes for other occurances of $(MAKE), just change these to cmake?
[15:55] <coolbhavi> sistpoty, you mean [ ! -f Makefile ] || $(CMAKE) distclean
[15:55] <coolbhavi> ?
[15:55] <sistpoty> coolbhavi: just cmake. I doubt that CMAKE is a make variable
[15:55] <coolbhavi> sistpoty, okay
[15:56] <sistpoty> coolbhavi: but basically yes. eventually you'll also need to replace Makefile with what's actually there (iirc cmake files are usually called CMakefile, but I haven't touched cmake stuff for some time)
[15:57] <coolbhavi> sistpoty, or can I use other b-d than cmake to build
[15:58] <sistpoty> coolbhavi: if the build system is a cmake one, then I guess you'll need cmake ;)
[15:59] <coolbhavi> sistpoty, okay
[16:19] <lfaraone> Hey, I'm building multibinary package (rainbow and libnss-rainbow2), but when I specify  "debian/rainbow/usr/lib/*" (the only files I want in the package) in "libnss-rainbow2.install", it actually puts them in "./debian/rainbow/usr/lib/*" in the resulting package. What am I not doing properly?
[16:21] <Laney> lfaraone: just put usr/lib
[16:21] <Laney> (also see man dh_install)
[16:24] <lfaraone> Laney: uh, when I do that, it installs the python library into "/usr/share/lib/", rather than the lib we specified.
[16:25] <Laney> what?
[16:25] <Laney> export DH_VERBOSE=1 in your rules file
[16:25] <Laney> then pastebin the full output
[16:25] <Laney> as well as the contents of your .install files
[16:26] <lfaraone> Laney: okay, one moment...
[16:27] <lfaraone> Laney: do I *need* an .install file for the first binary package in debian/control?
[16:28] <Laney> you need one if you want to install extra things in there
[16:29] <lfaraone> Laney: oh, /me just reread CDBS docs. for python multibinaries, "# CDBS defaults to the first non -doc/-dev/-common package listed in "debian/control""
[16:29] <Laney> right, helpers install files too
[16:31] <lfaraone> Laney:
[16:32] <lfaraone> Laney: log: http://sprunge.us/NVQg and libnss-rainbow2.install: http://sprunge.us/JCWL
[16:34] <Laney> is DH_VERBOSE on?
[16:34] <lfaraone> Laney: yes, DH_VERBOSE=1
[16:42] <Laney> I suspect the python system is installing the files for you
[16:46] <christoph_debian> are FTBFS bugs considered RC for Ubuntu as well?
[16:46] <christoph_debian> worth reporting?
[16:47] <sistpoty> christoph_debian: definitely worth reporting
[16:48] <Laney> we don't really have "RC" for universe though
[16:48] <christoph_debian> ok I'll build again to make sure it's not caused by me experimenting and if it's still there
[16:49] <sistpoty> christoph_debian: eventually you could also peek at http://qa.ubuntuwire.com/ftbfs/ (maybe it's listed there already)
[16:56] <lfaraone> Hey, lintian is complaining that my debian-changelog file is a symlink. It's a symlink because it's in the same source package as one of the packages it depends on, and for space purposes cdbs automagically symlinks it. Can I add a lintian override for this reason?
[16:57] <christoph_debian> sistpoty: it's not listed
[16:57] <sistpoty> lfaraone: just ignore the lintian warning ;)
[16:57] <lfaraone> sistpoty: okay, but what about when my sponsor complains it's not lintian clean? :P
[16:57] <sistpoty> lfaraone: tell him that there should be a bug open against lintian to get rid of this warning for ubuntu
[16:57] <christoph_debian> lfaraone: you depend on the package shiping the changelog, right?
[16:58] <lfaraone> christoph_debian: correct.
[16:58] <lfaraone> sistpoty: okay, well, is this invalid in debian? (since that's where I'm uploading my package)
[16:58] <lfaraone> *having my package uploaded to
[16:58] <sistpoty> lfaraone: nope, there it shouldn't happen...
[16:59] <sistpoty> lfaraone: is the package using cdbs? if so, have you tried to build it in an unstable chroot?
[16:59] <lfaraone> No. Oh, I see :)
[16:59] <sistpoty> lfaraone: iirc it's an ubuntu only change in cdbs causing the symlinks ;)
[17:00] <christoph_debian> I guess it's even allowd in Debian if you meet some strict conditions
[17:01] <lfaraone> Oh, lintian is complaining that I have a useless whatis entry for one of the manpages I created with "help2man". That's because I honestly have no idea what that command does, it's not used in any other part of their code, and I can't figure it out from the sourcecode. Can I ignore that too, or should I bug upstream to figure out what it is?
[17:03] <Laney> run lintian with -i
[17:03] <Laney> and it will tell you more
[17:04] <lfaraone> Laney: well, I know why it's giving the warning, it's because the "NAME" section is "rainbow-sugarize - manual page for rainbow-sugarize".
[17:04] <lfaraone> (for one of the packages)
[17:04] <lfaraone> *programs
[17:05] <Laney> it would be nice if you could fix it
[17:05] <Laney> but probably not the end of the world
[17:07] <sistpoty> Laney: btw.: in regards to ghc6/ia64: have you seen the mail from kari? looks like ghc6 still needs itself for stage1 so we should not drop ia64,as 6.8.2 appears to be enough for bootstrapping the next version
[17:07] <Laney> yeah i saw it
[17:07] <Laney> it's not necessary though, there is a stage1 build
[17:07] <Laney> but i dont mind keeping it aruond
[17:08] <Laney> around*
[17:08] <sistpoty> Laney: imo the default stage1 build needs ghc6 to create the intermediate c files. at least this was the case earlier on. It might work if we'd have the intermediate files around but back in the old days I never managed to get this going though
[17:09] <Laney> I rebuild it on my mac all the time
[17:09] <sistpoty> oh, nice :)
[17:09] <Laney> good on a cold winters day
[17:09] <sistpoty> heh
[17:10]  * hyperair grumbles about frostwire upstream being unresponsive
[17:12] <Laney> why do people always want to package that?
[17:14] <hyperair> hmm?
[17:14] <hyperair> somebody roused my interest on it the other day
[17:14] <hyperair> i thought i'd just poke the upstream via email and irc
[17:14] <hyperair> but the lead developer doesn't appear on irc, and doesn't seem responsive to mail either
[17:15] <lfaraone> Would a program that "populates a directory with the contents of the current environment variables" be in /usr/bin or /usr/sbin?
[17:16] <hyperair> um how do you populate a directory with the contents of your environment variables?
[17:17] <lfaraone> hyperair: quoth the manpage: "For each (key, value) in the current environment variables, mkenvdir creates a file with a name of key, contents value, in DIR."
[17:17] <hyperair> i see.
[17:17] <hyperair> fascinating.
[17:18] <hyperair> well, i'd say /usr/bin
[17:18] <hyperair> sbin appears to be something for sysadmins alone
[17:18] <hyperair> or otherwise administrators of said machine
[17:19] <lfaraone> hyperair: re frostwire, fork it! ;)
[17:19] <hyperair> lfaraone: upstream is active. just not responsive to my email.
[17:20] <hyperair> lfaraone: the issue is not that they are inactive, just that they're full of precompiled binaries
[17:20] <hyperair> and their site nicely claims that they're 100% GPL.
[17:20] <lfaraone> hyperair: and therefore not FOSS
[17:20] <hyperair> where's the source code?!
[17:20] <hyperair> well rather, the source is around, you just can't tell which binary comes from what
[17:20] <hyperair> they claim that they're FOSS.
[17:21]  * christoph_debian tries interesting packaging tricks like ignoring make errors
[17:21] <hyperair> you'll get beautiful lintian warnings
[17:22] <christoph_debian> hyperair: do you mean me? Jep I'm not in any way intending to upload that ;)
[17:22] <hyperair> oh
[17:22] <hyperair> heh
[17:22] <christoph_debian> just trying to see what happens
[17:23] <hyperair> erm the errors shall be.. ignored?
[17:24] <christoph_debian> sure but sometimes you can get some working package with soe small tricks, might help finding the problem for the errors
[17:25] <hyperair> it's probably better to patch the build system into submission =\
[17:25] <hyperair> you don't want anything pretending to be completely built when it's not
[17:34] <christoph_debian> hyperair: yeah I'm just searching for the root cause and so on ... but seems I've found some hints now
[18:41] <xnox> hey all! Can anyone please point me to gecko.m4 "upstream" (In the process of updating achient autootools upstream)
[18:48] <christoph_debian> ok how do I extract a source rpm?
[18:56] <randomaction> christoph_debian: rpm2cpio file.rpm | cpio -id
[18:56]  * Laney blinks
[18:56] <christoph_debian> randomaction: abused krusader let's see if the opensuse guys fixed my problem already :)
[19:01] <randomaction> Do I need a FFe for a no-change rebuild? (NBS-related)
[19:02] <Laney> no
[19:02] <randomaction> ok, thanks
[20:28] <blizzkid> Lo all. Would anyone have time and patience to walk me through a (imho simple) packaging? I have a script, I want to create a package, I need it to depend on at least version 2.0 of another package, and the script should be placed in /usr/bin upon apt-getting it.
[23:13] <blizzkid> hmmz, how do I tell dpkg-build to build for karmic instead of unstable? Can't seem to find it in the man page
[23:14] <Zhenech> p3rror, will do so tomorrow, bedtime now :)
[23:14] <blizzkid> dpkg-buildpackage that is
[23:15] <Zhenech> blizzkid, write it in the changelog?
[23:15] <p3rror> yep Zhenech
[23:15] <p3rror> so you received my message
[23:15] <p3rror> :)
[23:16] <Zhenech> p3rror, yes, my mutt just blinked telling me this :)
[23:16] <Zhenech> and I thought, hey, look if ali is on irc and tell him "ok" before you go sleeping
[23:16] <Zhenech> :)
[23:16] <blizzkid> thx Zhenech that worked
[23:17] <p3rror> you are a good main Evgeni
[23:17] <p3rror> thanks in advance
[23:17] <p3rror> ;
[23:17] <p3rror> ;)
[23:17] <Zhenech> you wellcome :)
[23:17] <p3rror> i mean you are a good man Evgeni
[23:17] <Zhenech> but now really bedtime :)
[23:17] <Zhenech> cu tomorrow
[23:17] <p3rror> yes i see
[23:17] <p3rror> well see you later