Re: KDE Dev Platform Status
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 26, 2007, at 12:08 PM, Thomas Zander wrote: > On Monday 26. November 2007 17:53:17 Dirk Mueller wrote: >> On Sunday 25 November 2007, Sebastian Kuegler wrote: >>> We should tap into coolo's experience here. My proposal would be >>> to have >>> one last BIC (but SC) monday. That should get us the critical >>> stuff/fallout, and not break things. I hope. >> >> Aha. Why did we release the platform if we break BIC one last >> time? Either >> we keep BC or we don`t. > > Why can be answered as 2 different things; > > 1) Because there are some showstoppers that can be fixed in a MUCH > better way > when BC is ignored. > > 2) Because there is nobody 'out there' that will find it a really > big problem > if we do break BC before we make a final release for the simple > reason that > this exact released version will not be in any distro's official > release. > But we've already made a final release of the Dev Platform. *That's the whole point!* > So, the real question is why not allow this for critical bugfixes. > (and those > only, obviously or else we'll need one in 2 weeks again). > No, the real question is why can't people just show some restraint and live with what we got since they apparently couldn't be bothered to either get up and fix it before the release or let somebody know that they've got things they want to fix and ask for a small delay. > ps. one such bug I'm thinking about is the kactioncollection one > (151421) - -- Matt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHS3YTA6Vv5rghv0cRArj1AJ4mtU1owTU06Mg+mLQZ4YeeS+nctQCfRgkl 2hVHfLJ1YieHmbS+6Jg4Yfc= =w0Pk -END PGP SIGNATURE- ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Removing kregexpedit and kcalc
A Dilluns 26 Novembre 2007, Albert Astals Cid va escriure: > A Dilluns 26 Novembre 2007, vàreu escriure: > > On Monday 26 November 2007, Albert Astals Cid wrote: > > > As i said, it enters and endless loop on start, so i did not test > > > anything. > > > > > > KNumber::operator quint64(void) const seems to call itself if you are > > > on a 64 bit machine like i am. > > > > So, how about debugging and fixing that issue? > > My mood is past the line of trying to debug and fix programs i don't know > and i don't care, sorry about that. Someone fixed it starting on amd64, now i can reproduce http://bugs.kde.org/show_bug.cgi?id=152713. Albert > > Albert > > > I don`t like to drop kcalc now. For 4.1 we can decide for something else > > if there is an alternative. > > > > A (IMHO) better solution would be to get rid of KNumber and use the C++ > > library for big numbers. Also fixes a license problem (because GMP is > > GPLv3, so legally its impossible to ship KCalc at the moment). > > > > > > Dirk > > ___ > release-team mailing list > release-team@kde.org > https://mail.kde.org/mailman/listinfo/release-team ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Removing kregexpedit and kcalc
A Dilluns 26 Novembre 2007, vàreu escriure: > On Monday 26 November 2007, Albert Astals Cid wrote: > > As i said, it enters and endless loop on start, so i did not test > > anything. > > > > KNumber::operator quint64(void) const seems to call itself if you are on > > a 64 bit machine like i am. > > So, how about debugging and fixing that issue? My mood is past the line of trying to debug and fix programs i don't know and i don't care, sorry about that. Albert > > I don`t like to drop kcalc now. For 4.1 we can decide for something else if > there is an alternative. > > A (IMHO) better solution would be to get rid of KNumber and use the C++ > library for big numbers. Also fixes a license problem (because GMP is > GPLv3, so legally its impossible to ship KCalc at the moment). > > > Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Removing kregexpedit and kcalc
On Monday 26 November 2007, Dirk Mueller wrote:
> > As i said, it enters and endless loop on start, so i did not test
> > anything.
> >
> > KNumber::operator quint64(void) const seems to call itself if you
> > are on a 64 bit machine like i am.
>
> So, how about debugging and fixing that issue?
Attached patch makes it work for me, but I have no idea if this is the
right way to do it or not.
Andras
--
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org
Index: kcalcdisplay.cpp
===
--- kcalcdisplay.cpp (revision 741923)
+++ kcalcdisplay.cpp (working copy)
@@ -38,6 +38,7 @@
#include "kcalcdisplay.h"
#include "kcalcdisplay.moc"
+
KCalcDisplay::KCalcDisplay(QWidget *parent)
:QLabel(parent), _beep(false), _groupdigits(false), _button(0), _lit(false),
_num_base(NB_DECIMAL), _precision(9),
@@ -303,7 +304,7 @@
being set with "setAmount"). Return value is the new base. */
int KCalcDisplay::setBase(NumBase new_base)
{
- CALCAMNT tmp_val = static_cast(getAmount());
+ CALCAMNT tmp_val = getAmount();
switch(new_base)
{
signature.asc
Description: This is a digitally signed message part.
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: KDE Dev Platform Status
On Monday 26. November 2007 17:53:17 Dirk Mueller wrote: > On Sunday 25 November 2007, Sebastian Kuegler wrote: > > We should tap into coolo's experience here. My proposal would be to have > > one last BIC (but SC) monday. That should get us the critical > > stuff/fallout, and not break things. I hope. > > Aha. Why did we release the platform if we break BIC one last time? Either > we keep BC or we don`t. Why can be answered as 2 different things; 1) Because there are some showstoppers that can be fixed in a MUCH better way when BC is ignored. 2) Because there is nobody 'out there' that will find it a really big problem if we do break BC before we make a final release for the simple reason that this exact released version will not be in any distro's official release. So, the real question is why not allow this for critical bugfixes. (and those only, obviously or else we'll need one in 2 weeks again). ps. one such bug I'm thinking about is the kactioncollection one (151421) -- Thomas Zander signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Removing kregexpedit and kcalc
On Monday 26 November 2007, Albert Astals Cid wrote: > As i said, it enters and endless loop on start, so i did not test anything. > > KNumber::operator quint64(void) const seems to call itself if you are on a > 64 bit machine like i am. So, how about debugging and fixing that issue? I don`t like to drop kcalc now. For 4.1 we can decide for something else if there is an alternative. A (IMHO) better solution would be to get rid of KNumber and use the C++ library for big numbers. Also fixes a license problem (because GMP is GPLv3, so legally its impossible to ship KCalc at the moment). Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE Dev Platform Status
On Sunday 25 November 2007, Sebastian Kuegler wrote: > We should tap into coolo's experience here. My proposal would be to have > one last BIC (but SC) monday. That should get us the critical > stuff/fallout, and not break things. I hope. Aha. Why did we release the platform if we break BIC one last time? Either we keep BC or we don`t. Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Removing kregexpedit and kcalc
A Dilluns 26 Novembre 2007, Richard Moore va escriure: > I've just tested trunk and if I remove the kcalc 16x16 svgz that is > causing a crash on startup in QSvgRenderer then kcalc can add fine. > Have you actually tested any of the problems in this report or do I > need to go through them one by one? As i said, it enters and endless loop on start, so i did not test anything. KNumber::operator quint64(void) const seems to call itself if you are on a 64 bit machine like i am. Albert > > Rich. > > On 11/25/07, Richard Moore <[EMAIL PROTECTED]> wrote: > > On 11/25/07, Albert Astals Cid <[EMAIL PROTECTED]> wrote: > > > A Diumenge 25 Novembre 2007, Richard Moore va escriure: > > > > Removing kcalc seems daft to me. It's pretty much essential for a > > > > sane desktop. Are you saying there are some problems with it that > > > > need fixing or just playing jobsworth? > > > > > > Problem i have: > > > * I can't not start it, it ends up in an inifite loop > > > > I'm getting a segfault on startup here, but that seems to be a > > kiconloader issue. > > > > > Problem other people has: > > > * It doesn't know how to add > > > http://bugs.kde.org/show_bug.cgi?id=152713 > > > > The problems in that bug seem to be more display related. > > > > > Real problem: > > > * No maintainer > > > > > > No playing here, i'm just not in mood. > > > > I'm not playing either, I think we need a calculator. I'll try to look > > into what's broken it. > > > > Rich, > > ___ > release-team mailing list > release-team@kde.org > https://mail.kde.org/mailman/listinfo/release-team ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
