denemo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Denemo-devel] latest linux binary?


From: Edgar Aichinger
Subject: Re: [Denemo-devel] latest linux binary?
Date: Mon, 29 Jan 2018 17:51:47 +0100

Just one more thing, I forgot to test the resulting Appimage before writing the previous mail this morning, and now that i did test I see it doesn't work...

This is the error I'm seeing in the terminal:

 

address@hidden:~/Downloads> ./denemo-1515000238.665198a92-Build21.1.glibc2.14-x86_64.AppImage
guile: uncaught throw to misc-error: (#f ~A ~S ~S ~S (No variable named %current-warning-port-fluid in #<module (guile) 2a76a00>) #f)
Cannot exit gracefully when init is in progress; aborting.

 

I will try to contact the OBS/appimage experts on IRC and tell here once I find out more.

 

Am Montag, 29. Januar 2018, 11:22:23 CET schrieb Edgar Aichinger:

> 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" <address@hidden> wrote:

> > >

> > > >

> > > > On January 22, 2018 at 9:18 PM Bric <address@hidden> wrote:

> > > >

> > > >

> > > > On January 22, 2018 at 1:48 PM Jeremiah Benham <address@hidden>

> > > > 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 < address@hidden>

> > > > 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

> > > > address@hidden

> > > > https://lists.gnu.org/mailman/listinfo/denemo-devel

> > > >

> > > >

> > > >

> > > >

> > > >

> > > > _______________________________________________ Denemo-devel mailing list

> > > > address@hidden https://lists.gnu.org/mailman/listinfo/denemo-devel

> > > >

> > > >

> > > >

> > > >

> > >

> >

> >

> >

> >

> >

> > _______________________________________________

> > Denemo-devel mailing list

> > address@hidden

> > https://lists.gnu.org/mailman/listinfo/denemo-devel

> >

>

>

>

>

>

> _______________________________________________

> Denemo-devel mailing list

> address@hidden

> https://lists.gnu.org/mailman/listinfo/denemo-devel

>

 

 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]