Mailing List Archive

Duncan wrote:
> What's up with kde-4.3.2? I see it's masked, but the mask was pre-4.3.2
> release I believe, presumably until 4.3.2 was released, it has been out
> for several days now, and the masking comment isn't helpful at all as to
> why it might /still/ be masked, even in the kde-testing overlay.
>
> Also, I see revision bumps for 4.3.1 when I'd expect to see 4.3.2 coming
> out, and the lzma USE flag that was on testing kdelibs now seems to be
> disappeared again as it downgrades back to gentoo-tree, etc.
>
> So I'm asking what's up.
Thats quite simple, 4.3.2 stay masked until we stable 4.3.1, stablebugs are
waiting on archies, we are hoping people will test for us. If we unmask 4.3.2
everyone will migrate to it so we would be stabling something not approved
working.
>
> Meanwhile, what about kde-testing changelogs? When I see a -rX bump, I
> like to see why it's happening. Similarly with USE flags coming and
> going. kde-testing doesn't seem to include changelogs. OK, sort of, but
> is there an easy replacement for it, besides manually browsing viewcvs or
> whatever? It's git-based, right? I know and use git what-changed on my
> live kernel git all the time. I suppose I could do that on the kde-
> testing git repo as well. Is that the suggested solution or is there
> better? I've been more or less flying blind and it's beginning to bother
> me, so getting the problem addressed would make me a rather happier
> camper. =:^)
There will be no changelogs. Use git history.
http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=summary
or just cd /path/to/the/interesting/dir/ && git log ../dir/
>
> And if I do find a bug, do I check for and post it @ bugs.gentoo, or
> elsewhere?
bugs.gentoo.org is official bugzilla for official projects. So yes you open bug in
there. Just add prefix [kde-testing] to summary for easier identification in the
list.
>
> Meanwhile, there's not a mailing list to follow what's going on more
> closely, is there? I obviously already follow this one. I suppose it's
> mostly IRC driven... and I'm not an IRC type of guy.,
We are IRC driven guys mostly. :D So this is best tracker for you. If you
think this is too few informations, well bad luck, because we aint going to
improve it probably. If you want more infos on MLs then join the irc and do
the summaries. :P

Cheers
Tomas

Duncan posted on Fri, 09 Oct 2009 09:34:51 +0000 as excerpted:

> Meanwhile, what about kde-testing changelogs? It's git-based, right?
> I suppose I could [use git whatchanged] on the kde-testing[.]

That works. I just setup a script for it. So that bit's taken care of.
=:^)

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

Tomáš Chvátal posted on Fri, 09 Oct 2009 13:33:46 +0200 as excerpted:

> Duncan wrote:
>> What's up with kde-4.3.2?

> Thats quite simple, 4.3.2 stay masked until we stable 4.3.1, stablebugs
> are waiting on archies, we are hoping people will test for us. If we
> unmask 4.3.2 everyone will migrate to it so we would be stabling
> something not approved working.

Thanks for the reply. It just felt quite weird seeing new 4.3.1-rX
revisons coming out when 4.3.2 was widely announced, and I knew the
ebuilds were available, because I caught them during the brief period
when they were unmasked before the upstream kde announcement, and
therefore weren't installable. But I knew why /that/ was so didn't
mention it, just didn't know why they /still/ weren't unmasked.

I was beginning to wonder if you'd decided to release 4.3.2 as 4.3.1-rX
bumps, to save people having to upgrade the packages that hadn't
changed... I guess that's more or less what the kernel packages do with
the 2.6.x.Y versions, simply make them 2.6.x-rZ (Z has no direct relation
to Y). But I never did gentoo kernels, preferring direct upstream (and
am now directly on kernel git), so that never directly affected me.
Using the same policy for kde4 certainly would have, tho I can't say I'd
be entirely displeased with the idea. But it's probably a bit to early
in the 4.x cycle for that yet. As it matures, there'll be less code
churn in most packages, and it might be worth it.

>> Meanwhile, what about kde-testing changelogs?

> There will be no changelogs. Use git history.

That's what I came to realize, sparked by thinking about it to write the
question. So an hour or so after posting that, I had a scriptlet setup
to do it for me. =:^) But if I'd have not asked the question, I'd
probably have not thought of it, so asking the question was good, even if
I did come up with my own answer. =:^)

>> And if I do find a bug, do I check for and post it @ bugs.gentoo, or
>> elsewhere?

> bugs.gentoo.org is official bugzilla for official projects. So yes you
> open bug in there. Just add prefix [kde-testing] to summary for easier
> identification in the list.

Thanks. It has been surprisingly smooth, here, every since you guys got
the kde3 and kde4 stuff working well together! =:^)

BTW, thanks! It was after that was working that I was finally able to
get kde4 working to my satisfaction -- by tackling a single kde4 app at a
time on a still mostly kde3 desktop. The problem was that at least at
4.2.4, when I did the switch, the kde4 defaults both normal preferences
and performance-wise were so incredibly bad, I couldn't get much of
anywhere at all trying to tackle all of them at once! By tackling a
single app at a time, getting it configured to my liking, then unmerging
the kde3 version so the kde4 version would run when invoked, I was able
to make the changes incrementally on an otherwise working desktop, and it
worked *MUCH* better. The last two apps I tackled were kwin and plasma,
the latter of which I did after finally switching to a kde4 desktop --
after configuring pretty much everything else.

The point is, that was all possible because you guys had kde3 and kde4
working well side-by-side by then, so I could run kde4 apps on a kde3
desktop, without screwing up ksycoca or whatever. Had you guys not put
in all that work to make it work, I'd have continued to have a /terrible/
time trying to get kde4 working, because it was just too much to try to
tackle all at once.

I don't know. That bit about running and configuring individual kde4
apps on a working kde3 desktop, may be worth adding as a hint to the kde4
upgrade guide... I know it sure helped me!

Yeah, there are still bugs, but they're pretty much all upstream. You
guys have done an amazing job with KDE here on Gentoo. Thanks again!
And I know where (and how) to bug if I need to, now.

>> Meanwhile, there's not a mailing list to follow what's going on more
>> closely, is there? I obviously already follow this one. I suppose
>> it's mostly IRC driven... and I'm not an IRC type of guy.,

> We are IRC driven guys mostly. :D So this is best tracker for you. If
> you think this is too few informations, well bad luck, because we aint
> going to improve it probably. If you want more infos on MLs then join
> the irc and do the summaries. :P

Who knows? Maybe someday. Meanwhile, running git whatchanged
ORIG_HEAD.. regularly after syncing the overlay, looks like it should
well cure that "running blind" feeling I was having. I'm happy it's git,
as I'm not as comfortable with any of the other (D)VCSs.

Thanks again! =:^)

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

On 10/09/2009 02:33 PM, Tomáš Chvátal wrote:
> Duncan wrote:
>> What's up with kde-4.3.2? I see it's masked, but the mask was pre-4.3.2
>> release I believe, presumably until 4.3.2 was released, it has been out
>> for several days now, and the masking comment isn't helpful at all as to
>> why it might /still/ be masked, even in the kde-testing overlay.
>>
>> Also, I see revision bumps for 4.3.1 when I'd expect to see 4.3.2 coming
>> out, and the lzma USE flag that was on testing kdelibs now seems to be
>> disappeared again as it downgrades back to gentoo-tree, etc.
>>
>> So I'm asking what's up.
> Thats quite simple, 4.3.2 stay masked until we stable 4.3.1

It seems 4.3.2 got unmasked but 4.3.1 is still ~arch :*)

> > Thats quite simple, 4.3.2 stay masked until we stable 4.3.1
>
> It seems 4.3.2 got unmasked but 4.3.1 is still ~arch :*)
> ,
Not true sunshine. 4.3.1 is stable on amd64, which is the most arch we all
care about ;P