Re: Possible problems with Intel drivers in 4.5.0 release
Em Terça-feira 03 Agosto 2010, às 08:02:27, Will Stephenson escreveu: > > missing hardware I am not able to investigate it. > > Do > you know what intel hardware and intel driver combination the test fails on? > On my openSUSE 11.3 machine with intel driver 2.12.0 and 945GM chipset, > openGL rendering is definitely working - when I switch to XRender I notice > that Blur stops working on widget backgrounds. > > Will > > > ___ > release-team mailing list > release-team@kde.org > https://mail.kde.org/mailman/listinfo/release-team > What i have here: xorg-x11-drv-intel-2.11.0-5 kernel 2.6.33.6 xorg-x11-server-Xorg-1.8.2 Intel x4500 HD ( But not sure on that ) -- Helio Chissini de Castro South America and Brazil Primary Contact KDE Developer since 2002 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Possible problems with Intel drivers in 4.5.0 release
Martin, what you need to test ? I have a notebook with this current issue ( Fedora 13 ) and happens that even Meego SDk not works anymore, so is indeed a Intel issue. I have another machine to test, desktop, but remote one. []'s Em Segunda-feira 02 Agosto 2010, às 15:59:24, Martin Gräßlin escreveu: > Hi Release-Team, > > I know that the release is scheduled for tomorrow, nevertheless I want to > make > you aware of a possible problem with Intel graphics cards and compositing. > > I think I first have to explain a little bit: KWin uses a test to determine > if > OpenGL compositing is working during the startup. This seems to fail for some > Intel drivers since some time. It used to work and the code has not changed, > so it is most likely a driver bug. I was first made aware of this problem at > Akademy. Due to the fact that I do not own Intel hardware I was unable to > reproduce or try to fix the issue. > > Up to 4.4 KWin just disabled compositing if this check during startup failed. > In the 4.5 development cycle it was changed to fall back to XRender > compositing. The idea behind it was that you get translucancy when starting > from live cd or running in a virtual machine. It was not meant for the case > that the OpenGL driver causes an incorrect self check failure. > > This fallback to XRender causes slowness of the system and some effects not > working. Furthermore the complete UI says that it is using OpenGL compositing > although in truth XRender is used. > > When I was made aware of this problem with Intel drivers I reverted the > fallback to XRender both in trunk and branch (svn revs 1148315 and 1148316). > Unfortunately I missed one change (the original commit changed more than just > the fallback) which I found by pure luck this weekend (svn commit 1157978). > It's confirmed that this commit is now finally working: compositing is > disabled at startup. By disabling the functionality checks in the advanced > compositing preferences it is possible to get OpenGL compositing working > again. > > Now the question is what to do with this commit. Due to the fact that I > missed > this one line KWin is now saying that it disables compositing but in truth is > falling back to XRender. I see three possible solutions: > > 1. We ignore it. This might result in many complaints about slow KWin and > that > effects are not working any more (e.g. cube, coverswitch, blur, etc.). We > will > have many complaints about slow KWin anyway due to the enabling of blur and > the fact that many drivers are too bad for it. On the other hand we had no > bug > report to this issue. I only heard about this problem by fellow KDE > developers, which might be related to the fact that we have more recent > drivers/Xorg than most of our users. > 2. We backport this patch to 4.5.0. This means a lot of work due to the > schedule (sorry for writing that late, I had to think about this issue for > one > day) and will cause users not be able to use desktop effects any more. But it > would be the cleanest one. > 3. We backport to 4.5.1. This would mean a behavior change between 4.5.0 and > 4.5.1 which I would not like. > > To summarize: I am not happy with any of the three options I came up with. > And > I do not know what to do about it. Given that the release is tomorrow I guess > it's only possible to choose between option 1 and 3, while I think option 2 > would be the best. I think it's better to disable compositing instead of slow > compositing. So the question is, if we should backport the commit for 4.5.1. > > The best solution would be to fix the failing self check. But due to missing > hardware I am not able to investigate it. > > Sorry for writing that late > Martin Gräßlin > -- Helio Chissini de Castro South America and Brazil Primary Contact KDE Developer since 2002 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kmldonkey version problem
On Sunday 28 February 2010 21:14:08 Christian Mangold wrote: > On Friday 19 February 2010 10:06:08 you wrote: > > At KDE SC 4.4.1 which will appear in two weeks or so, we will ship 2.0.5. > > I don't care much how ubuntu calls it, I assume that will be fixed to > > after this change. > > As there are no extragear tarballs on ktown after tagging 4.4.1, where can > we get the 2.0.5 tarball? I am sorry, if this is obvious, but I have no > experience with extragear releases. > > > Regards Christian Is not done yet. Tarballs will appears in stable/src/extragear []'s -- Helio Chissini de Castro South America and Brazil Primary Contact KDE Developer since 2002 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: getting rid of kde-l10n
On Tuesday 02 February 2010 17:41:43 Rex Dieter wrote: > Hear me out. :) > > I'm not proposing anything yet, but would like to hear about the > pros/cons of > 1. status quo: shipping translations separately to software > > 2. shipping translations alonside (ie, in the same release tarballs) > the software. > > How hard would it be to work toward something closer to 2 for KDE SC? > > -- Rex For me i see only one clear reason where this situation can provide some benefits, if we go to git path to have per app repository. Otherwise, change current structure is bad bad idea, nothing matter pros/cons, is just change a secular ( yes, comes from last one :-) process. So i would advise to raise this question for l10n team and scm discussion. []'s -- Helio Chissini de Castro South America and Brazil Primary Contact KDE Developer since 2002 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Freeze exemption for PA integration into Phonon
On Wednesday 18 November 2009 18:29:19 Sebastian Kügler wrote: > On Wednesday 18 November 2009 18:41:36 Tom Albers wrote: > > Op Wednesday 18 November 2009 18:10 schreef u: > > > Hi! > > > > > > Colin Guthrie has been working on better integration of PulseAudio in > > > Phonon, but AFAIK it is now too late for getting it into 4.4, without > > > getting and exemption from the freeze. > > > > > > But IMHO (and Eike Hein, who reminded me about this issue :-), distros > > > will most probably just go ahead and patch in coling's work anyways, if > > > it isn't available in KDE itself. > > > > > > The KDE-module in question is kdebase-runtime (and also Phonon itself, > > > but that's another story). > > > > > > Another tiny snag is that it depends on an unreleased version of > > > PulseAudio (because whoever packaged up the last PA release forgot to > > > include coling's work), but I assume spring-release distros will have > > > an up-to-date version, so if we just check for the right PA version > > > while building, we should be OK. > > > > > > Mandriva's latest release already includes coling's work, so it has > > > already received a fair amount of testing. > > > > > > So before you all start going around in circles screaming "pulseaudio > > > pt", if PA isn't available at build-time, all the PA-specific > > > stuff becomes nops (and possibly completely optimized away? I don't > > > have enough compiler-fu). And if Phonon is built with PA integration, > > > but the PA daemon isn't available for some reason (it crashed, or isn't > > > installed, for example), it degrades gracefully. > > > > > > I think this is the truth, the whole truth and nothing but the truth, > > > so help me God, but if I'm wrong, please correct me. :-) > > > > > > Or ask. Or grant an exemption, if you find the kindness in your hearts > > > to do so. > > > > A link to the patches would have been nice ;-) > > > > If there are good, working and tested cmake and ifdefs, I suggest we > > include it now, ship it in the beta and possibily in the first release > > candidate. If we get complains or unsolvable issues we can remove it for > > the final release if needed. > > > > Please wait 24h for other opinions, if noone objects or raises possible > > issues, please merge it in asap, so we can at least have some basic > > testing before we package the beta. > > Good suggestion. +1 > Colin work have my 100% approval. I was there in the integration in Mandriva. I would say "go". -- Helio Chissini de Castro South America and Brazil Primary Contact KDE Developer since 2002 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.3.2 tarballs (try #1) uploaded
Em Sexta-feira 02 de outubro 2009, às 16:45:16, Pierre Schmitz escreveu: > Am Freitag 02 Oktober 2009 16:39:15 schrieb Dirk Mueller: > > Hi, > > > > I just finished the first build of 4.3.2 tarballs. I think some bits in > > kde-l10n are failing, need to look at that now. Tarballs should be > > available in the usual place. > > > > Intended announcement is next week Tuesday. > > > > Greetings, > > Dirk > > The following files are installed by oxygen-icons and kdepim (kmail): > > /usr/share/icons/oxygen/16x16/actions/mail-forwarded-replied.png Humm, i removed those on trunk, but not in branch. Dirk, can you update kdepim tarball to revision 1030630 ? -- Helio Chissini de Castro Mandriva Research and Development ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Qt 4.6 && KDE 4.4.0
Aaron J. Seigo escreveu: > On September 23, 2009, Tom Albers wrote: >> ** Qt 4.6 dependency in trunk ** >> The release team has decided that KDE 4.4.0 will depend on Qt 4.6. To give >> developers the time to work with Qt 4.6, we have decided that from >> Saturday October 10th* trunk will start depending on Qt 4.6. Everyone need >> to update the coming two weeks to that version of Qt. > > since explicit +1'ing is necessary: +1 from me. > > distros _will_ ship KDE 4.3 with Qt 4.6. the performance improvements and > needs of other apps are too great. You mean 4.4 right ? Or future releases of 4.3 ? Mandriva already have the Qt 4.6 packages ready, is just matter to wait final release then we can do proper change. []'s -- Helio Chissini de Castro South America and Brazil Primary Contact KDE Developer since 2002 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.3.0 - we're getting closer
On Monday 20 of July 2009 17:11:00 Dirk Mueller wrote: > Hi, > > I think we should start thinking on wether or not to try with RC3 now or go > straight to 4.3.0. There were around 250 commits since RC2, which is quite > a lot. > > My current gut feeling is that a RC3 is in order, without having looked at > this in detail. Comments? Same here. There are space for an rc3 -- Helio Chissini de Castro Mandriva Research and Development ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: pre-releases of rc1
Aaron J. Seigo escreveu: > hi all ... > > looking at the bugs i'm getting about "rc1", it seems that Arch and Mandriva > have both made "rc1" packages available to their users. don't know if we need > to discuss anything with them, but there you go. > > as sebas noted, this seems to be the usual "push the packages into ultra- > unstable-testing distro repo a few days in advance" thing. so not sure it's > really t much of an issue. they are just trying to get ahead of the curve > so they can release quickly with us. > > maybe a gentle reminder from the release team to be sure that the packages > _are_ up to date when we release and to tell their testers of their ultra- > unstable-testing repo not to report issues until they have packages with the > actual final release? *shrug* Well, we do not released any packages for stable, so users that are using "cooker" are prone to know that whole thing can be broken and that's the goal of that, fix it, discover what is wrong. So, if there are some unhappy Mandriva user blaming the current state, instalation, please rereoute to us, because we know how to deal with then. Talking seriously, there some people that assume that the unstable repository should be stable and for years and it's been a regular discussion on mail lists, so our officila position is, if is cooker, it can be broken and is nobody's fault, not the projects nor even the distro. The users must be aware that it happens. From our part, if this caused any stress, i apologise.. []'s ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.2.5?
Em Sábado 30 de maio 2009, às 07:51:15, Sebastian Kügler escreveu: > > > > That way, distributions and others who cares can get "blessed" backport > > patches of the problems, which is kind of preferred. > > Yep, for grave problems, we might want to consider a 4.2.5, otherwise I > think we should stop at 4.2.4 and fully concentrate on 4.3. Security issues always got CVE and we do a regular patch. I think is highly unlikeable we will have some outstanding issue not detected yet that will force us to provide a full release. []' -- Helio Chissini de Castro Mandriva Research and Development ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.2.5?
Em Sexta-feira 29 de maio 2009, às 13:26:26, Allen Winter escreveu: > Howdy, > > Can we decide now if there will be a 4.2.5 release? > If not, then that saves us some unneeded backporting work. > > Recall we stopped at 4.1.4. > IMO we should stop at 4.2.4. > > Let's decide very soon and I'll communicate the decision to all developers. > > Regards, > Allen I'm ok in stop on 4.2.4 -- Helio Chissini de Castro Mandriva Research and Development ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdebase runtime ioslave freeze exemption request
Em Terça-feira 12 de maio 2009, às 19:08:30, Olivier Goffart escreveu: > Le Mandag 11 mai 2009, Helio Chissini de Castro a écrit : > > Hello guys ! > > > > Since I've got in the middle of the release of Mandriva 2009 Spring, i > > totally forgot the effective base part of lzma patch. > > > > So, attached is the kdebase-runtime patch, it contains no new string in > > code, but has their own doc and .desktop files, which is a translation > > issue. Since is a brand new thing and not touch any of current components > > functionality, i would like to request if is possible acceptance of this > > one. > > > > Thanks in advance > > I am fine with the code in the new patch. So can i go further and commit ? -- Helio Chissini de Castro KDE Developer Brasil/South America Primary Contact 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: kdebase runtime ioslave freeze exemption request
Em Segunda-feira 11 de maio 2009, às 19:55:05, você escreveu:
> I haven't checked the documentaton, but for the code:
> > Index: kioslave/man/kio_man.cpp
> > ===
> > --- kioslave/man/kio_man.cpp(revisão 966710)
> > +++ kioslave/man/kio_man.cpp(cópia de trabalho)
> > @@ -70,6 +70,10 @@
> > pos -= 4;
> > else if ( name->indexOf(".bz", -3) != -1 )
> > pos -= 3;
> > +else if ( name->indexOf(".lzma", -5) != -1 )
> > +pos -= 5;
> > +else if ( name->indexOf(".xz", -3) != -1 )
> > +pos -= 3;
> >
> > if ( pos > 0 )
> > pos = name->lastIndexOf('.', pos-1);
> > @@ -1317,6 +1321,10 @@
> > end -= 2;
> > else if ( len >= 4 && strcmp( end-3, ".bz2" ) == 0 )
> > end -= 4;
> > +else if ( len >= 4 && strcmp( end-4, ".lzma" ) == 0 )
>
> You meant len >=5
Fixed in new patch
> > +end -= 5;
> > + else if ( len >= 3 && strcmp( end-2, ".xz" ) == 0 )
> > +end -= 3;
> >
> > while ( end >= begin && *end != '.' )
> > end--;
>
> And check for identation problems.
Fixed in new patch attached
--
Helio Chissini de Castro
KDE Developer
Brasil/South America Primary Contact
Index: doc/kioslave/xz/index.docbook
===
--- doc/kioslave/xz/index.docbook (revisão 0)
+++ doc/kioslave/xz/index.docbook (revisão 0)
@@ -0,0 +1,37 @@
+
+
+
+]>
+
+
+xz / lzma
+
+
+&Lauri.Watts; &Lauri.Watts.mail;
+
+
+
+
+Xz is a compression program
+
+The xz kioslave is not directly usable, and is intended for use
+as a filter. For example, the tar kioslave can filter a file through
+the xz kioslave, in order to display the contents of a tar.lzma or tar.xz
+ file directly in a &konqueror; window.
+
+If you click on a file compressed with a .lzma or tar.xz
+ in &konqueror;, this kioslave is used to
+uncompress it and display it as a normal (uncompressed) file.
+
+If you are a developer, and would like to use the xz filter,
+you can find documentation on using kioslaves at http://developer.kde.org";>http://developer.kde.org
+
+ See the manual: xz.
+
+
+
Index: doc/kioslave/xz/CMakeLists.txt
===
--- doc/kioslave/xz/CMakeLists.txt (revisão 0)
+++ doc/kioslave/xz/CMakeLists.txt (revisão 0)
@@ -0,0 +1,3 @@
+### install files ###
+kde4_create_handbook(index.docbook INSTALL_DESTINATION ${HTML_INSTALL_DIR}/en SUBDIR kioslave/xz)
+
Mudanças de propriedades em: doc/kioslave/xz/CMakeLists.txt
___
Added: svn:eol-style
+ native
Index: kioslave/filter/xz.protocol
===
--- kioslave/filter/xz.protocol (revisão 0)
+++ kioslave/filter/xz.protocol (revisão 0)
@@ -0,0 +1,11 @@
+[Protocol]
+exec=kio_filter
+protocol=xz
+archiveMimetype=application/x-xz
+determineMimetypeFromExtension=false
+input=stream
+output=stream
+reading=true
+source=false
+DocPath=kioslave/xz.html
+Icon=package-x-generic
Index: kioslave/filter/lzma.protocol
===
--- kioslave/filter/lzma.protocol (revisão 0)
+++ kioslave/filter/lzma.protocol (revisão 0)
@@ -0,0 +1,11 @@
+[Protocol]
+exec=kio_filter
+protocol=lzma
+archiveMimetype=application/x-lzma
+determineMimetypeFromExtension=true
+input=stream
+output=stream
+reading=true
+source=false
+DocPath=kioslave/xz.html
+Icon=package-x-generic
Index: kioslave/filter/CMakeLists.txt
===
--- kioslave/filter/CMakeLists.txt (revisão 966970)
+++ kioslave/filter/CMakeLists.txt (cópia de trabalho)
@@ -2,6 +2,9 @@
macro_optional_find_package(BZip2)
macro_log_feature(BZIP2_FOUND "BZip2" "A high-quality data compressor" "http://www.bzip.org"; FALSE "" "Provides the ability to read and write bzip2 compressed data files in the filter kioslave.")
+macro_optional_find_package(LibLZMA)
+macro_log_feature(LIBLZMA_FOUND "LZMA/XZ" "A very high compression ratio data compressor" "http://tukaani.org/xz/"; FALSE "" "Provides the ability to read and write xz compressed data files.")
+
### next target ###
set(kio_filter_PART_SRCS filter.cc )
@@ -22,3 +25,6 @@
install( FILES bzip.protocol bzip2.protocol DESTINATION ${SERVICES_INSTALL_DIR} )
endif(BZIP2_FOUND)
+if(LIBLZMA_FOUND)
+install( FILES lzma.pro
kdebase runtime ioslave freeze exemption request
Hello guys !
Since I've got in the middle of the release of Mandriva 2009 Spring, i totally
forgot the effective base part of lzma patch.
So, attached is the kdebase-runtime patch, it contains no new string in code,
but has their own doc and .desktop files, which is a translation issue.
Since is a brand new thing and not touch any of current components
functionality, i would like to request if is possible acceptance of this one.
Thanks in advance
--
Helio Chissini de Castro
KDE Developer
Brasil/South America Primary Contact
Index: doc/kioslave/xz/index.docbook
===
--- doc/kioslave/xz/index.docbook (revisão 0)
+++ doc/kioslave/xz/index.docbook (revisão 0)
@@ -0,0 +1,37 @@
+
+
+
+]>
+
+
+xz / lzma
+
+
+&Lauri.Watts; &Lauri.Watts.mail;
+
+
+
+
+Xz is a compression program
+
+The xz kioslave is not directly usable, and is intended for use
+as a filter. For example, the tar kioslave can filter a file through
+the xz kioslave, in order to display the contents of a tar.lzma or tar.xz
+ file directly in a &konqueror; window.
+
+If you click on a file compressed with a .lzma or tar.xz
+ in &konqueror;, this kioslave is used to
+uncompress it and display it as a normal (uncompressed) file.
+
+If you are a developer, and would like to use the xz filter,
+you can find documentation on using kioslaves at http://developer.kde.org";>http://developer.kde.org
+
+ See the manual: xz.
+
+
+
Index: doc/kioslave/xz/CMakeLists.txt
===
--- doc/kioslave/xz/CMakeLists.txt (revisão 0)
+++ doc/kioslave/xz/CMakeLists.txt (revisão 0)
@@ -0,0 +1,3 @@
+### install files ###
+kde4_create_handbook(index.docbook INSTALL_DESTINATION ${HTML_INSTALL_DIR}/en SUBDIR kioslave/xz)
+
Mudanças de propriedades em: doc/kioslave/xz/CMakeLists.txt
___
Added: svn:eol-style
+ native
Index: kioslave/filter/xz.protocol
===
--- kioslave/filter/xz.protocol (revisão 0)
+++ kioslave/filter/xz.protocol (revisão 0)
@@ -0,0 +1,11 @@
+[Protocol]
+exec=kio_filter
+protocol=xz
+archiveMimetype=application/x-xz
+determineMimetypeFromExtension=false
+input=stream
+output=stream
+reading=true
+source=false
+DocPath=kioslave/xz.html
+Icon=package-x-generic
Index: kioslave/filter/lzma.protocol
===
--- kioslave/filter/lzma.protocol (revisão 0)
+++ kioslave/filter/lzma.protocol (revisão 0)
@@ -0,0 +1,11 @@
+[Protocol]
+exec=kio_filter
+protocol=lzma
+archiveMimetype=application/x-lzma
+determineMimetypeFromExtension=true
+input=stream
+output=stream
+reading=true
+source=false
+DocPath=kioslave/xz.html
+Icon=package-x-generic
Index: kioslave/filter/CMakeLists.txt
===
--- kioslave/filter/CMakeLists.txt (revisão 966710)
+++ kioslave/filter/CMakeLists.txt (cópia de trabalho)
@@ -2,6 +2,9 @@
macro_optional_find_package(BZip2)
macro_log_feature(BZIP2_FOUND "BZip2" "A high-quality data compressor" "http://www.bzip.org"; FALSE "" "Provides the ability to read and write bzip2 compressed data files in the filter kioslave.")
+macro_optional_find_package(LibLZMA)
+macro_log_feature(LIBLZMA_FOUND "LZMA/XZ" "A very high compression ratio data compressor" "http://tukaani.org/xz/"; FALSE "" "Provides the ability to read and write xz compressed data files.")
+
### next target ###
set(kio_filter_PART_SRCS filter.cc )
@@ -22,3 +25,6 @@
install( FILES bzip.protocol bzip2.protocol DESTINATION ${SERVICES_INSTALL_DIR} )
endif(BZIP2_FOUND)
+if(LIBLZMA_FOUND)
+install( FILES lzma.protocol xz.protocol DESTINATION ${SERVICES_INSTALL_DIR} )
+endif(LIBLZMA_FOUND)
Index: kioslave/info/kde-info2html
===
--- kioslave/info/kde-info2html (revisão 966710)
+++ kioslave/info/kde-info2html (cópia de trabalho)
@@ -39,6 +39,10 @@
# March 9 2003 Add support for browsing by file. by Luis Pedro Coelho
# June 11 2003 Update the layout of the sides to the new infopageslayout.
# by Sven Leiber
+# July 22 2008 Add support for lzma.
+# by Per Øyvind Karlsen
+# January 8 2009Update lzma support for new xz tool and format.
+# by Per Øyvind Karlsen
#
#---
@@ -147,6 +151,10 @@
if ($DirFileName =~ m/.info.bz2$/ ) {
open DIR, "-|", "bzcat", $DirFileName;
}
+ elsif ($DirFileName =~ m/.info.(lzma|xz)$/ ) {
+ open DIR, "-|", "xzcat", $DirFileName;
+ }
+
elsif ($DirFileName =~ m/.inf
Re: moving Tellico l10n into kdereview
Em Segunda-feira 11 de maio 2009, às 13:47:14, Allen Winter escreveu: > On Saturday 09 May 2009 4:44:51 pm Robby Stephenson wrote: > > Hi, > > > > I just moved Tellico from KDE playgorund into kdereview. Based on > > http://techbase.kde.org/Policies/SVN_Guidelines I wasn't sure if any i18n > > or l10n files needed to be moved as well. > > > > 'move /playground/office/tellico to /kdereview/tellico' > > Robby, > > We need to decide where tellico belongs. > utils? admin? office? pim? > > Also, do you have an idea yet if you want to go into extragear or the main > KDE modules? The main difference there is if you want to be on your own > release schedule or not. > > These decisions need to be made now, so the corresponding coordinator > can help guide you through the process. extragear has one cood, i.e. me :-P And tellico is a "Office" space candidate []'s -- Helio Chissini de Castro Mandriva Research and Development 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: Detecting Phonon version
Em Quinta-feira 07 de maio 2009, às 11:38:58, Matthias Kretz escreveu: > On Thursday 07 May 2009 15:10:21 Will Stephenson wrote: > > On Tuesday 05 May 2009 14:10:05 Matthias Kretz wrote: > > > So, KDE 4.3 should require Phonon 4.3. Everything else needs to be > > > optional (I already told Marco about this for mplayerthumbs). > > > > What did you tell him? Is he going to hack mplayerthumbs so it doesn't > > require VideoWidget::snapshot() or remove it entirely? Dirk says this > > failure to build kdemm vs phonon 4.3 is blocking 4.3beta1 tarballs. > > His answer is attached. > > Regards, > Matthias I just commited a cmake option to ENABLE_PHONON_API or not, so by default phonon part is not compiled and make time to fix. Tu compile it, just add -DENABLE_PHONON_API=TRUE in cmake configure -- Helio Chissini de Castro KDE Developer Brasil/South America Primary Contact ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: About Kamala
On Segunda-feira 13 de abril 2009 10:19:19 Mauricio Piacentini wrote: > Albert Astals Cid wrote: > > playground still has this meaning but afair we changed extragear to > > "stuff that will be released in its own schedule OR does not fit in what > > we think are essential programs of a desktop" > > > > For the second range of programs there is the config.ini file in > > playground/utils/createtarball that lets you add your program for release > > inside the "extragear release" that happens at the same time of KDE > > releases. > > So in this case I think Kamala can live in extragear, and be released > aligned with KDE. I looked at the tree and could not find a suitable > directory, though. Just to remember, we already do that on extragear, as devel need just have the version updated on the release list, and tarballs are generated every new release, so will be a no brainer step. >Should it be extragear/other, or extragear/misc? > We can later discuss then if our kdegames approach of letting lots of > games in is still valid, given this fact. Maybe we should consider > moving some to extragear/games, which does not exist currently. So let's open the space to a new born. I'm creating space right now even not havin a game inside yet. -- Helio Chissini de Castro Mandriva Research and Development ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Getting ready for KDE 4.2.2
On Monday 30 of March 2009 15:47:44 Dirk Mueller wrote: > On Friday 27 March 2009, Pino Toscano wrote: > > Well, there's still a branches/KDE/4.2/kdebase/runtime/pics/oxygen, which > > also exists in the current 4.2.2 tag. Should it be removed in both > > locations, or kdesupport's used for 4.3? > > The trunk kdesupport version of oxygen-icons appears to be broken with KDE > 4.2, at least the logout buttons are now named differently. > > I think it is the best to remove the seperate tarball and revisit this for > 4.2.3 or 4.3.0, if at all. Agreed for 4.3.0 Let's remain with 4.2.x in same state to avoid we fight per icon missing with oxygen team. 4.3.0 is trunk, so they know now what is missing or not Suggestion for oxygen maintainers is do a clean install to be sure that they have only new icons on his install, and not some leftovers from previous install. This can lead a false impression that everything is on the package []'s -- Helio Chissini de Castro KDE Developer Brasil/South America Primary Contact ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.2.2 tarballs (try #1) uploaded
On Friday 27 of March 2009 09:33:07 Pierre Schmitz wrote: > Am Freitag, 27. März 2009 13:10:30 schrieb Andreas Pakulat: > > Well, then move oxygen-icons from tags/KDE/4.2.2 to > > branches/kdesupport-for-4.2 as it belongs there and then remove > > kdebase/runtime/icons/oxygen from > > branches/KDE/4.2 and retag kdebase. > > The problem is that tags/KDE/4.2.2/oxygen-icons is copied from trunk and > that is not compatible with KDE 4.2. Some icons are missing or are renamed. > > So, I see too solutions here: > 1) move branches/KDE/4.2/kdebase/runtime/pics/oxygen to > branches/kdesupport- for-4.2/oxygen-icons and create the tag in 4.2.2 fro > mthat one > 2) forget about a separate oxygen-icons package in KDE 4.2 and keep it in > kdebase-runtime Independent or move/copy, etc.. i decided go in this way here: Package oxygen tarball Remove oxygen from kdebase-runtime package. If there is some missing icons on oxygen tarball, it's time to throw up on oxygen team to solve the mess. They discussed everything in the internal list and just communicate us when the mess are done. Many of the issues would not exists if they communicate with packagers and dirk *before* take the decision. Now, i expect that they figure out a better way to solve. But i think back to a big kdebase-runtime package now is out of question for me. -- Helio Chissini de Castro KDE Developer Brasil/South America Primary Contact ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.2.2 tarballs (try #1) uploaded
On Sexta-feira 27 Março 2009, Pierre Schmitz wrote: > Am Freitag, 27. März 2009 10:52:59 schrieb Andreas Pakulat: > > Well, trunk/kdesupport is not what you should use for the 4.2 releases. > > kdesupport for 4.2 is in /tags/kdesupport-for-4.2/kdesupport and there's > > no oxygen-icons there. Hence there should be no problem. > > And what is this about: /tags/KDE/4.2.2/oxygen-icons/ > > If this shouldn't be used with 4.2.2 it's fine, but all this is still > confusing. Why is there a oxygen-icons-4.2.2.tar.bz2 anyway if its not > meant to be used with KDE 4.2.2? Pierre is right, kdebase-runtime tarball is wrong, icons still there. -- Helio Chissini de Castro KDE Developer Brasil/South America Primary Contact ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Getting ready for KDE 4.2.2
On Quinta-feira 26 Março 2009, Pino Toscano wrote: > Alle mercoledì 25 marzo 2009, Helio Chissini de Castro ha scritto: > > On Wednesday 25 of March 2009 09:22:47 Dirk Mueller wrote: > > > Hi, > > > > > > KDE 4.2.2 tagging is scheduled for today around 23:59 UTC. I'll > > > probably do this tomorrow morning (my time) though. Please make sure > > > that your fixes are included and backported to 4.2 branch until then. > > > Translation update for KDE 4.2.2 are picked up from > > > branches/stable/l10n-kde4 like usual. if you want a new language to be > > > added to the KDE 4.2.2 released- language list, please let me know. > > > > > > If there are outstanding bugs that must be fixed before 4.2.2, please > > > tag them with the "kde-4.2.2-blocker" keyword in bugzilla and I'll > > > review the list. > > > > Dirk, just don't forget to ping oxygen guys to make package available > > too... > > Isn't the 4.2.x branch still providing Oxygen icons in kdebase/runtime? AFAIK buy last emails even 4.2.2 was splitted -- Helio Chissini de Castro KDE Developer Brasil/South America Primary Contact ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Getting ready for KDE 4.2.2
On Wednesday 25 of March 2009 09:22:47 Dirk Mueller wrote: > Hi, > > KDE 4.2.2 tagging is scheduled for today around 23:59 UTC. I'll probably do > this tomorrow morning (my time) though. Please make sure > that your fixes are included and backported to 4.2 branch until then. > Translation update for KDE 4.2.2 are picked up from > branches/stable/l10n-kde4 like usual. if you want a new language to be > added to the KDE 4.2.2 released- language list, please let me know. > > If there are outstanding bugs that must be fixed before 4.2.2, please tag > them with the "kde-4.2.2-blocker" keyword in bugzilla and I'll review the > list. > > Thanks, > Dirk Dirk, just don't forget to ping oxygen guys to make package available too... []'s -- Helio Chissini de Castro Mandriva Research and Development ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: a self debriefing
On Monday 08 September 2008, Aaron J. Seigo wrote: > some questions i'd suggest asking ourselves (please add your own as well): > > * what has the 6 month cycle won us in terms of real benefit thus far? ( taken out my distro hat here ) I'm fail to see benefits in terms that our primary visible users are distros. Doesn't matter when or how we decide launch, will be in the middle of schedule of some of then. So unless we decide benefit one distro, which would be bad, the 6 months is pointless. And is worse, since we, kde developers are seen distros backport more and more stuff from trunk because we launched too early or to late the date of their deployment.. And to make it worse, the "always summer in the trunk" will make then confuse, and developers ( there's exceptions ) as we know don't care too much about distro bugs from stable series, imagine in a word without any kind of freeze OEM and embedded projects doesn't care about dates and release, since they have their own pace, usually longer than a year and keeps their codebase alive for long time after their releases, as a common platform. And regular final users don't compile packages, so, launch a source release means nothing basically for then. > * are we getting the return in commitment promised from third parties due > to the discipline of a 6 month cycle, or do we need to re-assess that with > them? Third parties who ? > * how long before we can disentable the development cycle from it, ala Dirk > and Sebastian's presentation at Akademy '08? I would love to see it happens in the day after of 4.2 4.2 is a point of no return, but for 4.3 is feasible. > * if that disentanglement will take more than a year, how do we deal with > aligning our development with Qt? (our most critical and quickly evolving > component) Is there a reason to take a year ? > * are application developers being well served by the amount and form of > communication thus far? Slowly, but based on the pace of digikam devels, is getting there > * are the libraries being well served by the amount and form of > communication thus far? ( putting distro hat now ) No at all. kdelibs is fine, bug phonon had that confusion during the 4.1 cycle and things like nepomuk, soprano, eigen, akonadi are all a mess in the releases. Akonadi is the first one in the effort to stabilize kdesupport in last weeks, but is way too much to do ahead, and for after 4.2 -- Helio Chissini de Castro KDE Developer Brasil/South America Primary Contact ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.1.1 packages (try #1)
Another error on kdepim Scanning dependencies of target akonadi_strigi_feeder [ 14%] Building CXX object akonadi/agents/strigifeeder/CMakeFiles/akonadi_strigi_feeder.dir/akonadi_strigi_feeder_automoc.o [ 14%] Building CXX object akonadi/agents/strigifeeder/CMakeFiles/akonadi_strigi_feeder.dir/strigifeeder.o Linking CXX executable akonadi_strigi_feeder [ 14%] Built target akonadi_strigi_feeder Scanning dependencies of target nie-gen [ 14%] Generating out_headers, out_sources, out_includes, affiliation.cpp, application.cpp, archive.cpp, archiveitem.cpp, attachment.cpp, audio.cpp, audioimaccount.cpp, bbsnumber.cpp, carphonenumber.cpp, cellphonenumber.cpp, compressiontype.cpp, contact.cpp, contactgroup.cpp, contactlist.cpp, contactlistdataobject.cpp, contactmedium.cpp, cursor.cpp, datacontainer.cpp, dataobject.cpp, datasource.cpp, deletedresource.cpp, document.cpp, domesticdeliveryaddress.cpp, emailaddress.cpp, email.cpp, embeddedfiledataobject.cpp, executable.cpp, faxnumber.cpp, filedataobject.cpp, filehash.cpp, filesystem.cpp, filesystemimage.cpp, folder.cpp, font.cpp, gender.cpp, harddiskpartition.cpp, htmldocument.cpp, icon.cpp, imaccount.cpp, image.cpp, immessage.cpp, informationelement.cpp, internationaldeliveryaddress.cpp, isdnnumber.cpp, mailbox.cpp, mailboxdataobject.cpp, media.cpp, mediafilelistentry.cpp, medialist.cpp, mediastream.cpp, message.cpp, messageheader.cpp, messagingnumber.cpp, mindmap.cpp, modemnumber.cpp, operatingsystem.cpp, organizationcontact.cpp, pagernumber.cpp, paginatedtextdocument.cpp, parceldeliveryaddress.cpp, pcsnumber.cpp, personcontact.cpp, phonenumber.cpp, plaintextdocument.cpp, postaladdress.cpp, presentation.cpp, rasterimage.cpp, remotedataobject.cpp, remoteportaddress.cpp, role.cpp, software.cpp, softwareitem.cpp, softwareservice.cpp, sourcecode.cpp, spreadsheet.cpp, textdocument.cpp, trash.cpp, vectorimage.cpp, video.cpp, videoimaccount.cpp, videotelephonenumber.cpp, visual.cpp, voicephonenumber.cpp, website.cpp CMake Error at /home/mandrake/rpm/BUILD/kdepim-4.1.1/akonadi/agents/nie/rcgen.cmake:42 (message): Failed to generate Nepomuk resource classes. Do you have a recent Soprano version? make[2]: *** [akonadi/agents/nie/out_headers] Error 1 make[1]: *** [akonadi/agents/nie/CMakeFiles/nie-gen.dir/all] Error 2 make: *** [all] Error 2 error: Bad exit status from /home/mandrake/rpm/tmp/rpm-tmp.67840 (%build) RPM build errors: Bad exit status from /home/mandrake/rpm/tmp/rpm-tmp.67840 (%build) -- Helio Chissini de Castro KDE Project Brasil and South America Primary Contact ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.1.1 packages (try #1)
On Quinta 28 Agosto 2008 20:27:35 Allen Winter wrote: > On Thursday 28 August 2008 14:30:14 Dirk Mueller wrote: > > Hi, > > > > I've just finished uploading the first try of KDE 4.1.1 packages. I have > > no interesting news, please report any issues with them to me, or if > > there are important bugreports about it, tag them with the > > kde-4.1.1-blocker keyword on bugs.kde.org. > > Be warned, there might be a nasty bug with the new "squiggly misspelling > indicator" from Sonnet. Please test message composing in KMail and > Konqueror. > > The bug looks like it is coming from QSyntaxHighlighter, but I'm not sure > yet. If the bug bites, you can try reverting 852365 in kdelibs/kdeui/sonnet > (which undoes the squiggles) > ___ > release-team mailing list > release-team@kde.org > https://mail.kde.org/mailman/listinfo/release-team kdepim error with enable final. supported ? [ 2%] Building CXX object kode/kxml_compiler/CMakeFiles/kschema.dir/kschema_final_cpp.o In file included from /home/mandrake/rpm/BUILD/kdepim-4.1.1/build/kode/kxml_compiler/kschema_final_cpp.cpp:4: /home/mandrake/rpm/BUILD/kdepim-4.1.1/kode/kxml_compiler/schema.cpp:38: error: reference to 'Element' is ambiguous /home/mandrake/rpm/BUILD/kdepim-4.1.1/kode/kxml_compiler/schema.h:124: error: candidates are: class Schema::Element /home/mandrake/rpm/BUILD/kdepim-4.1.1/kode/kxml_compiler/parserrelaxng.h:75: error: class RNG::Element -- Helio Chissini de Castro KDE Project Brasil and South America Primary Contact ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Extragear KDE 4 stable branch
On Monday 04 August 2008 04:55:19 Tom Albers wrote: > Op maandag 04 augustus 2008 09:46 schreef u: > > > What's wrong with /branches/stables/extragear/ ? > > > > I think it will only contain really stable releases, i.e., those kde3 > > releases. > > In that case that folder can be renamed to extragear-kde3 and recreate the > extragear folder. To me this would be a no-brainer. > > Best. > > Toma Yep, expected too. Just rename folder and done. Why complicate ? :-) -- Helio Chissini de Castro KDE Project Brasil and South America Primary Contact ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: show stopper list?
On Monday 21 July 2008 10:32:16 Pino Toscano wrote: > Alle lunedì 21 luglio 2008, Rex Dieter ha scritto: > > Dirk Mueller wrote: > > > Anyone around who has more eyes and ears open and can bring in some > > > show stoppers or critical/annoying bugs we have to fix before 4.1? > > > > One of the critical/annoying kind: > > * okular: print pdf produces no output, also print to file broken : > > http://bugs.kde.org/161759 > > Blame Trolltech, not Okular. Okular or not, still be a a critical bug. -- Helio Chissini de Castro KDE Project Brasil and South America Primary Contact ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: show stopper list?
On Thursday 17 July 2008 05:40:48 Dirk Mueller wrote: > > Hi, > > > > Anyone around who has more eyes and ears open and can bring in some show > > stoppers or critical/annoying bugs we have to fix before 4.1? I don't know if this can be considered showstopper or not, but Annma opened a bug against Qt with QTextedit over QGraphicsView, related to compose keys. Is impossible type any accents in languages like portuguese. Easy reproduced, just go to kde keyboard layout, pick as example brazilian with br variety and try do things like é ( '+ e ) or ç ( ' + c ) using notes plasmoid or twitter one. -- Helio Chissini de Castro KDE Developer Brasil/South America Primary Contact ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: RC1 release criteria
On Tuesday 08 July 2008 16:46:38 Helio Chissini de Castro wrote: > On Tuesday 08 July 2008 15:58:19 Aaron J. Seigo wrote: > > On Tuesday 08 July 2008, Helio Chissini de Castro wrote: > > > I'm not consider this to a blocker for rc1 already, but for final yes: > > > http://bugs.kde.org/show_bug.cgi?id=164786 > > > > is Mandriva able to put any dev time into this, since it affects one of > > the Mandriva apps in particular? > > Actually, all gtk apps that embeds in systray, from x-chat to our perl-gtk > applets. > I will discuss with team leaders here about dev time. > Will give answer shortly Ok, i'm up to do the task now, but i need some help where to look and what was done before. I will need share my time with some other task related to akademy, but i will try keep as maximum responsive. -- Helio Chissini de Castro KDE Project Brasil and South America Primary Contact ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: RC1 release criteria
On Tuesday 08 July 2008 15:58:19 Aaron J. Seigo wrote: > On Tuesday 08 July 2008, Helio Chissini de Castro wrote: > > I'm not consider this to a blocker for rc1 already, but for final yes: > > http://bugs.kde.org/show_bug.cgi?id=164786 > > is Mandriva able to put any dev time into this, since it affects one of the > Mandriva apps in particular? Actually, all gtk apps that embeds in systray, from x-chat to our perl-gtk applets. I will discuss with team leaders here about dev time. Will give answer shortly -- Helio Chissini de Castro KDE Project Brasil and South America Primary Contact ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: RC1 release criteria
On Tuesday 08 July 2008 06:36:44 Dirk Mueller wrote: > Hi, > > so the time of RC1 tagging has come (tonight/tomorrow). I would like to > hear comments/list of todo items from each module maintainer that would > block RC1. > > (Yes, I tried browsing bugs.kde.org, but it is vastely useless in its > current form - we need a target milestone for bugs). > > Greetings, > Dirk I'm not consider this to a blocker for rc1 already, but for final yes: http://bugs.kde.org/show_bug.cgi?id=164786 []'s -- Helio Chissini de Castro KDE Project Brasil and South America Primary Contact ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.1 beta2 tarballs (4.0.83) try #1 uploaded
On Friday 20 June 2008 11:07:36 Dirk Mueller wrote: > On Wednesday 18 June 2008, Dirk Mueller wrote: > > Please cc me on any commit that should be included in the final beta2. > > also uploaded phonon-4.1.83.tar.bz2 release and automoc-0.9.83 which should > be used together with this release. > > Another thing that I realized recently: please make sure that your KDE > binary packages are branded. you can do that by adding > -DKDE_DISTRIBUTION_TEXT="foo 10.2.3" while cmakeing kdelibs. arbitrary > string is allowed, but if the first word describes the distro you're using, > then this greatly enhances the quality of bugreports if people click on the > "Report bug" link in an application. > > Greetings, > Dirk kdeplasmoids/dict requires Plasma/Icon header, which is not installed from current kdebase-workspace -- Helio Chissini de Castro KDE Project Brasil and South America Primary Contact ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.1 beta2 tarballs (4.0.83) try #1 uploaded
Hi Don't we agreed that kdeplasmoids module should be called kdeplasma on last thread for 4.0.82 ? []'s On Wednesday 18 June 2008 18:18:28 Dirk Mueller wrote: > Hi, > > just finished uploading the first try of tarballs.. not tested yet. let me > know of any issues. at least kdebindings seems to be failing at the moment > for me. please build kdebindings without kdevplatform support, as > kdevplatform is not going to be released with KDE 4.1. Also note that > quanta is missing from kdewebdev for the same reason. > > I've also tweaked the tarball generation scripts a bit so there might be > new regressions. so far it looks good though. > > Please cc me on any commit that should be included in the final beta2. > > Thanks, > Dirk > ___ > release-team mailing list > release-team@kde.org > https://mail.kde.org/mailman/listinfo/release-team -- Helio Chissini de Castro KDE Project Brasil and South America Primary Contact ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KEG Tarballs.
On Tuesday 17 June 2008 15:03:17 Tom Albers wrote: > Hi, > > As I'm currently busy with stuff, can someone else make the KEG tarballs > for the next release please? Announce it on the keg-list a few days before > running the trunk/playground/createtarball script with the kde-release as > answer to the first question and test build everything. > > Toma I do. Don't worry. Thanks for warning. -- Helio Chissini de Castro KDE Project Brasil and South America Primary Contact ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: the future of kdetoys
On Thursday 12 June 2008, Allen Winter wrote: > On Thursday 12 June 2008 08:58:13 Aaron J. Seigo wrote: > > On Thursday 12 June 2008, Allen Winter wrote: > > > BTW: do we have someone taking module coordinatorship for kdeplasmoids? > > > > that would be me i 'pose, since i was doing that for the extragear > > version of it. > > OK, I'll add that info to the Release Team Projects Page. > > > btw, not having a place to house plasma add-ons that aren't tied to a kde > > release is a bit of a pain. i can see extragear/plasma/ happening again > > at some point if we're not careful. > > Once we have a stable Plasma API, maybe this won't be a problem?? > > > also, the name of the module is already a bit of a misnomer since > > kdeplasmoids actually contain more than plasmoids (engines, themes, etc). > > i don't know if that really matters or anyone particularly cares, though > > =) > > Probably kdeplasma would have been better? > I suppose we could change the name for 4.2. I like above. As we don't have released beta2 yet, i think we have time to move. Aaron, how can we packagers can know which is engine / themes / etc based on what inside package ? I'm telling this because we suppose to split everything in subpackages called plasma- before, but with this is better to improve as plasma-- []'s -- Helio Chissini de Castro KDE Developer Brasil/South America Primary Contact ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.0.6 schedule
On Wednesday 04 June 2008, Dirk Mueller wrote: > Hi, > > contrary to our previous schedule of one month per patch release, I'd like > to delay 4.0.6 to the undefined future to not drag away ressources from KDE > 4.1 schedule, which is way more important. > > any objections to that plan? > > Thanks, > Dirk > ___ > release-team mailing list > release-team@kde.org > https://mail.kde.org/mailman/listinfo/release-team Agree. Undefined future and mybe never will be ok :-) -- Helio Chissini de Castro KDE Developer Brasil/South America Primary Contact ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDEPIM 4.1?
On Wednesday 30 April 2008, Sebastian Kuegler wrote: > On Wednesday 30 April 2008 04:26:54 Allen Winter wrote: > > Sebas' "Alpha1" announcement on the Dot [1] promises KDE-PIM > > as part of the 4.1 release. > > > > I have strong doubts about this. We need to discuss. > > > > There are several apps (KPilot, KMobileTools, KitchenSync,..) > > that haven't been touched for a long time. And other > > apps that are still a long way from being releasable. > > And another set (KMailCVT, Korn, ..) that I really have > > no idea about their status. > > > > One idea is to eliminate kdepim and move any of the apps > > that people still care about and actively maintain to extragear. > > > > Certainly, it is time for a review of what we have and what > > we need to jettison into unmaintained. But, more importantly, > > I simply don't see the our flagship apps being ready > > in the next couple months. > > > > Thoughts or comments? > > Which apps are ready? KMail and KOrganizer, I gather? How about > KAddressbook? Knotes? Akregator? That would make for a good PIM (it's the > apps I use anyway ;-)). > > Not that I was able to try them, yet... UNless i'm wrong, knode is in a good shape too except from be missin on kontact integration ( i still use to read qt-interest ) -- Helio Chissini de Castro KDE Developer Brasil/South America Primary Contact ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdeutils cleanup
On Monday 28 April 2008 11:41:56 Nicolas Ternisien wrote: > On Mon, Apr 28, 2008 at 4:30 PM, Matt Rogers <[EMAIL PROTECTED]> wrote: > > On Monday 28 April 2008 05:30:25 Jonathan Riddell wrote: > > > On Fri, Apr 18, 2008 at 05:32:53PM +0200, Friedrich W. H. Kossebau wrote: > > > > * KCalc - scientific calculator > > > > > > KCalc should be replaced by speedcrunch in my opinion, but that would > > > require the speedcrunch developers to propose it rather than just say > > > they will :) > > > > I disagree with you that KCalc should be replaced. I wouldn't > > necessarily call it a scientific calculator though. > > I will personally prefer to have Speedcrunch in kdeutils, because > Speedcrunch could have the look of a standard calculator and is really > more powerful for anyone who wants to make simple computation. > > Similar looks : > http://stuff.forum-software.org/calcs/kcalc.png > and > http://stuff.forum-software.org/calcs/speedcrunch.png You can't be serious. If we try to put this sort of advanced calculator instead kcalc, my company at least will have some customer complain heavily on their 20k machines deplyed with KDE for common users.. I'm strongly against this kind of replacement. -- Helio Chissini de Castro KDE Project Brasil and South America Primary Contact ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.0.2 tarballs ready
Em Thursday 28 February 2008 13:01:49 Dirk Mueller escreveu: > Hi, > > KDE 4.0.2 tarballs have been uploaded. The plan is to release them > Tuesday/Wednesday next week. Let me know if you find any issues with them. > > kde-l10n failed to build as usual, I'm currently fixing it. > > > Greetings, > Dirk > ___ > release-team mailing list > release-team@kde.org > https://mail.kde.org/mailman/listinfo/release-team Disregards my last email, my system was broken with trunk + branch. I got this error on kdenetwork: [ 6%] Building CXX object kget/plasma/applet/CMakeFiles/plasma_applet_kget.dir/plasma-kget.o /lixo/packages/kdenetwork4/BUILD/kdenetwork-4.0.2/kget/plasma/applet/plasma-kget.cpp: In member function 'virtual void PlasmaKGet::init()': /lixo/packages/kdenetwork4/BUILD/kdenetwork-4.0.2/kget/plasma/applet/plasma-kget.cpp:61: error: 'TopMargin' is not a member of 'Plasma' Some wrong kget backport ? -- Helio Chissini de Castro KDE Project South America Primary Contact ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.0.2 tarballs ready
Em Thursday 28 February 2008 13:01:49 Dirk Mueller escreveu: > Hi, > > KDE 4.0.2 tarballs have been uploaded. The plan is to release them > Tuesday/Wednesday next week. Let me know if you find any issues with them. > > kde-l10n failed to build as usual, I'm currently fixing it. > > > Greetings, > Dirk > ___ > release-team mailing list > release-team@kde.org > https://mail.kde.org/mailman/listinfo/release-team I odn know if i screwed up something, but kdepimlibs package is requesting me qt 4.4.0. Is that right ? -- Helio Chissini de Castro KDE Project South America Primary Contact ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Almost forgot: 3.5.9...
On Mon 18 Feb 2008 11:59:31 Stephan Kulow wrote: > Am Freitag 15 Februar 2008 schrieb Stephan Kulow: > > Hi, > > > > .. is on ktown for the packagers to grab since tuesday. > > So it looks like we can start rollout :) > > Is everything in place? I'd put the binary.inc and source.inc > in place tomorrow and s,3.5.8,3.5.9, in the announcement if > nothing else is prepared > > Greetings, Stephan > ___ > release-team mailing list > release-team@kde.org > https://mail.kde.org/mailman/listinfo/release-team For this time, we will not push packages on ktown, but already in our mirrors, for the devel and stable distro. How can i add this in the announcement ? -- Helio Castro Research and Development Mandriva Conectiva Brasil ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Distro BoF
On Sun 20 Jan 2008 09:42:39 Richard Moore wrote: > On 1/19/08, Jonathan Riddell <[EMAIL PROTECTED]> wrote: > > * System Settings Unix tools integration (possibly with Guidance KDE 4 > > * port) > > Could you explain this one? > > Thanks > > Rich. For some time distros have been doing tons of third party tools for administering parts of the system. This results in more panels, like Mandriva Control Center, Yast, etc.. The idea is make a simple way to integrate de calls of this tools in system settings, so user need open just one panel, even been not necessarily a KDE tool. -- Helio Chissini de Castro KDE Project South America Primary Contact ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Evaluation of the extragear tarball releases.
On Saturday 12 January 2008, Tom Albers wrote: > Hi, > > For the rc2 and for the final release we've been creating tarballs of > extragear applications. I've taken the time to evaluate this based on > feedback with different packers. I will try to keep it short and to the > point. > > 1) > The tarballs are now pretty much ok, the software to create them is > committed in playground[1], so everyone can make them, when I'm > unavailable. The only point is to include the translated documentation in > the tarball. It's not done, because there are currently no examples to work > with. Ok, great job. > 2) > The applications currently packaged[2] needs work. I discovered the > following problems: > > Ok: kgraphviewer, kphotoalbum(?), kmldonkey, kopete-cryptography, kaider, > rsibreak These applications seem maintained and ok. Although when kaider > moves to trunk for the 4.1 release, there won't be any updates up to the > release of 4.1. > > Unmaintained: kcoloredit, kfax, kiconedit, kpovmodeler, ligature > These applications seem unmaintained (please correct me if I'm wrong!), I > would like to remove them from the keg-release project. I would even like > to suggest to Helio to contact the maintainers and remove them from > extragear. I can do that too if wanted. I can do it, i already did when i moved extragear from places in svn. kpovmodeler is one that i really think is maintained in some way. > Own release schedule: ktorrent > KTorrent has made his own beta release between te rc2 and final keg > tarballs we created. I think we should disable ktorrent from our release > process for now, untill they indicate they want to join again. We need talk again with Joris, but remember, keg maintainers are free to do releases in between. We can push the same releases again in the launch, no issue. > 3) > One of the bigger issues is the versioning. Because they are released with > the kde release the internal version number of the application should be > bumped as well. I would like to suggest to use the same numbering as the > kde release they are part of. I've to discuss with some people how to do > that, but I can add something like 'setVersion(4.0.1)' to a cmake file, and > try to use that in the kaboutdata and when it's not set use the 'old' > value. Any ideas (or help with the execution) would be great. No, definitively i'm against use this. The applications should remain their own release number. That was thr original target of keg ans should stay this way. We should find a better way to match the version with our releases, and not the other way. > I will proceed with above in +/- two weeks if there are no objections. Not so fast. This is not easy changes and as i stated above, i'm far from be ok with this huge changes without discussion be more open in keg list Meeting at Mountain VIew ? -- Helio Chissini de Castro KDE Developer Brasil/South America Primary Contact ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 3.5.9
On Fri 11 Jan 2008 14:11:58 Rex Dieter wrote: > Stephan Kulow wrote: > > I wanted to wait with it after 4.0 and I don't mind if we don't do it > > at all, but there were 327 commits not counting translations, so > > it would be justified. > > +1 > > speaking of which, did anything actually happen wrt to Allen's proposed > merging of kdepim-enterprise? > > -- Rex > ___ > release-team mailing list > release-team@kde.org > https://mail.kde.org/mailman/listinfo/release-team +1 -- Helio Chissini de Castro KDE Project South America Primary Contact ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.0.1 schedule
On Fri 11 Jan 2008 11:06:23 Dirk Mueller wrote: > Hi, > > January 30th for tagging 4.0.1? > > Greetings, > Dirk > ___ > release-team mailing list > release-team@kde.org > https://mail.kde.org/mailman/listinfo/release-team Too close, and will make this topic of discussions on Mountain View Let's enjoy this time the proper release party and future ( like 4.1 ) discussion, and push 4.0.1 week further.. -- Helio Chissini de Castro KDE Project South America Primary Contact ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Proposed KDE 4.1 Release Schedule
On Tue 08 Jan 2008 08:38:44 Sebastian Kügler wrote: > On Monday 07 January 2008 15:26:21 Helio Chissini de Castro wrote: > > On Tue 08 Jan 2008 07:25:53 Sebastian Kügler wrote: > > > On Tuesday 08 January 2008 11:34:39 Dirk Mueller wrote: > > > > On Tuesday 08 January 2008, Matt Rogers wrote: > > > > > Not perfect, but it's a start. Comments? > > > > > > > > I miss the following information: > > > > > > > > a) Why was July chosen? Was it because it is 4.0 + 6months? So if it > > > > is "old release + 6months", then we go back to the idea of aligning > > > > with distributions. Proposing a 6 month cycle, but aligning it to the > > > > 4.0 date which was decided by a release event plan is not a good > > > > choice imho. Note that I do principally like the 6 month cycle. > > > > > > July should work for Fedora, Ubuntu assuming three months is enough to > > > do the integration work. Maybe you (or coolo) can fill in openSUSE > > > plans? (Those on the website are not particularly helpful.) > > > > > > For Ubuntu and Fedora it looks like they're releasing in April and > > > October. > > > > I'm glad that nobody remembers us ... > > Anyway, who cares about distros shipping KDE. > > Well, I'm running Mandriva *right now*, so I definitely do. :-) > > Can you quickly explain what Mandriva's release strategy looks like, and > what kind of schedule would be preferable for you? Two possible dates are common to us. We usually have major version and half major version releases. Major ones, 200x will usually be on first week of October half major, 200x.1 will usually be on first or second week in april So a July release will be perfect for us, giving us plenty of time to prepare the major release. []'s -- Helio Chissini de Castro KDE Project South America Primary Contact ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Proposed KDE 4.1 Release Schedule
On Tue 08 Jan 2008 07:25:53 Sebastian Kügler wrote: > On Tuesday 08 January 2008 11:34:39 Dirk Mueller wrote: > > On Tuesday 08 January 2008, Matt Rogers wrote: > > > Not perfect, but it's a start. Comments? > > > > I miss the following information: > > > > a) Why was July chosen? Was it because it is 4.0 + 6months? So if it is > > "old release + 6months", then we go back to the idea of aligning with > > distributions. Proposing a 6 month cycle, but aligning it to the 4.0 date > > which was decided by a release event plan is not a good choice imho. Note > > that I do principally like the 6 month cycle. > > July should work for Fedora, Ubuntu assuming three months is enough to do > the integration work. Maybe you (or coolo) can fill in openSUSE plans? > (Those on the website are not particularly helpful.) > > For Ubuntu and Fedora it looks like they're releasing in April and October. I'm glad that nobody remembers us ... Anyway, who cares about distros shipping KDE. -- Helio Chissini de Castro KDE Project South America Primary Contact ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [24h] Kompare move to extragear
On Thu 13 Dec 2007 10:29:06 Tom Albers wrote: > Hi, > > Without objections I will move Kompare to extragear tomorrow evening and > add it to the keg-tarball-on-release-project. > > The 24h waiting period starts now. No objection from me... -- Helio Chissini de Castro KDE Project South America Primary Contact ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 3.5.8 uploaded
Em Tuesday 09 October 2007 03:51:31 Stephan Kulow escreveu: > Hi! > > I tagged, packaged and uploaded KDE 3.5.8 to be > grabbed by packagers. I would like to know if there > is some spare time left to adapt the 3.5.7 release > announcement :) > > I don't think we want to take away any of the shine from > the 7th KConfig rewrite, but I guess some people might > still be interested in bugs being fixed. > > Albert was already so nice to create > http://www.kde.org/announcements/changelogs/changelog3_5_7to3_5_8.php > and we added kdevelop 3.5 to the mix, so there is something > to announce. > > Greetings, Stephan > ___ > release-team mailing list > release-team@kde.org > https://mail.kde.org/mailman/listinfo/release-team Hi Coolo, when will br the official announcement ? I need until weekend to finish my packages due my slow connection at Angola, but i don't want miss Mandriva from this release this time. []'s ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release event information and a healthy dose of ranting too!
A Tuesday 18 September 2007 13:26:30, Troy Unrau escreveu: > (this message is for the kde-ev-marketing mailing list members, and is > CC'ed to the release-team and kde-promo mailing list for information > purposes only) > > So guys, I figured I'd keep those of you not directly involved in > planning the release event know a little of what's going on. this is > the current situation, although I'm thinking we might want to change > tracks on this a little. Hi Troy I'm now in the middle of Africa continent ( Angola, to be more precise ) in a project that we can really define as a digital inclusion, and will be for next two months. So, for have a Visa for me i need do an interview in the US consulate at Brazil, and need be scheduled now, so i will need at least precise dates of the event to make my lifeb easier, and will submit the data from here, then my travel agency will have everything setup when i back to Brazil. I will tell to you the crazy experience here in the event :-) Ps. In some days, maybe we will have a good KDE pr about users and how KDE in doing well in Africa introducing computing as a totally new directions in this place !! ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release dates/nomenclature
Can we please turn on krazy again ? Adrian blogged about that, so now my fear of damage is complete, people already will ask "what the fuck is happening.." And divide more and more attention to explain what we're doing to everyone and increase the fud is exactly what we don't need now :-/ -- Helio Chissini de Castro KDE Project South America Primary Contact Curitiba - Brasil ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release dates/nomenclature
On Sunday 02 September 2007, Allen Winter wrote: > On Saturday 01 September 2007 6:55:57 pm Matt Rogers wrote: > > On Sep 1, 2007, at 4:29 PM, Allen Winter wrote: > > > On Saturday 01 September 2007 11:45:07 am Thomas Zander wrote: > > >> On Saturday 01 September 2007 17:30:34 Matt Rogers wrote: > > >>> That's no different than what we have now. The problem is that > > >>> people > > >>> seem to be too interested in fixing Krazy issues rather than fixing > > >>> actual bugs. How do you propose we get them interested in fixing > > >>> real > > >>> bugs? > > >> > > >> Stop running the not-so-interresting krazy tests? ;) > > > > > > We can pull the plug on the EBN entirely. > > > I don't think that will help get bugs fixed, but at least > > > it will reduce the number unneeded re-compiles. > > > > > > I had no idea Krazy/EBN was doing such so harm to the project. > > > That was not the intention. > > > > > > -Allen > > > > I don't think it does that much harm to the project. In fact, I would > > consider the EBN a good thing. However, it may be a good idea to > > suspend it temporarily. Perhaps the number of recompiles caused by > > people not fixing krazy issues will allow some of us to be more > > productive. It may also spur some of the newer developers to work on > > other things besides fixing Krazy issues, which in the grand scheme > > of things, are less important the closer we get to a freeze. (IMHO) > > Ok, I turned the Krazy web site off. > > I can't really do anything about the command line tool > except tell folks not to use it. > > -Allen Please, no. I was planning to use it in a next week presentation in a major conference here an one of the important things introduced during our evolution. Despite this, turn off Krazy is just a way to make more people talking about "what's happening". Sorry, but by blaming Krazy for the fact that we're lack of resources or for try force people to do something is almost the same to cut off the liberty of developers decide by thenselves what they want to do. Probably i'm not the first one to say that, but the current issues have NOTHING TO DO with tools like krazy, but to lack of we do better management of project and failing in to explain to out developers what we need to do right now. Seriously, shutting down krazy is more signal of weakness and confusion than a really help to project. PLease, get it online again. My 2c's -- Helio Chissini de Castro KDE Developer Brasil/South America Primary Contact ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: 3.5.X releases
Em Fri 20 Jul 2007, Stephan Kulow escreveu: > Hi! > > Perhaps the news spread to you already: I took more responsibility within > SUSE and I'm now Project Manager for the openSUSE distribution and for the > platform of our enterprise products (for those not working for a > distribution: platform is everything that is shared core functionality of a > server and a desktop distribution). > > That means my general time for KDE specifics will be reduced not just by > means of family extension, but also due to my job. While I would like to > continue doing KDE 3.5.X releases, I would understand if someone feels I'm > no longer the best suited person to do them. If so, now would be a good > time for a change. > > And trust me, I will accept any solution in the best interest of the KDE > project. > > Greetings, Stephan Dude, there's tons of kde people which is less busy than you are before this new task and you did great job, way better then us in our minor tasks. As kde 3.x base now is going slow and ( hope ) not demanding too much, there's no reason to replace your good work. And congrats by new position and the baby :-) -- Helio Chissini de Castro KDE Project South America Primary Contact Curitiba - Brasil 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: Beta1 and kdelibs Freeze
On Wednesday 13 June 2007, Allen Winter wrote: > On Wednesday 13 June 2007 5:57:04 pm Sebastian Kügler wrote: > > On Wednesday 13 June 2007 22:56:13 Allen Winter wrote: > > > Howdy, > > > > > > Note that the Monday June 25 Beta1 Release Milestone > > > is fast approaching. I'd like to make the following > > > clarifications and date changes to the schedule: > > > > > > 1. First, I'd like to change the date to 26 June so that > > > we may have 1 final "big changes Monday" on 25 June > > > > > > 2. Change > > > "From this date forward, a Beta Release will be published > > > every month until most grave bugs are resolved." > > > to > > > "From this date forward, a Beta version will be tagged > > > every month until most grave bugs are resolved. > > > The actual release of the Betas will occur soon > > > after the tagging." > > > > > > 3. Change > > > "Starting with the first Beta (25 June), the kdelibs API is frozen > > > solid. " to > > > "Starting with the first Beta (26 June), the kdelibs API is frozen > > > solid. " > > > > Coming to think of it, does this mean that Beta1 will be tagged right > > after a Monday? If so, isn't it a good idea to have a couple of days to > > have things settled down? > > Um... yes. > That's exactly what we did for the Alpha release. > I believe we moved the tagging to a Thursday. > > So June 28th then for the tagging? I would like to remind that Akademy starts on 29, so probably kde packagers will be there ( at least me taking care of Mandriva packages ) and i want do proper packagees, so been remote at Glasgow make divide attentions and will not take proper atention to akademy neither work is not good. So, unless is too important as a marketing factor, manage this beta AFTER last akademy day can be appreciated. Best regards -- Helio Chissini de Castro KDE Developer Brasil/South America Primary Contact ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
