Interest inquery: kde4-nosemantic overlay

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Interest inquery: kde4-nosemantic overlay

Duncan-42
For kde-4.11, it seems the gentoo/kde project has decided to hard-enable
the former semantic-desktop USE flag, forcing the option on and forcing a
number of formerly optional additional dependencies.[1]

But, I spent quite some time here switching away from kdepim's kmail,
akregator, etc, so I could kill akonadi on my system, and with it
semantic-desktop, etc, and I'm in no mood to have it hard-enabled now.
If it comes to it, I'd rather dump the kde desktop and switch to something
else[2], than have semantic-desktop on my system once again.

But with a bit of luck, I won't have to switch away from kde after all.

I already asked gentoo/kde to reconsider, given that they've supported
USE=-semantic-desktop until now and with 4.11 much of kde4's going into
maintenance mode as the upstream developer focus switches to kde5/kde-
frameworks, so it makes little sense to drop support for -semantic-
desktop now, when upstream is continuing to offer that option at least
thru kde4, and kde5/frameworks is supposed to be far more modular, so with
luck will allow users to pick and choose whether they want the
semantic-desktop components pulled in or not.  However, given the gentoo/
kde project history with dropping kde3 support and forcing kde3 users to
to the user-supported kde-sunset overlay even while kde4 was still not
ready for use (and despite upstream kde's broken promise to support kde3
as long as there continued to be users), I'm not optimistic, but it was
worth a shot.

But the kde-sunset overlay does suggest another alternative, a kde4-
nosemantic overlay.

Meanwhile, as I upgraded to the kde-4.11 pre-releases (currently 4.10.90
aka 4.11-beta2) in the kde overlay, for the kde-desktop-core and other
gentoo/kde packages I still run, I diffed the ebuilds between 4.10.x and
4.10.80 (aka 4.11-beta1), then checked the diffs for non-semantic-desktop
related changes and kept them, while changing the semantic-desktop force-
enabling changes to force-disabling instead.

Then I created a framework that works much like epatch_user, except
instead of automatically applying patches to upstream sources, it
automatically applies patches to gentoo ebuilds and instead of using the
/etc/portage/patches/ tree, it uses /etc/portage/patches.ebuild/.

So now I have a set of ebuild patches that patch the kde 4.11 ebuilds
(starting with 4.10.80, aka 4.11-beta1) to force-disable semantic-
desktop, instead of force-enabling it.  And I have a scripted framework
that auto-applies these patches to new ebuilds on emerge --sync and layman
-S, thus keeping no-semantic around as upstream gentoo/kde updates their
ebuilds.

For now, therefore, I'm fine, up and running on 4.10.90 (aka 4.11-beta2),
using gentoo/kde ebuilds auto-patched to kill the now forced-on semantic-
desktop, forcing it off instead.

But realistically, I honestly don't know if longer term, I'll be able to
continue maintenance of all of this by myself.  Chances are unfortunately
high that without help from others, over time I'll decide it's simply too
much of a hassle maintaining the patches, and will end up switching to
some other desktop, with the qt-based razor-qt desktop one candidate as
sort of a kde-lite desktop, and enlightenment as another, getting away
from kde and qt entirely.

Besides which, if I'm finding kde-nosemantic useful enough to go to all
this trouble, there's a good chance that others will be interested in it
themselves, especially if they don't have to do all the work I'm now doing
myself, themselves.  So with kde-sunset in mind as precedent, I'm now
proposing a kde-nosemantic overlay, like kde-sunset, user-maintained, but
for kde4 folks who want a continued no-semantic choice, instead of kde3
users.

Any interest?

To be further discussed:  Assuming a go-ahead on the general idea, do we
want to maintain it as a normal overlay carrying at least the kde4 ebuilds
that require patching to kill semantic-desktop, or should we simply build
on the epatch_ebuild_user scripts I have hacked up, presumably checking
them into a git repo along with the patches themselves somewhere and
making that available, then simply use that tool with the existing gentoo
tree (when 4.11 is released and ebuilds arrive in the main tree) and kde
project overlay to apply the patches to the existing tree and overlay
instead of creating a full-fledged kde-nosemantic overlay ourselves.  Of
course the tools and patches could then have ebuilds and appear in an
overlay of their own, rather than having the modified kde-nosemantic
ebuilds in an overlay.

One bonus to the tools overlay instead of a direct kde-nosemantic overlay
approach, is that gentooers not interested in kde, but interested in the
ebuild-patch tools, might find that useful, add that overlay to their
layman overlay list, and contribute patches to the ebuild-patches tool,
helping it mature and grow into a general purpose automated-ebuild-
patching tool rather faster than it might otherwise happen.

A hybrid alternative would be to adopt an idea much like the existing kde
overlay, where there's a documentation or tools directory that carries
them, in addition to the kde-base category and etc, carrying the patched
ebuilds themselves.

So what do people think?  Any interest?  How should we go about it?

Or should I just continue working on it on my own, with the likelihood
that at some point I'll decide it's not worth the trouble and switch to a
non-kde desktop, as I've switched to other non-kde tools as the kde
versions jumped the shark over the course of kde4?

In particular, I expect users who are or have been active in the kde-
sunset overlay will have some useful insights.

---
[1] Andreas Huttel, aka gentoo dev dilfridge, covered this on his blog
(which is in turn covered by planet-gentoo, where I subscribe to the feed,
thus seeing it there):

http://dilfridge.blogspot.com/2013/05/news-from-201305-gentoo-kde-team-meeting.html

[2] While during the early kde4 fiasco I was mostly standardized on kde
apps and therefore had little choice, over the course of kde4, I've
switched away from kde apps for first one thing than another, so by now
it's mostly the core kde4 desktop I depend on, plus a few other less vital
apps, games, dolphin, gwenview, superkaramba, that I could leave behind
far more easily now, if I decided I could no longer run the kde-
core-desktop.

--
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


Reply | Threaded
Open this post in threaded view
|

Re: Interest inquery: kde4-nosemantic overlay

Ian Whyman-3

To be honest I see this as a huge over reaction.

Its unclear from your mail if  you did try running it with it disabled at runtime first before hacking the ebuilds... If you did not I do recommended it just to see how little difference it actually makes.

I guess having all the hacks centralised will be useful at least though.

Ian

On 3 Jul 2013 18:33, "Duncan" <[hidden email]> wrote:
For kde-4.11, it seems the gentoo/kde project has decided to hard-enable
the former semantic-desktop USE flag, forcing the option on and forcing a
number of formerly optional additional dependencies.[1]

But, I spent quite some time here switching away from kdepim's kmail,
akregator, etc, so I could kill akonadi on my system, and with it
semantic-desktop, etc, and I'm in no mood to have it hard-enabled now.
If it comes to it, I'd rather dump the kde desktop and switch to something
else[2], than have semantic-desktop on my system once again.

But with a bit of luck, I won't have to switch away from kde after all.

I already asked gentoo/kde to reconsider, given that they've supported
USE=-semantic-desktop until now and with 4.11 much of kde4's going into
maintenance mode as the upstream developer focus switches to kde5/kde-
frameworks, so it makes little sense to drop support for -semantic-
desktop now, when upstream is continuing to offer that option at least
thru kde4, and kde5/frameworks is supposed to be far more modular, so with
luck will allow users to pick and choose whether they want the
semantic-desktop components pulled in or not.  However, given the gentoo/
kde project history with dropping kde3 support and forcing kde3 users to
to the user-supported kde-sunset overlay even while kde4 was still not
ready for use (and despite upstream kde's broken promise to support kde3
as long as there continued to be users), I'm not optimistic, but it was
worth a shot.

But the kde-sunset overlay does suggest another alternative, a kde4-
nosemantic overlay.

Meanwhile, as I upgraded to the kde-4.11 pre-releases (currently 4.10.90
aka 4.11-beta2) in the kde overlay, for the kde-desktop-core and other
gentoo/kde packages I still run, I diffed the ebuilds between 4.10.x and
4.10.80 (aka 4.11-beta1), then checked the diffs for non-semantic-desktop
related changes and kept them, while changing the semantic-desktop force-
enabling changes to force-disabling instead.

Then I created a framework that works much like epatch_user, except
instead of automatically applying patches to upstream sources, it
automatically applies patches to gentoo ebuilds and instead of using the
/etc/portage/patches/ tree, it uses /etc/portage/patches.ebuild/.

So now I have a set of ebuild patches that patch the kde 4.11 ebuilds
(starting with 4.10.80, aka 4.11-beta1) to force-disable semantic-
desktop, instead of force-enabling it.  And I have a scripted framework
that auto-applies these patches to new ebuilds on emerge --sync and layman
-S, thus keeping no-semantic around as upstream gentoo/kde updates their
ebuilds.

For now, therefore, I'm fine, up and running on 4.10.90 (aka 4.11-beta2),
using gentoo/kde ebuilds auto-patched to kill the now forced-on semantic-
desktop, forcing it off instead.

But realistically, I honestly don't know if longer term, I'll be able to
continue maintenance of all of this by myself.  Chances are unfortunately
high that without help from others, over time I'll decide it's simply too
much of a hassle maintaining the patches, and will end up switching to
some other desktop, with the qt-based razor-qt desktop one candidate as
sort of a kde-lite desktop, and enlightenment as another, getting away
from kde and qt entirely.

Besides which, if I'm finding kde-nosemantic useful enough to go to all
this trouble, there's a good chance that others will be interested in it
themselves, especially if they don't have to do all the work I'm now doing
myself, themselves.  So with kde-sunset in mind as precedent, I'm now
proposing a kde-nosemantic overlay, like kde-sunset, user-maintained, but
for kde4 folks who want a continued no-semantic choice, instead of kde3
users.

Any interest?

To be further discussed:  Assuming a go-ahead on the general idea, do we
want to maintain it as a normal overlay carrying at least the kde4 ebuilds
that require patching to kill semantic-desktop, or should we simply build
on the epatch_ebuild_user scripts I have hacked up, presumably checking
them into a git repo along with the patches themselves somewhere and
making that available, then simply use that tool with the existing gentoo
tree (when 4.11 is released and ebuilds arrive in the main tree) and kde
project overlay to apply the patches to the existing tree and overlay
instead of creating a full-fledged kde-nosemantic overlay ourselves.  Of
course the tools and patches could then have ebuilds and appear in an
overlay of their own, rather than having the modified kde-nosemantic
ebuilds in an overlay.

One bonus to the tools overlay instead of a direct kde-nosemantic overlay
approach, is that gentooers not interested in kde, but interested in the
ebuild-patch tools, might find that useful, add that overlay to their
layman overlay list, and contribute patches to the ebuild-patches tool,
helping it mature and grow into a general purpose automated-ebuild-
patching tool rather faster than it might otherwise happen.

A hybrid alternative would be to adopt an idea much like the existing kde
overlay, where there's a documentation or tools directory that carries
them, in addition to the kde-base category and etc, carrying the patched
ebuilds themselves.

So what do people think?  Any interest?  How should we go about it?

Or should I just continue working on it on my own, with the likelihood
that at some point I'll decide it's not worth the trouble and switch to a
non-kde desktop, as I've switched to other non-kde tools as the kde
versions jumped the shark over the course of kde4?

In particular, I expect users who are or have been active in the kde-
sunset overlay will have some useful insights.

---
[1] Andreas Huttel, aka gentoo dev dilfridge, covered this on his blog
(which is in turn covered by planet-gentoo, where I subscribe to the feed,
thus seeing it there):

http://dilfridge.blogspot.com/2013/05/news-from-201305-gentoo-kde-team-meeting.html

[2] While during the early kde4 fiasco I was mostly standardized on kde
apps and therefore had little choice, over the course of kde4, I've
switched away from kde apps for first one thing than another, so by now
it's mostly the core kde4 desktop I depend on, plus a few other less vital
apps, games, dolphin, gwenview, superkaramba, that I could leave behind
far more easily now, if I decided I could no longer run the kde-
core-desktop.

--
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


Reply | Threaded
Open this post in threaded view
|

Re: Interest inquery: kde4-nosemantic overlay

Duncan-42
Ian Whyman posted on Thu, 04 Jul 2013 07:48:01 +0100 as excerpted:

> To be honest I see this as a huge over reaction.
>
> Its unclear from your mail if  you did try running it with it disabled
> at runtime first before hacking the ebuilds... If you did not I do
> recommended it just to see how little difference it actually makes.
>
> I guess having all the hacks centralised will be useful at least though.

FWIW, I did run it up thru kde 4.6.  That's when I decided I didn't use
it anyway, so I might as well turn it off at build-time and avoid the
additional dependencies.

Now they /say/ semantic-desktop is far faster now, and easily run-time
disabled as well, and while I've certainly seen "the new, improved
semantic-desktop" story from kde enough times to not put a lot of
credence in that (not that kde was lying about the claims, but there's
"improved" and there's 'improved'...), the gentoo/kde devs do have
somewhat better credibility IMO and /they/ are saying it now, so I won't
argue that it's not the case.

So I'm not arguing that it can't be runtime disabled, or even that
performance might not have improved to the point where having it on isn't
a big deal either.

However, that doesn't change the fact that if I don't use it, I don't use
it, and I don't want or need all those additional deps (when I disabled
it, I was actually rather surprised at the number of packages I no longer
needed and was able to remove... only to allow them back on my system if
gentoo/kde had their way... which in this case they won't, not on my
system) it pulls in on my system, period.  Among other things, having
unused stuff on one's system is bad security practice.  One thing I've
found by experience about gentoo, and as it happens, generally like, is
that the very fact that because one is actually building all updates, not
simply installing binaries, over time and multiple updates it tends to
reasonably strongly discourage even having unused stuff installed -- thus
encouraging what's good security practice in any case. =:^)  And of
course in the normal case, either simply removing the unused package from
the world file or tweaking USE flags to avoid pulling it in (plus the
depclean to actually remove it), is all that's necessary to remove it, if
indeed it's truly unused.

Which is what's so frustrating here, as gentoo/kde is subverting the
normal gentoo process and way, forcing entirely unneeded and unused
dependencies, unless users take drastic measures like creating the
necessary patches to revert the force, and a script to auto-apply said
patches them as updates occur.

As one of the comments on the previously linked blog post stated, Larry
the Cow isn't amused! =:^(

So yes, arguably it /is/ making a big deal out of nothing.  OTOH, that's
what all the binary-distro folks say about the whole admin controls
optional deps via USE flags and actually building the package themselves,
too.  If I didn't feel strongly about that sort of thing, why would I
even bother with all build-from-sources hassle of gentoo in the first
place?  There's a number of reasons I'm a gentooer, and /none/ of them
are because I want distro package maintainers making my choices for me
about optional deps.

What's even more galling is that thru all of kde4 until 4.11, for a
number of kde packages declared the last feature release of the kde4
series, gentoo/kde has had the semantic-desktop USE flag.  With kde5/kde-
frameworks, upstream kde is going far more modular, with a much smaller
core (for two reasons, as part of the base functionality is actually
moving to qt5 as well as the actual lower kde base package count, so the
kde core should be MUCH smaller indeed), making everything else
optional.  Now I don't know for /sure/ that semantic-desktop is one (or
more) of the optional modules not part of core, but given it was optional
in kde4 and they're going more modular in kde5/frameworks, /not/ making
it optional in the latter would be a direct step backward from the
declared goal, so it should be reasonably unlikely.

Which means all of kde4 thru 4.10 would have had optional semantic-
desktop, and kde5/frameworks should have it optional as well, making hard-
enabling semantic-desktop for the 4.11 longer-term maintenance release
even less reasonable than it'd be if kde5 was going to force it on
upstream.

But as is so often said, in FLOSS, most devs are to a large extent simply
scratching their own itches, and it seems all the gentoo/kde devs use
semantic-desktop so dealing with the option is simply a hassle, not an
itch any of them has to scratch.  Of course it was the same thing with
kde3/kde4, none of the gentoo/kde devs were interested in maintaining
kde3 any longer despite the fact that kde4 was still very broken for the
needs of many users, so they simply dropped it, or rather, pushed it off
into the user-maintained kde-sunset overlay.  So I don't really expect
any different here, nor in fact am I really demanding it, tho it would
certainly be nice.  I'm simply disappointed, is all.  I'm prepared to do
what I must, but I'm disappointed, if not entirely surprised, that it
came to this.  Oh, well...

--
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


Reply | Threaded
Open this post in threaded view
|

Re: Interest inquery: kde4-nosemantic overlay

Alex Alexander
In reply to this post by Duncan-42
On Wed, Jul 03, 2013 at 05:32:25PM +0000, Duncan wrote:

> I already asked gentoo/kde to reconsider, given that they've supported
> USE=-semantic-desktop until now and with 4.11 much of kde4's going into
> maintenance mode as the upstream developer focus switches to kde5/kde-
> frameworks, so it makes little sense to drop support for -semantic-
> desktop now, when upstream is continuing to offer that option at least
> thru kde4, and kde5/frameworks is supposed to be far more modular, so with
> luck will allow users to pick and choose whether they want the
> semantic-desktop components pulled in or not.  However, given the gentoo/
> kde project history with dropping kde3 support and forcing kde3 users to
> to the user-supported kde-sunset overlay even while kde4 was still not
> ready for use (and despite upstream kde's broken promise to support kde3
> as long as there continued to be users), I'm not optimistic, but it was
> worth a shot.

Being part of the team that decided to remove KDE3 from the tree, I
assure you that it wasn't an easy decision. Unfortunately, KDE3 was in
really bad shape. Upstream had abandoned it, build tools slowly became
incompatible with it and maintaining it became a big PITA for the KDE
team.

A lot of work had been put into making KDE3 and KDE4 co-exist already,
since we too felt that KDE4 was not ready and I'm pretty sure we kept it
around longer than most distros out there.

But at some point KDE4 became usable and we had to move on, for our own
sanity.

--

That said, I do agree that semantic-desktop should stay optional in
KDE4.  Back in my KDE days I hated it and always ensured it - and its
ugly dependencies - stayed off my system. Unfortunately I am not part of
the KDE team anymore, so I don't know what their reasoning is behind
this decision. Hopefully they will reconsider :)

--
Alex Alexander | wired@gentoo
+ www.linuxized.com
++ www.leetworks.com

Reply | Threaded
Open this post in threaded view
|

Re: Interest inquery: kde4-nosemantic overlay

Duncan-42
Alex Alexander posted on Fri, 05 Jul 2013 01:02:24 +0300 as excerpted:

> Being part of the team that decided to remove KDE3 from the tree, I
> assure you that it wasn't an easy decision. Unfortunately, KDE3 was in
> really bad shape. Upstream had abandoned it, build tools slowly became
> incompatible with it and maintaining it became a big PITA for the KDE
> team.
>
> A lot of work had been put into making KDE3 and KDE4 co-exist already,
> since we too felt that KDE4 was not ready and I'm pretty sure we kept it
> around longer than most distros out there.
>
> But at some point KDE4 became usable and we had to move on, for our own
> sanity.

Thanks.

FWIW, I agree.  It was really upstream that dropped the ball on that one,
especially after ASeigo's (in)famous promise.  Both distros and users
were left to pick up the pieces on their own.

As for the timing, by the time kde3 actually headed to sunset, I had been
switched over for a couple months (maybe a bit more?) already, as I had
seen the gentoo/kde discussion and knew they were dropping it... with
little real choice given upstream kde had already dropped it, and by 4.2,
was claiming kde4 was ready for ordinary users despite it being horribly
broken alpha quality at best.

And it's a good thing I /did/ get a relatively early start, since even
tho I had been trying kde4 on and off since before its initial release,
it was simply still to broken to switch to directly, without a *LOT* of
tweaking and substitution of alternative options where there simply
wasn't a kde4 option yet (and in some cases still isn't, proper khotkeys
multi-key support being a case in point, but I ended up hacking together
a solution that worked for me).  I actually switched with 4.2.5, but it
took me well over a hundred hours (that's when I stopped counting, and I
was being conservative) of stress and sweat to complete the transition.  
Obviously, few would tolerate that, so it was still broken (alpha) by
definition.

Late in 4.5, say 4.5.4 or so, was the first version I considered truly
first-release quality, and that would have been a *LONG* time for a distro
to try to support kde3 without upstream itself helping.  I guess Debian
stable effectively did that, but Debian stable isn't a rolling distro and
wasn't constantly upgrading the rest of the distribution out from
underneath the stale kde3, breaking it in the process, either.  (Of
course, just when everything else was settling down, the kdepim devs had
to repeat pretty much the same story with akonadified kmail, in kdepim-4.6
+... the MIDDLE of what SHOULD have been a a stable-api series!  Anyone
sane would have reserved that for the 4.x -> 5.x transition, but that's a
whole different story.  OTOH, it was that which finally triggered my
switch off kmail/akonadi/kdepim entirely, and with that gone I no longer
had a reason to keep semantic-desktop on, so that's when I killed it here
too, thus setting the stage for this entire thread...)


On the bright side, tho, at least here all that work you put into making
kde3 and kde4 coexist reasonably peacefully was definitely NOT a waste.  
It was that work, after all, that finally allowed me a successful
transition to kde4, a single app at a time, by running the kde4 version
on what began as a kde3 desktop, configuring it to usability, then
unmerging the kde3 version so the kde4 version ran by default.  (Long
hairy app-by-app-transition account that was in my first post revision
elided as unnecessary...)

By switching to and configuring a kde4 app at a time, I was able to work
around two separate triggers of what turned out later to be a single root
blocker bug (the qt4-related painter bug fixed around 4.3.2 or 4.3.4),
the worst in plasma, the bad enough one in kwin, that were previously
making kde4 performance so horribly glacial that I simply couldn't work
in it long enough to configure it to my satisfaction and make the
transition.  Plus some other less major problems that helped me work thru,
of course...

And if kde3 and kde4 hadn't been usable at the same time, app-at-a-time
kde4 configuration while still working in a kde3 base desktop wouldn't
have been possible.  So I'm glad gentoo/kde /had/ put all the work they
did into letting them run side-by-side. =:^)

> That said, I do agree that semantic-desktop should stay optional in
> KDE4. Back in my KDE days I hated it and always ensured it - and its
> ugly dependencies - stayed off my system. Unfortunately I am not part of
> the KDE team anymore, so I don't know what their reasoning is behind
> this decision. Hopefully they will reconsider :)

Thanks.

With some luck... but I'm not counting on it.  And thankfully, I'm an
experienced and well versed enough gentooer now that I /can/ handle the
patching, at least relatively short term.  It's longer term that I'm
worried about.

But again with some luck, frameworks will get to be usable quickly enough
that I shouldn't have to deal with the patches for
/too/ long.  All upstream indications so far is that they don't want a
repeat of the early kde4 fiasco either, and the transition should be much
smoother.  That's in addition to the modularity, with the stated goal of
people being able to mix and match kde4 and kde5/frameworks apps as
desired, and only upgrade to the kde5/frameworks versions when the
individual apps are ready for it.

And there's already a very rough early alpha frameworks preview out
(AFAIK with 4.11-beta1), and a kde/kwin/wayland preview (which altho it's
a WIP, gentoo/kde /is/ apparently supporting, I see the wayland USE flags
already but haven't been brave enough to try wayland at all, yet) as well.

--
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


Reply | Threaded
Open this post in threaded view
|

Re: Interest inquery: kde4-nosemantic overlay

Michael Palimaka
In reply to this post by Alex Alexander
On 5/07/2013 08:02, Alex Alexander wrote:
> That said, I do agree that semantic-desktop should stay optional in
> KDE4.  Back in my KDE days I hated it and always ensured it - and its
> ugly dependencies - stayed off my system. Unfortunately I am not part of
> the KDE team anymore, so I don't know what their reasoning is behind
> this decision. Hopefully they will reconsider :)
>
The reason is that code like this is appearing increasingly throughout
the KDE SC:
find_package(Akonadi REQUIRED)
set_package_properties(NepomukCore PROPERTIES TYPE REQUIRED)

That is, we must maintain hacks in order to disable upstream's
requirements. They are difficult to maintain and also put us in a bad
standing with upstream.

Best regards,
Michael


Reply | Threaded
Open this post in threaded view
|

Re: Interest inquery: kde4-nosemantic overlay

Duncan-42
Michael Palimaka posted on Sat, 06 Jul 2013 23:12:42 +1000 as excerpted:

> On 5/07/2013 08:02, Alex Alexander wrote:
>> That said, I do agree that semantic-desktop should stay optional in
>> KDE4.  Back in my KDE days I hated it and always ensured it - and its
>> ugly dependencies - stayed off my system. Unfortunately I am not part
>> of the KDE team anymore, so I don't know what their reasoning is behind
>> this decision. Hopefully they will reconsider :)
>>
> The reason is that code like this is appearing increasingly throughout
> the KDE SC:
> find_package(Akonadi REQUIRED)
> set_package_properties(NepomukCore PROPERTIES TYPE REQUIRED)
>
> That is, we must maintain hacks in order to disable upstream's
> requirements. They are difficult to maintain and also put us in a bad
> standing with upstream.

That's actually why I ended up package.providing kdebase-runtime-meta
(along with ksplash, kdesu and kdnssd, for similar not-really-necessary,
more-useless-hassle-to-upgrade when I'm running live-branch kde, reasons)
here, since it's otherwise a dependency, and it in turn pulls in drkonqi,
which at one point anyway required something kdepim related to send the
mail, and when I killed kdepim on my system, I wanted nothing to do with
that, so I package.provided kdebase-runtime-meta in ordered to be able to
use (a copy of) the kdebase-runtime set instead, with bits like drkonqi
commented so as not to bring them in.  (With stripping it's not like
drkonqi ever thought the traces were usable anyway, and it's a runtime-
dep-only, that's only activated when an app crashes in any case, only to
tell me it can't use the generated reports anyway, so why even have it
installed in the first place, especially when it's pulling in some weird
kdepim dep that I otherwise can keep off my system.)

Of course that drkonqi kdepim dependency was added in one of the betas a
few feature releases ago, and as I hacked that and various other bits,
gradually adding one package.provided or patch on another to keep kde
updating, I gradually gained the experience and familiarity with kde
internals that allowed me to even /think/ about doing the whole no-
semantic patch series I'm doing now.  Had things started out with that,
I'd have not thought I could, but I'm into it deep enough now, it's just
one more layer piled on the others.

--
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


Reply | Threaded
Open this post in threaded view
|

Re: Interest inquery: kde4-nosemantic overlay

Johannes Huber
Am Samstag, 6. Juli 2013, 16:51:54 schrieb Duncan:

> Michael Palimaka posted on Sat, 06 Jul 2013 23:12:42 +1000 as excerpted:
> > On 5/07/2013 08:02, Alex Alexander wrote:
> >> That said, I do agree that semantic-desktop should stay optional in
> >> KDE4.  Back in my KDE days I hated it and always ensured it - and its
> >> ugly dependencies - stayed off my system. Unfortunately I am not part
> >> of the KDE team anymore, so I don't know what their reasoning is behind
> >> this decision. Hopefully they will reconsider :)
> >
> > The reason is that code like this is appearing increasingly throughout
> > the KDE SC:
> > find_package(Akonadi REQUIRED)
> > set_package_properties(NepomukCore PROPERTIES TYPE REQUIRED)
> >
> > That is, we must maintain hacks in order to disable upstream's
> > requirements. They are difficult to maintain and also put us in a bad
> > standing with upstream.
>
> That's actually why I ended up package.providing kdebase-runtime-meta
> (along with ksplash, kdesu and kdnssd, for similar not-really-necessary,
> more-useless-hassle-to-upgrade when I'm running live-branch kde, reasons)
> here, since it's otherwise a dependency, and it in turn pulls in drkonqi,
> which at one point anyway required something kdepim related to send the
> mail, and when I killed kdepim on my system, I wanted nothing to do with
> that, so I package.provided kdebase-runtime-meta in ordered to be able to
> use (a copy of) the kdebase-runtime set instead, with bits like drkonqi
> commented so as not to bring them in.  (With stripping it's not like
> drkonqi ever thought the traces were usable anyway, and it's a runtime-
> dep-only, that's only activated when an app crashes in any case, only to
> tell me it can't use the generated reports anyway, so why even have it
> installed in the first place, especially when it's pulling in some weird
> kdepim dep that I otherwise can keep off my system.)
>
> Of course that drkonqi kdepim dependency was added in one of the betas a
> few feature releases ago, and as I hacked that and various other bits,
> gradually adding one package.provided or patch on another to keep kde
> updating, I gradually gained the experience and familiarity with kde
> internals that allowed me to even /think/ about doing the whole no-
> semantic patch series I'm doing now.  Had things started out with that,
> I'd have not thought I could, but I'm into it deep enough now, it's just
> one more layer piled on the others.
For the record you offer nothing for users who want to use kdepim and thats
where the big story ends for us.

Greetings

--
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD

signature.asc (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Interest inquery: kde4-nosemantic overlay

Duncan-42
Johannes Huber posted on Sat, 06 Jul 2013 19:02:55 +0200 as excerpted:

> For the record you offer nothing for users who want to use kdepim and
> thats where the big story ends for us.

Well, obviously if they want to use kdepim, they need to have the
dependencies (now) needed for it... which basically means semantic-
desktop.  That's a given.  But for those who steer well clear of kdepim
in part because of its heavy deps... it'd be nice to still have the
choice to /avoid/ those deps... without having to hack and patch ebuilds
to do it.

Just the usual options gentooers are used to having, both in general and
specifically with kde4, is all.

But I didn't go into this expecting to change gentoo/kde policy.  I
thought I'd ask, just in case, but I didn't expect it to change.  Given
that the only user response so far is (effectively) that I'm making a
mountain out of a molehill...  Tho I'm not sure how many people in the
potential audience actually read this list.  If I were to start a thread
on the forums and if I had added a comment to the blog-post announcing
the gentoo/kde policy change asking if there's interest there, since
there /were/ a couple comments expressing disappointment...  But I'll
probably just continue doing the patches myself, until 5/frameworks gets
in good enough shape to migrate to it (assuming that's not too distant),
at which point, hopefully, upstream will be modular enough that there
won't be an issue any longer.  Else, if that turns out to be too far out
and I can't maintain the patches, I'll simply find another desktop.  As I
said, unlike with the early kde4 thing, that's actually a practical
option, now.

--
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


Reply | Threaded
Open this post in threaded view
|

Re: Interest inquery: kde4-nosemantic overlay

Dominique Michel-2
In reply to this post by Duncan-42
Le Wed, 3 Jul 2013 17:32:25 +0000 (UTC),
Duncan <[hidden email]> a écrit :

> For kde-4.11, it seems the gentoo/kde project has decided to
> hard-enable the former semantic-desktop USE flag, forcing the option
> on and forcing a number of formerly optional additional
> dependencies.[1]

With USE="-consolekit -policykit -semantic-desktop -udisks
-udisks2 -upowe", I get ride of both *kit and semantic-desktop in kde,
and of the whole of gnome as a bonus. -:)

I have only parts of kde in my system, but I made such a profile for
the pro-audio overlay, and no user complained it was not working. It is
another one as generic dekstop profile.

The main concern was *kit, which is mandatory with only very few
desktops like Gnome, but is enabled into all the gentoo desktop
profiles -:(. When I see it was possible to speed up kde by removing the
semantic desktop, I did a desktop-kde profile too.

>
> But, I spent quite some time here switching away from kdepim's kmail,
> akregator, etc, so I could kill akonadi on my system, and with it
> semantic-desktop, etc, and I'm in no mood to have it hard-enabled now.
> If it comes to it, I'd rather dump the kde desktop and switch to
> something else[2], than have semantic-desktop on my system once again.
>
> But with a bit of luck, I won't have to switch away from kde after
> all.
>
> I already asked gentoo/kde to reconsider, given that they've supported
> USE=-semantic-desktop until now and with 4.11 much of kde4's going
> into maintenance mode as the upstream developer focus switches to
> kde5/kde- frameworks, so it makes little sense to drop support for
> -semantic- desktop now, when upstream is continuing to offer that
> option at least thru kde4, and kde5/frameworks is supposed to be far
> more modular, so with luck will allow users to pick and choose
> whether they want the semantic-desktop components pulled in or not.
> However, given the gentoo/ kde project history with dropping kde3
> support and forcing kde3 users to to the user-supported kde-sunset
> overlay even while kde4 was still not ready for use (and despite
> upstream kde's broken promise to support kde3 as long as there
> continued to be users), I'm not optimistic, but it was worth a shot.
>
> But the kde-sunset overlay does suggest another alternative, a kde4-
> nosemantic overlay.
>
> Meanwhile, as I upgraded to the kde-4.11 pre-releases (currently
> 4.10.90 aka 4.11-beta2) in the kde overlay, for the kde-desktop-core
> and other gentoo/kde packages I still run, I diffed the ebuilds
> between 4.10.x and 4.10.80 (aka 4.11-beta1), then checked the diffs
> for non-semantic-desktop related changes and kept them, while
> changing the semantic-desktop force- enabling changes to
> force-disabling instead.
>
> Then I created a framework that works much like epatch_user, except
> instead of automatically applying patches to upstream sources, it
> automatically applies patches to gentoo ebuilds and instead of using
> the /etc/portage/patches/ tree, it uses /etc/portage/patches.ebuild/.
>
> So now I have a set of ebuild patches that patch the kde 4.11 ebuilds
> (starting with 4.10.80, aka 4.11-beta1) to force-disable semantic-
> desktop, instead of force-enabling it.  And I have a scripted
> framework that auto-applies these patches to new ebuilds on emerge
> --sync and layman -S, thus keeping no-semantic around as upstream
> gentoo/kde updates their ebuilds.
>
> For now, therefore, I'm fine, up and running on 4.10.90 (aka
> 4.11-beta2), using gentoo/kde ebuilds auto-patched to kill the now
> forced-on semantic- desktop, forcing it off instead.
>
> But realistically, I honestly don't know if longer term, I'll be able
> to continue maintenance of all of this by myself.  Chances are
> unfortunately high that without help from others, over time I'll
> decide it's simply too much of a hassle maintaining the patches, and
> will end up switching to some other desktop, with the qt-based
> razor-qt desktop one candidate as sort of a kde-lite desktop, and
> enlightenment as another, getting away from kde and qt entirely.
>
> Besides which, if I'm finding kde-nosemantic useful enough to go to
> all this trouble, there's a good chance that others will be
> interested in it themselves, especially if they don't have to do all
> the work I'm now doing myself, themselves.  So with kde-sunset in
> mind as precedent, I'm now proposing a kde-nosemantic overlay, like
> kde-sunset, user-maintained, but for kde4 folks who want a continued
> no-semantic choice, instead of kde3 users.
>
> Any interest?
>
> To be further discussed:  Assuming a go-ahead on the general idea, do
> we want to maintain it as a normal overlay carrying at least the kde4
> ebuilds that require patching to kill semantic-desktop, or should we
> simply build on the epatch_ebuild_user scripts I have hacked up,
> presumably checking them into a git repo along with the patches
> themselves somewhere and making that available, then simply use that
> tool with the existing gentoo tree (when 4.11 is released and ebuilds
> arrive in the main tree) and kde project overlay to apply the patches
> to the existing tree and overlay instead of creating a full-fledged
> kde-nosemantic overlay ourselves.  Of course the tools and patches
> could then have ebuilds and appear in an overlay of their own, rather
> than having the modified kde-nosemantic ebuilds in an overlay.
>
> One bonus to the tools overlay instead of a direct kde-nosemantic
> overlay approach, is that gentooers not interested in kde, but
> interested in the ebuild-patch tools, might find that useful, add
> that overlay to their layman overlay list, and contribute patches to
> the ebuild-patches tool, helping it mature and grow into a general
> purpose automated-ebuild- patching tool rather faster than it might
> otherwise happen.
>
> A hybrid alternative would be to adopt an idea much like the existing
> kde overlay, where there's a documentation or tools directory that
> carries them, in addition to the kde-base category and etc, carrying
> the patched ebuilds themselves.
>
> So what do people think?  Any interest?  How should we go about it?
>
> Or should I just continue working on it on my own, with the likelihood
> that at some point I'll decide it's not worth the trouble and switch
> to a non-kde desktop, as I've switched to other non-kde tools as the
> kde versions jumped the shark over the course of kde4?
>
> In particular, I expect users who are or have been active in the kde-
> sunset overlay will have some useful insights.
>
> ---
> [1] Andreas Huttel, aka gentoo dev dilfridge, covered this on his blog
> (which is in turn covered by planet-gentoo, where I subscribe to the
> feed, thus seeing it there):
>
> http://dilfridge.blogspot.com/2013/05/news-from-201305-gentoo-kde-team-meeting.html
>
> [2] While during the early kde4 fiasco I was mostly standardized on
> kde apps and therefore had little choice, over the course of kde4,
> I've switched away from kde apps for first one thing than another, so
> by now it's mostly the core kde4 desktop I depend on, plus a few
> other less vital apps, games, dolphin, gwenview, superkaramba, that I
> could leave behind far more easily now, if I decided I could no
> longer run the kde- core-desktop.
>


--
"We have the heroes we deserve."

Reply | Threaded
Open this post in threaded view
|

Re: Interest inquery: kde4-nosemantic overlay

Duncan-42
Dominique Michel posted on Sun, 07 Jul 2013 12:10:29 +0200 as excerpted:

> With USE="-consolekit -policykit -semantic-desktop -udisks -udisks2
> -upowe", I get ride of both *kit and semantic-desktop in kde, and of the
> whole of gnome as a bonus. -:)

That's very similar (identical?) to what I have.  But the semantic-
desktop flag is going away for kde 4.11... unfortunately, and they're
forcing semantic-desktop on.  The gentoo/kde project reasoning is in the
link I provided in the thread starter.

You might try razor-qt or a gtk-based desktop instead.  Or... my patches.

--
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


Reply | Threaded
Open this post in threaded view
|

Re: Interest inquery: kde4-nosemantic overlay

Dominique Michel-2
Le Sun, 7 Jul 2013 21:41:36 +0000 (UTC),
Duncan <[hidden email]> a écrit :

> Dominique Michel posted on Sun, 07 Jul 2013 12:10:29 +0200 as
> excerpted:
>
> > With USE="-consolekit -policykit -semantic-desktop -udisks -udisks2
> > -upowe", I get ride of both *kit and semantic-desktop in kde, and
> > of the whole of gnome as a bonus. -:)
>
> That's very similar (identical?) to what I have.  But the semantic-
> desktop flag is going away for kde 4.11... unfortunately, and they're
> forcing semantic-desktop on.  The gentoo/kde project reasoning is in
> the link I provided in the thread starter.
>
> You might try razor-qt or a gtk-based desktop instead.  Or... my

Thanks, I am happy with fvwm-crystal from years. And I am not
interested to maintain patches in the pro-audio overlay for a desktop
I will not use anyway.

Dominique

> patches.
>


--
"We have the heroes we deserve."

Reply | Threaded
Open this post in threaded view
|

Re: Interest inquery: kde4-nosemantic overlay

Martin Vaeth
In reply to this post by Duncan-42
Duncan <[hidden email]> wrote:
>
> Given
> that the only user response so far is (effectively) that I'm making a
> mountain out of a molehill...

I just post to let you know that you are not alone  :)

You also have friends in the forum sharing your opinion
https://forums.gentoo.org/viewtopic-t-963504-highlight-.html

Your effort is really appreciated.
However, I guess that most people are like me and just gave up:
If it really means to make new upstream patches and actually
fight against upstream policy, it is not worth the hassle.
The change of the Gentoo policy caused me to remove KDE,
and I guess most users who do not want the dependencies
have done (or will do) the same.

Independently on the overlay, I think your framework is
very interesting: Does your framework manage the ebuilds
in some overlay, or is it actually running tranparently
during emerge (probably with a patched version of portage),
allowing e.g. to change metadata without maintaining the
ebuild in a separate local overlay?
(I guess that it is the former, but your choice of the path
/etc/portage/... suggests the latter)


Reply | Threaded
Open this post in threaded view
|

kde-lean ;)

Steven J. Long
In reply to this post by Duncan-42
<Resend after subscribe>
Duncan wrote:
> For kde-4.11, it seems the gentoo/kde project has decided to hard-enable
> the former semantic-desktop USE flag, forcing the option on and forcing a
> number of formerly optional additional dependencies.[1]
>
> But, I spent quite some time here switching away from kdepim's kmail,
> akregator, etc, so I could kill akonadi on my system, and with it
> semantic-desktop, etc, and I'm in no mood to have it hard-enabled now.
> If it comes to it, I'd rather dump the kde desktop and switch to something
> else[2], than have semantic-desktop on my system once again.

I *totally* concur. After finally getting rid of KMail, it took me 9 months
to work out and feel comfortable with mutt[1], and then it was much less of a
step to get rid of nubkit, as well as semantic-craptop.

Finally, at 4.9 my KDE has come back to me, and feels as slick as 3.5 :-)

That's progress for ya.. ;p

> But with a bit of luck, I won't have to switch away from kde after all.
..

> Meanwhile, as I upgraded to the kde-4.11 pre-releases (currently 4.10.90
> aka 4.11-beta2) in the kde overlay, for the kde-desktop-core and other
> gentoo/kde packages I still run, I diffed the ebuilds between 4.10.x and
> 4.10.80 (aka 4.11-beta1), then checked the diffs for non-semantic-desktop
> related changes and kept them, while changing the semantic-desktop force-
> enabling changes to force-disabling instead.
>
> Then I created a framework that works much like epatch_user, except
> instead of automatically applying patches to upstream sources, it
> automatically applies patches to gentoo ebuilds and instead of using the
> /etc/portage/patches/ tree, it uses /etc/portage/patches.ebuild/.

Hmm that's quite interesting. Not something I'd personally want in the tree,
but definitely of interest to more advanced admins, as opposed to end-users.

(Yeah, we're all admins. Still, I don't administer a large network, and I
don't call myself a sys-admin. I just appreciate good infra.)

> So now I have a set of ebuild patches that patch the kde 4.11 ebuilds
> (starting with 4.10.80, aka 4.11-beta1) to force-disable semantic-
> desktop, instead of force-enabling it.  And I have a scripted framework
> that auto-applies these patches to new ebuilds on emerge --sync and layman
> -S, thus keeping no-semantic around as upstream gentoo/kde updates their
> ebuilds.

Have to say I think I'd prefer this as a semi-automatically generated overlay.
ie apply the patches, and if they work, let the maintainer confirm after
testing.

> For now, therefore, I'm fine, up and running on 4.10.90 (aka 4.11-beta2),
> using gentoo/kde ebuilds auto-patched to kill the now forced-on semantic-
> desktop, forcing it off instead.
>
> But realistically, I honestly don't know if longer term, I'll be able to
> continue maintenance of all of this by myself.  Chances are unfortunately
> high that without help from others, over time I'll decide it's simply too
> much of a hassle maintaining the patches

Indeed. You shouldn't be doing this alone, over the longer-term: it'll just
burn you out.

> Besides which, if I'm finding kde-nosemantic useful enough to go to all
> this trouble, there's a good chance that others will be interested in it
> themselves, especially if they don't have to do all the work I'm now doing
> myself, themselves.  So with kde-sunset in mind as precedent, I'm now
> proposing a kde-nosemantic overlay, like kde-sunset, user-maintained, but
> for kde4 folks who want a continued no-semantic choice, instead of kde3
> users.
>
> Any interest?

Hell yeah :-)[2] You picked an odd forum for it though: I only found out about
this because Dominique posted to pro-audio list.

> To be further discussed:  Assuming a go-ahead on the general idea, do we
> want to maintain it as a normal overlay carrying at least the kde4 ebuilds
> that require patching to kill semantic-desktop

Yes, as above. I much prefer the traceability of an overlay with conventional
ebuilds in it. If we're going to do this, let's do it right.

> or should we simply build
> on the epatch_ebuild_user scripts I have hacked up, presumably checking
> them into a git repo along with the patches themselves somewhere and
> making that available
..
> One bonus to the tools overlay instead of a direct kde-nosemantic overlay
> approach, is that gentooers not interested in kde, but interested in the
> ebuild-patch tools, might find that useful, add that overlay to their
> layman overlay list, and contribute patches to the ebuild-patches tool,
> helping it mature and grow into a general purpose automated-ebuild-
> patching tool rather faster than it might otherwise happen.

Yes, the tools should be available in their own right.

Tho that was an awfully long-winded way of saying "Ebuild-patch tools could
well be of wider interest." ;)

> A hybrid alternative would be to adopt an idea much like the existing kde
> overlay, where there's a documentation or tools directory that carries
> them, in addition to the kde-base category and etc, carrying the patched
> ebuilds themselves.

That sounds ideal, but why not just have two overlays? One for ebuild-patch
which others can use and collaborate around, and one conventional kde-lean
for people who want the end-product.

After all, ebuild-patch tools are strictly for maintainers, and people who
want to experiment on their system. The output ebuilds have an orthogonal use.

I'd ask that we collaborate on the forums[2] about this: things can move much
quicker there, and you get general encouragement and lots of bug feedback,
as well as others to help.

creaker patched kdelibs, as you'll see, already, and he's interested in
working on the overlay ("Without overlay it may be boring to do the things
I did before on every update.") So between the two of you, and as others
get involved, I'm sure it can be done. As you said, KDE-4 is practically
EOL, given that more developer focus is on 5.

I can get the overlays, git and trac setup, same as we did for hardened a few
years ago, if that helps.

Regards,
steveL.

[1] Kmail to mutt with Maildir and procmail:
    http://forums.gentoo.org/viewtopic-t-945868.html
   
[2] How to opt out of a semantic-desktop?
    http://forums.gentoo.org/viewtopic-t-963504.html
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Reply | Threaded
Open this post in threaded view
|

Re: Interest inquery: kde4-nosemantic overlay

Duncan-42
In reply to this post by Martin Vaeth
Martin Vaeth posted on Thu, 11 Jul 2013 07:25:37 +0000 as excerpted:

> Independently on the overlay, I think your framework is very
> interesting:
> Does your framework manage the ebuilds in some overlay, or is it
> actually running tranparently during emerge (probably with a patched
> version of portage), allowing e.g. to change metadata without
> maintaining the ebuild in a separate local overlay?
> (I guess that it is the former, but your choice of the path
> /etc/portage/... suggests the latter)

To be explicit, I'm using the official gentoo/kde overlay, which of
course is the only place with kde 4.11 series (4.10.80+) ebuilds ATM,
since 4.11 is still pre-release and we're dealing with the beta (4.10.80,
4.10.90) and rc (4.10.95+) sources and ebuilds.  But the framework I've
setup is repo agnostic and would find the ebuilds in whatever repo, main
tree or active overlay, they appear in.

Some background...

For some years now some ebuilds have made use of the epatch_user function
from eutils.eclass or base.eclass.  That function made use of a patches
tree organized by category and package at /etc/portage/patches/,
automatically applying any patches it found in the directory
corresponding to the ebuild being run.  Originally, calling epatch_user
was optional -- the ebuild had to inherit the appropriate eclass and call
the function.  However, with eapi-5, it's now a mandatory part of any
eapi-5 compliant ebuild.

Actually, I believe that idea originated with a guy (I've forgotten his
name and AFAIK he's no longer a gentooer, IIRC his domain expired some
time ago and I deleted the bookmark I had to it) who had a patched
portage with hooks at selected spots in the code, and various optional
utilities using those hooks for all sorts of useful stuff.  It seems
enough gentoo devs found his stuff useful, that portage gradually
integrated many of his hooks and tools, including this one.

Meanwhile, long before eapi-5 came along, I got tired of having to figure
out whether dropping a patch in the /etc/portage/patches tree was going
to work for a particular ebuild or not, and hacked up something using
/etc/portage/bashrc and a couple stub scripts, that ensured that I had
epatch_user available as a function, and ran it using one of the hooks
portage integrated for such extensions, the post_src_prepare function, as
I defined it in /etc/portage/bashrc.  So for some time now, I've been
able to simply drop source patches in the appropriate /etc/portage/
patches/ subdir and have them automatically applied, regardless of
whether the ebuild actually called epatch_user or not.

As anyone who for example tests gcc versions before they're unmasked will
know, a patch tree of this nature comes in really handy for applying
various source patches without having to manually modify the ebuild. =:^)

But, while that works great for source patches, at times one has to
modify ebuilds too, and there isn't yet an offical similar framework for
automatically applying ebuild patches.

I've occasionally been frustrated by this, but until this gentoo/kde
semantic-desktop policy change, particularly with epatch_user eliminating
the need for most of the ebuild edits I used to do, it was just easier to
do the manual hacking any time I needed to change an actual ebuild.

But with the gentoo/kde semantic-desktop policy change, that too changed,
as I was now doing ebuild patching longer term and on a rather wider
scale.  So I needed something like epatch_user, but for the ebuilds
themselves instead of for the sources the ebuilds used.


Meanwhile, some time ago I setup a script that among other things ran
emerge sync and layman -S (in parallel), then ran emerge --regen (with
multiple jobs) to rebuild the cache to take into account layman's
overlays.  Over time, this script expanded a bit to take on additional
tasks, including checking to see if my portage and sources partition was
mounted before running the sync and mounting it if not, updating the
esearch and portage-utils databases, doing an emerge --update --deep
--fetch @world, etc.  The script is called esyn (esync without the
terminating c), and I run it instead of esync to automatically take care
of all the stuff I'd otherwise do one command at a time at the beginning
of an update run.


So when the need for an ebuild-patching variant of the epatch_user
function came up with this gentoo/kde policy change and my subsequent
generation of all these ebuild patches I needed applied, it was rather
natural to simply add another function to my esyn script, that after
the syncs looped thru a tree paralleling /etc/portage/patches (which I
chose to call /etc/portage/patches.ebuild), and upon finding a patch in
that tree, looped thru each of the repos listed in $PORTDIR and
$PORTDIR_OVERLAY (as set in make.conf), matching category and package to
see if there are any matching ebuilds in that repo to patch.

If it finds a matching ebuild, like epatch_user, it first tries applying
the patch in a dry-run.  If the patch applies in the dry-run, then it
applies it for real.  If the patch doesn't apply in the dry-run, then it
could be an ebuild for an old version (in this case, kde 4.10 ebuilds
still have the semantic-desktop USE flag and don't need patched, neither
will the patches apply), or it might be an ebuild that had the patch
applied already (unlike with rsync, unless there's a conflict, git
doesn't overwrite local changes, so the patch stays applied at layman -S
and an attempted re-apply will fail; if there's a conflict, I can git
reset --hard the overlay and redo the overlay sync to pull down the
update, after which, given the conflict with the patch I had previously
applied, I'll likely need to create an updated patch to apply), etc, so
the function simply skips that ebuild and moves on to the next.

At this point it's all rather hacked together, but it works here.  I
expect that over time, as the ebuilds from the gentoo/kde overlay and
eventually in the main tree change, I'll find the patches don't apply and
my updates break, at which point I'll update the patches and/or update
the ebuild patching function as necessary.  Based on past experience, on
my own I'd get something semi-robust for my own setup in a few months to
a year, tho it still wouldn't necessarily work well for others.  Of
course if I were to turn the whole thing into a publicly available
project and take patches or even make it a publicly managed project (much
like kde-sunset), I expect it'd mature much faster and would be become
rather less hacky and rather more general purpose relatively quickly,
such that with the help of others it'd likely be generally usable and
reasonably stable within a couple months, instead of the year or so it'll
likely take me on my own, after which it'll be rather more robust but
still be targeted at only my system, if I don't take it public.

--
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


Reply | Threaded
Open this post in threaded view
|

Re: kde-lean ;)

Duncan-42
In reply to this post by Steven J. Long
Steven J. Long posted on Thu, 11 Jul 2013 13:59:32 +0100 as excerpted:

> <Resend after subscribe>
> Duncan wrote:
>> For kde-4.11, it seems the gentoo/kde project has decided to
>> hard-enable the former semantic-desktop USE flag, forcing the option on
>> and forcing a number of formerly optional additional dependencies.[1]
>>
>> But, I spent quite some time here switching away from kdepim's kmail,
>> akregator, etc, so I could kill akonadi on my system, and with it
>> semantic-desktop, etc, and I'm in no mood to have it hard-enabled now.
>> If it comes to it, I'd rather dump the kde desktop and switch to
>> something else[2], than have semantic-desktop on my system once again.
>
> I *totally* concur. After finally getting rid of KMail, it took me 9
> months to work out and feel comfortable with mutt[1], and then it was
> much less of a step to get rid of nubkit, as well as semantic-craptop.
>
> Finally, at 4.9 my KDE has come back to me, and feels as slick as 3.5
> :-)

It was kde 4.7 for me, but I definitely know the feeling. There's more
that could be said on that theme, but I guess for anyone interested in
this thread, it's preaching to the choir.  Suffice it to say that none of
us greeted that gentoo/kde announcement with rejoicing, to say the least,
but... (vvv)

> That's progress for ya.. ;p

(^^^) ... =:^(

>> Then I created a framework that works much like epatch_user, except
>> instead of automatically applying patches to upstream sources, it
>> automatically applies patches to gentoo ebuilds and instead of using
>> the /etc/portage/patches/ tree, it uses /etc/portage/patches.ebuild/.
>
> Hmm that's quite interesting. Not something I'd personally want in the
> tree, but definitely of interest to more advanced admins, as opposed to
> end-users.

Of course, as I guess you'll recall (you've been around long enough I
think) that's what was originally said about epatch_user as well...

> (Yeah, we're all admins. Still, I don't administer a large network, and
> I don't call myself a sys-admin. I just appreciate good infra.)

I definitely call myself a sysadmin.  It's my stated opinion that if
people were to take the job of administering their own systems as
seriously as a sysadmin does or should do (and I definitely do), then
we'd not have the problem with malware that we do, as there'd always be
insecure systems, but like a well immunized population, the immunity
level of the population as a whole would mean the number of infectible
hosts would be below that required for viable propagation, and the
infections simply wouldn't spread as there wouldn't be enough vulnerable
systems within reach for them to spread to.

Administrating a computer system is a serious job, and the more people
that consider it so, the less danger everyone, both those that treat the
job seriously and those who don't, are in.

So yes, I'm definitely a sysadmin, even if it's only for a couple
systems.  And yes, I take that job seriously, even if I'm not paid for it
because they're my own systems, administered as a hobby.


Meanwhile, before "ebuild_patch_user" gets to the point that it's
acceptable in mainline (if it /ever/ gets to the point that it's
acceptable in mainline), just as epatch_user, time and many rounds of
revision (and an appropriate level of verbosity saying an ebuild was
modified in emerge --info <pkg>, for posting with bugs) will be needed.

>> So now I have a set of ebuild patches that patch the kde 4.11 ebuilds
>> (starting with 4.10.80, aka 4.11-beta1) to force-disable semantic-
>> desktop, instead of force-enabling it.  And I have a scripted framework
>> that auto-applies these patches to new ebuilds on emerge --sync and
>> layman -S, thus keeping no-semantic around as upstream gentoo/kde
>> updates their ebuilds.
>
> Have to say I think I'd prefer this as a semi-automatically generated
> overlay.  ie apply the patches, and if they work, let the maintainer
> confirm after testing.

If the target audience is to include the less experienced, as you're
hinting at, then ultimately I must agree.

>> For now, therefore, I'm fine, up and running on 4.10.90 (aka
>> 4.11-beta2), using gentoo/kde ebuilds auto-patched to kill the now
>> forced-on semantic- desktop, forcing it off instead.
>>
>> But realistically, I honestly don't know if longer term, I'll be able
>> to continue maintenance of all of this by myself.
>
> Indeed. You shouldn't be doing this alone, over the longer-term: it'll
> just burn you out.

So we agree. =:^)

>> Besides which, if I'm finding kde-nosemantic useful enough to go to all
>> this trouble, there's a good chance that others will be interested in
>> it themselves, especially if they don't have to do all the work I'm now
>> doing myself, themselves.  So with kde-sunset in mind as precedent, I'm
>> now proposing a kde-nosemantic overlay, like kde-sunset,
>> user-maintained, but for kde4 folks who want a continued no-semantic
>> choice, instead of kde3 users.
>>
>> Any interest?
>
> Hell yeah :-)[2] You picked an odd forum for it though: I only found out
> about this because Dominique posted to pro-audio list.

I picked this list/forum for a couple (related) reasons, in addition to
convenience (I was already subscribed).

1) It's the coordinating list for kde-sunset, and this seemed a
reasonably similar project, so using the same list seemed appropriate.

2) This list is also where the gentoo/kde project posts meeting
announcements and sometimes summaries, etc.

Together those make this list more or less the all-things-kde list (not
excluding the more general desktop bit, but particularly for those
interested in kde...), and it seemed to me to make this the logical place
to post, certainly for an initial feeler.

>> To be further discussed:  Assuming a go-ahead on the general idea, do
>> we want to maintain it as a normal overlay carrying at least the kde4
>> ebuilds that require patching to kill semantic-desktop
>
> Yes, as above. I much prefer the traceability of an overlay with
> conventional ebuilds in it. If we're going to do this, let's do it
> right.

OK, barring any strong feeling posted to the contrary... WORKSFORME. =:^)

> Yes, the tools should be available in their own right.
>
> Tho that was an awfully long-winded way of saying "Ebuild-patch tools
> could well be of wider interest." ;)

I blame all those "minimum 2 pages" (replacing 2 with a larger number as
I advanced) assignments in school, when two paragraphs totaling half a
page would have well sufficed.  All those years of schooling forcing
rediculous verbosity... and I hit "real life" and everybody's saying
tl;dr!  Talk about schools teaching the wrong thing!

>> A hybrid alternative would be to adopt an idea much like the existing
>> kde overlay, where there's a documentation or tools directory that
>> carries them, in addition to the kde-base category and etc, carrying
>> the patched ebuilds themselves.
>
> That sounds ideal, but why not just have two overlays? One for
> ebuild-patch which others can use and collaborate around, and one
> conventional kde-lean for people who want the end-product.

kde-lean definitely beats kde-nosemantic, my working title.

As for ebuild-patch, an overlay just for it?  What about setting up a git
repo somewhere (github's popular, but not open source...) and putting the
ebuild for it, presumably using git2.eclass for a live-9999 version, in
the sunrise overlay?  Once it gets mature enough to tag, if we don't want
to bother with a tarball, a versioned ebuild can still use the git
infrastructure, and simply checkout a specific tag.

> After all, ebuild-patch tools are strictly for maintainers, and people
> who want to experiment on their system. The output ebuilds have an
> orthogonal use.

Agreed.

> I'd ask that we collaborate on the forums[2] about this: things can move
> much quicker there, and you get general encouragement and lots of bug
> feedback, as well as others to help.

I've actually seen lists/newsgroups move in very close to real-time -- as
close as I generally care to get (I don't do IRC as I like a bit more
time to compose my posts).

But, web-forums do seem to be more popular, and I guess I could dust off
my old forum login or create a new one...

> creaker patched kdelibs, as you'll see, already, and he's interested in
> working on the overlay ("Without overlay it may be boring to do the
> things I did before on every update.") So between the two of you, and as
> others get involved, I'm sure it can be done. As you said, KDE-4 is
> practically EOL, given that more developer focus is on 5.
>
> I can get the overlays, git and trac setup, same as we did for hardened
> a few years ago, if that helps.

That would be useful.

Person to person, let me also say I'm absolutely thrilled to have you
helping.  I didn't know you were a kde-er so thought it a bit much to
hope for, but I definitely consider your bash skills well above mine
(you're the name that comes to mind when the words "bash coder" get
used), and have little doubt that you'll be able to beat my poor hacks
that work on my system but that I wouldn't consider secure or robust
enough for general purpose use into much better general-purpose shape,
far faster/better than I could.

And I expect quite apart from improving the tools themselves, I'll learn
quite a lot from the process, and my next project will be rather higher
(dare I say professional?) quality early code as a result.  I certainly
can't argue with that! =:^)

Of course there's other than shell/bash, but that's the scripting I'm
most familiar with.  I tried perl but that didn't go so well.  I have on
my list to learn python some day, but it's been on my list for awhile,
and bash can do way more than a lot of people give it credit for, even if
it's not the most efficient choice for the job otherwise.

> [2] How to opt out of a semantic-desktop?
>     http://forums.gentoo.org/viewtopic-t-963504.html

I guess you're more of a forums user than I.  If we do the forums, new
topic in desktop environment, or unsupported software, or ...?  Or
continue with the topic above?

And do we combine the kde and tools subjects in a single topic or one for
each?

What else?

Back to the list vs forums thing:

FWIW, I prefer lists as I actually prefer newsgroups, and read my lists
via gmane as newsgroups.  However, I guess one goes where the audience
is, and as I said earlier, web-forums do seem to be more popular, so...  
But OTOH, this list is already used for kde-sunset and by the gentoo/kde
project, so an argument could be made for that too, and people that want
to talk about kde-lean bad enough will I guess subscribe...  How strong
are your forum prefs and do you have any further thoughts/reasons why
switching to the forums would be better?

It's just that... I've been a regular on some lists and/or newsgroups for
a decade or more (I've been a regular on the pan lists since 2002,
according to gmane, and I've been on some newsgroup or another since I
discovered them back in 1997 or so, back on MS with the IE4 previews),
but despite the best of intentions, I've never been able to handle a
forum for more than a couple months before I burn out on it, so quite
apart from the personal preference thing, a real-life consideration is
that my own longevity as a project contributor before burnout may well be
conditional on what form the project communications take, list or forum,
with the latter very possibly leading to much faster burnout.

Meanwhile, on another aspect of longevity, I expect I'll be making the
switch to kde5/frameworks with their more modular design (which I'm
SERIOUSLY hoping means keeping semantic-desktop optional, if not, I'll
almost certainly switch to something else rather quickly after I find
that out, but I'm optimistic given what I've read about it so far)
relatively quickly, as I tend to be somewhat ahead of the pack when it
comes to migrations, etc.

(With kde4 I was a bit slower than usual, as it simply wasn't working for
me, but I did try it before 4.0, dropping it for a time when it became
obvious that wouldn't be working for me at release, and periodically
after that, until 4.2 or so, when I force-switched to kde-4.2.5 despite
its brokenness after finding out that 3.x was no longer supported
upstream despite previous promises, and that as a result, gentoo/kde was
going to be dropping kde3 as well, even tho it took them several months
longer to actually drop it.)

And I'm hoping to switch to wayland about the same time as kde5/
frameworks, with the X-wayland client providing legacy X support where
necessary, tho all that's rather iffy and vague at this point.

But all that means my personal interest in kde4-lean may be rather short-
lived... perhaps to the end of year or early next, tho with kdelibs4 and
kde-workspace4 feature-frozen, kde4 itself is planned to continue getting
further updates until say mid-year 2014 (or later if they get behind on
kde5/frameworks), which means it'll probably remain available in gentoo
until end of 2014 or so, at least.

However, with interest and help from others, it's quite possible my
initial patches and tool code can help jumpstart things, and the project
will be able to continue without me by then.

What do you (and anyone else who cares to jump in) think?  Is it
reasonable to expect the project to be sustainable without me once I
decide to move on to kde5/frameworks, or are my active contributions and
patching likely to continue to be necessary, such that it may not be
worth even starting the (public) project (other than perhaps simply
throwing it over the wall and letting people use it as-is while they can)
if I'm not willing to commit to saying with it longer than that?

As I said, you're more experienced in the forums than I.  There's
certainly some interest there.  But is it likely enough to build
something that I can reasonably expect to be sustainable without me in a
reasonable time, or is it likely that I (and possibly you) will be doing
nearly everything myself/ourselves, and once I move on, the whole thing
will dry up and blow away?  And if it does dry up and blow away when I
leave, will it have been worth the trouble for the time it will have been
available (hey, it gave people six months they'd have not had otherwise
and that's something!), or not?

I guess it's likely that (given your help anyway) at least the ebuild-
patching framework will continue on as a viable tool, quite independent
of the kde-lean project where it originated.  That's something.

Of course the other possibility is that kde5/frameworks will continue an
optional semantic-desktop, but that contrary to gentoo norms and values,
the gentoo/kde project will fail to support that option there as it's now
doing with 4.11, in which case kde-lean in some form may continue to be
viable into kde5/frameworks...  But that's a possibility that remains to
be seen, and if it /does/ happen, I'm sure I'll need even more help
longer term to keep the kde-lean option viable.

Finally, it's worth confirming one thing brought up on the forum thread.  
I don't see any realistic possibility of doing anything further with
kdepim in a no-semantic kde.  That's an upstream hard-dependency and I
don't see anyw way around it, making kdepim totally non-viable for our
purposes.  Agreed?  Given that, I believe it best not to carry kdepim in
the kde-lean overlay at all, and to recommend that people use something
else.  Claws-mail seems the most direct low-dep but still GUI replacement
for both kmail and (with the feed plugin) akregator, but of course people
can choose thunderbird or something else if they prefer.  Meanwhile, we
can recommend that those that want to keep kmail or other kdepim
components use the semantic-desktop enabled mainline gentoo/kde,
instead.  Thus they can choose kdepim and semantic-desktop with mainline
gentoo/kde, or kde-lean and alternatives to kdepim packages, their choice.

And one more thing:  Short term, is it worth it to post the 4.10.80+
patches as I have them either here or to the forum thread linked above,
or is it better to wait until we have an overlay to put them in and/or
until 4.11.0 is available?  Because I see creaker posted his modified
kdelibs ebuild, but I think that was still kde 4.10.4.  My patches are
tested not to pull in the deps here at all (unlike his kdelibs-only
ebuild), but they're for 4.10.80+, where the semantic-desktop USE flag is
already gone, and thus won't apply cleanly to earlier versions that still
have it.  Also, while complete for the packages I have installed, I don't
have a full kde installed (obviously not kdepim, but beyond that too), so
further patches will likely be needed for other packages.

--
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


Reply | Threaded
Open this post in threaded view
|

Re: kde-lean ;)

creaker
This post has NOT been accepted by the mailing list yet.
Hi there!
Duncan-42 wrote
Because I see creaker posted his modified
kdelibs ebuild, but I think that was still kde 4.10.4.  My patches are
tested not to pull in the deps here at all (unlike his kdelibs-only
ebuild)
I didn't try to patch ebuilds, the things that I did can not be called a true patch. I was just very angry and I decided to break their (kde/gentoo devs) work (at least in my local portage tree) and prevent pulling me into their semantic herd.    
And I made ​​sure that KDE could be built without semantic USE flag. Removing nepomuk family was a second part.
I did not see 4.11 ebuilds, so I have no idea would it be as easy for 4.11 as it was for 4.10.4.

I did not see any person who would say that semantic desktop is a great thing (except kde/gentoo devs), so I think your work will be of interest to many gentoo users.
Reply | Threaded
Open this post in threaded view
|

Re: kde-lean TL;DR unless you're going to use it ;)

Steven J. Long
In reply to this post by Duncan-42
Duncan wrote:

> Steven J. Long posted
> > Duncan wrote:
> >> Then I created a framework that works much like epatch_user, except
> >> instead of automatically applying patches to upstream sources, it
> >> automatically applies patches to gentoo ebuilds and instead of using
> >> the /etc/portage/patches/ tree, it uses /etc/portage/patches.ebuild/.
> >
> > Hmm that's quite interesting. Not something I'd personally want in the
> > tree, but definitely of interest to more advanced admins, as opposed to
> > end-users.
>
> Of course, as I guess you'll recall (you've been around long enough I
> think) that's what was originally said about epatch_user as well...

Perhaps, but there's a qualitative difference, in distro terms, between
patching the upstream source, and changing what the distro recommends.
Sure, both leave you to pick up the pieces (as if anything else ever happens;)
but patching the ebuilds is the same as using an ebuild from overlay: get
your support from whoever provided it, not the distro.

> Administrating a computer system is a serious job, and the more people
> that consider it so, the less danger everyone, both those that treat the
> job seriously and those who don't, are in.

Like all things were "it would be better if only everyone did X" everyone
does NOT do X by definition, or we wouldn't have anything to discuss.

I don't personally feel the user should have to do anything to have a
reasonably secure machine, and I'd counter that the real problem is that most
people are using an inherently secure system (apparently by design if recent
news is accurate.) IOW we have bigger problems than what Linux users do.

But overall, we agree on approach: the user is in charge, and thus its their
responsibility. Given that we're all human, and further that I don't really
have the inclination to administer a large network and deal with end-users on
a daily basis, I still won't call myself an admin ;-) and will continue to
hero-worship the good ones, since I can't really get much done without them,
if it's outside my front-door.

> an appropriate level of verbosity saying an ebuild was modified in emerge
> --info <pkg>, for posting with bugs) will be needed.

Definitely. A terse line should be in every emerge --info, near the top.

> > Hell yeah :-)[2] You picked an odd forum for it though: I only found out
> > about this because Dominique posted to pro-audio list.
>
> I picked this list/forum for a couple (related) reasons, in addition to
> convenience (I was already subscribed).
>
> 1) It's the coordinating list for kde-sunset, and this seemed a
> reasonably similar project, so using the same list seemed appropriate.

Ah wasn't aware of that. It seemed odd to me, since the gentoo-kde team
clearly thinks the approach is a waste of time, so why expect a positive
response on their ML.

> >> A hybrid alternative would be to adopt an idea much like the existing
> >> kde overlay, where there's a documentation or tools directory that
> >> carries them, in addition to the kde-base category and etc, carrying
> >> the patched ebuilds themselves.
> >
> > That sounds ideal, but why not just have two overlays? One for
> > ebuild-patch which others can use and collaborate around, and one
> > conventional kde-lean for people who want the end-product.
>
> kde-lean definitely beats kde-nosemantic, my working title.
>
> As for ebuild-patch, an overlay just for it?  What about setting up a git
> repo somewhere (github's popular, but not open source...) and putting the
> ebuild for it, presumably using git2.eclass for a live-9999 version, in
> the sunrise overlay?  Once it gets mature enough to tag, if we don't want
> to bother with a tarball, a versioned ebuild can still use the git
> infrastructure, and simply checkout a specific tag.

Yeah a repo for it works fine, for me. People can just use a live vcs ebuild
to stay current; after all it's an experimental setup, so if you use it blindly
you're an idiot. The user must be aware that they need to review the patches
they apply to ebuilds on every bump, so being aware of the need to keep an eye
on epatch-user itself isn't that much of a hardship.

However we should still make it so that an upgrade doesn't actually change
existing patches. That pushes us in the direction of the patch, review and later
use of an ebuild, rather than a live patch during an emerge itself, which fits
with the separate overlay model.

(Yes, I'm aware you can't patch an ebuild during an emerge, because metadata has
to be constant.) I just mean the overall design is one of patching as one process,
and use as a later, independent phase that does not have any awareness of the
fact that the ebuild has been patched (apart from the metadata tag for QA.)

If that's required, I'd actually argue against it, even where it's similar to the
check of version being 99999*, as conceptually it feels broken: the whole point
is to patch the ebuild for a specific situation, and only to distribute as
equivalent ebuilds in an overlay. If you've patched it right, there should be
no need for anything like that.

It's never going to need to get a different set of sources according to whether
it's been patched or not, for example; the kind of thing we'd check version for
in a live ebuild that can be used for fixed sources. By definition it's always
patched.

That makes the ebuilds produced candidates for use elsewhere, should they be
wanted. Not for our stuff ofc, but for other users like overlays, where submission
of patched ebuilds to Gentoo might be a future possibility.

> > I'd ask that we collaborate on the forums[2] about this: things can move
> > much quicker there, and you get general encouragement and lots of bug
> > feedback, as well as others to help.
>
> I've actually seen lists/newsgroups move in very close to real-time -- as
> close as I generally care to get (I don't do IRC as I like a bit more
> time to compose my posts).

Lists can move in near to realtime yes, but they seldom move usefully when they're
moving that quickly, ime. Part of the problem is that all subscribers get a copy
of the email delivered to them, whereas forum posters have chosen to read your
post. Reading lists via gmane shields you from that, but it's important to remember
that many others get your posts in their mailboxes.

So if forum-users reply, it's because they're interested in the topic, and you
never get people who are just posting because they're irritated at what to them is
noise, since they're not actually interested in your new thing. If that were the
case they wouldn't even have opened the thread, let alone got to the end.

> But, web-forums do seem to be more popular, and I guess I could dust off
> my old forum login or create a new one...

Yay! :-)
 
> > I can get the overlays, git and trac setup, same as we did for hardened
> > a few years ago, if that helps.
>
> That would be useful.

Okey-dokey: I'll mail you off-list in the next day or two, after I've got the git
repo setup, as we'll need to also setup an ssh login for you, to commit.
 
> Person to person, let me also say I'm absolutely thrilled to have you
> helping.

Thanks man :) Your words gave me a real boost. I'm delighted to be collaborating
with you too: I always regretted that I couldn't persuade you to use update[1] ;)

> Of course there's other than shell/bash, but that's the scripting I'm
> most familiar with.  I tried perl but that didn't go so well.  I have on
> my list to learn python some day, but it's been on my list for awhile,
> and bash can do way more than a lot of people give it credit for, even if
> it's not the most efficient choice for the job otherwise.

Exactly. I was amazed at how far we could push bash, when I only had a 32-bit
machine. In the end, I gave up worrying about it, though slightly regretfully:
for some perverse reason I wanted it to fall over on me with such a large script.
As for performance, it's pretty sh1t-hot imo: the plan was to rewrite large chunks
in awk once we'd got the basics running, but it was never needed.

All in all, I'd say people who think bash is slow are using it wrong. Sure it's not
as fast as bb for basic sh. But if you want to write a moderately complex application
you'll tear your hair out with sh, in places where bash has constructs designed by
people who've been scripting for decades, to fix the exact *coding* limitation you've
come up against. Granted a lot came from ksh, and bash takes ideas from other shells
like zsh. Personally I like that ;)

Shell-scripts are slow, because people call externals when they don't know better,
typically on a crap OS that can't handle fork very easily, whereas it's trival on Unix.
Then they walk away declaiming how the language is useless. Unfortunately since it was
designed for use by any user, that means any idiot can knock something together and
think they know it well, though their script would earn them a day of lessons (or a
roasting if they think they're it) in #bash.

> > [2] How to opt out of a semantic-desktop?
> >     http://forums.gentoo.org/viewtopic-t-963504.html
>
> I guess you're more of a forums user than I.  If we do the forums, new
> topic in desktop environment, or unsupported software, or ...?  Or
> continue with the topic above?

Continue with the topic. If it needs to be moved the moderators will do it, when
they feel the time is right.
 
> And do we combine the kde and tools subjects in a single topic or one for
> each?

Let's just start with that thread, and make the tools work for our use-case,
while keeping them in a git repo others can use and collaborate around. We have
a reasonably simple aim for the tools, and we're both committed to making them
useful for more than the one project, so I'm reasonably happy we're not going
to make them unportable, or completely specific to kde.
 
> How strong are your forum prefs and do you have any further thoughts/reasons
> why switching to the forums would be better?

Just what I said above, about the forum users self-selecting that they care
about the thread, as opposed to spamming everyone's mailbox with it. Moderation is
useful too, when done as well as the Gentoo Forums are moderated. Though I prefer
IRC for people I actually have to collaborate with directly: it's more like email
than people imagine, so effectively works as async/offline, but it can be as quick
as real-life when needed. Plus it's all about your attitude and your knowledge,
not about what badge you have attached to your address. (In fact, flaunting +o is
actively discouraged.)

I won't do development on a mailing list, personally. Discussion around proposals
and ideas, to elicit feedback from the wider community before moving forward is
a great idea, and personally I think that's why Gentoo has done well. AIUI
when drobbins set it up he'd been burnt by the descent into clique that is a
peril for any FLOSS project, and so the dev ML has always had that as an explicit
purpose. Not that that stops it getting cliquey, it just means the current clique
(and they're nebulous things;) can never take over and destroy the distro. At
least, not without a clear record that users hated what was happening, before they
all left.

I quite like lists about patch submissions, though. When we used to get
gentoo-commits follow-ups on-list, it was actually interesting, since people
were talking about the code we actually want from them (ie ebuilds) and not
their latest dream of an idiot-box, or why portage sucks and can we have your
ebuilds.

The pro-audio overlay list is quite interesting for the same reason, though the
discussion is a lot sparser nowadays, and it's mostly just the bot. I like to
think that's because most of the problems are well-understood, and people
are just concentrating on the ebuilds. I have a vague feeling that probably
means we're due for a big round of "innovation" to make things more 'interesting'
or 'time-wasting' depending on your view. ;)

> It's just that... I've been a regular on some lists and/or newsgroups for
> a decade or more (I've been a regular on the pan lists since 2002,
> according to gmane, and I've been on some newsgroup or another since I
> discovered them back in 1997 or so, back on MS with the IE4 previews),
> but despite the best of intentions, I've never been able to handle a
> forum for more than a couple months before I burn out on it, so quite
> apart from the personal preference thing, a real-life consideration is
> that my own longevity as a project contributor before burnout may well be
> conditional on what form the project communications take, list or forum,
> with the latter very possibly leading to much faster burnout.

I think you should just deal with the issue, which is that you burnout on
forums, likely because you get too involved, and post at such length you
don't have time left over for yourself.

Don't do that. Learn to let go. Why does it matter if "someone on the internet
is wrong"? ;)

But still I'm glad you raised it, since it means I can keep an eye on it too,
and email you if I think you're burning out (or posting too much and not fixing
stuff instead;)

I think though, that the reason you burnout on forums is actually because they
move quicker than mailing lists, and people who are posting are usually as
caught up in the topic as you are: without moderators you basically don't have
any externals, unlike a ML, or IRC (where people are happy to tell you it's got
boring, and no one takes offense. Well, no-one you can't /ignore. ;)

> kde4 itself is planned to continue getting further updates until say mid-year
> 2014 (or later if they get behind on kde5/frameworks), which means it'll
> probably remain available in gentoo  until end of 2014 or so, at least.

Good to know, thanks.

> However, with interest and help from others, it's quite possible my
> initial patches and tool code can help jumpstart things, and the project
> will be able to continue without me by then.
>
> What do you (and anyone else who cares to jump in) think?  Is it
> reasonable to expect the project to be sustainable without me once I
> decide to move on to kde5/frameworks

Yup. Or we're doing it wrong, which we'll find out within the first two months.

> As I said, you're more experienced in the forums than I.  There's
> certainly some interest there.  But is it likely enough to build
> something that I can reasonably expect to be sustainable without me in a
> reasonable time, or is it likely that I (and possibly you) will be doing
> nearly everything myself/ourselves, and once I move on, the whole thing
> will dry up and blow away?

It's always a possibility. I don't think it's very likely for two reasons:
Firstly, I'm a lazy sh1t when it comes to anything that's not code, and a lot
of this won't be about coding, so it's very unlikely I'll be doing all the work ;)
Secondly, I have a lot more faith in Gentoo users when it comes to scratching
the itch to make stuff work. They've basically "self-selected" again when it comes
to that. And they have a very wide range of computing experience. AFAIC they're
basically _the_ elite userbase.

IME you just have to give them the support and encouragement to try stuff, and wait
to see who contributes the most. And what's good about it, is that even people who
think they can't contribute, do so, just by encouraging you, or giving you feedback.
There's been times when I would have given up on update, since it's just me now,
only for someone to post out of the blue and thank me. I cannot tell you the boost
that gives you, since it validates all the effort you've put in.

Again, because it's a self-selected group even when it comes to reading the thread,
the only people involved care about making it work. I was really surprised at how
nice people are on the forums, especially when compared to the mailing-list. Now I
take it as a given that anyone posting is coming from a positive space.

I wish I could say the same about the lists.

>  And if it does dry up and blow away when I
> leave, will it have been worth the trouble for the time it will have been
> available (hey, it gave people six months they'd have not had otherwise
> and that's something!), or not?

That's your call to make. All I'd say is: don't think of it as all-consuming,
and don't let your head go there when you are posting on the forums. You have
to remind yourself from time to time, that you're doing it because you want to,
and no-one's paying you a dime, so you don't owe anyone a thing. You care about it,
so it's easy to forget: it's low-priority. Period.
 
The only exception is when you've pushed a buggy version. Then you better fix it
quick (and not with a forced rebase), or expect a bollocking (as I've learnt, and
so shall I teach, since it cuts through the haze.[2] ;-)

> Finally, it's worth confirming one thing brought up on the forum thread.  
> I don't see any realistic possibility of doing anything further with
> kdepim in a no-semantic kde.  That's an upstream hard-dependency and I
> don't see anyw way around it, making kdepim totally non-viable for our
> purposes.  Agreed?  Given that, I believe it best not to carry kdepim in
> the kde-lean overlay at all, and to recommend that people use something
> else.

Agreed. I never thought I'd stop using KMail, but there it is.

> And one more thing:  Short term, is it worth it to post the 4.10.80+
> patches as I have them either here or to the forum thread linked above,
> or is it better to wait until we have an overlay to put them in and/or
> until 4.11.0 is available?

Do please post them to the forum thread, in a [code]block[/code] if the diff is
reasonably small; you can Preview any post to check how it'll look, or Edit it
(top-right of the post) after you've submitted it. If you do that before anyone
replies, it doesn't show up as an edit (Last edited..; edited X times in total.)
But in general preview everything with tags in it.

Or at a reasonably light pastebin with a [url=http://..]link text[/url] I use
http://sprunge.us/ generally, but IDK if that's at all permanent. I doubt it ;)
http://paste.debian.net/ is used by quite a few people, and checking it I see it
allows "permanent" posts.

Just not pastebin.com please. It used to have an awful lot more ads, but it's
still heavy, and it also used to insert CR/LF. I don't know if it still does;
I refuse to use it, and only occasionally follow a link to it on IRC if it's
something I'm really interested in reading. If someone's asking me for help,
they won't get it with a pastebin.com link, unless they're cool and use another
pastebin when asked.

> kdelibs ebuild was still kde 4.10.4.  My patches are tested not to pull in
> the deps here at all but they're for 4.10.80+, where the semantic-desktop USE
> flag is already gone, and thus won't apply cleanly to earlier versions that still
> have it.

Good, we need them in those versions, and we need to start thinking of the whole set
so collaboration early is better, as ever. I'd better get my update --toolchain patch
set finished so I can upgrade my system (Forgive me Gentoo for I have sinned: it's been
3 months since my last completed emerge world..;) and see what's happening in the
latest stable versions.

Thank god for FEATURES=binpkg[3] though: I can roll back if 4.10/11 turns out to be a
stinker. The way I feel about 4.9, is kinda how I felt about 3.5, so it's all good.
There's some nice stuff in kate for 4.11 I want to try though.

>  Also, while complete for the packages I have installed, I don't
> have a full kde installed (obviously not kdepim, but beyond that too), so
> further patches will likely be needed for other packages.

Yeah. Please post the patches to forums, so we can get cracking.

Regards,
steveL.

[1] http://forums.gentoo.org/viewtopic-t-546828.html
[2] http://www.paulgraham.com/head.html
 -- very useful to explain ourselves to non-coders, if you've not read it.
"I don't hate you, I just can't stand it when you talk to me.." ;)
[3] http://forums.gentoo.org/viewtopic-p-7165614.html#7165614
 -- I know you're using it, but others might not be yet.
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Reply | Threaded
Open this post in threaded view
|

Re: Interest inquery: kde4-nosemantic overlay

Steven J. Long
In reply to this post by Duncan-42
Duncan wrote:
> Martin Vaeth posted:
> > Does your framework manage the ebuilds in some overlay, or is it
> > actually running tranparently during emerge (probably with a patched
> > version of portage), allowing e.g. to change metadata without
> > maintaining the ebuild in a separate local overlay?
> > (I guess that it is the former, but your choice of the path
> > /etc/portage/... suggests the latter)
 
> the framework I've setup is repo agnostic and would find the ebuilds in
> whatever repo, main tree or active overlay, they appear in.

> I've occasionally been frustrated by this, but until this gentoo/kde
> semantic-desktop policy change, particularly with epatch_user eliminating
> the need for most of the ebuild edits I used to do, it was just easier to
> do the manual hacking any time I needed to change an actual ebuild.

Hmm why was a local overlay inappropriate? I thought you could mask packages
from specific overlays (or am i wrong about that?)

Not that it matters, in that I'm glad you've gone down this path. I'd just
like to know.

From what you've written, the first thing that springs to mind is
/etc/portage/postsync.d/ which has q-reinitialize in it. I have that activated,
and run eix-sync after emerge --sync in update, which takes care of overlays.
Which answers why postsync isn't sufficient in and of itself. Hmm I guess that
means that means qgrep et al aren't complete, which I've never noticed as I don't
use overlays.

Additionally, like Martin, I assumed you were doing this in a local overlay, not
on the tree itself, with resultant rsync wipeout. So if we can sort that out, by
writing the output to:
 "${local_overlay:=/usr/local/portage}/${ebuild#"$PORTDIR"}"
I'd be a lot happier. It'll fit much better in the process of pushing to an
external overlay as well.

The other thing I was going to mention is that update -s wraps the whole process,
to filter the rsync output so it's only one line (the performance thing I mentioned
in the other post: I never expected that to work so well but my mentor does the awk
so I just tried in bash, and was amazed. :) So we could:
a) get the list of ebuilds that have actually been changed via rsync, or
b) check what eix is reporting after (if the user has eix.)

However a postsync action similar to q would be the best; it just has to run after
the overlays have been sync'ed. As I said I don't use overlays, so it's up to you
and people like Martin to work the details of 'what and when' out. I'll help with
the 'how'. I'd just prefer something that doesn't require a wrapper, but works with
any emerge setup.

Alternatively, if we can get eix to do it directly, it'd rock afaic. Though a
developer I know refuses to use it, as he says it takes too long if you've got
a cvs tree, or sth. Unfortunately, like you, mv doesn't do IRC, so I've not been
able to get the two together for a chat to see if anything could be sorted, or
whether it's intractable.

Personally, I'm fine with a dep on eix fwiw.

I'm reasonably sure you can hook whatever you like into eix-sync, as I recall
telling people to just use it quite a lot back in the day (we do have postSync
actions as well, one for -q quiet usage, if defined) but mv can tell us more, if
eix can help. It seems the right spot, since eix-sync can run after emerge --sync
and do all the overlays, so people are used to running it. iirc again you can use
a postsync.d action, so it would be ideal.

We just don't with update as we want the rsync filtering, and have to work when
the user doesn't have eix, so it's always been separate. Having said that, if the
user has eix running in postsync, that'll work too.

That's the trouble with glue-scripting: you have to consider the interaction of
quite a few disparate commands, and various end-user setups.

It's also what makes it useful, and fun to work on. :-)

--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Reply | Threaded
Open this post in threaded view
|

Re: Interest inquery: kde4-nosemantic overlay

Martin Vaeth
Steven J. Long <[hidden email]> wrote:
>
> From what you've written, the first thing that springs to mind is
> /etc/portage/postsync.d/ which has q-reinitialize in it. I have that
> activated, and run eix-sync after emerge --sync in update, which takes
> care of overlays.
> Which answers why postsync isn't sufficient in and of itself.

I don't understand why postsync.d is not sufficient and why you run
eix-sync *after* emerge --sync (it should be run *instead of*).
eix-sync alone normally uses this order (only relevant tasks listed):

1. layman ...
2. emerge --sync [ hence, followed by postsync.d hooks ]
3. @-hooks from /etc/eix-sync.conf
4. eix-update
5. eix-diff

so if you use postsync.d to update a local overlay according to changes in
the tree (or of a layman overlay) this update should be visible in eix.
If you do not use eix, postsync.d should do as well...

If you want to avoid postsync.d (though I still do not understand why)
and use eix directly you can use the @-hooks:
Put e.g. into /etc/eix-sync.conf the lines

@StatusInfo Updating local overlay
@/path/to/command_to_update_local_overlay


12