Hi Ross, Ross Gammon <rossgammon@debian.org> writes: > I have spent some time going through the commit messages. There has > been a lot of work done! Yes :-) If I remember correctly, cdbs -> dh, and upstream churn between prereleases was the worst of it. >> Will you be sponsoring from git or mentors? How would you like me to >> work during the WIP cycles of the review? The git history will look a >> bit silly and confusing with too many "refinalise for release to >> unstable" commits ;-) > > I can do either. But I think in this case, I would prefer to work from > mentors (mainly because I have problems with my gbp setup on this > computer). But please also keep the git repository in sync (even if it > is on a different branch that we can merge later). > Will do! The WIP branch is called "rfs-976113-rebase" and I pushed it just now; it doesn't contain much yet. I will update mentors as soon as we have an upload candidate (still too many outstanding big issues at this time). > Actually, I would like to compliment you on your commit messages. It was > pleasing to see a verbose reason for the change, instead of some short > cryptic message that just generates more questions. > Thank you you, I appreciate that you noticed! It really helps with making sense of work from months ago that I've now forgotten the details and reasoning. And for other team members, of course. 'wish all new contributors were mentored to value this ;-) (I was) >> On #debian-multimedia, Sebastinas did a preliminary review, and two big >> issues were: >> >> 1. override_dh_auto_build had a typo! "override_override_dh_auto_build" >> * <facepalm> I've fixed this locally >> 2. I was missing an override_dh_auto_configure to make use of >> $DEB_CMAKE_EXTRA_FLAGS >> * I believe that is why the extra lib and dev packages became >> necessary. Now that I know what was causing the problem I can >> restore something closer to the old packaging. >> * Changing this in the future will require another trip through NEW, >> so what do you think the correct split of the package is? > > I was wondering why the library packages suddenly appeared. I think if > it is possible, it is best to stick to the old packages. What > applications would want to use hydrogen as a library? > Hypothetical 3rd party plugins, I think? Unfortunately even with -DWANT_SHARED=OFF we still end up with libhydrogen-core-1.0.1.a, which appears to have not been installed in the 0.9.7 series of Debian packages. I can whitelist and ignore it, but for comparison to other distributions, OpenSUSE chose to ship the lib: https://software.opensuse.org/package/libhydrogen-core0 (for 0.9.7) https://software.opensuse.org/package/libhydrogen-core1 (for 1.0.1) Also, I'm also not sure if there is any practical benefit to hydrogen-dev (hypothetical plugin development), so I'm wondering if the headers should not be installed; they weren't installed in the last release (0.9.7-6). Hydrogen-dev_1.0.1-1_all.deb is only 84KB, so could be merged into libhydrogen-core-1.0.1. Sebastinas says the -dev package is arch-specific, and if that's the case it seems like merging the -dev package into bin:libhydrogen-core-1.0.1 would be reasonable. There is something to be said the principle of least surprise when moving between distributions, but I don't have a position on way or the other. At this time we can also reassess the hydrogen and hydrogen-data split. If I was packaging Hydrogen from scratch I'm not sure that I would split them... Finally, if we maintain the split, what is your position on .desktop and appdata files? Should they go in bin:hydrogen-data, or in bin:hydrogen? >> I have not yet reopened any bugs. The list of -rm bugs is: >> 945042 642014 629105 870395 794042 586087 874907 347279 945042 >> [snip] > > I think the best thing is to reopen the bug and then close them in the > changelog once it is confirmed that they are closed. That way they are > closed with the right version information. The most important thing is > to ensure that bugs that are not fixed in the new version remain open. > I've reopened this list of bugs. > Let me know when the new version is available on mentors. > Will do! I'd just want to take care of the major design decisions first. Cheers, Nicholas
Attachment:
signature.asc
Description: PGP signature