=== mapreri_ is now known as mapreri | ||
=== AdmWiggin is now known as tianon | ||
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. | 01:47 |
---|---|---|
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:04 |
valorie | well, a few other paperwork things | 02:05 |
pifreak | :) | 02:08 |
valorie | debian channels in general aren't here on freenode; they are on OFTC | 02:08 |
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:15 |
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! | 02:16 |
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:32 |
sgs | I am basically unpacking my archive, cd <package> && dh_make -f ../<archive> | 15:34 |
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:38 |
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. | 15:40 |
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:08 |
cjwatson | sgs: So it's probably something like missing build-dependencies or some kind of mistake in debian/rules or similar. | 22:09 |
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:12 |
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:14 |
sgs | As far as I can see, the "new arrival" is: --runstatedir=/run | 22:15 |
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:17 |
sgs | cjwatson: https://paste.ubuntu.com/p/rSJCCSXTVz/ | 22:21 |
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:22 |
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:23 |
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:24 |
cjwatson | (Specifically you evidently didn't run autoreconf first ...) | 22:25 |
cjwatson | Let's see, just investigating | 22:26 |
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:28 |
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:29 |
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:30 |
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:31 |
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:33 |
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:34 |
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:35 |
sgs | cjwatson: Sure. I'll do that. | 22:39 |
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:43 |
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:45 |
cjwatson | (Upstream's autogen.sh hardcodes a particular version of Automake that was superseded in 2014, for some reason.) | 22:46 |
sgs | cjwatson: It worked :) Thank you so much for your time. :) | 23:01 |
cjwatson | np | 23:11 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!