hello everybody, everytime i pen chum (the gui) it says it's refreshing its repositories but then no app is shown

yesterday was working so maybe it's something related to today's update?

Hi again,

I have also been maintaining ecl and eql5 packages (a framework for using Qt5 in common-lisp) on OpenRepos and I would like to have them on chum.

Repositories are here but will need some rework as per #7 :
https://redmine.casenave.fr/sfos/ecl-spec.git
https://redmine.casenave.fr/sfos/eql5-spec.git

Thanks!

Hi,

I have been maintaining Emacs on OpenRepos and would like to have it on chum instead.
Main repository is here: https://git.savannah.gnu.org/git/emacs.git

Thanks!

Would be great to provide integration with OpenRepos and Storeman. Ideally:

• developers would submit new packages (or updates) to Chum
• users would have their Chum repository pointed to correct SFOS version/arch, as it is now
• users would get updates in OpenRepos stream (web and Storeman) and install from Chum

That way developers don't have to upload to OpenRepos and support for many SFOS versions is automatic. Users get excellent UI and infrastructure of OpenRepos.

Not sure how to implement it and whether OpenRepos API allows fr it already. Would require to discuss it with those who know OpenRepos API and maybe it can be extended for our case.

… for the organisation SailfishOS:Chum, see upper left corner at github.com/sailfishos-chum.

Until a proper, representative icon is created, please re-use the minimalistic, but acceptable icon for the SailfishOS:Chum GUI-client app, rsp. a PNG export of it with transparent background, a size of ≥ 512x512 Px², 1:1 aspect ratio with square pixels (i.e., simply: a spare image) and a file size under 1 MByte.
_{You may also take a look at this GitHub documentation (which adds nothing to aforementioned information): docs.github.com:Creating a custom badge and docs.github.com:Guidelines for logos.}

As described in the README, I am suggesting to either adopt (i.e., fork / clone) FileCase at the SailfishOS:Chum source repository or to just compile and package it at the SailfishOS:Chum OBS.

Its source code is at GitHub, unfortunately @CepiPerez did not assign a license to it (I would suggest to default to the Mozilla Public License 2.0 (MPL-2.0) for a multitude of reasons), but made his intention clear at OpenRepos, that all his unmaintained software shall be FLOSS (Free, Libre, Open Source Software).

The current status AFAICS:

• Cepi has explicitly handed over the maintenance to @llewelld (flypig / David Llewellyn-Jones, a sailor).
• David did quite some maintenance by himself in Q2-2021 and some additional contributions (AFAICS primarily fixes) from @ruditimmer (Rudi Timmermans) were merged in Q3-2021.
• But no new releases were being made available at the usual locations, not in the old repository or a new one at OpenRepos, or in the Jolla Store.
• Only today I found two releases from last year at GitHub, a place at which regular SailfishOS users will not discover software, and from which RPMs have to be manually downloaded and installed.
• Looking at the commit history of FileCase, it seems to be in "minimal maintenance mode" and AFAIR @CepiPerez has stated that he does not own a SailfishOS device since long.

Thus I am suggesting to make FileCase available for a broader audience, again: By offering it via the SailfishOS:Chum repository.

Side note: One topic, which is unclear to me is, if @CepiPerez wishes that his repository stays the "tip / upstream" source code repository (despite having no SFOS device AFAIR).

Opinions, suggestions how to proceed: @CepiPerez, @llewelld, @rinigus, @ruditimmer?

yq is a companion tool to jq which is already in chum.

It takes XML input and passes it on to jq to produce JSON.

This allows nifty scripting along the lines of

 data=$(curl http://foo.com/request_xml_reply | yq)
 curl --data "$data"

See: https://pypi.org/project/yq/ and a PoC packaging at https://build.sailfishos.org/package/show/home:nephros:devel:python/yq

NOTE: If accepted, please advise whether the resulting package should be called plan yq, or python3-yq as it is a python package.

I've packaged python3-wheel for Chum. Could you create a repo for it (repo name python-wheel)?

Hello, I am looking into moving some of the software I merely package and not maintain/write here, with the goals:

• to ease collaborative maintainance.
• where chum packages are currently in tar+spec format, they will br tar_gitted
• (And I want to clean out my github/gitlab/openrepos collections.)

For this I ask for either of these repos be created here.
Feel free to not do it for any of those that you think should not be here - I don't want to cause unnecessary work or clutter.

Notes on relocating the packaging repo from elsewhere:

Some of my packaging repos have quite a messy git history. As it is not important for most things, I plan to not clone but start afresh here. Unless there is a clever way to clone one branch into a fresh git repo? My obs-specific branches tend to be clean enough.

Hi,

I packaged a newer gnutls as well as one of its dependencies, nettle, and would like for them to be part of chum.
You can clone from these repositories:

https://redmine.casenave.fr/projects/gnutls-spec/repository
https://redmine.casenave.fr/projects/nettle-spec/repository

Thanks!

I would love to see https://github.com/Yubico/yubikey-manager in the chum repo. But, thb, I'm not able to get it packaged myself as I'm not experienced enough and I'm really confused with what packages are already there somehow (in the right versions) and what is missing. It is a Python lib. I tried some stuff, by copying things from suse:factory, but still I'm confused with most steps. I would love to take care of the packages (and the chain) but i need some help and guidance to get "on-boarded".

For packaging newer python packages pip is required which is in tools.
Can you add the tools repository path into of chum?

Add databases for supported languages. This may require additional repository in SFOS keyboard organization

Hurray, I am almost finished with making all the descriptions, headlines and terms concise and consistent throughout the SailfishOS:Chum "ecosystem".

One thing left to align is the "About" (at the upper right of the GitHub front-page for sailfishos-chum/main), so it additionally mentions the repository configuration helper RPMs also hosted and maintained here (which the current text "Documentation and issues" lacks).

Thus I am kindly asking a maintainer of this repository to click on the gear icon at the upper right of the GitHub front-page for sailfishos-chum/main (to the right of the text "About") and fill the "Description" field with:

SailfishOS:Chum Documentation, Issue tracker and repository configuration RPM

Hi,

I would like to submit one more package to chum: ledger.
You can find a working setup here: https://redmine.casenave.fr/projects/ledger-spec/repository

Python bindings are disabled because it requires libboost-python3 which is not available on sfos.

Thanks!

When installing from chum, it downloads the packages via http and does not check any GPG signatures (because there are none).
This means that, right now, any one who can hijack an HTTP connection can make you install & execute arbitrary code (which we don't want, duh).

I see some possible (quick) fixes:

• enable HTTPS on repo.merproject.org
  Apparently this is what Jolla does right now for their own repos. No GPG signatures as well but at least some transport protection.
  On repo.merproject.org, TLS support appears to be available but the configuration seems to be broken...
• GPG sign all packages in sailfishos:chum
• figure out a way to use OpenBSD's signify with RPMs

What are the plans on this?
The first option might be the most preferable right now, but the latter could be the best in the long term.

As we hit SSU issue (https://forum.sailfishos.org/t/ssu-features-are-not-updated-on-removal-of-the-settings-files/7364), use the same workaround as suggested by mal.

DESCRIPTION

https://github.com/sailfishos-chum/main/blob/main/rpm/sailfishos-chum.rpmlintrc#L37-L41
This is by the current design of this source-repository's structure. IMO it makes sense to rename spec file to "sailfishos-chum.spec" and move the Repo Config RPM(s) out of the "main" repo to a new repo "sailfishos-chum".'

ADDITIONAL INFORMATION

Too tired to flesh it out now: will do sometime.

From the discussion for PR #80, point 2c:

For obtaining a name at GitLab, as a fallback the URL might be parsed, though this provides the login name, not the pretty name, see, e.g.: https://gitlab.com/Olf0/sailfishX Although the pretty name can be extracted as the first string on a GitLab user page proper (when ignoring GitLab's top menu bar), see, e.g.: https://gitlab.com/Olf0

Note that I believe to remember that the pretty name can be left empty: IMO it makes sense to use the login name as a fallback, then.

As discussed for points 2a & 2b (not yet concluded), it might make sense to query the ultimately determined source code repository (out of {m_repo_url, m_url}) for the developer's name and the m_packaging_repo_url for the packager's name.

Side note: In general I do not like web-page "scraping", because web-pages are often altered. But in this case, I believe that the pretty name will very likely always be right below the avatar picture, so this is a sustainable solution.

1. Feature request: Please add the missing SailfishOS 3.2.0.12 "DoD" repositories at the SailfishOS-OBS to build against

   I always wondered why the SailfishOS build entries for 3.2.0.12 and ≤ 3.0.3.9 are missing, so I researched this.

   Result:

   • The build entries for SailfishOS 3.2.0.12 work fine, they are simply missing in the configuration.
   • There currently are no “Download on demand sources (rpmmd)” defined for the "DoD repos" sailfishos:3.0.3.9:armv7hl|i486 and the "DoD repos" for any older SailfishOS releases.
     Thus sailfishos:3.1.0.12:* are currently the oldest "Download on Demand (DoD)" repositories available to build against.

   Feature request: Add the following section to both, the meta configuration of the SailfishOS:Chum testing repository and the meta configuration of the regular SailfishOS:Chum repository, between the repository entries for 3.2.1.20_armv7hl and 3.1.0.12_i486.

  <repository name="3.2.0.12_i486">
    <path project="sailfishos:3.2.0.12" repository="latest_i486"/>
    <arch>i586</arch>
  </repository>
  <repository name="3.2.0.12_armv7hl">
    <path project="sailfishos:3.2.0.12" repository="latest_armv7hl"/>
    <arch>armv8el</arch>
  </repository>

Caveat: These two sailfishos:3.2.0.12:armv7hl|i486 "DoD repos" become enabled for all packages. This is a reasonable default for new packages, but may be wrong for existing packages. In my opinion one should not mind, if the builds fail for this single, old release (in two architectures). It is far more important that these two entries are on by default for new packages and likely this is the correct setting for many old packages, too. Also the "compromise approach" to have them enabled for SailfishOS:Chum testing, but disabled for the regular SailfishOS:Chum repository appears to be really confusing.
Hence I strongly suggest not to disable them (YMMV) by adding (usually in the global section, right before the first repository definition; but it is XML, it can be placed anywhere):

  <build>
    <disable repository="3.2.0.12_armv7hl"/>
    <disable repository="3.2.0.12_i486"/>
  </build>

2. Suggestion: Consider to enable the sailfishos:latest "DoD" repositories for SailfishOS:Chum testing

   Currently no sailfishos:latest "DoD" testing repositories are defined for SailfishOS:Chum testing, but it would be useful to know for developers if their software builds correctly against these targets (although Jolla seems to usually miss the chance to switch sailfishos:latest to a newer release during cBeta or EA phase). These "DoD" testing repositories are provided for all three architectures: {aarch64,armv7hl,i486}

   Suggestion: Add the following section to the meta configuration of the SailfishOS:Chum testing repository.

  <repository name="sailfish_testing_i486">
    <path project="sailfishos:latest" repository="latest_i486"/>
    <arch>i586</arch>
  </repository>
  <repository name="sailfish_testing_armv7hl">
    <path project="sailfishos:latest" repository="latest_armv7hl"/>
    <arch>armv8el</arch>
  </repository>
  <repository name="sailfish_testing_aarch64">
    <path project="sailfishos:latest" repository="latest_aarch64"/>
    <arch>aarch64</arch>
  </repository>

Special properties:

• With above configuration (for all three architectures: {aarch64,armv7hl,i486}) their built packages are published at https://repo.sailfishos.org/obs/sailfishos:/chum:/testing:/<package-name>/sailfish_testing_aarch64/, …/sailfish_testing_armv7hl/ and …/sailfish_testing_i486/, but also in every other …/<sfos-release>_{aarch64,armv7hl,i486}/.
• Thus one can select the CPU-architecture, but the built package is available for every SFOS-release. This is very resource efficient for noarch or other packages, which are not SFOS-release dependent: Built once, available-for all SFOS-releases.
• The git-tag date and short-hash is omitted in their package name.

Besides for testing purposes these repositories allow to build SFOS-release independent packages once and have them in all SFOS-release specific download directories.

P.S.: I have tested both suggestions (1 & 2) with a few C++, QML packages and a simple QML noarch package, e.g., Storeman.

i had a working installation
i have enabled testing repos checkbox
immediately after, chum gui told me that it cannot manage repos, maybe cause i have multiple ones defined

uninstal did not solve it
installing rpm package would succeed but icon would not show in launcher
now checking ssu commands to solve the problem:

my solution:
install chumgui via zypper as per piggz blog
ssu rr sailfishos-chum
start chumgui did re-initialize ...

oh right:.
i am using gs290 / yggdrasil with sfos 4.3.0.12

As integration with OpenRepos does not seem to be happening at any significant speed, we should consider backing up Chum repos with some kind of experience similar to app stores. This issue is made to discuss it and agree on steps forward.

Ideally, we need an app to interact with Chum on device and some kind of web presence. I'll try to write up what would such experience could be and later some implementation aspects. In principle, we should aim for something similar to Storeman and OpenRepos.

App:

• list available software in categories/subcategories
• search available software
• install software
• remove software
• see recent updates
• each software package could have icon, screenshots, issues and discussion forums, some stats.

Web:

Ideally same as for app, in part that makes sense:

• list available software in categories/subcategories
• search available software
• see recent updates
• each software package could have icon, screenshots, issues and discussion forums, some stats.

@mentaljam can surely add to that list or comment on it.

If we start from the app and can provide all data for that, maybe it will be easier to roll out web interface later. In the current state, sailfishos-chum-gui already shows that it is possible to get list, some info on app, install and remove it.

Apps are missing icons, issues, and so on. In principle, we can add such data and provide to ChumGui via some files online. For example, each app can add at OBS some special file meta.yaml that would list app's repo, link to issues, links to discussion forums (multiple if needed), link to releases, link to icon. Unless we can specify in SPEC and make it available to ChumGui from PackageKit. Those package-specific meta.yaml datasets can be collected by a crawler and published at some github repo or in some S3 type bucket. This would allow ChumGui to refresh it as soon as needed from a single source. The crawler can just update it (if needed) once an hour, for example.

For GitHub and GitLab repos, we can also show number of stars (and forks), if some simple API is available. That would indicate the status of the app similar to currently used stars in OpenRepos. Advantage of guiding users to online issue trackers and discussion forums is a great experience for developers. In addition, it allows to merge users from different platforms for the apps that are multi-platform.

Thoughts, ideas?

cc: @mentaljam @piggz

harbour-phototools provides a collection of useful tools for the daily photography.

The repository is not maintained any more and it's available for forking, actually I forked it here but I am not sure it needs to be renamed e.g. use fork in the name, and provide correct attributes, etc.

The code compiled and run successfully for aarch64 using latest SDK, and my device. It does not have dependences on any particular libs. There was a warning while packaging that icon resolutions for 108x108, 128x128, and 172x172 were not found, but I am not familiar with that.

Request a new Repo for application "Bugger/harbour-bugger".

It's an UI for submitting bugreports to the Forum, in the Bug Coordination Team defined format.

It would be god to have Chum as platform to cooperatively develop it.

A preview version can be evaluated here: https://build.merproject.org/package/show/home:nephros:devel/bugger

Hi,

it would be nice if you could add https://github.com/sailfishos-patches/patchmanager to chum.
The build process might be a bit more complex than default packages as different branches must be used for different OS version:

• SFOS < 4 => branch patchmanager3
• SFOS >= 4 => branch sfos4-fix

The packages already exist on openrepos (https://openrepos.net/content/coderus/patchmanager-30) for all architectures except for aarch64.
The version 3.0.65 was already running fine on Xperia X with 4.1.0.24 (armv7hl).

I hope you can add this unfortunately currently unmaintained but very good project to chum.

Regards,
Andrwe

ownKeepass got archived at https://github.com/jobe-m/ownkeepass. Let's fork it and make it compile at OBS

Does line 105 of the README.md address Jolla's repositories at the SailfishOS OBS or Jolla's RPM repositories (i.e., the binary repositories)?

I assume the latter and would insert RPM between Jolla's and repositories to resolve this ambiguity, if that is the correct solution.

Its current source is:
If an application is already compiled at the Sailfish OS OBS, simply use the "Submit package" action for the application and all its dependencies, which are not yet available as part of the SailfishOS:Chum repository or Jolla's repositories.

Triggered by sailfishos-chum/sailfishos-chum-gui#7 (comment) :

• In the row "Icon" an exhaustive list of possible file formats should be documented (i.e., all possible formats).
  (AFAIU at least SVG and PNG are supported. Edit: While I denoted that in the Metadata.md document, this does not resolve this point of this issue.)
• For pixel formats the optimal size (in Px²) should be documented, and also what happens, if a provided icon is smaller or larger than the desired size (e.g., "is automatically scaled to the optimal size").

When the Repo: field of the SailfishOS:Chum meta-data is not set (e.g., because the SailfishOS:Chum meta-data is missing), please check if the URL: field in the RPM spec file header section contains either gitlab.com or github.com and use it as Repo: URL subsequently (i.e., also for automatically determining the SailfishOS:Chum meta-data Url: sub-fields).

There is packaging of davfs here:

• https://build.sailfishos.org/package/show/sailfishos:chum/davfs2
• https://build.sailfishos.org/package/show/sailfishos:chum:testing/davfs2

The following dependency packages are also on chum and chum testing:

• libneon

These enable a SFOS device to mount DAV URLs natively (e.g. NextCloud).

They fall into the "actively maintained elsewhere, packaged for SFOS" category.

IF there is interest in having the packaging repos for these here in the chum repo, I request these repos to be created.
I shall then migrate to standard tar_git building for them where possible.

Please also advise whether any changes to the package naming (neon vs libneon vs neon-libs vs libneon-libs) would be wise to be in line with other such library packages.

From the Readme:

Make your software package successfully compile at the Sailfish OS OBS.

If you never worked with OBS it would be helpful to get some pointers on how to complete this step. Maybe there is some documentation that could be linked or maybe a few apps as examples (c with dependencies, python+QML,QML only, QML+webview+some webapp that needs to be built)

Executing ssu lryou can see that the sailfishos-chum repository is listed in "Enabled repositories (global)". This causes potential issues during OS updates.

A safer choice would be adding the repository to user section, as those repositores are disabled during OS updates.

As dictionaries are used by Presage predictive keyboard, package Hunspell dictionaries in UTF-8 (required by presage). Should be easy if based on https://github.com/wooorm/dictionaries

I'd like to package socat. Could you create a repo for this here?

lbt: as far as licensing goes I think the OBS should be limited to OSI/open-source licenses. Basically as per: https://en.opensuse.org/openSUSE:Build_Service_application_blacklist

DESCRIPTION

I suggest to switch off GitHub's "Discussions" for this repo, because the Patchmanager team tried to utilise them a year ago, concluding after three months to stop this experiment, because "Discussions" are a weak spot in GitHub's web-frontend. In contrast to that GitHub's "Issues" can be easily customised to handle all kinds of requests, which I did for "Bugs", "Help requests" and "Feature suggestions", each issues can carry useful attributes (assignee, extensible labels etc.), has useful state information (open, closed with <reason> etc.), and GitHub's "Issues" offer a well working search with filters for all this metadata. "Discussions" lack most of these, and the little metadata is awkward to handle and search for. Furthermore the "conversion" of a "Discussion" to an "Issue" is not really useful: It just uses the title to open a new issue report with this title.

Luckily nobody has started a discussion yet, so this feature can be switched off in the repository settings (in contrast to Patchmanager).

P.S.: The same applies to all SailfishOS:Chum source code repositories here, where no "Discussion" was ever started.

There is packaging of nfs-utils here:

• https://build.sailfishos.org/package/show/sailfishos:chum:testing/nfs-utils
• https://build.sailfishos.org/package/show/sailfishos:chum/nfs-utils

The following dependency packages are also on chum and chum testing:

• libevent
• keyutils
• libtirpc
• rpcbind

All these enable a SFOS device to use NFSv3 and NFSv4.x mounts (and theoretically to act as an NFS server).

They fall into the "actively maintained elsewhere, packaged for SFOS" category, but currently mainly use a dumb "tarball+spec in OBS" build structure.

IF there is interest in having the packaging repos for these here in the chum repo, I request these repos to be created.
I shall then migrate to standard tar_git building for them where possible.

If there is no interest in having NFS infrastructure maintained here, that's absolutely fine, just say no :)

Issue description

The repositories added by the spec file point to the wrong SailfishOS release version after a subsequent SailfishOS upgrade, because AFAICS there is no mechanism which updates them.

Possible resolution

Hence a mechanism is needed, which either is triggered by a SFOS upgrade or detects that these repo entries have become stale soon after a SFOS upgrade (i.e., do not match the installed SFOS release any more, as retrieved per grep -F VERSION_ID /etc/os-release | cut -d '=' -f 2), and updates these repository entries accordingly.

Workaround

As an awkward workaround until a proper resolution is available, users can remove ("uninstall") and re-install the SailfishOS:Chum RPM after a SailfishOS upgrade.

References

Line 41 and line 46 of the spec file

I'd like to provide https://github.com/zeromq/libzmq and https://github.com/zeromq/pyzmq
As always, could you create the respective repos (maybe named libzmq and python-zmq)?

edit: just saw that we have some dedicated python/python3 naming scheme. I slightly prefer the simple name without 3 but would package for python3 only...

We need an RPM package that can be distributed at OpenRepos and in the chum repos that would enable chum repos for users. Something with a SSU INI file that would allow users to follow repository corresponding to their SFOS version.

At https://build.sailfishos.org/project/meta/sailfishos:chum
please change

<project name="sailfishos:chum">
  <title>SailfishOS Community repos</title>
  <description>SailfishOS Community repos&#13;
&#13;
See https://github.com/sailfishos-chum/main for documentation and issues.&#13;
&#13;
Ping piggz or rinigus at #sailfishos for help</description>

to

<project name="sailfishos:chum">
  <title>SailfishOS:Chum</title>
  <description>SailfishOS:Chum community repository&#13;
&#13;
A GUI-client for SailfishOS:Chum is available for easy installation at https://chumrpm.netlify.app/ and its individual RPMs are also provided at https://build.sailfishos.org/package/show/sailfishos:chum/sailfishos-chum-gui&#13;
A helper RPM, which solely provides an appropriate local repository configuration for utilising SailfishOS:Chum with command line tools as pkcon or zypper, is available at https://build.sailfishos.org/package/show/sailfishos:chum/sailfishos-chum&#13;
&#13;
See https://github.com/sailfishos-chum/main for documentation, guidance, rules and the issue tracker.&#13;
You may also ping piggz or rinigus at the IRC channel #sailfishos for help.&#13;</description>

This aligns this description and its wording with PR #44 and sailfishos-chum/sailfishos-chum-gui#85

P.S.: I hope that my guess that #sailfishos denotes an IRC channel (and not some Telegram group etc.) is correct.

@rinigus, @poetaster contacted you with the wish to submit Storeman to the SailfishOS:Chum testing repository.

To prepare for this he replicated the setup of @mentaljam's Sailfish-OBS repo for Storeman in a sub-repo of @poetasters's Sailfish-OBS repo and I performed some minor adaptions. But I was strictly sticking to @mentaljam's OBS-repository structure, because this reflects the structure of Storeman's GitHub repository and the established workflow. Changing how Storeman's git- and OBS-repos are structured would require a fundamental change of the code organisation and the commit workflows, plus rewriting crucial parts of the spec file: This would be a tedious endeavour with the risk of breaking a well working, established processes, which were easy for me to comprehend in the few days since I started maintaining Storeman.
TL;DR: I do think that the Storeman's git- and OBS-repo organisation and workflows @mentaljam established make a lot of sense.

@poetaster contacted you (via Telegram, I believe) and transported this feedback of yours:

<rinigus> poetaster: can't you somehow organize it in a way where single master is pulled and options enabled/disabled depending on SFOS version?

Not easily. This would require a major reorganisation of code, git- and OBS-repo structure and workflows. It also would make the structure and processes much harder to understand.

<rinigus> right now it is a pain to accept and start enabling/disabling all the sfos/arch combinations

When submitting a package, OBS does not include the the built target configuration, unfortunately.

But this can be easily done by Copy & Paste of the <build> section of the OBS meta-data / -tab from the package origin at OBS to its submitted location. The meta-data for the four packages harbour-storeman-installer, harbour-storeman-sfos3.2, harbour-storeman-sfos3.3, harbour-storeman-sfos4.2 and harbour-storeman-testing is at:

• https://build.sailfishos.org/package/meta/home:poetaster:storeman/harbour-storeman-installer
• https://build.sailfishos.org/package/meta/home:poetaster:storeman/harbour-storeman-sfos3.2
• https://build.sailfishos.org/package/meta/home:poetaster:storeman/harbour-storeman-sfos3.3
• https://build.sailfishos.org/package/meta/home:poetaster:storeman/harbour-storeman-sfos4.2
• https://build.sailfishos.org/package/meta/home:poetaster:storeman/harbour-storeman-testing

Alternatively I offer to create or configure the repository configuration for these packages, when you provide an initial set-up of these four packages and configure me as a maintainer.

On first sight it appears to be reasonable to put these four packages into a harbour-storeman sub-project (not just storeman, as above) of the SailfishOS:Chum testing repo (and later the regular SailfishOS:Chum repo), so they are kept together. But I am not very experienced with OBS, so there may be reasons why this is deemed a "bad idea™".

The maintainer's OBS-account names are poetaster, mentaljam and olf.

Thank you for your support!

I am getting the error message from a service run of tar_git:

Files could not be expanded: service error: ERROR: couldn't clone reponame

service tar_git failed:
Handling reponame
fatal: not a git repository (or any parent up to mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
fatal: repository '/data/service/tar_git/https___gitlab.com_nephros/reponame' does not exist
ERROR: couldn't clone reponame

Steps to reproduce:

1. on GitLAB, create a new repo
2. when creating, make sure to create a 'private' visibility
3. commit some files that should wor with tar_git service
4. create a new package at OBS
5. create a service file pulling from the above repo
6. observe the cloning error as expected
7. on Gitlab project settings, change visibility from private to public
8. trigger the service again
9. service cannot clone still
10. use any other tool to clone that repo, confirm that it works normally.

I would like to host the abandoned Stellarium app on SailfishOS:chum repo.

Stellarium is a very nice planetarium application, that has a mobile version.

Two variants exist on openrepos:

• a much older version Stellarium SFM that was ported to Sailfish by matsav, and that avairus has managed to recompile for modern Aarch64.
• a more recent version Stellarrium Mobile ported this time by @fuchsmisch, based on the UbuntuTouch version 0.3 by @lduboeuf, it-self based on Stellarium Android.

The second version is the one I have enjoyed on my previous Xperia XA2 Ultra, but it doesn't have an Aarch64 package, and aviarus reports not managing to get that one to compile.

I have managed to rebase it against upstream UbuntuTouch's Stellarium Mobile 0.4 (based on Stellarium Android 0.12.3, using the mobile stellarium core 1.29.6) and successfully compiled it inside CODeRUS' docker and test on real Aarch64 hardware.

@fuchsmich has left the SailfishOS scene (the repos on github is now archived) and thus won't be maintaining the app any more, but mentionned being fine with the App moved to the abandoned Apps in SailfishOS:chum.

So would accept moving my fixed fork inside SailfishOS:chum? Thank you very much.

Hey,

I want to package pyhon-cairosvg and it's dependencies for that I need the following repositories:

• python3-cairosvg
• python3-cairocffi
• python3-cssselect2
• python3-defusedxml
• python3-pillow
• python3-tinycss2
• python3-webencodings
• pyproject-rpm-macros
• python3-tomli
• python3-flit

lbt suggested to create a list of maintainers that would link package to someone responsible for it.

… from "Sailfish OS Community Packages" to "SailfishOS:Chum community repository", see the upper left corner at github.com/sailfishos-chum.
Reason: That is the term we settled on and which was introduced in the past two days in various documents and at web-pages, specifically the informational page this organisation links to. Most importantly, the central word "Chum" is currently missing at the organisation's frontpage.

I have packaged zsh (https://github.com/takimata/zsh-packaging) and would like to transfer my repo into sailfishos-chum.
Could you give me access for this?

It already builds at OBS: https://build.merproject.org/package/show/home:takimata/zsh

Please add a new repo for the pcre2 library.

An example build is at https://build.merproject.org/package/show/home:nephros:branches:sailfishos:chum:testing/pcre2, adapted from the OpenSUSE spec.

This seems to be a common dependency, but is not available from Jolla AFAICS.