Re: So what's kdebase waiting for now?
On Thu, Dec 18, 2003 at 01:23:39AM +0100, Dominique Devriese wrote: > Nathanael Nerode writes: > > > ...taps fingers "ASAP" as of two days ago. Any chance this > > will happen this year?!? > > I've been naggin enough, so I'll try to be constructive here :) > > The kdebase bugs that I think are relevant to this upload ( I've been > working through quite some kdebase bugs recently, so I'm becoming a > bit familiar with them ;) ) are the following: I haven't looked the bugs listed here yet but I have essentially finished the kdebase deb except for making it actually compile :\ I think I have fixed everything you listed (from a brief look) as well as some others. I have also already finished the kdm debconf stuff as well, which was porting all of xdm's scripts over to kdm (not using the simple gdm one) but haven't tested it yet since I can't get it to compile. The last time I tried building it failed due to not finding -lkicker. I will try to determine what the problem is and get it uploaded. Chris signature.asc Description: Digital signature
kdenonbeta/kdedebian/kapture/kapture
CVS commit by mornfall: First working version of grouper. Can successfully load package list into a listview. May not compile right now... M +5 -0 kapture_part.cpp 1.2 M +86 -3 pkggrouper.cpp 1.3 M +38 -28pkggrouper.h 1.3 M +55 -0 pkglist.cpp 1.2 M +29 -6 pkglist.h 1.2 M +1 -0 pkgsubtree.h 1.3 M +22 -1 pkgtree.cpp 1.3 M +2 -1 pkgtreeitem.cpp 1.3 M +5 -7 pkgtreeitem.h 1.3 M +1 -0 pkgtreenode.h 1.3 M +3 -5 pkgview.cpp 1.2
Re: So what's kdebase waiting for now?
Chris Cheney writes: > I haven't looked the bugs listed here yet but I have essentially > finished the kdebase deb except for making it actually compile :\ I > think I have fixed everything you listed (from a brief look) as well > as some others. I have also already finished the kdm debconf stuff > as well, which was porting all of xdm's scripts over to kdm (not > using the simple gdm one) but haven't tested it yet since I can't > get it to compile. The last time I tried building it failed due to > not finding -lkicker. I will try to determine what the problem is > and get it uploaded. If you want, I'm willing to try and help out. Just tell me where to get the debian/ dir you're using, and I'll see what I can do. cheers domi
Re: Three more bugs:
On Thu, Dec 18, 2003 at 02:00:42AM +0100, Dominique Devriese wrote: > Here are three more bugs that you can close in the new upload, that I > forgot in my last mail: -snip- > Thanks for your work > domi I noticed while attempting to clean up kde BTS reports, that you have been very active caring about the bugs. I think you would be great help for the project if you would join the Debian QT/Kde maintainers team on alioth[1]. notice that you don't need to be a debian developer to get an alioth account and thus join projects. I'm not sure whats the post-breakin status of alioth, but I guess that after we get this kdebase stuff cleared, we can have a kick-off of the group maintainership. [1] http://alioth.debian.org/projects/pkg-kde/ -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark> A bad analogy is like leaky screwdriver | pgpevVU22PkyS.pgp Description: PGP signature
Re: Three more bugs:
Riku Voipio writes: > I noticed while attempting to clean up kde BTS reports, that you > have been very active caring about the bugs. I think you would be > great help for the project if you would join the Debian QT/Kde > maintainers team on alioth[1]. notice that you don't need to be a > debian developer to get an alioth account and thus join projects. > I'm not sure whats the post-breakin status of alioth, but I guess > that after we get this kdebase stuff cleared, we can have a kick-off > of the group maintainership. > [1] http://alioth.debian.org/projects/pkg-kde/ Hi, I'm flattered that you're asking me, I would very much like to join the project, I often post patches on the BTS that are trivial enough that I could simply have applied them myself, and it does sometimes seem a bit of a waste of time to not do it like that. I realize that I don't have enough experience with Debian packaging and the KDE Debian packages themselves to commit bigger things yet, but I do think it would be useful to have alioth access for the occasional trivial patches. How do I go about getting access to the project ? I have some questions about how this group operates, but I'll ask those in a separate mail. cheers domi
Debian KDE maintenance
Hi, I have some questions about how development occurs on the KDE Debian packages: 1. Exactly what is the role of the alioth pkg-kde project ? AFAICT from the website, there is no activity there, even the CVS repository is empty. 2. Where does active development occur on the packages ? KDE CVS or the repository on alioth ? If on KDE CVS, then in what branch do you work ? 3_1 or HEAD ? When will you move to the new 3_2 branch ? 3. How do you handle the upstream releases ? Do you take an official tarball as prepared by the KDE release dude, or do you pull your own copy from CVS at a time that suits you ? What happens if you then need to make some modifications to the debian-specific stuff and release a new package, but still based on the same upstream release ? 4. Is there an irc channel where you discuss the debian kde package development ? 5. Is there some kind of procedure on committing changes to the debian/ stuff ? I suppose trivial patches can be applied without a problem ? Where does discussion occur on more intrusive patches ? 6. What is the status of the group maintainership ? Well, those are basically the questions I have atm, I hope you can provide me with some answers :) thanks domi
kdebase/debian
CVS commit by rnolden: update M +0 -1 kappfinder.install 1.19 M +6 -0 ksplash.install 1.13 --- kdebase/debian/kappfinder.install #1.18:1.19 @@ -138,5 +138,4 @@ debian/tmp/usr/share/apps/kappfinder/apps/Multimedia/MP3info.desktop debian/tmp/usr/share/apps/kappfinder/apps/Multimedia/XMovie.desktop -debian/tmp/usr/share/apps/kappfinder/apps/Multimedia/Xpcd.desktop debian/tmp/usr/share/apps/kappfinder/apps/Multimedia/alevt.desktop debian/tmp/usr/share/apps/kappfinder/apps/Multimedia/aviplay.desktop --- kdebase/debian/ksplash.install #1.12:1.13 @@ -28,4 +28,10 @@ debian/tmp/usr/share/apps/ksplash/pics/splash.png debian/tmp/usr/share/doc/kde/HTML/en/ksplashml +debian/tmp/usr/share/icons/crystalsvg/22x22/apps/ksplash.png +debian/tmp/usr/share/icons/crystalsvg/128x128/apps/ksplash.png +debian/tmp/usr/share/icons/crystalsvg/32x32/apps/ksplash.png +debian/tmp/usr/share/icons/crystalsvg/16x16/apps/ksplash.png +debian/tmp/usr/share/icons/crystalsvg/64x64/apps/ksplash.png +debian/tmp/usr/share/icons/crystalsvg/48x48/apps/ksplash.png debian/tmp/usr/share/services/ksplash.desktop debian/tmp/usr/share/services/ksplashdefault.desktop
Re: Debian KDE maintenance
On Thu, Dec 18, 2003 at 03:13:57PM +0100, Dominique Devriese wrote: > 1. Exactly what is the role of the alioth pkg-kde project ? AFAICT > from the website, there is no activity there, even the CVS > repository is empty. The role is what we define it to be :) It is still in the planning phase. There is no cvs repository, because the current plan is to use subversion [1] not much to see there either. > 2. Where does active development occur on the packages ? KDE CVS or > the repository on alioth ? If on KDE CVS, then in what branch do > you work ? 3_1 or HEAD ? When will you move to the new 3_2 > branch ? There will be several diffrent branches. The model Branden uses for xfree86 maintainance[2] is probably close to what will be in kde svn. Now if I remember correctly, that means that "trunk" is whatever is going to next to sid, and under branches we debian dirs for other upstream versions (cvs, 3_2 and if we would have started this earlier 2_2). And under there, dirs for debian releases (sid/woody and soon sarge). And under people we have our own sandboxes where we can try any nontrivial changes. Now that's the plan, search the archives for more discussion. If anyone comes out with better ideas, now is the good time tell about them :) > 3. How do you handle the upstream releases ? Do you take an official > tarball as prepared by the KDE release dude, or do you pull your > own copy from CVS at a time that suits you ? What happens if you > then need to make some modifications to the debian-specific stuff > and release a new package, but still based on the same upstream > release ? Afaik we take the relases from cvs and clean them abit (remove CVS dirs etc). debian-specific changes are shipped as paches under debian/patches. > 4. Is there an irc channel where you discuss the debian kde package > development ? #debian-kde on freenode. There is typically more non-development discussion there thou. > 5. Is there some kind of procedure on committing changes to the > debian/ stuff ? I suppose trivial patches can be applied without > a problem ? Where does discussion occur on more intrusive patches > ? The policy suggestion[3] seems disappeared from people.debian.org - probably cleaned just to be sure. If I remember correctly, nontrivial patches should be done under your own people/domi branch, where the main package maintainer can verify them and merge it to trunk. > 6. What is the status of the group maintainership ? Waiting that the more critical stuff (kdebase) gets done, basicly. I think everyone pretty much agreed with the proposed policy. And svn is pretty new to most of us, so there will probably be some experimenting with it first. And finally as reply to your other mail, you need get an alioth account and ask one the project admins to add you. [1] http://svn.debian.org/ [2] http://deadbeast.net/~branden/svn_pres/top.html [3] http://people.debian.org/~madkiss/debian-kde-policy.html -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark> A bad analogy is like leaky screwdriver | pgpWYEnzA8kKi.pgp Description: PGP signature
kdebase_3.1.4-1_i386.changes ACCEPTED
Accepted: kappfinder_3.1.4-1_i386.deb to pool/main/k/kdebase/kappfinder_3.1.4-1_i386.deb kate_3.1.4-1_i386.deb to pool/main/k/kdebase/kate_3.1.4-1_i386.deb kcontrol_3.1.4-1_i386.deb to pool/main/k/kdebase/kcontrol_3.1.4-1_i386.deb kdebase-bin_3.1.4-1_i386.deb to pool/main/k/kdebase/kdebase-bin_3.1.4-1_i386.deb kdebase-data_3.1.4-1_all.deb to pool/main/k/kdebase/kdebase-data_3.1.4-1_all.deb kdebase-dev_3.1.4-1_i386.deb to pool/main/k/kdebase/kdebase-dev_3.1.4-1_i386.deb kdebase-kio-plugins_3.1.4-1_i386.deb to pool/main/k/kdebase/kdebase-kio-plugins_3.1.4-1_i386.deb kdebase_3.1.4-1.diff.gz to pool/main/k/kdebase/kdebase_3.1.4-1.diff.gz kdebase_3.1.4-1.dsc to pool/main/k/kdebase/kdebase_3.1.4-1.dsc kdebase_3.1.4-1_all.deb to pool/main/k/kdebase/kdebase_3.1.4-1_all.deb kdebase_3.1.4.orig.tar.gz to pool/main/k/kdebase/kdebase_3.1.4.orig.tar.gz kdeprint_3.1.4-1_i386.deb to pool/main/k/kdebase/kdeprint_3.1.4-1_i386.deb kdesktop_3.1.4-1_i386.deb to pool/main/k/kdebase/kdesktop_3.1.4-1_i386.deb kdm_3.1.4-1_i386.deb to pool/main/k/kdebase/kdm_3.1.4-1_i386.deb kfind_3.1.4-1_i386.deb to pool/main/k/kdebase/kfind_3.1.4-1_i386.deb khelpcenter_3.1.4-1_i386.deb to pool/main/k/kdebase/khelpcenter_3.1.4-1_i386.deb kicker_3.1.4-1_i386.deb to pool/main/k/kdebase/kicker_3.1.4-1_i386.deb klipper_3.1.4-1_i386.deb to pool/main/k/kdebase/klipper_3.1.4-1_i386.deb kmenuedit_3.1.4-1_i386.deb to pool/main/k/kdebase/kmenuedit_3.1.4-1_i386.deb konqueror-nsplugins_3.1.4-1_i386.deb to pool/main/k/kdebase/konqueror-nsplugins_3.1.4-1_i386.deb konqueror_3.1.4-1_i386.deb to pool/main/k/kdebase/konqueror_3.1.4-1_i386.deb konsole_3.1.4-1_i386.deb to pool/main/k/kdebase/konsole_3.1.4-1_i386.deb kpager_3.1.4-1_i386.deb to pool/main/k/kdebase/kpager_3.1.4-1_i386.deb kpersonalizer_3.1.4-1_i386.deb to pool/main/k/kdebase/kpersonalizer_3.1.4-1_i386.deb ksmserver_3.1.4-1_i386.deb to pool/main/k/kdebase/ksmserver_3.1.4-1_i386.deb ksplash_3.1.4-1_i386.deb to pool/main/k/kdebase/ksplash_3.1.4-1_i386.deb ksysguard_3.1.4-1_i386.deb to pool/main/k/kdebase/ksysguard_3.1.4-1_i386.deb ksysguardd_3.1.4-1_i386.deb to pool/main/k/kdebase/ksysguardd_3.1.4-1_i386.deb ktip_3.1.4-1_i386.deb to pool/main/k/kdebase/ktip_3.1.4-1_i386.deb kwin_3.1.4-1_i386.deb to pool/main/k/kdebase/kwin_3.1.4-1_i386.deb libkonq4-dev_3.1.4-1_i386.deb to pool/main/k/kdebase/libkonq4-dev_3.1.4-1_i386.deb libkonq4_3.1.4-1_i386.deb to pool/main/k/kdebase/libkonq4_3.1.4-1_i386.deb xfonts-konsole_3.1.4-1_all.deb to pool/main/k/kdebase/xfonts-konsole_3.1.4-1_all.deb Announcing to debian-devel-changes@lists.debian.org Closing bugs: 142489 154065 192550 206958 209532 209856 212212 218731 223407 Thank you for your contribution to Debian.
Processing of kdebase_3.1.4-1_i386.changes
kdebase_3.1.4-1_i386.changes uploaded successfully to localhost along with the files: kdebase_3.1.4-1.dsc kdebase_3.1.4.orig.tar.gz kdebase_3.1.4-1.diff.gz kappfinder_3.1.4-1_i386.deb kate_3.1.4-1_i386.deb kcontrol_3.1.4-1_i386.deb kdebase-bin_3.1.4-1_i386.deb kdebase-dev_3.1.4-1_i386.deb kdebase-kio-plugins_3.1.4-1_i386.deb kdeprint_3.1.4-1_i386.deb kdesktop_3.1.4-1_i386.deb kdm_3.1.4-1_i386.deb kfind_3.1.4-1_i386.deb khelpcenter_3.1.4-1_i386.deb kicker_3.1.4-1_i386.deb klipper_3.1.4-1_i386.deb kmenuedit_3.1.4-1_i386.deb konqueror_3.1.4-1_i386.deb konqueror-nsplugins_3.1.4-1_i386.deb konsole_3.1.4-1_i386.deb kpager_3.1.4-1_i386.deb kpersonalizer_3.1.4-1_i386.deb ksmserver_3.1.4-1_i386.deb ksplash_3.1.4-1_i386.deb ksysguard_3.1.4-1_i386.deb ksysguardd_3.1.4-1_i386.deb ktip_3.1.4-1_i386.deb kwin_3.1.4-1_i386.deb libkonq4_3.1.4-1_i386.deb libkonq4-dev_3.1.4-1_i386.deb kdebase_3.1.4-1_all.deb kdebase-data_3.1.4-1_all.deb xfonts-konsole_3.1.4-1_all.deb Greetings, Your Debian queue daemon
Re: Debian KDE maintenance
On Thu, Dec 18, 2003 at 03:13:57PM +0100, Dominique Devriese wrote: > > Hi, > > I have some questions about how development occurs on the KDE Debian > packages: > > 1. Exactly what is the role of the alioth pkg-kde project ? AFAICT > from the website, there is no activity there, even the CVS > repository is empty. The primary role of the alioth pkg-kde project is likely to be for svn access to the pkg-kde repo. It will be accessible to anyone who wants to join the group, although it will probably be primarily maintained by the current maintainers of the respective packages. Using svn or a rcs in general outside of the KDE repo allows for maintaining debian dirs for particular KDE releases easier. For example, it makes it easier to fixup a debian dir for KDE 3.2b2. Also since we are using svn its easier to move files and dirs around and change permissions if needed. I intend to keep i18n translations in KDE cvs though, since they seem to be updated by the KDE i18n team, which is in much better shape than the Debian i18n team. > 2. Where does active development occur on the packages ? KDE CVS or > the repository on alioth ? If on KDE CVS, then in what branch do > you work ? 3_1 or HEAD ? When will you move to the new 3_2 > branch ? So far I am still trying to clean up KDE_3_1_BRANCH for sarge. I think I will wait to try the pkg-kde svn for KDE 3.2. I will be moving to 3.2 once I have the rest of KDE built with the new patch system. > 3. How do you handle the upstream releases ? Do you take an official > tarball as prepared by the KDE release dude, or do you pull your > own copy from CVS at a time that suits you ? What happens if you > then need to make some modifications to the debian-specific stuff > and release a new package, but still based on the same upstream > release ? I have decided to do the following: cvs export KDE_3_1_4_RELEASE cvs export KDE_3_1_BRANCH run make -f admin/Makefile.common in foo-3.1.4 and then create the tarball. run diff -Nrua foo-3.1.4 foo-branch > 01_foo_branch.diff run uuencode 01_foo_branch.diff 01_foo_branch.diff > 01_foo_branch.diff.uu This lets us not have the CVS related stuff in the tarball. Apparently upstream keeps the CVS dirs in the tarball due to how fucked up their source is, if you want details feel free to ask. Then I put all the debian specific changes into debian/patches along with the 01_foo_branch.diff.uu. The reason that the branch diff is uuencoded is to allow easy inclusion of binary updates, which debian tools do not allow in the packages diff.gz directly. It may be a good idea in the future to also uuencode Debian specific binary files that are under the debian dir, so they can be changed in between upstream releases. Never make any changes outside of the debian dir that aren't done via patches, that way leads to insanity. If you modify the build system make sure to run make -f admin/Makefile.common again (and remember to make sure the patches have been applied before doing this) since we're using AM_MAINTAINER_MODE this will force update the autotools file such as Makefile.in and the changes will be in the packages diff.gz. The above sounds complicated but once you've done it a few times its easy to remember. > 4. Is there an irc channel where you discuss the debian kde package > development ? There are two channels on freenode #debian-kde and #debian-qt-kde. I intended #debian-qt-kde to be the developer channel but no one seems to be in there except for me. Either is fine to discuss issues. > 5. Is there some kind of procedure on committing changes to the > debian/ stuff ? I suppose trivial patches can be applied without > a problem ? Where does discussion occur on more intrusive patches > ? If you need to change things and they are minor just commit them or file a bug with a patch. If something major needs to change then email the maintainer of the package and/or send an email to this list. > 6. What is the status of the group maintainership ? Anyone can join, we need people that can triage bugs (forward, close, etc) like what you currently do, and others that can help with packaging issues. There is also some new Debian work being done upstream in kdenonbeta which would be useful to help with. I think they are working on a debconf frontend and a few other projects. If you are interested in the upstream debian projects join the kde-debian list that is on lists.kde.org. Chris BTW - kdebase 3.1.4-1 is in incoming now. signature.asc Description: Digital signature
