[01:47] <pifreak> 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] <valorie> pifreak: the easiest way is to get it into the debian archive
[02:04] <valorie> then it is simply a matter of syncing it over to the Ubuntu archive
[02:05] <valorie> well, a few other paperwork things
[02:08] <pifreak> :)
[02:08] <valorie> debian channels in general aren't here on freenode; they are on OFTC
[02:15] <pifreak> 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] <pifreak> 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] <valorie> great!
[15:32] <sgs> 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] <sgs> I am basically unpacking my archive, cd <package> && dh_make -f ../<archive>
[15:38] <sgs> then in the debian directory modifying control, changelog (sometimes rules) and finally running: dpkg-buildpackage <some options> .... 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] <sgs> 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] <cjwatson> 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] <cjwatson> sgs: So it's probably something like missing build-dependencies or some kind of mistake in debian/rules or similar.
[22:12] <sgs> 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] <sgs> override_dh_auto_configure:
[22:12] <sgs>     dh_auto_configure -- --prefix=/usr --disable-updatecheck --disable-updatecheckplugin
[22:14] <sgs> After 18.04 build fails with:
[22:14] <sgs> 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] <sgs> --disable-updatecheck --disable-updatecheckplugin returned exit code 2
[22:14] <sgs> make[1]: *** [debian/rules:24: override_dh_auto_configure] Error 2
[22:15] <sgs> As far as I can see, the "new arrival" is: --runstatedir=/run
[22:17] <cjwatson> sgs: Can you post the whole build log on paste.ubuntu.com?
[22:17] <cjwatson> 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] <sgs> cjwatson: https://paste.ubuntu.com/p/rSJCCSXTVz/
[22:22] <cjwatson> --runstatedir is not the problem here.
[22:22] <sgs> 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] <cjwatson> The thing in debian/compat, which is documented in "man debhelper".
[22:23] <cjwatson> This is the actual problem:
[22:23] <cjwatson> ./configure: line 13484: syntax error near unexpected token `ac'
[22:23] <cjwatson> ./configure: line 13484: `SYLPHEED_ACLOCAL_INCLUDE(ac)'
[22:23] <sgs> cjwatson: When I build sylpheed manually ./configure ...etc --runstatedir=/run is the only option it doesn't recognize.
[22:24] <cjwatson> 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] <cjwatson> Irrelevant, you're changing too many variables there so that's not a valid test.
[22:25] <cjwatson> (Specifically you evidently didn't run autoreconf first ...)
[22:26] <cjwatson> Let's see, just investigating
[22:28] <cjwatson> 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] <cjwatson> override_dh_autoreconf:
[22:28] <cjwatson>         dh_autoreconf ./autogen.sh
[22:28] <cjwatson> Note that the second line should begin with a hard tab character, not eight spaces, since debian/rules is a Makefile
[22:29] <cjwatson> 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] <sgs> OK...
[22:30] <cjwatson> If you aren't familiar with packaging, then trying to do it all yourself isn't a recipe for success.
[22:30] <cjwatson> Or at least is a recipe for having to read a lot of documentation.
[22:30] <cjwatson> 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] <cjwatson> 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] <sgs> cjwatson: The problem is that Ubuntu / Debian are still packaging 3.5.1 which is quite old.
[22:33] <cjwatson> 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] <cjwatson> And in fact you should not.
[22:34] <cjwatson> Running dh_make is saying "there is absolutely nothing of value in the existing packaging and I know better".
[22:34] <cjwatson> But in fact you don't know better since you said you're new to this :-)
[22:34] <cjwatson> 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] <cjwatson> 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] <sgs> cjwatson: Sure. I'll do that.
[22:43] <sgs> dh_autoreconf ./autogen.sh
[22:43] <sgs> ./autogen.sh: 6: ./autogen.sh: aclocal-1.14: not found
[22:43] <sgs> dh_autoreconf: ./autogen.sh returned exit code 127
[22:45] <cjwatson> Ah right, I guess maybe "dh_autoreconf autoreconf -- -fi -I ac" would work better in that case.
[22:45] <cjwatson> But I still think this is the wrong approach.
[22:46] <cjwatson> (Upstream's autogen.sh hardcodes a particular version of Automake that was superseded in 2014, for some reason.)
[23:01] <sgs> cjwatson: It worked :) Thank you so much for your time. :)
[23:11] <cjwatson> np