Re: RFC: Moving kubuntu packaging branches to pkg-kde git
Hi Maxy, > El 2014-08-12 a las 21:47 +0200, Philip Muskovac escribió: > > They don't get ignored, but if one build-dep breaks another the build will > > just FTBFS instead of dep-wait on the new version. And even scripted > > retrying of hundreds of builds is not really fun so we dumped > > kde-sc-dev-latest. The reason why we still bump versions all the time is > > to automatically catch kde-internal lib transitions. So even if we only > > update the changed packages this should still depend on the most recent > > packaged version (which should at that point be scripted) > > It could be an interesting project, kde-sc-dev-latest is a nice way to do > build dependencies change once, and thus with fewer errors, so if the amount > of bumps needed is big enought then any development pays itself. > > > On that point, how do you plan to handle no-change updates for kf5? As far > > as I remember upstream did say that having mismatched versions between kf5 > > components is unsupported. > > I might have missed that comment. I don't see the point on > uploading/rebuilding the package if the code doesn't change. So, what do > they mean by unsupported? They plan to break the abi on every release? No, not that but: framework cmakelists have one var for version that is defined to both define the framework's version and the versions it will look for in other frameworks so cmake would probably be rather unhappy if you skip things. And as the version changes for all components each release there wouldn't really be "no" change. > > > > > 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 > > > > [3] is already more helpful than the other scripts I ran into so far so > > thanks for sharing that. > I'm glad and surprised its useful to someone else. :) > > Working in the calligra package made me reevaluate lcheck, and now I think > that a mix of static information mixed with the auto updated blocks is > possible. > > > Going back to the original mail and the branch layout my original approach > > might've been a bit over complicated for what we actually need... > > > > So assuming a package that can be synced, where would we put the updates? > > 'master' seems to be meant for anything that targets unstable, so if you > > want to target 4.13 for the time being, should our changes for 4.14 be put > > into a 'next' that merges the unstable changes from master and is later > > merged back into master? > > Sounds like a solid plan. About this particular example, I plan to build > 4.13.97 soonish to prepare the transitions (if any) to have 4.14 in jessie. > > > Packages with a permanent diff from us lead back to my original proposal, > > which would mean 'master', 'next' like above and e.g. 'utopic' that we > > would continuously merge with next. > > > > Does that sound sane or do you have a better idea? > > I'm not sure if having branches that we are not actually using/building is > going to work, doing merges and reverts for unwanted changes is too awful? The idea was to make things easier for your side considering we would be moving into your repositories... I wouldn't mind starting out simple: Just move our packaging to alioth and start our branches by branching from master and then working there like we currently do with bzr on launchpad. Once you get to the point where you start working on a new version you could then merge our dev branch into master revert anything you don't want and batch our changelog into one update entry. After that we go and merge the result back into our branch and continue from there. That is close to what we do now (considering you've been looking at our packages), and should be an easy enough workflow for people to switch to. Philip signature.asc Description: This is a digitally signed message part. -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: RFC: Moving kubuntu packaging branches to pkg-kde git
Hi Maxy, On Thursday 07 August 2014 12:44:37 Maximiliano Curia wrote: > ¡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 ? Launchpad doesn't really care about the Maintainer that much. At least it doesn't matter for the default bug mails so that's a non-issue. I think it's more about people that know a bit about the package management seeing the email address in the package manager. > > > 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. They don't get ignored, but if one build-dep breaks another the build will just FTBFS instead of dep-wait on the new version. And even scripted retrying of hundreds of builds is not really fun so we dumped kde-sc-dev-latest. The reason why we still bump versions all the time is to automatically catch kde-internal lib transitions. So even if we only update the changed packages this should still depend on the most recent packaged version (which should at that point be scripted) On that point, how do you plan to handle no-change updates for kf5? As far as I remember upstream did say that having mismatched versions between kf5 components is unsupported. > > > 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 > [3] is already more helpful than the other scripts I ran into so far so thanks for sharing that. Going back to the original mail and the branch layout my original approach might've been a bit over complicated for what we actually need... So assuming a package that can be synced, where would we put the updates? 'master' seems to be meant for anything that targets unstable, so if you want to target 4.13 for the time being, should our changes for 4.14 be put into a 'next' that merges the unstable changes from master and is later merged back into master? Packages with a permanent diff from us lead back to my original proposal, which would mean 'master', 'next' like above and e.g. 'utopic' that we would continuously merge with next. Does that sound sane or do you have a better idea? Philip -- 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
RFC: Moving kubuntu packaging branches to pkg-kde git
Hi pkg-kde team, as we're currently in another rather painful package merge cycle, and with kf5 and plasma next just outside the door we've been talking about how we could move our packaging branches over to debian git to help with the merging and the rather large about of work duplication on both sides. For the large amount of SC/KF5/plasma packages we use a mostly scripted workflow which we would like to keep using, so we came up with this git branch layout: - 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. 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. A while ago I talked with maxy about commit access permissions, but for now I don't believe this would be an issue as most kubuntu packagers already are members of pkg-kde. 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. Would this be something you would consider? It would help us a lot as this would prevent us spending weeks to merge our packages and you would already have the changes for a new release in master when you plan to switch to it. Cheers, Philip Muškovac (yofel) Kubuntu Developer -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
