Bug#832941: RFS: 4pane (debian: to exclusive)
On Sun, Dec 25, 2016 at 3:53 AM, David Hart wrote: > However will it be accepted into debian? The project is moribund: apart from a > single commit 3 years ago, it's been unmaintained for 6 years. That was > supposed to give time for a rewrite which hasn't happened. I might be a good idea for 4pane upstream to switch to a long-term maintained build system like autotools/cmake or something new-fangled like bazel. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#832941: RFS: 4pane (debian: to exclusive)
Hello David, On Sat, Dec 24, 2016 at 07:53:09PM +, David Hart wrote: > Many thanks for the offer. I don't mind packaging Bakefile, and it shouldn't > be > difficult to do. > > However will it be accepted into debian? The project is moribund: apart from a > single commit 3 years ago, it's been unmaintained for 6 years. That was > supposed to give time for a rewrite which hasn't happened. > > On the other hand it works as well as ever and is still easily available > (http://bakefile.org/). > > Do you feel this alters the situation? If it hasn't bitrotted after 3 years, and you're willing to fix non-wishlist bugs that get reported to the Debian bug tracker, it would be fine to upload Bakefile. -- Sean Whitton signature.asc Description: PGP signature
Bug#832941: RFS: 4pane (debian: to exclusive)
Dear Sean, >Thank you for revising your work in light of my review. We're too late >to get 4Pane into stretch, so there's no longer any time pressure on >this review process. I know. It missed the jessie freeze too ;) >So I'd like to reply regarding only the Bakefile >issue, since that's the biggest blocker to uploading this. Good; I've found more issues in d/copyright that need sorting out first. >(Also, by the time the ftp-masters are accepting NEW packages again, I >will be a DD, so I can actually do the upload for you.) //snip >I suspect that those other packages are buggy, then. I note that the >ftp-masters have stated that their review process does not operate on >precedent: the presence of any given package in the archive does not >itself constitute a reason for accepting another. I see. >Why not just go ahead and package Bakefile? It might be useful to >someone else. You don't have to invoke it during the 4Pane build; it >just needs to be possible for someone else to get everything they need >to do so from the Debian mirrors. > >I will review and sponsor your packaging of Bakefile. Many thanks for the offer. I don't mind packaging Bakefile, and it shouldn't be difficult to do. However will it be accepted into debian? The project is moribund: apart from a single commit 3 years ago, it's been unmaintained for 6 years. That was supposed to give time for a rewrite which hasn't happened. On the other hand it works as well as ever and is still easily available (http://bakefile.org/). Do you feel this alters the situation? Regards, David Hart
Bug#832941: RFS: 4pane (debian: to exclusive)
Dear David, Thank you for revising your work in light of my review. We're too late to get 4Pane into stretch, so there's no longer any time pressure on this review process. So I'd like to reply regarding only the Bakefile issue, since that's the biggest blocker to uploading this. Once we've resolved that, I'll check through all the other points in my previous review, and your replies to them. (Also, by the time the ftp-masters are accepting NEW packages again, I will be a DD, so I can actually do the upload for you.) On Fri, Dec 23, 2016 at 06:17:04PM +, David Hart wrote: > >10. .build/DONT_README (heh) explains that the Bakefile tool is required > >to regenerate the build system. I.e. the preferred format for > >modification of the buildsystem is not by editing Makefile.in, but by > >changing some other files and running Bakefile > > No, that's the way that Makefile.in was initially created, and it would be a > convenient way to make major changes to it. But most of the time I edit > Makefile.in by hand (as I just did when removing some unused bitmaps) and for > normal building, even with dh_autoreconf, bakefile itself is irrelevant. As you said, "it would be a convenient way to make major changes to it" -- that makes it the preferred format for modification. By analogy, suppose that a .png was exported from an .svg. In many cases, it will be more convenient to edit the .png directly (e.g. converting the image to greyscale with convert(1)). But the .svg must be included to satisfy DFSG. > >(is Makefile.in the only file that Bakefile outputs?). > > There are also the 3 .m4 files in AddExtraM4Files.patch, which _are_ > needed for dh_autoreconf. > > >As before, this is a violation of DFSG. I think you need to package > >Bakefile for Debian, unless you can think of a way around this. > > As above I don't believe that's necessary. I'd add that bakefile was created > for the wxWidgets toolkit, which uses it far more often than does 4Pane. Yet > the wxWidgets packages e.g. libwxgtk3.0-dev don't include bakefile and their > maintainers presumably don't feel that violates DFSG. I suspect that those other packages are buggy, then. I note that the ftp-masters have stated that their review process does not operate on precedent: the presence of any given package in the archive does not itself constitute a reason for accepting another. Why not just go ahead and package Bakefile? It might be useful to someone else. You don't have to invoke it during the 4Pane build; it just needs to be possible for someone else to get everything they need to do so from the Debian mirrors. I will review and sponsor your packaging of Bakefile. -- Sean Whitton signature.asc Description: PGP signature
Bug#832941: RFS: 4pane (debian: to exclusive)
Dear Sean, Many thanks for your further input. >Here's another review, based on your 4pane-debian-dir repo. >Must-fixes >1. At least one of the files added by AddExtraM4Files.patch isn't accounted >for in d/copyright. //snip >9. Lots of files in .build/ are not accounted for in d/copyright. Thank you. I'd completely forgotten about copyright for bitmaps/ and hadn't considered it for debian/. Many of the bitmaps were acquired in 2004/5 and I didn't record where from. After spending a lot of time tracing them I believe d/copyright is now correct. >2. Vcs-* still point to the upstream code, not your 4pane-debian-dir repo. I'd thought that repo was just for the purpose of this review. However I've corrected that now. >8. Further, could you confirm that, for the files in bitmaps/ and the >images in doc/ whose preferred format for modification is not .png, the >.xpm/.svg/whatever source is available? I see some .xpm/.svg files but >not for every file. If the preferred format for modification for those >other files is editing the .png then it's fine. There is no other source. I confirm that if I or anyone else wished to modify a .png, editing it would be the preferred method. >10. .build/DONT_README (heh) explains that the Bakefile tool is required >to regenerate the build system. I.e. the preferred format for >modification of the buildsystem is not by editing Makefile.in, but by >changing some other files and running Bakefile No, that's the way that Makefile.in was initially created, and it would be a convenient way to make major changes to it. But most of the time I edit Makefile.in by hand (as I just did when removing some unused bitmaps) and for normal building, even with dh_autoreconf, bakefile itself is irrelevant. >(is Makefile.in the only file that Bakefile outputs?). There are also the 3 .m4 files in AddExtraM4Files.patch, which _are_ needed for dh_autoreconf. >As before, this is a violation of DFSG. I think you need to package >Bakefile for Debian, unless you can think of a way around this. As above I don't believe that's necessary. I'd add that bakefile was created for the wxWidgets toolkit, which uses it far more often than does 4Pane. Yet the wxWidgets packages e.g. libwxgtk3.0-dev don't include bakefile and their maintainers presumably don't feel that violates DFSG. >11. You need to run dch -r to refresh the changelog timestamp so it is >after the various changes you've made recently. Done >Suggestions >--- > >1. You might raise the debhelper compat to 10, the latest version. That >means you can drop '--parallel --with autoreconf' which are automatic at >compat 10. Done. >2. At the top of d/rules you define various EXTRA_ env vars. Could you >explain further why you can't do this "the standard way"? Would it be >possible to make it work by patching the upstream Makefile? Generally >speaking, it's better to have a short d/rules and move logic into the >upstream Makefile (otherwise someone trying to understand it has to flip >back and forth between two files). I see what you mean. I've now done so. >3. In a previous e-mail I explained why I think it would be clearer to >call the wxWindows license "GPL-2+ or wxWindows-3.1+". So far as I can >tell you never responded to that -- please consider the points I made. >Unless I'm missing something, it would make d/copyright clearer. I think I did, but anyway: In wxWindows circles the licence is invariably referred to as the wxWindows one, often with the explanation that it's GPL-2 plus an exception. It's also used in the libwxgtk3.0 packages' d/copyright. However I don't have any expertise in such things and I'm happy to change it if it's thought necessary. >4. You should probably s/4pane/4Pane/ in 4pane.doc-base. Done. >5. Rather than installing 4Pane.desktop twice, you could do something >like this: > >override_dh_install: >dh_install >( cd debian/4pane/usr/share && mv 4Pane/rc/4Pane.desktop applications ) Done. >6. It's definitely not wrong, but it might not be optimal. What I'm >imagining is the following situation: Debian users expect to find >certain files (changelogs, copyright files) in /usr/share/doc/foo. >Since 4Pane is known as '4Pane', a user might reasonably look in >/usr/share/doc/4Pane. But then they wouldn't be able to find the >standard files. For this reason, I think /usr/share/doc/4Pane should be >a link to /usr/share/doc/4pane and 4Pane can be patched to find its help >files there. Done. Regards, David Hart
Bug#832941: RFS: 4pane (debian: to exclusive)
Dear David, Here's another review, based on your 4pane-debian-dir repo. Must-fixes -- 1. At least one of the files added by AddExtraM4Files.patch isn't accounted for in d/copyright. 2. Vcs-* still point to the upstream code, not your 4pane-debian-dir repo. 3. d/copyright says that only you hold copyright on MyGenericDirCtrl.cpp and sdk/fswatcher/*, but the file headers have several other people's names. They should all be in d/copyright. 4. Your own copyright is not all 2016. Some files are 2014, and About.htm says 2007--2016. 5. Alberto Griggio and Otto Wyss also hold copyright on MyTreeCtrl.* 6. config.guess, config.sub, configure, configure.in, Makefile.in and install-sh are not accounted for in d/copyright. 7. Some bitmaps aren't accounted for in d/copyright. For example, I'm guessing you didn't produce bitmaps/libreoffice.png yourself (unless you did?). 8. Further, could you confirm that, for the files in bitmaps/ and the images in doc/ whose preferred format for modification is not .png, the .xpm/.svg/whatever source is available? I see some .xpm/.svg files but not for every file. If the preferred format for modification for those other files is editing the .png then it's fine. 9. Lots of files in .build/ are not accounted for in d/copyright. 10. .build/DONT_README (heh) explains that the Bakefile tool is required to regenerate the build system. I.e. the preferred format for modification of the buildsystem is not by editing Makefile.in, but by changing some other files and running Bakefile (is Makefile.in the only file that Bakefile outputs?). As before, this is a violation of DFSG. I think you need to package Bakefile for Debian, unless you can think of a way around this. 11. You need to run dch -r to refresh the changelog timestamp so it is after the various changes you've made recently. Command I used to find the copyright issues: `licensecheck --copyright -r .` Suggestions --- 1. You might raise the debhelper compat to 10, the latest version. That means you can drop '--parallel --with autoreconf' which are automatic at compat 10. 2. At the top of d/rules you define various EXTRA_ env vars. Could you explain further why you can't do this "the standard way"? Would it be possible to make it work by patching the upstream Makefile? Generally speaking, it's better to have a short d/rules and move logic into the upstream Makefile (otherwise someone trying to understand it has to flip back and forth between two files). 3. In a previous e-mail I explained why I think it would be clearer to call the wxWindows license "GPL-2+ or wxWindows-3.1+". So far as I can tell you never responded to that -- please consider the points I made. Unless I'm missing something, it would make d/copyright clearer. 4. You should probably s/4pane/4Pane/ in 4pane.doc-base. 5. Rather than installing 4Pane.desktop twice, you could do something like this: override_dh_install: dh_install ( cd debian/4pane/usr/share && mv 4Pane/rc/4Pane.desktop applications ) On Sun, Nov 20, 2016 at 06:31:33PM +, David Hart wrote: > Dear Sean, > > >1. Why do you have a folder full of patches, when you are the upstream > >author of 4Pane? Have they been applied upstream, but there hasn't been > >a release of 4Pane recently? > > Yes. They are implementing your previous suggestions. There hasn't been a > recent 4Pane release and, unless needed for debian packaging reasons, there > won't be one soon. A new release is not needed. Thanks for the explanation. > >2. I see that w.r.t. 4pane/4Pane, you're using 4Pane wherever Debian > >policy permits you too. Good idea. The only thing I'm not sure about > >is the symlink from /usr/share/doc/4Pane to /usr/share/doc/4pane/html. > >It could be misleading, since Debian users expect /usr/share/doc/foo to > >give them a folder containing a changelog, a Debian changelog etc. Why > >not link to /usr/share/doc/4pane? > > IIUC the current situation is correct: the debian changelog etc files are in > /usr/share/doc/4pane/ as expected, while the symlink from /usr/share/doc/4Pane > to html/ allows the program to find its F1 help files (which can be accessed > outside the program using a doc-base reader). > > If this is wrong please tell me. 6. It's definitely not wrong, but it might not be optimal. What I'm imagining is the following situation: Debian users expect to find certain files (changelogs, copyright files) in /usr/share/doc/foo. Since 4Pane is known as '4Pane', a user might reasonably look in /usr/share/doc/4Pane. But then they wouldn't be able to find the standard files. For this reason, I think /usr/share/doc/4Pane should be a link to /usr/share/doc/4pane and 4Pane can be patched to find its help files there. -- Sean Whitton signature.asc Description: PGP signature
Bug#832941: RFS: 4pane (debian: to exclusive)
Dear Sean, >1. Why do you have a folder full of patches, when you are the upstream >author of 4Pane? Have they been applied upstream, but there hasn't been >a release of 4Pane recently? Yes. They are implementing your previous suggestions. There hasn't been a recent 4Pane release and, unless needed for debian packaging reasons, there won't be one soon. >DEP-3 has a patch header to indicate that >they have been merged upstream, if this is indeed the case. Thanks, I've now added 'upstream,' to the Origin: field. >2. I see that w.r.t. 4pane/4Pane, you're using 4Pane wherever Debian >policy permits you too. Good idea. The only thing I'm not sure about >is the symlink from /usr/share/doc/4Pane to /usr/share/doc/4pane/html. >It could be misleading, since Debian users expect /usr/share/doc/foo to >give them a folder containing a changelog, a Debian changelog etc. Why >not link to /usr/share/doc/4pane? IIUC the current situation is correct: the debian changelog etc files are in /usr/share/doc/4pane/ as expected, while the symlink from /usr/share/doc/4Pane to html/ allows the program to find its F1 help files (which can be accessed outside the program using a doc-base reader). If this is wrong please tell me. Regards, David Hart
Bug#832941: RFS: 4pane (debian: to exclusive)
Dear David, 1. Why do you have a folder full of patches, when you are the upstream author of 4Pane? Have they been applied upstream, but there hasn't been a release of 4Pane recently? DEP-3 has a patch header to indicate that they have been merged upstream, if this is indeed the case. 2. I see that w.r.t. 4pane/4Pane, you're using 4Pane wherever Debian policy permits you too. Good idea. The only thing I'm not sure about is the symlink from /usr/share/doc/4Pane to /usr/share/doc/4pane/html. It could be misleading, since Debian users expect /usr/share/doc/foo to give them a folder containing a changelog, a Debian changelog etc. Why not link to /usr/share/doc/4pane? On Mon, Nov 14, 2016 at 09:30:49PM +, David Hart wrote: > For simplicity, I've just removed the tarball. It can always be done properly > in the future when I understand better what is required. Okay. > >Also, the Vcs-* fields still point to the upstream source, not the > >packaging repository. > > Does this need to be fixed before you can use the repo. No. > If so, what should I enter there? Vcs-Git: > https://github.com/dghart/4pane-debian-dir -b master Vcs-browser: > https://github.com/dghart/4pane-debian-dir/tree/master or something > different? You should look up the definitions of the Vcs-* fields in Debian policy :) -- Sean Whitton signature.asc Description: PGP signature
Bug#832941: RFS: 4pane (debian: to exclusive)
Dear Sean, >> >I'd recommend including the upstream code in the git repository, too. >> >But what you've done is fine -- thanks! >> >> I've now added that too. > >I think you misunderstood what I was suggesting. I'm certain I did ;) >You've committed the >tarball to git, but I meant adding the unpacked upstream source. > >Unfortunately, your change means that I can't build your package from >the git repository, so it's hard for me to continue my review. Please >consider using gbp-import-dsc(1), or reverting to only having debian/ in >git if you prefer. For simplicity, I've just removed the tarball. It can always be done properly in the future when I understand better what is required. >Also, the Vcs-* fields still point to the upstream source, not the >packaging repository. Does this need to be fixed before you can use the repo. If so, what should I enter there? Vcs-Git: https://github.com/dghart/4pane-debian-dir -b master Vcs-browser: https://github.com/dghart/4pane-debian-dir/tree/master or something different? Regards, David Hart
