[gentoo-desktop] Interest inquery: kde4-nosemantic overlay

[gentoo-desktop] Interest inquery: kde4-nosemantic overlay

[Duncan]

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

Re: [gentoo-desktop] Interest inquery: kde4-nosemantic overlay

[Ian Whyman]

[-- Attachment #1: Type: text/plain, Size: 7154 bytes --]

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" <1i5t5.duncan@cox.net> 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
>
>
>

[-- Attachment #2: Type: text/html, Size: 8082 bytes --]

[gentoo-desktop] Re: Interest inquery: kde4-nosemantic overlay

[Duncan]

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

Re: [gentoo-desktop] Interest inquery: kde4-nosemantic overlay

[Alex Alexander]

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

[gentoo-desktop] Re: Interest inquery: kde4-nosemantic overlay

[Duncan]

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

[gentoo-desktop] Re: Interest inquery: kde4-nosemantic overlay

[Michael Palimaka]

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

[gentoo-desktop] Re: Interest inquery: kde4-nosemantic overlay

[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.

-- 
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

Re: [gentoo-desktop] Re: Interest inquery: kde4-nosemantic overlay

[Johannes Huber]

[-- Attachment #1: Type: text/plain, Size: 2674 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

[gentoo-desktop] Re: Interest inquery: kde4-nosemantic overlay

[Duncan]

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

Re: [gentoo-desktop] Interest inquery: kde4-nosemantic overlay

[Dominique Michel]

Le Wed, 3 Jul 2013 17:32:25 +0000 (UTC),
Duncan <1i5t5.duncan@cox.net> 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."

[gentoo-desktop] Re: Interest inquery: kde4-nosemantic overlay

[Duncan]

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

Re: [gentoo-desktop] Re: Interest inquery: kde4-nosemantic overlay

[Dominique Michel]

Le Sun, 7 Jul 2013 21:41:36 +0000 (UTC),
Duncan <1i5t5.duncan@cox.net> 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."

[gentoo-desktop] Re: Interest inquery: kde4-nosemantic overlay

[Martin Vaeth]

Duncan <1i5t5.duncan@cox.net> 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)

[gentoo-desktop] kde-lean ;)

[Steven J. Long]

<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 ;-)

[gentoo-desktop] Re: Interest inquery: kde4-nosemantic overlay

[Duncan]

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

[gentoo-desktop] Re: kde-lean ;)

[Duncan]

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

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

[Steven J. Long]

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 ;-)

[gentoo-desktop] Re: Interest inquery: kde4-nosemantic overlay

[Steven J. Long]

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 ;-)

[gentoo-desktop] Re: Interest inquery: kde4-nosemantic overlay

[Martin Vaeth]

Steven J. Long <slong@rathaus.eclipse.co.uk> 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

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

[Duncan]

Steven J. Long posted on Tue, 16 Jul 2013 02:01:40 +0100 as excerpted:

> 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.

Of course public overlays were supposed to be the doom of gentoo too. 
Maybe they were and we're all oblivious...

Meanwhile, it's my "weekend" now (three day but with a meeting tomorrow), 
so I've a couple days to spend on this and other personal projects.  My 
goal is to be posting in the forum by the end of it, preferably with the 
first code posted.  We'll see.

Something that's been bothering me a bit.  So far, this "framework" is 
pretty much just a function in my sync script that applies my patches 
after a pull.  It's pretty simple, not even that much code or time, 
actually.  So it'll need adapted for a wider audience, but I /do/ hope to 
get at least the initial function posted to the forum before this 
"weekend" is over.

> 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.

Don't worry, the patches themselves are still manually created by /
someone/, they're simply applied immediately after the sync (before a 
cache regen since they affect deps), and if they no longer apply for 
whatever reason, it's not fatal, so the result will simply be that ebuild 
returns to upstream gentoo/kde default and wants to pull in the semantic-
desktop junk again, until someone comes up with an updated patch.

And I've had the first round of patch updates now.  So I know the fail 
mode and what's involved in updating the patches, now.  I was still 
running on original patches until then, so failure mode was just theory, 
until now.  Always good to have it tested. =:^)

(I've a couple tweaks to make the next couple days too, before posting 
it, based on that testing.)

> 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.)

You'll be happy to know that's the way it works. =:^)  I hadn't even 
consciously considered the other way until you mentioned it, I think 
because I too was so horrified by the possibility, that I rejected it out 
of hand and considered the separate phases the only realistic approach 
from the get-go.

> 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.

Very good point. Agreed.

> So if forum-users reply, it's because they're interested in the topic,

My ideal would be newsgroups, which is what lists end up being, thru 
gmane, for me.  But I guess the newsgroups-for-the-common-man ship sailed 
a long time ago...  Thanks for your insights on web forum dynamics.  They 
make sense and should be useful. =:^)

>>> I can get the overlays, git and trac setup
>> 
>> That would be useful.
> 
> Okey-dokey: I'll mail you off-list in the next day or two

Cool. =:^)

> I always regretted that I couldn't persuade you to use update[1] ;)

The timing was wrong.  By the time I heard of it, I already had my own 
system setup.  Which I'd always thought about packaging and making 
publicly available, but never got the properly rounded tuit. =:^\

But my system parallels emerge much more closely, being in effect little 
more than a bunch of emerge aliases, most of them starting ea (emerge --
ask) or ep (--pretend), with various other letter combinations added that 
parallel the similar emerge options (eaw= emerge --ask @world... with
--update --deep --newuse --oneshot implied, etc).

The parallels make it very easy to transfer emerge option knowledge to my 
system, and the reverse as well.

slashdot style mandatory car analogy:  Update is like power steering for 
emerge; emerge by itself is manual steering; my system's manual steering 
but with a custom steering ratio and wheel and with one of those tilt-
wheel things that lets you set the angle of the steering wheel. =:^)

In contrast, my "esyn" (no c) already had a bunch of pre/post/parallel-to-
sync functions doing everything from mounting the appropriate partition 
if necessary, to layman-syncing along with emerge sync, to regenerating 
caches and auto-fetching sources for the emerge @world to follow.  So 
throwing in another function to auto-ebuild-patch was no big deal.

Which means it's probably a good thing I didn't end up running update, or 
I'd have likely never had the inspiration that lead to this thread in the 
first place. =:^|

> for some perverse reason I wanted [bash] to fall over on me with such a
> large script.

LOL.  I understand the feeling. =:^P

> All in all, I'd say people who think bash is slow are using it wrong.

> 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.

I think a large part of it is that people forget just how slow the 
machines were that shell had to still be practical on back in the day.  
As a consequence, it's pretty impressive on today's machines, even if 
it's not as efficient as tuned native code.

> 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.

And I imagine I'm in for a reasonable set of lessons myself.  But even if 
I'm looking forward to it with a bit of trepidation, it's a good thing 
none-the-less. =:^)

OTOH, I think my /base/ is reasonably solid, because after all, I learned 
"hands-on", originally by rewriting Mandrake's initscripts, back in the 
day (2002-ish in this case).  And those scripts had naturally had years 
of hacking and tuning for the real world, which I think is why I took off 
so fast with shell, because I was hacking real-world bootscripts with a 
real-world purpose and real-world consequences if I screwed up, not some 
artificially weak script designed to use only what was presented in that 
lesson, with little real-world use.

But what I'm missing and should get with this project, is real-world 
experience in the translation back from "it works for me" to "it's broad-
based enough to work, with a bit of reasonable configuration, for pretty 
much everyone who'd have a reason to run it."  (Tho I've had a bit of 
that elsewhere, but nothing like this project's likely to be.)

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

Keepin' that link in for reference...

> Continue with the topic. If it needs to be moved the moderators will do
> it, when they feel the time is right.

> 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.

Makes sense.

> 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. ;)

LOL.  It's OT but we could probably compare stories, that against the pan 
lists that I've been on for a decade now.

> 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;)

Thanks.  We'll see how this "weekend" goes...

>> 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.

By-the-by, they're also discussing possibly doing 3-month cycles now, 
since both kdelibs and plasma-workspaces are feature-frozen for kde4 with 
4.11.  The argument is that there's less really potentially destructive 
change, while it would get fixes and any small feature updates out to 
users faster.  The OpenSuSE maintainers appear to be the biggest 
opposition, as it'd screw up their established work cycle, but others are 
arguing that a packaging approach similar to that taken for the even 
faster cycling firefox and chrome/chromium should solve that.

The story has been covered in several of the Linux/FLOSS newsfeeds I 
follow.

> 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.

Good point.  I guess the whole kde-sunset as well as sunrise overlays 
demonstrated that well enough.  Thanks for the reminder. =:^)

>> 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.

Thanks.  Hopefully in the next couple days...

> (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.

FWIW, I generally update about twice a week on my main machine.  I have 
something, somewhere, configured to warn me if I go more than a week 
between syncs, but AFAIK I've only actually seen that warning once, and 
can't even remember where it's configured.  Three months... I'd have to 
be in the hospital or something for most of that time.

But on the netbook (which I build for in a 32-bit build partition on my 
main machine), I think I went a year and a half between updates at one 
point... at which point the update gets rather "interesting", but can be 
done by a suitably well experienced gentooer, especially if they've been 
doing regular updates on another machine, thus having that memory to fall 
back on as to how they resolved various issues as they came up one at a 
time.

> Thank god for FEATURES=binpkg[3] though: I can roll back if 4.10/11
> turns out to be a stinker.

I've always thought FEATURES=binpkg was one of the best under-recommended 
features in portage... and wondered how paludis could fail to have the 
feature at all (tho for all I know it has it now).

> There's some nice stuff in kate for 4.11 I want to try though.

With 4.10 I began running the 4.x.49.9999 live-branch builds from the 
gentoo/kde overlay, and now that they're available (and patched) for 4.11 
branch too, I'm running that.

With ccache it's actually not too bad.  I'm not running a full kde (127-
ish live packages including a couple non-kde), and with my 6-core 
bulldozer, ssd-based main system and package trees, a tmpfs based 
PORTAGE_TMPDIR, and ccache, a full update twice a week typically takes me 
about an hour, including pre-scanning changelogs for anything interesting 
and doing the post-update etc-update, revdep-rebuild and emerge
--depclean.  (The live-package update on its own is under 20 minutes.)

What I'm /really/ waiting for is wayland, tho.  There's some options (USE 
flags, etc) showing up for it now in kde (kwin-4.11.49.9999 has a wayland 
USE flag, for instance), but I've not turned any of that stuff on nor 
emerged wayland at all yet.  There's a fair chance I'll try it in the 
4.11 time frame, however, and I'm guessing at a final switchover attempt 
next spring or so.  We'll see.  But that transition will be easiest if 
I'm already familiar with the latest kde, so I've an additional incentive 
to stay very current for the next few months.

-- 
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

[gentoo-desktop] Re: Interest inquery: kde4-nosemantic overlay

[Duncan]

Steven J. Long posted on Tue, 16 Jul 2013 03:01:50 +0100 as excerpted:

> 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?)

I believe I may have misunderstood Martin's original comment intent.  The 
below might more accurately address the situation.  (Assuming I'm not 
getting too sleepy to think straight...)

I do have a local overlay, and use it for one-offs, where the upstream 
ebuild's likely to include the patch relatively quickly, or where it only 
applies to a specific version so an update is likely to invalidate the 
patch in any case.

But in the kde case that wouldn't work as the patches will need to be 
reapplied long-term -- no upstream inclusion, as I didn't want to deal 
with manually overlaying/patching every single revision bump, etc.

Actually, for kde I run the betas from the overlay, and (since sometime 
in 4.10) have been running (and generally rebuilding about twice a week) 
the live-branch ebuilds (4.10.49.9999, 4.11.49.9999) when upstream 
branches along with the first rc.  Particularly the live-branch ebuilds 
(and even more the live-trunk -9999 ebuilds, but I've not gotten /that/ 
brave yet) get updated in-place to adapt to upstream code changes as well 
as gentoo system changes, and I wanted my hassle-free application of my 
no-semantic patches until they no longer applied, at which point I wanted 
to know about it so I could redo them.

So applying the patches direct-in-repo made most sense for me, with 
updates overwriting my changes, and the patches then reapplied on top of 
the updates.

But making that an option's probably a good idea, agreed.

> 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.

There's also the fact that my patches change dependencies -- that's what 
they're DESIGNED to do, after all, kill the semantic-desktop deps -- thus 
invalidating portage's metadata cache, so if emerge --regen isn't 
triggered afterward, every emerge invocation will take longer.

What my sync script (local version) basically does:

1) test-me: see if the tree partition is mounted and mount it if 
necessary.

2) setup-parms: grab niceness and parallel jobs from my portage 
configuration, etc.

3) emerge sync and layman sync (backgrounded in parallel, using wait).

4) ebuild-patch (that's my ebuild patching function, the interesting bit).

5) emerge $EJobs --regen

Then after the portage cache is updated, in background/parallel:

6) emerge --fetch (options) @world

7) eupdatedb (for esearch, with portage niceness applied)

8) q -qr (with portage niceness applied)

9) Then (while 6-8 are still backgrounded), spit out a "syncs done, 
fetches and db updates continuing in background" message, after which it 
returns me to a prompt while the background jobs complete.


Obviously that'll need generalized for non-local use.  1 and 2 could be 
generalized into presync.d (ordered), 6-9 into postsync.d (parallel), 3 
into simply sync.d (parallel), and 4 and 5 into immediate-postsync.d (or 
some such, ordered).

Then people could simply drop scriptlets into the appropriate *sync.d dir 
and let the general script handle it.  Meanwhile, #4, the ebuild-patch 
step that's of interest here, would become just another scriptlet file in 
immediate-postsync.d.

> 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.

An option makes sense...

> 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.)

I think the generalized *sync.d approach should still be wrappable.  And 
anything the wrapper handles can simply be left out of the *sync.d dir 
it'd otherwise be located in.

> 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. :-)

Indeed. =:^)

-- 
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

[gentoo-desktop] Re: Interest inquery: kde4-nosemantic overlay

[Martin Vaeth]

Duncan <1i5t5.duncan@cox.net> wrote:
>
> I do have a local overlay, and use it for one-offs

You can have several local overlays, one particularly dedicated for KDE
(and if you put the directory of the latter under git control,
you could also easily make it public e.g. on GitHub so that other users
can use it without using your framework).

> But in the kde case that wouldn't work as the patches will need to be
> reapplied long-term -- no upstream inclusion, as I didn't want to deal
> with manually overlaying/patching every single revision bump, etc.
> [...] So applying the patches direct-in-repo made most sense for me

Why not use the script to patch the ebuilds after fetching
but store the patched ebuilds in your dedicated overlay instead
of the original location?
If you give this dedicated overlay a higher priority in
/etc/portage/repos.conf, portage will install the patched
ebuilds if they are available.

For a general framework, one could e.g. support directories
of the form

/etc/portage/ebuild.patches/FROM:TO/whatever

so that "whatever" (patches, sed-commands, etc; depends how
your framework works) is applied by your framework after
it copied the corresponding ebuild from repository FROM to TO.
In particular, currently you would use only something like

/etc/portage/ebuild.patches/kde-experimental:kde_unsemantic/...

The scripts in your framework can use functions like
	portageq get_repo_path / FROM
or the quicker new
	eix-header -p FROM
to find out the corresponding paths, once these repositories
are set up (and in the eix database, respectively).

> There's also the fact that my patches change dependencies -- that's what
> they're DESIGNED to do, after all, kill the semantic-desktop deps -- thus
> invalidating portage's metadata cache, so if emerge --regen isn't
> triggered afterward, every emerge invocation will take longer.

For a local overlay you do not need to run emerge --regen. Running

egencache --repo=kde_unsemantic --update --update-use-local-desc

after applying the patches is sufficient: If kde_unsemantic has
a higher priority in /etc/portage/repos.conf, its metadata will
be taken.
BTW, I would suggest to put into metadata/layout.conf of
kde_unsemantic the lines

cache-formats = md5-dict
thin-manifests = true

and if you use git also into .gitignore the line

/metadata/md5-cache/

so that users have to run the above egencache command on their own
(which is better than having possibly outdated checksums for
eclasses in which case md5-cache would not help them, anyway).

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

That's why for end-users publishing the patched overlay would
be better: They can still come up with patches anyway, i.e.
they are not even excluded from development if they do not use
your framework.

[gentoo-desktop] Re: kde-lean overlay

[Steven J. Long]

Martin Vaeth wrote:
> Steven J. Long 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*).

You don't appear to have been reading, which is odd, as the mail you got
that info from explained the background at the same time. In summary, again:
we wrap emerge rsync, so it only takes one line on the terminal, and then
disappears. At the time I wrote it, I tried hard to get eix to do everything,
believe me.

Additionally,remember that I've had some people say they won't use eix (again as
mentioned prior, though you appear to have started to address the issue in your
more recent mail.) So irrespective of how nice eix is, we have to support users
without it. And at the time (5 years ago) it was a lot simpler to keep the
separation.

After all, there's not much eix can do about network speed, is there?
So what exact benefit do I get by hard-depending on eix, and losing utility?
It's the same runtime.

Don't get me wrong. I regularly sing the praises of eix, and quite often whinge
that someone should just work with you properly, in #gentoo-portage, no doubt to
their annoyance. But I don't code python, nor am I about to start, and you don't
do IRC, so there's not much I can do about it.

But in general we filter most of emerge's messages, in case there's something
important like a news item, leftover config-updates, a profile upgrade, package
moves and so on. And any message emerge spits out as IMPORTANT. Those can come
up during sync as well.

> 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

Well we do emerge --sync, then by default run: eix-sync '-0 -N'

That's changed once before, a few years ago, actually after discussion with you,
around the metadata sync times. But I'm happy to change the default flags again,
if you recommend something else. As is, it's always been a config setting, and it's
up to the user to explore the wider Gentoo landscape. In this case that's the massive
manpages for eix.

If you want us to run it in a different order, that's of course fine too. I don't
use overlays, I just like the tree diff from eix, and the speed of querying.
Note the user can override with postSync hooks as well. If it's layman --sync for
example, it gets run as the wrapped layman --sync command, after eix-sync. The idea
there is that a user who is using eix doesn't set that, and instead tells eix to do
it all, which is what we've been advising since 2007/8. But another user might.

(or ofc it can be a user-defined function.)

We don't shield the user from emerge: that's not update's purpose. It's designed to
make the routine decisions easier, that belong in a higher layer, closer to the user
and not to the package manager: ie scripted. An example of that is, we don't support
uninstall: in a few places we just tell the user to run emerge -Cq package (like
update -h/--help, and iirc in depclean or one of those maintenance tasks.)

And to give you all the info at the time you're making a decision. But we take the
position that dumbing-down Gentoo is a disservice to everyone: all you're doing is
postponing the inevitable, and the user who's done their own manual install, and knows
how and where to setup files, is much more likely to stay the distance, and be able to
recover when the idiot-box is being an idiot.

That's why coloured diffs of the relevant files are nice, since it reminds you where
stuff goes on, at the same time as you're confirming changes. Of course, if you want
to get complex, it'd probably take as long as trying to explain eix, given the amount
of additions that have been put in over the years, for binhosts, tinderboxes, chroots
etc.

> 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)

Again, that's because you're reacting to certain statements without considering
the whole. Likely because they're things that annoy you, with many of your users.
I know the feeling ;)

The simple fact is I raised postsync immediately, and was still musing as to how
we could use it. But as you've shown above, there's a lot of stuff that goes on
after the postsync (and overlay's have to be considered.)

That's why I've always recommend our users use eix to manage their overlays. We
wrap layman sync as well, but for end-users our advice has ALWAYS been: use eix.

I have no clue where Duncan's stuff comes in as yet, and it still sounds like it
needs reworking and QA once it's actually producing an overlay, as opposed to gobbing
all over the local mirror. If the process can run in postsync, that would be ideal.
As I already stated.

Seriously, I'm on your side. I've personally been using eix to display the tree, and
gladly, since the beginning.

So chill out ;)

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

[gentoo-desktop] kde-lean (was: Re: Interest inquery: kde4-nosemantic overlay)

[Steven J. Long]

Martin Vaeth wrote:
> Duncan wrote:
> > I do have a local overlay, and use it for one-offs
> 
> You can have several local overlays, one particularly dedicated for KDE
> (and if you put the directory of the latter under git control,
> you could also easily make it public e.g. on GitHub so that other users
> can use it without using your framework).

git clone git@weaver.gentooexperimental.org:kde-lean

I add eg: --separate-git-dir=$HOME/repo/git/kde-lean.git # for things I'll be
working on: it just means I have a bare repo kept safe to one side, no matter
what I mess up in my workdir (and I can rm -f it easily if I should feel to.)

Nothing in there of course, but I followed your instructions wrt setup, mv.
Oh, and added a repo_name.

If you email me your/an ssh-pubkey, I'll setup write-access.

The trac is here:
  http://weaver.gentooexperimental.org/trac/kde-lean
  
You need to register and login to browse the source, as we have to be careful
of excess CPU and network usage, since it's Patrick's infra, and we don't want
to be unwelcome guests. Benefit is we don't have to sign away anyone's rights
to github for the rest of time.

Bugs can be browsed and searched, as well as the wiki, ofc.

> > But in the kde case that wouldn't work as the patches will need to be
> > reapplied long-term -- no upstream inclusion, as I didn't want to deal
> > with manually overlaying/patching every single revision bump, etc.

Perhaps not manually, but that's exactly what is happening here. So doing
it in another output directory is no different: it just means you can run
a diff easily, and you don't need to overwrite the local portage mirror.

> > [...] So applying the patches direct-in-repo made most sense for me
> 
> Why not use the script to patch the ebuilds after fetching
> but store the patched ebuilds in your dedicated overlay instead
> of the original location?
> If you give this dedicated overlay a higher priority in
> /etc/portage/repos.conf, portage will install the patched
> ebuilds if they are available.

We can also supply a kde-lean.mask file that can either be dropped into
a directory package.mask, or simply:
 cat kde-lean.mask >> /etc/portage/package.mask

So we can mask eg: kde-base/kdelibs:4::gentoo given that it's not currently
available in overlay profiles/ (or wasn't last time I saw it discussed in
#-portage, at least. IIRC there's a "philosophical" objection, so I wouldn't
hold my breath.;)

There's really not that many packages that even have the semantic-desktop
flag; equery hasuse -p semantic-desktop # (slow) got me the list here:
 http://weaver.gentooexperimental.org/trac/kde-lean/roadmap

> For a general framework, one could e.g. support directories
> of the form
> 
> /etc/portage/ebuild.patches/FROM:TO/whatever

I'm assuming whatever is the usual specifier, from most specific to least,
ie: $PVR -> $CPN. Just so it's in the spec from dot.
 
> so that "whatever" (patches, sed-commands, etc; depends how
> your framework works) is applied by your framework after
> it copied the corresponding ebuild from repository FROM to TO.
> In particular, currently you would use only something like
> 
> /etc/portage/ebuild.patches/kde-experimental:kde_unsemantic/...

s/kde_unsemantic/kde-lean/g

Though if we're doing this for an overlay, FROM should be gentoo. Irrelevant
to the implementation, I know. Speaking of which:

http://weaver.gentooexperimental.org/trac/ebuild-patch
(same git address as above.) If you register on either, your login will be in the
passwd database, but you will need to login to the other trac (with the same
uid/password of course) for the account to be setup therein.

If you intend to commit, using the same email for your account, as for your
commits is supposed to link the two in the trac-vcs browser. (though that may only
work properly in svn, as it doesn't seem to apply to my commit to initialise the
repo, which was needed for gitolite to start managing it.) Regardless, your
email can be changed after, if it's an issue, though again it applies site-wide.

> The scripts in your framework can use functions like
> 	portageq get_repo_path / FROM
> or the quicker new
> 	eix-header -p FROM
> to find out the corresponding paths, once these repositories
> are set up (and in the eix database, respectively).

I'd prefer a straightforward, shlex-compatible config file personally. That makes
it quick for a sh-based implementation, across the board. It's easy enough to check
that {make,layman}.conf haven't changed, and to use the slower setup then.

> > Steven J. Long posted:
> > > From what you've written, the first thing that springs to mind is
> > > /etc/portage/postsync.d/ which has q-reinitialize in it.

> > There's also the fact that my patches change dependencies -- that's what
> > they're DESIGNED to do, after all, kill the semantic-desktop deps -- thus
> > invalidating portage's metadata cache, so if emerge --regen isn't
> > triggered afterward, every emerge invocation will take longer.
> 
> For a local overlay you do not need to run emerge --regen. Running
> 
> egencache --repo=kde_unsemantic --update --update-use-local-desc
> 
> after applying the patches is sufficient: If kde_unsemantic has
> a higher priority in /etc/portage/repos.conf, its metadata will
> be taken.

Can we do this in a postsync.d hook, both one that runs eix and one that
does not? Pseudo-code of the algorithm you'd use in both cases would be
ideal. Well, sh of the top-level would be /ideal/.. ;p

> BTW, I would suggest to put into metadata/layout.conf of
> [kde-lean;] the lines
> 
> cache-formats = md5-dict
> thin-manifests = true
> 
> and if you use git also into .gitignore the line
> 
> /metadata/md5-cache/
>
> so that users have to run the above egencache command on their own
> (which is better than having possibly outdated checksums for
> eclasses in which case md5-cache would not help them, anyway).

Lovely, followed to the letter.
 
> >> That's the trouble with glue-scripting: you have to consider the
> >> interaction of quite a few disparate commands, and various end-user
> >> setups.
> 
> That's why for end-users publishing the patched overlay would
> be better: They can still come up with patches anyway, i.e.
> they are not even excluded from development if they do not use
> your framework.

Indeed.

Seems apparent we need to get to milestone 0.2 for ebuild-patch
before we can think of publishing an overlay. 0.1 is up to Duncan: base
just means the initial impl of stage 4, in a state that he's happy for the
ROTW to see ;)

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

[gentoo-desktop] Re: kde-lean

[Steven J. Long]

Steven J. Long wrote:
> git clone git@weaver.gentooexperimental.org:kde-lean

Oops just been told that's the git daemon over ssh. Apologies.
To use the public urls:

  git clone git://weaver.gentooexperimental.org/ebuild-patch

  git clone git://weaver.gentooexperimental.org/kde-lean

-- 

[gentoo-desktop] Re: kde-lean

[Steven J. Long]

Duncan wrote:
> Something that's been bothering me a bit.  So far, this "framework" is 
> pretty much just a function in my sync script that applies my patches 
> after a pull.  It's pretty simple, not even that much code or time, 
> actually.  So it'll need adapted for a wider audience, but I /do/ hope to 
> get at least the initial function posted to the forum before this 
> "weekend" is over.

That's fine. Really it shouldn't be more than applying:
 /etc/portage/patches.ebuild/cat/pkg[-ver[-rN]].patch to the ebuild, and ensuring
that any extra patches are in /files for the overlay, which afaic is the
maintainer's job, but I'm happy for us to automate any part that's useful.

> Don't worry, the patches themselves are still manually created by /
> someone/, they're simply applied immediately after the sync (before a 
> cache regen since they affect deps), and if they no longer apply for 
> whatever reason, it's not fatal, so the result will simply be that ebuild 
> returns to upstream gentoo/kde default and wants to pull in the semantic-
> desktop junk again, until someone comes up with an updated patch.

Yeah, though I don't want anything reverting to default like that, so we need the
package.mask of synonymous ::gentoo packages.
 
> > 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.)
> 
> You'll be happy to know that's the way it works. =:^)  I hadn't even 
> consciously considered the other way until you mentioned it, I think 
> because I too was so horrified by the possibility, that I rejected it out 
> of hand and considered the separate phases the only realistic approach 
> from the get-go.

Good. You should know, I feel the same way about the idea of patching the local
portage mirror. I'm not happy with use of local/named overlay as an "option":
afaic it should be the only behaviour. If you must keep the option to patch ebuilds
in-situ, fine. Just not as default: opt-in to that instead.

> > Okey-dokey: I'll mail you off-list in the next day or two
> Cool. =:^)

Did you get my email? Worried I might have hit a spam-filter.

> But my system parallels emerge much more closely, being in effect little 
> more than a bunch of emerge aliases, most of them starting ea (emerge --
> ask) or ep (--pretend), with various other letter combinations added that 
> parallel the similar emerge options (eaw= emerge --ask @world... with
> --update --deep --newuse --oneshot implied, etc).
> 
> The parallels make it very easy to transfer emerge option knowledge to my 
> system, and the reverse as well.

I think you're a bit misinformed there: update _mirrors_ emerge options (or it's
a bug.) The -h for short options (--help for long ones) starts:
Usage: update <options> [target list]
 Options: -eapqvurnUDNoO[bB][gG][kK]iEmsSfFlRACMhtxXWYzc
           -eapunDNo[bB][kK][gG] : same as emerge

The only difference that would matter in usage, is that you have to use -i to
install something to world.

So update -uD --changed-use system # for example does the same thing emerge
would do. It just does the --pretend --verbose bit for you and waits for you
to review the output, as we're recommended to do, and gives you a dialog to edit
the list, and set package/global USE flags (or more commonly, read wtf they are;)
before continuing.
[You could use -U instead of --changed-use. That may be coming in portage, if zac
feels like it; he said it's free, anyhow.]

If you don't tell it to do something else, it assumes you want to:
  emerge -uD --changed-use world --with-bdeps y
followed by glsa-check, depclean and revdep-rebuild. At the end it runs
dispatch-conf (or etc-proposals et al) if needed (and not automated.)

So update -s syncs the tree, runs eix-sync which handles overlays and displays
the tree-differences, and then does the above.
[If that's wrong wrt eix and overlays, especially given that q's postsync runs
before eix, then someone please tell me what to do instead.]

That's the short version. ;)

So I'd argue update inculcates just as much transferable knowledge: for most things
you use it as you would emerge, with the exact same flags, but s/emerge/update to
let it provide "porcelain" around the command-line interface to portage.
Additionally any changes to config files are presented as coloured-diffs you have to
confirm, so while it saves time, it also reminds one where things happen.

With changelogs for downgrades (i think it is), while I knew it's the right thing to
do, I never bothered to check them. Having knowledge of how to do something, doesn't
mean one wants to type it in every time: it breaks the flow.
That's what scripts are for.

> > All in all, I'd say people who think bash is slow are using it wrong.
> > 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.
> 
> I think a large part of it is that people forget just how slow the 
> machines were that shell had to still be practical on back in the day.  
> As a consequence, it's pretty impressive on today's machines, even if 
> it's not as efficient as tuned native code.

Indeed: Unix sh has been doing the job of javascript in polkit since the days of
8-bit CPUs with 16-bit address-spaces. And an awful lot more too.
But if you fork lots of externals when you don't need to, your shell-script will be
slow, so people who script all the time, simply don't.

wrt "tuned native code" most of the people who look down on sh have no idea what
that means. They typically come out of Uni knowing Java, and deign to learn python,
so as to share their "talent" with the rest of us. They tend to look down on C too,
or "view it as a necessary evil" given that every sane OS is written in it.

Functional programmers tend to be a bit more open, since the idea of macro expansion
is not a dirty concept to them, and Guy Steele is hardly a slouch when it comes to C.
The trendy haskell boys (we love you #gentoo-haskell ;) need gcc to compile their
code.

> Meanwhile, it's my "weekend" now (three day but with a meeting tomorrow), 
> so I've a couple days to spend on this and other personal projects.  My 
> goal is to be posting in the forum by the end of it, preferably with the 
> first code posted.  We'll see.
..
> >> Short term, is it worth it to post the 4.10.80+ patches
> > Do please post them to the forum thread, in a [code]block[/code]
> > Or at a reasonably light pastebin with a [url=http://..]link text[/url]
> 
> Thanks.  Hopefully in the next couple days...

Uh-huh ;-) If you're obsessing over ebuild-patch before you release anything,
a) don't: nothing crafted by human hands is ever perfect, and
b) can you at least post the patches to KDE ebuilds you've built and run?
They don't need to be the exact versions we'll use, though we do need the original
as well as the patch(ed version), if it's not been in gentoo-x86 cvs. commit-ids
are fine for originals from gentoo git.

Alternatively, just push your current KDE-4.11 ebuilds to the overlay (kde-lean repo).

> FWIW, I generally update about twice a week on my main machine.  I have 
> something, somewhere, configured to warn me if I go more than a week 
> between syncs, but AFAIK I've only actually seen that warning once, and 
> can't even remember where it's configured.  Three months... I'd have to 
> be in the hospital or something for most of that time.

Well it's due to specific circumstances: my system is in a state where it needs a
deep toolchain upgrade, which is something I've wanted since we started update.
So I'm pausing til it's done, which gives me an incentive to get it done. (Yes I
know about sets. ;) Normally I update 2 or 3 times a week.

We did the same when the expat upgrade came in: it took about 6 months to get ABI
upgrades working in chroot well enough that we could upgrade live machines in
confidence. Still, multi-binhost support and the installer came out of that, as
well as the /etc/warning capability. There was no way we were going to rebuild the
whole chroot every time: it was only about testing what it would do with a specific
package set installed.

It really is quite spooky watching emerge install from stage3 with binpkgs: it feels
almost wrong for it to sail through it as quickly as an rpm-based distro. I saw that
happen countless times, so I know Gentoo and portage rock for that usage.

Reminds me, we'll bring the installer up to date after --toolchain is done, so we
can finally release it: last time we worked on it, lspci -k was just coming into
unstable, then we didn't have enough time for it. But I need to reinstall a laptop,
and we're going to try to get it installing a raspberry-pi. (need a challenge;)

> > There's some nice stuff in kate for 4.11 I want to try though.
> With 4.10 I began running the 4.x.49.9999 live-branch builds from the 
> gentoo/kde overlay, and now that they're available (and patched) for 4.11 
> branch too, I'm running that.

Ah these mythical patches, I keep hearing about.. ;p

> What I'm /really/ waiting for is wayland, tho.

Heh it's quite a good contrast in use-cases: I'm incredibly conservative about
trying out new things when it comes to my desktop; I like it boring and reliable,
same as everything else I can't function without. (That's why I didn't go near
KDE-4 til 4.4; usually it's been x.2.) So if you're pushing to try the interesting
new technology, that's good as it means we're not going to be left behind.

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

[gentoo-desktop] Re: kde-lean

[Duncan]

Steven J. Long posted on Wed, 24 Jul 2013 03:04:52 +0100 as excerpted:

> Did you get my email? Worried I might have hit a spam-filter.

I got it, but my "weekend" last week... didn't end up being entirely off 
after all, and I've been up... about 32 hours now...

We'll see how this one goes... after some sleep...

-- 
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

[gentoo-desktop] Re: Interest inquery: kde4-nosemantic overlay

[Michael Palimaka]

I just saw that in Arch Linux's AUR[1], they provide a fake (empty) 
package that satisfies the package manager's dependencies, but doesn't 
actually do anything.

Perhaps this approach could help ease the maintenance burden?

[1]: https://aur.archlinux.org/packages/nepomuk-core-fake/

[gentoo-desktop] Re: Interest inquery: kde4-nosemantic overlay

[Duncan]

Michael Palimaka posted on Fri, 26 Jul 2013 04:00:30 +1000 as excerpted:

> I just saw that in Arch Linux's AUR[1], they provide a fake (empty)
> package that satisfies the package manager's dependencies, but doesn't
> actually do anything.
> 
> Perhaps this approach could help ease the maintenance burden?
> 
> [1]: https://aur.archlinux.org/packages/nepomuk-core-fake/

The way gentoo (or rather, portage) does that is package.provided... but 
that doesn't take care of ebuilds hard-enabling build-time deps, which 
then cause the build to fail when they're not found.  Those hard enablings 
must be patched out, and if that's being done, might as well patch out 
the dependency itself at the same time.

Binary-based packages don't have the build-time problem, but they /can/ 
have other problems if they were built against libraries that simply 
aren't there to provide their symbols to load.

A stub library could be built to provide the symbols and short-out the 
logic as necessary, but that's beyond /my/ expertise, anyway.

-- 
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

[gentoo-desktop] Re: Interest inquery: kde4-nosemantic overlay

[Michael Palimaka]

On 26/07/2013 04:26, Duncan wrote:
> but
> that doesn't take care of ebuilds hard-enabling build-time deps, which
> then cause the build to fail when they're not found.  Those hard enablings
> must be patched out, and if that's being done, might as well patch out
> the dependency itself at the same time.
Which ebuilds hard-enable?

Re: [gentoo-desktop] Re: Interest inquery: kde4-nosemantic overlay

[Fabiano Engler]

[-- Attachment #1: Type: text/plain, Size: 1780 bytes --]

Oh man, knowing the next release will force enable semantic desktop is bad
news, I would surely drop KDE desktop when that became stable and I am
forced to update.

Your work offers some hope though, I think the better approach for end
users would be a plug and play overlay, but if I haven't read it here I
would probably not even think about looking for an overlay for this and
would just move away, which I suspect some other users will do too..

Thanks for the time and effort into sharing this, much appreciated.

Fabiano.
On Jul 11, 2013 5:05 AM, "Martin Vaeth" <vaeth@mathematik.uni-wuerzburg.de>
wrote:

> Duncan <1i5t5.duncan@cox.net> 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)
>
>
>

[-- Attachment #2: Type: text/html, Size: 2343 bytes --]

Re: [gentoo-desktop] Re: Interest inquery: kde4-nosemantic overlay

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 546 bytes --]

Am Samstag, 27. Juli 2013, 03:36:08 schrieb Fabiano Engler:
> Oh man, knowing the next release will force enable semantic desktop is bad
> news, I would surely drop KDE desktop when that became stable and I am
> forced to update.

One of the pertinent facts about the Gentoo mailing lists is that regularly 
molehills are percieved and described as mountains.

[Yes you may quote that for LWN distro quote of the week. If you must.]

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

[gentoo-desktop] Re: Re: Interest inquery: kde4-nosemantic overlay

[Steven J. Long]

Andreas K. Huettel wrote:
> Also schrieb Fabiano Engler:
> > Oh man, knowing the next release will force enable semantic desktop is bad
> > news, I would surely drop KDE desktop when that became stable and I am
> > forced to update.
> 
> One of the pertinent facts about the Gentoo mailing lists is that regularly 
> molehills are percieved and described as mountains.

Far more pertinent for a user, is that your concerns will regularly be disparaged
by "developers" who don't really see their mission as enabling users to get the
job done.

Consequently you may expect sneering or sardonic replies to valid issues that you
raise, even when you're not arguing with their decision, but simply providing
workarounds to enable people to use their machines how they see fit.

When pushed beyond condescension, the usual response is whining about "use-cases"
and questioning of your motives and method, since you can "just" turn it off, or
some other guff that ignores your valid reasons for wanting another option, and
consequently does not help you to get the job done.

Still, you likely have more experience than the person patronising you, and are
grown-up enough to shrug it off and get on with the task at hand.

That doesn't mean you have to like it, and no-one external will expect you to:
just the usual clique that will round on you for daring to step into the snakepit
and speak your mind.

Ignore them, and do not respond for a couple of days, and never in kind, as blame
will only ever attach to you, irrespective of how rude they might be.

> [Yes you may quote that for LWN distro quote of the week. If you must.]

If only it were worth quoting.

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

[gentoo-desktop] Re: Interest inquery: kde4-nosemantic overlay

[Duncan]

Fabiano Engler posted on Fri, 26 Jul 2013 22:36:08 -0300 as excerpted:

> Oh man, knowing the next release will force enable semantic desktop is
> bad news, I would surely drop KDE desktop when that became stable and I
> am forced to update.
> 
> Your work offers some hope though, I think the better approach for end
> users would be a plug and play overlay, but if I haven't read it here I
> would probably not even think about looking for an overlay for this and
> would just move away, which I suspect some other users will do too..
> 
> Thanks for the time and effort into sharing this, much appreciated.

Time to get rid of these old subthreads still marked to reply to later, 
as events have long passed them up.

(On a personal note, work suddenly slammed me with mountains of overtime, 
and while I normally update a couple times a week, I had all I could do 
to update even a couple times a month for awhile.  That's why my posts 
here unfortunately dried up so fast.  Work has slowed down to something 
reasonable again, so now I have time to come back and tie up lose ends, 
even if time and events /have/ rather made them anticlimatic.)

As I assume most readers have figured out by now but for the record, 
gentoo/kde, to their credit, finally decided to add the semantic-desktop 
USE flag back to 3.11 before it stabilized. =:^)

So ultimately, the only folks that had to deal with the situation were 
those like me running in-tree unstable, or the gentoo/kde overlay with 
its pre-release versions (which is where I am).  And people running 
~arch, and even MORE so people running overlay pre-release versions, 
should be prepared to deal with this sort of thing, or they should 
reevaluate their running ~arch or the overlay in the first place.

Never-the-less, it's likely that our protests did play at least a small 
part in bringing the semantic-desktop back, such that it was never 
removed for stable users at all. =:^)

Thanks be to the gentoo/kde dev(s) that stepped up to do the work, as 
some of us users know quite well now what sort of things that involves! 
=:^)

-- 
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

[gentoo-desktop] Re: kde-lean

[Duncan]

Steven J. Long posted on Wed, 24 Jul 2013 03:04:52 +0100 as excerpted:

> Duncan wrote:
>> Something that's been bothering me a bit.  So far, this "framework" is
>> pretty much just a function in my sync script that applies my patches
>> after a pull.  It's pretty simple, not even that much code or time,
>> actually.  So it'll need adapted for a wider audience, but I /do/ hope
>> to get at least the initial function posted to the forum before this
>> "weekend" is over.
> 
> That's fine. Really it shouldn't be more than applying:
>  /etc/portage/patches.ebuild/cat/pkg[-ver[-rN]].patch to the ebuild, and
>  ensuring
> that any extra patches are in /files for the overlay, which afaic is the
> maintainer's job, but I'm happy for us to automate any part that's
> useful.

OK, so as my last post a few minutes ago mentioned, work finally slowed 
down on the mountains of overtime they were giving me and I'm back to 
wrap up these loose ends of threads I left marked to reply to later, even 
tho time and events moved on and the original trigger is gone.

Are you still interested in doing something with this general ebuild 
patching framework?  While the semantic-desktop use is gone, I still find 
it useful for the occasional ebuild patch, and keeping the framework 
around and working means the next time something like this comes up, 
it'll be far easier to deal with.

And if you have a different list to take the discussion to, I'm open to 
that too.  I prefer not to go just personal mail, however, because that's 
too easy to let drop and never come back to if something dumps on me like 
those mountains of overtime did.  IOW, were this thread private mail, I'd 
have never done this followup...  At least with the public threads, 
there's some reason to come back and wrap up, if nothing else, and that 
could ultimately mean the difference between this project going public 
and it staying just a bunch of scripts I use myself, locally.

-- 
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

[gentoo-desktop] Re: Interest inquery: kde4-nosemantic overlay

[Duncan]

Michael Palimaka posted on Fri, 26 Jul 2013 23:36:59 +1000 as excerpted:

> On 26/07/2013 04:26, Duncan wrote:
>> but that doesn't take care of ebuilds hard-enabling build-time deps,
>> which then cause the build to fail when they're not found.  Those hard
>> enablings must be patched out, and if that's being done, might as well
>> patch out the dependency itself at the same time.

> Which ebuilds hard-enable?

As I've said elsewhere just now, wrapping up threads long overtaken by 
events that I still had marked to reply to later...

In context, I was referring to (the now dead issue of) gentoo/kde 
removing USE=semantic-desktop.  While the USE flag was gone, ebuilds that 
had previously soft-depended on nepomuk, etc, subject to USE=semantic-
desktop, were then hard-depending on it, because the USE flag had been 
removed and the dependencies hard-enabled in the ebuild.

Gentoo's package.provided could be used to "fake" the package being there 
for portage, but that wouldn't help for ebuilds that hard-enabled 
configure-options that had previously been enabled only with USE=semantic-
desktop, because the dependencies were now hard-dependencies coded into 
the ebuild.  Naturally, when those ebuilds failed to find dependencies 
the hard-enabled options called for, they failed, and package.provided 
wouldn't help with that.

I was simply saying that such hard-enabling had to be patched out to 
avoid those failures, and since we were patching it out anyway, we might 
as well patch out the entire dependency, thus avoiding the whole 
package.provided hassle as well.

Happily, events overtook the thread in my absence, and gentoo/kde decided 
to bring back USE=semantic-desktop before 4.11 stabilization, after all. 
=:^)  So now it doesn't matter.  However, that /is/ what I was referring 
to, as I wrap up this subthread.

-- 
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

[gentoo-desktop] Re: kde-lean

[Duncan]

Steven J. Long posted on Mon, 22 Jul 2013 03:31:49 +0100 as excerpted:

> Steven J. Long wrote:
>> git clone git@weaver.gentooexperimental.org:kde-lean
> 
> Oops just been told that's the git daemon over ssh. Apologies.
> To use the public urls:
> 
>   git clone git://weaver.gentooexperimental.org/ebuild-patch
> 
>   git clone git://weaver.gentooexperimental.org/kde-lean

[ More long dead thread wrapup]

Still interested in this?  kde-lean has of course been overtaken by 
events, but there's still some merit in the ebuild-patch framework idea.

-- 
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

[gentoo-desktop] Re: Interest inquery: kde4-nosemantic overlay

[Duncan]

Martin Vaeth posted on Thu, 18 Jul 2013 14:32:06 +0000 as excerpted:

> Why not use the script to patch the ebuilds after fetching but store the
> patched ebuilds in your dedicated overlay instead of the original
> location?
> If you give this dedicated overlay a higher priority in
> /etc/portage/repos.conf, portage will install the patched ebuilds if
> they are available.
> 
> For a general framework, one could e.g. support directories of the form
> 
> /etc/portage/ebuild.patches/FROM:TO/whatever

[More dead thread wrapup]

Just bumping this as an idea to followup on, in case there's interest in 
continuing framework development in other subthread replies.

-- 
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

[gentoo-desktop] Re: kde-lean

[Steven J. Long]

On Thu, Jan 02, 2014 at 09:26:34, Duncan wrote:
> Are you still interested in doing something with this general ebuild 
> patching framework?

Hell yeah :) Was about to start work on it next week or two.

>  While the semantic-desktop use is gone, I still find 
> it useful for the occasional ebuild patch, and keeping the framework 
> around and working means the next time something like this comes up, 
> it'll be far easier to deal with.

Well it's not quite gone, as konversation-1.4 and 1.5 pull in akonadi
for "address-book integration"; I've patched ebuilds in my local overlay
just a couple of days ago, following Chiitoo's post[1] (he updated the
patch for 1.5) but not installed either yet. I've had a couple of busy
months too, and not done much on update, but got back to it a week or
two ago, starting with a bug that was weird (only showed up on end-user
system, and I'm still not sure why it happened which bothers me, but
reverting the old, minor change has fixed it.)

I also want to add some of creaker's work to kde-lean, so we have a nice
out-of-the-box experience for people who aren't interested in nubkit[2]
either. Chiitoo's post is in his thread, and creaker's also coded up
a Qt automounter that works in the Dolphin context menu[3].

I switched back to using Konqui for file-management: can't believe
I was so dumb as to keep trying to use Dolphin. Back in the day, a
KDE desktop with konqui and fish://, with just kwrite for editing,
was considered THE best php "IDE". Midnight-commander mode *rocks*
for work, and now I just have the Konqui "profiles" button in
taskbar, with Bookmarks for quick web access. Much nicer :-)

> And if you have a different list to take the discussion to, I'm open to 
> that too.  I prefer not to go just personal mail, however, because that's 
> too easy to let drop and never come back to if something dumps on me like 
> those mountains of overtime did.  IOW, were this thread private mail, I'd 
> have never done this followup...

Yeah agreed, although as you may have realised I'm not a regular on this
list: I only opened it today out of curiousity as to why it was in my
subscribed newsgroups. Heh forgetful old me, I'm afraid :)

So ok, I've remembered now heh and will try to stay up with it. But
really, I would have bcc'ed as well: it's fine to keep list discussion
to the list, and I entirely agree with that. But you have to bear in
mind that you're working with human beings who are forgetful, too,
and I for one read gentoo lists (apart from pro-audio) via gmane.

[I haven't bcc:ed you on this as the address I have for you is
clearly a list one, so I'm presuming you do everything via email
and don't want two copies.]

In terms of keeping it in public, I'd also recommend using a bug
tracker. It's amazing how motivating it is to fix and close a bug, or
at least I find it so. Keeping them active indicates that you've not
dismissed that concern, even if you've not worked on it for ages. I
have a couple that simply have to wait til I've got more fundamental
things working, but which will be sorted out when I get there. I tend
not to close those LATER (I think i have one bug in that state) as
I want the reminder when I use the interface; they just get milestoned
against the next version (though we've been on 0.1.4.0_{pre,rc}N for
about 5 years or sth: once --toolchain is correct, we'll move up.)

>  At least with the public threads, there's some reason to come
> back and wrap up, if nothing else, and that could ultimately
> mean the difference between this project going public 
> and it staying just a bunch of scripts I use myself, locally.

Well tbh, I was just going to do it anyhow, as Neddy's started a
gentoo-static overlay[4], and I need to maintain kde-lean come what
may. (there's nothing in atm, as i was waiting on you before,
which was I'd decided just to go ahead with our own thing. good
job I did open this list, huh?:) Gentoo-static is nice and small
so makes a good test-case.

I mean you say it's better to keep it public and I agree; but there's
also something to be said for keeping in touch, and not assuming your
workflow and methods are in use by others. For instance I'd basically
given up on you; removed your repo from accessibility and was about
to delete the trac and the backend repo. A further 2 months has
gone by, imo simply because you cba to email me. Good show *cough*

So the idea is to have a list of ebuilds per overlay, and simply to
do a diff from the upstream version in-tree, which is our patch.
Then we a) check the current ebuild version hasn't changed,
and: b) try to apply it to later incoming versions
 (after a sync.)

Ideally we want to do it _before_ q and eix post-sync.
eix isn't an issue for our users, in that update runs it
separately, but it may be for people who use emerge directly,
since istr that eix-sync is used to run emerge --sync.

Shouldn't be a problem with a suitable postsync hook, which
would cover both cases. OFC it's only needed for the overlay
author running upatch (new name in my head, easier to type)
to maintain the overlay, not for the overlay users who just
use layman. layman sync is normally run by eix-sync iirc,
which is perfect if we've modded the ebuilds just before.

However it's important to know the version of the upstream ebuild
so we can track changes (ie SHA256 or MD5 from manifest.) I'm
leaning toward simply backing up the manifest file, as that
covers everything.

If this is sounding a lot like a git branch, that's because it is.
I've looked around for a suitable gentoo git repo, but can't
find one (perhaps I haven't looked hard enough.) There isn't one on
gentoo's github[5], for sure. Funtoo used to maintain one, but
they're not any more, and I can't see any branches in their repos
online that are to do with that.

Patrick started the conversion process, and left the intermediate
stage work-products up[6] for anyone who wants to continue it,
although it would ofc be much better if he also showed how to
update it with current changes. It still saves a lot of time
though, as you need a massive amount of RAM (for me anyhow) to
do the initial conversion.

I don't know cvs at all; hell I hardly know git. If someone is
going to carry on with Patrick's work, it's better done sooner,
or we may have to do the initial conversion all over again.

OFC if you have something to show, by all means push it to the
repos: I'd much rather use work you're maintaining than reinvent
the wheel. Oh, you'll have to send me an ssh pubkey, as I told you
last year, and I'd advise you to keep that off-list. It's nothing
to do with the actual work, and simply an infra detail. The
ebuild-patch repo[7] is yours, and if you need another for QA
or something, just tell me.

If again i don't hear from you, then with respect to you as THE
uber-user: Do NOT waste any *more* of _my_ time. I don't have a lot
of it, and not many years left. And please don't rhapsodise with
rationalisations instead of results. I find it intensely annoying,
when you didn't just email me to get your repo sorted out months
ago. I _expect_ better in future and I *know* you are capable of
it. I mean, if you don't take the initiative, then forget about
your project, with the best of regards. Who else is supposed to
drive it forward, when you clearly don't think it's worth doing?

Or y'know: enjoy your private collection on your own, or with
others who like working in such a fashion.

And good luck to you, truly.

Regards,
steveL.

[1] http://forums.gentoo.org/viewtopic-p-7432716.html#7432716
[2] http://forums.gentoo.org/viewtopic-t-938680.html
[3] http://forums.gentoo.org/viewtopic-t-972762.html
[4] http://weaver.gentooexperimental.org/trac/gentoo-static/
[5] https://github.com/gentoo/
[6] http://gentooexperimental.org/~patrick/weblog/
    archives/2014-02.html#e2014-02-20T09_32_05.txt
[7] http://weaver.gentooexperimental.org/trac/ebuild-patch/browser

(I hate urls split across email lines: impossible to cp and
paste ime. It's current at weblog; paste the relative part
if you're reading this in an archive, and care. ;)
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)