[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-desktop
Subject:    [gentoo-desktop] Re: kde-lean TL;DR unless you're going to use it ;)
From:       Duncan <1i5t5.duncan () cox ! net>
Date:       2013-07-17 10:32:31
Message-ID: pan$84146$d1492adf$150096c$530f740b () cox ! net
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]