Hello again, I've made progress this morning, and an Appimage from latest git is available now, with correct version numbers, while the rpms still are built from the release tarball. I had forgotten to enable the appmage service in OBS, thus no git sources... guess I needed some sleep.
Same URL: https://download.opensuse.org/repositories/home:/edogawa/AppImage/ Jeremiah, if you need help in fixing the current conflict in your branch, tell me... there is a commandline program to interact with OBS, called osc and it can resolve this. Or delete and re-branch, or as I said, detach your branch by either also using osc or removing the file _link, shown when displaying "unmerged sources". Cheers, Edgar Am Sonntag, 28. Januar 2018, 18:02:53 CET schrieb Edgar Aichinger: > Am Samstag, 27. Januar 2018, 13:37:21 CET schrieb Jeremiah Benham: > > I am working on getting a AppImage built of denemo here: > > https://build.opensuse.org/package/show/home:jjbenham:branches:home:edogawa/denemo > > > > It all compiles but it chokes installing the .png and .desktop files into > > the appimage directory. Maybe you can help out by looking for other > > examples of what others have done. I need some guidance here. I may need to > > ask on the forums or irc or something. > > > > Jeremiah > > I'm sorry to join this discussion late, but today finally I found a bit time > to look at this. > > I see your denemo package on OBS is branched from mine, and heavily modified > just to create the Appimage from latest git. > Now today I tried and in turn copied your appimage.yml to my package, which > lead to a new bunch of problems due to the link relationship between our two > packages... > Any changes I make in my package that are incompatible to yours make your > branch appear broken. BTW, You can detach your branch by deleting the _link > file from the package sources. > > As I don't want to get rid of the release version in my package, and after a > few trials cannot seem to find a way to get and extract the git sources for > the appimage, I decided to try with the release tarball for now. In > appimage.yml I have commented the references to git, and modified the script > section so that ./autogen.sh is omitted. > > I think the linuxdeployqt command cares for all the .desktop file stuff > except the icon location, so I copy pixmaps/denemo.png into $BUILD_APPDIR and > that made it generate the appimage. I think that's the step your yml is > missing. > > There are quite a few oddities going on though, e.g. the way to change into > the extracted source dir, or why it ends up with a packagename > denemo-0-Buildxx instead of 2.0.14 in my case. I cannot ivest more time right > now, but I thought I should let you knowabout my findings and hope this is > useful. > > Maybe we should think about how to cooperate better in OBS, I'm not exactly > an expert but I use it since some years and understand quite some of it. For > example you could make me maintainer in your branch, or we could set up a new > project called e.g. home:denemo with separate packages for release and git > builds, quite some applications use a scheme like that, see e.g. > home:Entropytuner. > > So to summarize my work from today: > The appimage I was able to generate (from 2.0.14) is here: > https://download.opensuse.org/repositories/home:/edogawa/AppImage/ > > my denemo package is being built at > https://build.opensuse.org/package/show/home:edogawa/denemo > (IIRC you need to log in to read the build logs) > > > > > > > On Jan 26, 2018 7:51 PM, "Bric" <b...@flight.us> wrote: > > > > > > > > On January 22, 2018 at 9:18 PM Bric <b...@flight.us> wrote: > > > > > > > > > On January 22, 2018 at 1:48 PM Jeremiah Benham <jeremiahben...@gmail.com> > > > wrote: > > > > > > I see this also integrates with OBS and travis. Travis, is that what our > > > testing system is called? Where and how is travis being run? > > > > > > Jeremiah > > > > > > > > > > > > :~$ sudo apt-get build-dep denemo > > > Reading package lists... Done > > > Building dependency tree > > > Reading state information... Done > > > The following packages have unmet dependencies: > > > libevince-dev : Depends: libgtk-3-dev (>= 3.8.0) but it is not going to > > > be installed > > > libgtk2.0-dev : Depends: libpango1.0-dev (>= 1.20) but it is not going to > > > be installed > > > Depends: libcairo2-dev (>= 1.6.4-6.1) but it is not going > > > to be installed > > > libgtksourceview-3.0-dev : Depends: libgtk-3-dev (>= 3.10) but it is not > > > going to be installed > > > librsvg2-dev : Depends: libcairo2-dev (>= 1.2.0) but it is not going to > > > be installed > > > > > > > > > Guess there's no prospect/hope to get a 64-bit binary? > > > > > > > > > > > > .... sucks. > > > > > > > > > > > > On Mon, Jan 22, 2018 at 11:46 AM, Richard Shann < rich...@rshann.plus.com> > > > wrote: > > > > > > On Mon, 2018-01-22 at 10:05 -0600, Jeremiah Benham wrote: > > > > I am reading up on how to use AppImage. I don't know how long it will > > > > take but it will be better than what we currently have. > > > > > > That looks promising - I've long thought that the old unix model of > > > shared libraries for every program has been left behind by cheaper > > > memory storage. > > > > > > Richard > > > > > > > > > ______________________________ _________________ > > > Denemo-devel mailing list > > > Denemo-devel@gnu.org > > > https://lists.gnu.org/mailman/listinfo/denemo-devel > > > > > > > > > > > > > > > > > > _______________________________________________ Denemo-devel mailing list > > > Denemo-devel@gnu.org https://lists.gnu.org/mailman/listinfo/denemo-devel > > > > > > > > > > > > > > > > > > > > _______________________________________________ > Denemo-devel mailing list > Denemo-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/denemo-devel > _______________________________________________ Denemo-devel mailing list Denemo-devel@gnu.org https://lists.gnu.org/mailman/listinfo/denemo-devel
