Create Task
Maniphest T4852

digikam (un)stable sourcing wrong git
Closed, ResolvedPublic
Actions

Description

Digikam git builds use kde:digikam however the tarball is actually based on kde:digikam-software-collection. To mitgate this we have debian/rules mangle everything so it is like we started with d-s-c. This is not only very unreliable it also bypasses the actual source building code of the tooling.

  • digikam git builds should watch and generate off of the d-s-c repo
  • the builds will need to run a script in that repo to pull the sources for the collection. tooling currently has no tech for this, but a if-branch in the source could do for now (in the future a simple system should be devised)
  • the jenkins jobs somehow also need to have kde:digikam as a git repo so it can detect actual source changes to integrate! It doesn't have to clone or use the source, but it absolutely needs to somehow be aware of it so it can perform polling on the repo and get notified of changes. this also applies to kipi and whatever else the scripts would pull into the collection.

Related Objects

sitter created this task.Dec 7 2016, 11:03 AM
sitter updated the task description. (Show Details)
sitter mentioned this in T3799: refine digikam unstable hack.
sitter triaged this task as Low priority.
sitter moved this task from Discussing to Ready To Do on the Neon board.
rwooninck added a subscriber: rwooninck.Dec 28 2016, 9:42 AM

There is an alternative solution to this all. However this would mean that User and Development will not be tracking the same packages.

For User one can use the released tarball and build the full package (digikam, kipi-plugins, etc). For Development one would require to build the components separately from their respective git repo's. This would prevent all kind of hacks to get the tarball based on the git snapshots and makes life a whole lot easier. The only downside is that the job merge_digikam has to disappear or we have to rename the package on User to digikamsc.

Looking at all the issues that are mentioned for the current methodology, I believe the better way would be to create this split.

sitter added a comment.Jan 9 2017, 10:43 AM
In T4852#72821, @rwooninck wrote:

There is an alternative solution to this all. However this would mean that User and Development will not be tracking the same packages.

That would still mean one would have to invent technology to bridge the gap. From a packaging POV the use of unstable is to continuously maintain the packaging against HEAD and not have to faff about for days once a new release is out but simply forward merge. Respectively unstable gets improved by imporving user. If we were to split the repos we'd make this loop impossibly hard to pull off ultimately being as though we actually maintain two different applications even though they aren't. Also, from a CI POV the further we are away from what a release artifact looks like, the less representative our builds are of the actual product quality (of digikam).

So, overall I think we stand to gain more by changing the way the sources are assembled.

jriddell added a subscriber: jriddell.Oct 3 2018, 10:50 AM

This problem went away but current problem seems to be something to do with kipi-plugins being different in git checkout compared to tar
https://build.neon.kde.org/job/bionic_unstable_neon-packaging_digikam_bin_amd64/88/console

jriddell added a comment.Apr 22 2019, 4:55 PM

kipi-plugins now released and split out, nearly semi sane again

jriddell moved this task from Ready To Do to Doing on the Neon board.Apr 22 2019, 4:55 PM
jriddell added a comment.Sep 12 2019, 9:51 AM

Current issue seem to be that digikam.mo translation doesn't get picked up by our stuff. Investigate why.

carlosdem added a subscriber: carlosdem.Feb 27 2023, 10:31 PM

seems that digikam's repo is now same as release tarball. i've changed the rules file to reflect this and there are packages in unstable and stable again.

carlosdem closed this task as Resolved.Feb 27 2023, 10:32 PM
carlosdem claimed this task.