Re: Transition to new mirror infrastructure

[Rex Dieter]

I'm stumped here why this isn't working as before on milonia, to transfer a
whole bunch of files at a time with wildcards.
While individual transfers are fine:
rsync deino.kde.org:stable/release-service/20.08.3/src/yakuake-20.08.3.tar.xz
. -v
yakuake-20.08.3.tar.xz
(success)

Wildcards no longer work:
rsync deino.kde.org:stable/release-service/20.08.3/src/*.xz .
rsync: link_stat
"/srv/archives/ftp/stable/release-service/20.08.3/src/*.xz" failed: No such
file or directory (2)
rsync error: some files/attrs were not transferred (see previous errors)
(code 23) at main.c(1816) [Receiver=3.2.3]
rsync: [Receiver] write error: Broken pipe (32)

Any ideas?


On Sat, Oct 31, 2020 at 1:01 PM Ben Cooksley  wrote:

> On Sun, Nov 1, 2020 at 4:49 AM Christoph Feck  wrote:
>
>> On 10/31/20 03:08, Ben Cooksley wrote:
>> > This transition has now been completed, and going forward all access
>> should
>> > now be directed to deino.kde.org.
>>
>> Did I understand it correctly, that "deino" is the replacement for
>> "milona", but shouldn't offer ssh/scp access anymore, but need to use
>> sftp?
>>
>
> Deino is the replacement to Milonia yes.
> The restriction on access only applies to packagers and those with
> accounts for managing data on files.kde.org/cdn.kde.org/distribute.kde.org
> and doesn't apply to ftpadmin.
>
>
>> For what it's worth, I could successfully ssh login to
>> ftpad...@deino.kde.org (using the credentials I used previously on
>> milona), and could use mkdir/chmod in stable/release-service path,
>> albeit response time was very laggy.
>>
>
> I've investigated that issue with response times and found that the
> network adapter was extremely unhappy and regularly resetting itself.
> Following a system reboot it appears to have been corrected, however we'll
> monitor the system to confirm this is the case.
>
>
>> If that's not the correct replacement procedure, please clarify.
>>
>> BG,
>> Christoph
>>
>
> Many thanks,
> Ben
>
>
>>
>> --
>> Christoph Feck
>> KDE Release Team
>>
>>

Re: KF 5.37 requiring Qt 5.7

[Rex Dieter]

David Faure wrote:

> On lundi 7 août 2017 18:25:35 CEST Rex Dieter wrote:
>> David Faure wrote:
>> >> > Isn't it an option to leave it in, at version 5.36, rather than
>> >> > removing it completely ?
>> >> 
>> >> In the short-term, yes.
>> >> 
>> >> Long term, I'm not willing to ship (and support) this if it's not
>> >> supported upstream either (where bugs are usually fixed in newer
>> >> releases).
>> > 
>> > I thought you said that long term you were looking at upgrading to Qt
>> > 5.9...
>> 
>> I may or may not be successful.
>> 
>> > In any case I'm not sure why Qt's promise to maintain 5.6 for 3 years
>> > means that all Qt-based libraries must promise the same.
>> 
>> , you asked for feedback, and I gave it.  I'm just spelling out
>> the results of implementing the change now => dropping support for RHEL7
> 
> That's unfortunate, which is why I'm still trying to discuss and find
> solutions with you, but we just can't support Qt 5.6 forever.
> 
> Does RHEL have additional optional repos that allow upgrading (e.g. to a
> newer Qt), like OpenSuSE has? Then it wouldn't be "completely dropping out
> of RHEL7", but "requiring an extra repo". Not as good as a core package,
> but still a possibility for those who might need it.

Policy for any official-ish addon repos is that they cannot replace any core 
packages (Qt5 is that).  So, in general no.  I see no alternatives for 
*now*.   This is why I'd suggested waiting until we knew more, but I can 
also accept letting kf5 move forward and waiting/hoping for a better Qt5 
solution on our end too.

-- Rex

Re: KF 5.37 requiring Qt 5.7

[Rex Dieter]

David Faure wrote:

>> > Isn't it an option to leave it in, at version 5.36, rather than
>> > removing it completely ?
>> 
>> In the short-term, yes.
>> 
>> Long term, I'm not willing to ship (and support) this if it's not
>> supported upstream either (where bugs are usually fixed in newer
>> releases).
> 
> I thought you said that long term you were looking at upgrading to Qt
> 5.9...

I may or may not be successful.

> In any case I'm not sure why Qt's promise to maintain 5.6 for 3 years
> means that all Qt-based libraries must promise the same.

, you asked for feedback, and I gave it.  I'm just spelling out the 
results of implementing the change now => dropping support for RHEL7

It's up to you if you choose to implement changes that means some downstream 
distros cannot (reasonably) use your (latest/supported) software anymore.

-- Rex

Re: KF 5.37 requiring Qt 5.7

[Rex Dieter]

David Faure wrote:

> On lundi 7 août 2017 16:46:59 CEST Rex Dieter wrote:
>> David Faure wrote:
>> > On mercredi 2 août 2017 22:55:10 CEST Rex Dieter wrote:
>> >> David Faure wrote:
>> >> > According to the policy that KF5 should work with the last 3
>> >> > releases of Qt5.x, it is time now for upcoming releases of KF5 to
>> >> > drop support for Qt 5.6.
>> >> > 
>> >> > Packagers: is that acceptable?
>> >> 
>> >> I'd prefer to continue to allow 5.6 awhile, to continue to allow
>> >> support for rhel 7.
>> > 
>> > That's curious, how do you package the parts of KDE Applications or
>> > Workspace that already require Qt 5.7 ?
>> 
>> I haven't packaged those pieces yet.
>> 
>> Sounds like you may have moved forward anyway, so I guess I'll have to
>> start
>> the process of removing KF5 from the EPEL addon repository for rhel7.  I
>> shame, I and a few others did a fair amount of work to get that in.
> 
> Isn't it an option to leave it in, at version 5.36, rather than removing
> it completely ?

In the short-term, yes.

Long term, I'm not willing to ship (and support) this if it's not supported 
upstream either (where bugs are usually fixed in newer releases).

-- Rex

Re: KF 5.37 requiring Qt 5.7

[Rex Dieter]

David Faure wrote:

> On mercredi 2 août 2017 22:55:10 CEST Rex Dieter wrote:
>> David Faure wrote:
>> > According to the policy that KF5 should work with the last 3 releases
>> > of Qt5.x, it is time now for upcoming releases of KF5 to drop support
>> > for Qt 5.6.
>> > 
>> > Packagers: is that acceptable?
>> 
>> I'd prefer to continue to allow 5.6 awhile, to continue to allow support
>> for rhel 7.
> 
> That's curious, how do you package the parts of KDE Applications or
> Workspace that already require Qt 5.7 ?

I haven't packaged those pieces yet.

Sounds like you may have moved forward anyway, so I guess I'll have to start 
the process of removing KF5 from the EPEL addon repository for rhel7.  I 
shame, I and a few others did a fair amount of work to get that in.

-- Rex

Re: KF 5.37 requiring Qt 5.7

[Rex Dieter]

David Faure wrote:

> According to the policy that KF5 should work with the last 3 releases of
> Qt5.x, it is time now for upcoming releases of KF5 to drop support for Qt
> 5.6.
> 
> Packagers: is that acceptable?

I'd prefer to continue to allow 5.6 awhile, to continue to allow support for 
rhel 7.

And in the meantime, will push them to rebase to something newer (5.9?) for 
the next point release.

-- Rex

Re: Review of special packager access

[Rex Dieter]

Ben Cooksley wrote:

> I'd therefore like for someone from each distribution to please
> confirm that their distro is still active and who can serve as a
> general point of contact for that distribution

Fedora is still active, contact:
Rex Dieter <rdie...@fedoraproject.org>

Thanks

-- Rex

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE Frameworks 5.22.0

[Rex Dieter]

David Faure wrote:

> Dear packagers,
> 
> KDE Frameworks 5.22.0 has been uploaded to the usual place.

frameworkintegration releases prior to 5.22.0 included translation file 
frameworkintegration5.mo for various locales, but 5.22 no longer does.  Was 
this intentional or bug/oversight?

-- Rex


___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE Applications 15.12.0 available for packagers -

[Rex Dieter]

Clive Johnston wrote:

> While packaging kdepimlibs 15.12.0 I get the following CMake error:
> 
> Could not find a configuration file for package "KF5Prison" that is
> compatible with requested version "1.2.1".
> 
> Can someone let me know where the 1.2.1 release tarball is located, Ive
> search depot and cant find it.

It's not released yet, and it should only be an optional dependency.

One blocker to make a release, imo, is to make sure it is parallel-
installable with qt4 prison, see also:
https://git.reviewboard.kde.org/r/125944/

-- Rex


___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE Connect 0.9 for Plasma 5

[Rex Dieter]

Albert Vaca wrote:

> Hi!
> 
> I just published the first version of KDE Connect for the Plasma 5
> desktop.
> 
> http://download.kde.org/unstable/kdeconnect/0.9/src/kdeconnect-kde-0.9.tar.xz.mirrorlist

Is it intentional that this release includes no translations?

-- Rex

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: how to release oxygen-icons

[Rex Dieter]

On 10/07/2015 08:14 AM, Jonathan Riddell wrote:

Oxygen icons is back and updated and due to be part of Plasma 5.5

...

So how to release it now?


Silly question, why does it have to be part of plasma release, rather 
than continue to release it as part of applications ?


-- rex

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Kamoso and first Purpose release

[Rex Dieter]

Aleix Pol wrote:

> On Tue, Sep 29, 2015 at 11:06 AM, Jonathan Riddell 
> wrote:
>>> Yes, that's the idea. The code was moved from kdevplatform to Purpose,
>>> but note that your kdevelop won't have this as you don't have KDevelop
>>> 5.
>>>
>>> Jonathan, you said you renamed it, how do you rename it so that it's
>>> still found by the code?
>>
>> I just updated the reviewboardplugin.json file, that's the only place I
>> saw it referenced.
>>
>> Jonathan
> 
> Can you maybe contribute the patch to KDE, so everyone can benefit?

If it wasn't clear, Jonathan's fix was to kde git already,

https://quickgit.kde.org/?p=purpose.git=commit=c11acd122b6e44cfc7e5c516aa651e7b79149b7b


-- Rex

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Kamoso and first Purpose release

[Rex Dieter]

On 09/28/2015 11:32 AM, Jonathan Riddell wrote:


Kubuntu packages are in wily ready for release in a month.

It helps packagers to keep a sequential version number scheme e.g. 2.9.80, 
2.9.90, 3.0.0 etc


I'm also seeing an icon conflict between purpose-1.0 and 
kdevplatform-1.7.x, they both provide

/usr/share/icons/hicolor/128x128/apps/reviewboard.png
/usr/share/icons/hicolor/16x16/apps/reviewboard.png

How are others resolving this?

-- Rex

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE Applications 15.08 RC is out

[Rex Dieter]

Raymond Wooninck wrote:

 On Thursday 06 August 2015 22:21:52 Albert Astals Cid wrote:
 I failed to use the proper CC when publishing it in kde.org this
 afternoon.
 
 Any feedback? Is anyone actually compiling this or the Beta packages?
 
 Hi Albert,
 
 I have compiled KDE Applications 15.08 RC for openSUSE and have the
 following failures:
 
 1)libkgeomap will no longer compile as that it requires the 
Qt4/KDE4
 version of Marble, but Marble is now Qt5/KF5 based.


It's been possible to ship both Qt4 and Qt5 based libmarblewidget for 
awhile, but it seems that marble devs disabled Qt4 support only recently.

Either way, the suggestion to ship 2 marbles (as Albert suggested), one 
Qt4/kde4 based and one Qt5/kf5 based is reasonable. It just means 
downstreams will have to use separate sources to do it (instead of building 
twice from the same sources as before).

-- Rex

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Future frameworks releases

[Rex Dieter]

David Faure wrote:

 Hello packagers,
 
 The thread Versioning of Frameworks on kde-frameworks-devel has led to
 the idea that some future frameworks (coming from the kdepim world) would
 not be part of every Frameworks release, and would have their own
 versioning scheme. This is at the request of their maintainer, Christian,
 CC'ed.
 
 For example:
   KF 5.12 would contain KImap 2.1
   KF 5.13 would not contain a KImap release
   KF 5.14 would contain KImap 2.1.1
   KF 5.15 would contain KImap 2.2
 
 Would that work for you guys?

A little conventional, but ok with me (with fedora packager hat on).

-- Rex

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE Applications 14.12.1 tarballs up for packagers

[Rex Dieter]

On 01/10/2015 04:58 PM, Albert Astals Cid wrote:

They are in stable/applications.

Release is next week tuesday if all goes well

There's also LTS packages for kdelibs, kdepim, kdepimlibs and kde-runtime 4.14
and for kde-workspace 4.11


I assume you meant kdepim-runtime here (not kde-runtime)

-- Rex

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Fwd: kdeedu-data

[Rex Dieter]

On 10/26/2014 05:18 PM, Jeremy Whiting wrote:

Ugh, I saw that on fedora recently. Why do distros do that? I guess
those same distros also patch KStandardDirs to look for files there ?
Or set KDEHOME or something so it will look there?


The why was because that dir was also used by kde3, and kde4 
introduced various conflicts.  off the top of my head (it's been 
awhile), there were at least 2... kate and khtml


As to how it's implemented, on fedora at least, we build all kde4 
packages with a standard set of build flags, one of which is:

-DDATA_INSTALL_DIR:PATH=/usr/share/kde4/apps
I believe other distros follow a similar convention here, and probably 
for similar reason(s).


-- Rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Fwd: kdeedu-data

[Rex Dieter]

Jeremy Whiting wrote:

 Hey packagers,
...
 Now kdeedu-data uses ecm instructions to build like other kf5 based
 applications. Is that going to be a problem to make both khangman and
 kanagram run time depend on these packages, while kdeedu-data at build
 time requires ecm to build?

kdeedu-data having a build-dep on ecm is fine by me (with my fedora packager 
hat on).

-- Rex

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: 4.14.0 packages up for packagers

[Rex Dieter]

On 08/14/2014 11:50 AM, Albert Astals Cid wrote:

El Dijous, 14 d'agost de 2014, a les 10:54:08, Albert Astals Cid va escriure:

Hi, there 4.14.0 packages are up for packagers at the usual location.

Public release is next Wednesday.

I have not yet built the packages, doing so now.


FWIW all built fine here.


kate pate (python) plugin fails for me (since .97 release at least), and 
possibly most anything depending on pykde4.


https://bugs.kde.org/show_bug.cgi?id=338137

and one possible/proposed fix,
https://git.reviewboard.kde.org/r/119679/

-- Rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: 4.14.0 packages up for packagers

[Rex Dieter]

On 08/14/2014 12:05 PM, Rex Dieter wrote:

On 08/14/2014 11:50 AM, Albert Astals Cid wrote:

El Dijous, 14 d'agost de 2014, a les 10:54:08, Albert Astals Cid va
escriure:

Hi, there 4.14.0 packages are up for packagers at the usual location.

Public release is next Wednesday.

I have not yet built the packages, doing so now.


FWIW all built fine here.


kate pate (python) plugin fails for me (since .97 release at least), and
possibly most anything depending on pykde4.

https://bugs.kde.org/show_bug.cgi?id=338137

and one possible/proposed fix,
https://git.reviewboard.kde.org/r/119679/


Patch reviewed and committed to 4.14 branch,
http://commits.kde.org/pykde4/84139e526d1ed02d15606dacbd4c9b0c8cf1a872

I heard a rumor a new tarball will land including this soon (maybe Saturday)

-- Rex

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: 4.13.2 tarballs are up for packagers

[Rex Dieter]

On 06/08/2014 06:08 AM, Albert Astals Cid wrote:

El Dissabte, 7 de juny de 2014, a les 17:44:37, Rex Dieter va escriure:

On 06/06/2014 01:26 PM, Albert Astals Cid wrote:

tarballs are up for packagers in the usual location.

kdepim-runtime is missing since it has a regression in the passing tests
and people have not convinced me enough that the tests failing are
harmless.

I've given the kdepim people until monday to fix them or we'll release
without it.


kdelibs-4.13.2 fails to build on arm platform (ie, anywhere qreal !=
double) due to commit
https://projects.kde.org/projects/kde/kdelibs/repository/revisions/6197b21be
57967a6f4045cbc354c43ed83f7480c

which fixes

https://bugs.kde.org/show_bug.cgi?id=335346

I added a comment to the bug and re-opened it


My current feeling is that this is not ultra important to block the release
(even it would be cool if we can add it in) given how niche kde+arm is at the
moment.


I agree.

However, I've confirmed the proposed fix in the bug works, so if it gets 
committed quickly (ie today or so), it would be nice to get included in 
a new tarball, since it still does have the

set (KDE_VERSION_RELEASE 1)
problem described earlier too.

-- Rex

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: 4.13.2 tarballs are up for packagers

[Rex Dieter]

On 06/06/2014 01:26 PM, Albert Astals Cid wrote:

tarballs are up for packagers in the usual location.

kdepim-runtime is missing since it has a regression in the passing tests and
people have not convinced me enough that the tests failing are harmless.

I've given the kdepim people until monday to fix them or we'll release without
it.


kdelibs-4.13.2 fails to build on arm platform (ie, anywhere qreal != 
double) due to commit

https://projects.kde.org/projects/kde/kdelibs/repository/revisions/6197b21be57967a6f4045cbc354c43ed83f7480c

which fixes

https://bugs.kde.org/show_bug.cgi?id=335346

I added a comment to the bug and re-opened it

-- Rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: 4.11.0 tarballs available (for packagers)

[Rex Dieter]

On 08/09/2013 05:47 AM, Andreas K. Huettel wrote:

Am Donnerstag, 8. August 2013, 01:58:01 schrieb Albert Astals Cid:

The tarballs can be found in their usual embargo location (available only
to packagers)


Marble python bindings fail to build.


Tracked here,
https://bugs.kde.org/show_bug.cgi?id=322573

-- rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Exception for Nepomuk Ebook Indexers

[Rex Dieter]

On 06/20/2013 07:51 AM, Vishesh Handa wrote:

They introduce an optional dependency of libepub.


It's already an optional dependency for okular, so I'm definitely ok 
with the addition here.


-- rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Release Strategy Proposal

[Rex Dieter]

On 04/26/2013 08:37 AM, Frank Reininghaus wrote:

Hi,

2013/4/26 Sebastian Kügler:

Hi,

tldr
Let's make 4.11 the last feature release for platform and workspace in the 4
series, make 4.11 a long term maintainance release.
/tldr

I would like to propose the following for our release planning in the next
year:

- Make 4.11 Platform and Workspaces a long-term maintainance release with
   bugfix updates for two years

- After 4.11.0, shift feature development to Frameworks 5 and Plasma
   Workspaces 2, in order to not delay this forever

- Applications are not part of this proposal, we'd need feedback from App
   module maintainers. It doesn't need to be decided along with this proposal
   though. For now, App developers should be encouraged to make releases on top
   of 4.x, and jump onto KF5 when it's ready


What exactly is part of this proposal then? Is it

(a) All modules which are released as part of the KDE SC 4.11, or
(b) only kdelibs, kde-runtime (and kde-workspace)?


clearly the latter,
Make 4.11 Platform and Workspaces...
but may be a good idea to explicitly enumerate which modules that 
includes to avoid any confusion.


With my packager-hat on, this raises some concern about future possible 
version assumptions being broken (ie, packaging that assumes constant 
versioning across all kde core packages).  That's something that will 
have to be dealt with sooner or later (with frameworks5) anyway, so 
maybe it's not necessarily a bad thing.


-- rex

-- rex


___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Better testing of tagged tars

[Rex Dieter]

On 01/31/2013 03:42 PM, Andrea Scarpino wrote:

We, as Arch Linux and Chakra-Project developers would like to propose now
to follow the recommendation set by Dirk Mueller in the last long ml thread
regarding this issue, and have the build packages from the tagged tars
available to our testers during the time period between tagging and release.


Has anyone ever explicitly said making packages available to targetted 
testers was a *bad* idea?


I'm not aware of any, and if they had, I would disagree with them.

In short, more testing is a good thing(tm) and is encouraged.

Keep in mind when I said targetted testers, they need to be aware that 
these are not public or release builds yet, that is all.


-- rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: 4.10 RC1 tarballs available for packagers

[Rex Dieter]

On 12/19/2012 07:30 AM, Anke Boersma wrote:

Seems this commit:
https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/9dd4218a5e16f29ea664c619b295ca1ce382f2cb
makes the package kde-base-artwork obsolete, files from it are duplicated
in kde-workspace build, causing conflicts on installation.


looks more like to me this got committed to the wrong repo (should've 
been to kde-base-artwork instead of kde-workspace)


-- rex


On Tue, Dec 18, 2012 at 7:14 PM, Anke Boersma veritasf...@gmail.com wrote:


Hi

KDE 4.9.95, kdepimlibs lists nepomukcore as optional depend, build fails
without it installed, seems a true depend now.  No issues building with it
installed.

Anke



On Tue, Dec 18, 2012 at 5:56 PM, Albert Astals Cid aa...@kde.org wrote:


The tarballs are in their usual packager-only location (unstable/4.9.95)

I'm attaching the sha1sum of the tarballs and the branches,
hashes/revisions
they were created from.

We have increased the cmake required version from 2.8.8 to 2.8.9 but
2.8.9 was
already needed otherwise kdepimlibs didn't find boost, so not really a
change
;-)

I have built the packages and build fine here

Cheers,
   Albert
___
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



___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: kde-runtime kdelibs dep

[Rex Dieter]

On 12/14/2012 09:52 AM, David Faure wrote:

If I commit the fix in kde-runtime without raising the kdelibs requirement,
then a kdelibs-4.9 + kde-runtime-4.10 user, will end up with a nastier bug,
where copying a directory out of the trash uses the right name, but flattens
out the contents of the directory (a/b/f - a/f).

If I commit the fix in kde-runtime*and*  raise the requirement to kdelibs 4.10
(both of which will be released at the same time), then the bug will be fixed
without such a nasty regression.


imho, kdelibs-4.9 + kde-runtime-4.10 isn't worth worrying too much 
about, and I personally have no problem raising the requirement as you 
suggest.


If that's problematic at all, committing the fix, and issuing some sort 
or build or run time warning recommending kdelibs-4.10 is a compromise.


-- rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Patch needed in phonon-backend-gstreamer for fixing a bug in Dolphin and other players

[Rex Dieter]

On 11/28/2012 06:01 PM, Manuel Tortosa Moreno wrote:

This patch:

https://projects.kde.org/projects/kdesupport/phonon/phonon-
gstreamer/repository/revisions/2db4c430740da89fb22319b2ded63e770f3d6fac

fixes an ugly issue with several players, specially Dragon is affected with a
bug when using the Gstreamer backend,  (double window on clossing, borked
subtitles...)

As there's no new release of the backend yet, we should either consider to
release a tarball including this fix before kde 4.9.4 gets released?


1.  have you talked with phonon devs yet? (cc'ing)

2.  that commit is on master/ branch only currently as far as I can 
tell, not  phonon-gstreamer 4.6 branch (backported/merged/whatever)


-- rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: libkdcraw api compatibility?

[Rex Dieter]

Andreas K. Huettel wrote:

 it seems like there are api-incompatible changes in libkdcraw-4.9.80
 (compared to 4.9.x).
...
 No problem inside KDE proper, and I also know that digikam-3_betaX and
 kipi- plugins-3_betaX is fixed. However... Are there any other known
 third-party consumers for that?

kphotoalbum uses libkdcraw

On a similar note, libkipi also had changes that breaks
kamoso, https://bugs.kde.org/show_bug.cgi?id=307147
and
kphotoalbum, https://bugs.kde.org/show_bug.cgi?id=307148

-- rex

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: 4.9.3 tarballs available (for packagers)

[Rex Dieter]

On 11/06/2012 07:55 AM, Andrea Scarpino wrote:

On Friday 02 November 2012 01:38:55 Albert Astals Cid wrote:

The tarballs can be found in their usual embargo location (available only to
packagers)


Did anyone built qyoto? I cannot build it with cmake 2.8.10, see
https://bugs.kde.org/show_bug.cgi?id=309652 for info.


Confirmed on fedora too, seems to be some sort of regression or behavior 
change in cmake-2.8.10 (I followed up on the bug too).


CC'ing kde-buildsystem list for any insight or comment.

-- rex


___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: The misterious case of oxygen-icons

[Rex Dieter]

On 08/16/2012 06:48 PM, Friedrich W. H. Kossebau wrote:

So anybody objecting to document oxygen-iconset as a hard dependency in
README.packagers in kde-runtime?


no objection, good idea +1

-- rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: The misterious case of oxygen-icons

[Rex Dieter]

On 08/16/2012 05:41 PM, Albert Astals Cid wrote:


Or maybe the answers are

* Why are we releasing it with the SC if it's not part of it?
Because noone else wants to release it

* Why is it not branched?
Becuase it's not really part of the SC

* What should we package with the tarball of oxygen-icons for KDE SC 4.9.1?
http://websvn.kde.org/trunk/kdesupport/oxygen-icons/


If that is the case, I can live with that for KDE SC 4.9.x but for 4.10 I'd
really like it to either live by the rules of the rest of the SC or to get
it's own packager.


I believe your guesses are close to the reality of things

and, I agree with your 4.10 proposal, and releasing it separately 
(particularly because it is so big and gets infrequent updates these 
days), assuming nuno (or someone else) is willing to do so.  else, we 
can go with live by the rules option.


-- rex

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: The misterious case of oxygen-icons

[Rex Dieter]

On 08/16/2012 06:14 PM, Albert Astals Cid wrote:

Do we really have a runtime dependency on oxygen-icons? My limited knowledge
in the matter is that icon names are standarized thus you can use oxygen-icons
or AlbertAwesomeImages (aai for friends) and it'll still work.

Can someone with more knowledge confirm or reject?


technically no, but in practical terms yes.

1.  it's used as a fall back icon theme
2.  if not present, many many icons will be missing all over

-- rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Virtuoso 6.1.5 is buggy

[Rex Dieter]

On 07/17/2012 10:25 AM, Martin Schlander wrote:

Tirsdag den 17. juli 2012 20:38:25 Vishesh Handa skrev:

Please avoid using Virtuoso 6.1.5 with Nepomuk from kde 4.9.


Does that imply virtuoso 6.1.5 + KDE SC 4.8.x is a safe combo?


reportedly yes (or at least better off than 6.1.5 + 4.9 anyway)

-- rex

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Release Team BoF Summary

[Rex Dieter]

On 07/16/2012 03:37 PM, Michael Jansen wrote:

4.5.70 is a stable release for anyone with experience in release numbers


imo, that's a false assumption.  anyone making that mistake deserves 
what they get.


-- rex

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Release Team BoF Summary

[Rex Dieter]

On 07/16/2012 05:41 PM, Rex Dieter wrote:

On 07/16/2012 03:37 PM, Michael Jansen wrote:

4.5.70 is a stable release for anyone with experience in release numbers


imo, that's a false assumption.  anyone making that mistake deserves
what they get.


Hit enter too fast... I'm speaking mostly in terms if items that fall 
under the kde development platform(1) umbrella (or whatever you want 
to call it), so to be in the constructive mode and in case I missed it 
being suggested already,


I would *not* mind tagging the tarballs to highlight the fact they are 
pre-releases, ie,


kdefoo-4.5.70-beta1

As that preserves the ability to do strict numeric-only comparisions

to be clear, what I do mind is stuff of the form:
kdefoo-4.6-beta1

-- rex

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Release Script (KF5)

[Rex Dieter]

On 07/12/2012 12:29 PM, Michael Jansen wrote:

I will implement the ability to skip release for unchanged modules
(fully automated) and would ask everyone here to really think twice
before asking the release team to keep the current practice of releasing
everything. Because there is no reason.


Not exactly no reason.  There's the case that it can be used to simplify 
versioning on pkg interdependencies.


Now, I'd have a much lesser concern if modules that are part of the 'kde 
development platform' at least are never skipped.


-- rex

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Release Script (KF5)

[Rex Dieter]

On 07/12/2012 12:43 PM, Martin Gräßlin wrote:


Now, I'd have a much lesser concern if modules that are part of the 'kde
development platform' at least are never skipped.



Could you explain why?


So, right now I can do a very simple runtime dependency for kde apps:

KDE_DEV_VERSION=$(kde4-config --kde-version | cut -d' ' -f1)

Requires: kde-runtime = $KDE_DEV_VERSION

to ensure that this application pulls in (at least) the version of kde 
stuff used to build it.  (and kde-runtime in turn has versioned 
dependencies on stuff lower than itself in the stack, like kdelibs, 
kdepimlibs, oxygen-icons, nepomuk-core).


An analogue for libraries where the above is simplified to just
Requires: kdelibs = $KDE_DEV_VERSION

Which happens to work quite nicely now in practice.(1)

Now, this will get much more complicated to track if the 'kde 
development platform' is no longer released as a whole and versions 
don't match up.  This, at least from my own POV, is where requests from 
packagers are coming that module inter-dependencies (esp versioning!) be 
clearly documented somewhere.


A lot of this could go away of qt/kde actually used symbol versioning 
too, but I digress... :(


-- rex

(1) A lot of this could go away if qt/kde actually used symbol 
versioning too, but I digress... :(

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Release Script (KF5)

[Rex Dieter]

On 07/12/2012 01:25 PM, Martin Gräßlin wrote:

But apart from that: could we start dreaming? Dreaming of a KDE where every
application clearly defines what dependencies it has and exactly in a way that
packagers can set up the dependencies in an automatic and correct way? Can we
consider going forward with leaving all hacks behind us and not stop the
fixing with the hacks being the reasons?


Yes, please.   My dream includes:

start the work to define this wonderfully well-specified set of 
dependencies *first*, *then* consider dropping all the old assumptions 
and hacks (not before).


-- rex

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KSecrets State?

[Rex Dieter]

On 07/10/2012 09:56 AM, Jeremy Whiting wrote:

It seems it has been moved to playground from kdelibs, but the
application in kdeutils is still sitting there.  Shouldn't that be
moved to playground also until it works?


yes, +1

-- rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.8.5 planning

[Rex Dieter]

On 07/05/2012 11:31 AM, Scott Kitterman wrote:

On Thursday, July 05, 2012 05:01:58 PM Rolf Eike Beer wrote:

Am 05.07.2012 13:00, schrieb Dirk Mueller:

Hi,

I guess with all the kdelibs mess we should redo another 4.8.5
release. Does
anyone have suggestions for a release plan?

I would like to do tagging either tomorrow morning or in the last
July week,
as I'm on vacation in between.

Any preference?


Will that be a normal release (i.e. full KDE SC) or just kdelibs?


This might be a nice time to try only releasing the packages that have
changes.


I think I'd have to object to that in this case.  if you want to try 
experimenting in some later major release, fine, but not in a minor 
point release.


This comes mostly with my fedora packager hat on, where we parse the 
output of:

kde4-config --version
to describe the kde development platform version used and use that for a 
versioned minimal dependency on kde-runtime (or kdelibs as appropriate). 
 Updating just kdelibs without kde-runtime too, would break our 
(apparently naive) assumption.


-- rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.8.5 planning

[Rex Dieter]

On 07/05/2012 12:51 PM, Michael Jansen wrote:


  Also, *before* you start doing partial releases, please present an exact

  definition of the dependencies *between versions*.

As i see that you are on the release-team list. May i ask why you voice
your objections the exact same moment someone wants to try something we
discussed here on the list for quite some time instead of actively
participating this to the discussion before?


So, one the one hand, I do applaud you for your efforts to make things 
suck less release-wise.   Really, really, really I do.  you rock.


On the other hand, I (among at least one other in this recent thread) 
was too busy to chime in earlier.   Yeah, I suck for that.  Boo on me.


But, there was a difference between the brainstorming and *just* talk, 
and then moving to the next step(s) and actually doing it.  at that 
point, folks waved flags that the a proposed change could have bad 
side-effects that affect them directly.


Sorry for that.  Please be patient.  have I mentioned you rock?

-- rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Final soprano release

[Rex Dieter]

On 06/28/2012 11:41 AM, Allen Winter wrote:

On Wednesday 27 June 2012 11:56:05 PM Albert Astals Cid wrote:

El Dimecres, 27 de juny de 2012, a les 17:28:47, Allen Winter va escriure:

On Wednesday 27 June 2012 4:29:06 AM Sebastian Trüg wrote:

done.

On 06/25/2012 11:31 PM, Albert Astals Cid wrote:

Hi Sebastian, any chance to get final 2.8 soprano release soon?



Sebastian,

I installed Soprano git master and it says that version is 2.7.56.
Did you forget to increase the version number in the top-level CMakeLists.txt?


He used the 2.8 branch for the tarball

-- rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: kdebindings-kimono support for Soprano is broken in beta2

[Rex Dieter]

On 06/11/2012 02:00 PM, Manuel Tortosa wrote:

KDEBindings-Kimono can be only compiled with -DWITH_Soprano=OFF

Build error, right during the configure, does not even starts the building:

CMake Error: The following variables are used in this project, but they
are set to NOTFOUND.

Please set them or make sure they are set and tested correctly in the
CMake files:

SOPRANO_INDEX_LIBRARIES (ADVANCED)

linked by target soprano-sharp in directory
/chakra/desktop-unstable/kdebindings-kimono/src/kimono-4.8.90/soprano

-- Configuring incomplete, errors occurred!

Aborting...


Seems ok on my builds,

...
-- Found Soprano: /usr/include
-- Found SharedDesktopOntologies: /usr/share/ontology
-- Found Nepomuk: /usr/lib/kde4/devel/libnepomuk.so;/usr/lib/libsoprano.so
-- Found KdepimLibs: /usr/lib/cmake/KdepimLibs/KdepimLibsConfig.cmake
-- Found Akonadi: /usr/lib/cmake/Akonadi/AkonadiConfig.cmake
-- Build kimono bindings: Akonadi;KHTML;KTextEditor;Nepomuk;Plasma;Soprano
-- Skip kimono bindings:
-
-- The following external packages were located on your system.
-- This installation will have the extra features provided by these 
packages.

-
   * libmono - Mono library
   * Soprano - Soprano libraries
...

verbose log here:

http://kojipkgs.fedoraproject.org/packages/kimono/4.8.90/1.fc18/data/logs/i686/build.log


-- rex

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

kdesdk cmake-bustage, kde4_add_plugin

[Rex Dieter]

Seems some odd cmake borkage is going on trying to build kdesdk-4.8.90 
(4.8.80 suffered the same, but I hadn't noticed then), in that any 
modules using kde4_add_plugin seem to not get compiled with -fPIC 
properly, and fail linking, for example,


dolphin-plugins:
/usr/bin/ld: 
CMakeFiles/fileviewsvnplugin.dir/fileviewsvnplugin_automoc.o: relocation 
R_X86_64_32 against `_ZN17FileViewSvnPlugin16staticMetaObjectE' can not 
be used when making a shared object; recompile with -fPIC


kstartperf:
/usr/bin/ld: CMakeFiles/kstartperf.dir/libkstartperf.o: relocation 
R_X86_64_32 against `.rodata.str1.1' can not be used when making a 
shared object; recompile with -fPIC


blindly replacing kdesdk toplevel CMakeLists.txt with that from 4.8.4 
makes things happy again.  Still trying to track down exactly what's 
going wrong...


-- rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: kdesdk cmake-bustage, kde4_add_plugin

[Rex Dieter]

On 06/10/2012 12:41 PM, Rex Dieter wrote:

Seems some odd cmake borkage is going on trying to build kdesdk-4.8.90
(4.8.80 suffered the same, but I hadn't noticed then), in that any
modules using kde4_add_plugin seem to not get compiled with -fPIC
properly, and fail linking, for example,

dolphin-plugins:
/usr/bin/ld:
CMakeFiles/fileviewsvnplugin.dir/fileviewsvnplugin_automoc.o: relocation
R_X86_64_32 against `_ZN17FileViewSvnPlugin16staticMetaObjectE' can not
be used when making a shared object; recompile with -fPIC

...

blindly replacing kdesdk toplevel CMakeLists.txt with that from 4.8.4 makes 
things happy again.



So, more data:

... = a bunch of -I... includes not relevant,

4.8.4 gets compiled as:

cd .../kdesdk-4.8.4/build/dolphin-plugins/svn  /usr/lib64/ccache/c++ 
 -DMAKE_FILEVIEWSVNPLUGIN_LIB -D_BSD_SOURCE -D_XOPEN_SOURCE=500 
-D_BSD_SOURCE -DQT_NO_STL -DQT_NO_CAST_TO_ASCII -D_REENTRANT 
-DKDE_DEPRECATED_WARNINGS -DKDE4_CMAKE_TOPLEVEL_DIR_LENGTH=48 
-DQT_USE_FAST_CONCATENATION -DQT_USE_FAST_OPERATOR_PLUS 
-Wnon-virtual-dtor -Wno-long-long -ansi -Wundef -Wcast-align 
-Wchar-subscripts -Wall -W -Wpointer-arith -Wformat-security 
-fno-exceptions -DQT_NO_EXCEPTIONS -fno-check-new -fno-common 
-Woverloaded-virtual -fno-threadsafe-statics -fvisibility=hidden 
-Werror=return-type -fvisibility-inlines-hidden -O2 -g -DNDEBUG 
-DQT_NO_DEBUG -fPIC ...   -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -o 
CMakeFiles/fileviewsvnplugin.dir/fileviewsvnplugin_automoc.o -c 
/home/rdieter1/pkgs.fedoraproject.org/kdesdk/foo/kdesdk-4.8.4/build/dolphin-plugins/svn/fileviewsvnplugin_automoc.cpp


and in 4.8.90 this get's compiled with:

cd .../kdesdk-4.8.90/build/dolphin-plugins/svn  /usr/lib64/ccache/c++ 
 -DMAKE_FILEVIEWSVNPLUGIN_LIB -DQT_NO_STL -DQT_NO_CAST_TO_ASCII 
-D_REENTRANT -DKDE_DEPRECATED_WARNINGS 
-DKDE4_CMAKE_TOPLEVEL_DIR_LENGTH=48 -DQT_USE_FAST_CONCATENATION 
-DQT_USE_FAST_OPERATOR_PLUS -O2 -g -DQT_NO_DEBUG ... 
-D_LARGEFILE64_SOURCE -o 
CMakeFiles/fileviewsvnplugin.dir/fileviewsvnplugin_automoc.o -c 
/home/rdieter1/pkgs.fedoraproject.org/kdesdk/foo/kdesdk-4.8.90/build/dolphin-plugins/svn/fileviewsvnplugin_automoc.cpp



many differences (mostly flags being removed), but most noticeable 
causing the immediate issue was -fPIC


any advice, clues, suggestions?

Fedora 17 (and f18/rawhide) here, using cmake-2.8.8-4.fc17

-- rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Packaging 4.9: KSecrets

[Rex Dieter]

On 05/22/2012 06:04 PM, Albert Astals Cid wrote:

I understand we do *not* want KSecrets in 4.9 releases, right?


Right, that seems to be the consensus, including it's maintainer.

-- rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KSecrets State?

[Rex Dieter]

On 05/17/2012 07:01 AM, Anne-Marie Mahfouf wrote:


A few weeks ago, KSecrets working state was challenged and considered as
still alpha but as we could not agree on removing it from 4.8 releases,
it stayed there.
Now is the question on whether it improved for 4.9 and should be kept in
the 4.9 release series or if it should be put in a development area again.
Valentin, what's your opinion? Did people try it through the 4.8
releases and reported problems that you improved? What is your vision
for the future?


My primary issue:

* ksecrets seems to not fully implement the 
org.freedesktop.Secret.Service dbus interface.  In particular, I can't 
get any application that functions with gnome-keyring to function 
properly when ksecrets is installed.  similar to:

http://mail.kde.org/pipermail/ksecretservice-devel/2012-March/000141.html

apps just report: No such method 'ReadAlias' in interface 
'org.freedesktop.Secret.Service' ...


I can't find any open bug at the moment, will file one shortly if my 
continued searches are fruitless.


Another smaller issue:
* a crash in ksecrets' test suite:
https://bugs.kde.org/show_bug.cgi?id=296493
with no reply yet.

Without any positive feedback on either issue, it seems to me that 
ksecrets is doing more harm than good atm, and removing from 4.9 should 
be considered.


-- rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.8.2 tarballs (try#1) uploaded

[Rex Dieter]

On 03/31/2012 01:26 PM, Chusslove Illich wrote:

[: Dirk Mueller :]
Also, please mail release-team@kde.org about any issues you find as
blocking for this release. the plan is to release them tuesday or
wednesday next week.


If also l10n packs are ready, could you check if kde-l10n-sr is around 12
MiB (bz2) and 10 MiB (xz)? If they are less then half of that, the
misterious packaging issue stroke again, and here are the proper ones:

http://nedohodnik.net/kde-sr/kde-l10n-sr-4.8.2.tar.bz2
http://nedohodnik.net/kde-sr/kde-l10n-sr-4.8.2.tar.xz


Seems so,

5.6M kde-l10n-sr-4.8.2.tar.xz

-- rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.8.2 tarballs (try#1) uploaded

[Rex Dieter]

On 03/30/2012 06:38 AM, Max Brazhnikov wrote:

On Fri, 30 Mar 2012 01:33:42 +0200, Dirk Mueller wrote:


Hi,

I just finished uploading the 4.8.2 tarballs. they're xz only for now. I've
created them with pixz(1) meanwhile, so that they're build within reasonable
amount of time.

I've shortly tested it, and all xz variants I have available seem to be able
to handle those files just fine. Let me know if you find a problem with that
approach.

Also, please mail release-team@kde.org about any issues you find as blocking
for this release. the plan is to release them tuesday or wednesday next week.


kde-base-artwork-4.8.2 installs the same ksplash theme that already comes with 
kde-workspace.


Looks like creating that separate kde-base-artwork tarball was a mistake 
(happened in 4.8.1 too, which also differred from 4.8.0)


-- rex

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: kde-base-artwork

[Rex Dieter]

On 01/06/2012 06:31 AM, Jonathan Riddell wrote:


kde-base-artwork has been added in RC 2.  I'm having people worried
that after a release candidate might be too late to rename a module,
I'd think adding one is more likely to be a problem.  This module has
no COPYING file and most problematic its files overlap the contents of
kde-workspace.  I'm not sure what the purpose of it is that is not already 
served by kde-workspace.


kde-base-artwork tarball indeed duplicates content already included in 
kde-workspace-4.7.97's tarball

ksplash/ksplashx/themes/default

I second Jonathan's concerns, and would recommend dropping the separate 
kde-base-artwork too.


(not sure if we ought to be cc'ing kde-packager yet at this point...)

-- rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

kde-4.7.95 's startkde still sets MALLOC_CHECK_

[Rex Dieter]

For better or worse, seems that our kde-4.8rc1 (aka 4.7.95) startkde 
still sets MALLOC_CHECK_ , so we're likely seeing a few more crashes 
than usual.


a bit of deja-vu,
http://lists.kde.org/?l=kde-release-teamm=130979983309914w=2

(Personally, I'm hearing about and witnessing some fun kmail crashes 
that go away with no MALLOC_CHECK_ :

https://bugs.kde.org/show_bug.cgi?id=289693
https://bugs.kde.org/show_bug.cgi?id=289967
)

-- rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.8 RC1 (4.7.95) tarballs uploaded (try#1)

[Rex Dieter]

Phil Miller wrote:

 KDE has some issues with qt-4.8.0.
 
 One of it is regarding QUrl.toLocalfile:
 
 https://bugzilla.redhat.com/show_bug.cgi?id=749213

probably of more interest is following these,
https://bugreports.qt.nokia.com//browse/QTBUG-22382
and it's impact on kde:
http://bugs.kde.org/show_bug.cgi?id=285028

 Patching qt with followed patch fixes it:
 
 qt-everywhere-opensource-src-4.8.0-QUrl_toLocalFile.patch

Not exactly fix, but more of a workaround to restore qt47 behavior in the 
meantime.

-- rex

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Request: remove libkactivites from kdelibs (in experimental/)

[Rex Dieter]

On 11/04/2011 05:05 PM, Aaron J. Seigo wrote:

we currently have libkactivities in kdelibs/experimental. due to upcoming
changs and frameworks 5 development, it has been moved into its own git
repository: kactivities.

i would like to request approval to remove it from kdelibs/experimental and
make the kactivities repository a dependency for kde-workspace.


+1, ok with me...

-- rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: adding a QA responsibility to the release team??

[Rex Dieter]

On 09/17/2011 11:59 AM, Giorgos Tsiapaliwkas wrote:


So,i propose a new timeline addition in which we will check our tarballs
better and a new bugzilla compoment in which we will be able to
report regressions and critical bugs which hasn't been fixed.


There's already a week between initial tarball creation (for packagers) 
and official release.  Are you proposing making this longer? or... some 
other workflow?


2 additional comments:
* I think it may be unwise to conflate release engineering with QA, they 
really are 2 distinct items (though obviously interelated).
* I'm also of a mind there's no special need for additional bugzilla 
components... in the past, when/if regressions or blockers identified in 
our week, they were dealt-with appropriately.


-- rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Forgot to backport changes in kde-runtime

[Rex Dieter]

On 07/25/2011 10:26 AM, Vishesh Handa wrote:
 Hey Release team

 I'd posted on the list about 10 days ago about the need to backport a
 lot of Nepomuk commits. One of which was extremely important and fixed
 file indexing. ( The others were very trivial stuff that didn't really
 matter ). I apparently forgot to push that one important commit. ( Yes,
 I'm an idiot! )

 Could you guys please repackage kde-runtime? I've just backported the
 commits.

for posterity, what commit(s) precisely?

-- rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: kdelibs and kate , quasi circular dependency

[Rex Dieter]

On 07/21/2011 09:03 AM, Milian Wolff wrote:
 Milian Wolff, 21.07.2011:
 Rex Dieter, 21.07.2011:
 Hi, been working on the adapting packaging for our new split tarball
 world order, and have run into a bit of a quandry wrt kdelibs and kate.

 Prior to the split, libktexteditor and katepart were nicely bundled
 together in kdelibs.  So, anything linking libktexteditor naturally had
 an implementation available, and it just worked.  This is no longer
 true.

 This is not true. KDELibs never shipped an implementation of the
 interfaces. You always needed kate installed from kdesdk for those apps to
 work.

 Or thinking about it: I'm actually not sure, was katepart in SVN days in
 kdelibs? Anyhow, if so the solution would be to split kate tarball and
 create a katepart package that other packages can depend on.

Yes it was.  That's my point.  I guess I'm implicitly arguing that 
splitting libktexteditor and katepart into separate pieces is arguably a 
*bad idea*, at least packaging-wise.

still wondering how other (particularly rpm-based) packagers are 
handling this case...

-- rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Too generic name of mobipocket tarball.

[Rex Dieter]

On 07/15/2011 08:56 AM, Philip Muskovac wrote:

 We (the kubuntu team) were discussing the package name for mobipocket
 and in our opinion 'mobipocket' is a far too generic name for the
 tarball since it's not the only source that deals with mobipocket files
 and doesn't contain a mobipocket application either as you would think
 seeing how the other tarballs are named. Can that be renamed into
 kdegraphics-mobipocket or similiar so the tarball name has some relation
 to it's contents?

I think the only reason there is anything named with a kdegraphics- 
prefix anymore, as those pieces are still coming from the classic svn 
kdegraphics module.  Otherwise, tarballs are (arbitrarily) named after 
their new git module.

See also the KDE 4.7 beta 2 as monolitic tarballs. threads on this and 
buildsystem lists for some background (and more gnashing of teeth)

-- rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: RFC: Release Management Going Forward

[Rex Dieter]

Sebastian Kügler wrote:

 Let me dump my brain and add how I see release management going forward
 from here:
 
 = KDE SC 4.x =
 * monolithic tarballs, layout like 4.6.0 release
 * no disruption in packages
 * git migration should not have effect on released tarball layout to keep
   packagers' lives easy
 * optional split tarballs (split/ subdirectory?)

I would welcome this immensely, even if a bit late.

I know a couple distros (fedora, kubuntu at least) had serious complaints 
about the the current tarball splitting, but have begrudingly been putting 
in a lot of effort to adapt anyway for lack of repreive.

-- rex

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: RFC: Release Management Going Forward

[Rex Dieter]

On 06/27/2011 02:49 PM, Alexander Neundorf wrote:
 On Friday 24 June 2011, Nicolas Alvarez wrote:
 ...
 I tried an ExternalProject-based approach before for kdeedu. The main
 inherent and unavoidable disadvantage is that 'make' alone will *install*
 the subprojects.

 Yes, that's unavoidable.
 Serious question: is this a problem ?
 You can still use DESTDIR.

A little, but I suppose it'll be a little less bad as long as:

rm -rf $DESTDIR
make install DESTDIR=$DESTDIR

still works (later).

-- Rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: RFC: Release Management Going Forward

[Rex Dieter]

On 06/22/2011 02:16 PM, Alexander Neundorf wrote:
 On Wednesday 22 June 2011, Rex Dieter wrote:

 To be clear, this can make reproducible 4.7.x tarballs, or just 4.7
 branch snapshots? or both?

 What do you mean with reproducible 4.7.x tarballs exactly ?
 Get the sources from git tags ?

Yes (ie, to duplicate released tarballs essentially).

-- Rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: kdegraphics 4.6.4 tarball contains the wrong okular

[Rex Dieter]

On 06/20/2011 03:09 PM, Dirk Mueller wrote:
 On Friday 17 June 2011, Albert Astals Cid wrote:

 with 4.x) or because the newest Okular tag is v4.6.1 in git repo..

 okular was taken from svn, simply because thats the way it used to be at the
 beginning when I tagged 4.6.2, and nobody told me that I should switch to the
 git version, so I didn't.

There was this,
http://mail.kde.org/pipermail/release-team/2011-May/004835.html
mentioning the completion of the move of the kdegraphics items.

-- Rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: git migration, next steps: proposal

[Rex Dieter]

On 06/07/2011 12:49 PM, Arkadiusz Miskiewicz wrote:

 Now if I have big kde tarball and I want to split into smaller pieces I have
 to figure out which file is used by what and then put that file into proper
 separate subpackage. With split tarballs I don't have to do such guessing.
 It's already done.

Right. While there are some advocating against any and all tarball 
splits (Kevin, Erik, others?), I think there are a good number 
(including Scott, myself and other fedora packagers minus Kevin) that 
are asking for only well-planned split tarballs.

With that in mind, I'd propose:

* for any module (in the classic svn sense) not-yet fully migrated to 
git (ie, that is currently in the frankenstein half-split state), 
continue to distribute it as a single monolithic tarball.

I'm assuming this is technically feasible.  If not, the point is moot 
(and why are we having this conversation? :) ).

-- Rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: git migration, next steps

[Rex Dieter]

On 06/03/2011 09:19 AM, Jeremy Whiting wrote:

 As you may or may not know kdeaccessibility and kdeutils are ready to
 migrate to git (when the freeze is over, don't worry).  And we'd like to
 know what the feeling is about the best time to migrate to minimize
 packaging/releasing stresses.  We'd also like to know what
 packagers/release-team think of the split repos already done in kde-edu,
 etc. Should we provide artificial monolithic tarballs?

I would advocate for monolithic tarballs (again) in general (not just 
kdeedu), the current quasi-arbitrary half-done hodge-podge kde-4.6.80 
tarballs are quite a mess (with both my packager and release-team hats on).

Split tarballs *after* migrations are final and where it can be 
carefully planned and executed would be more welcome, say for kde-4.8.

-- Rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: git migration, next steps

[Rex Dieter]

On 06/03/2011 10:56 AM, Ian Monroe wrote:

 It's still release-team@kde.org not release-team-ark,
 release-team-marble etc etc. Why would split tarballs for 4.7 be an
 uncoordinated shambles? So far the main reason against it seems to be
 that it would be kind of a pain in dealing with your internal
 bureaucracy of adding new SRPMs.

It's that, and a lot more.  Fact is, the current source tarballs 
situation with 4.6.80 is inconsistent and (at least feels) unplanned. 
Seems to me, git repo splits were done only for convenience of 
developers (and rightly so), but without any forethought to the 
implications that had on source distribution and packagers.  The latter 
ought to be well-planned and discussed ahead-of-time, not rushed in as 
an afterthought.

-- Rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: git migration, next steps

[Rex Dieter]

On 06/03/2011 10:56 AM, Ian Monroe wrote:

 It's still release-team@kde.org not release-team-ark,
 release-team-marble etc etc. Why would split tarballs for 4.7 be an
 uncoordinated shambles? So far the main reason against it seems to be
 that it would be kind of a pain in dealing with your internal
 bureaucracy of adding new SRPMs.

(cc'ing -packagers)

It's that, and a lot more.  Fact is, the current source tarballs 
situation with 4.6.80 is inconsistent and (at least feels) unplanned. 
Seems to me, git repo splits were done only for convenience of 
developers (and rightly so), but without any forethought to the 
implications that had on source distribution and packagers.  The latter 
ought to be well-planned and discussed ahead-of-time, not rushed in as 
an afterthought.

-- Rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Minor Point Relase Policy Draft

[Rex Dieter]

 http://techbase.kde.org/Policies/Minor_Point_Release_Policy/Draft
 I did some edits.

 So did anyone have a look at my edits to that page? Do they make sense for
 you? It's something we could agree on?

Agreement from me.

-- Rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: [PATCH] Re: KDE 4.6.0: go or no go?

[Rex Dieter]

On 01/20/2011 07:00 AM, Dirk Mueller wrote:
 On Wednesday 19 January 2011, Dirk Mueller wrote:

 so the general consensus seems to be against slipping the schedule and
 inserting a RC3.

 This means that we need to solve bug 246678. Given that there seems to be
 no fix in sight (no comment in the last 14 days), can we mitigate it. is
 there a way to disable whatever causes the problem by default? what would
 be the patch for that?

 I think the attached patch should make the services be disabled by default,
 thereby avoiding kde bug 246678. I'm asking for a review and a comment whether
 we can go ahead with this workaround for KDE 4.6.0.

 As the general consensus was (previously) already against slipping the
 schedule, I need a solution NOW to be able to release 4.6.0 in time.

With my release-team hat on, said patch is an acceptable workaround for 
now, though simply disabling the nepomuk krunner seemed to be enough for 
some.

-- Rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: [PATCH] Re: KDE 4.6.0: go or no go?

[Rex Dieter]

On 01/20/2011 02:05 PM, Alexander Neundorf wrote:
 On Thursday 20 January 2011, Ian Monroe wrote:
 On Thu, Jan 20, 2011 at 12:20, Alexander Neundorfneund...@kde.org  wrote:
 On Thursday 20 January 2011, Dirk Mueller wrote:
 On Wednesday 19 January 2011, Dirk Mueller wrote:
 so the general consensus seems to be against slipping the schedule and
 inserting a RC3.

 This means that we need to solve bug 246678. Given that there seems to
 be no fix in sight (no comment in the last 14 days), can we mitigate
 it. is there a way to disable whatever causes the problem by default?
 what would be the patch for that?

 Hi,

 I think the attached patch should make the services be disabled by
 default, thereby avoiding kde bug 246678. I'm asking for a review and a
 comment whether we can go ahead with this workaround for KDE 4.6.0.

 As the general consensus was (previously) already against slipping the
 schedule, I need a solution NOW to be able to release 4.6.0 in time.

 Did you try building KDE 4.6.0 with CMake 2.8.4rc1 ?

 If not, please do so.

 There has been a relatively significant change in it wrt to how include()
 and find_package() find their files (now when a file which is part of
 cmake calls include() or find_package() it first looks in
 CMAKE_ROOT/share/cmake/Modules/ instead of first looking in
 CMAKE_MODULE_PATH).

 I didn't have a lot of time since mid of December, so I didn't get around
 to give it a try. Also today I won't have the time and then there's
 already weekend, and I won't return before late Sunday.
 If it breaks (should error out somewhere related to
 FindPackageHandleStandardArgs), please let me know.
 Setting cmake policy CMP0017 to NEW should fix this breakage if it
 occurs. This would have to be done at the top of FindKDE4Internal.cmake
 where the other policies are set too, inside a if(POLICY CMP0017) guard.

 IMO if this breakge occurs, this is something which we *must* fix before
 the 4.6.0 release. I spent basically months of arguing and testing about
 this issue with the cmake devs to get this new behaviour (without the new
 behaviour KDE 4.5.0/4.5.1 would have broken cmake 2.8.3, or the other way
 round, depending on how you see it) into cmake.

 Delaying 4.6.0 at this point due to a cmake that barely any distros
 are using seems quite foolish to me (assuming it is an issue).

 No, this is not foolish.
 All distros will use cmake= 2.8.4 in the future.
 It would mean that KDE 4.6.0 will forever be unbuildable with any cmake=
 2.8.4.

 This is the code which would have to go into FindKDE4Internal.cmake in case of
 breakage:

Looks ok to me, just built kdebase-runtime-4.5.95 with cmake-2.8.4-rc1 
yesterday (is that a good enough test?).

-- Rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Re: KDE 4.6.0 and cmake-2.8.4-rc1

[Rex Dieter]

On 01/20/2011 02:20 PM, Alexander Neundorf wrote:
 On Thursday 20 January 2011, Rex Dieter wrote:

 This is the code which would have to go into FindKDE4Internal.cmake in
 case of breakage:

 Looks ok to me, just built kdebase-runtime-4.5.95 with cmake-2.8.4-rc1
 yesterday (is that a good enough test?).

 Hmm, not necessarily.
 Were there warnings about files being shadowed, mentioning CMP0017 issued by
 cmake ?

Yes there were lots of warnings. :(

For gory details,

http://kojipkgs.fedoraproject.org/packages/kdebase-runtime/4.5.95/3.fc15/data/logs/i686/build.log

  kdelibs would be good.

I'll try that next.

 Make sure all packages which are found with 2.8.3 are also found with
 2.8.4rc1.

I believe everything was found in the kdebase-runtime build, but I'll do 
some double-checking.

-- Rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDEPIM 4.6 beta4 (second try)

[Rex Dieter]

On 01/10/2011 09:15 AM, Allen Winter wrote:

 See /pub/kde/unstable/kdepim/4.5.94.1 on your ftp.kde.org mirror.

 0243aa59c3acd9c38403b3acddb33c22c9c39c65  kdepim-4.5.94.1.tar.bz2
 f226165cd7f92524be354329097e5009b5754046  kdepim-runtime-4.5.94.1.tar.bz2

builds ok, but contains locale/translation conflicts between 
kdepim-runtime-4.5.94.1 and kde-l10n-4.5.95.  Ugh.  Here's an example 
wrt kde-l10n-de:

/usr/share/locale/de/LC_MESSAGES/accountwizard_ical.mo
/usr/share/locale/de/LC_MESSAGES/accountwizard_imap.mo
/usr/share/locale/de/LC_MESSAGES/accountwizard_kolab.mo
/usr/share/locale/de/LC_MESSAGES/accountwizard_mailbox.mo
/usr/share/locale/de/LC_MESSAGES/accountwizard_maildir.mo
/usr/share/locale/de/LC_MESSAGES/accountwizard.mo
/usr/share/locale/de/LC_MESSAGES/accountwizard_pop3.mo
/usr/share/locale/de/LC_MESSAGES/akonadi_birthdays_resource.mo
/usr/share/locale/de/LC_MESSAGES/akonadi_contacts_resource.mo
/usr/share/locale/de/LC_MESSAGES/akonadi_davgroupware_resource.mo
/usr/share/locale/de/LC_MESSAGES/akonadi-filestore.mo
/usr/share/locale/de/LC_MESSAGES/akonadi_ical_resource.mo
/usr/share/locale/de/LC_MESSAGES/akonadi_imap_resource.mo
/usr/share/locale/de/LC_MESSAGES/akonadi_invitations_agent.mo
/usr/share/locale/de/LC_MESSAGES/akonadi_kabc_resource.mo
/usr/share/locale/de/LC_MESSAGES/akonadi_kcal_resource.mo
/usr/share/locale/de/LC_MESSAGES/akonadi_kdeaccounts_resource.mo
/usr/share/locale/de/LC_MESSAGES/akonadi_knut_resource.mo
/usr/share/locale/de/LC_MESSAGES/akonadi_kolabproxy_resource.mo
/usr/share/locale/de/LC_MESSAGES/akonadi_kresourceassistant.mo
/usr/share/locale/de/LC_MESSAGES/akonadi_localbookmarks_resource.mo
/usr/share/locale/de/LC_MESSAGES/akonadi_maildir_resource.mo
/usr/share/locale/de/LC_MESSAGES/akonadi_maildispatcher_agent.mo
/usr/share/locale/de/LC_MESSAGES/akonadi_mailtransport_resource.mo
/usr/share/locale/de/LC_MESSAGES/akonadi_mbox_resource.mo
/usr/share/locale/de/LC_MESSAGES/akonadi_microblog_resource.mo
/usr/share/locale/de/LC_MESSAGES/akonadi_mixedmaildir_resource.mo
/usr/share/locale/de/LC_MESSAGES/akonadi_nepomukfeeder.mo
/usr/share/locale/de/LC_MESSAGES/akonadi_nepomuktag_resource.mo
/usr/share/locale/de/LC_MESSAGES/akonadi_nntp_resource.mo
/usr/share/locale/de/LC_MESSAGES/akonadi_openxchange_resource.mo
/usr/share/locale/de/LC_MESSAGES/akonadi_pop3_resource.mo
/usr/share/locale/de/LC_MESSAGES/akonadi_serializer_plugins.mo
/usr/share/locale/de/LC_MESSAGES/akonadi_singlefile_resource.mo
/usr/share/locale/de/LC_MESSAGES/akonaditray.mo
/usr/share/locale/de/LC_MESSAGES/akonadi_vcarddir_resource.mo
/usr/share/locale/de/LC_MESSAGES/akonadi_vcard_resource.mo
/usr/share/locale/de/LC_MESSAGES/kabc_akonadi.mo
/usr/share/locale/de/LC_MESSAGES/kaddressbookmigrator.mo
/usr/share/locale/de/LC_MESSAGES/kcal_akonadi.mo
/usr/share/locale/de/LC_MESSAGES/kcm_akonadi.mo
/usr/share/locale/de/LC_MESSAGES/kio_akonadi.mo
/usr/share/locale/de/LC_MESSAGES/kjotsmigrator.mo
/usr/share/locale/de/LC_MESSAGES/kmail-migrator.mo
/usr/share/locale/de/LC_MESSAGES/kres-migrator.mo
/usr/share/locale/de/LC_MESSAGES/kresources_shared_akonadi.mo
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: can kdebase-4.5.4 depend on kdelibs = 4.5.4?

[Rex Dieter]

On 11/27/2010 01:29 PM, Chani wrote:
 [please CC]
 
 erk. I just backported a bugfix to 4.5 - but it needs a new function in 
 kdelibs. which makes kdebase depend on 4.5.4 for that function.
 but, ade tells me that it might not be allowed to depend on anything more 
 than 
 4.5.0.
 is this true? :/  ('cause then I'll have to revert. wah.)

Personally, I'm ok with it.

After a quick hunt through techbase.kde.org, I was unable to find
anything that strictly forbids this.  I'm fairly certain I recall
precedent of this being done in the past as well.

-- Rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.6 Beta1 tarballs (4.5.80) uploaded

[Rex Dieter]

On 11/22/2010 10:24 AM, Rex Dieter wrote:
 On 11/19/2010 01:44 PM, Dirk Mueller wrote:

 Hi, 

 I just finished uploading the first set of tarballs.. I believe I need a 
 couple 
 of more tarballs for those to work properly (akonadi etc), working on  that 
 now. 

 Please let me know of urgent fixes/compile issues in those tar balls. 
 
 kget fail,
 
 kdenetwork-4.5.80/kget/transfer-plugins/bittorrent/bttransferfactory.cpp:28:10:
 error: 'InitLibKTorrent' is not a member of 'bt'
 
 Using latest libktorrent-1.0.4, seems to come from this commit,
 http://websvn.kde.org/?view=revisionrevision=1172082
 
 Need a newer libktorrent release too?

Looks like it, the function has added to libktorrent only very recently,
http://gitweb.kde.org/libktorrent.git/commitdiff/455666929e36028b3bba52016a9e7e58eb02ef86

-- Rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.6 Beta1 tarballs (4.5.80) uploaded

[Rex Dieter]

On 11/19/2010 01:44 PM, Dirk Mueller wrote:

 I just finished uploading the first set of tarballs.. I believe I need a 
 couple 
 of more tarballs for those to work properly (akonadi etc), working on  that 
 now. 
 
 Please let me know of urgent fixes/compile issues in those tar balls. 

Need a newer soprano release (= 2.5.60).

-- Rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.6 Beta1 tarballs (4.5.80) uploaded

[Rex Dieter]

On 11/19/2010 01:44 PM, Dirk Mueller wrote:
 
 Hi, 
 
 I just finished uploading the first set of tarballs.. I believe I need a 
 couple 
 of more tarballs for those to work properly (akonadi etc), working on  that 
 now. 
 
 Please let me know of urgent fixes/compile issues in those tar balls. 

Can't find any required polkit-qt-1 = 0.98.1 release either.

-- Rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.6 Beta1 tarballs (4.5.80) uploaded

[Rex Dieter]

On 11/19/2010 01:44 PM, Dirk Mueller wrote:
 
 Hi, 
 
 I just finished uploading the first set of tarballs.. I believe I need a 
 couple 
 of more tarballs for those to work properly (akonadi etc), working on  that 
 now. 
 
 Please let me know of urgent fixes/compile issues in those tar balls. 

Oh boy, another one,

   * Akonadi (1.4.52 or higher)  http://pim.kde.org/akonadi
 Akonadi server libraries (from kdesupport)
 Akonadi is required to build KdepimLibs.

-- Rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.5.2 tarballs (try#1 uploaded)

[Rex Dieter]

On 10/01/2010 11:38 AM, Dirk Mueller wrote:
 
 Hi, 
 
 I just finished uploading the first set of KDE 4.5.2 tarballs. Tentatively 
 release is tuesday next week. 
 
 Please report any failures to me that would justify a tarball respin. if in 
 doubt. please mail. 

I'm seeing a kdebindings failure inside of the python bindings,

[ 69%] Building CXX object
python/pykde4/CMakeFiles/python_module_PyKDE4_kio.dir/sip/kio/sipkiopart0.o
cd
/builddir/build/BUILD/kdebindings-4.5.2/x86_64-redhat-linux-gnu/python/pykde4
 /usr/bin/c++   -Dpython_module_PyKDE4_kio_EXPORTS -D_BSD_SOURCE
-D_XOPEN_SOURCE=500 -D_BSD_SOURCE -DQT_NO_STL -DQT_NO_CAST_TO_ASCII
-D_REENTRANT -DKDE_DEPRECATED_WARNINGS -DQT3_SUPPORT -D_REENTRANT
-DQT_CORE_LIB -DQT_GUI_LIB -DUSING_SOPRANO_NRLMODEL_UNSTABLE_API -O2 -g
-pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic  -Wnon-virtual-dtor
-Wno-long-long -ansi -Wundef -Wcast-align -Wchar-subscripts -Wall -W
-Wpointer-arith -Wformat-security -fno-exceptions -DQT_NO_EXCEPTIONS
-fno-check-new -fno-common -Woverloaded-virtual -fno-threadsafe-statics
-fvisibility=hidden -fvisibility-inlines-hidden -O2 -DNDEBUG
-DQT_NO_DEBUG -fPIC
-I/builddir/build/BUILD/kdebindings-4.5.2/x86_64-redhat-linux-gnu/python/pykde4
-I/builddir/build/BUILD/kdebindings-4.5.2/python/pykde4
-I/builddir/build/BUILD/kdebindings-4.5.2
-I/builddir/build/BUILD/kdebindings-4.5.2/x86_64-redhat-linux-gnu
-I/usr/include/kde4 -I/usr/include/kde4/KDE -I/usr/include/KDE
-I/usr/include/phonon -I/usr/include/QtXmlPatterns -I/usr/include/QtXml
-I/usr/include/QtWebKit -I/usr/include/QtUiTools -I/usr/include/QtTest
-I/usr/include/QtSvg -I/usr/include/QtSql -I/usr/include/QtScriptTools
-I/usr/include/QtScript -I/usr/include/QtOpenGL -I/usr/include/QtNetwork
-I/usr/include/QtMultimedia -I/usr/include/QtHelp
-I/usr/include/QtDesigner -I/usr/include/QtDeclarative
-I/usr/include/QtDBus -I/usr/include/Qt3Support -I/usr/include/QtGui
-I/usr/include/QtCore -I/usr/include/Qt -I/usr/lib64/qt4/mkspecs/default
-I/usr/include/python2.7 -I/usr/include/kde4/solid
-I/usr/include/kde4/kio -I/usr/include/kde4/kdeprint
-I/usr/include/kde4/kdeprint/lpr -I/usr/include/kde4/dom
-I/usr/include/kde4/ksettings -I/usr/include/kde4/knewstuff2
-I/usr/include/kde4/dnssd   -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -o
CMakeFiles/python_module_PyKDE4_kio.dir/sip/kio/sipkiopart0.o -c
/builddir/build/BUILD/kdebindings-4.5.2/x86_64-redhat-linux-gnu/python/pykde4/sip/kio/sipkiopart0.cpp
...
/usr/include/kde4/kio/tcpslavebase.h: In function 'PyObject*
slot_KIO_TCPSlaveBase_SslResult___xor__(PyObject*, PyObject*)':
/usr/include/kde4/kio/tcpslavebase.h:63:10: error: 'enum
KIO::TCPSlaveBase::SslResultDetail' is protected
/usr/share/sip/PyQt4/QtCore/qglobal.sip:320:95: error: within this context
/usr/include/kde4/kio/tcpslavebase.h: In function 'PyObject*
slot_KIO_TCPSlaveBase_SslResult___or__(PyObject*, PyObject*)':
/usr/include/kde4/kio/tcpslavebase.h:63:10: error: 'enum
KIO::TCPSlaveBase::SslResultDetail' is protected
/usr/share/sip/PyQt4/QtCore/qglobal.sip:315:95: error: within this context

Using the latest sip-4.11.1 , PyQt4-4.7.7 here.  A problem with PyQt4's
qglobal.sip ?

-- Rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.5.2 tarballs (try#1 uploaded)

[Rex Dieter]

On 10/02/2010 09:14 AM, Rex Dieter wrote:
 On 10/01/2010 11:38 AM, Dirk Mueller wrote:

 Hi, 

 I just finished uploading the first set of KDE 4.5.2 tarballs. Tentatively 
 release is tuesday next week. 

 Please report any failures to me that would justify a tarball respin. if in 
 doubt. please mail. 
 
 I'm seeing a kdebindings failure inside of the python bindings,
 
 [ 69%] Building CXX object
 python/pykde4/CMakeFiles/python_module_PyKDE4_kio.dir/sip/kio/sipkiopart0.o
 cd
 /builddir/build/BUILD/kdebindings-4.5.2/x86_64-redhat-linux-gnu/python/pykde4
  /usr/bin/c++   -Dpython_module_PyKDE4_kio_EXPORTS -D_BSD_SOURCE
 -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -DQT_NO_STL -DQT_NO_CAST_TO_ASCII
 -D_REENTRANT -DKDE_DEPRECATED_WARNINGS -DQT3_SUPPORT -D_REENTRANT
 -DQT_CORE_LIB -DQT_GUI_LIB -DUSING_SOPRANO_NRLMODEL_UNSTABLE_API -O2 -g
 -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
 --param=ssp-buffer-size=4 -m64 -mtune=generic  -Wnon-virtual-dtor
 -Wno-long-long -ansi -Wundef -Wcast-align -Wchar-subscripts -Wall -W
 -Wpointer-arith -Wformat-security -fno-exceptions -DQT_NO_EXCEPTIONS
 -fno-check-new -fno-common -Woverloaded-virtual -fno-threadsafe-statics
 -fvisibility=hidden -fvisibility-inlines-hidden -O2 -DNDEBUG
 -DQT_NO_DEBUG -fPIC
 -I/builddir/build/BUILD/kdebindings-4.5.2/x86_64-redhat-linux-gnu/python/pykde4
 -I/builddir/build/BUILD/kdebindings-4.5.2/python/pykde4
 -I/builddir/build/BUILD/kdebindings-4.5.2
 -I/builddir/build/BUILD/kdebindings-4.5.2/x86_64-redhat-linux-gnu
 -I/usr/include/kde4 -I/usr/include/kde4/KDE -I/usr/include/KDE
 -I/usr/include/phonon -I/usr/include/QtXmlPatterns -I/usr/include/QtXml
 -I/usr/include/QtWebKit -I/usr/include/QtUiTools -I/usr/include/QtTest
 -I/usr/include/QtSvg -I/usr/include/QtSql -I/usr/include/QtScriptTools
 -I/usr/include/QtScript -I/usr/include/QtOpenGL -I/usr/include/QtNetwork
 -I/usr/include/QtMultimedia -I/usr/include/QtHelp
 -I/usr/include/QtDesigner -I/usr/include/QtDeclarative
 -I/usr/include/QtDBus -I/usr/include/Qt3Support -I/usr/include/QtGui
 -I/usr/include/QtCore -I/usr/include/Qt -I/usr/lib64/qt4/mkspecs/default
 -I/usr/include/python2.7 -I/usr/include/kde4/solid
 -I/usr/include/kde4/kio -I/usr/include/kde4/kdeprint
 -I/usr/include/kde4/kdeprint/lpr -I/usr/include/kde4/dom
 -I/usr/include/kde4/ksettings -I/usr/include/kde4/knewstuff2
 -I/usr/include/kde4/dnssd   -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -o
 CMakeFiles/python_module_PyKDE4_kio.dir/sip/kio/sipkiopart0.o -c
 /builddir/build/BUILD/kdebindings-4.5.2/x86_64-redhat-linux-gnu/python/pykde4/sip/kio/sipkiopart0.cpp
 ...
 /usr/include/kde4/kio/tcpslavebase.h: In function 'PyObject*
 slot_KIO_TCPSlaveBase_SslResult___xor__(PyObject*, PyObject*)':
 /usr/include/kde4/kio/tcpslavebase.h:63:10: error: 'enum
 KIO::TCPSlaveBase::SslResultDetail' is protected
 /usr/share/sip/PyQt4/QtCore/qglobal.sip:320:95: error: within this context
 /usr/include/kde4/kio/tcpslavebase.h: In function 'PyObject*
 slot_KIO_TCPSlaveBase_SslResult___or__(PyObject*, PyObject*)':
 /usr/include/kde4/kio/tcpslavebase.h:63:10: error: 'enum
 KIO::TCPSlaveBase::SslResultDetail' is protected
 /usr/share/sip/PyQt4/QtCore/qglobal.sip:315:95: error: within this context
 
 Using the latest sip-4.11.1 , PyQt4-4.7.7 here.  A problem with PyQt4's
 qglobal.sip ?

Looks like it is indeed a change to qglobal.sip , maybe this diff to the
latest PyQt4 snapshot will help (verifying builds now),

--- ./PyQt-x11-gpl-4.7.7/sip/QtCore/qglobal.sip 2010-09-20
08:10:28.0 -0500
+++ ./PyQt-x11-gpl-snapshot-4.8-03f4f0257fd5/sip/QtCore/qglobal.sip
2010-10-01 21:38:47.0 -0500
@@ -312,12 +312,12 @@
 // Qt.Alignment class.
 QFlags operator|(int f);
 %MethodCode
-sipRes = new QFlags(*a0 | (ENUM(a1)));
+sipRes = new QFlags(*a0 | a1);
 %End

 QFlags operator^(int f);
 %MethodCode
-sipRes = new QFlags(*a0 ^ (ENUM(a1)));
+sipRes = new QFlags(*a0 ^ a1);
 %End

 // These are necessary to prevent Python comparing object IDs.


-- Rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDEPIM 4.5Beta1

[Rex Dieter]

On 06/30/2010 12:51 PM, Allen Winter wrote:
 Howdy,

 kdepim 4.5 beta1 has been tagged (tags/kdepim/kdepim-4.5beta1) and I created
 a tarball for your compiling and packaging pleasure.

 The tarball will be showing up on the public KDE mirrors soon.
 Look in the /pub/kde/unstable/kdepim/kdepim-4.5-beta1.tar.bz2

 Let me know if you encounter any problems with this tarball.

Silly question, what kdepim-runtime should be used with this (or is it 
included in the aforementioned tarball too)?

-- Rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Thoughts on freeze policy for kdesdk/scripts?

[Rex Dieter]

On 06/24/2010 06:38 PM, Michael Pyne wrote:

 I'm wondering if we have any special policy/exemptions for the development
 freeze for the scripts in kdesdk/scripts. Typically they are for use by KDE
 platform developers and so it seems to me that they wouldn't necessarily fall
 under a development freeze like the Software Compilation or Platform.

I think I would agree.

-- Rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: 4.4.5?

[Rex Dieter]

On 05/31/2010 08:36 AM, Allen Winter wrote:
 Do we want to make a 4.4.5 release?

 Seems like we could make a 4.4.5 in late June,  since 4.5.0 is due  early 
 August.

 If we want 4.4.5, I propose the schedule:
 June 24th, 2010: Tag KDE 4.4.5
 June 29th, 2010: Release KDE 4.4.5

 I vote yes.

yes +1

-- Rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.5 Beta 1 (4.4.80) uploaded for testing

[Rex Dieter]

On 05/26/2010 11:56 AM, Dirk Mueller wrote:
 On Tuesday 25 May 2010, Rex Dieter wrote:

 It seems 4.5b1 needs newer and as-yet unreleased versions of both
 akonadi (1.3.60+) and soprano (2.4.63+).  Can we get tarballs for those
 these?

 http://download.akonadi-project.org/akonadi-1.3.80.tar.bz2

Is this supposed to be 1.3.60 or 1.3.80 ?  the tarball is obviously 
1.3.80, but CMakeLists.txt inside says 1.3.60.

-- Rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.5 Beta 1 (4.4.80) uploaded for testing

[Rex Dieter]

On 05/21/2010 08:42 AM, Raymond Wooninck wrote:
 On Friday 21 May 2010 14:31:42 Andrea Scarpino wrote:
 On Thursday May 20 2010 16:11:47 Dirk Mueller wrote:

 just finished uploading the first set of tarballs for KDE 4.5 Beta1.
 Currently kdepim is skipped intentionally from KDE 4.5.
...
 kdelibs build fails with:

 [ 23%] Building CXX object
 nepomuk/query/CMakeFiles/nepomukquery.dir/result.o
 /build/src/kdelibs-4.4.80/nepomuk/query/result.cpp: In member function
 'bool Nepomuk::Query::Result::operator==(const Nepomuk::Query::Result)
 const': /build/src/kdelibs-4.4.80/nepomuk/query/result.cpp:162:46: error:
 no match for 'operator==' in '((const Nepomuk::Query::Result*)this)-

 Hi Andrea,

 This error I recognized and is caused by an old version of Soprano. Please
 make sure you have a recent snapshot (2.4.63).

It seems 4.5b1 needs newer and as-yet unreleased versions of both 
akonadi (1.3.60+) and soprano (2.4.63+).  Can we get tarballs for those 
these?

-- Rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

kdebindings-4.4.80 build failures

[Rex Dieter]

I'm seeing kdebindings failures.

trying to build against qt-4.7.0-beta1 results in one kind,

[ 12%] Building CXX object smoke/qtgui/CMakeFiles/smokeqtgui.dir/x_20.o
cd 
/builddir/build/BUILD/kdebindings-4.4.80/i686-redhat-linux-gnu/smoke/qtgui 
 /usr/bin/c++   -Dsmokeqtgui_EXPORTS -D_BSD_SOURCE ...
  -o CMakeFiles/smokeqtgui.dir/x_20.o -c 
/builddir/build/BUILD/kdebindings-4.4.80/i686-redhat-linux-gnu/smoke/qtgui/x_20.cpp
/builddir/build/BUILD/kdebindings-4.4.80/i686-redhat-linux-gnu/smoke/qtgui/x_20.cpp:
 
In static member function 'static void 
__smokeqtgui::x_QGlobalSpace::x_776(Smoke::StackItem*)':
/builddir/build/BUILD/kdebindings-4.4.80/i686-redhat-linux-gnu/smoke/qtgui/x_20.cpp:19820:
 
error: 'PM_FrameCornerWidth' was not declared in this scope
...

details:
https://koji.fedoraproject.org/koji/getfile?taskID=2207364name=build.log


And, against qt-4.6.2, another,
[ 19%] Generating smokedata.cpp, x_1.cpp, x_2.cpp, x_3.cpp, x_4.cpp, 
x_5.cpp, x_6.cpp, x_7.cpp, x_8.cpp, x_9.cpp, x_10.cpp
cd 
/builddir/build/BUILD/kdebindings-4.4.80/x86_64-redhat-linux-gnu/smoke/qsci 
 
/builddir/build/BUILD/kdebindings-4.4.80/x86_64-redhat-linux-gnu/generator/bin/smokegen
 
-config 
/builddir/build/BUILD/kdebindings-4.4.80/x86_64-redhat-linux-gnu/smoke/qsci/../qt/config.xml
 
-smokeconfig 
/builddir/build/BUILD/kdebindings-4.4.80/smoke/qsci/smokeconfig.xml -I 
/usr/include/Qsci -- 
/builddir/build/BUILD/kdebindings-4.4.80/smoke/qsci/qscintilla2_includes.h
Couldn't find config file 
/builddir/build/BUILD/kdebindings-4.4.80/x86_64-redhat-linux-gnu/smoke/qsci/../qt/config.xml
 

Cannot load library generator_: (libgenerator_.so: cannot open shared 
object file: No such file or directory)
make[2]: *** [smoke/qsci/smokedata.cpp] Error 1

details:
http://kdeforge.unl.edu/apt/kde-redhat/mock/fedora-13-x86_64-kde/kdebindings/build.log

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

kde-4.4, virtuoso-6.1.0, and virtuosoconverter

[Rex Dieter]

FYI,
http://kde-apps.org/content/show.php/Nepomuk+Virtuoso+Converter

1.  The requirements for kde-4.4/nepomuk have changed pretty late in the 
game (after all 4.4rc's).

2.  I personally have had trouble downloading 6.1.0 for the past 24hrs 
from sourceforge, if this is a continuing problem for others, perhaps we 
could put it on kde mirrors somewhere?

3.  the aforementioned data conversion tool (from 5.0.x) as-is seems... 
less than optimal.

Comments?

-- Rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: [Nepomuk] kde-4.4, virtuoso-6.1.0, and virtuosoconverter

[Rex Dieter]

On 02/04/2010 07:43 AM, Sebastian Trueg wrote:
 Rex Dieter wrote:
 FYI,
 http://kde-apps.org/content/show.php/Nepomuk+Virtuoso+Converter

 1.  The requirements for kde-4.4/nepomuk have changed pretty late in the
 game (after all 4.4rc's).

 No, they did not. I always said that Virtuoso 6 would be the dependency
 for KDE 4.4.

That's all well and good.

I had held off trying to use 6.0 myself, based on comments from you that 
it was buggy and didn't work, ie, waiting for 6.0.1 or 6.1, which has 
now landed.

Fact is that we're in a bad situation of now requiring something that's 
been untested and it's data is incompatible with what was tested.

 3.  the aforementioned data conversion tool (from 5.0.x) as-is seems...
 less than optimal.

 less than optimal is way too detailed for me to give any feedback on.  ;)

 Anyway, the converter is hacky tool allowing early adopters of KDE 4.4
 who already tries Nepomuk with Virtuoso 5 (and thus, compile
 themselves!) to easily convert their data.

I get that.  I was hoping we could do better.  This is just a 
consequence of (1), and not having ample time to adapt to the new stuff.

-- Rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Kopete-jabber is not working anymore

[Rex Dieter]

On 01/28/2010 03:51 PM, Detlev Casanova wrote:
 Hi,
 jabber.org has recently changed it's server configuration.
 Now, Kopete is not connecting to any jabber.org account.

 How can I tell the release team that this is blocking for KDE 4.4 before we
 have worked the problem out ?

You can propose it as you just did...

However, I don't consider what jabber.org does raises to the level of
blocking a kde release.  It's a bug like any other, and it'll get fixed 
when it gets fixed, hopefully sooner rather than later.

any bug(s) filed (for tracking purposes)?

-- Rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Upcoming KDE 4.4 vs. Bug #162485 (no suitably sufficient SSL/TLS support)

[Rex Dieter]

Matthias Andree wrote:

 The problem - to me - seems to be that showstopper bugs aren't stopping  
 the KDE show to gain the necessary attention

Several related issues, based on my own experience and perceptions as 
mostly a lurker on the release team:

1.  KDE currently has a time-based schedule
2.  This isn't a bug, but a missing feature
2a. We have no documented or objective criteria to identify showstopper 
bugs (or features, for that matter)
3.  We have no obvious/documented process for dealing with conflicts 
between 1 and 2.

Now, I'd welcome discussions and input on how best to deal with these 
(in the 4.5 timeframe).  I'll even offer some suggestions of my own, 
after pondering it a bit.

-- Rex

p.s.  I'd love to be shown wrong about any of the above assertions about 
things not being obvious or documented.
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.4 RC1 (4.3.90) tarballs uploaded

[Rex Dieter]

Andrea Scarpino wrote:
 2010/1/7 Dirk Mueller muel...@kde.org:
 while I had the problem originally, after updating to 4.4 kdebase/workspace 
 it
 builds fine for me.

I can confirm the same failure here, building against 
kdebase-worspace-4.3.90.

 But kdebase-workspace requires kdebindings-python to enable KDE Python
 support, if your solution work, one needs to build kdebase-workspace
 twice??

That's one of those checks for stuff really only needed at runtime, not 
buildtime... (which really irks me(1))

I'd propose that runtime-only checks like that:
1.  not be fatal for the build
2.  output/warning be made clearer that this is a runtime-only 
dependency (or the check be removed altogether).

(though I suppose such a proposal may be better suited for the 
buildsystem list)

-- Rex

p.s.  amarok has a similar type of check for qtscriptgenerator... I'm 
sure there are others.

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.4 RC1 (4.3.90) tarballs uploaded

[Rex Dieter]

Simon Edwards wrote:
 Andrea Scarpino wrote:
 2010/1/6 Dirk Mueller muel...@kde.org:
 I just finished the first set of 4.3.90 (KDE 4.4 RC1) tarballs and uploaded
 them. kde-l10n still takes a few more hours, I'll upload them later.

 Please let me know of any urgent issues, we'd like to release this asap.
 Hi, kdebindings fails to build here:

 Linking CXX shared library ../../lib/pykde/phonon.so
 [ 83%] Built target python_module_PyKDE4_phonon
 [ 84%] Generating sip/plasma/sipplasmapart0.cpp,
 sip/plasma/sipplasmapart1.cpp, sip/plasma/sipplasmapart2.cpp,
 sip/plasma/sipplasmapart3.cpp, sip/plasma/sipplasmapart4.cpp,
 sip/plasma/sipplasmapart5.cpp, sip/plasma/sipplasmapart6.cpp,
 sip/plasma/sipplasmapart7.cpp
 sip: QAbstractAnimation has not been defined
 make[2]: *** [python/pykde4/sip/plasma/sipplasmapart0.cpp] Error 1
 make[1]: *** [python/pykde4/CMakeFiles/python_module_PyKDE4_plasma.dir/all]
 Error 2
 make: *** [all] Error 2
 
 It should work fine with a recent SIP and PyQt snapshot.

Thanks, I'm testing that out myself now.

 A new stable release of PyQt is imminent, then can I up the version 
 check in CMakeLists.txt. Sorry for the inconvenience guys.

As I just commented in kde-bindings, the newer sip release appears to be 
binary incompatible (ie, 4.9.x had SIP_API_MAJOR 6, and 4.10 has 
SIP_API_MAJOR 7), so requires a rebuild of all things using sip. :( 
(unless I'm missing something).

-- Rex

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.4 RC1 (4.3.90) tarballs uploaded

[Rex Dieter]

Rex Dieter wrote:
 Simon Edwards wrote:
 Andrea Scarpino wrote:
 2010/1/6 Dirk Mueller muel...@kde.org:
 I just finished the first set of 4.3.90 (KDE 4.4 RC1) tarballs and uploaded
 them. kde-l10n still takes a few more hours, I'll upload them later.

 Please let me know of any urgent issues, we'd like to release this asap.
 Hi, kdebindings fails to build here:

 Linking CXX shared library ../../lib/pykde/phonon.so
 [ 83%] Built target python_module_PyKDE4_phonon
 [ 84%] Generating sip/plasma/sipplasmapart0.cpp,
 sip/plasma/sipplasmapart1.cpp, sip/plasma/sipplasmapart2.cpp,
 sip/plasma/sipplasmapart3.cpp, sip/plasma/sipplasmapart4.cpp,
 sip/plasma/sipplasmapart5.cpp, sip/plasma/sipplasmapart6.cpp,
 sip/plasma/sipplasmapart7.cpp
 sip: QAbstractAnimation has not been defined
 make[2]: *** [python/pykde4/sip/plasma/sipplasmapart0.cpp] Error 1
 make[1]: *** [python/pykde4/CMakeFiles/python_module_PyKDE4_plasma.dir/all]
 Error 2
 make: *** [all] Error 2
 It should work fine with a recent SIP and PyQt snapshot.
 
 Thanks, I'm testing that out myself now.

Confirmed, all builds well (for me on fedora 12 anyway) against latest 
sip/PyQt4 snapshots (I tested sip-4.10-snapshot-20100102 and 
PyQt-x11-gpl-4.7-snapshot-20091231 ).

-- Rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.4 Beta2 (4.3.85) tarballs available

[Rex Dieter]

On 12/19/2009 08:57 AM, Sebastian Kügler wrote:
 On Friday 18 December 2009 23:59:55 Rex Dieter wrote:
 On 12/18/2009 02:24 PM, Rex Dieter wrote:
 Dirk Mueller wrote:
 On Friday 18 December 2009, Dirk Müller wrote:
 I just finished uploading the first set of Beta2 tarballs, a bit later
 than expected, sorry about that.

 I'll start testing them now, please report any issues you might find.

 Sebas suggested to release them earlier than scheduled on the release
 schedule, possibly even afternoon tomorrow.

 any opinions about that? it seems doable to me but I would like to have
 positive compile feedback until then from at least two sources (myself
 included).

 -1 here so far, kdebindings is failing somewhere in smoke/plasma for me.

 I think this should fix it,
 http://websvn.kde.org/?revision=1063597view=revision

 Test builds going now.

 Alright, let's aim the release for Monday. :)

For posterity, several other fixes were required to get a successful build.

1.  smokenepomuk was disabled, so anything depending on this failed 
(ruby, csharp).
2.  some small breakage in php bindings as well.

A minimal patch against 4.3.85 tarball fixing these is:
http://cvs.fedoraproject.org/viewvc/devel/kdebindings/kdebindings-4.3.85-fix-build.patch

We're working to upstream the php fixes, and I *think* smokenepomuk is 
fixed in this later largish commit,
http://websvn.kde.org/?view=revisionrevision=1063412
but that's untested by me.

-- Rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.4 Beta2 (4.3.85) tarballs available

[Rex Dieter]

Dirk Mueller wrote:
 On Friday 18 December 2009, Dirk Müller wrote:
 
 I just finished uploading the first set of Beta2 tarballs, a bit later than
 expected, sorry about that.

 I'll start testing them now, please report any issues you might find.
 
 Sebas suggested to release them earlier than scheduled on the release 
 schedule, possibly even afternoon tomorrow. 
 
 any opinions about that? it seems doable to me but I would like to have 
 positive compile feedback until then from at least two sources (myself 
 included). 

-1 here so far, kdebindings is failing somewhere in smoke/plasma for me.

Gory details,

[ 28%] Building CXX object smoke/plasma/CMakeFiles/smokeplasma.dir/x_7.o
cd 
/builddir/build/BUILD/kdebindings-4.3.85/x86_64-redhat-linux-gnu/smoke/plasma 
 /usr/bin/c++   -DMAKE_SMOKEPLASMA_LIB -D_BSD_SOURCE
...
-D_LARGEFILE64_SOURCE -o CMakeFiles/smokeplasma.dir/x_7.o -c 
/builddir/build/BUILD/kdebindings-4.3.85/x86_64-redhat-linux-gnu/smoke/plasma/x_7.cpp
...
  CMakeFiles/smokeplasma.dir/x_7.o: In function `x_Plasma__ScrollWidget':
/builddir/build/BUILD/kdebindings-4.3.85/x86_64-redhat-linux-gnu/smoke/plasma/x_7.cpp:1946:
 
undefined reference to `Plasma::ScrollWidget::ScrollWidget(QGraphicsItem*)'
collect2: ld returned 1 exit status


Even more gory details,
http://koji.fedoraproject.org/koji/taskinfo?taskID=1880201
http://koji.fedoraproject.org/koji/getfile?taskID=1880201name=build.log

-- Rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.4 Beta2 (4.3.85) tarballs available

[Rex Dieter]

On 12/18/2009 02:24 PM, Rex Dieter wrote:
 Dirk Mueller wrote:
 On Friday 18 December 2009, Dirk Müller wrote:

 I just finished uploading the first set of Beta2 tarballs, a bit later than
 expected, sorry about that.

 I'll start testing them now, please report any issues you might find.

 Sebas suggested to release them earlier than scheduled on the release
 schedule, possibly even afternoon tomorrow.

 any opinions about that? it seems doable to me but I would like to have
 positive compile feedback until then from at least two sources (myself
 included).

 -1 here so far, kdebindings is failing somewhere in smoke/plasma for me.

I think this should fix it,
http://websvn.kde.org/?revision=1063597view=revision

Test builds going now.

-- Rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Freeze exemption for PA integration into Phonon

[Rex Dieter]

On 11/18/2009 11:41 AM, Tom Albers wrote:
 Op Wednesday 18 November 2009 18:10 schreef u:

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

Admittedly with my distro-packager hat firmly on, I whole-heartedly 
support efforts to merge asap and getting things tested in beta.

-- Rex

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: microblog plasmoid fix in 4.3 branch, but not in 4.3.0

[Rex Dieter]

On 08/02/2009 07:35 PM, Aaron J. Seigo wrote:
 hello packagers and release team ...

 if you're packaging up 4.3.0, you may want to include this patch:

   http://websvn.kde.org/?view=revrevision=1004203

 to kdeplasma-addons, which fixes the submission of updates to
 twitter/identi.ca from the microblogger plasmoid.

Thanks and all, tried it, but on posting anything, plasma crashes for 
me.  I'll post more details (with bug reference, backtrace once I get 
all the debuginfo bits installed).

-- Rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.3 Beta2 : missing/unreleased dependencies

[Rex Dieter]

On 06/03/2009 04:23 PM, Maciej Mrozowski wrote:
 On Wednesday 03 of June 2009 22:24:05 Ingmar Vanhassel wrote:

 At least kdebase-runtime [1], and kdebindings [2] fail here if I use the
 latest soprano release. Is soprano trunk required or will a soprano release
 follow?

 Further yet unstatisfied (but at least listed in CMakeLists.txt)
 dependencies for 4.3 seem to be:
 - yet unreleased eigen for kdeedu/step
 - yet unreleased sip/PyQt4 for pykde4
 - trunk phonon for mplayerthumbs to work with phonon backend (and not mplyer
 executable - this one is optional though)

Also, I was under the impression that phonon would be addressed in time 
for 4.3 too.  To use qt's phonon, or standalone?  If the former, where 
would the xine backend come from?  If the latter, any new releases coming?

-- Rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: oxygen icons moved

[Rex Dieter]

Dirk Mueller wrote:
 On Monday 16 March 2009, C. Boemann wrote:
 
 The oxygen icons have been moved to kdesupport/oxygenicons

 The intension is to release it more often than kde itself, so that we can
 provide up-to-date icons for applications that are outside the normal KDE
 release schedules
 
 I am probably missing the discussion somewhere.. but who is going to provide 
 working oxygen tarballs for each KDE release and where are they being found?

I'd go a step further, and highly recommend that oxygen make a 
standalone release (tarball) for public consumption asap, so that 
distros can get a head start on packaging it.

-- Rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Getting distros to fix my lazyness

[Rex Dieter]

Aurélien Gâteau wrote:
 Hi,
 
 I just realized I forgot to bump Gwenview version number from 2.2.0 to 
 2.2.1 before KDE 4.2.1 got tagged (just fixed it for 4.2.2).
 
 I would like to suggest kde packagers to fix the version number in their 
 4.2.1 packages. What is the best way to communicate this to all (well, 
 most) of them?

mail a patch to kde-packa...@kde.org

-- Rex

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team