[04:19] cyphermox: that freecad upload could've been another no change rebuild to fix the changelog entry [04:20] cyphermox: I meant build2 vs ubuntu1 :) [04:21] micahg: He knows. It was an accident. [04:21] ScottK: was looking for scrollback and didn't see any [04:21] It was a PM. [04:22] ok === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [07:06] good morning [07:07] good morning! :) [07:32] Morning dholbach. [07:37] hey iulian [09:43] 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] i reckon you guys are the perfect ones to answer this question ^^ === mitya57_ is now known as mitya57 === ara is now known as Guest64238 === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [12:58] 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] muelli: .orig tarball should be downloaded from upstream, you shouldn't change or regenerate it [13:19] if svn-buildpackage doesn't work, you can unpack upstream and your source into one directory [13:19] cd there and run debuild [13:24] mitya57: I *have* already downloaded the SVN repository. So all the sources are there. [13:26] muelli: if the upstream svn contains debian directory, the package should be native instead [13:26] so, you need to change debian/source/format to "3.0 (native)" and [13:26] well, that shows 3.0 (quilt) [13:26] drop "-0" prefix from the first (from top) entry in debian/changelog [13:27] muelli: change "quilt" to "native" [13:27] this is the most simpliest solution, [13:28] you won't have to deal with separate .orig and .debian tarballs [13:28] *the most simple [13:28] mitya57: alright. Sounds good. thank you very much. [13:29] you are welcome [13:29] Still a bit annoying. I presume, I can convince dpkg-source to just assume the format to be native. [13:30] and quilt format would indicate there to be patches/ directory and a series file, is that correct? [13:30] dpkg-source is for generating .dsc files [13:31] quilt format is the most common format, it supports debian/patches but doesn't require that [13:35] 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] just modify in place [13:36] are you going to just build that package for yourself, or upload it somewhere? [13:39] 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] in any case you'll have to modify that manually (or manually build the tarball, if you leave the format unmodified) [13:40] every time the upstream changes [13:41] thanks for your help so far. Highly appreciated. [13:42] 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] ah, my ~/.dput.cf has method sftp, while the dput -f does ftp *thinking* [13:44] my .dput.cf has ftp [13:44] it's anyway secure because it checks your pgp key on server side [13:45] and I do just "dput my-ppa PKGNAME_VERSION_source.changes" [13:45] 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] I have to go out, sorry === jbicha is now known as Guest70781 === Guest70781 is now known as jbicha_ [15:11] Hi all! [15:18] is gir1.2-gjsdbus-1.0 still needed in 12.10? [16:09] Hello [16:10] I'm trying to create package(s) for OpenCog using instructions on ubuntu wiki.. [16:11] When I run 'debuild -uc -us', all goes fine until I get this: http://pastebin.com/VqwrPZim [16:11] Line 19 is where some errors start to pop up... [16:14] .deb packages for opencog don't exist. I'm starting from scratch [16:19] 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] Also, opencog uses cmake and I didn't made any changes to debian/rules (autogenerated by 'bzr dh-make'). [16:31] 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 === jacob_ is now known as jacob === Pici is now known as Guest55530 === Pici` is now known as Pici [18:02] bug 700036 [18:02] Launchpad bug 700036 in blcr (Ubuntu Natty) "package blcr-dkms 0.8.2-15ubuntu1 failed to install/upgrade: blcr kernel module failed to build - error: ‘struct signal_struct’ has no member named ‘count’" [High,Triaged] https://launchpad.net/bugs/700036 [18:02] just wanted the title, lp times out in the browser [18:05] reloading often works when bits of lp timeout. If the relevant bits of table are in RAM, it may not timeout [18:07] does not help :/ those blcr bugs almost always time out, probably because of the hundreds of dupes [18:08] opened for me, first time [18:08] oh, also for bugs, .../+text [18:09] strange [18:09] a +text works [18:09] thx [18:26] Hello [18:29] How common (and difficult) is it to create multiple packages from a single version controlled repo of a project that uses cmake? [18:30] The project has many component programs many of which can serve as independent program/libraries. [18:30] But they are all tied under a single cmake project using top-level CMakeLists.txt file. [18:31] you build multiple source packages? [18:31] SpamapS, re Bug #1003465, do I still need all that information with a microrelease SRU ? [18:31] Launchpad bug 1003465 in empathy (Ubuntu) "SRU request for bug fix release 3.4.2.1" [Wishlist,New] https://launchpad.net/bugs/1003465 [18:32] a source package can have multiple binary packages [18:32] The code for the complete project is in a single upstream source package. [18:33] bcurtiswx: I don't see a micro release exception for empathy here: https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions [18:33] bcurtiswx: so yes. At least you need to discuss the risk of regression created by introducing all of the changes. [18:34] 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] 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] you're using cmake to build the package? [18:36] SpamapS, hmm I thought there was some exception with GNOME packages and microreleases [18:36] yes jtaylor [18:36] I'm not familiar with that [18:36] ok [18:36] multiple binary packages from one source is possible (and normal), but no idea if cmake supports it [18:37] bcurtiswx: none that I see. [18:37] bcurtiswx: I think in practice, a lot of them have been waved through [18:39] 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] SpamapS, hmm. OK. Thanks [18:39] yes but how to teach that to cmake? [18:40] or cpack in this case [18:41] 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] that requires modifying debian/ [18:41] I guess what is wanted is automated debian packaging from cmake [18:42] jtaylor: sorry, if I was not clear. I'm NOT using cpack. All I do is use cmake to build project. [18:42] to build a proper package you need files in debian/ anyways [18:43] geser: I'm not sure about that cpack can output to debs and rpms [18:43] I don't thnk you need a debian dir for that [18:44] I don't know about cpack, so can't comment on it [18:44] frceego: in that case do what geser said [18:44] yes. noted. [18:45] 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] 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] Any ideas why my 'debuild -uc -us' fails? all goes fine until I get this: http://pastebin.com/VqwrPZim [18:48] something is broken with the build, see line 19 [18:51] 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] 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] err..wait [18:57] I was wrong. The file exists instead at /home/amberj/dustbin/opencog-0.1/opencog/embodiment/Control/MessagingSystem [18:57] This has to do either with project's cmake or me messing with cmake's cache for the project. [18:58] Let me retry by doing a fresh checkout.. Once I'm done, I'll report here. [19:04] Thanks geser jtaylor [19:17] Is there a (de facto) standard way to create upstream tarballs? [19:18] depends on the upstream [19:18] 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] And then, tar the directory [19:19] that works [19:19] bzr has an export command btw [19:20] can bzr export as a tar.gz too? [19:20] AmberJ: there are a bunch of recipes in the old packaging guide: https://wiki.ubuntu.com/PackagingGuide [19:20] geser: yes [19:21] tumbleweed, thanks, bzr's export was what I was looking for. === yofel_ is now known as yofel [21:05] geser, jtaylor Just done with deb package... project's cmake config was fine; it seems I messed with cmake's cache last time === highvolt1ge is now known as highvoltage [22:21] Somebody around with some GTK coding knowledge ? [22:41] dupondje, sometimes it's better just to ask your question ;) [22:41] (and you might get a better response in #ubuntu-desktop) === jbicha_ is now known as jbicha