Revision history [back]

I added the mer-tools repository by issuing ssu ar mer-tools as root, which appends mer-tools to the line enabled-repos=store, mer-tools in /etc/ssu/ssu.ini.
Question 1: But when I list the subscribed repositories with ssu lr it outputs mer-tools ... https://releases.jolla.com/releases/2.1.3.7/mer-tools/builds/armv7hl/packages/ in the Enabled repositories (user): section, not in the Enabled repositories (global): section, although it is clearly a Jolla supplied repository (by looking at its source link and how it is added in the ssu.ini file)?!?

As most (if not all) of the tools available in Jolla's mer-tools repository seem to be somewhat outdated (by looking at their version numbers compared to a recent desktop Linux distribution), I started searching for the built RPM files at other locations, because I was unable to look up the contents of https://releases.jolla.com/releases/2.1.3.7/mer-tools/builds/armv7hl/packages/ directly. The tedious workaround is to look up RPMs expected in there by using pkcon search name in order to obtain their version numbers.
Question 2: Is there a way to take a look at all RPMs available in Jolla's mer-tools repository directly (e.g. in a web browser, by using the CLI tools zypper or rpm etc.)?

So I started searching the WWW for mer-tools:

• First I looked for development repositories and found:

  • https://git.merproject.org/mer-tools, which solely contains sdk-webapps and has been unmaintained for 4 years (while https://git.merproject.org/ still seems to be the central, active development repository for Mer / SailfishOS, with its compiled packages available at https://build.merproject.org/project/show/mer:core).
  • In contrast to this https://github.com/mer-tools is still maintained (although the tools there are rather rarely updated), but only provides source releases (i.e. tar- / zip-balls). At least one can determine the current version of each tool there, although tediously.
    Question 3: But the version numbers of the recent tar-balls does correspond to the versions available in any other mer-tools repository (looking at e.g. the android-tools package): Where are those packages released in binary form? Is there a process defined for this?

• So I turned over to http://projects.merproject.org/ to look for built packages (i.e. RPMs) and there the real confusion started:

  • In http://projects.merproject.org/releases/ there are "Mer-Tools" and "mer-tools" subdirectories, but they seem to be an exact mirror of each other!?!
    Question 4: Why do these two directories have the exactly same content? Wouldn't it make sense to remove one of them (presumably "Mer-Tools")?

    • In http://projects.merproject.org/releases/mer-tools/ the file "latest-release" points to "8.1.0", thus the packages in e.g. http://projects.merproject.org/releases/mer-tools/latest/builds/armv7hl/packages/armv7hl/ are identical to the 8.1.0 release and are all dated 2013-04-23 (which is quite outdated)! Checking with the packages, which can be obtained from Jolla's mer-tools repository, these are (luckily) newer, so "latest" does not point to the latest packages!
      Question 5: Why are there no newer releases than mer-tools 8.1.0 on 2013-04-28, although the mer-tools are obviously still developed further (see below)?
    • So I took a closer long at the "mer-tools" subdirectory "test", only to see that testing obviously stopped on 2013-06-24, see e.g. http://projects.merproject.org/releases/mer-tools/test/builds/armv7hl/packages/armv7hl/.
      Question 6: Why does the "test" subdirectory still exist, even though it is not used anymore?
    • Then I turned to the last two subdirectories of interest, "next" and "rolling", which are duplicates of each other (again, presumably due to http://projects.merproject.org/releases/mer-tools/next-release pointing to "rolling") and obviously contain automatically generated packages (all packages the are at most a few days old and carry the same build date) and many more packages than all other directories under http://projects.merproject.org/releases/mer-tools/! Unfortunately the auto-generated character of these packages lets me hesitate to install anything from there and this also is clearly not the source of the packages in Jolla's mer-tools repository.
      Question 7: Why do both subdirectories "next" and "rolling" exist, although they share the same content?

  • Thus I kept on searching in http://projects.merproject.org/ and also found "mer-tools:" in http://projects.merproject.org/obs/ with a much cleaner directory structure, although still confusing:

    • The subdirectories "devel:" and "testing:" (those with a colon ":") contain both a directory "Trial:", which in turn obviously contains two different trials, but nothing of interest.
      Question 8: Why do these two subdirectories still exist, if they just have been created for trial purposes in 2013 / 2014?
    • The subdirectory "stable" looks promising (by its name) and really contains packages with build dates ranging from 2013 to 2017 (see e.g. http://projects.merproject.org/obs/mer-tools:/stable/latest_armv7hl/armv7hl/), so it looks properly maintained. But when comparing package versions there with what is available in Jolla's mer-tools repository, they differ: Some packages provided by Jolla are older (e.g. dosfstools), some are newer (e.g. btrfs-progs, android-tools) judging by their version numbers.
    • The subdirectory "devel" also lives up to its name, as all packages are either the same or newer than in the "stable" directory (by build date and version numbers, see e.g. http://projects.merproject.org/obs/mer-tools:/devel/latest_armv7hl/armv7hl/). Only the "android-tools" package is newer by date in the "stable" directory, although it carries a lower version number (at least this is the only confusing package I have found by quickly glancing over the packages)!?! The packages there also differ from Jolla's mer-tools repository: While the "btrfs-progs" package provided by Jolla is newer (by version number), all other packages from Jolla seem to be older (e.g. dosfstools, android-tools). It also differs a lot from http://projects.merproject.org/releases/mer-tools/rolling/ (by version numbers and naturally by build dates of the packages).
    • In contrast to that, the "testing" subdirectory contains older packages (with build dates ranging from 2013 to 2015, see e.g. http://projects.merproject.org/obs/mer-tools:/testing/latest_armv7hl/armv7hl/) than the "stable" directory, also with the exception of the "android-tools" package, which also is older by date, but newer by version than the one in "stable" (but much older than the one in "devel").
      Question 9: Why does the "testing" directory still exist, if it is not used anymore (and contains older packages than "stable")?

• Ultimately I remembered that NielDK provides a lot of updated packages for SailfishOS in his OpenRepos repository, so I started looking here at the Mer-OBS and found http://repo.merproject.org/obs/home:/nielnielsen/, which provides much newer (by version) packages than all aforementioned repositories (see e.g. http://repo.merproject.org/obs/home:/nielnielsen/sailfish_latest_armv7hl/armv7hl/), but these packages supposedly have not undergone much testing. Kudos to @NielDK for providing these, although enabling his OpenRepos or Mer-OBS repository is IMO somewhat dangerous, as one can accidentally update half of the installed SailfishOS to newer components by either automatic dependency resolution when installing a package or a simple pkcon update; still, when a feature is not available in the quite old (although recently built) versions in Jolla's mer-tools repository or http://projects.merproject.org/obs/mer-tools:/stable/ (or ../devel or http://projects.merproject.org/releases/mer-tools/rolling/), Niel provides a source for much newer packages (thanks!).

• As all these different mer-tools repositories are quite confusing, I searched the WWW again for some meta-information:
  https://wiki.merproject.org/wiki/Tools provides some information, but much of that does not seem to be correct (e.g. the pointers to "Mer:Tools" and "Mer:Tools:Testing" repositories at the Mer-OBS, which do not exist), even though this wiki page has been last updated 2016-06-27.

To summarise this research journey:

• Still have not found the source for the packages in Jolla's mer-tools repository at https://releases.jolla.com/releases/2.1.3.7/mer-tools/builds/armv7hl/packages/, neither their sources or at least all their versions and build dates (or the process from ine to the other)..
• Found http://projects.merproject.org/obs/mer-tools:/stable/ which mostly provides slightly newer packages than Jolla (but not for all packages) and looks trustworthy, but its relationship to Jolla's mer-tools repository is unclear. Hence I refrain from simply enabling this repository, but may try single packages downloaded manually, if issues with a Jolla provided one should arise.
• http://projects.merproject.org/obs/mer-tools:/devel/ provides newer packages than its "stable" version and looks better maintained than http://projects.merproject.org/releases/mer-tools/rolling/, but the specifics of these repositories (who is maintaining them, why do they exist in parallel, how much QA have those packages undergone?) are absolutely unclear to me.
• The "android-tools" package seems to be an outlier across these repositories WRT its version and build date.
• http://repo.merproject.org/obs/home:/nielnielsen/ provides much newer versions of all mer-tools packages (plus many components of the SailfishOS proper), but should be used very carefully, IMO (i.e. you should exactly know what you are doing and how to return to a known good state).
• Found lots and lots of old cruft while researching the state of mer-tools!
• All in all, the mer-tools do not appear to be properly maintained in general, structurally (too many repositories and dead directories) and by looking at the diverting versions in the maintained repos and their branches. This is rather creating an impression of carelessness.

Hopefully this little documentation is helpful for others.
Even more I am hoping that this posting many trigger somebody at Jolla to clean up this mess and tell something about the purpose, relationship and maintenance of all these repositories here.

I added the mer-tools repository by issuing ssu ar mer-tools as root, which appends mer-tools to the line enabled-repos=store, mer-tools in /etc/ssu/ssu.ini.
Question 1: But when I list the subscribed repositories with ssu lr it outputs mer-tools ... https://releases.jolla.com/releases/2.1.3.7/mer-tools/builds/armv7hl/packages/ in the Enabled repositories (user): section, not in the Enabled repositories (global): section, although it is clearly a Jolla supplied repository (by looking at its source link and how it is added in the ssu.ini file)?!?

As most (if not all) of the tools available in Jolla's mer-tools repository seem to be somewhat outdated (by looking at their version numbers compared to a recent desktop Linux distribution), I started searching for the built RPM files at other locations, because I was unable to look up the contents of https://releases.jolla.com/releases/2.1.3.7/mer-tools/builds/armv7hl/packages/ directly. The tedious workaround is to look up RPMs expected in there by using pkcon search name in order to obtain their version numbers.
Question 2: Is there a way to take a look at all RPMs available in Jolla's mer-tools repository directly (e.g. in a web browser, by using the CLI tools zypper or rpm etc.)?

So I started searching the WWW for mer-tools:

• First I looked for development repositories and found:

  • https://git.merproject.org/mer-tools, which solely contains sdk-webapps and has been unmaintained for 4 years (while https://git.merproject.org/ still seems to be the central, active development repository for Mer / SailfishOS, with its compiled packages available at https://build.merproject.org/project/show/mer:core).
  • In contrast to this https://github.com/mer-tools is still maintained (although the tools there are rather rarely updated), but only provides source releases (i.e. tar- / zip-balls). At least one can determine the current version of each tool there, although tediously.
    Question 3: But the version numbers of the recent tar-balls does correspond to the versions available in any other mer-tools repository (looking at e.g. the android-tools package): Where are those packages released in binary form? Is there a process defined for this?

• So I turned over to http://projects.merproject.org/ to look for built packages (i.e. RPMs) and there the real confusion started:

  • In http://projects.merproject.org/releases/ there are "Mer-Tools" and "mer-tools" subdirectories, but they seem to be an exact mirror of each other!?!
    Question 4: Why do these two directories have the exactly same content? Wouldn't it make sense to remove one of them (presumably "Mer-Tools")?

    • In http://projects.merproject.org/releases/mer-tools/ the file "latest-release" points to "8.1.0", thus the packages in e.g. http://projects.merproject.org/releases/mer-tools/latest/builds/armv7hl/packages/armv7hl/ are identical to the 8.1.0 release and are all dated 2013-04-23 (which is quite outdated)! Checking with the packages, which can be obtained from Jolla's mer-tools repository, these are (luckily) newer, so "latest" does not point to the latest packages!
      Question 5: Why are there no newer releases than mer-tools 8.1.0 on 2013-04-28, although the mer-tools are obviously still developed further (see below)?
    • So I took a closer long at the "mer-tools" subdirectory "test", only to see that testing obviously stopped on 2013-06-24, see e.g. http://projects.merproject.org/releases/mer-tools/test/builds/armv7hl/packages/armv7hl/.
      Question 6: Why does the "test" subdirectory still exist, even though it is not used anymore?
    • Then I turned to the last two subdirectories of interest, "next" and "rolling", which are duplicates of each other (again, presumably due to http://projects.merproject.org/releases/mer-tools/next-release pointing to "rolling") and obviously contain automatically generated packages (all packages the are at most a few days old and carry the same build date) and many more packages than all other directories under http://projects.merproject.org/releases/mer-tools/! http://projects.merproject.org/releases/mer-tools/ ! Unfortunately the auto-generated character of these packages lets me hesitate to install anything from there and this also is clearly not the source of the packages in Jolla's mer-tools repository.
      Question 7: Why do both subdirectories "next" and "rolling" exist, although they share the same content?

  • Thus I kept on searching in http://projects.merproject.org/ and also found "mer-tools:" in http://projects.merproject.org/obs/ with a much cleaner directory structure, although still confusing:

    • The subdirectories "devel:" and "testing:" (those with a colon ":") contain both a directory "Trial:", which in turn obviously contains two different trials, but nothing of interest.
      Question 8: Why do these two subdirectories still exist, if they just have been created for trial purposes in 2013 / 2014?
    • The subdirectory "stable" looks promising (by its name) and really contains packages with build dates ranging from 2013 to 2017 (see e.g. http://projects.merproject.org/obs/mer-tools:/stable/latest_armv7hl/armv7hl/), so it looks properly maintained. But when comparing package versions there with what is available in Jolla's mer-tools repository, they differ: Some packages provided by Jolla are older (e.g. dosfstools), some are newer (e.g. btrfs-progs, android-tools) judging by their version numbers.
    • The subdirectory "devel" also lives up to its name, as all packages are either the same or newer than in the "stable" directory (by build date and version numbers, see e.g. http://projects.merproject.org/obs/mer-tools:/devel/latest_armv7hl/armv7hl/). Only the "android-tools" package is newer by date in the "stable" directory, although it carries a lower version number (at least this is the only confusing package I have found by quickly glancing over the packages)!?! The packages there also differ from Jolla's mer-tools repository: While the "btrfs-progs" package provided by Jolla is newer (by version number), all other packages from Jolla seem to be older (e.g. dosfstools, android-tools). It also differs a lot from http://projects.merproject.org/releases/mer-tools/rolling/ (by version numbers and naturally by build dates of the packages).
    • In contrast to that, the "testing" subdirectory contains older packages (with build dates ranging from 2013 to 2015, see e.g. http://projects.merproject.org/obs/mer-tools:/testing/latest_armv7hl/armv7hl/) than the "stable" directory, also with the exception of the "android-tools" package, which also is older by date, but newer by version than the one in "stable" (but much older than the one in "devel").
      Question 9: Why does the "testing" directory still exist, if it is not used anymore (and contains older packages than "stable")?

• Ultimately I remembered that NielDK provides a lot of updated packages for SailfishOS in his OpenRepos repository, so I started looking here at the Mer-OBS and found http://repo.merproject.org/obs/home:/nielnielsen/, which provides much newer (by version) packages than all aforementioned repositories (see e.g. http://repo.merproject.org/obs/home:/nielnielsen/sailfish_latest_armv7hl/armv7hl/), but these packages supposedly have not undergone much testing. Kudos to @NielDK for providing these, although enabling his OpenRepos or Mer-OBS repository is IMO somewhat dangerous, as one can accidentally update half of the installed SailfishOS to newer components by either automatic dependency resolution when installing a package or a simple pkcon update; still, when a feature is not available in the quite old (although recently built) versions in Jolla's mer-tools repository or http://projects.merproject.org/obs/mer-tools:/stable/ (or ../devel or http://projects.merproject.org/releases/mer-tools/rolling/), Niel provides a source for much newer packages (thanks!).

• As all these different mer-tools repositories are quite confusing, I searched the WWW again for some meta-information:
  https://wiki.merproject.org/wiki/Tools provides some information, but much of that does not seem to be correct (e.g. the pointers to "Mer:Tools" and "Mer:Tools:Testing" repositories at the Mer-OBS, which do not exist), even though this wiki page has been last updated 2016-06-27.

To summarise this research journey:

• Still have not found the source for the packages in Jolla's mer-tools repository at https://releases.jolla.com/releases/2.1.3.7/mer-tools/builds/armv7hl/packages/, neither their sources or at least all their versions and build dates (or the process from ine to the other)..
• Found http://projects.merproject.org/obs/mer-tools:/stable/ which mostly provides slightly newer packages than Jolla (but not for all packages) and looks trustworthy, but its relationship to Jolla's mer-tools repository is unclear. Hence I refrain from simply enabling this repository, but may try single packages downloaded manually, if issues with a Jolla provided one should arise.
• http://projects.merproject.org/obs/mer-tools:/devel/ provides newer packages than its "stable" version and looks better maintained than http://projects.merproject.org/releases/mer-tools/rolling/, but the specifics of these repositories (who is maintaining them, why do they exist in parallel, how much QA have those packages undergone?) are absolutely unclear to me.
• The "android-tools" package seems to be an outlier across these repositories WRT its version and build date.
• http://repo.merproject.org/obs/home:/nielnielsen/ provides much newer versions of all mer-tools packages (plus many components of the SailfishOS proper), but should be used very carefully, IMO (i.e. you should exactly know what you are doing and how to return to a known good state).
• Found lots and lots of old cruft while researching the state of mer-tools!
• All in all, the mer-tools do not appear to be properly maintained in general, structurally (too many repositories and dead directories) and by looking at the diverting versions in the maintained repos and their branches. This is rather creating an impression of carelessness.

Hopefully this little documentation is helpful for others.
Even more I am hoping that this posting many trigger somebody at Jolla to clean up this mess and tell something about the purpose, relationship and maintenance of all these repositories here.

I added the mer-tools repository by issuing ssu ar mer-tools as root, which appends mer-tools to the line enabled-repos=store, mer-tools in /etc/ssu/ssu.ini.
Question 1: But when I list the subscribed repositories with ssu lr it outputs mer-tools ... https://releases.jolla.com/releases/2.1.3.7/mer-tools/builds/armv7hl/packages/ in the Enabled repositories (user): section, not in the Enabled repositories (global): section, although it is clearly a Jolla supplied repository (by looking at its source link and how it is added in the ssu.ini file)?!?

As most (if not all) of the tools available in Jolla's mer-tools repository seem to be somewhat outdated (by looking at their version numbers compared to a recent desktop Linux distribution), I started searching for the built RPM files at other locations, because I was unable to look up the contents of https://releases.jolla.com/releases/2.1.3.7/mer-tools/builds/armv7hl/packages/ directly. The tedious workaround is to look up RPMs expected in there by using pkcon search name in order to obtain their version numbers.
Question 2: Is there a way to take a look at all RPMs available in Jolla's mer-tools repository directly (e.g. in a web browser, by using the CLI tools zypper or rpm etc.)?

So I started searching the WWW for mer-tools:

• First I looked for development repositories and found:

  • https://git.merproject.org/mer-tools, which solely contains sdk-webapps and has been unmaintained for 4 years (while https://git.merproject.org/ still seems to be the central, active development repository for Mer / SailfishOS, with its compiled packages available at https://build.merproject.org/project/show/mer:core).
  • In contrast to this https://github.com/mer-tools is still maintained (although the tools there are rather rarely updated), but only provides source releases (i.e. tar- / zip-balls). At least one can determine the current version of each tool there, although tediously.
    Question 3: But the version numbers of the recent tar-balls does correspond to the versions available in any other mer-tools repository (looking at e.g. the android-tools package): Where are those packages released in binary form? Is there a process defined for this?

• So I turned over to http://projects.merproject.org/ to look for built packages (i.e. RPMs) and there the real confusion started:

  • In http://projects.merproject.org/releases/ there are "Mer-Tools" and "mer-tools" subdirectories, but they seem to be an exact mirror of each other!?!
    Question 4: Why do these two directories have the exactly same content? Wouldn't it make sense to remove one of them (presumably "Mer-Tools")?

    • In http://projects.merproject.org/releases/mer-tools/ the file "latest-release" points to "8.1.0", thus the packages in e.g. http://projects.merproject.org/releases/mer-tools/latest/builds/armv7hl/packages/armv7hl/ are identical to the 8.1.0 release and are all dated 2013-04-23 (which is quite outdated)! Checking with the packages, which can be obtained from Jolla's mer-tools repository, these are (luckily) newer, so "latest" does not point to the latest packages!
      Question 5: Why are there no newer releases than mer-tools 8.1.0 on 2013-04-28, although the mer-tools are obviously still developed further (see below)?
    • So I took a closer long at the "mer-tools" subdirectory "test", only to see that testing obviously stopped on 2013-06-24, see e.g. http://projects.merproject.org/releases/mer-tools/test/builds/armv7hl/packages/armv7hl/.
      Question 6: Why does the "test" subdirectory still exist, even though it is not used anymore?
    • Then I turned to the last two subdirectories of interest, "next" and "rolling", which are duplicates of each other (again, presumably due to http://projects.merproject.org/releases/mer-tools/next-release pointing to "rolling") and obviously contain automatically generated packages (all packages the are at most a few days old and carry the same build date) and many more packages than all other directories under http://projects.merproject.org/releases/mer-tools/ ! http://projects.merproject.org/releases/mer-tools/. Unfortunately the auto-generated character of these packages lets me hesitate to install anything from there and this also is clearly not the source of the packages in Jolla's mer-tools repository.
      Question 7: Why do both subdirectories "next" and "rolling" exist, although they share the same content?

  • Thus I kept on searching in http://projects.merproject.org/ and also found "mer-tools:" in http://projects.merproject.org/obs/ with a much cleaner directory structure, although still confusing:

    • The subdirectories "devel:" and "testing:" (those with a colon ":") contain both a directory "Trial:", which in turn obviously contains two different trials, but nothing of interest.
      Question 8: Why do these two subdirectories still exist, if they just have been created for trial purposes in 2013 / 2014?
    • The subdirectory "stable" looks promising (by its name) and really contains packages with build dates ranging from 2013 to 2017 (see e.g. http://projects.merproject.org/obs/mer-tools:/stable/latest_armv7hl/armv7hl/), so it looks properly maintained. But when comparing package versions there with what is available in Jolla's mer-tools repository, they differ: Some packages provided by Jolla are older (e.g. dosfstools), some are newer (e.g. btrfs-progs, android-tools) judging by their version numbers.
    • The subdirectory "devel" also lives up to its name, as all packages are either the same or newer than in the "stable" directory (by build date and version numbers, see e.g. http://projects.merproject.org/obs/mer-tools:/devel/latest_armv7hl/armv7hl/). Only the "android-tools" package is newer by date in the "stable" directory, although it carries a lower version number (at least this is the only confusing package I have found by quickly glancing over the packages)!?! The packages there also differ from Jolla's mer-tools repository: While the "btrfs-progs" package provided by Jolla is newer (by version number), all other packages from Jolla seem to be older (e.g. dosfstools, android-tools). It also differs a lot from http://projects.merproject.org/releases/mer-tools/rolling/ (by version numbers and naturally by build dates of the packages).
    • In contrast to that, the "testing" subdirectory contains older packages (with build dates ranging from 2013 to 2015, see e.g. http://projects.merproject.org/obs/mer-tools:/testing/latest_armv7hl/armv7hl/) than the "stable" directory, also with the exception of the "android-tools" package, which also is older by date, but newer by version than the one in "stable" (but much older than the one in "devel").
      Question 9: Why does the "testing" directory still exist, if it is not used anymore (and contains older packages than "stable")?

• Ultimately I remembered that NielDK provides a lot of updated packages for SailfishOS in his OpenRepos repository, so I started looking here at the Mer-OBS and found http://repo.merproject.org/obs/home:/nielnielsen/, which provides much newer (by version) packages than all aforementioned repositories (see e.g. http://repo.merproject.org/obs/home:/nielnielsen/sailfish_latest_armv7hl/armv7hl/), but these packages supposedly have not undergone much testing. Kudos to @NielDK for providing these, although enabling his OpenRepos or Mer-OBS repository is IMO somewhat dangerous, as one can accidentally update half of the installed SailfishOS to newer components by either automatic dependency resolution when installing a package or a simple pkcon update; still, when a feature is not available in the quite old (although recently built) versions in Jolla's mer-tools repository or http://projects.merproject.org/obs/mer-tools:/stable/ (or ../devel or http://projects.merproject.org/releases/mer-tools/rolling/), Niel provides a source for much newer packages (thanks!).

• As all these different mer-tools repositories are quite confusing, I searched the WWW again for some meta-information:
  https://wiki.merproject.org/wiki/Tools provides some information, but much of that does not seem to be correct (e.g. the pointers to "Mer:Tools" and "Mer:Tools:Testing" repositories at the Mer-OBS, which do not exist), even though this wiki page has been last updated 2016-06-27.

To summarise this research journey:

• Still have not found the source for the packages in Jolla's mer-tools repository at https://releases.jolla.com/releases/2.1.3.7/mer-tools/builds/armv7hl/packages/, neither their sources or at least all their versions and build dates (or the process from ine to the other)..
• Found http://projects.merproject.org/obs/mer-tools:/stable/ which mostly provides slightly newer packages than Jolla (but not for all packages) and looks trustworthy, but its relationship to Jolla's mer-tools repository is unclear. Hence I refrain from simply enabling this repository, but may try single packages downloaded manually, if issues with a Jolla provided one should arise.
• http://projects.merproject.org/obs/mer-tools:/devel/ provides newer packages than its "stable" version and looks better maintained than http://projects.merproject.org/releases/mer-tools/rolling/, but the specifics of these repositories (who is maintaining them, why do they exist in parallel, how much QA have those packages undergone?) are absolutely unclear to me.
• The "android-tools" package seems to be an outlier across these repositories WRT its version and build date.
• http://repo.merproject.org/obs/home:/nielnielsen/ provides much newer versions of all mer-tools packages (plus many components of the SailfishOS proper), but should be used very carefully, IMO (i.e. you should exactly know what you are doing and how to return to a known good state).
• Found lots and lots of old cruft while researching the state of mer-tools!
• All in all, the mer-tools do not appear to be properly maintained in general, structurally (too many repositories and dead directories) and by looking at the diverting versions in the maintained repos and their branches. This is rather creating an impression of carelessness.

Hopefully this little documentation is helpful for others.
Even more I am hoping that this posting many trigger somebody at Jolla to clean up this mess and tell something about the purpose, relationship and maintenance of all these repositories here.

I added the mer-tools repository by issuing ssu ar mer-tools as root, which appends mer-tools to the line enabled-repos=store, mer-tools in /etc/ssu/ssu.ini.
Question 1: But when I list the subscribed repositories with ssu lr it outputs mer-tools ... https://releases.jolla.com/releases/2.1.3.7/mer-tools/builds/armv7hl/packages/ in the Enabled repositories (user): section, not in the Enabled repositories (global): section, although it is clearly a Jolla supplied repository (by looking at its source link and how it is added in the ssu.ini file)?!?

As most (if not all) of the tools available in Jolla's mer-tools repository seem to be somewhat outdated (by looking at their version numbers compared to a recent desktop Linux distribution), I started searching for the built RPM files at other locations, because I was unable to look up the contents of https://releases.jolla.com/releases/2.1.3.7/mer-tools/builds/armv7hl/packages/ directly. The tedious workaround is to look up RPMs expected in there by using pkcon search name in order to obtain their version numbers.
Question 2: Is there a way to take a look at all RPMs available in Jolla's mer-tools repository directly (e.g. in a web browser, by using the CLI tools zypper or rpm etc.)?

So I started searching the WWW for mer-tools:

• First I looked for development repositories and found:

  • https://git.merproject.org/mer-tools, which solely contains sdk-webapps and has been unmaintained for 4 years (while https://git.merproject.org/ still seems to be the central, active development repository for Mer / SailfishOS, with its compiled packages available at https://build.merproject.org/project/show/mer:core).
  • In contrast to this https://github.com/mer-tools is still maintained (although the tools there are rather rarely updated), but only provides source releases (i.e. tar- / zip-balls). At least one can determine the current version of each tool there, although tediously.
    Question 3: But the version numbers of the recent tar-balls does correspond to the versions available in any other mer-tools repository (looking at e.g. the android-tools package): Where are those packages released in binary form? Is there a process defined for this?

• So I turned over to http://projects.merproject.org/ to look for built packages (i.e. RPMs) and there the real confusion started:

  • In http://projects.merproject.org/releases/ there are "Mer-Tools" and "mer-tools" subdirectories, but they seem to be an exact mirror of each other!?!
    Question 4: Why do these two directories have the exactly same content? Wouldn't it make sense to remove one of them (presumably "Mer-Tools")?

    • In http://projects.merproject.org/releases/mer-tools/ the file "latest-release" points to "8.1.0", thus the packages in e.g. http://projects.merproject.org/releases/mer-tools/latest/builds/armv7hl/packages/armv7hl/ are identical to the 8.1.0 release and are all dated 2013-04-23 (which is quite outdated)! Checking with the packages, which can be obtained from Jolla's mer-tools repository, these are (luckily) newer, so "latest" does not point to the latest packages!
      Question 5: Why are there no newer releases than mer-tools 8.1.0 on 2013-04-28, although the mer-tools are obviously still developed further (see below)?
    • So I took a closer long at the "mer-tools" subdirectory "test", only to see that testing obviously stopped on 2013-06-24, see e.g. http://projects.merproject.org/releases/mer-tools/test/builds/armv7hl/packages/armv7hl/.
      Question 6: Why does the "test" subdirectory still exist, even though it is not used anymore?
    • Then I turned to the last two subdirectories of interest, "next" and "rolling", which are duplicates of each other (again, presumably due to http://projects.merproject.org/releases/mer-tools/next-release pointing to "rolling") and obviously contain automatically generated packages (all packages the are at most a few days old and carry the same build date) and many more packages than all other directories under http://projects.merproject.org/releases/mer-tools/. Unfortunately the auto-generated character of these packages lets me hesitate to install anything from there and this also is clearly not the source of the packages in Jolla's mer-tools repository.
      Question 7: Why do both subdirectories "next" and "rolling" exist, although they share the same content?

  • Thus I kept on searching in http://projects.merproject.org/ and also found "mer-tools:" in http://projects.merproject.org/obs/ with a much cleaner directory structure, although still confusing:

    • The subdirectories "devel:" and "testing:" (those with a colon ":") contain both a directory "Trial:", which in turn obviously contains two different trials, but nothing of interest.
      Question 8: Why do these two subdirectories still exist, if they just have been created for trial purposes in 2013 / 2014?
    • The subdirectory "stable" looks promising (by its name) and really contains packages with build dates ranging from 2013 to 2017 (see e.g. http://projects.merproject.org/obs/mer-tools:/stable/latest_armv7hl/armv7hl/), so it looks properly maintained. But when comparing package versions there with what is available in Jolla's mer-tools repository, they differ: Some packages provided by Jolla are older (e.g. dosfstools), some are newer (e.g. btrfs-progs, android-tools) android-tools), judging by their version numbers.
    • The subdirectory "devel" also lives up to its name, as all packages are either the same or newer than in the "stable" directory (by build date and version numbers, see e.g. http://projects.merproject.org/obs/mer-tools:/devel/latest_armv7hl/armv7hl/). Only the "android-tools" package is newer by date in the "stable" directory, although it carries a lower version number (at least this is the only confusing package I have found by quickly glancing over the packages)!?! The packages there also differ from Jolla's mer-tools repository: While the "btrfs-progs" package provided by Jolla is newer (by version number), all other packages from Jolla seem to be older (e.g. dosfstools, android-tools). It also differs a lot from http://projects.merproject.org/releases/mer-tools/rolling/ (by version numbers and naturally by build dates of the packages).
    • In contrast to that, the "testing" subdirectory contains older packages (with build dates ranging from 2013 to 2015, see e.g. http://projects.merproject.org/obs/mer-tools:/testing/latest_armv7hl/armv7hl/) than the "stable" directory, also with the exception of the "android-tools" package, which also is older by date, but newer by version than the one in "stable" (but much older than the one in "devel").
      Question 9: Why does the "testing" directory still exist, if it is not used anymore (and contains older packages than "stable")?

• Ultimately I remembered that NielDK provides a lot of updated packages for SailfishOS in his OpenRepos repository, so I started looking here at the Mer-OBS and found http://repo.merproject.org/obs/home:/nielnielsen/, which provides much newer (by version) packages than all aforementioned repositories (see e.g. http://repo.merproject.org/obs/home:/nielnielsen/sailfish_latest_armv7hl/armv7hl/), but these packages supposedly have not undergone much testing. Kudos to @NielDK for providing these, although enabling his OpenRepos or Mer-OBS repository is IMO somewhat dangerous, as one can accidentally update half of the installed SailfishOS to newer components by either automatic dependency resolution when installing a package or a simple pkcon update; still, when a feature is not available in the quite old (although recently built) versions in Jolla's mer-tools repository or http://projects.merproject.org/obs/mer-tools:/stable/ (or ../devel or http://projects.merproject.org/releases/mer-tools/rolling/), Niel provides a source for much newer packages (thanks!).

• As all these different mer-tools repositories are quite confusing, I searched the WWW again for some meta-information:
  https://wiki.merproject.org/wiki/Tools provides some information, but much of that does not seem to be correct (e.g. the pointers to "Mer:Tools" and "Mer:Tools:Testing" repositories at the Mer-OBS, which do not exist), even though this wiki page has been last updated 2016-06-27.

To summarise this research journey:

• Still have not found the source for the packages in Jolla's mer-tools repository at https://releases.jolla.com/releases/2.1.3.7/mer-tools/builds/armv7hl/packages/, neither their sources or at least all their versions and build dates (or the process from ine to the other)..other).
• Found http://projects.merproject.org/obs/mer-tools:/stable/ which mostly provides slightly newer packages than Jolla (but not for all packages) and looks trustworthy, but its relationship to Jolla's mer-tools repository is unclear. Hence I refrain from simply enabling this repository, but may try single packages downloaded manually, if issues with a Jolla provided one should arise.
• http://projects.merproject.org/obs/mer-tools:/devel/ provides newer packages than its "stable" version and looks better maintained than http://projects.merproject.org/releases/mer-tools/rolling/, but the specifics of these repositories (who is maintaining them, why do they exist in parallel, how much QA have those packages undergone?) are absolutely unclear to me.
• The "android-tools" package seems to be an outlier across these repositories WRT its version and build date.
• http://repo.merproject.org/obs/home:/nielnielsen/ provides much newer versions of all mer-tools packages (plus many components of the SailfishOS proper), but should be used very carefully, IMO (i.e. you should exactly know what you are doing and how to return to a known good state).
• Found lots and lots of old cruft while researching the state of mer-tools!
• All in all, the mer-tools do not appear to be properly maintained in general, structurally (too many repositories and dead directories) and by looking at the diverting versions in the maintained repos and their branches. This is rather creating an impression of carelessness.

Hopefully this little documentation is helpful for others.
Even more I am hoping that this posting many trigger somebody at Jolla to clean up this mess and tell something about the purpose, relationship and maintenance of all these repositories here.

I added the mer-tools repository by issuing ssu ar mer-tools as root, which appends mer-tools to the line enabled-repos=store, mer-tools in /etc/ssu/ssu.ini.
Question 1: But when I list the subscribed repositories with ssu lr it outputs mer-tools ... https://releases.jolla.com/releases/2.1.3.7/mer-tools/builds/armv7hl/packages/ in the Enabled repositories (user): section, not in the Enabled repositories (global): section, although it is clearly a Jolla supplied repository (by looking at its source link and how it is added in the ssu.ini file)?!?

As most (if not all) of the tools available in Jolla's mer-tools repository seem to be somewhat outdated (by looking at their version numbers compared to a recent desktop Linux distribution), I started searching for the built RPM files at other locations, because I was unable to look up the contents of https://releases.jolla.com/releases/2.1.3.7/mer-tools/builds/armv7hl/packages/ directly. The tedious workaround is to look up RPMs expected in there by using pkcon search name in order to obtain their version numbers.
Question 2: Is there a way to take a look at all RPMs available in Jolla's mer-tools repository directly (e.g. in a web browser, by using the CLI tools zypper or rpm etc.)?

So I started searching the WWW for mer-tools:

• First I looked for development repositories and found:

  • https://git.merproject.org/mer-tools, which solely contains sdk-webapps and has been unmaintained for 4 years (while https://git.merproject.org/ still seems to be the central, active development repository for Mer / SailfishOS, with its compiled packages available at https://build.merproject.org/project/show/mer:core).
  • In contrast to this https://github.com/mer-tools is still maintained (although the tools there are rather rarely updated), but only provides source releases (i.e. tar- / zip-balls). At least one can determine the current version of each tool there, although tediously.
    Question 3: But the version numbers of the recent tar-balls does correspond to the versions available in any other mer-tools repository (looking at e.g. the android-tools package): Where are those packages released in binary form? Is there a process defined for this?

• So I turned over to http://projects.merproject.org/ to look for built packages (i.e. RPMs) and there the real confusion started:

  • In http://projects.merproject.org/releases/ there are "Mer-Tools" and "mer-tools" subdirectories, but they seem to be an exact mirror of each other!?!
    Question 4: Why do these two directories have the exactly same content? Wouldn't it make sense to remove one of them (presumably "Mer-Tools")?

    • In http://projects.merproject.org/releases/mer-tools/ the file "latest-release" points to "8.1.0", thus the packages in e.g. http://projects.merproject.org/releases/mer-tools/latest/builds/armv7hl/packages/armv7hl/ are identical to the 8.1.0 release and are all dated 2013-04-23 (which is quite outdated)! Checking with the packages, which can be obtained from Jolla's mer-tools repository, these are (luckily) newer, so "latest" does not point to the latest packages!
      Question 5: Why are there no newer releases than mer-tools 8.1.0 on 2013-04-28, although the mer-tools are obviously still developed further (see below)?
    • So I took a closer long at the "mer-tools" subdirectory "test", only to see that testing obviously stopped on 2013-06-24, see e.g. http://projects.merproject.org/releases/mer-tools/test/builds/armv7hl/packages/armv7hl/.
      Question 6: Why does the "test" subdirectory still exist, even though it is not used anymore?
    • Then I turned to the last two subdirectories of interest, "next" and "rolling", which are duplicates of each other (again, presumably due to http://projects.merproject.org/releases/mer-tools/next-release pointing to "rolling") and obviously contain automatically generated packages (all packages the are at most a few days old and carry the same build date) and many more packages than all other directories under http://projects.merproject.org/releases/mer-tools/. Unfortunately the auto-generated character of these packages lets me hesitate to install anything from there and this also is clearly not the source of the packages in Jolla's mer-tools repository.
      Question 7: Why do both subdirectories "next" and "rolling" exist, although they share the same content?

  • Thus I kept on searching in http://projects.merproject.org/ and also found "mer-tools:" in http://projects.merproject.org/obs/ with a much cleaner directory structure, although still confusing:

    • The subdirectories "devel:" and "testing:" (those with a colon ":") contain both a directory "Trial:", which in turn obviously contains two different trials, but nothing of interest.
      Question 8: Why do these two subdirectories still exist, if they just have been created for trial purposes in 2013 / 2014?
    • The subdirectory "stable" looks promising (by its name) and really contains packages with build dates ranging from 2013 to 2017 (see e.g. http://projects.merproject.org/obs/mer-tools:/stable/latest_armv7hl/armv7hl/), so it looks properly maintained. But when comparing package versions there with what is available in Jolla's mer-tools repository, they differ: Some packages provided by Jolla are older (e.g. dosfstools), some are newer (e.g. btrfs-progs, android-tools), judging by their version numbers.
    • The subdirectory "devel" also lives up to its name, as all packages are either the same or newer than in the "stable" directory (by build date and version numbers, see e.g. http://projects.merproject.org/obs/mer-tools:/devel/latest_armv7hl/armv7hl/). Only the "android-tools" package is newer by date in the "stable" directory, although it carries a lower version number (at least this is the only confusing package I have found by quickly glancing over the packages)!?! The packages there also differ from Jolla's mer-tools repository: While the "btrfs-progs" package provided by Jolla is newer (by version number), all other packages from Jolla seem to be older (e.g. dosfstools, android-tools). It also differs a lot from http://projects.merproject.org/releases/mer-tools/rolling/ (by version numbers and naturally by build dates of the packages).
    • In contrast to that, the "testing" subdirectory contains older packages (with build dates ranging from 2013 to 2015, see e.g. http://projects.merproject.org/obs/mer-tools:/testing/latest_armv7hl/armv7hl/) than the "stable" directory, also with the exception of the "android-tools" package, which also is older by date, but newer by version than the one in "stable" (but much older than the one in "devel").
      Question 9: Why does the "testing" directory still exist, if it is not used anymore (and contains older packages than "stable")?

• Ultimately I remembered that NielDK provides a lot of updated packages for SailfishOS in his OpenRepos repository, so I started looking here at the Mer-OBS and found http://repo.merproject.org/obs/home:/nielnielsen/, which provides much newer (by version) packages than all aforementioned repositories (see e.g. http://repo.merproject.org/obs/home:/nielnielsen/sailfish_latest_armv7hl/armv7hl/), but these packages supposedly have not undergone much testing. Kudos to @NielDK for providing these, although enabling his OpenRepos or Mer-OBS repository is IMO somewhat dangerous, as one can accidentally update half of the installed SailfishOS to newer components by either automatic dependency resolution when installing a package or a simple pkcon update; still, when a feature is not available in the quite old (although recently built) versions in Jolla's mer-tools repository or http://projects.merproject.org/obs/mer-tools:/stable/ (or ../devel or http://projects.merproject.org/releases/mer-tools/rolling/), Niel provides a source for much newer packages (thanks!).

• As all these different mer-tools repositories are quite confusing, I searched the WWW again for some meta-information:
  https://wiki.merproject.org/wiki/Tools provides some information, but much of that does not seem to be correct (e.g. the pointers to "Mer:Tools" and "Mer:Tools:Testing" repositories at the Mer-OBS, which do not exist), even though this wiki page has been last updated 2016-06-27.

To summarise this research journey:

• Still have not found the source for the packages in Jolla's mer-tools repository at https://releases.jolla.com/releases/2.1.3.7/mer-tools/builds/armv7hl/packages/, neither their sources or at least all their versions and build dates (or the process from ine to the other).
• Found http://projects.merproject.org/obs/mer-tools:/stable/ which mostly provides slightly newer packages than Jolla (but not for all packages) and looks trustworthy, but its relationship to Jolla's mer-tools repository is unclear. Hence I refrain from simply enabling this repository, but may try single packages downloaded manually, if issues with a Jolla provided one should arise.
• http://projects.merproject.org/obs/mer-tools:/devel/ provides newer packages than its "stable" version and looks better maintained than http://projects.merproject.org/releases/mer-tools/rolling/, but the specifics of these repositories (who is maintaining them, why do they exist in parallel, how much QA have those packages undergone?) are absolutely unclear to me.
• The "android-tools" package seems to be an outlier across these repositories WRT its version and build date.
• http://repo.merproject.org/obs/home:/nielnielsen/ provides much newer versions of all mer-tools packages (plus many components of the SailfishOS proper), but should be used very carefully, IMO (i.e. you should exactly know what you are doing and how to return to a known good state).
• Found lots and lots of old cruft while researching the state of mer-tools!
• All in all, the mer-tools do not appear to be properly maintained in general, structurally (too many repositories and dead directories) and by looking at the diverting versions in the maintained repos and their branches. This is rather creating an impression of carelessness.

Hopefully this little documentation is helpful for others.
Even more I am hoping that this posting many trigger somebody at Jolla to clean up this mess and tell something about the purpose, relationship and maintenance of all these repositories here. here.

I added the mer-tools repository by issuing ssu ar mer-tools as root, which appends mer-tools to the line enabled-repos=store, mer-tools in /etc/ssu/ssu.ini.
Question 1: But when I list the subscribed repositories with ssu lr it outputs mer-tools ... https://releases.jolla.com/releases/2.1.3.7/mer-tools/builds/armv7hl/packages/ in the Enabled repositories (user): section, not in the Enabled repositories (global): section, although it is clearly a Jolla supplied repository (by looking at its source link and how it is added in the ssu.ini file)?!?

As most (if not all) of the tools available in Jolla's mer-tools repository seem to be somewhat outdated (by looking at their version numbers compared to a recent desktop Linux distribution), I started searching for the built RPM files at other locations, because I was unable to look up the contents of https://releases.jolla.com/releases/2.1.3.7/mer-tools/builds/armv7hl/packages/ directly. The tedious workaround is to look up RPMs expected in there by using pkcon search name in order to obtain their version numbers.
Question 2: Is there a way to take a look at all RPMs available in Jolla's mer-tools repository directly (e.g. in a web browser, by using the CLI tools zypper or rpm etc.)?

So I started searching the WWW for mer-tools:

• First I looked for development repositories and found:

  • https://git.merproject.org/mer-tools, which solely contains sdk-webapps and has been unmaintained for 4 years (while https://git.merproject.org/ still seems to be the central, active development repository for Mer / SailfishOS, with its compiled packages available at https://build.merproject.org/project/show/mer:core).
  • In contrast to this https://github.com/mer-tools is still maintained (although the tools there are rather rarely updated), but only provides source releases (i.e. tar- / zip-balls). At least one can determine the current version of each tool there, although tediously.
    Question 3: But the version numbers of the recent tar-balls tar-ball releases there does not correspond to the versions available in any other mer-tools repository (looking at the ones mentioned below, e.g. for the android-tools package): Where are those packages released in binary form? Is there a process defined for this?

• So I turned over to http://projects.merproject.org/ to look for built packages (i.e. RPMs) and there the real confusion started:

  • In http://projects.merproject.org/releases/ there are "Mer-Tools" and "mer-tools" subdirectories, but they seem to be an exact mirror of each other!?!
    Question 4: Why do these two directories have the exactly same content? Wouldn't it make sense to remove one of them (presumably "Mer-Tools")?

    • In http://projects.merproject.org/releases/mer-tools/ the file "latest-release" points to "8.1.0", thus the packages in e.g. http://projects.merproject.org/releases/mer-tools/latest/builds/armv7hl/packages/armv7hl/ are identical to the 8.1.0 release and are all dated 2013-04-23 (which is quite outdated)! Checking with the packages, which can be obtained from Jolla's mer-tools repository, these are (luckily) newer, so "latest" does not point to the latest packages!
      Question 5: Why are there no newer releases than mer-tools 8.1.0 on 2013-04-28, although the mer-tools are obviously still developed further (see below)?
    • So I took a closer long at the "mer-tools" subdirectory "test", only to see that testing obviously stopped on 2013-06-24, see e.g. http://projects.merproject.org/releases/mer-tools/test/builds/armv7hl/packages/armv7hl/.
      Question 6: Why does the "test" subdirectory still exist, even though it is not used anymore?
    • Then I turned to the last two subdirectories of interest, "next" and "rolling", which are duplicates of each other (again, presumably due to http://projects.merproject.org/releases/mer-tools/next-release pointing to "rolling") and obviously contain automatically generated packages (all packages the are at most a few days old and carry the same build date) and many more packages than all other directories under http://projects.merproject.org/releases/mer-tools/. Unfortunately the auto-generated character of these packages lets me hesitate to install anything from there and this also is clearly not the source of the packages in Jolla's mer-tools repository.
      Question 7: Why do both subdirectories "next" and "rolling" exist, although they share the same content?

  • Thus I kept on searching in http://projects.merproject.org/ and also found "mer-tools:" in http://projects.merproject.org/obs/ with a much cleaner directory structure, although still confusing:

    • The subdirectories "devel:" and "testing:" (those with a colon ":") contain both a directory "Trial:", which in turn obviously contains two different trials, but nothing of interest.
      Question 8: Why do these two subdirectories still exist, if they just have been created for trial purposes in 2013 / 2014?
    • The subdirectory "stable" looks promising (by its name) and really contains packages with build dates ranging from 2013 to 2017 (see e.g. http://projects.merproject.org/obs/mer-tools:/stable/latest_armv7hl/armv7hl/), so it looks properly maintained. But when comparing package versions there with what is available in Jolla's mer-tools repository, they differ: Some packages provided by Jolla are older (e.g. dosfstools), some are newer (e.g. btrfs-progs, android-tools), judging by their version numbers.
    • The subdirectory "devel" also lives up to its name, as all packages are either the same or newer than in the "stable" directory (by build date and version numbers, see e.g. http://projects.merproject.org/obs/mer-tools:/devel/latest_armv7hl/armv7hl/). Only the "android-tools" package is newer by date in the "stable" directory, although it carries a lower version number (at least this is the only confusing package I have found by quickly glancing over the packages)!?! The packages there also differ from Jolla's mer-tools repository: While the "btrfs-progs" package provided by Jolla is newer (by version number), all other packages from Jolla seem to be older (e.g. dosfstools, android-tools). It also differs a lot from http://projects.merproject.org/releases/mer-tools/rolling/ (by version numbers and naturally by build dates of the packages).
    • In contrast to that, the "testing" subdirectory contains older packages (with build dates ranging from 2013 to 2015, see e.g. http://projects.merproject.org/obs/mer-tools:/testing/latest_armv7hl/armv7hl/) than the "stable" directory, also with the exception of the "android-tools" package, which also is older by date, but newer by version than the one in "stable" (but much older than the one in "devel").
      Question 9: Why does the "testing" directory still exist, if it is not used anymore (and contains older packages than "stable")?

• Ultimately I remembered that NielDK provides a lot of updated packages for SailfishOS in his OpenRepos repository, so I started looking here at the Mer-OBS and found http://repo.merproject.org/obs/home:/nielnielsen/, which provides much newer (by version) packages than all aforementioned repositories (see e.g. http://repo.merproject.org/obs/home:/nielnielsen/sailfish_latest_armv7hl/armv7hl/), but these packages supposedly have not undergone much testing. Kudos to @NielDK for providing these, although enabling his OpenRepos or Mer-OBS repository is IMO somewhat dangerous, as one can accidentally update half of the installed SailfishOS to newer components by either automatic dependency resolution when installing a package or a simple pkcon update; still, when a feature is not available in the quite old (although recently built) versions in Jolla's mer-tools repository or http://projects.merproject.org/obs/mer-tools:/stable/ (or ../devel or http://projects.merproject.org/releases/mer-tools/rolling/), Niel provides a source for much newer packages (thanks!).

• As all these different mer-tools repositories are quite confusing, I searched the WWW again for some meta-information:
  https://wiki.merproject.org/wiki/Tools provides some information, but much of that does not seem to be correct (e.g. the pointers to "Mer:Tools" and "Mer:Tools:Testing" repositories at the Mer-OBS, which do not exist), even though this wiki page has been last updated 2016-06-27.

To summarise this research journey:

• Still have not found the source for the binary packages in Jolla's mer-tools repository at https://releases.jolla.com/releases/2.1.3.7/mer-tools/builds/armv7hl/packages/, neither their sources or at least all their versions and build dates (or the process from ine to the other).
• Found http://projects.merproject.org/obs/mer-tools:/stable/ which mostly provides slightly newer packages than Jolla (but not for all packages) and looks trustworthy, but its relationship to Jolla's mer-tools repository is unclear. Hence I refrain from simply enabling this repository, but may try single packages downloaded manually, if issues with a Jolla provided one should arise.
• http://projects.merproject.org/obs/mer-tools:/devel/ provides newer packages than its "stable" version and looks better maintained than http://projects.merproject.org/releases/mer-tools/rolling/, but the specifics of these repositories (who is maintaining them, why do they exist in parallel, how much QA have those packages undergone?) are absolutely unclear to me.
• The "android-tools" package seems to be an outlier across these repositories WRT its version and build date.
• http://repo.merproject.org/obs/home:/nielnielsen/ provides much newer versions of all mer-tools packages (plus many components of the SailfishOS proper), but should be used very carefully, IMO (i.e. you should exactly know what you are doing and how to return to a known good state).
• Found lots and lots of old cruft while researching the state of mer-tools!
• All in all, the mer-tools do not appear to be properly maintained in general, structurally (too many repositories and dead directories) and by looking at the diverting versions in the maintained repos and their branches. This is rather creating an impression of carelessness.

Hopefully this little documentation is helpful for others.
Even more I am hoping that this posting many trigger somebody at Jolla to clean up this mess and tell something about the purpose, relationship and maintenance of all these repositories here.

Edit: A tiny bit of progress in understanding of the workflow and relationships.
The version numbers shown when descending in https://build.merproject.org/project/subprojects/mer-tools seem to correspond with the ones when looking at specific source tar-ball releases at https://github.com/mer-tools.
And structurally https://build.merproject.org/project/subprojects/mer-tools corresponds to the three non-trial directories in http://projects.merproject.org/obs/mer-tools:/, but the build dates and version numbers do not match (although the file list seems to match)?!?
Another conundrum, and no connection at all to Jolla's mer-tools and the ones at http://projects.merproject.org/releases/mer-tools/.

I added the mer-tools repository by issuing ssu ar mer-tools as root, which appends mer-tools to the line enabled-repos=store, mer-tools in /etc/ssu/ssu.ini.
Question 1: But when I list the subscribed repositories with ssu lr it outputs mer-tools ... https://releases.jolla.com/releases/2.1.3.7/mer-tools/builds/armv7hl/packages/ in the Enabled repositories (user): section, not in the Enabled repositories (global): section, although it is clearly a Jolla supplied repository (by looking at its source link and how it is added in the ssu.ini file)?!?

As most (if not all) of the tools available in Jolla's mer-tools repository seem to be somewhat outdated (by looking at their version numbers compared to a recent desktop Linux distribution), I started searching for the built RPM files at other locations, because I was unable to look up the contents of https://releases.jolla.com/releases/2.1.3.7/mer-tools/builds/armv7hl/packages/ directly. The tedious workaround is to look up RPMs expected in there by using pkcon search name in order to obtain their version numbers.
Question 2: Is there a way to take a look at all RPMs available in Jolla's mer-tools repository directly (e.g. in a web browser, by using the CLI tools zypper or rpm etc.)?

So I started searching the WWW for mer-tools:

• First I looked for development repositories and found:

  • https://git.merproject.org/mer-tools, which solely contains sdk-webapps and has been unmaintained for 4 years (while https://git.merproject.org/ still seems to be the central, active development repository for Mer / SailfishOS, with its compiled packages available at https://build.merproject.org/project/show/mer:core).
  • In contrast to this https://github.com/mer-tools is still maintained (although the tools there are rather rarely updated), but only provides source releases (i.e. tar- / zip-balls). At least one can determine the current version of each tool there, although tediously.
    Question 3: But the version numbers of the recent tar-ball releases there does not correspond to the versions available in any other mer-tools repository (looking at the ones mentioned below, e.g. for the android-tools package): Where are those packages released in binary form? Is there a process defined for this?

• So I turned over to http://projects.merproject.org/ to look for built packages (i.e. RPMs) and there the real confusion started:

  • In http://projects.merproject.org/releases/ there are "Mer-Tools" and "mer-tools" subdirectories, but they seem to be an exact mirror of each other!?!
    Question 4: Why do these two directories have the exactly same content? Wouldn't it make sense to remove one of them (presumably "Mer-Tools")?

    • In http://projects.merproject.org/releases/mer-tools/ the file "latest-release" points to "8.1.0", thus the packages in e.g. http://projects.merproject.org/releases/mer-tools/latest/builds/armv7hl/packages/armv7hl/ are identical to the 8.1.0 release and are all dated 2013-04-23 (which is quite outdated)! Checking with the packages, which can be obtained from Jolla's mer-tools repository, these are (luckily) newer, so "latest" does not point to the latest packages!
      Question 5: Why are there no newer releases than mer-tools 8.1.0 on 2013-04-28, although the mer-tools are obviously still developed further (see below)?
    • So I took a closer long at the "mer-tools" subdirectory "test", only to see that testing obviously stopped on 2013-06-24, see e.g. http://projects.merproject.org/releases/mer-tools/test/builds/armv7hl/packages/armv7hl/.
      Question 6: Why does the "test" subdirectory still exist, even though it is not used anymore?
    • Then I turned to the last two subdirectories of interest, "next" and "rolling", which are duplicates of each other (again, presumably due to http://projects.merproject.org/releases/mer-tools/next-release pointing to "rolling") and obviously contain automatically generated packages (all packages the are at most a few days old and carry the same build date) and many more packages than all other directories under http://projects.merproject.org/releases/mer-tools/. Unfortunately the auto-generated character of these packages lets me hesitate to install anything from there and this also is clearly not the source of the packages in Jolla's mer-tools repository.
      Question 7: Why do both subdirectories "next" and "rolling" exist, although they share the same content?

  • Thus I kept on searching in http://projects.merproject.org/ and also found "mer-tools:" in http://projects.merproject.org/obs/ with a much cleaner directory structure, although still confusing:

    • The subdirectories "devel:" and "testing:" (those with a colon ":") contain both a directory "Trial:", which in turn obviously contains two different trials, but nothing of interest.
      Question 8: Why do these two subdirectories still exist, if they just have been created for trial purposes in 2013 / 2014?
    • The subdirectory "stable" looks promising (by its name) and really contains packages with build dates ranging from 2013 to 2017 (see e.g. http://projects.merproject.org/obs/mer-tools:/stable/latest_armv7hl/armv7hl/), so it looks properly maintained. But when comparing package versions there with what is available in Jolla's mer-tools repository, they differ: Some packages provided by Jolla are older (e.g. dosfstools), some are newer (e.g. btrfs-progs, android-tools), judging by their version numbers.
    • The subdirectory "devel" also lives up to its name, as all packages are either the same or newer than in the "stable" directory (by build date and version numbers, see e.g. http://projects.merproject.org/obs/mer-tools:/devel/latest_armv7hl/armv7hl/). Only the "android-tools" package is newer by date in the "stable" directory, although it carries a lower version number (at least this is the only confusing package I have found by quickly glancing over the packages)!?! The packages there also differ from Jolla's mer-tools repository: While the "btrfs-progs" package provided by Jolla is newer (by version number), all other packages from Jolla seem to be older (e.g. dosfstools, android-tools). It also differs a lot from http://projects.merproject.org/releases/mer-tools/rolling/ (by version numbers and naturally by build dates of the packages).
    • In contrast to that, the "testing" subdirectory contains older packages (with build dates ranging from 2013 to 2015, see e.g. http://projects.merproject.org/obs/mer-tools:/testing/latest_armv7hl/armv7hl/) than the "stable" directory, also with the exception of the "android-tools" package, which also is older by date, but newer by version than the one in "stable" (but much older than the one in "devel").
      Question 9: Why does the "testing" directory still exist, if it is not used anymore (and contains older packages than "stable")?

• Ultimately I remembered that NielDK provides a lot of updated packages for SailfishOS in his OpenRepos repository, so I started looking here at the Mer-OBS and found http://repo.merproject.org/obs/home:/nielnielsen/, which provides much newer (by version) packages than all aforementioned repositories (see e.g. http://repo.merproject.org/obs/home:/nielnielsen/sailfish_latest_armv7hl/armv7hl/), but these packages supposedly have not undergone much testing. Kudos to @NielDK for providing these, although enabling his OpenRepos or Mer-OBS repository is IMO somewhat dangerous, as one can accidentally update half of the installed SailfishOS to newer components by either automatic dependency resolution when installing a package or a simple pkcon update; still, when a feature is not available in the quite old (although recently built) versions in Jolla's mer-tools repository or http://projects.merproject.org/obs/mer-tools:/stable/ (or ../devel or http://projects.merproject.org/releases/mer-tools/rolling/), Niel provides a source for much newer packages (thanks!).

• As all these different mer-tools repositories are quite confusing, I searched the WWW again for some meta-information:
  https://wiki.merproject.org/wiki/Tools provides some information, but much of that does not seem to be correct (e.g. the pointers to "Mer:Tools" and "Mer:Tools:Testing" repositories at the Mer-OBS, which do not exist), even though this wiki page has been last updated 2016-06-27.

To summarise this research journey:

• Still have not found the source for the binary packages in Jolla's mer-tools repository at https://releases.jolla.com/releases/2.1.3.7/mer-tools/builds/armv7hl/packages/, neither their sources or at least all their versions and build dates (or the process from ine one to the other).
• Found http://projects.merproject.org/obs/mer-tools:/stable/ which mostly provides slightly newer packages than Jolla (but not for all packages) and looks trustworthy, but its relationship to Jolla's mer-tools repository is unclear. Hence I refrain from simply enabling this repository, but may try single packages downloaded manually, if issues with a Jolla provided one should arise.
• http://projects.merproject.org/obs/mer-tools:/devel/ provides newer packages than its "stable" version and looks better maintained than http://projects.merproject.org/releases/mer-tools/rolling/, but the specifics of these repositories (who is maintaining them, why do they exist in parallel, how much QA have those packages undergone?) are absolutely unclear to me.
• The "android-tools" package seems to be an outlier across these repositories WRT its version and build date.
• http://repo.merproject.org/obs/home:/nielnielsen/ provides much newer versions of all mer-tools packages (plus many components of the SailfishOS proper), but should be used very carefully, IMO (i.e. you should exactly know what you are doing and how to return to a known good state).
• Found lots and lots of old cruft while researching the state of mer-tools!
• All in all, the mer-tools do not appear to be properly maintained in general, structurally (too many repositories and dead directories) and by looking at the diverting versions in the maintained repos and their branches. This is rather creating an impression of carelessness.

Hopefully this little documentation is helpful for others.
Even more I am hoping that this posting many trigger somebody at Jolla to clean up this mess and tell something about the purpose, relationship and maintenance of all these repositories here.

Edit: A tiny bit of progress in understanding of the workflow and relationships.
The version numbers shown when descending in https://build.merproject.org/project/subprojects/mer-tools seem to correspond with the ones when looking at specific source tar-ball releases at https://github.com/mer-tools.
And structurally https://build.merproject.org/project/subprojects/mer-tools corresponds to the three non-trial directories in http://projects.merproject.org/obs/mer-tools:/, but the build dates and version numbers do not match (although the file list seems to match)?!?
Another conundrum, and no connection at all to Jolla's mer-tools and the ones at http://projects.merproject.org/releases/mer-tools/.

I added the mer-tools repository by issuing ssu ar mer-tools as root, which appends mer-tools to the line enabled-repos=store, mer-tools in /etc/ssu/ssu.ini.
Question 1: But when I list the subscribed repositories with ssu lr it outputs mer-tools ... https://releases.jolla.com/releases/2.1.3.7/mer-tools/builds/armv7hl/packages/ in the Enabled repositories (user): section, not in the Enabled repositories (global): section, although it is clearly a Jolla supplied repository (by looking at its source link and how it is added in the ssu.ini file)?!?

As most (if not all) of the tools available in Jolla's mer-tools repository seem to be somewhat outdated (by looking at their version numbers compared to a recent desktop Linux distribution), I started searching for the built RPM files at other locations, because I was unable to look up the contents of https://releases.jolla.com/releases/2.1.3.7/mer-tools/builds/armv7hl/packages/ directly. The tedious workaround is to look up RPMs expected in there by using pkcon search name in order to obtain their version numbers.
Question 2: Is there a way to take a look at all RPMs available in Jolla's mer-tools repository directly (e.g. in a web browser, by using the CLI tools zypper or rpm etc.)?

So I started searching the WWW for mer-tools:

To summarise this research journey:

• Still have not found the source for the binary packages in Jolla's mer-tools repository at https://releases.jolla.com/releases/2.1.3.7/mer-tools/builds/armv7hl/packages/, neither their sources or at least all their versions and build dates (or the process from one to the other).
• Found http://projects.merproject.org/obs/mer-tools:/stable/ which mostly provides slightly newer packages than Jolla (but not for all packages) and looks trustworthy, but its relationship to Jolla's mer-tools repository is unclear. Hence I refrain from simply enabling this repository, but may try single packages downloaded manually, if issues with a Jolla provided one should arise.
• http://projects.merproject.org/obs/mer-tools:/devel/ provides newer packages than its "stable" version and looks better maintained than http://projects.merproject.org/releases/mer-tools/rolling/, but the specifics of these repositories (who is maintaining them, why do they exist in parallel, how much QA have those packages undergone?) are absolutely unclear to me.
• The "android-tools" package seems to be an outlier across these repositories WRT its version and build date.
• http://repo.merproject.org/obs/home:/nielnielsen/ provides much newer versions of all mer-tools packages (plus many components of the SailfishOS proper), but should be used very carefully, IMO (i.e. you should exactly know what you are doing and how to return to a known good state).
• Found lots and lots of old cruft while researching the state of mer-tools!
• All in all, the mer-tools do not appear to be properly maintained in general, structurally (too many repositories and dead directories) and by looking at the diverting versions in the maintained repos and their branches. This is rather creating an impression of carelessness.

Hopefully this little documentation is helpful for others.
Even more I am hoping that this posting many trigger somebody at Jolla to clean up this mess and tell something about the purpose, relationship and maintenance of all these repositories here.

Edit: A tiny bit of progress in understanding of the workflow and relationships.
The version numbers shown when descending in https://build.merproject.org/project/subprojects/mer-tools seem to correspond with the ones when looking at specific source tar-ball releases at https://github.com/mer-tools.
And structurally https://build.merproject.org/project/subprojects/mer-tools corresponds to the three non-trial directories in http://projects.merproject.org/obs/mer-tools:/, but the build dates and version numbers do not match (although the file list seems to match)?!?
Another conundrum, and no connection at all to Jolla's mer-tools and the ones at http://projects.merproject.org/releases/mer-tools/.

I added the mer-tools repository by issuing ssu ar mer-tools as root, which appends mer-tools to the line enabled-repos=store, mer-tools in /etc/ssu/ssu.ini.
Question 1: But when I list the subscribed repositories with ssu lr it outputs mer-tools ... https://releases.jolla.com/releases/2.1.3.7/mer-tools/builds/armv7hl/packages/ in the Enabled repositories (user): section, not in the Enabled repositories (global): section, although it is clearly a Jolla supplied repository (by looking at its source link and how it is added in the ssu.ini file)?!?

As most (if not all) of the tools available in Jolla's mer-tools repository seem to be somewhat outdated (by looking at their version numbers compared to a recent desktop Linux distribution), I started searching for the built RPM files at other locations, because I was unable to look up the contents of https://releases.jolla.com/releases/2.1.3.7/mer-tools/builds/armv7hl/packages/ directly. The tedious workaround is to look up RPMs expected in there by using pkcon search name in order to obtain their version numbers.
Question 2: Is there a way to take a look at all RPMs available in Jolla's mer-tools repository directly (e.g. in a web browser, by using the CLI tools zypper or rpm etc.)?

So I started searching the WWW for mer-tools:

1. First I looked for development repositories and found:

   • https://git.merproject.org/mer-tools, which solely contains sdk-webapps and has been unmaintained for 4 years (while https://git.merproject.org/ still seems to be the central, active development repository for Mer / SailfishOS, with its compiled packages available at https://build.merproject.org/project/show/mer:core).
   • In contrast to this https://github.com/mer-tools is still maintained (although the tools there are rather rarely updated), but only provides source releases (i.e. tar- / zip-balls). At least one can determine the current version of each tool there, although tediously.
     Question 3: But the version numbers of the recent tar-ball releases there does not correspond to the versions available in any other mer-tools repository (looking at the ones mentioned below, e.g. for the android-tools package): Where are those packages released in binary form? Is there a process defined for this?

2. So I turned over to http://projects.merproject.org/ to look for built packages (i.e. RPMs) and there the real confusion started:

   • In http://projects.merproject.org/releases/ there are "Mer-Tools" and "mer-tools" subdirectories, but they seem to be an exact mirror of each other!?!
     Question 4: Why do these two directories have the exactly same content? Wouldn't it make sense to remove one of them (presumably "Mer-Tools")?

     • In http://projects.merproject.org/releases/mer-tools/ the file "latest-release" points to "8.1.0", thus the packages in e.g. http://projects.merproject.org/releases/mer-tools/latest/builds/armv7hl/packages/armv7hl/ are identical to the 8.1.0 release and are all dated 2013-04-23 (which is quite outdated)! Checking with the packages, which can be obtained from Jolla's mer-tools repository, these are (luckily) newer, so "latest" does not point to the latest packages!
       Question 5: Why are there no newer releases than mer-tools 8.1.0 on 2013-04-28, although the mer-tools are obviously still developed further (see below)?
     • So I took a closer long at the "mer-tools" subdirectory "test", only to see that testing obviously stopped on 2013-06-24, see e.g. http://projects.merproject.org/releases/mer-tools/test/builds/armv7hl/packages/armv7hl/.
       Question 6: Why does the "test" subdirectory still exist, even though it is not used anymore?
     • Then I turned to the last two subdirectories of interest, "next" and "rolling", which are duplicates of each other (again, presumably due to http://projects.merproject.org/releases/mer-tools/next-release pointing to "rolling") and obviously contain automatically generated packages (all packages the are at most a few days old and carry the same build date) and many more packages than all other directories under http://projects.merproject.org/releases/mer-tools/. Unfortunately the auto-generated character of these packages lets me hesitate to install anything from there and this also is clearly not the source of the packages in Jolla's mer-tools repository.
       Question 7: Why do both subdirectories "next" and "rolling" exist, although they share the same content?

   • Thus I kept on searching in http://projects.merproject.org/ and also found http://projects.merproject.org/obs/mer-tools:/ with a much cleaner directory structure, although still confusing:

     • The subdirectories "devel:" and "testing:" (those with a colon ":") contain both a directory "Trial:", which in turn obviously contains two different trials, but nothing of interest.
       Question 8: Why do these two subdirectories still exist, if they just have been created for trial purposes in 2013 / 2014?
     • The subdirectory "stable" looks promising (by its name) and really contains packages with build dates ranging from 2013 to 2017 (see e.g. http://projects.merproject.org/obs/mer-tools:/stable/latest_armv7hl/armv7hl/), so it looks properly maintained. But when comparing package versions there with what is available in Jolla's mer-tools repository, they differ: Some packages provided by Jolla are older (e.g. dosfstools), some are newer (e.g. btrfs-progs, android-tools), judging by their version numbers.
     • The subdirectory "devel" also lives up to its name, as all packages are either the same or newer than in the "stable" directory (by build date and version numbers, see e.g. http://projects.merproject.org/obs/mer-tools:/devel/latest_armv7hl/armv7hl/). Only the "android-tools" package is newer by date in the "stable" directory, although it carries a lower version number (at least this is the only confusing package I have found by quickly glancing over the packages)!?! The packages there also differ from Jolla's mer-tools repository: While the "btrfs-progs" package provided by Jolla is newer (by version number), all other packages from Jolla seem to be older (e.g. dosfstools, android-tools). It also differs a lot from http://projects.merproject.org/releases/mer-tools/rolling/ (by version numbers and naturally by build dates of the packages).
     • In contrast to that, the "testing" subdirectory contains older packages (with build dates ranging from 2013 to 2015, see e.g. http://projects.merproject.org/obs/mer-tools:/testing/latest_armv7hl/armv7hl/) than the "stable" directory, also with the exception of the "android-tools" package, which also is older by date, but newer by version than the one in "stable" (but much older than the one in "devel").
       Question 9: Why does the "testing" directory still exist, if it is not used anymore (and contains older packages than "stable")?

3. Ultimately I remembered that NielDK provides a lot of updated packages for SailfishOS in his OpenRepos repository, so I started looking here at the Mer-OBS and found http://repo.merproject.org/obs/home:/nielnielsen/, which provides much newer (by version) packages than all aforementioned repositories (see e.g. http://repo.merproject.org/obs/home:/nielnielsen/sailfish_latest_armv7hl/armv7hl/), but these packages supposedly have not undergone much testing. Kudos to @NielDK for providing these, although enabling his OpenRepos or Mer-OBS repository is IMO somewhat dangerous, as one can accidentally update half of the installed SailfishOS to newer components by either automatic dependency resolution when installing a package or a simple pkcon update; still, when a feature is not available in the quite old (although recently built) versions in Jolla's mer-tools repository or http://projects.merproject.org/obs/mer-tools:/stable/ (or ../devel or http://projects.merproject.org/releases/mer-tools/rolling/), Niel provides a source for much newer packages (thanks!).

4. As all these different mer-tools repositories are quite confusing, I searched the WWW again for some meta-information:
   https://wiki.merproject.org/wiki/Tools provides some information, but much of that does not seem to be correct (e.g. the pointers to "Mer:Tools" and "Mer:Tools:Testing" repositories at the Mer-OBS, which do not exist), even though this wiki page has been last updated 2016-06-27.

To summarise this research journey:

• Still have not found the source for the binary packages in Jolla's mer-tools repository at https://releases.jolla.com/releases/2.1.3.7/mer-tools/builds/armv7hl/packages/, neither their sources or at least all their versions and build dates (or the process from one to the other).
• Found http://projects.merproject.org/obs/mer-tools:/stable/ which mostly provides slightly newer packages than Jolla (but not for all packages) and looks trustworthy, but its relationship to Jolla's mer-tools repository is unclear. Hence I refrain from simply enabling this repository, but may try single packages downloaded manually, if issues with a Jolla provided one should arise.
• http://projects.merproject.org/obs/mer-tools:/devel/ provides newer packages than its "stable" version and looks better maintained than http://projects.merproject.org/releases/mer-tools/rolling/, but the specifics of these repositories (who is maintaining them, why do they exist in parallel, how much QA have those packages undergone?) are absolutely unclear to me.
• The "android-tools" package seems to be an outlier across these repositories WRT its version and build date.
• http://repo.merproject.org/obs/home:/nielnielsen/ provides much newer versions of all mer-tools packages (plus many components of the SailfishOS proper), but should be used very carefully, IMO (i.e. you should exactly know what you are doing and how to return to a known good state).
• Found lots and lots of old cruft while researching the state of mer-tools!
• All in all, the mer-tools do not appear to be properly maintained in general, structurally (too many repositories and dead directories) and by looking at the diverting versions in the maintained repos and their branches. This is rather creating an impression of carelessness.

Hopefully this little documentation is helpful for others.
Even more I am hoping that this posting many trigger somebody at Jolla to clean up this mess and tell something about the purpose, relationship and maintenance of all these repositories here.

Edit: A tiny bit of progress in understanding of the workflow and relationships.
The version numbers shown when descending in https://build.merproject.org/project/subprojects/mer-tools seem to correspond with the ones when looking at specific source tar-ball releases at https://github.com/mer-tools.
And structurally https://build.merproject.org/project/subprojects/mer-tools corresponds to the three non-trial directories in http://projects.merproject.org/obs/mer-tools:/, but the build dates and version numbers do not match (although the file list seems to match)?!?
Another conundrum, and no connection at all to Jolla's mer-tools and the ones at http://projects.merproject.org/releases/mer-tools/.