Bug#1030599: RFS: codelite/17.0.0+dfsg-1 [QA] -- Powerful and lightweight IDE
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for the package "codelite" * Package name: codelite Version : 17.0+dfsg-1 Upstream Author : Eran Ifrah * URL : https://codelite.org * License : GPL2+ * Vcs : https://salsa.debian.org/debian/codelite (previous codelite version) https://github.com/dghart/debian-salsa-codelite-clone (current version) Section : devel It builds those binary packages: codelite - Powerful and lightweight IDE codelite-plugins - Powerful and lightweight IDE - plugins To access further information about this package, please visit the following URL: https://mentors.debian.net/package/codelite Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/c/codelite/codelite_17.0+dfsg-1.dsc Changes since the last upload: * QA upload. * New upstream release. * debian/control: - Bump standards to 4.6.2. * debian/copyright: - Update copyright date - Add copyright for new module * debian/patches: - Refresh patches. - Drop 1 patch applied upstream. - Merge 2 patches. * debian/codelite-plugins.links: - Remove 2 unneeded entries, and the now-empty file. * debian/rules: - Added -gdwarf-4 to cflags and cxxflags as dwz cannot cope with DWARFv5. - Remove no longer needed dh_install entries. * Update lintian overrides. * Update d/codelite.install and codelite-plugins.install. * Change the upstream tarball url. This is an update to the latest upstream version, codelite 17.0.0. The amended package builds and works, and has no significant lintian issues. Please note that I don't have access to salsa, so that does not contain the new version. Instead there is a clone at https://github.com/dghart/debian-salsa-codelite-clone Regards, David Hart
Bug#981982: RFS: codelite/15.0+dfsg-1 [QA] -- Powerful and lightweight IDE
Hi Tobi, Many thanks for your review. >(Note: Due to the freeze, an upload to unstable is currently out of scope. You >might either want to wait for bullseye's release or target experimental for >now) I know. The new release and RFS preceded the freeze, but didn't attract a sponsor in time. I'll wait for bullseye. >Thanks for the updated package… >Some questions though: >- d/control: > - I see in the diff >- that you start Depend: on clangd and clang-format. >Is codelite _really_ depending as in Policy-Depends on it? It's long enough ago that I can't remember, but I'll check. > (there are some *arch-dependent* Build-Depends on clang stugg that seems to >be in contradiction… as the Depends are not arch-depenent this does not fit >somehow…) >- note this change is not documented in d/changelog, thats why I had to > guess: PLEASE document the _whys_ of your changes to help the sponsor out > until they improve in reading your mind… ;-) Sorry, that was an oversight. >nitpick: > - d/copyright does not need all those extra blank lines :) > >PS: You know the package is orphaned :) Could we talk you into adopting it? >(Its okay if you decline, but TIA for considering!) I know, and 40 or 50 years ago I'd have jumped at the chance. But codelite really deserves a long term maintainer, and that excludes me. >Tagging moreinfo because of the questions above (clang and freeze) >Remove the tag when you think the package is ready for a second review… Will do. Thanks again. Regards, David
Bug#981982: RFS: codelite/15.0+dfsg-1 [QA] -- Powerful and lightweight IDE
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for the package "codelite" * Package name: codelite Version : 15.0+dfsg-1 Upstream Author : Eran Ifrah * URL : https://codelite.org * License : CodeLite * Vcs : https://salsa.debian.org/debian/codelite (previous codelite version) https://github.com/dghart/debian-salsa-codelite-clone (current version) Section : devel It builds those binary packages: codelite - Powerful and lightweight IDE codelite-plugins - Powerful and lightweight IDE - plugins To access further information about this package, please visit the following URL: https://mentors.debian.net/package/codelite Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/c/codelite/codelite_15.0+dfsg-1.dsc Changes since the last upload: * QA upload. . * New upstream release. . * d/patches: - Refresh patches. - Drop 3 patches applied upstream. . * d/control: - Bump standards to 4.5.1. . * d/source/lintian-overrides: - Remove override for the defunct testsuite-autopkgtest-missing. . * d/codelite-plugins.lintian-overrides: - Remove 2 no-longer-needed overrides. . * d/copyright: - Add a new entry, tools, to Files-Excluded. . * d/not-installed: - Add this to cope with the bump from debhelper-compat to 13, which fails - builds that contain uninstalled files instead of just warning about them . * d/watch: - Bump version to 4.0 . * d/upstream/metadata: - Add Repository and Repository-Browse fields - Add Bug-Database and Bug-Submit fields This is an update to the latest upstream version, codelite 15.0. The amended package builds and works, and has no significant lintian issues. Please note that I don't have access to salsa, so that does not contain the new version. Instead there is a clone at https://github.com/dghart/debian-salsa-codelite-clone Regards, David Hart
Bug#953773: RFS: codelite/14.0+dfsg-1 [QA] -- Powerful and lightweight IDE
>On Sat, Mar 14, 2020 at 11:47:53AM +0000, David Hart wrote: >> >It seems to be a result of gcc upgrading to 9.3.0, and has now been reported >> >> The gcc package has been fixed and codelite builds again here. Also, the >> Mentors upload now contains the qt4-qmake -> qt5-qmake fix. > >Thanks. > >There's another problem: the changelog mangles and removes some previous >uploads. The diff is: >//snip >Versions up to 13 shouldn't get changed, other than to fix errors. Indeed, it wasn't intentional. I hadn't noticed that the salsa d/changelog had been altered as part of the 13.0 upload, and failed to update the changelog in the github clone. Now fixed there, and I've updated the package in mentors.
Bug#953773: RFS: codelite/14.0+dfsg-1 [QA] -- Powerful and lightweight IDE
>It seems to be a result of gcc upgrading to 9.3.0, and has now been reported >elsewhere: e.g. #953806 and #953796. There's also an explanation (that's well >outside my comfort zone) at >https://bugs.launchpad.net/ubuntu/+source/chrony/+bug/1867316 . > >IIUC this needs to be fixed in gcc, and there's nothing that can be done at >codelite level. The gcc package has been fixed and codelite builds again here. Also, the Mentors upload now contains the qt4-qmake -> qt5-qmake fix. Regards, David
Bug#953773: RFS: codelite/14.0+dfsg-1 [QA] -- Powerful and lightweight IDE
Hi,
>On Fri, Mar 13, 2020 at 11:19:46AM +0000, David Hart wrote:
>> * Package name: codelite
>>Version : 14.0+dfsg-1
>> ...
>> This is an update to the latest upstream version, codelite 14.0.
>> The amended package builds and works, and has no significant lintian issues.
>
>Hi!
>I'm afraid it doesn't build on current unstable: there's this bug repeated
>in eleventy zillion places:
>
>/usr/include/wx-3.0/wx/datetime.h:462:40: error: ‘INT_MIN’ was not declared in
>this scope
> 462 | wxDateTime() { m_time = wxLongLong(wxINT32_MIN, 0); }
> |^~~
>/usr/include/wx-3.0/wx/datetime.h:462:40: note: ‘INT_MIN’ is defined in header
>‘’; did you forget to ‘#include ’?
Argh!, yes. I now get that too after a dist-upgrade, and in a new sbuild (I
don't think my previous one was updating properly). However it also happens when
trying to build the current codelite 13.0 package.
It seems to be a result of gcc upgrading to 9.3.0, and has now been reported
elsewhere: e.g. #953806 and #953796. There's also an explanation (that's well
outside my comfort zone) at
https://bugs.launchpad.net/ubuntu/+source/chrony/+bug/1867316 .
IIUC this needs to be fixed in gcc, and there's nothing that can be done at
codelite level.
Thank you for your input.
Regards,
David
Bug#953773: RFS: codelite/14.0+dfsg-1 [QA] -- Powerful and lightweight IDE
Hi, >David Hart kirjoitti 13.3.2020 klo 13.19: >> Changes since the last upload: >> >>* QA upload. >> . >>* New upstream release. >> - Remove the .py extension from a script with language-extension >> . >>* d/patches: >> - Refresh patches. >> - Drop 2 patches applied upstream. >> - Make a helper script python3-compatible. >> . >>* debian/control: >> - Bump standards to 4.5.0. >> . >>* debian/lintian-overrides: >> - Add override for file-references-package-build-path false positive. >> >> This is an update to the latest upstream version, codelite 14.0. >> The amended package builds and works, and has no significant lintian issues. > >Hi! > >The codelite-plugins package recommends qt4-qmake which has been removed from >Debian already. Can the recommendation be upgraded to qt5-qmake? Thank you for letting me know. I've done so in the git repo, and I'll create an updated package when building is possible again. Regards, David
Bug#953773: RFS: codelite/14.0+dfsg-1 [QA] -- Powerful and lightweight IDE
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for the package "codelite" * Package name: codelite Version : 14.0+dfsg-1 Upstream Author : Eran Ifrah * URL : https://codelite.org * License : CodeLite * Vcs : https://salsa.debian.org/debian/codelite (previous codelite version) https://github.com/dghart/debian-salsa-codelite-clone (current version) Section : devel It builds those binary packages: codelite - Powerful and lightweight IDE codelite-plugins - Powerful and lightweight IDE - plugins To access further information about this package, please visit the following URL: https://mentors.debian.net/package/codelite Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/c/codelite/codelite_14.0+dfsg-1.dsc Changes since the last upload: * QA upload. . * New upstream release. - Remove the .py extension from a script with language-extension . * d/patches: - Refresh patches. - Drop 2 patches applied upstream. - Make a helper script python3-compatible. . * debian/control: - Bump standards to 4.5.0. . * debian/lintian-overrides: - Add override for file-references-package-build-path false positive. This is an update to the latest upstream version, codelite 14.0. The amended package builds and works, and has no significant lintian issues. Please note that I don't have access to salsa, so that does not contain the new version. Instead there is a clone at https://github.com/dghart/debian-salsa-codelite-clone Regards, David Hart
Bug#921373: RFS: codelite [QA] -- Powerful and lightweight IDE
>05:11:40PM +0000, David Hart wrote: >> * Package name: codelite >> Version : 12.0+dfsg-1 > >> Changes since the last upload: >> >> codelite (12.0+dfsg-1) unstable; urgency=medium >> >> * QA upload. >> >> * New upstream release. >> >> * debian/codelite-plugins.install: >> - Install new plugins. >> * debian/copyright: >> - Add copyright for new plugin. >> - Update copyright dates. >> * debian/patches: >> - Refresh patches. >> - Backport a fix for LLDB terminal crashes. >> - Fix 3 more spelling mistakes. >> * debian/control: >> - Bump standards to 4.3.0. >> * debian/compat: >> - Use debhelper 11. >> * debian/watch: >> - Add oversionmangle for +dfsg > >Your upload would remove the last changelog entry, could you please fix >that? Otherwise, I see no problems so far. > >The issue with VCS would be nice to solve but is not a showstopper. Thank you for noticing! It must have been added after I git-cloned. Now fixed and the upload refreshed. Regards, David Hart
Bug#921373: RFS: codelite [QA] -- Powerful and lightweight IDE
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for an update of the orphaned package "codelite" * Package name: codelite Version : 12.0+dfsg-1 Upstream Author : eranif * URL : https://codelite.org * License : GPL2+ Section : devel It builds these binary packages: codelite -- Powerful and lightweight IDE codelite-plugins -- Powerful and lightweight IDE - plugins To access further information about this package, please visit the following URL: https://mentors.debian.net/package/codelite Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/c/codelite/codelite_12.0+dfsg-1.dsc There is also a git repo: https://github.com/dghart/debian-salsa-codelite-clone which is a clone of https://salsa.debian.org/debian/codelite to which afaict I can't upload. After being RFA for some time, codelite is now orphaned: see #852312. It still provides version 10.0, while the upstream version is 12.0. I've updated the package to 12.0 and made other minor fixes. This is a request for a review and upload of the update. The amended package builds and works, and is lintian-clean apart from the warning: orphaned-package-not-maintained-in-debian-infrastructure. Changes since the last upload: codelite (12.0+dfsg-1) unstable; urgency=medium * QA upload. * New upstream release. * debian/codelite-plugins.install: - Install new plugins. * debian/copyright: - Add copyright for new plugin. - Update copyright dates. * debian/patches: - Refresh patches. - Backport a fix for LLDB terminal crashes. - Fix 3 more spelling mistakes. * debian/control: - Bump standards to 4.3.0. * debian/compat: - Use debhelper 11. * debian/watch: - Add oversionmangle for +dfsg Regards, David Hart
Bug#910966: RFS: 4pane/5.0-2
Hi Herbert, >My final comments so I can upload the package: >The history of debian/changelog is been changed. Please, >keep the history. >+4pane (5.0-1) testing; urgency=medium > > * New upstream version. > All the previous patches are now redundant and a dfsg tarball is > no longer needed. >- * Bump std-version to 4.0.0, no changes needed >- * Update copyright file. >- * Add dependency on gettext, msgfmt is used by upstream build system >- * Update watch file Ah. The 5.0-1 sponsor expanded my changelog entry, and I'd not updated that here. Now fixed. Thank you for noticing it. > - debian/rules does not need these two lines: >-DPKG_EXPORT_BUILDFLAGS = 1 >-include /usr/share/dpkg/buildflags.mk Also fixed. Many thanks in advance for sponsoring! Regards, David Hart
Bug#910966: RFS: 4pane/5.0-2
Hi Herbert, >debian/changelog > - is "UNRELEASED". > - a comment: I never saw a changelog going to 'testing'. Like > version 5.0-1. It is in Sid anyway. But there are less 4 lines > in that part of the file I wasn't sure what was right for that field. I've now changed it to 'unstable'. >debian/copyright > - does not have a 'Files: debian/*". I never saw that either. I don't think it's needed. As I'm both the packager and upstream, IIUC the contents of a 'Files: debian/*' entry would just duplicate the overriding 'Files: *'. Please correct me if I'm mistaken. Thank you for taking the time to comment. Regards, David Hart
Bug#910966: RFS: 4pane
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for an update of my package "4pane" * Package name: 4pane Version : 5.0-2 Upstream Author : David Hart * URL : https://4Pane.co.uk * License : GPL3 Section : x11 It builds these binary packages: 4pane - four-pane detailed-list file manager To access further information about this package, please visit the following URL: https://mentors.debian.net/package/4pane Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/4/4pane/4pane_5.0-2.dsc There is also a git repo: https://github.com/dghart/4pane-debian-dir The upload mostly changes to the latest debhelper and policy versions, with consequent lintian fixes. However it also switches 4pane to use the GTK3 flavour of wxwidgets3.0: see #894663. This is a request for a review and upload of the update. The amended package builds and works, and is lintian-clean. Changes since the last upload: 4pane (5.0-2) unstable; urgency=medium * Depend on the gtk+3 version of wxWidgets: see #894663 * Override testsuite-autopkgtest-missing * Add an upstream/metadata file * Move the appdata.xml file from appdata/ to metadata/ * Change some links from http: to https: * Update to the latest debhelper and policy versions Regards, David Hart
Bug#869345: RFS: 4pane (new upstream version)
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for an update of my package "4pane" * Package name: 4pane Version : 5.0-1 Upstream Author : David Hart <debian.4p...@dfgh.net> * URL : http://4Pane.co.uk * License : GPL3 Section : x11 It builds these 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_5.0-1.dsc There is also a git repo: https://github.com/dghart/4pane-debian-dir After a new upstream release, I have updated the 4pane package, https://packages.debian.org/source/unstable/4pane. This is a request for a review and upload of that update. The amended package builds and works, and is lintian-clean apart from: I: 4pane source: testsuite-autopkgtest-missing Changes since the last upload: 4pane (5.0-1) unstable; urgency=medium * New upstream version. All the previous patches are now redundant and a dfsg tarball is no longer needed. Regards, David Hart
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 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 <deb...@4pane.co.uk>" >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 <deb...@4pane.co.uk>" 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 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
Stephan Kulow <co...@kde.org>" 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 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? Finally, my ITP has timed-out and the package removed from mentors. Does this now matter? Regards, David Hart
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 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 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 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)
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 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 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 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 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)
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 >th
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 <debian.4p...@dfgh.net> * 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
Bug#764520: RFS: 4pane/3.0-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package 4pane * Package name: 4pane Version : 3.0-1 Upstream Author : David Hart debian.4p...@dfgh.net * 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_3.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. Regards, David Hart -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141008202130.43ed5...@fx8350.here
