KDE-git edition coordination

Development
43

well, it could be solved by making it an “edition”.

so current kf5-git/plasma-git would become kf5-kde-git-edition and plasma-kde-git-edition and any kdegear app that would “be built on these” would have -kde-git-edition.

so dolphin would become dolphin-kde-git-edition

( possible replace kde-git-edition, with some cool name, like kdegittezided :stuck_out_tongue: )

( the main goal would be for "pacman -Ss “kde-gittezided/kde-git-edition” and show the designated packages, and show their relation )

EDIT: though, to be honest, and this is my opinion that might be by lack of foresight:

what I would like is git packages that base themselves on arch, like dolphin-git ( which is based on normal kde stack ), would be on chaotic-aur like present.

the kde git packages, which replace the current stack and are needed for packages, would be on another repo. so enabling “kde git edition”, would be just a [kde-git-edition] repo on pacman.conf with higher priority.

Is there a bad reason to not use the different repo’s strategy?

44

Hmm.

If you want to "fork" the KDE -git packages to determine the rebuild tree then it definitely needs a new set of PKGBUILDs.

I'd probably suggest an -edge suffix that's the same PKGBUILD as the -git package but pegged to a specific git commit. This way -edge packages can depend on -edge packages, and you can ensure they are built against a known set of commits from the upstream repos.

I wouldn't keep the -git identifier in the package names to make it clear that these are tagged rather than purely VCS-based.

2 Likes
45

Well, this profile also inevitably adds kde-unstable/ (still not sure why), adding another one is a bit much no?

46

it adds kde-unstable? don’t understand ?

47

Check /etc/pacman.conf in an installation/live iso of the new profile, for some reason it gets added there in front of all the others. Even though nothing from it gets installed

48

We would first need to adapt our tools to support multiple repos which I’m not sure if its going to happen :thinking:

I just removed the weird named packages and set all of the packages in question to use -git dependencies. So no more problem, just the people eventually using these packages will need to build their konsole-git or whatever themselves now :eyes:

2 Likes
49

Anyone using a -git package should expect to rebuild it themselves given it’s built from the head of the main development branch, and they’d normally only be doing that because they want to test or be involved in the development process. So - I think that’s fine. :grin:

2 Likes
50

But its that the only issue? Although it would be nice, I don’t see it as a major problem. ( having to use the terminal to switch to kde-git, as it should not be the flagship main edition of Garuda for obvious reasons. Although I don’t see much issue in “making a checkbox” )

The only issue, is that if one installs dolphin-git from aur, at the next update, all mayhem will break loose ( because aur/dolphin-git uses stable kde, and pacman with chaotic will install all kde-git stack ).

this all comes from the naming. I think something like kde-neonized ( kde-n30n7z3d ?? ), coming from kde neon, which people already understand what it is.

Also, is there really demand for using dolphin-git ( as it was ) in garuda? There is, in my opinion, to much “gits” packages “without any real purpose”.

Depending if people actually like this ( and I have to say that kde git has been very good in terms of stability ), using the repo route, interesting thing can be done, like the:

  • [kde-neonized-plasma] ( all kde git stack )
  • [kde-neonized-stable-apps] ( kde gear stable apps compiled on top of [kde-neonized-plasma] , which of course need to be above the previous repo. This could be a repo for people that only want bleeding edge desktop/plasma.

The repo scheme could also be used to include any other app ( not under the kde umbrella ) but that breaks when using this stack.

( the package naming would be the same as the “normal ones”, so that people don’t mess up adding this package or removing another, or, mixing packages, as all hell would break loose. the selection would be based on “repo” configs on pacman.conf. Looking at it this way, creating the kde-neonized edition would be almost like just adding the pacman.conf repo config ( and of course, taking care of special cases, like theming or things that change on kde git versions ) )

I think its the most flexible and less error prone way. Of course, I can be wrong, as I never created a distro, much less one with as much use as garuda, so experience here matters, and I have none.

( I hope you read this as someone trying to give ideas, and not just complaining :stuck_out_tongue: )

51

btw ... i haven't been testing the ISO on real machine, only on vm.

I have been using kde git on installed system for 2 weeks now, and everything cool so far.

2 Likes
52

btw, just a notice, that I was almost forgetting:

found a list of packages that "don't replace" the standard ones:
kpmcore, ark and plasma-workspace-wallpapers.

I mean that those packages don't ask to replace ( for example, ark-git doesn't replace ark, and then conflicts on its installation. pacman -rdd ark is needed ).

I think those PKGBUILD's need
conflicts=("${pkgname%-git}")
right ?

3 Likes
53

Fixed :slight_smile: I'm on the -git packages myself, working as well :slight_smile:

4 Likes
54

is something wrong with caotic-aur compiling ? space issues ?

Some packages that I checked as failing with:

error: could not extract /var/lib/pacman/local/glib2-2.70.2-1/mtree (Write failed)
error: could not extract /usr/bin/gapplication (Write failed)
error: could not extract /usr/bin/gdbus (Write failed)
error: could not extract /usr/bin/gdbus-codegen (Write failed)
error: could not extract /usr/bin/gio (Write failed)
error: could not extract /usr/bin/gio-querymodules (Write failed)
error: could not extract /usr/bin/glib-compile-resources (Write failed)
error: could not extract /usr/bin/glib-compile-schemas (Write failed)
error: could not extract /usr/bin/glib-genmarshal (Write failed)
error: could not extract /usr/bin/glib-gettextize (Write failed)
error: could not extract /usr/bin/glib-mkenums (Write failed)
error: could not extract /usr/bin/gobject-query (Write failed)
error: could not extract /usr/b

( example with plasma-desktop-git )

55

No, everything should be fine. We have a new builder which builds in a 40GB tmpfs, might be from the time where I did not adjust its size :eyes:

2 Likes
56

well, those do seem like they were from 2 days ago.

although there seems to be the same issue with plasma-workspace-git, which was compiled today, a few hours ago.

I will monitor if it happens again after today.

EDIT: confirmed, seems some packages that were giving issues are already compiling fine !! :slight_smile:

57

ping @dr460nf1r3 ...

it seems its still happening though :frowning:

EDIT: and now seems to have worked again ( was checking kwin-git, yesterday compilation ( day 16 ) had the same issue, but todays ( day 17 ) worked fine ).

1 Like
58

I changed some filesystem sizes, that might have helped. Gotta keep an eye on it :eyes:

2 Likes
59

So, are we ready to release this with the upcoming release? :eyes:

1 Like
60

I think its good for a initial release :slight_smile: although I have to retest the iso, I have only been using it as installed.
I will retest the iso in a new VM.

There have been some issues, kwin-git has been failing all week.

Could you put the logs in a git repo? I could check them out daily and see which ones are failing and why

2 Likes
61

What about testing kwinft-git as a more cutting edge alternative?

62

because its cutting! :slight_smile: it never worked very well in my experience.