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

List:       gentoo-desktop
Subject:    [gentoo-desktop] Re: kde-lean
From:       "Steven J. Long" <slong () rathaus ! eclipse ! co ! uk>
Date:       2014-03-18 0:35:42
Message-ID: 20140318003542.GA1586 () rathaus ! eclipse ! co ! uk
[Download RAW message or body]

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

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