Re: RFC: Moving kubuntu packaging branches to pkg-kde git
¡Hola Rohan! El 2014-07-29 a las 16:10 +0200, Rohan Garg escribió: > > - master: has the shared packaging and targets the latest upstream (beta?) > > release (which should really be everything as long as something doesn't > > cause > > a problem for the other team) > > - (e.g. unstable, utopic): has any distribution specific changes > > that > > cannot be kept in master (like specific patches, recommends/suggests changes > > for archive reasons) > > and is used to generate the actual archive packages for that specific > > series. This is mostly ok, but, as I mentioned via irc, I think it would be better to split branches only when there is a packaging difference, and it should be a goal to minimize these. Right now, we have merged some bzr history for simple packages, mostly uneventful, some of the things that we need to solve are: - debian/control Maintainer field Right now Debian packages use: Maintainer: Debian Qt/KDE Maintainers And Ubuntu packages use: Maintainer: Kubuntu Developers XSBC-Original-Maintainer: Debian Qt/KDE Maintainers The merged packages use: Maintainer: Debian/Ubuntu Qt/KDE Maintainers X-Ubuntu-Maintainer: Kubuntu Developers There is a proposal of ScottK to use a debian/control.in to generate the right fields on each case (using the version vendor was it?), I would prefer to set some Maintainer string we can live with and avoid regenerating the debian/control file on build. - Bumping build dependencies versions Kubuntu packages force the rebuild of the kde packages against the newer versions of the libs it uses, even if upstream doesn't require them and/or there is no abi/api change between them, while in Debian we try to bump the build dependencies because the upstream CMakeLists.txt declares that it needs the newer version or to upload the package in a way that waits for a transition to happend. The Kubuntu solution could end up hiding some abi breakage, which, in Debian, we would prefer to expose. - Updating packages without source changes On each kde release there are a number of packages that have no changes upstream, in Debian we skip those packages. Again, problems with these packages would expose an abi breakage. > > While I believe that this mostly should work fine, at this point I'm not > > quite > > sure how to manage the changelog. OdyX suggested generating it from the git > > commit messages which I think would work out best, as we could then keep our > > respective distribution changelogs and only share the change messages. As mentioned via irc, the changelogs can be merged (dpkg-mergechangelogs can be useful here), keeping in mind that the first upload of an upstream version to a particular distribution requires a full upload, so we'll need to use an explicit '-sa' to upload an upstream version that the other distribution have already uploaded. > > For now, I would propose trying this shared repository idea out with the new > > kf5 and later also the plasma packages as you don't have any repositories > > for > > those yet. > Could we move this forward maybe? :D Yes, I believe this is the right way. -- “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are–by definition–not smart enough to debug it.” -- Brian Kernighan Saludos /\/\ /\ >< `/ signature.asc Description: Digital signature -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: RFC: Moving kubuntu packaging branches to pkg-kde git
On Thursday 07 August 2014 09:55:56 Maximiliano Curia wrote: > ¡Hola Rohan! > > El 2014-07-29 a las 16:10 +0200, Rohan Garg escribió: > > > - master: has the shared packaging and targets the latest upstream > > > (beta?) > > > release (which should really be everything as long as something doesn't > > > cause a problem for the other team) > > > > > > - (e.g. unstable, utopic): has any distribution specific > > > changes that cannot be kept in master (like specific patches, > > > recommends/suggests changes for archive reasons) > > > and is used to generate the actual archive packages for that specific > > > series. > This is mostly ok, but, as I mentioned via irc, I think it would be better > to split branches only when there is a packaging difference, and it should > be a goal to minimize these. > > Right now, we have merged some bzr history for simple packages, mostly > uneventful, some of the things that we need to solve are: > > - debian/control Maintainer field > > Right now Debian packages use: > Maintainer: Debian Qt/KDE Maintainers > And Ubuntu packages use: > Maintainer: Kubuntu Developers > XSBC-Original-Maintainer: Debian Qt/KDE Maintainers > The merged packages use: > Maintainer: Debian/Ubuntu Qt/KDE Maintainers > X-Ubuntu-Maintainer: Kubuntu Developers > > > There is a proposal of ScottK to use a debian/control.in to generate the > right fields on each case (using the version vendor was it?), I would > prefer to set some Maintainer string we can live with and avoid > regenerating the debian/control file on build. Wasn't the whole point of the maintainer change that debian maintainers were grumpy about getting mails from issues in derivatives? If we do a shared maintenance of packages on alioth I *personally* wouldn't mind just dumping the kubuntu part here. > > - Bumping build dependencies versions > > Kubuntu packages force the rebuild of the kde packages against the newer > versions of the libs it uses, even if upstream doesn't require them and/or > there is no abi/api change between them, while in Debian we try to bump the > build dependencies because the upstream CMakeLists.txt declares that it > needs the newer version or to upload the package in a way that waits for a > transition to happend. > > The Kubuntu solution could end up hiding some abi breakage, which, in > Debian, we would prefer to expose. We do that really to make our life easier... and did you dump kde-sc-dev- latest? What we do is pretty much a replacement for that as versioned breaks don't work on launchpad. You have a point though as e.g. we did not notice the ABI breakage in kdepimlibs that you found a couple days ago. > > - Updating packages without source changes > > On each kde release there are a number of packages that have no changes > upstream, in Debian we skip those packages. > > Again, problems with these packages would expose an abi breakage. We already only update packages with diffs in post-release updates, so it would be trivial to just do that all the time. (The exceptions are kde4libs and kdepimlibs which are always updated) At least if we keep using our scripts we'll have to fix the version bumping that we talked about in the previous point. > > > > While I believe that this mostly should work fine, at this point I'm not > > > quite sure how to manage the changelog. OdyX suggested generating it > > > from the git commit messages which I think would work out best, as we > > > could then keep our respective distribution changelogs and only share > > > the change messages. > As mentioned via irc, the changelogs can be merged (dpkg-mergechangelogs can > be useful here), keeping in mind that the first upload of an upstream > version to a particular distribution requires a full upload, so we'll need > to use an explicit '-sa' to upload an upstream version that the other > distribution have already uploaded. > > > > For now, I would propose trying this shared repository idea out with the > > > new kf5 and later also the plasma packages as you don't have any > > > repositories for those yet. > > > > Could we move this forward maybe? :D > > Yes, I believe this is the right way. How would you propose we handle updating copyright files? As you probably know we are pretty lazy when it comes to that (as it's a horrible black hole for developer time). Would you be fine with updating that whenever you get to the point of uploading? Or do you have a process that allows updating them pretty fast? Maybe we could set up a script to check the copyright changes between upstream versions to make that faster? Philip -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: RFC: Moving kubuntu packaging branches to pkg-kde git
¡Hola Philip! El 2014-08-07 a las 10:39 +0200, Philip Muskovac escribió: > Wasn't the whole point of the maintainer change that debian maintainers were > grumpy about getting mails from issues in derivatives? Afaik it was for reports reported to the Debian maintainers that were unaware or not interested in the derivatives, if we are merging the teams then that complain shouldn't apply, it sort of depends on the noise level it generates, though. Is there a way to configure the launchpad bugs to be sent to another ml instead of the Maintainer address ? > We do that really to make our life easier... and did you dump kde-sc-dev- > latest? No, but I haven't updated it in a while. It might be obsoleted after kf5, I don't know. > What we do is pretty much a replacement for that as versioned breaks > don't work on launchpad. They get ignored? We still need them for moving files between packages and such. > How would you propose we handle updating copyright files? As you probably > know > we are pretty lazy when it comes to that (as it's a horrible black hole for > developer time). Would you be fine with updating that whenever you get to the > point of uploading? Or do you have a process that allows updating them pretty > fast? Doing a git diff upstream/old_version upstream/new_version | grep -i copyright helps, specially with no changes, but after a while you need to review the whole copyright file again. There are a few projects to improve the copyright file checks [1] and generation [2], but nothing great. In particular, I don't like the generation tools that drop any change manually made to the copyright file. I use a dumb wrapper around licensecheck [3] to group the result by license and some vim macros to reformat it. > Maybe we could set up a script to check the copyright changes between > upstream > versions to make that faster? Not an easy task, but it may be possible to do a tool that either parses the git diff or that calls licensecheck in the old and the new tree and parses the licensecheck diff. [1]: https://github.com/agustinhenze/dlt [2]: https://code.launchpad.net/~clint-fewbar/+junk/lcheck [3]: http://maxy.com.ar/debian/license-helper.py -- “First, solve the problem. Then, write the code.” -- John Johnson Saludos /\/\ /\ >< `/ signature.asc Description: Digital signature -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
