Re: ongoing libkdegames transition.
¡Hola Emilio! El 2015-10-17 a las 13:25 +0200, Emilio Pozuelo Monfort escribió: Sounds exactly like a standard transition? Oh, you're right. https://release.debian.org/transitions/html/auto-libkdegames.html I've uploaded libkdegames-kde4, that provides the missing libs and data packages, would the migration of this lib be blocked by this auto transition? Happy hacking, -- "The day Microsoft makes something that doesn't suck, is probably the day Microsoft starts making vacuum cleaners." -- Ernst Jan Plugge Saludos /\/\ /\ >< `/ signature.asc Description: Digital signature
Re: ongoing libkdegames transition.
¡Hola peter! El 2015-10-18 a las 09:25 +0100, peter green escribió: Do you have a preferred solution in mind? IMO if it is likely that some packages will take significant time to migrate to the new kdegames kf5 then introducing a new libkdegames-kde4 source package is probablly the way to go. Ok, the upload that reintroduces the kde4 versions of libkdegames (libkdegames-kde4) source has already been accepted, thanks to Scott Kitterman. I hope this solves the issue for now. Regarding the kde team packages I think that we are going to start removing the not migrated games after 15.12, after that we should probably send bugs about the deprecation of libkdegames-kde4. Happy hacking, -- "La duración de un minuto depende de que lado del baño estés." -- Ley de la Relatividad (Burke) Saludos /\/\ /\ >< `/ signature.asc Description: Digital signature
Re: ongoing libkdegames transition.
On 17/10/15 10:48, Maximiliano Curia wrote: Hi, On 17/10/15 03:55, peter green wrote: There appears to be a transition going on with the libkdegames source package which seems to require sourceful changes in the rdeps. A substantial number of rdeps have transitioned but a substantial number have not and no bug reports seem to have been filed on said rdeps, nor does there seem to be a transition tracker. The new package names (kf5 versions) don't clash with the old ones and the so files have different lib names, so a transition is not really needed, at least not in the way that the release team tracks them. It would have been better if we had upload the new lib with a different source name. Agreed. Is there any other package affected by this? Yes, quite a few. https://ftp-master.debian.org/cruft-report-daily.txt * source package libkdegames version 4:15.08.0-1 no longer builds binary package(s): kde-games-core-declarative libkdegames-dev libkdegames6abi1 libkdegames6abi1-dbg libkdegamesprivate1abi1 on amd64,arm64,armel,armhf,i386,kfreebsd-amd64,kfreebsd-i386,mips,mipsel,powerpc,ppc64el,s390x - suggested command: dak rm -m "[auto-cruft] NBS (no longer built by libkdegames)" -s unstable -a amd64,arm64,armel,armhf,i386,kfreebsd-amd64,kfreebsd-i386,mips,mipsel,powerpc,ppc64el,s390x -p -R -b kde-games-core-declarative libkdegames-dev libkdegames6abi1 libkdegames6abi1-dbg libkdegamesprivate1abi1 - broken Depends: kgoldrunner: kgoldrunner kigo: kigo klickety: klickety kmahjongg: kmahjongg knavalbattle: knavalbattle knetwalk: knetwalk knights: knights kolf: kolf konquest: konquest kreversi: kreversi kshisen: kshisen ksirk: ksirk ksnakeduel: ksnakeduel kspaceduel: kspaceduel ksudoku: ksudoku ktuberling: ktuberling kubrick: kubrick lskat: lskat tagua: tagua - broken Build-Depends: bomber: libkdegames-dev (>= 4:4.11) bovo: libkdegames-dev (>= 4:4.11) granatier: libkdegames-dev (>= 4:4.11) kajongg: libkdegames-dev (>= 4:4.11) kapman: libkdegames-dev (>= 4:4.11) katomic: libkdegames-dev (>= 4:4.11) kblackbox: libkdegames-dev (>= 4:4.11) kblocks: libkdegames-dev (>= 4:4.11) kbounce: libkdegames-dev (>= 4:4.11) kbreakout: libkdegames-dev (>= 4:4.11) kdiamond: libkdegames-dev (>= 4:4.11) kfourinline: libkdegames-dev (>= 4:4.11) kgoldrunner: libkdegames-dev (>= 4:14.12.2) kigo: libkdegames-dev (>= 4:14.12.0) killbots: libkdegames-dev (>= 4:4.11) kiriki: libkdegames-dev (>= 4:4.11) kjumpingcube: libkdegames-dev (>= 4:4.11) klickety: libkdegames-dev (>= 4:4.11) klines: libkdegames-dev (>= 4:4.11) kmahjongg: libkdegames-dev (>= 4:14.12.2) kmines: libkdegames-dev (>= 4:4.11) knavalbattle: libkdegames-dev (>= 4:4.11) knetwalk: libkdegames-dev (>= 4:4.11) knights: libkdegames-dev (> 4:4.9) kolf: libkdegames-dev (>= 4:14.12.2) kollision: libkdegames-dev (>= 4:4.11) konquest: libkdegames-dev (>= 4:14.12.2) kpat: libkdegames-dev (>= 4:4.11) kreversi: libkdegames-dev (>= 4:14.12.2) kshisen: libkdegames-dev (>= 4:4.11) ksirk: libkdegames-dev (>= 4:4.11) ksnakeduel: libkdegames-dev (>= 4.9.0~) kspaceduel: libkdegames-dev (>= 4:4.11) ksquares: libkdegames-dev (>= 4:4.11) ksudoku: libkdegames-dev (>= 4:14.12.2) ktuberling: libkdegames-dev (>= 4:4.11) kubrick: libkdegames-dev (>= 4:4.11) libkmahjongg: libkdegames-dev (>= 4:14.12.2) lskat: libkdegames-dev (>= 4:14.12.2) palapeli: libkdegames-dev (>= 4:14.12.2) picmi: libkdegames-dev (>= 4:4.11) tagua: libkdegames-dev (>= 4:4.10.0) I find it curious that there are more significantly more broken build-depends than broken depends, maybe some of those build-depends are bogus. As a deriviative maintainer I'd like to know what the rough plans and timescales are here so I can consider the best way to handle this downstream. Do you have a preferred solution in mind? IMO if it is likely that some packages will take significant time to migrate to the new kdegames kf5 then introducing a new libkdegames-kde4 source package is probablly the way to go.
Re: ongoing libkdegames transition.
Hi, On 17/10/15 03:55, peter green wrote: > There appears to be a transition going on with the libkdegames source > package which seems to require sourceful changes in the rdeps. A > substantial number of rdeps have transitioned but a substantial number have > not and no bug reports seem to have been filed on said rdeps, nor does > there seem to be a transition tracker. The new package names (kf5 versions) don't clash with the old ones and the so files have different lib names, so a transition is not really needed, at least not in the way that the release team tracks them. It would have been better if we had upload the new lib with a different source name. Right now, if we need fix something in the kde4 version we would need to upload a new source package named libkdegames-kde4 or something. > The new kdegames package has migrated to testing, presumablly under > "smooth updates" leaving out of data packages in testing. Interesting, I haven't noticed this, that leaves lskat in a weird state. I'm expecting lskat to be migrated to frameworks in 15.12, in the meantime we should probably remove lskat from testing, otherwise we would need to either upload the beta frameworks version of lskat or upload the libkdegames-kde4 version mentioned earlier. Is there any other package affected by this? > As a deriviative maintainer I'd like to know what the rough plans and > timescales are here so I can consider the best way to handle this > downstream. Do you have a preferred solution in mind? Thanks for reporting the issue. -- "It is not the task of the University to offer what society asks for, but to give what society needs." -- Edsger W. Dijkstra Saludos /\/\ /\ >< `/ signature.asc Description: OpenPGP digital signature
Re: ongoing libkdegames transition.
On 17/10/15 11:48, Maximiliano Curia wrote: > Hi, > > On 17/10/15 03:55, peter green wrote: >> There appears to be a transition going on with the libkdegames source >> package which seems to require sourceful changes in the rdeps. A >> substantial number of rdeps have transitioned but a substantial number have >> not and no bug reports seem to have been filed on said rdeps, nor does >> there seem to be a transition tracker. > > The new package names (kf5 versions) don't clash with the old ones and the so > files have different lib names, so a transition is not really needed, at least > not in the way that the release team tracks them. Sounds exactly like a standard transition? > Is there any other package affected by this? Take a look at this: https://release.debian.org/transitions/html/auto-libkdegames.html And from https://release.debian.org/britney/update_output.txt: trying: -libkdegames6abi1/i386 skipped: -libkdegames6abi1/i386 (54, 9) got: 49+0: a-9:i-27:a-3:a-1:a-1:m-1:m-1:p-1:p-3:s-2 * i386: kbattleship, kde-games-core-declarative, kgoldrunner, kigo, klickety, kmahjongg, knavalbattle, knetwalk, knights, knights-dbg, kolf, konquest, kreversi, kshisen, ksirk, ksnakeduel, kspaceduel, ksudoku, ktuberling, kubrick, libkdegamesprivate1abi1, tagua trying: -libkdegamesprivate1abi1/i386 skipped: -libkdegamesprivate1abi1/i386 (25, 38) got: 33+0: a-9:i-11:a-3:a-1:a-1:m-1:m-1:p-1:p-3:s-2 * i386: kigo, kmahjongg, ksirk, ksnakeduel, ksudoku, tagua trying: -kde-games-core-declarative/i386 skipped: -kde-games-core-declarative/i386 (33, 30) got: 28+0: a-9:i-6:a-3:a-1:a-1:m-1:m-1:p-1:p-3:s-2 * i386: knetwalk Cheers, Emilio
ongoing libkdegames transition.
There appears to be a transition going on with the libkdegames source package which seems to require sourceful changes in the rdeps. A substantial number of rdeps have transitioned but a substantial number have not and no bug reports seem to have been filed on said rdeps, nor does there seem to be a transition tracker. The new kdegames package has migrated to testing, presumablly under "smooth updates" leaving out of data packages in testing. As a deriviative maintainer I'd like to know what the rough plans and timescales are here so I can consider the best way to handle this downstream.
