Mailing List Archive

kde-lean ;)
<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 ;-)
Re: kde-lean ;) [ In reply to ]
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
Re: kde-lean TL;DR unless you're going to use it ;) [ In reply to ]
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 ;-)
Re: kde-lean TL;DR unless you're going to use it ;) [ In reply to ]
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
Re: kde-lean [ In reply to ]
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 ;-)
Re: kde-lean [ In reply to ]
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
Re: kde-lean [ In reply to ]
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
Re: kde-lean [ In reply to ]
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 ;-)