Bug#832941: RFS: 4pane
Dear Sean, >Sorry, I assumed that uscan would redownload the .pgp file, but it was >using the old one. Apologies for wasting your time with that. That's OK, I've wasted plenty of yours ;) >While you previously said that everything remaining in .build/ is your >own work, the file wxwin.m4 is not yours. So that needs to be added to >d/copyright. Ah, I see the problem. In the tarball .build/ contains only 3 files, all mine. However a 4th is added by ChangeToAutomakeBuild.patch, and that does indeed need a d/copyright entry. I've added one, calling it .build/wxwin.m4 as that's where it will end up. Please let me know if I should instead have referred to d/patches/. >The patch header for ChangeToAutomakeBuild.patch does not make sense... Well spotted. A copy/paste error, now fixed. >These two are the only remaining issues in d35ef45. >I also noticed that you often cram several copyright lines into a single >line. Please consider using line breaks. Done. >If you're able to address the issues I've raised in this message, please >remove the moreinfo tag in this bug, and don't forget to re-run `dch -r` >to refresh the changelog timestamp. I hope I've removed the tag, though the bug's status has not yet updated. Regards, David Hart
Bug#832941: RFS: 4pane
Dear David, On Tue, Mar 28, 2017 at 01:36:03PM +0100, David Hart wrote: > Hmm, I can't make it fail here. e.g. Sorry, I assumed that uscan would redownload the .pgp file, but it was using the old one. Apologies for wasting your time with that. While you previously said that everything remaining in .build/ is your own work, the file wxwin.m4 is not yours. So that needs to be added to d/copyright. The patch header for ChangeToAutomakeBuild.patch does not make sense... These two are the only remaining issues in d35ef45. As a suggestion, strictly optional: I also noticed that you often cram several copyright lines into a single line. Please consider using line breaks. E.g. Copyright: 2005-2014, Mike Hommey 1998-2010, Mozilla Project instead of Copyright: 2005-2014, Mike Hommey 1998-2010, Mozilla Project Similarly for some Files: fields. If you're able to address the issues I've raised in this message, please remove the moreinfo tag in this bug, and don't forget to re-run `dch -r` to refresh the changelog timestamp. -- Sean Whitton signature.asc Description: PGP signature
Bug#832941: RFS: 4pane
Dear Sean, >I can't review your latest work because the PGP signature for the >tarball fails to verify: >iris ~/rfs/4pane % origtargz -u >W: Unable to locate package 4pane >Trying uscan --download-current-version ... >uscan: Newest version of 4pane on remote site is 4.0, specified download > version is 4.0 gpgv: Signature made Wed 22 Mar 2017 01:04:44 PM MST >gpgv:using RSA key D594F63B22250D6A >gpgv: BAD signature from "David Hart " >uscan warn: OpenPGP signature did not verify. >Could not find any location for 4pane_4.0+dfsg.orig.tar.* >I guess that you haven't uploaded an updated signature. Hmm, I can't make it fail here. e.g. ~/temp/retry/4pane> origtargz -u W: Unable to locate package 4pane Trying uscan --download-current-version ... uscan: Newest version of 4pane on remote site is 4.0, specified download version is 4.0 gpgv: Signature made Wed 22 Mar 2017 20:04:44 GMT gpgv:using RSA key D594F63B22250D6A gpgv: Good signature from "David Hart " Unpacking ../4pane_4.0+dfsg.orig.tar.gz That was using a fresh debian repo clone. I also tried uscan direct, and did a gpg2 --verify direct on the uploaded file. Finally I tested in a new virtualbox guest. All were successful. Can you think of anything else that might be going wrong? Regards, David Hart
Bug#832941: RFS: 4pane
Dear David, I can't review your latest work because the PGP signature for the tarball fails to verify: iris ~/rfs/4pane % origtargz -u W: Unable to locate package 4pane Trying uscan --download-current-version ... uscan: Newest version of 4pane on remote site is 4.0, specified download version is 4.0 gpgv: Signature made Wed 22 Mar 2017 01:04:44 PM MST gpgv:using RSA key D594F63B22250D6A gpgv: BAD signature from "David Hart " uscan warn: OpenPGP signature did not verify. Could not find any location for 4pane_4.0+dfsg.orig.tar.* I guess that you haven't uploaded an updated signature. I tried to verify the change by comparing the tarballs with diffoscope, to work around this, but the paths within the tarball have changed (4pane-4.0/ -> ./4pane-4.0/) so that is not feasible. -- Sean Whitton signature.asc Description: PGP signature
Bug#832941: RFS: 4pane
Dear Sean, >>> Files in .build/ remain, and are not given in d/copyright. >> The remaining ones are my own files. Won't they be covered by '*'? >Oh, sorry, I assumed you hadn't written 4pane.m4. Not so many people >know m4, as I understand it :) I believe you; it's not my idea of light relaxation either. >Having read the results of your research, I suggest the following >approach: >- insert all the authorship info you've managed to find thus far -- no > reason to throw away that effort -- in the Copyright: field, not > Comment:. > In the situation where you have a list of project authors but it is > unlikely that they all worked on the icon file, just list them all, > and put "Comment: These are the authors for the upstream project from > which this file was obtained." >- for the files where it is not clear, write a copyright string based on > the project name. E.g. for kedit.xpm, "(C) 1999 kde-artist team" >If this doesn't sound sane, it might be best to ask debian-legal. But I >think we could go ahead and upload and see what the ftp-masters think of >my proposed solution. Thank you for the suggestion, which sounds entirely reasonable to me. I've updated d/copyright along those lines, and uploaded a new tarball with Makefile.in removed. >> Finally, my ITP has timed-out and the package removed from >> mentors. Does this now matter? >We don't need mentors since I am working out of your git repo. Your ITP >does not appear to have timed out. If the RFS gets closed, you can just >re-open it. Sorry, wrong TLA; it was actually a notification about this RFS, which still seems live. Regards, David Hart
Bug#832941: RFS: 4pane
Dear David, On Wed, Mar 15, 2017 at 11:37:58AM +, David Hart wrote: > >- Various stanzas do not include the copyright years, yet these are > > available in the files. The Copyright: field is meant to contain the > > copyright claim as it was stated by the upstream author.. > > May I ask which tool you used for that? I've found debmake -kk the best I've > tried, but it doesn't check for dates. > > I've gone through by hand and added all that I found. Of course: licensecheck --copyright -r . > >- Files in .build/ remain, and are not given in d/copyright. > > The remaining ones are my own files. Won't they be covered by '*'? Oh, sorry, I assumed you hadn't written 4pane.m4. Not so many people know m4, as I understand it :) > >- Files: bitmaps/iceweasel.png > > Copyright: Uncertain > > > >Files: bitmaps/kedit.xpm > >Copyright: Unknown > > > >Files: bitmaps/kwrite.xpm > >Copyright: Various > > > >The ftp-masters would be very likely to reject these. Since you found > >the source repos, surely you can find a name for the copyright fields? > > I tried hard, but failed to find definite copyright authors for these and > other bitmaps; I therefore added 'Comment:' fields. In detail: I understand, and appreciate that this is quite a frustrating time sink. > [...] > With the possible exception of kedit, all of these icons are or were included > in > other debian packages, so it would be surprising if there is no solution short > of removal. In general, what currently acceptable ways are there to fill the > Copyright field when an author isn't specified for a particular element of a > package? What we are hitting up against here is a limitation of the DEP-5 copyright format, which can make it seem like listing all authors is more important than establishing that the work is under a free license. Having read the results of your research, I suggest the following approach: - insert all the authorship info you've managed to find thus far -- no reason to throw away that effort -- in the Copyright: field, not Comment:. In the situation where you have a list of project authors but it is unlikely that they all worked on the icon file, just list them all, and put "Comment: These are the authors for the upstream project from which this file was obtained." - for the files where it is not clear, write a copyright string based on the project name. E.g. for kedit.xpm, "(C) 1999 kde-artist team" If this doesn't sound sane, it might be best to ask debian-legal. But I think we could go ahead and upload and see what the ftp-masters think of my proposed solution. > Finally, my ITP has timed-out and the package removed from > mentors. Does this now matter? We don't need mentors since I am working out of your git repo. Your ITP does not appear to have timed out. If the RFS gets closed, you can just re-open it. -- Sean Whitton signature.asc Description: PGP signature
Bug#832941: RFS: 4pane
Dear Sean, >Hopefully a final review (of b74e630): >- your copyright on debian/ is out-of-date -- you need s/2016/2017/ >By the way, you can merge the '*' and 'debian/*' stanzas. Done >- Various stanzas do not include the copyright years, yet these are > available in the files. The Copyright: field is meant to contain the > copyright claim as it was stated by the upstream author.. May I ask which tool you used for that? I've found debmake -kk the best I've tried, but it doesn't check for dates. I've gone through by hand and added all that I found. >- Files in .build/ remain, and are not given in d/copyright. The remaining ones are my own files. Won't they be covered by '*'? >- Makefile.in is still in the tarball, but it's not in the preferred > format for modification, as we've discussed previously. It has to be > removed. I'll do so, but not yet in case I need to remove any of the following too. >- Files: bitmaps/iceweasel.png > Copyright: Uncertain > >Files: bitmaps/kedit.xpm >Copyright: Unknown > >Files: bitmaps/kwrite.xpm >Copyright: Various > >The ftp-masters would be very likely to reject these. Since you found >the source repos, surely you can find a name for the copyright fields? I tried hard, but failed to find definite copyright authors for these and other bitmaps; I therefore added 'Comment:' fields. In detail: iceweasel.png: I'd originally put in the 'Comment' field: "See https://addons.mozilla.org/en-gb/firefox/addon/iceweasel-branding/ which says: "Original copyright 2005-2014, Mike Hommey The artwork is copyright Unicko". I was wrong to suggest CC-BY-SA; I think that is just the license of the add-on page. The iceweasel-branding package has the same icon: https://anonscm.debian.org/cgit/pkg-mozext/iceweasel-branding.git/plain/src/iceweasel/iceweasel_icon.svg. That package's d/copyright (http://metadata.ftp-master.debian.org/changelogs/main/f/firefox-branding-iceweasel/firefox-branding-iceweasel_0.4.0_copyright) doesn't specify a separate license for the .svg icon. Globally it says: "src/iceweasel/* Copyright: 2005-2014, Mike Hommey 1998-2010, Mozilla Project 2016 Desktopd Project License: MPL-2.0" so I've changed it to that, minus the 2016 entry as I copied the icon in 2008. kedit.xpm and kwrite.xpm. I added these icons in 2003 or 4, probably from SuSE 8.2 which I was using at the time. According to https://github.com/KDE/kde1-kdeutils/commit/fe8e268ff0d795017227f40b6137006a6cbc2e09 these icons were amoung those added to kdeutils in 1999 by Torsten Rahn with the comment "Painted by the kde-artist team". No copyright is mentioned there. Though grepping the package shows that some of its constituents, e.g. konsole, have separate licence files, neither kedit nor kwrite do. kdeutils itself has a GPL-2 'COPYING' file. It also has a debian; d/copyright says "Copyright: All programs are either under the GPL or the Artistic License (namely kpanel, kwm, konsole, kstart)". I can find no further information about kedit.xpm. If you feel that's sufficient to specify GPL-2, copyright Torsten Rahn 1999, I'll do so. Otherwise I don't know what is correct. Should I remove this icon from the package? kwrite is still maintained, associated with kate. http://metadata.ftp-master.debian.org/changelogs/main/k/kate/kate_4.8.4-1_copyright, dated 2012, says about kwrite itself: kwrite/ Copyright: © 2010 Dominik Haumann Copyright: © 2001 Christoph Cullmann Copyright: © 2001 Joseph Wenninger Copyright: © 2001 Anders Lund License for all components unless stated otherwise: GNU Library General Public License, version 2 (LGPL-2) Again I'm happy to use that specific attribution if you consider it will apply to the xpm too. I also put 'various' for mate-text-editor.png, gedit.xpm and evince.xpm, for similar reasons. mate-text-editor.png: https://github.com/perberos/mate-text-editor/blob/master/AUTHORS gives 10 names but doesn't mention the icon specifically. gedit.xpm: For gedit itself http://metadata.ftp-master.debian.org/changelogs/main/g/gedit/gedit_3.22.0-2_copyright lists 30 copyright owners, with various dates. There is no mention of the icon's creator or specific copyright. evince.xpm: http://metadata.ftp-master.debian.org/changelogs/main/e/evince/evince_2.30.3-2+squeeze1_copyright mentioned 9 authors in 2005. Cloning git.gnome.org/evince makes it clear that evince itself is GPL-2 but doesn't mention the icon's author or separate copyright. bitmaps/include/chardevice.xpm bitmaps/include/blockdevice.xpm: These are in kde1-kdebase. https://github.com/KDE/kde1-kdebase/blob/master/COPYING confirms the licence is GPL-2. https://github.com/KDE/kde1-kdebase/blob/master/AUTHORS says: "Look in the subdirs to get info about the authors. The package is maintained by Stephan Kulow " However the xpms aren't in a particular app's subdir, they're in pics/ together with many others and have no separate copyright or author files. With the possible exception of kedit, all of these icons are or were
Bug#832941: RFS: 4pane
Dear David, Hopefully a final review (of b74e630): - you forgot `dch -r` - your copyright on debian/ is out-of-date -- you need s/2016/2017/ By the way, you can merge the '*' and 'debian/*' stanzas. - Files: bitmaps/iceweasel.png Copyright: Uncertain Files: bitmaps/kedit.xpm Copyright: Unknown Files: bitmaps/kwrite.xpm Copyright: Various The ftp-masters would be very likely to reject these. Since you found the source repos, surely you can find a name for the copyright fields? - The shortname "CC-BY-SA" should probably be suffixed with the license version. - Makefile.in is still in the tarball, but it's not in the preferred format for modification, as we've discussed previously. It has to be removed. - Various stanzas do not include the copyright years, yet these are available in the files. The Copyright: field is meant to contain the copyright claim as it was stated by the upstream author.. - Files in .build/ remain, and are not given in d/copyright. -- Sean Whitton signature.asc Description: PGP signature
Bug#832941: RFS: 4pane
Dear Sean, >Unfortunately, your watch file still isn't working: > >hephaestus ~/rfs/4pane-debian-dir % uscan --download-current-version >uscan warn: In debian/watch no matching hrefs for version 4.0 in watch line > http://www.4Pane.co.uk/4pane-(.*)\.tar\.gz Ah, I wasn't testing with --download-current-version. I've uploaded a fix, and that option does now works here. Regards, David Hart
Bug#832941: RFS: 4pane
Dear David, Unfortunately, your watch file still isn't working: hephaestus ~/rfs/4pane-debian-dir % uscan --download-current-version uscan warn: In debian/watch no matching hrefs for version 4.0 in watch line http://www.4Pane.co.uk/4pane-(.*)\.tar\.gz Remember that by default, uscan looks for tags matching the URI pattern. I'm not an expert on uscan but I think you should be able to get it to substitute the version and just download that. -- Sean Whitton signature.asc Description: PGP signature
Bug#832941: RFS: 4pane
Dear Sean, >> I've uploaded a +dfsg tarball to the 4Pane website and altered d/watch to >> download it. uscan and lintian seem happy, so hopefully I've done this >> correctly. > >This won't work because your changelog still has 4.0-1 as the version >number.. >While we're at it, why do you have an additional .1 suffix to the dfsg >version number? It's certainly not a deal-breaker, but it's hardcoded >into the watch file, which could be annoying in the future. That was my misunderstanding of the DebianMentorsFaq dfsg section. I've corrected it now. I've added +dfsg to the changelog and adjusted watch to cope. I hope I got it right this time. Regards, David Hart
Bug#832941: RFS: 4pane
Dear David, On Wed, Mar 08, 2017 at 09:10:26PM +, David Hart wrote: > I've uploaded a +dfsg tarball to the 4Pane website and altered d/watch to > download it. uscan and lintian seem happy, so hopefully I've done this > correctly. This won't work because your changelog still has 4.0-1 as the version number.. While we're at it, why do you have an additional .1 suffix to the dfsg version number? It's certainly not a deal-breaker, but it's hardcoded into the watch file, which could be annoying in the future. -- Sean Whitton signature.asc Description: PGP signature
Bug#832941: RFS: 4pane
Dear Sean, >I've just reviewed revision 5e12184 of your packaging repository, and >compared it against the points of my previous review. I'm happy to see >that almost everything was handled. I also built and installed the >package and tried out 4Pane. > >There are two remaining issues. > >1) You need to run `dch -r` so that the timestamp in the changelog is >after all the changes you have made. You have modified this package >since December! Try to get into the habit of committing a `dch -r` >change before each upload/review. Sorry, I'll try to remember. >2) Your ChangeToAutomakeBuild.patch does not actually resolve the DFSG >issues because the files are still present in the upstream tarball, >which can't be distributed by the Debian mirrors. A copy of those files >is also present in the .patch file... > >The usual solution is to repack the upstream tarball to remove the >files, and append '+dfsg' to the upstream version. Since you are the >upstream author, you could just make a 4.1 release of 4pane not >containing those files. Whichever one would be more convenient for you. I see. That not only makes sense, but is also more elegant than patching. As well as bakefile-related files, I've also removed several bitmaps of unknown licence as presumably the above paragraphs would apply to them too. I've uploaded a +dfsg tarball to the 4Pane website and altered d/watch to download it. uscan and lintian seem happy, so hopefully I've done this correctly. Regards, David Hart
Bug#832941: RFS: 4pane
Dear David, Thank you for your updated package! I've just reviewed revision 5e12184 of your packaging repository, and compared it against the points of my previous review. I'm happy to see that almost everything was handled. I also built and installed the package and tried out 4Pane. There are two remaining issues. 1) You need to run `dch -r` so that the timestamp in the changelog is after all the changes you have made. You have modified this package since December! Try to get into the habit of committing a `dch -r` change before each upload/review. 2) Your ChangeToAutomakeBuild.patch does not actually resolve the DFSG issues because the files are still present in the upstream tarball, which can't be distributed by the Debian mirrors. A copy of those files is also present in the .patch file... The usual solution is to repack the upstream tarball to remove the files, and append '+dfsg' to the upstream version. Since you are the upstream author, you could just make a 4.1 release of 4pane not containing those files. Whichever one would be more convenient for you. I still need to do a full d/copyright review before I upload, but I'd prefer not to do that until the tarball has been repacked. -- Sean Whitton signature.asc Description: PGP signature
Bug#832941: RFS: 4pane
Dear Sean, I'd not lost interest, just slowed down during the stretch freeze. I've now uploaded an altered d/ >> 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... >> 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. I did create a Bakefile package but found that Bakefile segfaults with the stretch version of python. Though by coincidence a fix was mentioned elsewhere a few days later so it could be made to work, I was sufficiently discouraged that future 4Pane releases will probably switch to automake. I've therefore removed all Bakefile traces from the source repo and substituted an automake build system. This autoreconfs and builds successfully. I hope you will be happy with this alternative, but if not I'll fix the potential Bakefile package. >>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. Regards, David Hart
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
Bug#832941: RFS: 4pane
Dear David, On Wed, Nov 09, 2016 at 05:17:29PM +, David Hart wrote: > Dear Sean, > > Thank you for your comments. > > >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. 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. Also, the Vcs-* fields still point to the upstream source, not the packaging repository. -- Sean Whitton signature.asc Description: PGP signature
Bug#832941: RFS: 4pane
Dear Sean, Thank you for your comments. >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. >> >12. Please consider using dh_autoreconf to ensure that the package's >> >build system can be reproduced from the source code provided >> If I understand dh_autoreconf correctly, it can't: a fresh autoconf call will >> fail as the package doesn't include various non-standard .m4 macros and such. >> That could be fixed by a largish patch, but I'll leave it to a sponsor to >> decide. > >In that case, this is now a "must-fix". The build system is part of the >source package, so the source code for that build system must be >included, to satisfy DFSG. You need to include those macros (or switch >to use standard ones). I've done so, and autoreconf now runs successfully as part of the build process. >On Fri, Sep 30, 2016 at 03:40:33PM +0100, David Hart wrote: >> >2. Why doesn't 4pane work on archs other than i386, amd64, hurd-i386? >> I didn't think it would. However after discussion on debian-mentors I've now >> shown it works on armel, and it builds on kfreebsd-amd64 but immediately >> hangs in a forkpty call; I'll try to debug that when I have time. I expect >> some or all of the other archs will also build. If/when 4pane attracts a >> sponsor I'll try them. > >Debian packages need to work on all our release architectures unless >there is some fundamental fact about the package that prevents it >(e.g. a tool for analysing machine code on a particular arch). Note >that kfreebsd-amd64 is not a release architecture anymore. I've now worked around the kfreebsd hang (unfortunately Adam Borowski's fix didn't work for me). A comment today on debian-mentors suggested that claiming 'Architecture: any' was reasonable even if the remaining ports have not yet been tested... I've also added doc-base support. These changes are uploaded to https://github.com/dghart/4pane-debian-dir Regards, David Hart
Bug#832941: RFS: 4pane (debian: message 7 of 20)
On Sat, Oct 08, 2016 at 09:37:48AM -0700, Sean Whitton wrote: > On Fri, Sep 30, 2016 at 03:40:33PM +0100, David Hart wrote: > > >2. Why doesn't 4pane work on archs other than i386, amd64, hurd-i386? > > I didn't think it would. However after discussion on debian-mentors I've now > > shown it works on armel, and it builds on kfreebsd-amd64 but immediately > > hangs > > in a forkpty call; I'll try to debug that when I have time. I expect some or > > all of the other archs will also build. If/when 4pane attracts a sponsor > > I'll > > try them. I haven't looked at all at 4pane, but it might be a case of grantpt()/forkpty() failing to work if you have a handler for SIGCHLD: https://github.com/kilobyte/kbtin/commit/f915c121a19c00bd52dd7e159778806e8dba0979 (the commit message says freebsd kernel 9.x, but that's as in "as opposed to 8.x". And it's glibc only, real FreeBSD works ok.). (My fix has an obvious race condition, you need another wait after restoring the signal.) > Debian packages need to work on all our release architectures unless > there is some fundamental fact about the package that prevents it > (e.g. a tool for analysing machine code on a particular arch). Sadly that's not true, packages are allowed to skip any architectures for any reason or no reason at all. The only case it's an issue is when the architecture worked before (to be exact: it has a version in testing) and you haven't yet filed a RM. Being allowed and it being the right thing to do are different things, though, and I'd urge you to port to all architectures if possible. > Note that kfreebsd-amd64 is not a release architecture anymore. On one hand, this means less reasons to make it work, but on the other, the porters are swamped with extra effort and could use any help you can do. Making your package work there is always nice (and, unlike exotic archs, you can trivially set up kfreebsd in a virtual machine or on a spare partition at native speed). Meow! -- A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month. Filter out and throw away the fruits (can dump them into a cake, etc), let the drink age at least 3-6 months.
Bug#832941: RFS: 4pane (debian: message 7 of 20)
Dear David, A few comments on your reply. On Fri, Sep 30, 2016 at 03:40:33PM +0100, David Hart wrote: > >2. Why doesn't 4pane work on archs other than i386, amd64, hurd-i386? > I didn't think it would. However after discussion on debian-mentors I've now > shown it works on armel, and it builds on kfreebsd-amd64 but immediately hangs > in a forkpty call; I'll try to debug that when I have time. I expect some or > all of the other archs will also build. If/when 4pane attracts a sponsor I'll > try them. Debian packages need to work on all our release architectures unless there is some fundamental fact about the package that prevents it (e.g. a tool for analysing machine code on a particular arch). Note that kfreebsd-amd64 is not a release architecture anymore. > >4 I think that it would be clearer to express the wxWindows license as a > >dual-license: "GPL-2+ or wxWindows", with separate license paragraphs for > >each > >of those. > I'm not sure I understand. wxWidgets isn't dual-licensed, it uses just the > wxWindows license which, though similar to GPL-2, is different. I might be missing something, but the text of the license says: - you can use the library under the GPL-2 or later - you can use the library under wxWindows License 3.1 or later - if you add other GPL code to the library you can no longer distribute under the wxWindows License - if you make modifications you can continue the dual-licensing or not The 3rd and 4th points follow from the 1st and 2nd, so all the license is actually saying is the 1st and 2nd, i.e., a dual license under GPL-2+ and wxWindows-3.1+. > > Of your suggestions, 2, 3, 5, and 7-9 are now implemented. Of the > others that need a comment: > > >1 I'd be very grateful if you'd put this source package in a git repository. > I presume you mean just the contents of debian/. I've done this: > https://github.com/dghart/4pane-debian-dir I'd recommend including the upstream code in the git repository, too. But what you've done is fine -- thanks! > >6. Can Vcs-Git: use a secure protocol? https:// rather than git://. > I don't think so, not without the user logging in to sourceforge. Fair enough. > >11. I'm not familiar with wxWidgets practices, but is it unavoidable to > >include sections of code from the wxWidgets sources... > It's not at all normal, but I have to do it in two places: > First, originally the main display widget was effectively unsubclassable and > even now it would be very hard. I hope to replace the control with one new in > wx3.0 when I no longer support wx2.8. Second, wxWidgets' inotify wrapper is > new > in wx3.0; I've copied some of the code for use in earlier versions. Sounds reasonable, though, I'm not a C++ programmer. Hopefully someone else on d-mentors will comment. > >12. Please consider using dh_autoreconf to ensure that the package's > >build system can be reproduced from the source code provided > If I understand dh_autoreconf correctly, it can't: a fresh autoconf call will > fail as the package doesn't include various non-standard .m4 macros and such. > That could be fixed by a largish patch, but I'll leave it to a sponsor to > decide. In that case, this is now a "must-fix". The build system is part of the source package, so the source code for that build system must be included, to satisfy DFSG. You need to include those macros (or switch to use standard ones). It is not required to run dh_autoreconf: it is sufficient to include everything that would be needed to reconfigure. However, it is strongly recommended that you actually reconf, because it proves that all the required source code is actually present. Further, running dh_autoreconf can uncover bugs in the build system. -- Sean Whitton signature.asc Description: PGP signature
Bug#832941: RFS: 4pane (debian: message 7 of 20)
Dear Sean, Many thanks for taking the time to write such a detailed review. Of the must-fixes: >1. The changelog should contain exactly one entry, closing the ITP. Ah, that not only makes sense but is easier. Done. >2. Why doesn't 4pane work on archs other than i386, amd64, hurd-i386? I didn't think it would. However after discussion on debian-mentors I've now shown it works on armel, and it builds on kfreebsd-amd64 but immediately hangs in a forkpty call; I'll try to debug that when I have time. I expect some or all of the other archs will also build. If/when 4pane attracts a sponsor I'll try them. >3 The Vcs-* fields should point to a repo/branch containing the source >package, not the upstream master branch. That also makes sense. Done. >4 I think that it would be clearer to express the wxWindows license as a >dual-license: "GPL-2+ or wxWindows", with separate license paragraphs for each >of those. I'm not sure I understand. wxWidgets isn't dual-licensed, it uses just the wxWindows license which, though similar to GPL-2, is different. Of your suggestions, 2, 3, 5, and 7-9 are now implemented. Of the others that need a comment: >1 I'd be very grateful if you'd put this source package in a git repository. I presume you mean just the contents of debian/. I've done this: https://github.com/dghart/4pane-debian-dir >4.Why is there an additional copy of the manpage in the debian/ subdir? That was a quick-fix for a 4[Pp]ane issue. I've now removed it and instead use a link. >6. Can Vcs-Git: use a secure protocol? https:// rather than git://. I don't think so, not without the user logging in to sourceforge. >10. You're inconsistent about 4pane versus 4Pane... The original name was 4Pane, and outside debian it still is. I don't mind changing things while packaging but it risks breakages, so I'll ask my future sponsor how best to do this. >11. I'm not familiar with wxWidgets practices, but is it unavoidable to >include sections of code from the wxWidgets sources... It's not at all normal, but I have to do it in two places: First, originally the main display widget was effectively unsubclassable and even now it would be very hard. I hope to replace the control with one new in wx3.0 when I no longer support wx2.8. Second, wxWidgets' inotify wrapper is new in wx3.0; I've copied some of the code for use in earlier versions. >12. Please consider using dh_autoreconf to ensure that the package's build >system can be reproduced from the source code provided If I understand dh_autoreconf correctly, it can't: a fresh autoconf call will fail as the package doesn't include various non-standard .m4 macros and such. That could be fixed by a largish patch, but I'll leave it to a sponsor to decide. Again, thank you for your time and effort. Regards, David Hart >Dear David, > >I've split it into two sections: things that I would consider must-fixes >before an upload to Debian, and suggested improvements. The latter >aren't strictly necessary, but they would help demonstrate to a >potential sponsor that you are committed to maintaining this package in >Debian. > >Must-fixes/clarifications: > >1. The changelog should contain exactly one entry, closing the ITP. The >current changelog suggests that 4pane has already been uploaded to >Debian. > >2. Why doesn't 4pane work on archs other than i386, amd64, hurd-i386? >(an eclectic list!) > >3. The Vcs-* fields should point to a repo/branch containing the source >package, not the upstream master branch. > >4. I think that it would be clearer to express the wxWindows license as >a dual-license: "GPL-2+ or wxWindows", with separate license paragraphs >for each of those. > >Suggestions: > >1. I'd be very grateful if you'd put this source package in a git >repository. That way, I can use `git diff` to review changes that >you've made in response to my comments. > >2. At least PACKAGERS, README are missing a trailing newline. > >3. The "but may be used by others" line in the manpage doesn't make much >sense. Normally this is used to indicate that a manpage written by a >Debian contributor is used in a Debian derivative, but of course any >copy of a manpage written by *upstream* gets used by others. > >4. Why is there an additional copy of the manpage in the debian/ subdir? > >5. "As well as standard file manager things" I would suggest >s/things/functionality/. Also, the scare quotes around 'terminal >emulator', 'grep' etc. aren't needed and could be confusing. > >6. Can Vcs-Git: use a secure protocol? https:// rather than git://. > >7. The debian/* paragraph in d/copyright is redundant. > >8. The Debian menu system is deprecated. You seem to be installing a >FreeDesktop.org desktop file into /usr/share/4Pane/rc. Please install >that as a desktop file that will be picked up by desktop environments -- >see Debian Policy 9.6. > >9. I think the html docs should go in /usr/share/doc/4pane/html. Then >someone just looking for the changelog, README etc. need not hunt >thr
Bug#832941: RFS: 4pane
control: tag -1 +moreinfo control: owner -1 ! Dear David, Thank you for your work to bring this new package to Debian! I can't sponsor the upload, but I hope this review is useful to you. I've split it into two sections: things that I would consider must-fixes before an upload to Debian, and suggested improvements. The latter aren't strictly necessary, but they would help demonstrate to a potential sponsor that you are committed to maintaining this package in Debian. Must-fixes/clarifications: 1. The changelog should contain exactly one entry, closing the ITP. The current changelog suggests that 4pane has already been uploaded to Debian. 2. Why doesn't 4pane work on archs other than i386, amd64, hurd-i386? (an eclectic list!) 3. The Vcs-* fields should point to a repo/branch containing the source package, not the upstream master branch. 4. I think that it would be clearer to express the wxWindows license as a dual-license: "GPL-2+ or wxWindows", with separate license paragraphs for each of those. Suggestions: 1. I'd be very grateful if you'd put this source package in a git repository. That way, I can use `git diff` to review changes that you've made in response to my comments. 2. At least PACKAGERS, README are missing a trailing newline. 3. The "but may be used by others" line in the manpage doesn't make much sense. Normally this is used to indicate that a manpage written by a Debian contributor is used in a Debian derivative, but of course any copy of a manpage written by *upstream* gets used by others. 4. Why is there an additional copy of the manpage in the debian/ subdir? 5. "As well as standard file manager things" I would suggest s/things/functionality/. Also, the scare quotes around 'terminal emulator', 'grep' etc. aren't needed and could be confusing. 6. Can Vcs-Git: use a secure protocol? https:// rather than git://. 7. The debian/* paragraph in d/copyright is redundant. 8. The Debian menu system is deprecated. You seem to be installing a FreeDesktop.org desktop file into /usr/share/4Pane/rc. Please install that as a desktop file that will be picked up by desktop environments -- see Debian Policy 9.6. 9. I think the html docs should go in /usr/share/doc/4pane/html. Then someone just looking for the changelog, README etc. need not hunt through the html files. 10. You're inconsistent about 4pane versus 4Pane. For example, you use /usr/share/4Pane but /usr/share/doc/4pane (with 4Pane as a symlink). Since the package is 4pane, you should use '4pane' in all directories the package uses (the compatibility symlinks from 4Pane to 4pane are fine). 11. I'm not familiar with wxWidgets practices, but is it unavoidable to include sections of code from the wxWidgets sources, as you describe in LICENSE? Is it not possible to call library functions instead? Since you link against libwxgtk I assume that it isn't possible to replace the copied code with library calls, but I'd appreciate it if you could confirm that. 12. Please consider using dh_autoreconf to ensure that the package's build system can be reproduced from the source code provided I haven't tried installing and running the package yet, but hopefully the above is enough to be going on with. -- Sean Whitton signature.asc Description: PGP signature
Bug#832941: RFS: 4pane [ITP] (updated package)
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "4pane" * Package name: 4pane Version : 4.0-1 Upstream Author : David Hart * URL : http://4Pane.co.uk * License : GPL3 Section : x11 It builds those binary packages: 4pane - four-pane detailed-list file manager To access further information about this package, please visit the following URL: http://mentors.debian.net/package/4pane Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/4/4pane/4pane_4.0-1.dsc More information about 4Pane can be obtained from http://4Pane.co.uk. 4Pane is a multi-pane, detailed-list file manager. Though anyone can use it, it is aimed more at the expert than the average user, with extra features such as multiple undo and redo, multiple renaming and user-defined tools. Since the initial release in 2008, 4Pane has been taken up by a few distros, most notably Arch and PCLinuxOS, and it's now in openMandriva's 'cooker'. I have been creating on-site packages since 2008, so I do have some packaging experience. Apart from a necessary override, the uploaded package is lintian-clean. This is an update for the 4.0 release of 4Pane. Since my #764520 RFS I'm pleased to report that 4Pane has been taken up by Fedora and is in openSUSE tumbleweed. So, of the major distros the only ones missing are those based on debian... Regards, David Hart
