[04:19] <micahg> cyphermox: that freecad upload could've been another no change rebuild to fix the changelog entry
[04:20] <micahg> cyphermox: I meant build2 vs ubuntu1 :)
[04:21] <ScottK> micahg: He knows.  It was an accident.
[04:21] <micahg> ScottK: was looking for scrollback and didn't see any
[04:21] <ScottK> It was a PM.
[04:22] <micahg> ok
[07:06] <dholbach> good morning
[07:07] <mitya57> good morning! :)
[07:32] <iulian> Morning dholbach.
[07:37] <dholbach> hey iulian
[09:43] <jokerdino> hey MOTU folks, can someone take a jab at this question - http://askubuntu.com/questions/144052/how-to-file-a-bug-report-for-a-specific-ubuntu-release
[09:43] <jokerdino> i reckon you guys are the perfect ones to answer this question ^^
[12:58] <muelli> hey folks. I have a subversion repository with a debian/ folder. It's libnfc from http://libnfc.googlecode.com/svn/trunk. And all I want it a source package that I can upload. Bonus points if I can alter the arguments to dh_auto_configure. git-buildpackage would work reasonably well, but svn-buildpackage doesn't work as expected :-\ I.e. I need to generate a .orig tarball myself... Is that really true?
[13:18] <mitya57> muelli: .orig tarball should be downloaded from upstream, you shouldn't change or regenerate it
[13:19] <mitya57> if svn-buildpackage doesn't work, you can unpack upstream and your source into one directory
[13:19] <mitya57> cd there and run debuild
[13:24] <muelli> mitya57: I *have* already downloaded the SVN repository. So all the sources are there.
[13:26] <mitya57> muelli: if the upstream svn contains debian directory, the package should be native instead
[13:26] <mitya57> so, you need to change debian/source/format to "3.0 (native)" and
[13:26] <muelli> well, that shows 3.0 (quilt)
[13:26] <mitya57> drop "-0" prefix from the first (from top) entry in debian/changelog
[13:27] <mitya57> muelli: change "quilt" to "native"
[13:27] <mitya57> this is the most simpliest solution,
[13:28] <mitya57> you won't have to deal with separate .orig and .debian tarballs
[13:28] <mitya57> *the most simple
[13:28] <muelli> mitya57: alright. Sounds good. thank you very much.
[13:29] <mitya57> you are welcome
[13:29] <muelli> Still a bit annoying. I presume, I can convince dpkg-source to just assume the format to be native.
[13:30] <muelli> and quilt format would indicate there to be patches/ directory and a series file, is that correct?
[13:30] <mitya57> dpkg-source is for generating .dsc files
[13:31] <mitya57> quilt format is the most common format, it supports debian/patches but doesn't require that
[13:35] <muelli> how would I best change the "original" from SVN then. I could obviously modify in place. But should I rather export the the patch (i.e. svn diff), put it somewhere and revert the change?
[13:36] <mitya57> just modify in place
[13:36] <mitya57> are you going to just build that package for yourself, or upload it somewhere?
[13:39] <muelli> mitya57: well, I want to scratch my own itch first, but I want to do it as sustainably as possible. So it'll at least end up on my ppa
[13:40] <mitya57> in any case you'll have to modify that manually (or manually build the tarball, if you leave the format unmodified)
[13:40] <mitya57> every time the upstream changes
[13:41] <muelli> thanks for your help so far. Highly appreciated.
[13:42] <muelli> another dput related question. So far I have to do "dput -f ppa: ..." and I haven't had any success trying to configure a default. I want to make it "dput *.changes" only, i.e. without the -f. Is that possible?
[13:43] <muelli> ah, my ~/.dput.cf has method sftp, while the dput -f does ftp *thinking*
[13:44] <mitya57> my .dput.cf has ftp
[13:44] <mitya57> it's anyway secure because it checks your pgp key on server side
[13:45] <mitya57> and I do just "dput my-ppa PKGNAME_VERSION_source.changes"
[13:45] <muelli> yeah, well. sometime I can only go out of the network with port 22, 80 and 443. But right now it works, so I'll give it a shot
[13:46] <mitya57> I have to go out, sorry
[15:11] <PaoloRotolo> Hi all!
[15:18] <gnomefreak> is gir1.2-gjsdbus-1.0 still needed in 12.10?
[16:09] <AmberJ> Hello
[16:10] <AmberJ> I'm trying to create package(s) for OpenCog using instructions on ubuntu wiki..
[16:11] <AmberJ> When I run 'debuild -uc -us', all goes fine until I get this: http://pastebin.com/VqwrPZim
[16:11] <AmberJ> Line 19 is where some errors start to pop up...
[16:14] <AmberJ> .deb packages for opencog don't exist. I'm starting from scratch
[16:19] <AmberJ> Line 19 says: "cp: cannot stat `../../opencog-0.1/opencog/embodiment/Control/MessagingSystem/router': No such file or directory" ... But this file exists in the specified location
[16:30] <AmberJ> Also, opencog uses cmake and I didn't made any changes to debian/rules (autogenerated by 'bzr dh-make').
[16:31] <AmberJ> Though I read about some cmake edits that can be made to debian/rules, I didn't made any. And the build process seems to go fine without any edit to debain/rules
[18:02] <jtaylor> bug 700036
[18:02] <jtaylor> just wanted the title, lp times out in the browser
[18:05] <tumbleweed> reloading often works when bits of lp timeout. If the relevant bits of table are in RAM, it may not timeout
[18:07] <jtaylor> does not help :/ those blcr bugs almost always time out, probably because of the hundreds of dupes
[18:08] <tumbleweed> opened for me, first time
[18:08] <tumbleweed> oh, also for bugs, .../+text
[18:09] <jtaylor> strange
[18:09] <jtaylor> a +text works
[18:09] <jtaylor> thx
[18:26] <frceego> Hello
[18:29] <frceego> How common (and difficult) is it to create multiple packages from a single version controlled repo of a project that uses cmake?
[18:30] <frceego> The project has many component programs many of which can serve as independent program/libraries.
[18:30] <frceego> But they are all tied under a single cmake project using top-level CMakeLists.txt file.
[18:31] <jtaylor> you build multiple source packages?
[18:31] <bcurtiswx> SpamapS, re Bug #1003465, do I still need all that information with a microrelease SRU ?
[18:32] <jtaylor> a source package can have multiple binary packages
[18:32] <frceego> The code for the complete project is in a single upstream source package.
[18:33] <SpamapS> bcurtiswx: I don't see a micro release exception for empathy here: https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
[18:33] <SpamapS> bcurtiswx: so yes. At least you need to discuss the risk of regression created by introducing all of the changes.
[18:34] <frceego> The code for the complete project is in a single upstream source package."cmake". I could not find much info about cmake+multipleBinaries on Ubuntu wiki... So, I'm reading debian's new maintainer's guide.
[18:35] <frceego> oops, typo. I meant: I'm interested in this kinda project using "cmake". The upstream source is tied under a single cmake project()
[18:35] <jtaylor> you're using cmake to build the package?
[18:36] <bcurtiswx> SpamapS, hmm I thought there was some exception with GNOME packages and microreleases
[18:36] <frceego> yes jtaylor
[18:36] <jtaylor> I'm not familiar with that
[18:36] <frceego> ok
[18:36] <jtaylor> multiple binary packages from one source is possible (and normal), but no idea if cmake supports it
[18:37] <SpamapS> bcurtiswx: none that I see.
[18:37] <SpamapS> bcurtiswx: I think in practice, a lot of them have been waved through
[18:39] <geser> jtaylor, frceego: the splitting into seperate binary packages is done after the "make install" during the package build by specifing in debian/$package.install which files go to which binary package
[18:39] <bcurtiswx> SpamapS, hmm. OK. Thanks
[18:39] <jtaylor> yes but how to teach that to cmake?
[18:40] <jtaylor> or cpack in this case
[18:41] <geser> you don't need to tell cmake it, cmake install into $DESTDIR and debhelper (more precisely dh_install) moves then the files around
[18:41] <jtaylor> that requires modifying debian/
[18:41] <jtaylor> I guess what is wanted is automated debian packaging from cmake
[18:42] <frceego> jtaylor: sorry, if I was not clear. I'm NOT using cpack. All I do is use cmake to build project.
[18:42] <geser> to build a proper package you need files in debian/ anyways
[18:43] <jtaylor> geser:  I'm not sure about that cpack can output to debs and rpms
[18:43] <jtaylor> I don't thnk you need a debian dir for that
[18:44] <geser> I don't know about cpack, so can't comment on it
[18:44] <jtaylor> frceego: in that case do what geser said
[18:44] <frceego> yes. noted.
[18:45] <geser> if you want something which can be uploaded to the archive (or a PPA) you need to be able to build the binary package with the usual Debian/Ubuntu tools (dpkg-buildpackage)
[18:46] <frceego> yes, someone told that to me a few days ago. So, I quit the idea of using cpack and now I'm learning about debian/ubuntu tools ..
[18:47] <AmberJ> Any ideas why my 'debuild -uc -us' fails? all goes fine until I get this: http://pastebin.com/VqwrPZim
[18:48] <jtaylor> something is broken with the build, see line 19
[18:51] <AmberJ> jtaylor, Line 19 says: "cp: cannot stat `../../opencog-0.1/opencog/embodiment/Control/MessagingSystem/router': No such file or directory" ... But this file exists in the specified location
[18:51] <geser> if computed the relative path correctly based on this log then it tries to find a file /home/amberj/opencog-0.1/opencog/embodiment/Control/MessagingSystem/router
[18:52] <AmberJ> err..wait
[18:57] <AmberJ> I was wrong. The file exists instead at /home/amberj/dustbin/opencog-0.1/opencog/embodiment/Control/MessagingSystem
[18:57] <AmberJ> This has to do either with project's cmake or me messing with cmake's cache for the project.
[18:58] <AmberJ> Let me retry by doing a fresh checkout.. Once I'm done, I'll report here.
[19:04] <AmberJ> Thanks geser jtaylor
[19:17] <AmberJ> Is there a (de facto) standard way to create upstream tarballs?
[19:18] <tumbleweed> depends on the upstream
[19:18] <AmberJ> The project I'm working with does not provides upstream tar files atm. So, I typically checkout/branch the bazaar repo and use 'find' to recursively delete .bzr/
[19:19] <AmberJ> And then, tar the directory
[19:19] <tumbleweed> that works
[19:19] <tumbleweed> bzr has an export command btw
[19:20] <geser> can bzr export as a tar.gz too?
[19:20] <tumbleweed> AmberJ: there are a bunch of recipes in the old packaging guide: https://wiki.ubuntu.com/PackagingGuide
[19:20] <tumbleweed> geser: yes
[19:21] <AmberJ> tumbleweed, thanks, bzr's export was what I was looking for.
[21:05] <AmberJ> geser, jtaylor Just done with deb package... project's cmake config was fine; it seems I messed with cmake's cache last time
[22:21] <dupondje> Somebody around with some GTK coding knowledge ?
[22:41] <chrisccoulson> dupondje, sometimes it's better just to ask your question ;)
[22:41] <chrisccoulson> (and you might get a better response in #ubuntu-desktop)