it was present in mageia 1 and then removed, iirc it is not maintained anymore by upstream, and as you can see here: https://bugs.mageia.org/buglist.cgi?quicksearch=ALL%20f-spot&list_id=14131 there was some bugs

Resolution: (none) => WONTFIX
Status: NEW => RESOLVED

if it's not maintained anymore by upstream, is there an alternative?

and afaict, it was still in mga2.

if upstream is dead, then wontfix is ok, but maybe an alternative would be nice to know.

CC: (none) => alien

shotwell ?

f-spot isn't dead yet. Mostly dead right now, but I'm still working on it and have a hackfest coming up in October. In fact, we have had 2 gsoc students adding two new features. Integrated ability to edit RAW outside of f-spot (have f-spot consume the result) and tagging faces in f-spot. I'm not sure if the face recognition stuff was completely finished.

CC: (none) => sshaw

thanks for the comment...

i'm afraid we've had some bugs on our own, and not a package maintainer to follow up on them.

after seeing the huge number of open bugs and last code commit being may (not counting translations), it looked like it was dead-ish.

since it isn't dead, it can possibly be revived on Mageia if we have a package maintainer for it. ie: a contact person for the bugs and someone to handle the packaging... since this is still on our svn, the packaging will not likely be the biggest problem.

if anyone is willing to step up, grab this package, fix it's bugs (and/or speak with upstream), then i'm sure it can be revived.

(In reply to Stephen Shaw from comment #4)
> f-spot isn't dead yet. Mostly dead right now, but I'm still working on it
> and have a hackfest coming up in October. In fact, we have had 2 gsoc
> students adding two new features. Integrated ability to edit RAW outside of
> f-spot (have f-spot consume the result) and tagging faces in f-spot. I'm not
> sure if the face recognition stuff was completely finished.

Thx, so reopening this ticket.

It'll be for cauldron, though, if someone grabs it.

I don't think it is useful to reopen the Mageia 2 f-spot bugs, because Mageia 2's EOL will be end of November.

Severity: normal => enhancement
Version: 3 => Cauldron
Resolution: WONTFIX => (none)
Source RPM: (none) => f-spot
Status: RESOLVED => REOPENED
CC: (none) => marja11

I took a look at this and created a libtoolized tarball from current git master.

It now configures OK but build fails:
http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/cauldron/x86_64/core/release/log/f-spot-0.9.0-0.6551.1.mga4.src.rpm/build.0.20130918233557.log

If anyone can figure it out, my current (WIP) SRPM is here:
http://mtf.no-ip.co.uk/pub/linux/barjac/tests/f-spot-0.9.0-0.6551.1.mga4.src.rpm

It probably needs an upstream bug report.

CC: (none) => zen25000

(In reply to Barry Jackson from comment #7)
> I took a look at this and created a libtoolized tarball from current git
> master.
> 
> It now configures OK but build fails:
> http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/cauldron/x86_64/core/release/
> log/f-spot-0.9.0-0.6551.1.mga4.src.rpm/build.0.20130918233557.log
> 
> If anyone can figure it out, my current (WIP) SRPM is here:
> http://mtf.no-ip.co.uk/pub/linux/barjac/tests/f-spot-0.9.0-0.6551.1.mga4.src.
> rpm
> 
> It probably needs an upstream bug report.

This is an issue I've faced as well trying to compile from sources. There are a couple of changes required on the Makefiles and csproj (to declare the Mono.Cairo version 4.0.0 in the project files). I have been trying to find some time to work on a pull request and proper patch on 0.8.2. (Also would require an update of mono-flickrnet)

CC: (none) => nguyen.matthieu

i see lots of obsoleteness

FSpot.Exporters.Flickr/FlickrRemote.cs(60,16): error CS0246: The type or namespace name `LicenseCollection' could not be found. Are you missing an assembly reference?

^^ this looks like you're missing a package that gives LicenseCollection . well, perhaps you could remove flickr export? or find something that supplies this LicenseCollection...

LicenseCollection was added in the FlickrNet 3.0 API. So the Flickr Export plugin in F-Spot needs to be ported to the 3.0 API. Furthermore, Flickr recently changed their API URLS to use https-only, and flickrnet-3.13 is required in order to take the change into account...

Hi all⦠

what about asking/telling the F-spot mailing list⦠if there is something wrong, the dev's may like to know â¦

(In reply to Benjamin Leduc from comment #11)
> Hi all⦠
> 
> what about asking/telling the F-spot mailing list⦠if there is something
> wrong, the dev's may like to know â¦

Incidentally, Stephen Shaw (Comment #4) is the lead, and I've been trying for some months to devote time to become a maintainer of F-Spot as well (mainly because I don't want to have to redo cataloguing and migrating a 25k pics library to another program). So... the devs are aware :)

For FlickrNet, I had opened a Bugzilla on mageia to request a backport of mono-flickrnet-3 over here: https://bugs.mageia.org/show_bug.cgi?id=12778

Hi. Small update. I've talked to Stephen Shaw. You should take your sources from https://github.com/mono/f-spot rather than git.gnome.org

I have a couple of pull requests there that are pending approval, and that should fix the compilation issues you had (I'm using MGA4 so I ran into the same compilation problems you did)

(In reply to Matthieu Nguyen from comment #13)
> Hi. Small update. I've talked to Stephen Shaw. You should take your sources
> from https://github.com/mono/f-spot rather than git.gnome.org
> 
> I have a couple of pull requests there that are pending approval, and that
> should fix the compilation issues you had (I'm using MGA4 so I ran into the
> same compilation problems you did)

I took a snapshot from your branch which I guess has your pull request changes in it and attempted to build a package using the temporary mono-flickrnet-3.13.0 package made from the binaries from upstream:

http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/cauldron/x86_64/log/f-spot-0.9.0-0.6606.1.mga5.src.rpm/build.0.20140722231032.log

Any ideas?

You need to apply the Hyena patch after the autogen.sh:

patch -p1 < external.patch

before running make.

Created attachment 5309 [details]
build log

I'm currently using a tarball created from your git branch on which autogen.sh has been run with NOCONFIGURE=1, so that configure can be run during package build as normal.

The tarball is extracted in the package build and then patches are applied which is before configure.

Are you saying that the patch needs to be applied after configure? This would be the case if it was applied after autogen.sh without the NOCONFIGURE option.

Either way, on testing this I still get the same errors with or without the hyena patch when building for either Mga4 or for Cauldron.

(I re-diffed the patch after manually applying the changes as the original would not apply despite my best efforts ;)

Is that normal that patch have to be applied on a git tarball?

(In reply to Barry Jackson from comment #16)
> Created attachment 5309 [details]
> build log
> 
> I'm currently using a tarball created from your git branch on which
> autogen.sh has been run with NOCONFIGURE=1, so that configure can be run
> during package build as normal.
> 
> The tarball is extracted in the package build and then patches are applied
> which is before configure.
> 
> Are you saying that the patch needs to be applied after configure? This
> would be the case if it was applied after autogen.sh without the NOCONFIGURE
> option.
> 
> Either way, on testing this I still get the same errors with or without the
> hyena patch when building for either Mga4 or for Cauldron.
> 
> (I re-diffed the patch after manually applying the changes as the original
> would not apply despite my best efforts ;)

Actually, my mistake. The patch has to be applied *before* configure, since it also impacts the Makefile.am, so you need the patch before the makefiles are generated.

The Hyena.Gui/Makefile should have the following line if the patching happened properly (note the sdk:4 flag):

ASSEMBLY_BUILD_FLAGS = -unsafe -sdk:4

(In reply to Benjamin Leduc from comment #17)
> Is that normal that patch have to be applied on a git tarball?

This is only a temporary solution, because f-spot makes a reference to a git submodule that has compilation problems with mageia 4 (and the patch is part of the tarball). It is intended to not need the patch anymore once transition to gtk3 will be complete and the submodule version can be updated to latest. I wanted to have the patch executed by autogen.sh itself, just didn't have time to put the change in yet... :/

Created attachment 5310 [details]
hyena patch

No, that Makefile just has:
ASSEMBLY_BUILD_FLAGS = -unsafe
which is what is in the Makefile.in/am files.

Just to be sure that we are not at cross purposes I am attaching the hyena patch that I am using, which is a re-diff of https://raw.githubusercontent.com/GNOME/f-spot/master/hyena.patch

(In reply to Barry Jackson from comment #19)
> Created attachment 5310 [details]
> hyena patch
> 
> No, that Makefile just has:
> ASSEMBLY_BUILD_FLAGS = -unsafe
> which is what is in the Makefile.in/am files.
> 
> Just to be sure that we are not at cross purposes I am attaching the hyena
> patch that I am using, which is a re-diff of
> https://raw.githubusercontent.com/GNOME/f-spot/master/hyena.patch

Yeah, that doesn't look like it's coming from my branch :).

Here's what I put in my pull request and is pending approval by the lead dev: https://github.com/NguyenMatthieu/f-spot/blob/master/external.patch

Created attachment 5313 [details]
mk-tar script

OK now we have the correct patch.

However it still does not create a Makefile with:
 ASSEMBLY_BUILD_FLAGS = -unsafe -sdk:4

The above does appear in the Makefile.am

I see these Makefile* files in Hyena.Gui (after configure and build fail):

Makefile                   ASSEMBLY_BUILD_FLAGS = -unsafe
Makefile.am                ASSEMBLY_BUILD_FLAGS = -unsafe -sdk:4
Makefile.am.0000           ASSEMBLY_BUILD_FLAGS = -unsafe
Makefile.in                ASSEMBLY_BUILD_FLAGS = -unsafe

To confirm that the source tarball is not the issue, I am attaching the script I use to create it.

Attachment 5310 is obsolete: 0 => 1

(In reply to Barry Jackson from comment #21)
> Created attachment 5313 [details]
> mk-tar script
> 
> OK now we have the correct patch.
> 
> However it still does not create a Makefile with:
>  ASSEMBLY_BUILD_FLAGS = -unsafe -sdk:4
> 
> The above does appear in the Makefile.am
> 
> I see these Makefile* files in Hyena.Gui (after configure and build fail):
> 
> Makefile                   ASSEMBLY_BUILD_FLAGS = -unsafe
> Makefile.am                ASSEMBLY_BUILD_FLAGS = -unsafe -sdk:4
> Makefile.am.0000           ASSEMBLY_BUILD_FLAGS = -unsafe
> Makefile.in                ASSEMBLY_BUILD_FLAGS = -unsafe
> 
> To confirm that the source tarball is not the issue, I am attaching the
> script I use to create it.

That's odd. The Makefile.in should be generated from the Makefile.am. I'll check what the autogen.sh is doing...

Hang on please re-read #18 :)

I don't see how the hyena patch can have any effect on the Makefile if the Makefile is created by autogen.sh, since the patch is applied *after* autogen.sh is run.
It cannot be applied before, IIUC  since the files to patch do not exist at that time. (as I have discovered) :\

(In reply to Barry Jackson from comment #24)
> I don't see how the hyena patch can have any effect on the Makefile if the
> Makefile is created by autogen.sh, since the patch is applied *after*
> autogen.sh is run.
> It cannot be applied before, IIUC  since the files to patch do not exist at
> that time. (as I have discovered) :\

Well, if you run autogen.sh with NOCONFIGURE then it shouldn't run the configure script, which is what creates the Makefile. So that should have worked.

Anyways, looks like the solution is to have the patch applied inside the autogen.sh itself, rather than after it. (Or, as a workaround, I suppose that running autogen.sh once, applying the patch, then running autogen.sh should do the trick, but this is starting to look reaaaaal ugly).

I'll update as soon as I have the code ready.

I did try running autogen.sh in the spec, but then it... - Ah... I just realized why that failed. It was looking for .git but I had stripped it when making the tarball with --exclude-vcs :\
I may try that again tomorrow ;)

(In reply to Barry Jackson from comment #26)
> I did try running autogen.sh in the spec, but then it... - Ah... I just
> realized why that failed. It was looking for .git but I had stripped it when
> making the tarball with --exclude-vcs :\
> I may try that again tomorrow ;)

All right, I updated my master so that now the patch applies itself as part of the autogen.sh, right after the external git submodules are fetched. Things should work better now :)

OK good, now I see ASSEMBLY_BUILD_FLAGS = -unsafe -sdk:4 is now in Makefile after configure, however build still fails.

Initial test show lots of warnings but only one error:

FSpot/GroupSelector.cs(466,4): error CS0171: Field `FSpot.GroupSelector.Box.bar' must be fully assigned before control leaves the constructor

All build logs:
http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/cauldron/x86_64/log/f-spot-0.9.0-0.6610.1.mga5.src.rpm/

(Now using mono-flickrnet from repos :)

A build for Mga4 gets further, but chokes on lcms undefined symbols even when using lcms2 later version from Cauldron :\

http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/4/x86_64/log/f-spot-0.9.0-0.6610.1.mga4.src.rpm/build.0.20140724110024.log

(In reply to Barry Jackson from comment #29)
> A build for Mga4 gets further, but chokes on lcms undefined symbols even
> when using lcms2 later version from Cauldron :\
> 
> http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/4/x86_64/log/f-spot-0.9.0-0.
> 6610.1.mga4.src.rpm/build.0.20140724110024.log

(In reply to Barry Jackson from comment #28)
> OK good, now I see ASSEMBLY_BUILD_FLAGS = -unsafe -sdk:4 is now in Makefile
> after configure, however build still fails.
> 
> Initial test show lots of warnings but only one error:
> 
> FSpot/GroupSelector.cs(466,4): error CS0171: Field
> `FSpot.GroupSelector.Box.bar' must be fully assigned before control leaves
> the constructor
> 
> All build logs:
> http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/cauldron/x86_64/log/f-spot-0.
> 9.0-0.6610.1.mga5.src.rpm/
> 
> (Now using mono-flickrnet from repos :)

The warnings are (unfortunately) normal. Much code cleanup still needs to be done (but the first priority is to get the soft back in the repos and try to get some traction, I think...)

I updated my branch for the GroupSelector.cs issue.

Not sure about the lcms2 problem, need to talk with Stephen, he mentioned to me that git/master had been updated to work with the latest lcms2 versions...

OK getting further.
Now we have a Flickrnet problem.

http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/cauldron/x86_64/log/f-spot-0.9.0-0.6612.1.mga5.src.rpm/build.0.20140724120130.log

(In reply to Barry Jackson from comment #31)
> OK getting further.
> Now we have a Flickrnet problem.
> 
> http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/cauldron/x86_64/log/f-spot-0.
> 9.0-0.6612.1.mga5.src.rpm/build.0.20140724120130.log

/usr/lib/mono/4.5/Microsoft.Common.targets:  warning : Reference 'FlickrNet, Version=3.13.0.0, Culture=neutral, PublicKeyToken=2491df59efa5d132' not resolved

After installing the new mono-flickrnet package, the reference should be resolved, that's odd.

What does gacutil say? It should says this:

$ gacutil -l FlickrNet
The following assemblies are installed into the GAC:
FlickrNet, Version=3.13.0.0, Culture=neutral, PublicKeyToken=2491df59efa5d132
Number of items = 1

baz@localhost ~]$ gacutil -l FlickrNet
The following assemblies are installed into the GAC:
FlickrNet, Version=3.5.0.0, Culture=neutral, PublicKeyToken=2491df59efa5d132
Number of items = 1

[baz@localhost ~]$ rpm -q mono-flickrnet
mono-flickrnet-3.13.0-1.mga5
[baz@localhost ~]$

Hmm. so does this mean there is a bug in the mono-flickrnet package in the repo since it's showing a different version?

I'm guessing that you have the version of mono-flickrnet I made from the upstream binaries that I linked to?
I am now using the package that is built from sources and is in the repo. Unfortunately it has the same name and version so to install it you would need to:
su
urpmi.update -a
urpme mono-flickrnet && urpmi mono-flickrnet

(In reply to Barry Jackson from comment #33)
> baz@localhost ~]$ gacutil -l FlickrNet
> The following assemblies are installed into the GAC:
> FlickrNet, Version=3.5.0.0, Culture=neutral, PublicKeyToken=2491df59efa5d132
> Number of items = 1
> 
> [baz@localhost ~]$ rpm -q mono-flickrnet
> mono-flickrnet-3.13.0-1.mga5
> [baz@localhost ~]$
> 
> Hmm. so does this mean there is a bug in the mono-flickrnet package in the
> repo since it's showing a different version?
> 
> I'm guessing that you have the version of mono-flickrnet I made from the
> upstream binaries that I linked to?
> I am now using the package that is built from sources and is in the repo.
> Unfortunately it has the same name and version so to install it you would
> need to:
> su
> urpmi.update -a
> urpme mono-flickrnet && urpmi mono-flickrnet

Yup, sounds like a bug in the new mono-flickrnet package. I still have the one from the binaries, yes (not using Cauldron so I used the direct link in the other bug report)

Created attachment 5314 [details]
build log

Yes.
Using the version you have it reports 3.13.0 and the build of f-spot now gets to the lcms errors in Cauldron. (Attached)

Attachment 5309 is obsolete: 0 => 1

Are you only getting the lcms error in Cauldron? I am not using Cauldron, just mga4. (Need to setup a Cauldron VM, though, apparently ;) )

I just ran two builds - one for Cauldron and one for Mga4 both with the updated mono-flickrnet available.

Cauldron:
http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/cauldron/x86_64/log/f-spot-0.9.0-0.6612.1.mga5.src.rpm/build.0.20140724153302.log

Mga4:
http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/4/x86_64/log/f-spot-0.9.0-0.6612.1.mga4.src.rpm/build.0.20140724153547.log

So no, the lcms errors appear identical in both Mga4 and Cauldron (without looking too closely ;) 

The package currently has a build require on pkgconfig(lcms) and pkgconfig(lcms2). I am guessing that maybe the former is no longer required?

Those symbols are lcms2 related, yes.

And yes, if I read this commit properly: https://github.com/mono/f-spot/commit/9c52d5feb5170020cc3b79944ff3c95bb2fc574b

So now, f-spot uses lcms2 exclusively.

Yes, f-spot is exclusively lcms2. If there is anything lcms1 in there its a bug. :)

Hi Stephen,
OK so why are we hitting this with lcms2-2.6 devel installed?:

(handle me gently - I'm only a struggling packager not a programmer :0)

/home/baz/rpmbuild/BUILD/f-spot/lib/libfspot/f-screen-utils.c:139: undefined reference to `cmsxyY2XYZ'
/home/baz/rpmbuild/BUILD/f-spot/lib/libfspot/f-screen-utils.c:140: undefined reference to `cmsxyY2XYZ'
/home/baz/rpmbuild/BUILD/f-spot/lib/libfspot/f-screen-utils.c:142: undefined reference to `cmsCreateProfilePlaceholder'
/home/baz/rpmbuild/BUILD/f-spot/lib/libfspot/f-screen-utils.c:146: undefined reference to `cmsSetDeviceClass'
/home/baz/rpmbuild/BUILD/f-spot/lib/libfspot/f-screen-utils.c:147: undefined reference to `cmsSetColorSpace'
/home/baz/rpmbuild/BUILD/f-spot/lib/libfspot/f-screen-utils.c:148: undefined reference to `cmsSetPCS'
/home/baz/rpmbuild/BUILD/f-spot/lib/libfspot/f-screen-utils.c:150: undefined reference to `cmsSetHeaderRenderingIntent'
/home/baz/rpmbuild/BUILD/f-spot/lib/libfspot/f-screen-utils.c:153: undefined reference to `cmsPipelineAlloc'
/home/baz/rpmbuild/BUILD/f-spot/lib/libfspot/f-screen-utils.c:160: undefined reference to `cmsStageAllocCLut16bitGranular'
/home/baz/rpmbuild/BUILD/f-spot/lib/libfspot/f-screen-utils.c:164: undefined reference to `cmsStageAllocToneCurves'
/home/baz/rpmbuild/BUILD/f-spot/lib/libfspot/f-screen-utils.c:165: undefined reference to `cmsPipelineInsertStage'
/home/baz/rpmbuild/BUILD/f-spot/lib/libfspot/f-screen-utils.c:168: undefined reference to `cmsStageSampleCLut16bit'
/home/baz/rpmbuild/BUILD/f-spot/lib/libfspot/f-screen-utils.c:176: undefined reference to `cmsPipelineInsertStage'
/home/baz/rpmbuild/BUILD/f-spot/lib/libfspot/f-screen-utils.c:179: undefined reference to `cmsWriteTag'
/home/baz/rpmbuild/BUILD/f-spot/lib/libfspot/f-screen-utils.c:180: undefined reference to `cmsWriteTag'
/home/baz/rpmbuild/BUILD/f-spot/lib/libfspot/f-screen-utils.c:181: undefined reference to `cmsWriteTag'
/home/baz/rpmbuild/BUILD/f-spot/lib/libfspot/f-screen-utils.c:182: undefined reference to `cmsD50_XYZ'
/home/baz/rpmbuild/BUILD/f-spot/lib/libfspot/f-screen-utils.c:182: undefined reference to `cmsWriteTag'
/home/baz/rpmbuild/BUILD/f-spot/lib/libfspot/f-screen-utils.c:183: undefined reference to `cmsWriteTag'
/home/baz/rpmbuild/BUILD/f-spot/lib/libfspot/f-screen-utils.c:186: undefined reference to `cmsPipelineFree'
/home/baz/rpmbuild/BUILD/f-spot/lib/libfspot/f-screen-utils.c:171: undefined reference to `cmsPipelineFree'
/home/baz/rpmbuild/BUILD/f-spot/lib/libfspot/f-screen-utils.c:172: undefined reference to `cmsCloseProfile'

Anyone got a clue?
f-screen-utils.c includes the following:

#include <config.h>
#include <gtk/gtk.h>
#include <X11/Xlib.h>
#include <X11/Xatom.h>
#include <gdk/gdkx.h>
#include <lcms2.h>
#include <lcms2_plugin.h>

What is it missing?

(In reply to Barry Jackson from comment #41)
> Anyone got a clue?
> f-screen-utils.c includes the following:
> 
> #include <config.h>
> #include <gtk/gtk.h>
> #include <X11/Xlib.h>
> #include <X11/Xatom.h>
> #include <gdk/gdkx.h>
> #include <lcms2.h>
> #include <lcms2_plugin.h>
> 
> What is it missing?

I don't have the problem on my machine, and am off for three weeks :(. Maybe Stephen shaw will know...

Could you please attach output of:
rpm -qa
on your machine before you go?

Have a good trip!

(In reply to Barry Jackson from comment #43)
> Could you please attach output of:
> rpm -qa
> on your machine before you go?
> 
> Have a good trip!

Sorry, already gone, writing for the airport...

Cannot rpm -qa, but I have the latest lcms2 and lcms2-devel from the mga4 x86_64 official repos for sure. My urpmi updates are run daily, not using cauldron

(In reply to Matthieu Nguyen from comment #44)
> (In reply to Barry Jackson from comment #43)
> > Could you please attach output of:
> > rpm -qa
> > on your machine before you go?
> > 
> > Have a good trip!
> 
> Sorry, already gone, writing for the airport...
> 
> Cannot rpm -qa, but I have the latest lcms2 and lcms2-devel from the mga4
> x86_64 official repos for sure. My urpmi updates are run daily, not using
> cauldron

Just in case you get to see your mail on holiday - I got past that issue after many test builds in Mga4 system. It's an issue with our %configure2_5x rpm macro - just what causes it to fail I have not investigated yet.

There is another issue in the tests but I have disabled those for now, and have finally built an rpm locally and in iurt for Mga4.

So, progress at last :)

Created attachment 5746 [details]
Build log for current master (0.8.0 rev369)

Build in Cauldron still fails using git master as per the attached - any ideas?

Created attachment 5747 [details]
rpm -qa in build chroot

Created attachment 5748 [details]
mk-tar-git-rev

Script I currently use to create tarball.

Looks like Stephen added a reference to the latest Nunit (2.6.3).

rpm -qis mono-nunit on my machine shows that in mono-nunit 3.2.3, the packaged nunit framework is Nunit 2.4.8 :(

OK, so I built the latest mono-3.10.0 and re-built f-spot against it only to get the same error.
Checking in the chroot it seems that the nunit framework is still Nunit 2.4.8 in mono-nunit-3.10.0. :(

(In reply to Barry Jackson from comment #50)
> OK, so I built the latest mono-3.10.0 and re-built f-spot against it only to
> get the same error.
> Checking in the chroot it seems that the nunit framework is still Nunit
> 2.4.8 in mono-nunit-3.10.0. :(

Sorry I didn't reply earlier. I don't even have mono 3.10 (I think it's even more than that in the 3.x releases) yet. I think when the package wants mono 3.6 the Nunit constraint should be to the same Nunit version.

I'll try contacting Stephen and see if it would be possible to set the required Nunit version back to 2.4.8 instead of 2.6.

Is the mono-3.10 package available on a repo (cauldron?)

Versions of mono in Mageia:
3.12.1-1.mga5 // core-release (Mga, cauldron, x86_64)
3.12.1-1.mga5 // core-release (Mga, cauldron, i586)
3.2.3-5.1.mga4 // core-updates_testing (Mga, 4, i586)
3.2.3-5.mga4 // core-release (Mga, 4, x86_64)
3.2.3-5.mga4 // core-release (Mga, 4, i586)
2.10.9-4.1.mga3 // core-updates (Mga, 3, x86_64)
2.10.9-4.1.mga3 // core-updates (Mga, 3, i586)
2.10.9-4.mga3 // core-release (Mga, 3, x86_64)
2.10.9-4.mga3 // core-release (Mga, 3, i586)
2.10.9-1.mga2 // core-release (Mga, 2, x86_64)
2.10.9-1.mga2 // core-release (Mga, 2, i586)
2.10.1-1.1.mga1 // core-updates (Mga, 1, x86_64)
2.10.1-1.1.mga1 // core-updates (Mga, 1, i586)
2.10.1-1.mga1 // core-release (Mga, 1, x86_64)
2.10.1-1.mga1 // core-release (Mga, 1, i586)

(In reply to Barry Jackson from comment #52)
> Versions of mono in Mageia:
> 3.12.1-1.mga5 // core-release (Mga, cauldron, x86_64)
> 3.12.1-1.mga5 // core-release (Mga, cauldron, i586)
> 3.2.3-5.1.mga4 // core-updates_testing (Mga, 4, i586)
> 3.2.3-5.mga4 // core-release (Mga, 4, x86_64)
> 3.2.3-5.mga4 // core-release (Mga, 4, i586)
> 2.10.9-4.1.mga3 // core-updates (Mga, 3, x86_64)
> 2.10.9-4.1.mga3 // core-updates (Mga, 3, i586)
> 2.10.9-4.mga3 // core-release (Mga, 3, x86_64)
> 2.10.9-4.mga3 // core-release (Mga, 3, i586)
> 2.10.9-1.mga2 // core-release (Mga, 2, x86_64)
> 2.10.9-1.mga2 // core-release (Mga, 2, i586)
> 2.10.1-1.1.mga1 // core-updates (Mga, 1, x86_64)
> 2.10.1-1.1.mga1 // core-updates (Mga, 1, i586)
> 2.10.1-1.mga1 // core-release (Mga, 1, x86_64)
> 2.10.1-1.mga1 // core-release (Mga, 1, i586)

I think the update to 3.12.1 will be necessary anyways (seen there's a bug open about a critical TLS security fix in there), at least for Mga5. Will try to setup a cauldron vm to see how things go with the latest mono version...

I have it building now in Cauldron it, logs should appear here:
http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/cauldron/x86_64/log/f-spot-0.8.0-0.369.0.2.mga5.src.rpm/

I also just tried with the latest upstream f-spot from git (only 4 commits more than in December) but the errors are the same.

Hey guys. I'd definitely move to that newer mono because of the TLS stuff. It was a big enough deal that Xamarin bumped all of their products. Also, mono 4.0 should be coming out soon. It'll definitely be worth getting in for a variety of reasons.

As for the nunit stuff. I'll look into that when I get a chance (probably next week). Mono ships with its own very of nunit 2.4.x. We don't want that one. We want nunit 2.6.  The easiest way to get it is through nuget, but that isn't really an option for linux packaging.

Since f-spot is in Cauldron now, can this bug report be closed?

@ Mike

http://pkgsubmit.mageia.org/data/maintdb.txt gives a wrong impression, here, sorry :-/ 

Don't worry if you don't grasp all of what I say between the "----" lines, feel free to only read what's below that part, about Sophie.

--------------------------------------------------------------------------
It seems http://pkgsubmit.mageia.org/data/maintdb.txt does not only show information about packages that were built and added to our mirrors, but also about Mga 4 or cauldron packages that didn't built, but are not in obsolete... and f-spot is still (or again) there http://svnweb.mageia.org/packages/cauldron/f-spot/ instead of among the obsoleted packages http://svnweb.mageia.org/packages/obsolete/?dir_pagestart=200 :-(

if I try to install f-spot in cauldron, shotwell is offered instead:

[root@Mga5RC_EFI marja]# urpmi f-spot
To satisfy dependencies, the following packages are going to be installed:
  Package                        Version      Release       Arch    
(medium "Core Release (BlueHD1)")
  lib64gee0.8_2                  0.16.1       2.mga5        x86_64  
  lib64gexiv2_2                  0.10.2       2.mga5        x86_64  
  lib64raw10                     0.16.0       6.mga5        x86_64  
  shotwell                       0.20.2       3.mga5        x86_64  
14MB of additional disk space will be used.
3.2MB of packages will be retrieved.
Proceed with the installation of the 4 packages? (Y/n) 

(Looking at the shotwell spec file, that is correct behaviour, shotwell obsoletes and provides f-spot http://svnweb.mageia.org/packages/cauldron/shotwell/current/SPECS/shotwell.spec?revision=816424&view=markup)
----------------------------------------------------------------------------

I didn't tell you about Sophie, yet: she's a very useful IRC bot https://wiki.mageia.org/en/Sophie

Sophie said:

2015:04:05:08:42 < marja> :v f-spot -v 4
2015:04:05:08:42 < Sophie> marja: There is no rpm named `f-spot' in (Mga, 4, x86_64), but the word matches in core-release (Mga, 2, i586)
2015:04:05:08:42 < marja> :v f-spot -v cauldron
2015:04:05:08:42 < Sophie> marja: There is no rpm named `f-spot' in (Mga, cauldron, x86_64), but the word matches in core-release (Mga, 2, i586)

CC'ing Nic, because I didn't tell him about Sophie, either

The best way to learn to use Sophie is to just try her out, and watch how others use her on IRC.

CC: (none) => nic

Not sure I follow. So in order to get the new f-spot package in the repo, the shotwell SPEC has to be updated?

(In reply to Matthieu Nguyen from comment #59)
> Not sure I follow. So in order to get the new f-spot package in the repo,
> the shotwell SPEC has to be updated?

Yes. f-spot was obsoleted by shotwell here:

http://svnweb.mageia.org/packages/cauldron/shotwell/current/SPECS/shotwell.spec?r1=296332&r2=296902

So that commit would need to be reverted before f-spot could be re-introduced.

Does f-spot build and run now? It was badly broken last time I tried.

I have to check. Latest from git didn't build for me on mga4 (my packages were too old, didn't have the courage to download sources for all the deps, much prever to use the *-devel packages :) ). I know my pull request for fixing the flickr export is not in, so that's still broken for sure, but it looks like there has been some work done (especially to port the app to GTK3, and make it build again on more systems). I migrated my main system to mga5, so I'll try it again now.

(In reply to Matthieu Nguyen from comment #61)
> I have to check. Latest from git didn't build for me on mga4 (my packages
> were too old, didn't have the courage to download sources for all the deps,
> much prever to use the *-devel packages :) ). I know my pull request for
> fixing the flickr export is not in, so that's still broken for sure, but it
> looks like there has been some work done (especially to port the app to
> GTK3, and make it build again on more systems). I migrated my main system to
> mga5, so I'll try it again now.

So, I made myself a clean Mageia 5 VM. It started to complain about dbus-sharp-glib-2.0 not found. Which is because of this pull request that was merged in order to get f-spot to compile under Debian:

https://github.com/mono/f-spot/pull/29

Apparently, we'd need to update our dbus-sharp (https://github.com/mono/dbus-sharp/releases)to 0.8 and dbus-sharp-glib 0.6.0 (https://github.com/mono/dbus-sharp-glib/releases)

I will probably switch this VM to cauldron to be able to test candidate updates.

Yes, I hit the same issue.

I have built updated dbus-sharp and dbus-sharp-glib packages for Mga5 for testing which you can install by adding this repo temporarily:

http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/5/x86_64/media/extra/release/

F-spot still won't build though :\

Will attach build log below.

Created attachment 6826 [details]
Build log with new dbus-sharp*

Not sure if this is relevant as I'm totally out of my depth here but grepping I notice that in f-spot sources:

src/Clients/MainApp.UnitTest/MainApp.UnitTest.csproj:    <Reference Include="nunit.framework, Version=2.4.8.0

whereas

src/Core/FSpot.Core.UnitTest/FSpot.Utils.UnitTest.csproj:    <Reference Include="nunit.framework, Version=2.6.3.0

(In reply to Barry Jackson from comment #65)
> Not sure if this is relevant as I'm totally out of my depth here but
> grepping I notice that in f-spot sources:
> 
> src/Clients/MainApp.UnitTest/MainApp.UnitTest.csproj:    <Reference
> Include="nunit.framework, Version=2.4.8.0
> 
> whereas
> 
> src/Core/FSpot.Core.UnitTest/FSpot.Utils.UnitTest.csproj:    <Reference
> Include="nunit.framework, Version=2.6.3.0

Ran into the same problem. Not sure why one or two project files switched to nunit 2.6.3 in their version instead of 2.4.8 which is the one bundled in mono 3.12.

I meant to open an issue upstream about this (either the autogen.sh / configure script should complain that NUNIT is not the right version, either the csproj file using 2.6.3.0 should be using 2.4.8 only, provided the version change was not made necessary because of a unit test code change).

Unfortunately, since mono only provides 2.4.8, it would mean an extra dependency (would need to create a nunit package, basically)...

as a workaround, I locally modified the csproj to say "2.4.8.0", and I got f-spot to compile. But I need to take that issue to the dev to make sure what the right approach is.

Created attachment 6827 [details]
crash report

I patched the csproj and it builds but crashes on launch after displaying the main GUI - no doubt you see the same?

(In reply to Barry Jackson from comment #67)
> Created attachment 6827 [details]
> crash report
> 
> I patched the csproj and it builds but crashes on launch after displaying
> the main GUI - no doubt you see the same?

Is that the full stacktrace from running f-spot --debug?

I did run into the issue, but I'm not sure if it's because I tried on that clean VM with no photos.db, or because of something else. I would consider it an upstream "crasher" issue, personally.

Did you run into a "DLL not found" issue with libgtk-win32 as well?

The libgtk-win32 issue seems to be a problem because gtk-sharp-beans is getting added to the GAC. I'd recommend updating to the latest version 2.14.0 + a patch.
Here is what openSUSE has done - https://build.opensuse.org/package/show/Mono:Factory/gtk-sharp-beans

Created attachment 6828 [details]
terminal output from f-spot --debug

(In reply to Barry Jackson from comment #70)
> Created attachment 6828 [details]
> terminal output from f-spot --debug

ok, doesn't look related to the missing DLL. Will open an issue upstream for it

Looking at the output I think I might be able to track the crash down.

Output looks oddly similar to this:

https://github.com/mono/f-spot/issues/23
(In reply to Matthieu Nguyen from comment #71)
> (In reply to Barry Jackson from comment #70)
> > Created attachment 6828 [details]
> > terminal output from f-spot --debug
> 
> ok, doesn't look related to the missing DLL. Will open an issue upstream for
> it

Actually, looks oddly similar to this:

https://github.com/mono/f-spot/issues/23

There's new activity going on at the moment on the f-spot git tree, the devs are working on getting a build out the door.

I wanted to recheck on my Cauldron VM, see if the crash at startup still happens, but I could not find the updated dbus-glip-sharp 0.6 package (only have 0.5 in my repo).

Is it available somewhere already?

Does not look like it:
https://github.com/mono/dbus-sharp/wiki/Release-notes-dbus-sharp-0.7-and-dbus-sharp-glib-0.5

Created attachment 7385 [details]
mono-flickrnet build log

Oh and while on this - mono-flickrnet no longer builds despite updating it - any ideas?
log attached

(In reply to Barry Jackson from comment #75)
> Does not look like it:
> https://github.com/mono/dbus-sharp/wiki/Release-notes-dbus-sharp-0.7-and-
> dbus-sharp-glib-0.5

I was more referring to the packages you built back in July. You sent a link to the repo where one could get the 0.8/0.6 packages you built, but I don't see it there anymore.

(cf comments #62 and #63)

(In reply to Barry Jackson from comment #76)
> Created attachment 7385 [details]
> mono-flickrnet build log
> 
> Oh and while on this - mono-flickrnet no longer builds despite updating it -
> any ideas?
> log attached

No idea. Actually, in the latest version of f-spot, some external dependencies (like flickrnet) are brought in as a git submodule in external and compiled directly during the F-Spot build. So I don't think you still need mono-flickrnet anymore.

Ah OK I just found the sources for 0.81/0.6 so I will try to build them - what do you want Mga5 or Mga6? (x86_64 I guess?)

I will push them to Cauldron if they build OK.

They won't build in Cauldron (I'm guessing it's the new mono version there), but in Mageia 5 they are OK and are now in the repo in #63.
Googling it may be a problem with something missing from the mono build in Cauldron. I will ask the mono maintainer.

OK solved for Cauldron too :) I found the answer here:
https://bugzilla.redhat.com/show_bug.cgi?id=1255204#c1
So just use the same url as in #62 but s/cauldron/5/ if you want to try cauldron before I push them there. The specs are a mess and need a tidy up.

Barry

mono-flickrnet is also fixed in cauldron now :) We don't want to use bundled or even worse 'downloaded during build' stuff - we need to use our own packages.

(In reply to Barry Jackson from comment #82)
> mono-flickrnet is also fixed in cauldron now :) We don't want to use bundled
> or even worse 'downloaded during build' stuff - we need to use our own
> packages.

Yeah, I suspected as much, and raised it to Stephen on gitter.

The reason I included it right in f-spot was because several distros were behind with their package. That almost seems to be the case with several dependencies. I decided it was easier for me if I just included it so that I could improve f-spot instead of having to wait for all of the distros to catch up first :(

Hi Stephen,
I understand - as long as we can disable the included stuff and use our own without too much head scratching then that's fine ;)

Barry

We build flikrnet as part of the build process, I suppose you could just replace the dll. Since I'm building it from source (part of the tarball), is there value in replacing it? I suppose it saves space on the hard drive?

(In reply to Barry Jackson from comment #85)
> Hi Stephen,
> I understand - as long as we can disable the included stuff and use our own
> without too much head scratching then that's fine ;)
> 
> Barry

I'm not a build expert so I'm not sure how to have a "build from submodule if lib not present on the system" behaviour. But I'm thinking as an alternative if you just remove it from /usr/lib/f-spot/Extensions/FlickrNet.*, maybe at runtime F-spot would just pick up the one bundled in the distro?

Would have to try it, though.

I'm not sure either. I think debian has something built into their build process that deals with that. I'm just not sure how that works.

Some packages have the option to disable the use of bundled libs etc. at build time using a configure option --without-local-xyz, or similar but I don't know how it works in detail.

Problems occur when bundled stuff has security updates - these are handled fairly quickly in our own discrete packages.
When the same software is bundled, we have to rely on various 'upstreams' to fix it, or patch it ourselves within each package, which multiplies the maintenance and qa effort, for which we don't have the resources.

Updating dbus-sharp and dbus-sharp-glib has broken several packages that need the 1.0 ABI, so I am reverting the change, and introducing dbus-sharp2 and dbus-sharp-glib2 in Cauldron to provide the 2.0 ABI.

f-spot with the included git stuff in Cauldron now does build, but crashes on launch.

An unhandled exception was thrown: libunique-1.0.so.0

I am not sure if I have enough disk space left in the VM to load all the debuinfo to get a useful backtrace.

Created attachment 7394 [details]
output from $ f-spot --debug

(In reply to Barry Jackson from comment #91)
> Created attachment 7394 [details]
> output from $ f-spot --debug

in my MGA5 I have lib64unique1.0_0 installed.

Do you have it in your cauldron? I'm not sure why it wouldn't complain during the auto*.sh phase. Maybe we need to check for that too...

(In reply to Matthieu Nguyen from comment #92)
> (In reply to Barry Jackson from comment #91)
> > Created attachment 7394 [details]
> > output from $ f-spot --debug
> 
> in my MGA5 I have lib64unique1.0_0 installed.
> 
> Do you have it in your cauldron? I'm not sure why it wouldn't complain
> during the auto*.sh phase. Maybe we need to check for that too...

Hi Matthieu
I now have it working in cauldron.
For some reason autoreq is not pulling in: 
%{_lib}unique1.0_0
%{_lib}gnomeui2_0
so for now I have added them as hard Requires and it's looking quite stable.

The only thing that crashes it so far, is help->contents.

BTW the updated versions of dbus-sharp and dbus-sharp-glib still have the original package names.
The ones that now provide the old 1.0 ABI are dbus-sharp1.0 and dbus-sharp-glib1.0
I was advised that this was the correct way to handle it, and it's finally all sorted in Cauldron ;)

OK having tested some more I hit a few issues running in X86_64 VM none of which are apparent in a build for armv5tl which I have also tested on real hardware.
So maybe there is a problem with my VM or maybe there is an issue with X86_64 build.

I have tried removing the external downloads during build with no success at all.

Another issue this raises is that the (possibly unstable) snapshots of the external sources used are just what happens to be the state of the sources at our  build time - giving no control whatsoever of the 'versions' in use.
This is totally unacceptable in my opinion.

Without a sane way to turn off this 'feature' then this project is looking like a non-starter for Mageia.

I am asking qa to take a look for comments.

Downloading additional source code during a build is a violation of our packaging policy.  First of all, if additional third party code is needed, packages should generally link against existing system versions of those things, and second of all, if additional tarballs are needed, they should be included in the source RPM so that they're available without needing to be downloaded.

In addition, downloading source code is not guaranteed to actually *work* during the package build process. 

For example, several build systems (Fedora's Koji, SUSE's Open Build Service, etc.) actually do not configure network connectivity for the builder environment, so any build that requires downloading sources at build-time will automatically trigger a FTBFS condition.

This is to guarantee the reproducibility of the package build, which is important for security and reliability reasons[1].

[1]: https://reproducible-builds.org/

CC: (none) => ngompa13

Just so we are clear :)
F-Spot is NOT downloading additional/3rd party software during a build/packaging process. If for some reason it is then that is a bug.

Flickrnet is a git submodule, but that should be part of the release tarball. The reason it and a couple more things are in there is either because upstream is dead and hasn't had a new release causing all kinds of packaging and build problems for those trying to just build it locally or the distro just hasn't been updating that package as is the case with flickrnet. I don't want to split my time between packaging 3rd party deps across X platforms and improving f-spot. I'm going to cause improving f-spot every time. If the distros bring flickrnet up to date it'd in theory actually make my life easier and I'd no longer have to deal with that submodule.

That sounds reasonable Stephen.  It is a real pain for both developers like yourself and packagers like us when projects don't make releases and you have to use git snapshots, but we can certainly do that for flickrnet if we must.

flickrnet is the guilty one :)

It is just that no one had updated the flickrnet package on just about any distro and in order to revive the addin we needed a newer flickrnet. The path of least resistance was to just bring in the submodule for the time being. Once distros catch up I'll very happily drop it :)

Assigning this package request to all packagers collectively. On a voluntary basis, one of them might want to integrate it to the distribution and maintain it for bug and security fixes.

You might also want to join the packager team to maintain this piece of software: see https://wiki.mageia.org/en/Becoming_a_Mageia_Packager

Assignee: bugsquad => pkg-bugs

After so many years this pile of code is still an unusable mess. Quote from the GitHub page:

"WARNING
The code base is in heavy flux right now. It might be completely broken right now. Known issues:

Doesn't start
AdjustTimeDialog is completely broken due to removing Gnome.DateTime
Autotools stuff is likely doing the wrongs things due to heavy changes."

Closing again as WONTFIX.

Resolution: (none) => WONTFIX
Status: REOPENED => RESOLVED