Re: Bug#664681: transition: KDE's 4.8 release of platform, applications and workspace
Hello, On šeštadienis 24 Kovas 2012 23:45:02 Sune Vuorela wrote: On Saturday 24 March 2012 22:10:07 you wrote: On Mon, Mar 19, 2012 at 22:07:22 +0100, Sune Vuorela wrote: a couple of months ago, KDE released the januar feature release Should we do the qt multiarch change before this? We can do the qt multiarch change first. we also can do it after. I would personally like to see the Qt multiarch change done, because it also brings in qt4.8 With qt4-x11 multiarch done [1] and KDE Plasma Workspaces ready in experimental [2], when could we expect a transition slot? [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653903 [ bug not closed though ] [2] http://pkg-kde.alioth.debian.org/redir/kde-sc-buildd-experimental?compact=1 -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part. -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: KDE multiarchification and packages installing into /usr/lib/kde4
Hello, On sekmadienis 18 Kovas 2012 21:14:26 Kai Wasserbäch wrote: Dear fellow KDE maintainers, I've got a few packages installing things into /usr/lib/kde4 (e.g. plasma-widget-yawp or qapt). If I install my libraries currently under /usr/lib/kde4 into the multiarch path, are they still found as Plasmoids/plug-ins/... by the core KDE stuff? Or is it better to wait with moving to MA paths? There is no point for KDE applications to go multiarch until KDE itself supports multiarch, is it? I'm too lazy to check but I'm pretty sure that the short answer to your question is no, plasma won't find it. -- Modestas Vainius mo...@debian.org -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: lupdate, lrelease TDebs
Hello, On šeštadienis 04 Birželis 2011 20:31:50 Neil Williams wrote: I'm restarting work on TDebs (at request of the release team and others) and I'm also doing some work using Qt on Emdebian, including usage of QtLinguist and this is likely to result in at least outline support for Qt translations files in TDebs. The DEP is a bit out of date - the changes at Alioth seem to have interfered with my commits. I'm working on new scripts to build the TDebs themselves. http://dep.debian.net/deps/dep4 Package maintainers will already have libqt4-dev installed but translation updates using lupdate and lrelease would be needed in order for translation teams to provide TDeb updates to existing packages without requiring a binary rebuild. What would be the chances of qt4-x11 providing yet another binary package which only provides lupdate and lrelease? Of course, why not. Just turn this mail into a bug report so it does not get lost. (Installing libqt4-dev in a sid pbuilder chroot involves 44 newly installed packages and 34.9 MB of archives (with Recommends turned off). Now some of those would be installed on translator machines but quite a lot would not - especially the other -dev packages.) Just trying to gauge the impact of using TDebs with Qt. I'm aware that KDE packages may have differing translation mechanisms, this is more about packages which just use Qt or which are not part of KDE directly. KDE uses gettext (*.mo files etc.). POT files are generated from source files with some KDE specific tool. -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part. -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: [SCM] Eigen2 packaging branch, upstream, created. debian/2.0.15-1-2-gcb73e65
Hello, On sekmadienis 29 Gegužė 2011 10:28:41 Anton Gladky wrote: The branch, upstream has been created at cb73e65fa1958a3c4382e00c13c1574fdb252e8b (commit) - Shortlog commit cb73e65fa1958a3c4382e00c13c1574fdb252e8b Author: Anton Gladky gladky.an...@gmail.com Date: Sat May 28 23:56:57 2011 +0200 Imported Upstream version 2.0.16 commit 828261c6f4e76b2de15d7f3e08b9dda6612528de Author: Anton Gladky gladky.an...@gmail.com Date: Sat May 28 23:53:06 2011 +0200 Imported Upstream version 2.0.15 --- This is not how it works. You can't implement random git workflows while the package is under Debian Qt/KDE team maintenance. Please stick to [1]. [1] http://anonscm.debian.org/gitweb/?p=pkg-kde/qt/qt4-x11.git;a=blob;f=debian/README.source -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part. -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Bug#624382: transition: KDE SC 4.6
Hello, On ketvirtadienis 28 Balandis 2011 01:59:22 Modestas Vainius wrote: It's not very clear to me (personally) what to do with kdebindings but IMHO if possible, it's better to delay it sometime after this transition. This ugly beast links the whole distro together. Just to note: even if current kdebindings 4:4.4.5 was binNMUed and built fine against 4.6, it would definitely pick up dependency on at least new kdebase- workspace, kdegraphics and kdeedu. kdebindings links sip, python and mono together (and something else I don't remember now). P.S. It is fine to have kdebindings RC buggy in unstable or testing (it wouldn't be the first and the last time, really :-)). All that counts is that it did not end up blocking transitions. -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part. -- http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk
Re: Handling BIC-without-SONAME-bump in KDE SC libraries
. That would effectively limit us to one patch per source package while the rest would be conveniently configured in debian/control. [1] http://www.akkadia.org/drepper/symbol-versioning [2] http://sourceware.org/git/?p=glibc.git;a=commit;h=9a8fcca0b33c26759134a545ac45251df53418a3 [3] apppath: libpath: no version information available (required by apppath) [4] http://sourceware.org/git/?p=glibc.git;a=blob;f=elf/dl-lookup.c;hb=glibc-2.13#l168 -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part. -- http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk
Re: Handling BIC-without-SONAME-bump in KDE SC libraries
Hello,
On antradienis 15 Kovas 2011 00:23:14 Modestas Vainius wrote:
2. [ Library level ]. Change library SONAME (e.g. add debN suffix,
specifics to be discussed) and rename the package. No Breaks/Replaces
needed as there are no conflicting files.
As an amendment to this plan, we could start versioning the symbols of BIC-
prone libraries (i.e. basically everything not kde*libs). This would help us
avoid the following con:
b) if conflicting libraries are loaded in the same app memory space
(unlikely though), it might lead to crashes at runtime;
It's still an open question how much symbol versioning would affect people
building from source (e.g. kde developers or kdesrc-build users). What's more,
it's still unknown how much effort (i.e. upstream code patching) this would
need.
If we were to move forward with this plan, we need to agree about naming of
custom SOVERSION and symbol versions. Please respond to this mail even if it
was a short yes/no answer with small remarks. My proposal would be:
SOVERSION: ${upsteamSOVERSION}debN (where N is a number (starting from 1)
bumped after each BIC-without-SONAME-bump)
symbol versions: DEB_${upsteamSOVERSION}[_N] where N is the same as above if
there was at least one BIC-without-SONAME-bump. Otherwise _N part would be
omitted. Whereas symbol versioning could be avoided if there was no BIC-
without-SONAME-bump, is an open technical question (that would be somewhat
more binary compatible with the rest of world, at least temporary).
--
Modestas Vainius mo...@debian.org
signature.asc
Description: This is a digitally signed message part.
--
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk
New build system (dhmk based) for Qt/KDE packages (qt-kde-team/2/*)
the place. In order to understand what's going on, have a look at what variables get defined in dhmk_rules.mk. Unfortunately, extensive templating options make dhmk UI a bit more cluttered than the one of dh(1) but it's still far far less complex than cdbs (in my opinion anyway). Some more information is available in qt-kde-team/2/README. Therefore, I would like to see Qt/KDE packages getting converted to dhmk [2]. Unless somebody has to offer something better, they are welcome to. But personally, I no longer see sticking to CDBS as an option. While qt-kde- team/2/* is not perfect, I tried to decouple it from tight bound with perl while adhering to the best successful practises established by dh(1). [1] http://git.debian.org/?p=pkg-kde/pkg-kde-tools.git;a=commit;h=8de511c5 [2] I have recently converted phonon and its backends will follow soon. -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part. -- http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk
Re: [SCM] KOffice packaging branch, koffice2.3-experimental, created. c359cca5424e5d3a9456c33c071f400f85a57749
Hello, On trečiadienis 18 Rugpjūtis 2010 00:28:58 Raúl Sánchez Siles wrote: The branch, koffice2.3-experimental has been created at c359cca5424e5d3a9456c33c071f400f85a57749 (commit) - Shortlog commit c359cca5424e5d3a9456c33c071f400f85a57749 Author: Raúl Sánchez Siles rasas...@gmail.com Date: Tue Aug 17 23:08:42 2010 +0200 Adding koreport desktop files. --HG-- branch : koffice2.3 commit 15bafb7244a547cf59bb54676cd9258786f77e2b Author: Raúl Sánchez Siles rasas...@gmail.com Date: Tue Aug 17 23:05:31 2010 +0200 Not including KChart application but rather the chart shape plugin. I'm sorry but your branch as it is not mergable because it does not derive from master and duplicates the whole history. Please rebase it on master or delete it from public repository. HG metadata is not helpful either. -- http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk
Re: towards KDE 4.5? (mail to -release, filling the needed info)
Hello, On trečiadienis 04 Rugpjūtis 2010 08:57:44 Ana Guerrero wrote: Thanks for all your answers so far! Now the next step is mailing the release team, I have voluntered with this part, but as as you know, I have not been around lately and I need some help recollecting information. The plan is: shipping into the next stable release with KDE 4.5.x where x is hopefully at least =2 with Qt 4.7. 2 will still be too buggy (it always is). I would estimate 1 at the end of August (sooner than 1 month), 2 at the end of September, 3 at the end of October. We should stress to RT than KDE point releases won't have any effect on the rest of the archive, not even shlibs bump of anything (example 4.4.4 - 4.4.5 which went flawlessly). They have nothing to worry about. The 4.5.0 release is in 2 days and we are far from having packages ready, so as Modestas pointed, we could ship then wherever we have something ok for general public at qt-kde.d.n and later upload 4.5.1 directly to the archive. 4.5.1 is supposed to be released in the 2nd week of September. As I said above, I expect it to be released way sooner. Quoting dirk: quote Unfortunately it seems that lots of fixes are being backported at the moment, so we have to delay the rest to an early 4.5.1 release it seems. /quote About KDE 4.5, gkiagia, Modestas: what have you found so far? As I have understood it, we should have not problems with the soname bumps/additions/ removals (if any) out of KDE (SC). Nop, there will definitely be removals and soname bumps out of KDE SC (some workspace libs, libkonq5, kdegraphics libs). A couple of packages will need to be binNMUed. That's definitely digikam (maybe new upstream release even), kphotoalbum, ktorrent, konq-plugins, kmess, kdiff3, probably a few more. Finally, it is kdepim. The official planning currently says they will skip 4.5.0 and release with 4.5.1 and well, the changes will be big. Should we keep 4.4.x anyway? My vote goes to kdepim 4.4.x stack. kdepim-akonadi will be too fresh and untested for stable Debian release. -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part. -- http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk
Re: Switching KDE packaging to git
Hello, On pirmadienis 12 Liepa 2010 09:33:18 Fathi Boudra wrote: Like official KDE modules, those will have to be done one by one when somebody has time. Hopefully migration process won't have too many caveats and will be polished during migration of official KDE packaging so anybody could do it for krap/extras. qt4-x11.git migration was not very smooth hence I will need to find more reliable ways/scripts. I'll give try with svn2git tool used by KDE: http://gitorious.org/svn2git Yeah, that was my thought as well. It is packaged as svn-all-fast-export. -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part. -- http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk
Re: Switching KDE packaging to git
Hello, On pirmadienis 12 Liepa 2010 12:09:38 Sune Vuorela wrote: git clone... tar --magic-option-that-are-hard-to-remember xf foo.tar.gz build... it's --strip=1. shell aliases help. Somehow, I think I woudl prefer if it was just the content of twhe debian dir that was versioned, not the directory. tar xf foo.tar.gz git clone debian I don't think it is a good idea unless you intend to keep `git clone`ing each new upstream release. In your scenario, removing old upstream source tree but keeping debian in the persistent cloned packaging directory will need some effort (more than remembering --strip=1 to tar). On the contrary, when debian dir itself is versioned, you can use `git clean -xdff` to clean up old upstream source tree without too much effort because parent packaging directory is under git control. I see where is your idea coming from. However, git is not svn and I don't think `cp -a debian /path/to/upstream/source` is a particularly good idea mainly because git encourages commit frequently, push rarely and subversion gives you no other choice but to push when committing. Desyncing working tree with git state will be confusing in the long term. That's why git won't even allow to push to checked out repository by default. -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part. -- http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk
Re: Switching KDE packaging to git
Hello, On antradienis 13 Liepa 2010 01:12:03 Mark Purcell wrote: Seems like a lot of options and moving parts for the maintenance of kde-extras packages. In kde-extras we generally have new upstream releases with sometimes a handful of Debian specific patches, sometimes pulling something early from upstream. Well, my original mail has never been about kde-extras. Unlike qt4-x11 or KDE, kde-extras are released individually as separate rather small entities. Compare that to 400+ mb big qt4-x11 or 22 huge source packages of KDE. If I was to start packaging kde-extras app from scratch, I would definitely choose the same workflow I currently use for ktorrent/konversation, i.e. upstream + packaging with patching in quilt + pristine-tar. upstream branches are really useful when they are manageable despite some caveats with quilt patches in this workflow (the next release of dpkg-dev will make it easy to workaround them). However, this 'upstream branch' workflow does not scale in cases like qt4-x11 (due to its size) or official KDE modules (due to the number of upstream branches to update for each new release and their cumulative size). upstream + packaging with patching in quilt + pristine-tar is basically what git buildpackage supports. At least, git import-orig makes it easy to import and manage upstream pristine-tar branches. However, I do not agree with `git buildpackage` tagging conventions (e.g. that it replaces '~', which git does not support in tags, with '.', how uninformative tag annotations are etc.) so I tend to avoid it. svn-buildpackage manages this use case without lots of command line foo, without manual extraction of the upstream tarball or manually extracting the tarball into the repository. Am I missing something, or is git too powerful for the use case we have with kde-extras? I have never used svn-buildpackage but I believe git-buildpackage is as easy to use as svn-buildpackage if you want to use a wrapper and accept all its conventions (which I don't). That qt4-x11.git README.source was written with bare git in mind so it might be a bit verbose. -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part. -- http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk
Switching KDE packaging to git
Hello, so hereby I propose to switch our KDE packaging from svn to git on git://git.debian.org/git/pkg-kde/kde/$modulename.git. In other words, each official KDE module gets its own $module.git under git://git.debian.org/git/pkg-kde/kde/ with a script to clone/pull/etc. them all. 1) We would use the same workflow as for qt4-x11.git, i.e. no upstream branch. It proved to be fine, didn't it? Fathi, you worked most with qt4-x11.git, is there anything you would like to be changed? 2) upstream pristine-tar branches are nice for small packages but from my experience: a) they are additional burden to manage even if `git import-orig` makes it kinda easy to import; but kde is 22 source packages so I don't think this will scale; b) things get complicated (though manageable with some patience) when there are a few packaging branches based on different upstream versions. It might be tricky to get merging right; c) upstream branches increase repository size considerably; given that kde has 22 source packages, clone of all repos will be huge; d) last but not least, when we decide we want upstream branches, we can always add them later without any cost. 3) Packaging will be imported to git with all history. The main motivation for VCS change is upcoming situation. We will probably have to release with 4.4.5, but we will want to package KDE 4.5 as well. Merging in svn is impossible but we want to properly track changes which apply to both 4.4.5 = 4.5 packaging (we have lost changes in the past due to svn deficiencies). Secondary motivation is that centralized svn is ageing while git is distributed, fast, has some nice features and is the most featureful DVCS at the moment. Last but not least, KDE upstream is eventually switching to git. -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part. -- http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk
Re: /usr/share/doc/kde4 (Debian) vs. /usr/share/doc/kde (Kubuntu)
Hello, On sekmadienis 23 Gegužė 2010 16:15:39 Pino Toscano wrote: 23). So the only opportunity I see for this is KDE SC 4.4.4 release; +1 on the switch for 4.4.4. 4.4.4 in archive so mini-transition has started. Among the packages you listed, some don't explicitly list any documentation path in either install files, rules or anything else in the debian packaging (so a binNMU can be enough for them): kcollectd digikam-doc icecc-monitor kcheckgmail kdesudo kmess kmplayer kphotoalbum krecipes rsibreak skanlite smb4k kmidimon rkward kwave frescobaldi kvkbd backintime = 18 packages Our kde4libs 4.4.4 still looks in the /usr/share/doc/kde4/HTML for docs so binNMUs are not needed for proper functionality. What's more, technically, if docs are in the arch:all package, binNMU won't help. So maybe we will get back to fixing these packages sometime right before freeze. Hopefully, most of these packages will fix themselves when maintainer does a routine upload to solve other issues. Instead, these need a sourceful upload: tellico k3b kdesvn keurocalc kile kmymoney konq-plugins konversation krusader skrooge kdiff3 eqonomize = 12 packages I filled serious bugs against tellico, kdiff3 and eqonomize. Other packages belong to KDE extras so rather than filling bugs I sent a mail. However, during routine rebuild of archive, Lucas might open serious bugs against those packages as well. So there is no need to delay uploads for too long. -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part. -- http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk
Re: rev 17779 - krap/libdbusmenu-qt/trunk/debian
Hello, On pirmadienis 03 Gegužė 2010 16:28:31 Praveen A wrote: 2010/5/3 Modestas Vainius modes...@vainius.eu: No, you don't need to start -2 revision for these changes because -1 has never been officially uploaded to Debian. This also means that you don't need to document changes in the changelog until initial release is uploaded to Debian archive. So basically, you can just drop this -2 entry completely. Please remove 0.3.2-1 tag as well since it is invalid and does not point to official upload. OK. Made these changes. Fine. Now the last nitpicks: 1) I overlooked that the package uses cmake (don't know why I initially thought it used qmake). debhelper (= 7.3) is enough for this (Build-Depends). 2) I suggest you reconsider not using (A proud GNU user) in Uploaders field and changelog trailer. Now it may look cool somewhat but you may get tired of this eventually. It is rather unusual as well. If I were you I would just keep your full name and email like Debian Policy 5.6.2 recommends. Btw, this is not a blocker for sponsoring, it is your choice eventually. Finally feel free to `dch -r -D unstable`, build source package, upload it to mentors or alioth and give me an URL to .dsc which I will sponsor. -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part. -- http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk
Re: rev 17779 - krap/libdbusmenu-qt/trunk/debian
Hello, On pirmadienis 03 Gegužė 2010 20:42:47 Modestas Vainius wrote: Hello, On pirmadienis 03 Gegužė 2010 16:28:31 Praveen A wrote: 2010/5/3 Modestas Vainius modes...@vainius.eu: No, you don't need to start -2 revision for these changes because -1 has never been officially uploaded to Debian. This also means that you don't need to document changes in the changelog until initial release is uploaded to Debian archive. So basically, you can just drop this -2 entry completely. Please remove 0.3.2-1 tag as well since it is invalid and does not point to official upload. OK. Made these changes. Fine. Now the last nitpicks: 1) I overlooked that the package uses cmake (don't know why I initially thought it used qmake). debhelper (= 7.3) is enough for this (Build-Depends). 2) I suggest you reconsider not using (A proud GNU user) in Uploaders field and changelog trailer. Now it may look cool somewhat but you may get tired of this eventually. It is rather unusual as well. If I were you I would just keep your full name and email like Debian Policy 5.6.2 recommends. Btw, this is not a blocker for sponsoring, it is your choice eventually. And... 3) dbusmenu-qt public headers include Qt headers therefore add libqt4-dev to Depends of the -dev package. -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part. -- http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk
Bug#579690: transition: KDE SC 4.4.3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
User: release.debian@packages.debian.org
Usertags: transition
Hello,
as a follow up to [1], I open a new bug for KDE SC 4.4.3 transition tracking.
Uploads of 20+ KDE SC source packages and a couple of other in-house ones
(google-gadgets, libmsn) are currently planned for May 2-4. The transition
seems to be ready [2] on arches which have functional experimental buildds.
FYI, all build failures there have been triggered by bugs of either
pkg-kde-tools or attica. Good news is that those bugs have already been fixed
in sid.
For future reference, please note that starting with 4.4, KDE SC packages
include symbol files for all public libraries. This means that packages of new
minor upstream releases (e.g. all upstream releases in 4.4 series) will no
longer need to migrate to testing together as a whole bunch because
intedependences of all KDE SC packages will be tied to the most recent KDE
major version (e.g. = 4.4) rather than to the most recent minor one (e.g. =
4.4.{1,2,3}). This means that each source package of KDE SC (whether it
includes libraries or not) becomes an independent entity (likely expection
being kdebindings) on its own unless we do major packaging changes for minor
upstream releases (unlikely) or upload a new major (e.g. from 4.4.x to 4.5.x)
upstream release.
Therefore, we'll no longer coordinate typical uploads of new minor KDE SC (as
entity) upstream releases. Obviously, normal rules still apply and we'll do our
best not to upload those individual KDE SC source packages which would
negatively impact other ongoing transitions at that moment.
Major (e.g. 4.4 - 4.5) upstream upgrades will be coordinated as before because
they are always going to be like a shlibs bump in the best case scenario. Yet
soname changes, package renames or other major packaging changes are also very
likely then.
1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570360#47
2.
https://buildd.debian.org/pkg.cgi?pkg=maint=debian-qt-kde%40lists.debian.orgdist=experimental
Below you will find relevant information about the transition most of which has
already been posted to bug #570360.
--
The following packages will be removed when KDE 4.4 replaces KDE 4.3 currently
in sid:
kpackage
libkonqsidebarplugin4
libkonqsidebarplugin4-dev
libkfontinst4
libkwineffects1
libnepomukquery4
libnepomukqueryclient4
libplasma-applet-system-monitor4
libplasmaclock4
libprocesscore4
libprocessui4
libtaskmanager4
libweather-ion4
libsmokeakonadi2
libsmokekde4-2
libsmokeokular2
libsmokeplasma2
libsmokeqimageblitz2
libsmokeqt4-2
libsmokesoprano2
indi
libmarble4
kdesnake
libkdcraw7
libkdcraw7-dev
libkexiv2-7
libkexiv2-7-dev
libkipi6
libkipi6-dev
kde-i18n-bn
kde-i18n-th
kde-l10n-bnin
kde-l10n-hne
kde-l10n-ku
kde-l10n-mr
kde-l10n-th
kpilot
libkabcommon4
libkontactinterfaces4
libmaildir4
kdepimlibs-data
liblancelot0
kdesdk-dev
kdessh
kxsldbg
Although the list is long but actually it affects only the following 3rd
party reverse dependencies. Fortunately, all maintainers of these packages
are members of pkg-kde so there won't be delays updating the package.
Debian KDE Extras Team pkg-kde-ext...@lists.alioth.debian.org
digikam
kipi-plugins
kphotoalbum
ktorrent
Kai Wasserbäch deb...@carbon-project.org
plasma-widget-yawp
In addition, we are going to do google-gadgets and libmsn soname changes.
These packages have no dependencies outside KDE (kdebase-workspace and
kdenetwork) hence they won't cause any additional trouble.
To sum up, KDE SC 4.4 transition will be almost like shlibs bump with a few
minor exceptions above.
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.33-2-amd64 (SMP w/1 CPU core)
Locale: LANG=lt_LT.UTF-8, LC_CTYPE=lt_LT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk
Re: epoch for KAudioCreator
Hello, On šeštadienis 07 Lapkritis 2009 14:37:03 Harald Sitter wrote: So, upstream is not planning on pushing it back to kdemm, indeed upstream thinks that with proper distro support (i.e. fast package updates I suppose) there is no reason why he would want to move it to kdemm since extragear allows for a much more felxible release management anyway. I suppose that makes bumping acceptable? (btw, I completely agree with the statement about different epochs :)) Well, then I personally have no problem with that. But maybe I'm not the right person to ask because if kaudiocreator is no longer (and is not going to be) in official KDE, my interest about it ends right here as I'm not going to maintain it anyway :) However, generally speaking, you don't have much choice anyway since fancy 'really' version number (esp. of already epoched version) makes even less sense. -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part. -- http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk
Switch to orig.tar.bz2 dpkg-source format 3.0 (quilt)?
Hello, since Debian ftpmasters have made it possible to upload source packages packaged in the next generation formats: 1) I don't see any blockers to use pristine KDE upstream tarballs anymore (renamed to appropriate orig.tar.bz2 of course). 2) What about dpkg-source format 3.0 (quilt) for all official KDE packages? I tested it and I was sort of pleased with results. Added benefits: * no quilt build dependency; * no need to add/remove quilt build dependency when the first patch is added / all patches are removed; * no patch system class in debian/rules (will need newer pkg-kde-tools). Disadvantages: * if our packages were kept upstream sources in packaging VCS, it would be a bit of inconvenient (esp. in the context of svn) not to commit debian-patched upstream files or do `quilt pop -a` after each test build. But since we only keep debian/ under VCS, I don't see any blockers or regressions in a workflow. -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part. -- http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk
Re: KDE plans for the squeeze cycle
artsd off (and do not pull it in by default) and forgetting about it. Who wants to transition kdelibs4c2a and rip users off from sound in their KDE 3 applications? In summary: We would like a Squeeze release with KDE 4.4.0 at least (4.4.1 if possible) and Qt 4.6. For us december work quite *bad*, if you freeze in december we'll have some kde 4.3.x and from january we'll be using 4.4, if the freeze last a few months (*), by July we will be using 4.6 and it will be quite hard to care about bugs in KDE 4.3.x, that will be from 2 releases ago In my opinion, Squeeze should aim at = KDE 4.4.2, = Qt 4.6.1. That would be around the end of Q1 2010 / beginning of Q2 2010. If freezing in late summer / early autumn, aim at the latest Qt 4.6.x and = KDE 4.5.1. -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part. -- http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk
Re: big plans for kde4.3.x ?
Hello, On 2009 m. July 3 d., Friday 02:28:08 Sune Vuorela wrote: If any of you have big plans for packaigng changes regarding kde4.3.0, now is the time to speak up with your plans and a timeline for accomplishing it and/or mentioning what help you need from others to accomplish it. Especially plans that requires NEW caused by packaging changes, and not caused by new applications, or things that in general can cause breakages that we need to care about. My plans: Split kdebase-workspace-libs4+5 in seperate libraries. Done mostly by Martin Alfke with a bit additional cleanup by George Kiagiadakis and Modestas Vainius Kdebindings: pc files for the mono bindings, more mono packages. Split out krosspython and krossruby (antd other krossthings) to separate packages. My plan is to migrate kdelibs5 (and workspace lib* probably) to symbol files when relevant support is in dpkg-dev. Since this will take time (on dpkg side), it will probably happen later in 4.3.x cycle. As a side effect, I plan to tie kdebase-runtime to API which typically only an application would use, but not a library (e.g. KAboutData). -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part. -- http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk
Re: Adding presubj files for all KDE packages
Hello, On 2009 m. May 26 d., Tuesday 05:44:25 Armin Berres wrote: with the template provided by Modestas. Is this our new policy? Do we officially not forward bugreports anymore (at least as long as we have no Bugsqad) and tell people immediately to take this upstream? I am just asking, because my impression after various discussions e.g. on d...@l.d.o has been that this is considered quite rude. But in fact it is way less rude than just letting the bugs rot forever. Who thinks it is rude, (s)he can join our team and do a better job (but they won't). The main difference is that KDE is not a small package and most vocal developers on d...@l.d.o have no idea what it is like to maintain a huge pile of software which you hardly use 1/3rd yourself (I base my opinion on discussion about copyright files). It is either: 1) let user know what is typically going to happen with his/her bug (i.e. nothing). If we continue with tagging 'upstream', we do a pretty good job separating wasted bugs from useful ones and it is already an improvement. 2) forget/ignore bugs like we did before. BTS continues to become useless. IMHO, 1st is a better option. As for presubj, we only have a handful of people reporting upstream bugs to Debian BTS. Once they all get a template reply at least once, it is high probability they won't report such bugs again (or think good about it before reporting). So eventually such presubj's won't be needed. -- Modestas Vainius geroma...@mailas.com signature.asc Description: This is a digitally signed message part. -- http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk
Re: kde-standard pre-list
Hi, On 2009 m. April 23 d., Thursday 16:50:04 Ana Guerrero wrote: ** Apps that is already included because it belongs to kde-minimal: dolphin kappfinder kdepasswd kfind kde-window-manager klipper konqueror konqueror-nsplugins konsole ksysguard kwrite plasma-widget-folderview systemsettings I think kde-standard should depend on those apps via kde-minimal rather than directly. TODO: we need to add khelpercenter4 to minimal now. ** Apps in unstable: This lists 170 apps that are currently in unstable, please do not go into details now, just point to the clearly development only apps i may have skipt. If we skip the games and edu apps, the list is not soo long. adept akregator amor ark blinken bomber bovo digikam dragonplayer eqonomize gtk-qt-engine-kde4 gwenview juk kaddressbook kalarm kalgebra kalzium kamera kanagram kapman kate katomic kbattleship kblackbox kblocks kbounce kbreakout kbruch kcalc kcharselect kcolorchooser kcron kde-style-polyester kde-zeroconf kdeartwork-style kdegraphics-strigi-plugins kdemultimedia-kio-plugins kdenetwork-filesharing kdepim-groupware kdepim-kresources kdepim-strigi-plugins kdepim-wizards kdessh kdesudo kdf kdiamond kdiff3 kdm keurocalc kfilereplace kfloppy kfourinline kgamma kgeography kget kgoldrunner kgpg khangman khelpcenter4 kig kile killbots kimagemapeditor kinfocenter kio-ftps kipi-plugins kiriki kiten kjots kjumpingcube kleopatra klettres klines klinkstatus kmag kmahjongg kmail kmines kmix kmldonkey kmousetool kmouth kmplayer kmplot kmtrace knemo knetwalk knetworkconf knode knotes kode kolf kollision kolourpaint4 kommander kompare konq-plugins konqueror-plugin-gnash konquest konsolekalendar kontact kopete korganizer kover kpackage kpartloader kpat kpilot kppp krdc krename kreversi krfb kruler krusader ksame kscd kscreensaver kscreensaver-xsavers kshisen ksirk ksnapshot kspaceduel ksquares kstars ksudoku ksystemlog kteatime ktimer ktimetracker ktorrent ktouch kttsd ktuberling kturtle ktux kubrick kuiviewer kuser kwalletmanager kwave kweather kwin-style-crystal kwin-style-dekorator kwordquiz lskat marble okteta okular okular-extra-backends palapeli parley plasma-runners-addons plasma-scriptengine-googlegadgets plasma-scriptengine-javascript plasma-scriptengine-qedje plasma-scriptengine-superkaramba plasma-scriptengine-webkit plasma-widget-ktorrent plasma-widget-lancelot plasma-widget-weather plasma-widgets-addons plasma-widgets-workspace python-kde4 rsibreak showfoto smb4k step sweeper yakuake ** FYi, stuff i have already discarded: cervisia compiz-kde compizconfig-backend-kconfig cvsservice icecc-monitor kapptemplate kbugbuster kcachegrind kdesdk-kio-plugins kdesvn kdesvn-kio-plugins kdesdk-strigi-plugins kxsldbg lokalize rkward umbrello ** Applications in experimental: What of the following will should add to the list assuming they will be in unstable soon. amarok koffice suite ( karbon, kchart, kplato, kpresenter, krita, kspread, kthesaurus, kword) konversation kopete-silc-plugin kshutdown ksshaskpass kwin-style-skulpture kyzis plasma-widget-networkmanagement tagua (made for pre-KDE 4.1) Lets see: Depends (limited to official KDE): phonon-backend-xine (recommended backend) kdeplasma-addons plasma-scriptengines (brings all plasma-scriptengine-*) kdm gwenview okular kwalletmanager kmix kopete kget kontact kmail akregator ? (maybe something else from PIM, not an expert) dragonplayer juk kdemultimedia-kio-plugins kscd kmix (or just whole kdemultimedia metapackage instead of the 5 above) ark kscreensaver kscreensaver-xsavers plasma-desktopthemes-artwork (maybe other kdeartwork stuff) kinfocenter kcalc ? kolourpaint4 ? (a few games and maybe something from edu) (everything needed for polished root switching support) Recommends: k3b (cd burning, no alternative) kmplayer or kaffeine - advanced media player amarok (mostly due to popularity, media devices (ipod etc.) and internet services support) digikam (photo management) and showfoto ? konq-plugins (users ask too frequently
Re: meta-kde4 and meta-kde
Hello, On 2009 m. April 8 d., Wednesday 14:23:56 Peter Eisentraut wrote: Well, being able to say apt-get install kde would still be very handy. The problem with kde package name is its ambiguousness. Full kde is not what users want most of the time. Now they will have to explicitly choose either kde-full or kde-minimal so they will know what they are getting into. signature.asc Description: This is a digitally signed message part. -- http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk
Re: meta-kde4 and meta-kde
Hello, On 2009 m. April 7 d., Tuesday 08:59:21 Sune Vuorela wrote: do s/kde4/kde/ across meta-kde4 - and maybe make kde-minimal provide kde-core. +1 And maybe rename kde meta package to kde-full. +1 -keep kde4 and add kde (both do the same) I think we should remove such generic package names. At least when users install kde-full, they are aware what they are getting into. - and add some kde-desktop-full package that is kde4 with a recommends in all the cool apps: amarok, yakuake ktorrent... For users that just want everything. that might be good for the future, when more apps go kde4. However, imho, depending on kde-full would be a mistake, we need to do a better selection of packages (e.g. as kde-standard was proposed yesterday). signature.asc Description: This is a digitally signed message part. -- http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk
Re: Uploads to lenny and the $KDEHOME dilemma
Hello, I'm fine with ~/.kde for KDE4. However: 2009 m. Vasaris 4 d., trečiadienis, Sune Vuorela rašė: The first group of the users we are screwing should just do a cp .kde kde3 if they are unsure. The question is how you are going to communicate with such users (as well as current experimental users)? I disagree that changing a line in variables.mk and forgetting about it is the way to go. It might be enough for users of individual kde applications, but not for the users of the KDE desktop. What is more, I don't think that a mail to mailing list and a note in release notes are enough. The second group of users managed to migrate from .kde to .kde4. They should be able to migrate back as well. Probably they will if we let all of them know that they should do that. -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part. -- http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk
Re: Working with the tools - or around/against the tools
Hi, Thursday 03 July 2008, Ana Guerrero rašė: I do not care at all about using +++ Name or [ Name ] but when more than a person have worked in the package I like uploading it as a team upload as we have done until now. So not ok about changing that. However, current practise is not consistent with regard to if there is only one maintainer doing changes, team name address may not be used at the bottom. This practise should be avoided because: 1) Somebody is _always_ the first to make changes. So s(he) may put his/her name in the maintainer space of the changelog entry (lets call such entry entry). 2) Now the second maintainer committing changes has to: a) add +++ Changes by line for the first maintainer, which effectively means copypasting from the changelog maintainer field if 1st maitainer created a personal entry. A bit time consuming. b) add +++ Changes for My name. Pretty easy. c) replace current changelog maintainer with Debian QT/KDE Maintainers. I usually end up copying and pasting from the previous non-personal entry (but I sometimes need to search for the it due to existence of personal entries). 3) Third and subsequent maintainners has only to do 2b. So the 1st or the 2nd maintainner gets the most additional work to do with the changelog. 4) If personal changelog entries are allowed, it effectively means that dch -m will not work for creating proper new revision entry after personal changelog entry. So the 1st maintainer has to do 2c in addition to 2b or create a new personal entry _or_ leave all the burden to the 2nd maintainer. Most of these tasks can be automated by dch if the standard layout is used. However, dch behaviour depends on having the name of the real maintainer in the changelog maintainer field to transform personal entry to the team entry. Having all this said, I very dislike personal changelog entries because they potentially leave more work for the 2nd maintainer (2a part). I never do them. So if to change anything at all, in my opinion, only the following alternatives are viable: 1) Do as dch supports now, i.e. do not use team in the changelog maintainer field (Sune proposal). 2) Do not change anything until team name in the changelog maintainer is implemented in dch (Ana's wish). 3) Disallow non-team name address in the changelog mainainer field, hence everybody adds their own +++ Changes by name. I can write svn hook which would enforce this rule. This will ensure that dch -m will always work properly for creating new changelog entries. -- Modestas Vainius [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part. -- http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk
Re: current status
Hello, Wednesday 02 July 2008, Peter Eisentraut rašė: However, I have the feeling from vague observation that some parts don't really work or integrate well in a KDE 3 environment. I would like to hear what problems you have. Well, ktorrent 3.1 will obviously have lookfield of KDE4 and it will not share cookies with KDE3 konqueror. Maybe MIME associations might be a problem (fixable). However, old ktorrent will still be available in the ktorrent2.2 package (for people who don't want to pull 200mb+ of dependencies and run KDE4 daemons or can't live without RSS plugin) and I'll switch ktorrent package to 3.1 in unstable as soon ktorrent2.2 is in the archive. This would need some more thorough testing, but if there is general interest I can address that some time (or someone else could!). I'm looking forward to your help on this one because I don't use KDE3 anymore. However, ktorrent 3.1 seems to work fine on Fluxbox. -- Modestas Vainius [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part. -- http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk
Re: KDE4 dependencies problem
Hi, kdebase-workspace* has Architecture allhttp://packages.debian.org/experimental/all/kdebase-workspace/download *kdebase-workspace *has version 4.0.80-2 like i386 (this is problem because because amd64 has only first build) *kdebase-workspace *depends on: amd64 packages will go in 40 minutes (+mirror sync time). In current situation, you should still be able to install individual packages (kdebase- workspace-bin, systemsettings, kdm etc.). -- Modestas Vainius [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part. -- http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk
