Bug#790816: RFS: roxterm/3.0.1-1
On 08/07/15 07:09, Vincent Cheng wrote: NameError: name 'reload' is not defined debian/rules:48: recipe for target 'override_dh_auto_clean' failed Oh, I didn't notice reload was python 2 only. And setdefaultencoding doesn't work any more in python 3 anyway. However, I was able to build your package just by adding "export LC_ALL=C.UTF-8" to d/rules. I can upload your package with this change, or if you'd rather fix this upstream, that's fine with me as well. I tried that with pdebuild and it didn't work for me. I got a series of errors from perl that it couldn't set the locale and was falling back to "C", and then mscript/maitch failed the same way as before. In any case I'd rather fix the problem upstream, in a way that doesn't depend on the environment, and I finally found a way to do that, by adding an encoding argument to open(). With this change it does build for me with pdebuild so I've uploaded it again, and hopefully we've got rid of all these problems at last. There is one other change, in src/roxterm-config.ui I rearranged the Tabs section of the profile editor slightly, in response to a simple issue that was raised upstream this morning. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#790816: RFS: roxterm/3.0.1-1
Hi Tony,
On Tue, Jul 7, 2015 at 6:07 AM, Tony Houghton wrote:
> On 07/07/15 09:21, Vincent Cheng wrote:
>
>> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position
>> 836: ordinal not in range(128)
>>
>> debian/rules:36: recipe for target 'override_dh_auto_build' failed
>>
>> I've attached the full build log.
>
>
> I think the problem is that the PC you tried the build on doesn't have utf8
> as its default encoding, so I need to enforce that in the script. This would
That's really more of a "problem" caused by pbuilder (which enforces
LANG=C and LC_ALL=C). If you aren't doing so already, please do test
build your package with pbuilder/cowbuilder/sbuild.
> need to apply upstream too so I think the best way is to change mscript.py
> with the attached patch. Would you be able to test that for me before I
> upload a new version?
>
Unfortunately your patch makes d/rules clean fail for me:
$ pdebuild --debbuildopts '-d'
dpkg-checkbuilddeps: Unmet build dependencies: librsvg2-bin libvte-2.91-dev po4a
W: Unmet build-dependency in source
dpkg-buildpackage: source package roxterm
dpkg-buildpackage: source version 3.0.1-1
dpkg-buildpackage: source distribution unstable
dpkg-buildpackage: source changed by Tony Houghton
dpkg-source --before-build roxterm-3.0.1
dpkg-source: info: using options from
roxterm-3.0.1/debian/source/options: --extend-diff-ignore=\.pot?$
dpkg-source: info: applying mscript.py.encoding.diff
fakeroot debian/rules clean
dh clean
dh_testdir
debian/rules override_dh_auto_clean
make[1]: Entering directory '/tmp/roxterm/roxterm-3.0.1'
python3 mscript.py clean --lock-top --build-dir=debian/build
--top-dir=../.. --src-dir='${TOP_DIR}/src'
Traceback (most recent call last):
File "mscript.py", line 4, in
reload(sys)
NameError: name 'reload' is not defined
debian/rules:48: recipe for target 'override_dh_auto_clean' failed
However, I was able to build your package just by adding "export
LC_ALL=C.UTF-8" to d/rules. I can upload your package with this
change, or if you'd rather fix this upstream, that's fine with me as
well.
Regards,
Vincent
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#790816: RFS: roxterm/3.0.1-1
On 07/07/15 09:21, Vincent Cheng wrote:
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position
836: ordinal not in range(128)
debian/rules:36: recipe for target 'override_dh_auto_build' failed
I've attached the full build log.
I think the problem is that the PC you tried the build on doesn't have
utf8 as its default encoding, so I need to enforce that in the script.
This would need to apply upstream too so I think the best way is to
change mscript.py with the attached patch. Would you be able to test
that for me before I upload a new version?
--- mscript.py.old 2015-07-07 14:00:48.380541102 +0100
+++ mscript.py 2015-07-07 14:01:52.855115233 +0100
@@ -1,6 +1,10 @@
#!/usr/bin/env python3
-import errno, os, re, sys, time
+import sys
+reload(sys)
+sys.setdefaultencoding('UTF8')
+
+import errno, os, re, time
from maitch import *
Bug#790816: RFS: roxterm/3.0.1-1
On 04/07/15 22:29, Vincent Cheng wrote: (If you have time, please upload an updated package to mentors so it's easier to discuss any further changes.) I've done that, hopefully it will be available by the time you read this. The Breaks/Replaces I've decided on are as follows: Package: roxterm-data Replaces: roxterm-common Breaks: roxterm-common (<< 3.0.0) I don't think it needs to explicitly Break any other packages, because their removal/replacement will be forced along with roxterm-common. Package: roxterm Replaces: roxterm-gtk3 (<< 3.0.0), roxterm-gtk2 (<< 3.0.0) Breaks: roxterm-gtk3 (<< 3.0.0), roxterm-gtk2 (<< 3.0.0) I originally also had it Break the old -dbg packages, but I think that's superfluous for the same reason as above. Package: roxterm-dbg Replaces: roxterm-gtk3-dbg (<< 3.0.0), roxterm-gtk2-dbg (<< 3.0.0) Breaks: roxterm-gtk3-dbg (<< 3.0.0), roxterm-gtk2-dbg (<< 3.0.0) roxterm-gtk2, roxterm-gtk3, roxterm-gtk2 and roxterm-gtk3 are now all dummy packages, they don't Break or Replace anything because the packages they depend on should take care of everything, and as virtual packages they don't contain files that clash with others. Nothing explicitly breaks the old virtual package roxterm, I can't see a need for that with all the other relationships I have. I've tested what should be the most difficult upgrade scenario in the piuparts chroot and it went smoothly. Other changes: I think debian/rules was passing CFLAGS etc to ./mscript.py configure incorrectly so I've fixed that. During testing I had a problem with changes wrt the tarball in a pot file while trying to repeat a build so I've added a debian/source/options with extend-diff-ignore for .pot and .po. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#790816: RFS: roxterm/3.0.1-1
On Sat, Jul 4, 2015 at 7:35 AM, Tony Houghton wrote: > One other point I noticed is that currently I have roxterm-data Breaks > and Replaces roxterm << 3.0.0-1 (actually I put 2 instead of 3 by > mistake so that needs changing anyway), where roxterm << 3 is the old > virtual package. As there is no direct replacement for that, do you > agree I should keep the Breaks where it is but remove the Replaces? > Breaks probably isn't strictly necessary either, but it might be a good > idea just in case there's a clash in /usr/share/doc/roxterm. If there's an upgrade scenario where file ownership changes from roxterm to roxterm-data or vice versa (i.e. one package overwrites files owned by the other), you need to declare both Breaks and Replaces. So if roxterm and roxterm-data both owned files with the same name in /usr/share/doc/roxterm or elsewhere, currently or in a past release, then yes, you'll need both Breaks and Replaces. (If you have time, please upload an updated package to mentors so it's easier to discuss any further changes.) Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#790816: RFS: roxterm/3.0.1-1
On 04/07/15 10:19, Vincent Cheng wrote: On Fri, Jul 3, 2015 at 8:30 AM, Tony Houghton wrote: My thinking is that anybody still using roxterm-gtk2 has some good reason to do so and will not want to upgrade to a GTK3 version even if it means missing out on the latest features and bug fixes; they are already missing out on some useful features from vte-2.90. With the relationships the way they are at the moment users can keep roxterm-gtk2 without having to pin it. I tested that scenario and it seems to work. But, since vte9 (the GTK2 version of vte) is scheduled for removal from the archive, is this undesirable? Ah, I didn't realize that this is actually intentional. Well, IMHO it's saner to offer users an upgrade path by default (i.e. to the gtk3 version), and let them choose to manually pin packages if they don't want to upgrade for some reason. However, I can't find a Policy reference that mandates all binary packages to have an upgrade path or similar, so I'll leave the choice to you. I think I'll change my decision on that. There do seem to be stronger reasons for providing an automatic upgrade from roxterm-gtk2 than to make things easier for users who want to keep it without continued support and maintenance. Ack, roxterm should declare Breaks: roxterm-gtk2 (in addition to -gtk3) and roxterm-dbg should declare Breaks: roxterm-gtk2-dbg (in addition to -gtk3-dbg). Why wouldn't you want the equivalent Replaces relationships here as well? Having roxterm declare Replaces: roxterm-gtk2 is not going to force roxterm-gtk2 to be automatically upgraded in the first scenario I described in my last email (where the user has roxterm-gtk2 and roxterm-common installed, but not roxterm; nothing gets upgraded in this scenario). Without Replaces, users who currently have only roxterm-gtk2 and roxterm-common installed, who then decide to switch to the gtk3 version by running apt-get install roxterm, can't do so (at least, not without removing roxterm-gtk2 first). One other point I noticed is that currently I have roxterm-data Breaks and Replaces roxterm << 3.0.0-1 (actually I put 2 instead of 3 by mistake so that needs changing anyway), where roxterm << 3 is the old virtual package. As there is no direct replacement for that, do you agree I should keep the Breaks where it is but remove the Replaces? Breaks probably isn't strictly necessary either, but it might be a good idea just in case there's a clash in /usr/share/doc/roxterm. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#790816: RFS: roxterm/3.0.1-1
* Tony Houghton , 2015-07-03, 16:30: The way I get the parallel option looks quite nasty too, is there a better way to do that? The code currently reads: ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) NUMJOBS = $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) CONFIGURE_COMMON += --parallel=$(NUMJOBS) endif You could probably avoid repeating the filter part: NUMJOBS = $(or $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS))),1) CONFIGURE_COMMON += --parallel=$(NUMJOBS) -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#790816: RFS: roxterm/3.0.1-1
On Fri, Jul 3, 2015 at 8:30 AM, Tony Houghton wrote: >> - d/rules: CFLAGS = $(shell dpkg-buildflags | grep '^CFLAGS=') is >> quite brittle; I suggest using dpkg-buildflags --get CFLAGS instead >> (ditto for CPPFLAGS and LDFLAGS) > > > That's better, I don't know how I missed that, unless it's a recent > addition to dpkg-buildflags. The way I get the parallel option looks > quite nasty too, is there a better way to do that? Not that I know of...I've never really worried about supporting parallel builds in my own packages, to be honest. >> Regarding your package split, have you tested other possible upgrade >> scenarios? There's a few scenarios I can think of that are broken or >> not ideal: >> - A user who just has roxterm-gtk2 installed (and roxterm-common >> auto-installed), without the roxterm metapackage, will not get any >> updates because both of these packages are no longer built from >> src:roxterm > > > My thinking is that anybody still using roxterm-gtk2 has some good > reason to do so and will not want to upgrade to a GTK3 version even if > it means missing out on the latest features and bug fixes; they are > already missing out on some useful features from vte-2.90. With the > relationships the way they are at the moment users can keep roxterm-gtk2 > without having to pin it. I tested that scenario and it seems to work. > But, since vte9 (the GTK2 version of vte) is scheduled for removal from > the archive, is this undesirable? Ah, I didn't realize that this is actually intentional. Well, IMHO it's saner to offer users an upgrade path by default (i.e. to the gtk3 version), and let them choose to manually pin packages if they don't want to upgrade for some reason. However, I can't find a Policy reference that mandates all binary packages to have an upgrade path or similar, so I'll leave the choice to you. >> - A user has roxterm-gtk2 and roxterm-gtk2-dbg installed. Aside from >> the same problem as the first scenario, if he/she now chooses to >> apt-get install roxterm-dbg, (I think) dpkg will explode due to file >> conflicts between roxterm-gtk2-dbg and roxterm-dbg. > > > So I should add Breaks: roxterm-gtk2-dbg to roxterm-dbg, and I think it > would also be more appropriate to move Breaks: roxterm-gtk2 and > roxterm-gtk3 from roxterm-data to roxterm, because the latter is the > package that contains the corresponding files. But, if the previous > point about preventing roxterm-gtk2 from being automatically upgraded is > OK, I don't want to add Replaces: roxterm-gtk2(-dbg). Ack, roxterm should declare Breaks: roxterm-gtk2 (in addition to -gtk3) and roxterm-dbg should declare Breaks: roxterm-gtk2-dbg (in addition to -gtk3-dbg). Why wouldn't you want the equivalent Replaces relationships here as well? Having roxterm declare Replaces: roxterm-gtk2 is not going to force roxterm-gtk2 to be automatically upgraded in the first scenario I described in my last email (where the user has roxterm-gtk2 and roxterm-common installed, but not roxterm; nothing gets upgraded in this scenario). Without Replaces, users who currently have only roxterm-gtk2 and roxterm-common installed, who then decide to switch to the gtk3 version by running apt-get install roxterm, can't do so (at least, not without removing roxterm-gtk2 first). Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#790816: RFS: roxterm/3.0.1-1
On 02/07/15 21:09, Vincent Cheng wrote: Control: tag -1 + moreinfo Control: owner -1 ! Hi Tony, On Wed, Jul 1, 2015 at 1:22 PM, Tony Houghton wrote: I thought I had released 2.9.6-1 and 2.9.7-1 via sponsorship too, but for some reason the current version in unstable is still 2.9.5-1. Is the changelog OK as above or should I merge these entries? Please merge the above d/changelog entries. Done. I think I've realised/remembered the reason for the "missing" releases. I released them upstream and in my Ubuntu PPA, but not for Debian because it was in freeze at the time and I didn't think the changes were important enough for an unblock. I just skimmed the debdiff between 2.9.5-1 and your package on mentors and noticed a few small things: - your newly added d/copyright stanza for ".ycm_extra_conf.py.in" has a License: GPL-3+ header, but the license body references GPL-2 multiple times. Fixed. But I have some more questions before I upload a new version... - d/rules: CFLAGS = $(shell dpkg-buildflags | grep '^CFLAGS=') is quite brittle; I suggest using dpkg-buildflags --get CFLAGS instead (ditto for CPPFLAGS and LDFLAGS) That's better, I don't know how I missed that, unless it's a recent addition to dpkg-buildflags. The way I get the parallel option looks quite nasty too, is there a better way to do that? Regarding your package split, have you tested other possible upgrade scenarios? There's a few scenarios I can think of that are broken or not ideal: - A user who just has roxterm-gtk2 installed (and roxterm-common auto-installed), without the roxterm metapackage, will not get any updates because both of these packages are no longer built from src:roxterm My thinking is that anybody still using roxterm-gtk2 has some good reason to do so and will not want to upgrade to a GTK3 version even if it means missing out on the latest features and bug fixes; they are already missing out on some useful features from vte-2.90. With the relationships the way they are at the moment users can keep roxterm-gtk2 without having to pin it. I tested that scenario and it seems to work. But, since vte9 (the GTK2 version of vte) is scheduled for removal from the archive, is this undesirable? - A user has roxterm-gtk2 and roxterm-gtk2-dbg installed. Aside from the same problem as the first scenario, if he/she now chooses to apt-get install roxterm-dbg, (I think) dpkg will explode due to file conflicts between roxterm-gtk2-dbg and roxterm-dbg. So I should add Breaks: roxterm-gtk2-dbg to roxterm-dbg, and I think it would also be more appropriate to move Breaks: roxterm-gtk2 and roxterm-gtk3 from roxterm-data to roxterm, because the latter is the package that contains the corresponding files. But, if the previous point about preventing roxterm-gtk2 from being automatically upgraded is OK, I don't want to add Replaces: roxterm-gtk2(-dbg). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#790816: RFS: roxterm/3.0.1-1
Control: tag -1 + moreinfo Control: owner -1 ! Hi Tony, On Wed, Jul 1, 2015 at 1:22 PM, Tony Houghton wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "roxterm" > > * Package name: roxterm >Version : 3.0.1-1 >Upstream Author : Tony Houghton > * URL : http://roxterm.sourceforge.net > * License : GPL2+ >Section : x11 > > It builds these binary packages: > > roxterm- Multi-tabbed GTK+/VTE terminal emulator - binaries > roxterm-data - Multi-tabbed GTK+/VTE terminal emulator - data files > roxterm-dbg - Debugging symbols for roxterm > roxterm-gtk3 - Multi-tabbed GTK+/VTE terminal emulator - transitional > package > roxterm-gtk3-dbg - Multi-tabbed GTK+/VTE terminal emulator - transitional > package > > To access further information about this package, please visit the following > URL: > > http://mentors.debian.net/package/roxterm > > > Alternatively, one can download the package with dget using this command: > > dget -x > http://mentors.debian.net/debian/pool/main/r/roxterm/roxterm_3.0.1-1.dsc > > More information about roxterm can be obtained from > http://roxterm.sourceforge.net > > Changes since the last upload: > > roxterm (3.0.1-1) unstable; urgency=medium > > * Updated Standards-Version to 3.9.6. > * Build uses python3 (updated Build-Depends accordingly). > * Upstream tarball now uses .xz compression. > * Added Select All menu item. > * Allow unlimited scrollback lines. > * Fixed some unsafe uses of sprintf. > * Provide option to rewrap text when terminal width changes. > * Drop support for GTK2 etc (Closes: #790183). > * Reorganized surviving binary packages. > * Use vte-2.91 API (Closes: #788028). > > -- Tony Houghton Wed, 01 Jul 2015 18:50:46 +0100 > > roxterm (2.9.7-1) unstable; urgency=low > > * Fixed colour/shortcut shceme CLI switch clash. > * Fixed --tab aiming to target most recently focused window. > > -- Tony Houghton Mon, 30 Mar 2015 18:24:17 +0100 > > roxterm (2.9.6-1) unstable; urgency=low > > * debian/copyright: Added .ycm_extra_conf.py.in. > * Fade text in unselected tabs. > * Fix maximise and full screen buttons in profile. > > -- Tony Houghton Thu, 08 Jan 2015 21:16:21 + > > I thought I had released 2.9.6-1 and 2.9.7-1 via sponsorship too, but > for some reason the current version in unstable is still 2.9.5-1. Is the > changelog OK as above or should I merge these entries? Please merge the above d/changelog entries. I just skimmed the debdiff between 2.9.5-1 and your package on mentors and noticed a few small things: - your newly added d/copyright stanza for ".ycm_extra_conf.py.in" has a License: GPL-3+ header, but the license body references GPL-2 multiple times. - d/rules: CFLAGS = $(shell dpkg-buildflags | grep '^CFLAGS=') is quite brittle; I suggest using dpkg-buildflags --get CFLAGS instead (ditto for CPPFLAGS and LDFLAGS) Regarding your package split, have you tested other possible upgrade scenarios? There's a few scenarios I can think of that are broken or not ideal: - A user who just has roxterm-gtk2 installed (and roxterm-common auto-installed), without the roxterm metapackage, will not get any updates because both of these packages are no longer built from src:roxterm - A user has roxterm-gtk2 and roxterm-gtk2-dbg installed. Aside from the same problem as the first scenario, if he/she now chooses to apt-get install roxterm-dbg, (I think) dpkg will explode due to file conflicts between roxterm-gtk2-dbg and roxterm-dbg. And perhaps other scenarios as well, but that's all for now since my lunch break is over. :) You should actually keep around dummy transitional packages for every single package that's currently no longer being built from src:roxterm. That's probably the simplest way of making sure all possible upgrade scenarios work (+ double checking package inter-relationships are correct). Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#790816: RFS: roxterm/3.0.1-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "roxterm" * Package name: roxterm Version : 3.0.1-1 Upstream Author : Tony Houghton * URL : http://roxterm.sourceforge.net * License : GPL2+ Section : x11 It builds these binary packages: roxterm- Multi-tabbed GTK+/VTE terminal emulator - binaries roxterm-data - Multi-tabbed GTK+/VTE terminal emulator - data files roxterm-dbg - Debugging symbols for roxterm roxterm-gtk3 - Multi-tabbed GTK+/VTE terminal emulator - transitional package roxterm-gtk3-dbg - Multi-tabbed GTK+/VTE terminal emulator - transitional package To access further information about this package, please visit the following URL: http://mentors.debian.net/package/roxterm Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/r/roxterm/roxterm_3.0.1-1.dsc More information about roxterm can be obtained from http://roxterm.sourceforge.net Changes since the last upload: roxterm (3.0.1-1) unstable; urgency=medium * Updated Standards-Version to 3.9.6. * Build uses python3 (updated Build-Depends accordingly). * Upstream tarball now uses .xz compression. * Added Select All menu item. * Allow unlimited scrollback lines. * Fixed some unsafe uses of sprintf. * Provide option to rewrap text when terminal width changes. * Drop support for GTK2 etc (Closes: #790183). * Reorganized surviving binary packages. * Use vte-2.91 API (Closes: #788028). -- Tony Houghton Wed, 01 Jul 2015 18:50:46 +0100 roxterm (2.9.7-1) unstable; urgency=low * Fixed colour/shortcut shceme CLI switch clash. * Fixed --tab aiming to target most recently focused window. -- Tony Houghton Mon, 30 Mar 2015 18:24:17 +0100 roxterm (2.9.6-1) unstable; urgency=low * debian/copyright: Added .ycm_extra_conf.py.in. * Fade text in unselected tabs. * Fix maximise and full screen buttons in profile. -- Tony Houghton Thu, 08 Jan 2015 21:16:21 + I thought I had released 2.9.6-1 and 2.9.7-1 via sponsorship too, but for some reason the current version in unstable is still 2.9.5-1. Is the changelog OK as above or should I merge these entries? Regards, Tony Houghton -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
