=== mapreri_ is now known as mapreri === AdmWiggin is now known as tianon [01:47] How do I get my game into the official Ubuntu software center? IS there a guide or blog about it? Thanks! I bet it's hard, but I hope I can do it some day. It's a free open source C++ game. [02:04] pifreak: the easiest way is to get it into the debian archive [02:04] then it is simply a matter of syncing it over to the Ubuntu archive [02:05] well, a few other paperwork things [02:08] :) [02:08] debian channels in general aren't here on freenode; they are on OFTC [02:15] But you think to get into the Ubuntu software center / apt-get Ubuntu repositories, it's doable as long as my software is stable? :D I for some reason assumed it's pretty regulated and they'd never take my software because I'm a noob [02:16] Thanks valorie! I will look into some debain guides and find a debian-specific IRC if I need further help with creating packages and such. I appreciate the advice! [02:16] great! [15:32] Hi all. I've been maintaining my own repo building software containing some of my own patches and modification. I have been following the "Debian New Maintainers' Guide" https://www.debian.org/doc/manuals/maint-guide/index.en.html. Since Ubuntu 18.04 I started experiencing some problems while building packages: [15:34] I am basically unpacking my archive, cd && dh_make -f ../ [15:38] then in the debian directory modifying control, changelog (sometimes rules) and finally running: dpkg-buildpackage .... what started happening is that the configure scripts started failing (after 18.04)... if I run the build manually ./configure && make ... everything works fine. [15:40] My question is: Is there any updated tutorial for building .deb packages (not interested in src. packages)? Any other hints and advice are more than welcome. [22:08] sgs: I think people are probably going to need to see a full transcript of exactly what you're doing and the failures in order to be able to help. The fundamentals of how to build binary packages haven't changed. [22:09] sgs: So it's probably something like missing build-dependencies or some kind of mistake in debian/rules or similar. [22:12] cjwatson: OK... In a nutshell I am building my own version of the sylpheed client. After running dh_make -f ... in debian/rules I have: [22:12] override_dh_auto_configure: [22:12] dh_auto_configure -- --prefix=/usr --disable-updatecheck --disable-updatecheckplugin [22:14] After 18.04 build fails with: [22:14] dh_auto_configure: ./configure --build=x86_64-linux-gnu --prefix=/usr --includedir=\${prefix}/include --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-silent-rules --libdir=\${prefix}/lib/x86_64-linux-gnu --libexecdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run --disable-maintainer-mode --disable-dependency-tracking --prefix=/usr [22:14] --disable-updatecheck --disable-updatecheckplugin returned exit code 2 [22:14] make[1]: *** [debian/rules:24: override_dh_auto_configure] Error 2 [22:15] As far as I can see, the "new arrival" is: --runstatedir=/run [22:17] sgs: Can you post the whole build log on paste.ubuntu.com? [22:17] It's true that debhelper in 18.04 passes --runstatedir=/run, but only in compat level 11; you would have had to specifically opt into this. [22:21] cjwatson: https://paste.ubuntu.com/p/rSJCCSXTVz/ [22:22] --runstatedir is not the problem here. [22:22] cjwatson: I don't understand what do you mean by compat level 11. I am sorry, but I am quite new into Debian/Ubuntu pkg. [22:22] The thing in debian/compat, which is documented in "man debhelper". [22:23] This is the actual problem: [22:23] ./configure: line 13484: syntax error near unexpected token `ac' [22:23] ./configure: line 13484: `SYLPHEED_ACLOCAL_INCLUDE(ac)' [22:23] cjwatson: When I build sylpheed manually ./configure ...etc --runstatedir=/run is the only option it doesn't recognize. [22:24] Translating: your debian/rules runs autoreconf (because debhelper does that automatically as of compat level 10), but you don't have the right build-dependencies for it to be able to regenerate the build system. [22:24] Irrelevant, you're changing too many variables there so that's not a valid test. [22:25] (Specifically you evidently didn't run autoreconf first ...) [22:26] Let's see, just investigating [22:28] To fix this particular bug I think you need to add this to debian/rules, to make sure that autoreconf picks up sylpheed's local autoconf bits: [22:28] override_dh_autoreconf: [22:28] dh_autoreconf ./autogen.sh [22:28] Note that the second line should begin with a hard tab character, not eight spaces, since debian/rules is a Makefile [22:29] You may of course run into some other problem later. Is there some reason you aren't sticking with the presumably tried-and-tested packaging in the sylpheed source package, even if you need to change some bit of it? [22:29] OK... [22:30] If you aren't familiar with packaging, then trying to do it all yourself isn't a recipe for success. [22:30] Or at least is a recipe for having to read a lot of documentation. [22:30] dh_make is for when you need to package something that nobody else has packaged before, not for when you need to make some relatively minor tweak to an existing package. [22:31] In other words, while we can probably help to fix the specific things you're running into, it sounds like you're going about the whole thing the wrong way. [22:33] cjwatson: The problem is that Ubuntu / Debian are still packaging 3.5.1 which is quite old. [22:33] Sure, but you really do not have to completely redo the packaging from scratch in order to upgrade to a new upstream version. [22:33] And in fact you should not. [22:34] Running dh_make is saying "there is absolutely nothing of value in the existing packaging and I know better". [22:34] But in fact you don't know better since you said you're new to this :-) [22:34] You'd be better off transplanting the packaging parts (i.e. debian/*) from the existing source package, and massaging them as necessary for the new upstream version. [22:35] You might have to e.g. adjust and/or drop some of the patches a bit. But still better than entirely throwing away the existing packaging. [22:39] cjwatson: Sure. I'll do that. [22:43] dh_autoreconf ./autogen.sh [22:43] ./autogen.sh: 6: ./autogen.sh: aclocal-1.14: not found [22:43] dh_autoreconf: ./autogen.sh returned exit code 127 [22:45] Ah right, I guess maybe "dh_autoreconf autoreconf -- -fi -I ac" would work better in that case. [22:45] But I still think this is the wrong approach. [22:46] (Upstream's autogen.sh hardcodes a particular version of Automake that was superseded in 2014, for some reason.) [23:01] cjwatson: It worked :) Thank you so much for your time. :) [23:11] np