Thanks for the KDE SC 4.4 release
by Roderick Johnstone
Hi
Our research group is now updated to the recent KDE SC 4.4 release
through the Fedora 12 updates. Its working really well for us.
I just wanted to say a big thank you to all the packagers, testers and
bug fixers who brought this to Fedora. This community is awesome!
Roderick
14 years, 2 months
More nepomuk/kmail problems and workarounds
by Anne Wilson
I'd hate to be the ones trying to track down these issues, because not
everyone is affected with any of them, as far as I can see. Anyway, the latest
updates broke my Kontact, so here's what I've gathered as work-arounds.
Since the update, Kontact will not start, and it appears to be unrelated to
mysql or nepomuk.
First work-around - all the apps run as stand-alone apps, so it's possible to
get by while the cause of this is being sought.
KMail still suffers from delays and freezes when sending, the fix for which is
promised in 4.4.1. It's possible to work around this as a temporary measure.
Second workaround - close kontact or kmail and kaddressbook if you are running
stand-alone apps. Disable strigi in systemsettings. Stop nepomuk, delete the
database and restart nepomukserver. The actual commands you need are (as
user)
qdbus org.kde.NepomukServer /nepomukserver org.kde.NepomukServer.quit
rm -r .kde/share/apps/nepomuk
nepomukserver
This will, of course, wipe out all the database, including any tags you've
added. In theory, I understand that it's possible to do a more selective wipe
of the database. If this matters to you you can find the instructions at
http://techbase.kde.org/Development/Tutorials/Metadata/Nepomuk/TipsAndTri...
indexed_data
Hope this helps some of you :-)
Anne
--
New to KDE4? - get help from http://userbase.kde.org
Just found a cool new feature? Add it to UserBase
14 years, 2 months
RE: Have I missed fix for 4.4 login problem?
by Dwight Paige
Original post poorly written. Sorry for that.
The problem is that AutoLoginDelay=10 doesn't work as of KDE 4.4.
Problem also occurs in openSuSE 11.2 and Mandriva 2010.0 all are
x86_64. AutoLogin immediately works but when I set 'AutoLoginDelay=10'
in 'kdmrc' upon logging in login screen freezes and no user can login.
When login screen is reached user MUST very quickly hit enter [even
though AutoLoginEnable=true] OR login screen freezes and no user can login.
Was wondering if anyone else was having this problem?
Bug report filed upstream:
https://bugs.kde.org/show_bug.cgi?id=229475
--
Thanks,
Dwight Paige
If the only tool you have is a hammer, you tend to see every problem as a nail.
14 years, 2 months
SWG Spins discussion and follow-up actions
by Matt Domsch
FYI, these were the notes from last Monday's Board Strategic Working
Group meeting, where your responses to the Board's questions were
noted and discussed. From this, there are several specific actions we
would like to see taken:
# the problems hampering Spins due to long GNOME dependency chain
requirements has a ticket open for FESCo to discuss.
https://fedorahosted.org/fesco/ticket/345
# hosting space for Spins for direct http downloads will be made available by Infrastructure.
Each spin should file a request for space with infrastructure.
http://fedoraproject.org/wiki/Infrastructure/RFR
# being able to offer AutoQA
individual Spins should get involved with QA Team to ensure their
needs are addressed as well as those of the rest of the Project.
This is highly dependent on Spins owners contributing to the QA
methodologies and even direct test efforts - QA is already feeling
overwhelmed, and we need to scale this process out across more volunteers.
# banners on get.fp.o -> spins.fp.o
https://fedorahosted.org/fedora-websites/ticket/16
People with web site building experience are asked to participate in
the websites team to remove "waiting on someone who can" as a possible
bottleneck.
I thank you all for your valuable input and continuing contributions
to Fedora.
Thanks,
Matt
----- Forwarded message from John Poelstra <poelstra(a)redhat.com> -----
Date: Mon, 01 Mar 2010 16:17:37 -0800
From: John Poelstra <poelstra(a)redhat.com>
To: advisory-board(a)lists.fedoraproject.org
Subject: Board SWG Meeting 2010-03-01 Recap
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.9.1.7) Gecko/20100120 Fedora/3.0.1-1.fc12 Thunderbird/3.0.1
https://fedoraproject.org/wiki/Meeting:Board_strategic_working_group_2010...
== Roll Call ==
* Attendees: John Poelstra, Paul Frields, Chris Tyler, Mike McGrath,
Colin Walters, Matt Domsch
* Notes from last meeting:
https://fedoraproject.org/wiki/Meeting:Board_strategic_working_group_2010...
== Spins Work ==
* Background:
** Matt and Colin have been collecting feedback to questions asked
**
https://fedoraproject.org/wiki/User:Walters/SpinsSigsRemixes_TargetAudience
**
https://fedoraproject.org/wiki/User:Walters/SpinsSigsRemixes_ChangeDistri...
** http://lists.fedoraproject.org/pipermail/spins/2010-February/000996.html
** https://fedoraproject.org/wiki/User:Mdomsch/SWG_Spins
* Each spin producing group does believe they can and should define a
target audience
* John: would it help clarify our message to refer to the live gnome
desktop as the ''default offering'' rather than referring to it as a spin?
** Paul: Spins were initially conceived as a range of things the
community can produce that are alternatives to what we feel must be
created, or add-ons that narrowly focus on special use cases
* Matt: Rel-eng sits in the middle of the spin creation process right
now -- a couple communication breakdowns have happened over time,
sometimes spin producers didn't know their spin was being built
** Matt: semi-OT -- at some point need to reconsider the question of who
builds the spins. Does it always have to be Release Engineering?
** Paul: more narrowly aimed spins (FEL, Games, ...) seem to nail their
use cases quite well
* Top of mind problem seems to be some dependency chains
(system-config-keyboard), whether or not that is the most serious
problem or not isn't clear
* '''PAIN POINT IDENTIFIED''': Dependency chain requirements cause
alternate desktop spins to still pull in a large portion of the GNOME stack.
** '''NEXT STEPS''': Mike will file ticket with FESCo requesting they
look at dependency chain requirements. This could be a Fedora
Engineering Services task.
** Colin willing to look at helping with dependency chain issues
** ''TICKET''': https://fedorahosted.org/fesco/ticket/345
* '''NON PAIN POINT''': Spins SIG does feel that resolution processes
have been working well when they're needed.
* Resources:
** Infrastructure now has the ability to host additional content,
including spins. This has been a long time incoming, and needs to be
implemented and announced, but the capacity is there now.
** Ambassadors who want to pass out specific spins can make requests for
monetary resources to CommArch, to be evaluated in the scope of media
requests and budget.
*** The Board is not taking a stance on what medias should be produced
for any particular event.
* Not sure what to do with feedback from survey work that showed that
some people don't want the board to help or ask questions about how they
can help
=== Next Steps & Positive Outcomes ===
# dependency chain requirements
#* https://fedorahosted.org/fesco/ticket/345
# hosting space for Spins
#* Each spin should file a request for space with infrastructure
# (tentative) being able to offer AutoQA
#* individual Spins should get involved with QA Team to ensure their
needs are addressed as well as those of the rest of the Project.
# banners on get.fp.o
#* https://fedorahosted.org/fedora-websites/ticket/16
# Update wiki pages for information collected
== Default Offering ==
* https://fedoraproject.org/wiki/User:Pfrields/Current_default_offering
* https://fedoraproject.org/wiki/User:Pfrields/Different_default_offering
* Give feedback to Paul by tomorrow, 2010-03-02
* Paul will send to Board for approval on 2010-03-02
== Topics and plan for next meeting ==
* John/Chris will take up topic of "What is a target audience?"
* Meet next week, 2010-03-08 at 20:00 UTC (3:00pm EST/12:00pm PST)
_______________________________________________
advisory-board mailing list
advisory-board(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/advisory-board
----- End forwarded message -----
14 years, 2 months
Re: Harmless KDE feature upgrades - yeah right
by Kevin Kofler
Petrus de Calguarium wrote:
> I think it is unnecessary to provide the latest
> releases for any releases except the current and
> rawhide. If people don't bother to upgrade to the
> current release, then they obviously don't care
> to run a cutting edge system, so there is no
> point in providing it at the expense of a whole
> lot of work. It only takes an evening to download
> a live cd, install it, and do some rudimentary
> configurations. The rest can be achieved as one
> actually uses the system, so there is no excuse
> for not running the latest release. Considering
> that a lot of the work is done by volunteers (or
> are you, all you redhat/fedora people?), this is
> a fabulous system all for free and not even money
> can purchase anything better.
[snip]
> Definitely, old releases should receive only the
> necessary bug fixes, not new features. This is a
> terrible waste of manpower.
It's actually almost no extra work to build the updates also for the
previous stable release. We have to build them for the current stable
anyway. It just means doing the usual routine (copying the specfile,
committing and running make tag and make build BUILD_FLAGS=--nowait) twice
instead of once (and even the commit can be done for both at once by
committing in the parent directory), which takes only a few seconds extra,
the builds run in parallel. Doing the updates for only one Fedora release
would not be a significant saving of time or effort. Actually actively
fixing bugs in the old, no longer supported by upstream branch would
actually be MORE work.
> To save man-hours, it might be better to scrap
> kde-redhat and just stick to updates and updates-
> testing. I would enable updates-testing (and
> sometimes I even pull something off koji
> manually), but many would stick to the safer
> route of just enabling updates.
kde-redhat is also very little work, usually just rebuilding stuff from
Rawhide for the unstable repository, it's basically handled by 1 person (Rex
Dieter) and it has been extremely helpful in helping to get prereleases
tested and thus to prevent some disasters with the update to the actual
release.
Kevin Kofler
14 years, 2 months
Translations
by Tomas Straupis
Hello
What is the procedure with translations of applications and documentation?
If translations have been submitted to svn they should appear in
next KDE release or are there some additional obstacles?
I was doing some documentation translations in Lithuanian language
but all docs (handbooks) are still in English... Translations have
been submitted to trunk before branching KDE4.4.
$ env | grep LANG
LANG=lt_LT.UTF-8
# rpm -qa | grep Lithuanian
kde-l10n-Lithuanian-4.4.0-1.fc12.noarch
Thank you
--
Tomas Straupis
14 years, 2 months
Re: Harmless KDE feature upgrades - yeah right
by Jaroslav Reznik
On Thursday 04 March 2010 13:13:18 Rahul Sundaram wrote:
> On 03/04/2010 05:13 PM, Juha Tuomala wrote:
> > This is exactly kind off stuff I don't have time now to solve,
> > since I need to work. If such upgrade would have been put to
> > next coming release, I could have upgraded when I have time,
> > some weekend - it would not interrupted my working and ruin my
> > day.
>
> Yes and it does happen now and then that updates like these cause end
> users some pain and while some users love to tinker and play with new
> features others see it as a hindrance even if it is purely enhancement
> with no regressions because even UI changes cause disruption in workflow
> setting aside all the possibility of regressions and I dont believe that
> Fedora has the right balance between innovation and stability (not
> merely robustness but any change for that matter) at the moment (CentOS
> is far removed and rawhide is far too bleeding edge)
>
> Whether it would be a separate backports repo or merely some more
> conservativeness in our update stream needs to be discussed and the
> current discussion has brought up very polarised opinions and at this
> point it would be useful to discuss detailed proposals than continuously
> repeating the same points in a circle
>
> For your specific case please file bug reports
We (some KDE SIG people) are currently working on so called stability proposal
[1]. That means one bigger update per release as KDE schedules are not in sync
with Fedora releases. So this means - Fn release of Fedora is getting updates
and users will get fresh software (rawhide is not an option), Fn-1 is
considered as stable, without any "mayor" updates but it's still quite fresh
so users don't have (are not forced) to switch to brand new release, probably
breaking more than just update.
One of reasons we can be now much more conservative is that KDE is now in very
good shape and few releases ago we couldn't let users with for example 4.0,
4.1 releases. Now it's not so important to do big steps as changes are not so
visible
FKDESCo is going to vote probably on next meeting, Tuesday 09 14:00 UTC. So
please, Fedora KDE users - comment these changes! We're working for you!
CC'ing kde(a)lists.fpo.
[1] https://fedoraproject.org/wiki/SIGs/KDE/Stability_Proposal
Jaroslav
> Rahul
--
Jaroslav Řezník <jreznik(a)redhat.com>
Software Engineer - Base Operating Systems Brno
Office: +420 532 294 275
Mobile: +420 731 455 332
Red Hat, Inc. http://cz.redhat.com/
14 years, 2 months
Kget humour?
by Petrus de Calguarium
I was just downloading a large file with kget. I
was cooking supper and 15-20 minutes later, when
I got back to the computer, there was a kget
message on the screen, roughly as follows:
"You have a download in progress. Delete it and
download again?"
And below were buttons, 'yes', 'no' and 'cancel'.
I pressed 'no' and my download is safe.
Is that supposed to be funny or would it really
have deleted a 1GB download for no reason
whatsoever and downloaded it all over again?
14 years, 2 months
Too much debugging information in KDE
by Jeremy Sanders
Hi - With the new update to KDE, the applications appear to print much more
debugging information to the console, most of which is useless to the user.
This is a problem when trying to run applications from the command line
(e.g. okular when using LaTeX) as simple operations on the KDE application
spawn reams of debugging on the user's console.
Is there some way of switching it off? I notice most of this goes to
.xsession-errors anyway, so it doesn't seem worthwhile duplicating it all.
Thanks
Jeremy
14 years, 2 months
KFileDialog replacing QFileDialog
by Jeremy Sanders
I've filed a bug here listing problems when some part of the KDE/Qt system
appears to be replacing QFileDialog (the Qt file dialog) with KFileDialog
(the KDE file dialog) in my Qt/PyQt application:
https://bugzilla.redhat.com/show_bug.cgi?id=570090
I've filed this under Qt, but maybe someone knows whether it is KDE doing
this, and whether it is possible to turn off this (currently) buggy
behaviour, at least for my application.
Thanks
Jeremy
14 years, 2 months
