Stable ebuilds: Add tdebase ebuilds. #53

Manually merged
eliddell merged 1 commits from other/stable-revised into master 4 years ago
Collaborator

Signed-off-by: E. Liddell ejlddll@warpmail.net

Old branch was a mess and impossible to rebase even before I copied the wrong directory on top of it (oops?). This is all the 14.0.6 ebuilds from there, plus their manifests, plus some tweaks to:

dev-tqt/tqt/tqt-14.0.6.ebuild
trinity-base/tdelibs/tdelibs-14.0.6.ebuild
eclass/trinity-base-2.eclass
eclass/trinity-meta-2.eclass

The changes to the eclasses are extremely minor (tweaks in comment wording and the addition of the one directory unpack).

Ebuilds for arts, kcminit, kcontrol, kdesktop, ksysguard, tdm have been altered to incorporate some useful stuff from the live ebuilds. The others pretty much matched the live ebuilds already (except for KEYWORDS).

Regarding tdelibs with hwlib:

pmount is now only pulled in if the USE flags udevil, udisks, old_udisks are all off, since it's supposed to be the ultimate fallback for automounting.

Does anyone know whether sys-apps/elogind has the necessary functionality to act as a backend for tdelibs' WITH_LOGINDPOWER? By my understanding, it should be a drop-in replacement for logind. We may need to rethink how the USE flags and deps work around that.

Signed-off-by: E. Liddell <ejlddll@warpmail.net> Old branch was a mess and impossible to rebase even before I copied the wrong directory on top of it (oops?). This is all the 14.0.6 ebuilds from there, plus their manifests, plus some tweaks to: dev-tqt/tqt/tqt-14.0.6.ebuild trinity-base/tdelibs/tdelibs-14.0.6.ebuild eclass/trinity-base-2.eclass eclass/trinity-meta-2.eclass The changes to the eclasses are extremely minor (tweaks in comment wording and the addition of the one directory unpack). Ebuilds for arts, kcminit, kcontrol, kdesktop, ksysguard, tdm have been altered to incorporate some useful stuff from the live ebuilds. The others pretty much matched the live ebuilds already (except for KEYWORDS). Regarding tdelibs with hwlib: pmount is now only pulled in if the USE flags udevil, udisks, old_udisks are all off, since it's supposed to be the ultimate fallback for automounting. Does anyone know whether sys-apps/elogind has the necessary functionality to act as a backend for tdelibs' WITH_LOGINDPOWER? By my understanding, it should be a drop-in replacement for logind. We may need to rethink how the USE flags and deps work around that.
Chris commented 4 years ago
Collaborator

You are getting better with git, it seems. 😸

Now it would be good if you could recycle your old PR and branch maybe, for other work.

Good work, from some quick look. 👍

About elogind - Yes, you are absolutely right here and the idea was great. In fact I have added that already, but it seems never pushed it. I wrote Slavek about that already some weeks ago. In fact, it is just some drop-in replacement and should work perfectly.

There will be some elogind USE, which does from CMake level just activate -DWITH_LOGIND, just as systemd.

About pmount - Good one too.

You are getting better with git, it seems. :smile_cat: Now it would be good if you could recycle your old PR and branch maybe, for other work. Good work, from some quick look. :+1: About `elogind` - Yes, you are absolutely right here and the idea was great. In fact I have added that already, but it seems never pushed it. I wrote Slavek about that already some weeks ago. In fact, it is just some drop-in replacement and should work perfectly. There will be some `elogind` USE, which does from CMake level just activate `-DWITH_LOGIND`, just as `systemd`. About `pmount` - Good one too.
Chris added this to the R14.0.8 release milestone 4 years ago
Chris commented 4 years ago
Collaborator

After some closer look, it seems you have re-used some older version of some ebuilds, like for kdcop and other ones? Because now you re-introduced the empty IUSE="" and the ebuilds are lacking the copyright now again. 😅

Please, are you so kind to fix that again?

After some closer look, it seems you have re-used some older version of some ebuilds, like for `kdcop` and other ones? Because now you re-introduced the empty `IUSE=""` and the ebuilds are lacking the copyright now again. :sweat_smile: Please, are you so kind to fix that again?
Chris commented 4 years ago
Collaborator

Please, if you do fix that with some commit, can you please use

git rebase -i HEAD~2 (the 2 stands for the number of commits you want to squash)

before pushing? You will have to add -f when pushing then, to force the push.

Please remove the old commit message then from the resulting commit, which is about your fix, so it is not doubled.

And can you change the commit title to something more clear then like Stable ebuilds: Add tdebase ebuilds. when you are doing that? Would be wonderful. 😸

Round 2 would make sense, if your old commit would end up in the commit history of the master branch, which isn't the case. So that would be a bit confusing.

Please, if you do fix that with some commit, can you please use `git rebase -i HEAD~2` (the `2` stands for the number of commits you want to squash) before pushing? You will have to add `-f` when pushing then, to force the push. Please remove the old commit message then from the resulting commit, which is about your fix, so it is not doubled. And can you change the commit title to something more clear then like `Stable ebuilds: Add tdebase ebuilds.` when you are doing that? Would be wonderful. :smile_cat: Round 2 would make sense, if your old commit would end up in the commit history of the master branch, which isn't the case. So that would be a bit confusing.
Chris changed title from stable ebuilds round 2--rebase and manifests to Stable ebuilds: Add tdebase ebuilds. 4 years ago
Poster
Collaborator

I wouldn't say that messing up my local repository to the point of uselessness (twice!) represents my getting better at git. ;P

Ugh, I must have made the changes to the kdcop etc. ebuilds directly in the repository rather than my working tree, and then blown them away when I had to delete and re-initialize the repository. Of course, the possibility of having to blow everything away due to git-ineptitude was the reason I set up a separate working tree in the first place. I'll re-run all the diffs.

I wouldn't say that messing up my local repository to the point of uselessness (twice!) represents my getting better at git. ;P Ugh, I must have made the changes to the kdcop etc. ebuilds directly in the repository rather than my working tree, and then blown them away when I had to delete and re-initialize the repository. Of course, the possibility of having to blow everything away due to git-ineptitude was the reason I set up a separate working tree in the first place. I'll re-run all the diffs.
Chris commented 4 years ago
Collaborator

So after another review on your work, there are still many things not in sync or not right. Some are small, some not. It's great you fixed some of these copyrights with your last commit, but some copyrights are still lacking in your ebuilds.

I am sorry, but this things should be fixed, before it can be merged. Otherwise we will lose the overview very fast. I just reviewed what could be done over TGW, but there might be more, because there are too many files now to show all differences online, but here is some collection:

  • drkonqi is still missing +hwlib
  • kcheckpass is still missing -DKCHECKPASS_PAM_SERVICE=tde
  • kcontrol -> Fix USB support + two times +xrandr + +svg is missing
  • tdelibs -> act-group/plugdev + einfo (please, see my new PR's)
  • khelpcenter -> Can you make it depending on either www-misc/htdig or www-client/hldig already?
  • klipper -> RDEPEND="${RDEPEND}" can't work
  • ksmserver is still missing +hwlib; upower needs to be removed with dbus-tqt and dbus-1-tqt dependencies
  • ksysguard -> IUSE=" dell-laptop lm_sensors -> Please remove the extra space
  • tdebase-tdeioslaves -> hwlib, not tdehw + dependencies are still versioned + tdeject is still using a slot
  • tdesu still has no fixed kdeglobal(s) in the message
  • tdm -> Please, do a full review, +hwlib is missing, svg too, depends still on dbus
  • tqt -> Please, can you sync with my latest PR about that?

Please, can you make some full review, ebuild by ebuild if you have the time? And please, for your later work. Can you just copy over the 9999 ebuilds and use them as base? This way we don't need to review every single ebuild at detail.

Sorry for the late reaction, but I had to care about much things in real life and couldn't find the attention. But it's wonderful you seems to have already started on the tdeartwork branch. Keep up the great work. 👍

At some point, we will finaly merge it. 😸

So after another review on your work, there are still many things not in sync or not right. Some are small, some not. It's great you fixed some of these copyrights with your last commit, but some copyrights are still lacking in your ebuilds. I am sorry, but this things should be fixed, before it can be merged. Otherwise we will lose the overview very fast. I just reviewed what could be done over TGW, but there might be more, because there are too many files now to show all differences online, but here is some collection: * `drkonqi` is still missing `+hwlib` * `kcheckpass` is still missing `-DKCHECKPASS_PAM_SERVICE=tde` * `kcontrol` -> Fix USB support + two times `+xrandr` + `+svg` is missing * `tdelibs` -> `act-group/plugdev` + `einfo` (please, see my new PR's) * `khelpcenter` -> Can you make it depending on either `www-misc/htdig` or `www-client/hldig` already? * `klipper` -> `RDEPEND="${RDEPEND}"` can't work * `ksmserver` is still missing `+hwlib`; `upower` needs to be removed with `dbus-tqt` and `dbus-1-tqt` dependencies * `ksysguard` -> `IUSE=" dell-laptop lm_sensors` -> Please remove the extra space * `tdebase-tdeioslaves` -> `hwlib`, not `tdehw` + dependencies are still versioned + `tdeject` is still using a slot * `tdesu` still has no fixed `kdeglobal(s)` in the message * `tdm` -> Please, do a full review, `+hwlib` is missing, `svg` too, depends still on `dbus` * `tqt` -> Please, can you sync with my latest PR about that? Please, can you make some full review, ebuild by ebuild if you have the time? And please, for your later work. Can you just copy over the `9999` ebuilds and use them as base? This way we don't need to review every single ebuild at detail. Sorry for the late reaction, but I had to care about much things in real life and couldn't find the attention. But it's wonderful you seems to have already started on the tdeartwork branch. Keep up the great work. :+1: At some point, we will finaly merge it. :smile_cat:
Poster
Collaborator

Some of those differences are on purpose, and were based on an inspection of CMakeLists for 14.0.7, but I admit that I don't remember which ones. I'll check back this weekend and document which, while I take care of the other differences.

Some of those differences are on purpose, and were based on an inspection of CMakeLists for 14.0.7, but I admit that I don't remember which ones. I'll check back this weekend and document which, while I take care of the other differences.
Chris commented 4 years ago
Collaborator

Okay, wonderful if you could do that and good point about the CMakeLists differences. 👍

Last time I checked the differences regarding to that, there were hardly any. But I just realized again we are talking about 14.0.6 here, so that could be possible still. Especially the upower point could be working code here for the stable branch. In the master branch, there is still the CMakeLists option, but without effect from what I have investigated last time.

Okay, wonderful if you could do that and good point about the CMakeLists differences. :+1: Last time I checked the differences regarding to that, there were hardly any. But I just realized again we are talking about 14.0.6 here, so that could be possible still. Especially the `upower` point could be working code here for the stable branch. In the master branch, there is still the CMakeLists option, but without effect from what I have investigated last time.
Poster
Collaborator

Apologies for taking forever to catch up. Some of the differences were due to my not having dug deep enough into the code. My notes on the remaining differences follow:

trinity-base-2.eclass: Just discard the changes here if it makes things easier—they're to comments, not anything functional.

kcontrol: Not sure what the issue is with USB. Fixed everything else.

khelpcenter: You haven't added hldig yourself that I can see, but okay.

tdm: dbus is still used in backend/consolekit.c, and included in CMakeLists.txt for backend. I think it's legitimate to retain it as a dependency for the time being. It can be revisited for 14.0.8.

ksmserver: Still contains code that uses dbus, but not upower. It's possible that the dep should be on dbus directly, and not dbus-tqt, but I'd have to check a lot more source to be certain.

tdelibs: Technically, WITH_UDEVIL and the various crypt flags don't exist in stable, but since the worst thing they can produce is a warning, I re-added them anyway. Note grammar fixes in einfo.

tqt: As far as I can tell, the only significant difference left is the line setting S, which is necessary for the ebuild to work. Other than that, there are a few places where I have "|| die" and you don't, and the alphabetical reordering of the flags. These are not functional changes, and I don't think they're worth altering.

(In general, please be a little less fussy about the comments and whitespace, or we're never going to get this merged, okay? That's stuff that can be fixed afterwards.)

Apologies for taking forever to catch up. Some of the differences were due to my not having dug deep enough into the code. My notes on the remaining differences follow: trinity-base-2.eclass: Just discard the changes here if it makes things easier—they're to comments, not anything functional. kcontrol: Not sure what the issue is with USB. Fixed everything else. khelpcenter: You haven't added hldig yourself that I can see, but okay. tdm: dbus is still used in backend/consolekit.c, and included in CMakeLists.txt for backend. I think it's legitimate to retain it as a dependency for the time being. It can be revisited for 14.0.8. ksmserver: Still contains code that uses dbus, but not upower. It's possible that the dep should be on dbus directly, and not dbus-tqt, but I'd have to check a lot more source to be certain. tdelibs: Technically, WITH_UDEVIL and the various crypt flags don't exist in stable, but since the worst thing they can produce is a warning, I re-added them anyway. Note grammar fixes in einfo. tqt: As far as I can tell, the only *significant* difference left is the line setting S, which is necessary for the ebuild to work. Other than that, there are a few places where I have "|| die" and you don't, and the alphabetical reordering of the flags. These are not functional changes, and I don't think they're worth altering. (In general, please be a little less fussy about the comments and whitespace, or we're never going to get this merged, okay? That's stuff that can be fixed afterwards.)
Chris commented 4 years ago
Collaborator

Wonderful you got it and no problem about the time, really. I can understand that very well. 😸

Regarding your points:

kcontrol -> Great! That looks good. The USB problem was in #56 extra described, so you can understand it. But I will add it myself now, no problem. So we can merge this faster. Just important you know what is the problem.

ksmserver -> Uses dbus only for HAL. With HWLIB, or without HAL in general, there is no need for dbus -> Tested. But, I also build ksmserver without even dbus-1-tqt! And the difference between the HAL vs the HWLIB backends are, that the later one calls functions of that HWLIB backend directly, instead of the HAL backend, which does dbus calls. But because we aren't support HAL anymore, there should be no dependency at all. But as you can see, in my latest live ebuild of ksmserver, I have added the hwlib USE, which the stable branch is even supporting too. With that, the dbus-1-tqt dependency isn't needed at all and in fact, there should be no dbus dependency needed at all. I also plan to add some eclass function, to depend on tdelibs build with hwlib USE - Something like need-hwlib yes/optional, or likely. So tdelibs with hwlib USE will keep care of all that dependencies. But that is not related for now and it's no problem. I can fix that later myself, so we get your work merged. Also you write yourself, upower isn't used, but you still have that USE in the ebuild remain.

tdelibs -> Good point! I wasn't aware of that udevil isn't existing at all in the stable branch. That is wondering me very much, but you seems to be right. I just saw udisks and so as options and assumed udevil is there too. From what I know, Selk talked about udevil and he is using the stable branch too. I can remove what is not used myself, if you are happy and okay with that. Just leaving it for the stable branch isn't something good, if we care about typos in text or the ordering of USE flags, leaving non-functional USE flags isn't consistent to our approach. Right?

tdm -> You are right. Good point. It seems I just saw the dbus-1-tqt dependency and thought that dbus is pulled in by that anyway. I never asked myself if that dependency was right, because I assumed it. It seems that was naive. So good we talked about that!

khelpcenter -> Well, you are right about. It was just supposed to be good will, because I thought it would be good, you would have added it already. It's on my todo list too. Therefore the already in my comment about that.

tqt > Well, I tried to express why I do some changes and as I pointed out, there is a difference for master vs stable there. For the master branch, you need to define tqtdir, but in the stable branch it is still qtdir. So your latest change regarding to that is wrong, sadly. But, I can fix up that myself too, so we are getting your work merged. About setting ${S}, well, it seems that is only needed for the stable branch at all, so that is a good point and great we talked about! At least with GIT and the master branch, it isn't needed at all. But that wasn't even meant by me. About || die, I made some commit with explaining why that isn't needed anymore with EAPI 7. Built in commands are doing that anyway, these days. But, I can fix that myself too. I am sorry, but I didn't notice you already synced regarding with the USE flags, because I did some ebuild by ebuild review, based on the live ebuilds and because that still looked very different, I assumed you missed that. So I missed it. Great! It seems I need to sync with you.

klipper -> Just removing the RDEPEND isn't the right thing. It just should be RDEPEND="${DEPEND}", so it works.

But, I just realized something different. Because there isn't any libart_lgpl-14.0.6.ebuild, you either have to change that DEPEND, or you need to add that ebuild too. The same related to the libr ebuild. I am sorry that I noticed that just now. But that shows that some good review is much more important than just getting something done.

I can really understand, you want to get that merged and I am likely, but I just want to prevent some later chaos. Please understand that. At the same time, demotivating you is the last I want, okay? Please, keep your motivation! 😸

All my build tests are done with the master branch, but I tried to check against the stable sources. Keep that in mind. So I might not be fully right either! 😅

Regarding the typos - Great! I will sync with your work regarding to that and other things too. Is is wonderful to see we can improve both more and more. 👍

So, if you allow me, I would like to fix some things by a commit myself, so you can work on other things and you can review my changes than and if all is good, we can merge it, is that okay for you?

By the way: I never intendet, that you need to be up to date to my very latest changes (the id change for example), but it is wonderful to see you did that too! But I thought it would be good to be in some kind of sync.

After all, it is a great gain, to scrutinise dependencies, build options and all this kind of things. So we learn more about the TDE internals. It can be only a gain, please keep that in mind after all. 👍

And some good news: Fat-Zer showed up this night and is positive about our work. He will deprecate his overlay and reference to ours as the new main overlay. Most likely he will join our efforts too, if he has some time. 😄

Wonderful you got it and no problem about the time, really. I can understand that very well. :smile_cat: Regarding your points: `kcontrol` -> Great! That looks good. The USB problem was in #56 extra described, so you can understand it. But I will add it myself now, no problem. So we can merge this faster. Just important you know what is the problem. `ksmserver` -> Uses `dbus` only for `HAL`. With `HWLIB`, or `without HAL` in general, there is no need for `dbus` -> Tested. But, I also build `ksmserver` without even `dbus-1-tqt`! And the difference between the `HAL` vs the `HWLIB` backends are, that the later one calls functions of that HWLIB backend *directly*, instead of the `HAL` backend, which does *dbus calls*. But because we aren't support `HAL` anymore, there should be no dependency at all. But as you can see, in my latest live ebuild of `ksmserver`, I have added the `hwlib` USE, which the `stable` branch is even supporting too. With that, the `dbus-1-tqt` dependency isn't needed at all and in fact, there should be no `dbus` dependency needed at all. I also plan to add some eclass function, to depend on `tdelibs` build with `hwlib` USE - Something like `need-hwlib yes/optional`, or likely. So `tdelibs` with `hwlib` USE will keep care of all that dependencies. But that is not related for now and it's no problem. I can fix that later myself, so we get your work merged. Also you write yourself, `upower` isn't used, but you still have that USE in the ebuild remain. `tdelibs` -> Good point! I wasn't aware of that `udevil` isn't existing at all in the `stable` branch. That is wondering me very much, but you seems to be right. I just saw `udisks` and so as options and assumed `udevil` is there too. From what I know, Selk talked about `udevil` and he is using the `stable` branch too. I can remove what is not used myself, if you are happy and okay with that. Just leaving it for the `stable` branch isn't something good, if we care about typos in text or the ordering of USE flags, leaving non-functional USE flags isn't consistent to our approach. Right? `tdm` -> You are right. Good point. It seems I just saw the `dbus-1-tqt` dependency and thought that `dbus` is pulled in by that anyway. I never asked myself if that dependency was right, because I assumed it. It seems that was naive. So good we talked about that! `khelpcenter` -> Well, you are right about. It was just supposed to be good will, because I thought it would be good, you would have added it already. It's on my todo list too. Therefore the `already` in my comment about that. `tqt` > Well, I tried to express why I do some changes and as I pointed out, there is a difference for `master` vs `stable` there. For the `master` branch, you need to define `tqtdir`, but in the `stable` branch it is still `qtdir`. So your latest change regarding to that is wrong, sadly. But, I can fix up that myself too, so we are getting your work merged. About setting `${S}`, well, it seems that is only needed for the `stable` branch at all, so that is a good point and great we talked about! At least with GIT and the `master` branch, it isn't needed at all. But that wasn't even meant by me. About `|| die`, I made some commit with explaining why that isn't needed anymore with EAPI 7. Built in commands are doing that anyway, these days. But, I can fix that myself too. I am sorry, but I didn't notice you already synced regarding with the USE flags, because I did some ebuild by ebuild review, based on the live ebuilds and because that still looked very different, I assumed you missed that. So I missed it. Great! It seems I need to sync with you. `klipper` -> Just removing the `RDEPEND` isn't the right thing. It just should be `RDEPEND="${DEPEND}"`, so it works. But, I just realized something different. Because there isn't any `libart_lgpl-14.0.6.ebuild`, you either have to change that `DEPEND`, or you need to add that ebuild too. The same related to the `libr` ebuild. I am sorry that I noticed that just now. But that shows that some good review is much more important than just getting something done. I can really understand, you want to get that merged and I am likely, but I just want to prevent some later chaos. Please understand that. At the same time, demotivating you is the last I want, okay? Please, keep your motivation! :smile_cat: All my build tests are done with the `master` branch, but I tried to check against the `stable sources`. Keep that in mind. So I might not be fully right either! :sweat_smile: Regarding the `typos` - Great! I will sync with your work regarding to that and other things too. Is is wonderful to see we can improve both more and more. :+1: So, if you allow me, I would like to fix some things by a commit myself, so you can work on other things and you can review my changes than and if all is good, we can merge it, is that okay for you? By the way: I never intendet, that you need to be up to date to my very latest changes (the `id` change for example), but it is wonderful to see you did that too! But I thought it would be good to be in some kind of sync. After all, it is a great gain, to scrutinise dependencies, build options and all this kind of things. So we learn more about the TDE internals. It can be only a gain, please keep that in mind after all. :+1: And some good news: Fat-Zer showed up this night and is positive about our work. He will deprecate his overlay and reference to ours as the new main overlay. Most likely he will join our efforts too, if he has some time. :smile:
Poster
Collaborator

ksmserver: I admit to only grepping the sources, as opposed to inspecting them. When I got a lot of hits for dbus in shutdowndlg.cpp, I didn't bother to check for a conditional.

tdelibs: I was a bit surprised to discover it wasn't there either, but inspection showed that there was no build option to toggle.

khelpcenter: You ran afoul of English-language slang/idiom here. In English (at least the American and Canadian dialects), “Can you [do X] already?” implies “You've been trying to put off [doing X] for a while now, and it's annoying, so can you stop arguing and get it done?” I figured that wasn't what you meant, but . . .

tqt: Builds for me in its current state, but it might be affected by the fact that there's a version already installed.

I think I wrote the libart ebuild and then didn't commit it (although I built originally against the main-tree version of libart and used packages.provided to smoothe out the version problem—sloppy of me). I'll check on that, and tweak klipper and possibly tdelibs and tqt.

(I also apologize for being irritable—it's partially due to Real Life stuff that I shouldn't have brought in here.)

Even if Fat-Zer doesn't have time to do much here, it's nice to know he approves.

ksmserver: I admit to only grepping the sources, as opposed to inspecting them. When I got a lot of hits for dbus in shutdowndlg.cpp, I didn't bother to check for a conditional. tdelibs: I was a bit surprised to discover it wasn't there either, but inspection showed that there was no build option to toggle. khelpcenter: You ran afoul of English-language slang/idiom here. In English (at least the American and Canadian dialects), “Can you [do X] already?” implies “You've been trying to put off [doing X] for a while now, and it's annoying, so can you stop arguing and get it done?” I figured that wasn't what you meant, but . . . tqt: Builds for me in its current state, but it might be affected by the fact that there's a version already installed. I think I wrote the libart ebuild and then didn't commit it (although I built originally against the main-tree version of libart and used packages.provided to smoothe out the version problem—sloppy of me). I'll check on that, and tweak klipper and possibly tdelibs and tqt. (I also apologize for being irritable—it's partially due to Real Life stuff that I shouldn't have brought in here.) Even if Fat-Zer doesn't have time to do much here, it's nice to know he approves.
Chris commented 4 years ago
Collaborator

Its great at least one of us is really great at English! 😸

I will fix the merge conflics and if some little things are left, most likely tomorrow.

If there is more, you can fix it by another PR then. 👍

Its great at least one of us is really great at English! :smile_cat: I will fix the merge conflics and if some little things are left, most likely tomorrow. If there is more, you can fix it by another PR then. :+1:
Poster
Collaborator

Okay, I added in the libart_lgpl ebuild and tweaked tdelibs and klipper. That's all I have time for tonight.

Okay, I added in the libart_lgpl ebuild and tweaked tdelibs and klipper. That's all I have time for tonight.
Chris commented 4 years ago
Collaborator

Great, looks good. Thank you! 👍

Great, looks good. Thank you! :+1:
Poster
Collaborator

What's left to be done on this? I've lost track.

What's left to be done on this? I've lost track.
SlavekB modified the milestone from R14.0.8 release to R14.0.9 release 4 years ago
Chris commented 4 years ago
Collaborator

Nothing, I just have to sorry to you, because I not got to that, because of private things in real life distracted me. 😞

Nothing, I just have to sorry to you, because I not got to that, because of private things in real life distracted me. :disappointed:
Chris commented 4 years ago
Collaborator

I resolved the few merge conflicts now, so your work can be merged finaly. 👍

If there are any further problems or cosmetics you or me can fix them afterwards.
Would be interesting what your results are at this state. Please report here, if you have time and chance.

It's great you already started work on tdeartwork.

Keep up the good work. 😄

I resolved the few merge conflicts now, so your work can be merged finaly. :+1: If there are any further problems or cosmetics you or me can fix them afterwards. Would be interesting what your results are at this state. Please report here, if you have time and chance. It's great you already started work on tdeartwork. Keep up the good work. :smile:
eliddell closed this pull request 4 years ago
SlavekB modified the milestone from R14.0.9 release to R14.0.8 release 4 years ago
Chris deleted branch other/stable-revised 4 years ago
The pull request has been manually merged as e412aa0434.
Sign in to join this conversation.
No reviewers
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: TDE/tde-packaging-gentoo#53
Loading…
There is no content yet.