Bug#810536: RFS: roxterm/3.3.2-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for the latest version of my package "roxterm" * Package name: roxterm Version : 3.3.2-1 Upstream Author : Tony Houghton <h...@realh.co.uk> * 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-gtk2 - Transitional package to upgrade roxterm-gtk2 to roxterm roxterm-gtk2-dbg - Transitional package to upgrade roxterm-gtk2-dbg to roxterm-dbg roxterm-gtk3 - Transitional package to upgrade roxterm-gtk3 to roxterm roxterm-gtk3-dbg - Transitional package to upgrade roxterm-gtk3-dbg to roxterm-dbg 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.3.2-1.dsc More information about roxterm can be obtained from http://roxterm.sourceforge.net Changes since the last upload: roxterm (3.3.2-1) unstable; urgency=medium * Removed debian/dirs to prevent creation of now empty /usr/share/pixmaps. * Build-Depends avoids buggy version of gettext (Closes: #809570). * debian/rules: Use --enable-nls instead of deprecated --enable-translations. * New upstream release: + Fixed ssh port number in config ui (upstream #120). + Fixed configure --disable-nls. + Update New Window/Tab With Profile submenus when profiles change (upstream #121). + Fade text and background colour labels along with buttons (Closes: #810016). + Documented shortcuts translation problem described by #809719. -- Tony Houghton <h...@realh.co.uk> Sat, 09 Jan 2016 14:00:02 + Bug #809570 is actually due to a gettext bug (which is now fixed), but I decided to keep a separate ticket open for roxterm because I changed its Build-Depends to avoid the buggy version of gettext.
Bug#806898: RFS: roxterm/3.3.1-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for the latest version of my package "roxterm" * Package name: roxterm Version : 3.3.1-1 Upstream Author : Tony Houghton <h...@realh.co.uk> * 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-gtk2 - Transitional package to upgrade roxterm-gtk2 to roxterm roxterm-gtk2-dbg - Transitional package to upgrade roxterm-gtk2-dbg to roxterm-dbg roxterm-gtk3 - Transitional package to upgrade roxterm-gtk3 to roxterm roxterm-gtk3-dbg - Transitional package to upgrade roxterm-gtk3-dbg to roxterm-dbg 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.3.1-1.dsc More information about roxterm can be obtained from http://roxterm.sourceforge.net Changes since the last upload:
Bug#803395: RFS: roxterm/3.2.1-1
Package: sponsorship-requests Severity: normal Dear Vicent and/or other potential sponsors, I am looking for a sponsor for the latest version of my package "roxterm" * Package name: roxterm Version : 3.2.1-1 Upstream Author : Tony Houghton <h...@realh.co.uk> * 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-gtk2 - Transitional package to upgrade roxterm-gtk2 to roxterm roxterm-gtk2-dbg - Transitional package to upgrade roxterm-gtk2-dbg to roxterm-dbg roxterm-gtk3 - Transitional package to upgrade roxterm-gtk3 to roxterm roxterm-gtk3-dbg - Transitional package to upgrade roxterm-gtk3-dbg to roxterm-dbg 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.2.1-1.dsc More information about roxterm can be obtained from http://roxterm.sourceforge.net Changes since the last upload: roxterm (3.2.1-1) unstable; urgency=medium * New upstream version: + Use vte 0.40's new word char API (Closes: #798656). * Don't use deprecated debian menu system. -- Tony Houghton <h...@realh.co.uk> Thu, 29 Oct 2015 13:12:11 +
Bug#796261: RFS: roxterm/3.1.5-1
Package: sponsorship-requests Severity: normal Dear Vicent and/or other potential sponsors, I am looking for a sponsor for the latest version of my package roxterm * Package name: roxterm Version : 3.1.5-1 Upstream Author : Tony Houghton h...@realh.co.uk * 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-gtk2 - Transitional package to upgrade roxterm-gtk2 to roxterm roxterm-gtk2-dbg - Transitional package to upgrade roxterm-gtk2-dbg to roxterm-dbg roxterm-gtk3 - Transitional package to upgrade roxterm-gtk3 to roxterm roxterm-gtk3-dbg - Transitional package to upgrade roxterm-gtk3-dbg to roxterm-dbg It fixes upstream bug https://sourceforge.net/p/roxterm/bugs/116/ which is quite severe. 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.1.5-1.dsc More information about roxterm can be obtained from http://roxterm.sourceforge.net Changes since the last upload: roxterm (3.1.5-1) unstable; urgency=medium * Prevent --fork crashing on broken DBUS messages. -- Tony Houghton h...@realh.co.uk Thu, 20 Aug 2015 16:21:44 +0100
Bug#795298: #795298 RFS: roxterm/3.1.3-1
On 12/08/15 19:39, Tony Houghton wrote: Oops, please wait until I change it to 3.1.4-1. I overlooked the appdata file in #795217. It contains some outdated content so I need to change it upstream. OK, 3.1.4-1 is ready now. The dget command is now: dget -x http://mentors.debian.net/debian/pool/main/r/roxterm/roxterm_3.1.4-1.dsc and the ChangeLog since the last release is: roxterm (3.1.4-1) unstable; urgency=medium * Make --fork wait until dbus service name has been acquired. * Fixed child-exited signal handler for vte-2.91's new signature. * Support named user sessions. * Removed profile option for initial number of tabs. * Updated roxterm.svg's and roxterm.appdata.xml.in's licence and copyright (Closes: #795217). * debian/control: Changed descriptions and dependencies of dummy packages to prevent lintian warnings. * Added lintian overrides for warnings about dummy dbg packages. -- Tony Houghton h...@realh.co.uk Wed, 12 Aug 2015 19:54:53 +0100
Bug#795298: RFS: roxterm/3.1.3-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package roxterm * Package name: roxterm Version : 3.1.3-1 Upstream Author : Tony Houghton h...@realh.co.uk * 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-gtk2 - Transitional package to updgrade roxterm-gtk2 to roxterm roxterm-gtk2-dbg - Transitional package to updgrade roxterm-gtk2-dbg to roxterm-dbg roxterm-gtk3 - Transitional package to updgrade roxterm-gtk3 to roxterm roxterm-gtk3-dbg - Transitional package to updgrade roxterm-gtk3-dbg to roxterm-dbg 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.1.3-1.dsc More information about roxterm can be obtained from http://roxterm.sourceforge.net Changes since the last upload: roxterm (3.1.3-1) unstable; urgency=medium * Make --fork wait until dbus service name has been acquired. * Fixed child-exited signal handler for vte-2.91's new signature. * Support named user sessions. * Removed profile option for initial number of tabs. * Updated SVG icon's licence and copyright (Closes: #795217). * debian/control: Changed descriptions and dependencies of dummy packages to prevent lintian warnings. * Added lintian overrides for warnings about dummy dbg packages. -- Tony Houghton h...@realh.co.uk Wed, 12 Aug 2015 18:13:04 +0100 Regards, Tony Houghton
Bug#795298: #795298 RFS: roxterm/3.1.3-1
Oops, please wait until I change it to 3.1.4-1. I overlooked the appdata file in #795217. It contains some outdated content so I need to change it upstream.
Bug#792200: closed by Vincent Cheng vch...@debian.org (Re: Bug#792200: RFS: roxterm/3.0.2-1)
Hi, I got emails saying that roxterm 3.0.1-1 and then 3.0.2-1 were uploaded and the RFS bugs closed (the latter on 13 July), but the latest version showing up in the archives is still 2.9.5-1. Has something gone wrong with the upload? -- 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/55c34ee7.3010...@realh.co.uk
Bug#792200: RFS: roxterm/3.0.2-1
Package: sponsorship-requests Severity: normal Dear mentors, By Murphy's Law (or is it Sod's Law) I found quite a serious bug in roxterm a day or two after the last release, so I've uploaded a new version which needs sponsoring. TIA. * Package name: roxterm Version : 3.0.2-1 Upstream Author : Tony Houghton h...@realh.co.uk * 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-gtk2 - Multi-tabbed GTK+/VTE terminal emulator - transitional package roxterm-gtk2-dbg - Multi-tabbed GTK+/VTE terminal emulator - transitional package 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.2-1.dsc More information about roxterm can be obtained from http://roxterm.sourceforge.net Changes since the last upload: roxterm (3.0.2-1) unstable; urgency=medium * Fixed crash when dragging a tab from one window to another. * Added note about python 2-3 migration to news.html. -- Tony Houghton h...@realh.co.uk Sun, 12 Jul 2015 14:11:47 +0100 -- 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/55a27071.3030...@realh.co.uk
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-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/559e8c12.3010...@realh.co.uk
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-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/559a9ddc.2010...@realh.co.uk
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 h...@realh.co.uk 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-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5597ef43.6020...@realh.co.uk
Re: Restructuring roxterm packaging (was Replacing roxterm's multiple binary packages with one)
On 02/07/15 20:49, Vincent Cheng wrote: Hi Tony, Sorry, just saw your roxterm RFS and realized that I actually never got back to you with your latest set of questions. On Wed, Jun 17, 2015 at 5:49 AM, Tony Houghton h...@realh.co.uk wrote: That won't cause problems due to the reversed dependencies? One disadvantage I can foresee is that this will cause everybody who automatically upgrades from version 2.x to have this virtual package installed. Is Provides definitely the wrong thing to do? Provides (i.e. using virtual packages) is not meant to be used to facilitate upgrades (Policy 3.6 describes their intended purpose [1]). Transitional packages with the appropriate depends+breaks+replaces package inter-relationships is the proper way of renaming packages, and shouldn't cause any problems if done right. OK. I tried Provides in the chroot, because I didn't interpret the policy manual as forbidding it for this purpose, but I found it didn't have the desired effect anyway. If I do use a new dummy package I think it would be a good idea to notify users that they can remove it, or is it not important enough to justify potentially interrupting the upgrade process? And is NEWS.Debian the correct mechanism for such messages? IMHO if the upgrade process doesn't require any manual user intervention, there's no point in notifying users via debian/NEWS (I know apt-listchanges will read debian/NEWS, not sure about debian/NEWS.Debian). And having packages be renamed shouldn't require any user intervention (dummy packages can be kept installed indefinitely and not cause any issues). OK. I had decided not to do that anyway. Sorry about the partially duplicate post. I lost connectivity to my IMAP server while posting the first one and didn't realise the SMTP had succeeded. And I'm wondering whether it would be better to aim to remove such a transitional package quite soon, or keep it until after the next release of Debian. I think the latter would help ease upgrades indefinitely, but typical roxterm users are probably more likely to track testing or unstable than to only upgrade at stable Debian releases. Please keep the transitional package around for at least one full release cycle. It's not safe to assume that all roxterm users only track testing/unstable, and there's little cost to you as maintainer to keep around a dummy package to facilitate oldstable-stable upgrades (nothing more than an extra binary package stanza in d/control, really) so that stable users can have painfree upgrades. Good, that again confirms what I thought. -- 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/5596a0cd.2040...@realh.co.uk
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 h...@realh.co.uk 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-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5596aaa4.9060...@realh.co.uk
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 h...@realh.co.uk * 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 h...@realh.co.uk 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 h...@realh.co.uk 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 h...@realh.co.uk 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-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55944c02.4080...@realh.co.uk
Re: Restructuring roxterm packaging (was Replacing roxterm's multiple binary packages with one)
On 17/06/15 04:56, Vincent Cheng wrote: On Tue, Jun 16, 2015 at 9:30 AM, Tony Houghton h...@realh.co.uk wrote: What I found was that if roxterm-gtk3 is installed, but not roxterm (the old virtual package), dist-upgrade doesn't install the new roxterm package. I was expecting the 'Replaces: roxterm-gtk3' in the new roxterm to make that happen. 'apt-get install roxterm' does remove roxterm-common and roxterm-gtk3, replacing them with roxterm-data and roxterm, which is good. Should I just leave it at that, or is there something I can and should do to persuade dist-upgrade to automatically replace roxterm-gtk3 with the new roxterm? How would I do that? 'Provides: roxterm-gtk3' perhaps? Make roxterm-gtk3 a dummy transitional package (i.e. Section: oldlibs, Priority: extra), and have it depend on roxterm (and keep the dummy package around for at least one release to facilitate upgrades). Would it be a good idea to show a message when installing the new dummy package, recommending that users remove it, and if so, is NEWS.Debian the correct way to do that? And I'm wondering whether it would be better to aim to remove such a transitional package quite soon, or keep it until after the next release of Debian. I think the latter would help ease upgrades indefinitely, but typical roxterm users are probably more likely to track testing or unstable than to only upgrade at stable Debian releases. -- 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/558175fb.7040...@realh.co.uk
Re: Restructuring roxterm packaging (was Replacing roxterm's multiple binary packages with one)
On 17/06/15 04:56, Vincent Cheng wrote: On Tue, Jun 16, 2015 at 9:30 AM, Tony Houghton h...@realh.co.uk wrote: What I found was that if roxterm-gtk3 is installed, but not roxterm (the old virtual package), dist-upgrade doesn't install the new roxterm package. I was expecting the 'Replaces: roxterm-gtk3' in the new roxterm to make that happen. 'apt-get install roxterm' does remove roxterm-common and roxterm-gtk3, replacing them with roxterm-data and roxterm, which is good. Should I just leave it at that, or is there something I can and should do to persuade dist-upgrade to automatically replace roxterm-gtk3 with the new roxterm? How would I do that? 'Provides: roxterm-gtk3' perhaps? Make roxterm-gtk3 a dummy transitional package (i.e. Section: oldlibs, Priority: extra), and have it depend on roxterm (and keep the dummy package around for at least one release to facilitate upgrades). That won't cause problems due to the reversed dependencies? One disadvantage I can foresee is that this will cause everybody who automatically upgrades from version 2.x to have this virtual package installed. Is Provides definitely the wrong thing to do? If I do use a new dummy package I think it would be a good idea to notify users that they can remove it, or is it not important enough to justify potentially interrupting the upgrade process? And is NEWS.Debian the correct mechanism for such messages? -- 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/55816ce0.4080...@realh.co.uk
Re: Restructuring roxterm packaging (was Replacing roxterm's multiple binary packages with one)
On 15/06/15 08:19, Vincent Cheng wrote: If these changes are inevitable, it's really up to you as to when you want to make them happen (I'd suggest that doing them early in the release cycle is better than later, however). I think these changes sound fine in principle, although a debdiff would certainly make it easier to make a judgment. Either way, please be sure to test various upgrade scenarios with piuparts and/or manually using a chroot/VM before uploading your package! I've done some testing. I had to set up a repo with reprepro anyway to be able to test what apt-get would do, but I didn't find piuparts very useful beyond creating a persistent chroot with its -k option. What I found was that if roxterm-gtk3 is installed, but not roxterm (the old virtual package), dist-upgrade doesn't install the new roxterm package. I was expecting the 'Replaces: roxterm-gtk3' in the new roxterm to make that happen. 'apt-get install roxterm' does remove roxterm-common and roxterm-gtk3, replacing them with roxterm-data and roxterm, which is good. Should I just leave it at that, or is there something I can and should do to persuade dist-upgrade to automatically replace roxterm-gtk3 with the new roxterm? How would I do that? 'Provides: roxterm-gtk3' perhaps? -- 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/55804f41.5010...@realh.co.uk
Restructuring roxterm packaging (was Replacing roxterm's multiple binary packages with one)
On 09/06/15 14:04, Dominique Dumont wrote: On Monday 08 June 2015 16:54:53 Tony Houghton wrote: roxterm-common (data files, roxterm-gtk2 and roxterm-gtk3 depend on it) roxterm-gtk2, roxterm-gtk3 (binaries) roxterm-gtk2-dbg, roxterm-gtk3-dbg (corresponding debugging symbols) roxterm (virtual package depending on roxterm-gtk3) I want to replace them with a single package, roxterm. I'm not quite sure how to set up the package relationships to do this. I would like the new roxterm to automatically replace roxterm-gtk3, so I think I need to add Replaces: roxterm-gtk3 to the new roxterm, and AFAICT from the policy manual I should use Breaks as well (rather than Conflicts). Depending on its size, it may be better to keep roxterm-common: this package is arch:all and this would avoid duplication these data for each arch. Next, you may want to consider what will happen if (or when?) gtk4 appears on your radar screen: will you split roxterm package again ? OK, I'll keep the current structure, apart from dropping the gtk2 packages. However, now that there isn't more than one supported GTK version the names aren't so appropriate. I'd like to rename roxterm-common to roxterm-data, drop the virtual package and rename roxterm-gtk3 to just roxterm (similarly roxterm-gtk3-dbg - roxterm-dbg). Should I avoid those changes unless absolutely necessary, or go ahead and make them now? roxterm-gtk3 would presumably have to be renamed eventually anyway on migration to GTK4. -- 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/557d7719.5090...@realh.co.uk
Re: Replacing roxterm's multiple binary packages with one
On 10/06/15 12:53, Dominique Dumont wrote: On Tuesday 09 June 2015 17:22:30 Tony Houghton wrote: Depending on its size, it may be better to keep roxterm-common: this package is arch:all and this would avoid duplication these data for each arch. IIRC I was thinking of doing that a long time ago (before the GTK2/3 split) but was advised against it because the data files weren't very big. But they're probably considerably bigger now, mainly because of the translations. Then we need the current data size to find out the best solution. roxterm-common 2.9.5-1 in the previous/current release has a package size of 182.1KB. roxterm-gtk3:amd64 is 145.1KB, and roxterm-gtk3-dbg:amd64 is 411.8KB. My prototype monolithic package for amd64 (including debugging symbols) is 902KB. I suppose the relative size of the existing dbg packages makes a strong case against including debugging symbols in the main package. -- 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/5578327b.90...@realh.co.uk
Re: Replacing roxterm's multiple binary packages with one
On 09/06/15 14:04, Dominique Dumont wrote: On Monday 08 June 2015 16:54:53 Tony Houghton wrote: roxterm-common (data files, roxterm-gtk2 and roxterm-gtk3 depend on it) roxterm-gtk2, roxterm-gtk3 (binaries) roxterm-gtk2-dbg, roxterm-gtk3-dbg (corresponding debugging symbols) roxterm (virtual package depending on roxterm-gtk3) I want to replace them with a single package, roxterm. I'm not quite sure how to set up the package relationships to do this. I would like the new roxterm to automatically replace roxterm-gtk3, so I think I need to add Replaces: roxterm-gtk3 to the new roxterm, and AFAICT from the policy manual I should use Breaks as well (rather than Conflicts). Depending on its size, it may be better to keep roxterm-common: this package is arch:all and this would avoid duplication these data for each arch. IIRC I was thinking of doing that a long time ago (before the GTK2/3 split) but was advised against it because the data files weren't very big. But they're probably considerably bigger now, mainly because of the translations. If I did that I think I'd still have to use Breaks or Conflicts against the GTK2 packages I'm dropping; again I'd need some advice on exactly how to do that. Next, you may want to consider what will happen if (or when?) gtk4 appears on your radar screen: will you split roxterm package again ? There were reasons for people to stick to GTK2, such as not liking GNOME 3 and because of https://bugzilla.gnome.org/show_bug.cgi?id=649680, but I hope the GTK3/4 transition will be smoother and not give me reasons to support both at once. -- 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/557712c6.1080...@realh.co.uk
Replacing roxterm's multiple binary packages with one
I've decided to discontinue support for legacy libraries in roxterm and concentrate on GTK3 and vte-2.91 and I want to simplify the packaging because of this. The current/old version has these binary packages: roxterm-common (data files, roxterm-gtk2 and roxterm-gtk3 depend on it) roxterm-gtk2, roxterm-gtk3 (binaries) roxterm-gtk2-dbg, roxterm-gtk3-dbg (corresponding debugging symbols) roxterm (virtual package depending on roxterm-gtk3) I want to replace them with a single package, roxterm. I'm not quite sure how to set up the package relationships to do this. I would like the new roxterm to automatically replace roxterm-gtk3, so I think I need to add Replaces: roxterm-gtk3 to the new roxterm, and AFAICT from the policy manual I should use Breaks as well (rather than Conflicts). The main complication is that I don't want to use Replaces: roxterm-gtk2 in case some people want to hang on to that for as long as possible (GTK3 windows with geometry don't work properly with some window managers, for instance), and having the new version wanting to replace it at every dist-upgrade would be a nuisance for them. So should I add Breaks: roxterm-common, roxterm-gtk2 without a corresponding Replaces? Anything else? Should the new roxterm also be marked Breaks older versions of its namesake? Also, I don't want a separate package for the sake of debugging symbols. Is it OK to include them in the main package and override lintian, or is it mandatory to use a separate -dbg package? If so, my preference would be to exclude the debugging symbols for the sake of the simplicity of a single binary package. -- 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/5575bacd.8080...@realh.co.uk
Bug#771361: RFS: roxterm/2.9.5-1
On 29/11/2014 00:18, gregor herrmann wrote: On Fri, 28 Nov 2014 19:35:02 +, Tony Houghton wrote: I am looking for a sponsor for my package roxterm. I have also posted an unblock request which is #771358. Should I merge these two bugs? Please add the requested information (i.e. a debdiff of the .dsc files) to #771358. It would make sense to have a yay/nay from the release team before uploading the new version to unstable. I've been asked to go ahead in #771358 so I'd be grateful for someone to proceed with the sponsorship. -- 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/547b1b28.7070...@realh.co.uk
Bug#771361: RFS: roxterm/2.9.5-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package roxterm. I have also posted an unblock request which is #771358. Should I merge these two bugs? * Package name: roxterm * Version : 2.9.5-1 * Upstream Author : Tony Houghton h...@realh.co.uk * URL : http://roxterm.sourceforge.net * License : GPL-2+, LGPL-3+ * Section : x11 It builds these binary packages: roxterm - Multi-tabbed GTK+/VTE terminal emulator - virtual package for GTK3 roxterm-common - Multi-tabbed GTK+/VTE terminal emulator - common files roxterm-gtk2 - Multi-tabbed GTK+/VTE terminal emulator - GTK2 version roxterm-gtk2-dbg - Debugging symbols for GTK2 version of roxterm roxterm-gtk3 - Multi-tabbed GTK+/VTE terminal emulator - GTK3 version roxterm-gtk3-dbg - Debugging symbols for GTK3 version of roxterm 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_2.9.5-1.dsc More information about roxterm can be obtained from http://roxterm.sourceforge.net Changes since the last upload: roxterm (2.9.5-1) unstable; urgency=medium * Recognise _NET_WM_DESKTOP special value 0x correctly. * Don't crash if EDITOR env variable is unset when editing shortcuts (Closes: #771022). -- Tony Houghton h...@realh.co.uk Fri, 28 Nov 2014 18:20:06 + Regards, Tony Houghton -- 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/5478ce66.2080...@realh.co.uk
Bug#762011: RFS: roxterm/2.9.4-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package roxterm * Package name: roxterm * Version : 2.9.4-1 * Upstream Author : Tony Houghton h...@realh.co.uk * URL : http://roxterm.sourceforge.net * License : GPL-2+, LGPL-3+ * Section : x11 It builds these binary packages: roxterm - Virtual package for roxterm-gtk3 roxterm-common - Multi-tabbed GTK+/VTE terminal emulator - common files roxterm-gtk2 - Multi-tabbed GTK+/VTE terminal emulator - GTK2 version roxterm-gtk2-dbg - Debugging symbols for GTK2 version of roxterm roxterm-gtk3 - Multi-tabbed GTK+/VTE terminal emulator - GTK3 version roxterm-gtk3-dbg - Debugging symbols for GTK3 version of roxterm 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_2.9.4-1.dsc More information about roxterm can be obtained from http://roxterm.sourceforge.net. Changes since the last upload: roxterm (2.9.4-1) unstable; urgency=low * Fixed metadata_license and non-default screenshot in appdata. * debian/control Build-Depends: + Added libtool-bin (Closes: #761785). + Added librsvg2-bin. + Removed graphicsmagick option:- it can't create favicon.ico. Regards, Tony Houghton -- 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/5419d04b.8070...@realh.co.uk
Bug#756634: RFS: roxterm/2.9.3-1 (was 2.9.1-1)
retitle 756634 RFS: roxterm/2.9.3-1 thanks On 08/08/14 09:48, Vincent Cheng wrote: On Thu, Aug 7, 2014 at 6:06 AM, Tony Houghton h...@realh.co.uk wrote: Except that wasn't working for me, it said it was incompatible with source format 3.0 (Quilt) (see above). Or was it specifically my regex or syntax? It looked OK to me. Have you tried building roxterm twice in a row in an up-to-date sid chroot (you're probably already doing this since it's best practice anyways, but it can't hurt to ask I guess)? Does that error message still appear then? Ruling out differences in your build environment, I don't see anything else that could be causing the problem you're having with extend-diff-ignore. To be honest I've been a bit lazy and not done that, but I've hopefully found another solution to the problem and also made sure to run a dist-upgrade before building. I've changed upstream so that AppInfo.xml only gets written at the configure stage if it doesn't already exist, otherwise it only gets updated when generating the tarball. The new version is 2.9.3-1, dsc at http://mentors.debian.net/debian/pool/main/r/roxterm/roxterm_2.9.3-1.dsc. Fingers crossed this problem is finally laid to rest! -- 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/53e4e665.8090...@realh.co.uk
Bug#756634: RFS: roxterm/2.9.1-1
On 07/08/14 09:27, Vincent Cheng wrote:
On Wed, Aug 6, 2014 at 3:01 PM, Tony Houghton h...@realh.co.uk wrote:
retitle 756634 RFS: roxterm/2.9.2-1
thanks
I think I've managed to fix the build now so that the debian package can be
built repeatedly. Most of the changes are upstream so there is a new
version. Please use the new link:
http://mentors.debian.net/debian/pool/main/r/roxterm/roxterm_2.9.2-1.dsc
Thanks for helping to improve this package and to get the new version into
Debian.
Building twice in a row still fails (the date in AppInfo.xml can
change; you can easily just workaround this with extend-diff-ignore,
of course):
Except that wasn't working for me, it said it was incompatible with
source format 3.0 (Quilt) (see above). Or was it specifically my regex
or syntax? It looked OK to me.
AppInfo.xml is a hangover from when I used to use the ROX desktop.
Shipping it in the tarball allows users to see info about the app before
compiling it. I don't know whether any roxterm users are still using
that, but I don't want to delete the ROX bits just in case. Next time I
change upstream I should change the build so that it doesn't regenerate
AppInfo.xml, and get my update-tags script to change it instead (I'll
keep forgetting if I rely on doing it manually).
But for now I'd like to fix this without a new upstream release. If I
can't get extend-diff-ignore to work would it be OK to have debian/rules
copy the file into debian at the start of the build and restore it
afterwards? Or is that too nasty a kludge?
Also, if you don't mind me being a bit pedantic, can you run
wrap-and-sort -s so that e.g. it'd be easier to review changes to your
deps and build-deps in debian/control?
OK, one dep per line, that makes sense. Is there anything I should do to
have it applied to other files generated from control after expanding
${misc:Depends} etc?
--
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/53e379c6.6040...@realh.co.uk
Bug#756634: RFS: roxterm/2.9.1-1
retitle 756634 RFS: roxterm/2.9.2-1 thanks I think I've managed to fix the build now so that the debian package can be built repeatedly. Most of the changes are upstream so there is a new version. Please use the new link: http://mentors.debian.net/debian/pool/main/r/roxterm/roxterm_2.9.2-1.dsc Thanks for helping to improve this package and to get the new version into Debian. -- 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/53e2a5d3.50...@realh.co.uk
Bug#756634: RFS: roxterm/2.9.1-1
On 04/08/14 21:58, Vincent Cheng wrote: On Mon, Aug 4, 2014 at 12:24 PM, Tony Houghton h...@realh.co.uk wrote: On 04/08/14 07:11, Vincent Cheng wrote: On Thu, Jul 31, 2014 at 10:15 AM, Eriberto Mota eribe...@debian.org wrote: - Allow the content modification of the po/roxterm.pot. To make it, create the file debian/source/options with this content[1]: extend-diff-ignore = ^po/roxterm.pot$ I did that, but I get this warning: dpkg-source: warning: --extend-diff-ignore:=(^|/)po/roxterm.pot$ is not a valid option for Dpkg::Source::Package::V3::Quilt This seems to work (there are a lot more files that dpkg-source complains about): extend-diff-ignore = ^(po/((.*).mo|roxterm.pot)|(.*).xml|Help/(.*)|roxterm.spec)$ That still doesn't work for me, I get the same warning as before. If it works for you I'll upload a new version with that and some other changes designed to fix this, but there are still several underlying problems with the build, creating things like .mo files in the top source directory instead of in the build directory, and building in debian/build-gtk* causes the .pot files to show different paths for the source files than if it's run in the default upstream build directory. I think I really need to switch to a different build system to fix this, so that would probably take a few days :-(. -- 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/53e12903.7050...@realh.co.uk
Bug#756634: RFS: roxterm/2.9.1-1
On 04/08/14 07:11, Vincent Cheng wrote: On Thu, Jul 31, 2014 at 10:15 AM, Eriberto Mota eribe...@debian.org wrote: 1. Update DH from 7 to 9. Thanks for the feedback. I'm not quite sure what that bit means though. Do I just need to update Build-Depends to debhelper (= 9)? -- 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/53df9408.4020...@realh.co.uk
Bug#756634: RFS: roxterm/2.9.1-1
On 04/08/14 07:11, Vincent Cheng wrote: On Thu, Jul 31, 2014 at 10:15 AM, Eriberto Mota eribe...@debian.org wrote: - Allow the content modification of the po/roxterm.pot. To make it, create the file debian/source/options with this content[1]: extend-diff-ignore = ^po/roxterm.pot$ I did that, but I get this warning: dpkg-source: warning: --extend-diff-ignore:=(^|/)po/roxterm.pot$ is not a valid option for Dpkg::Source::Package::V3::Quilt and the package still can't be built twice from the same directory. Besides roxterm.pot it also detects changes to the po/*.po files. I think these get updated with a new POT-Creation-Date header. I can probably find a way to prevent these files from being updated with no changes other than date stamps, but I'm puzzled why extend-diff-ignore doesn't work with format 3.0 (quilt). I can't find any information as to why not. Is there another way to make it ignore these? -- 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/53dfdddc.7030...@realh.co.uk
Bug#756634: RFS: roxterm/2.9.1-1
Package: sponsorship-requests Severity: normal [important for RC bugs, wishlist for new packages] Dear mentors, I am looking for a sponsor for my package roxterm * Package name: roxterm * Version : 2.9.1-1 * Upstream Author : Tony Houghton h...@realh.co.uk * URL : http://roxterm.sourceforge.net * License : GPL-2+, LGPL-3+ * Section : x11 It builds those binary packages: roxterm - Multi-tabbed GTK+/VTE terminal emulator - virtual package for GTK3 roxterm-common - Multi-tabbed GTK+/VTE terminal emulator - common files roxterm-gtk2 - Multi-tabbed GTK+/VTE terminal emulator - GTK2 version roxterm-gtk2-dbg - Debugging symbols for GTK2 version of roxterm roxterm-gtk3 - Multi-tabbed GTK+/VTE terminal emulator - GTK3 version roxterm-gtk3-dbg - Debugging symbols for GTK3 version of roxterm 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_2.9.1-1.dsc More information about hello can be obtained from http://www.example.com. Changes since the last upload: roxterm (2.9.1-1) unstable; urgency=low * Changed default GTK colour scheme: + Make bold black (LP: #1340721). + Don't set cursor colour due to https://bugzilla.gnome.org/show_bug.cgi?id=695011. * Add support for launching ssh from matching URIs (based on a patch by Karl E. Jorgensen). * Support popular SCM URIs (copy to clipboard only). * Fixed background transparency support for recent versions of vte. * Don't crash trying to use a copy of an empty profile (Closes: #752253). * Allow Shortcuts files to be reloaded and edited as text. * Override --tab to false if no match for --title. * debian/control: Added Build-Depends on imagemagick, itstool. * debian/copyright: Updated year. * Support XDG AppData spec. * Corrected profile editor page selection when background options are disabled (doesn't affect Debian). * Changed keyboard shortcut for Find Next to avoid clash with New Window. * Fixed wrapping of some dialog labels. * Exclude logo source xcf (gimp) file from installation. * Added GTK VTE version summary to About dialog. -- Tony Houghton h...@realh.co.uk Thu, 31 Jul 2014 15:34:01 +0100 Regards, Tony Houghton -- 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/53da5e9d.8090...@realh.co.uk
Bug#739089: Subject: RFS: roxterm/2.8.2-1
Package: sponsorship-requests Severity: normal [important for RC bugs, wishlist for new packages] Dear mentors, I am looking for a sponsor for my package roxterm * Package name: roxterm Version : 2.8.2-1 Upstream Author : [fill in name and email of upstream] * URL : [fill in URL of upstreams web site] * License : [fill in] Section : x11 It builds these binary packages: roxterm - Multi-tabbed GTK+/VTE terminal emulator - virtual package for GTK3 roxterm-common - Multi-tabbed GTK+/VTE terminal emulator - common files roxterm-gtk2 - Multi-tabbed GTK+/VTE terminal emulator - GTK2 version roxterm-gtk2-dbg - Debugging symbols for GTK2 version of roxterm roxterm-gtk3 - Multi-tabbed GTK+/VTE terminal emulator - GTK3 version roxterm-gtk3-dbg - Debugging symbols for GTK3 version of roxterm 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_2.8.2-1.dsc More information about roxterm can be obtained from http://roxterm.sourceforge.net Changes since the last upload: * Re-enabled deprecated background options for now. A few people were upset about these options being disabled so I decided to keep them enabled until a vte without ther support arrives, or is about to arrive, in Debian. Regards, Tony Houghton -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140215192110.0a667...@realh.co.uk
Re: Bug#735598: marked as done (RFS: roxterm/2.8.1-1)
Thanks for sponsoring it. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140118142157.427e1...@realh.co.uk
Bug#735598: RFS: roxterm/2.8.1-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package roxterm * Package name: roxterm * Version : 2.8.1-1 * Upstream Author : Tony Houghton h...@realh.co.uk * URL : http://roxterm.sourceforge.net * License : GPL-2+ * Section : x11 It builds these binary packages: roxterm- Multi-tabbed GTK+/VTE terminal emulator - virtual package for GTK3 roxterm-common - Multi-tabbed GTK+/VTE terminal emulator - common files roxterm-gtk2 - Multi-tabbed GTK+/VTE terminal emulator - GTK2 version roxterm-gtk2-dbg - Debugging symbols for GTK2 version of roxterm roxterm-gtk3 - Multi-tabbed GTK+/VTE terminal emulator - GTK3 version roxterm-gtk3-dbg - Debugging symbols for GTK3 version of roxterm 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_2.8.1-1.dsc Changes since the last upload: * Added dbg packages. * Recommends: dbus-x11. * Updated Standards-Version. * Support signature check in debian/watch. * New upstream version: + Use text instead of online SourceForge logo in HTML docs (privacy issue). + Fixed crashes/warnings when searching terminals. + More memory leak fixes in menus. + Don't support terminal background options deprecated by vte. Regards, Tony Houghton -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140116185511.11a4e...@realh.co.uk
Add debug files to existing packages or add -dbg packages?
ROXTerm is going to need a new release soon and I'd like to include debugging symbols. It currently has binary packages roxterm-common (data files), roxterm-gtk3 (executables linked with GTK3 etc) and roxterm-gtk2 (linked with GTK2 etc). Should debugging symbols always be put in separate -dbg packages or can they be added to existing packages? If there is a choice I'm leaning towards the latter. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140112182535.10829...@realh.co.uk
Re: Bug#710835: RFS: roxterm/2.7.1-1
On Sun, 2 Jun 2013 18:09:46 -0300 Eriberto eribe...@eriberto.pro.br wrote: Hey! Your package has lintian warnings. Please, see http://bit.ly/lintian You must add a message about transition from experimental to unstable in debian/changelog. I suggest: Uploaded to unstable, because lintian will search by to unstable in changelog. There is such a message but lintian missed it because it didn't include to unstable. I thought it would be OK to ignore the warning because it's pedantic and there is a message about experimental/unstable. I would have fixed it, but I didn't see the warning until after I'd uploaded it (does debuild not enable pedantic by default or did I just miss it?) and set tags upstream etc, thinking everything was OK. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130603130030.2bcfc...@realh.co.uk
Bug#710835: RFS: roxterm/2.7.1-1
On Sun, 2 Jun 2013 18:09:46 -0300 Eriberto eribe...@eriberto.pro.br wrote: Hey! Your package has lintian warnings. Please, see http://bit.ly/lintian You must add a message about transition from experimental to unstable in debian/changelog. I suggest: Uploaded to unstable, because lintian will search by to unstable in changelog. There is such a message but lintian missed it because it didn't include to unstable. I thought it would be OK to ignore the warning because it's pedantic and there is a message about experimental/unstable. I would have fixed it, but I didn't see the warning until after I'd uploaded it (does debuild not enable pedantic by default or did I just miss it?) and set tags upstream etc, thinking everything was OK. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130603131500.08c58...@realh.co.uk
Bug#710835: RFS: roxterm/2.7.1-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my updated package roxterm * Package name: roxterm Version : 2.7.2-1 Upstream Author : Tony Houghton h...@realh.co.uk * URL : http://roxterm.sourceforge.net * License : GPL2+ Section : x11 It builds these binary packages: roxterm - Multi-tabbed GTK+/VTE terminal emulator - virtual package for GTK3 roxterm-common - Multi-tabbed GTK+/VTE terminal emulator - common files roxterm-gtk2 - Multi-tabbed GTK+/VTE terminal emulator - GTK2 version roxterm-gtk3 - Multi-tabbed GTK+/VTE terminal emulator - GTK3 version 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_2.7.2-1.dsc More information about roxterm can be obtained from http://roxterm.sourceforge.net Changes since the last upload: * New upstream release: + Plugged memory leak. + Fixed l10n. + Worked around race condition when using --tab. + Height option default is now consistent in term and profile editor. * Target unstable again now Wheezy is released. There is a lintian warning because I didn't use the right key phrase in the changelog about moving back from experimental to unstable. It's a pedantic warning which I didn't discover until after I uploaded, and the change is documented, so I hope it's OK. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130602215320.1027e...@realh.co.uk
Bug#704494: RFS: roxterm/2.7.1-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my updated package roxterm * Package name: roxterm Version : 2.7.1-1 Upstream Author : Tony Houghton h...@realh.co.uk * URL : http://roxterm.sourceforge.net * License : GPL2+ Section : x11 It builds these binary packages: roxterm - Multi-tabbed GTK+/VTE terminal emulator - virtual package for GTK3 roxterm-common - Multi-tabbed GTK+/VTE terminal emulator - common files roxterm-gtk2 - Multi-tabbed GTK+/VTE terminal emulator - GTK2 version roxterm-gtk3 - Multi-tabbed GTK+/VTE terminal emulator - GTK3 version 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_2.7.1-1.dsc More information about roxterm can be obtained from http://roxterm.sourceforge.net Changes since the last upload: * Enable translations even if incomplete. + debian/control: Build-Depends on po4a and gettext. + debian/roxterm-common.install: Add translation files. * Use GdkRGBA instead of GdkColor when possible. * Added option to bind a colour scheme to a profile (Closes: #684294). * Escape quotes in URLs (Closes: #696917). * Added optional new tab button (Closes: #665840). * Parse a single argument to -e in case it contains a space-separated executable and arguments. * Fixed Files/Filer option by responding to changes of widget content. * Support python 2.4 in build by not using with statement. * Exclude from end of URL match. * Added half page scrolling actions (patch by Jim Paris). * Added bold and dim colour options. * Changed default select-by-word pattern (ameliorates #688025). * Fixed misinterpretation of --tab-name as --tab. * debian/control: git repo has moved. * debian/rules: Use git to generate version info etc if .git is present. * debian/changelog: Target experimental due to wheezy pre-release freeze. * lintian overrides for xpm files were apparently obsolete; removed. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402001720.1b228...@realh.co.uk
Changelog etiquette for upstream patches
As both the upstream and Debian maintainer for roxterm I'm unsure what to do about documenting a patch that was submitted by someone else to the upstream tracker. I've applied the patch upstream but don't know the best way to credit the author in debian/changelog. Include his name? Not his email address I think because of spam/privacy issues. Perhaps just add the patch's URL? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130301155424.5d4e2624@janet.centauri
Re: Changelog etiquette for upstream patches
On Fri, 1 Mar 2013 11:03:50 -0500 Ryan Kavanagh r...@debian.org wrote: Hi Tony, On Fri, Mar 01, 2013 at 03:54:24PM +, Tony Houghton wrote: As both the upstream and Debian maintainer for roxterm I'm unsure what to do about documenting a patch that was submitted by someone else to the upstream tracker. I would document this information using a DEP-3 header[0], in particular, the Author and Origin fields. If it's linked to an upstream bug report, link to that bug report as well. Author: John Doe j...@example.com Origin: link to patch applied in upstream VCS Bug: http://upstream.bugtrackerurl/1275270 I've applied the patch upstream but don't know the best way to credit the author in debian/changelog. Include his name? I would either write * Apply upstream patch fixing frobnicator, 02_fix_frob.diff (Closes: #245274) letting people look at the patch header for credits, or * Apply upstream patch by John Doe fixing frobnicator, 02_fix_frob.diff (Closes: #245274) The thing is there isn't a separate patch in the debian packaging or elsewhere in the pending release tarball because I've applied the patch to the code upstream. The bug is upstream too, not in Debian. So including the URL for the upstream bug looks nearest to your suggestion. Luckily sourceforge bug URLs are a more reasonable size since the last upgrade, and/or I can use their URL shortening service. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130301220552.36863496@janet.centauri
Re: Getting involved as a maintainer
On Fri, 1 Mar 2013 14:02:44 -0300 Saulo Moraes sa...@gmx.com wrote: Hi, I would like to contribute with Debian, I am a professional developer but will be better to start working as a maintainer. After check the Debian Packages that Need Lovin' I have choose the samsung-tools as my first experience and as I know I littler about it after install in my laptop... Well I have reply the request for packaging http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=599788; but no answer yet... So my quest is may someone help me to get involved? How or Who can support me in my first package upload ? I am reading the documentation available but I think is time to start in practice. This has been packaged for Ubuntu in a PPA, so that would probably be a good starting point: https://launchpad.net/~voria/+archive/ppa. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130301221147.405e775a@janet.centauri
Migrating from experimental to unstable
Suppose I have a new version of my package available and I upload it to experimental during a freeze. After the freeze I'd like that new version in unstable, but I haven't made any changes in the meantime. Is there a migration process from experimental to unstable, or is it normal to bump the debian revision (because the changelog should document the move between unstable and experimental and not hide that from history I guess) and upload a new version with no other changes? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130118214604.2d27aef1@tiber
Re: Bug#670176:
On Mon, 3 Dec 2012 13:27:15 +0100 Nick Andrik nick.and...@gmail.com wrote: The problem is that I ran dput yesterday but the package dis not appear in my packages on mentor (I didn't even receive an email). I guess it got stuck somewhere in the incoming queue. I read somewhere that it takes 6 hours to get unstuck, but still no email from yesterdays' upload and I get Upload failed: 403 Forbidden when I run dput again. Any idea on how to fix this? I think this can happen if the first upload is partially successful; HTTP won't let you overwrite the file that's already there. Try reconfiguring dput to use FTP instead. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121203133615.68d8e339@roland
Easy bugfix for roxterm: should it go into wheezy?
A bug has been found in roxterm: https://sourceforge.net/p/roxterm/bugs/88/. I wouldn't consider it a high priority but the fix is very trivial, just adding a single line of code. Should I release this for wheezy? If so, how do I go about it? Should I open a debian bug and give it a certain priority or tag? Do I have to add anything to my RFS? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121029152445.42a00335@roland
Bug#678552: RFS: roxterm/2.6.5-1
Pinging this. I guess it may already be too late to avoid some of the extra work needed to get it into testing after the freeze though :-(. On Fri, 22 Jun 2012 17:59:27 +0100 Tony Houghton h...@realh.co.uk wrote: Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package roxterm * Package name: roxterm Version : 2.6.5-1 Upstream Author : Tony Houghton h...@realh.co.uk URL : http://roxterm.sourceforge.net License : GPL2+ Section : x11 It builds those binary packages: * roxterm - Multi-tabbed GTK+/VTE terminal emulator - virtual package for GTK3 * roxterm-common - Multi-tabbed GTK+/VTE terminal emulator - common files * roxterm-gtk2 - Multi-tabbed GTK+/VTE terminal emulator - GTK2 version * roxterm-gtk3 - Multi-tabbed GTK+/VTE terminal emulator - GTK3 version 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_2.6.5-1.dsc More information about roxterm can be obtained from http://roxterm.sourceforge.net Changes since the last upload: * Inherit cwd correctly when being launched from a command (fixes regression in 2.6.4). This fixes a bug reported upstream so I'm keen for the update to make it into wheezy's release. Regards, Tony Houghton -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120629155701.5597038d@junior
Bug#678552: RFS: roxterm/2.6.5-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package roxterm * Package name: roxterm Version : 2.6.5-1 Upstream Author : Tony Houghton h...@realh.co.uk URL : http://roxterm.sourceforge.net License : GPL2+ Section : x11 It builds those binary packages: * roxterm - Multi-tabbed GTK+/VTE terminal emulator - virtual package for GTK3 * roxterm-common - Multi-tabbed GTK+/VTE terminal emulator - common files * roxterm-gtk2 - Multi-tabbed GTK+/VTE terminal emulator - GTK2 version * roxterm-gtk3 - Multi-tabbed GTK+/VTE terminal emulator - GTK3 version 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_2.6.5-1.dsc More information about roxterm can be obtained from http://roxterm.sourceforge.net Changes since the last upload: * Inherit cwd correctly when being launched from a command (fixes regression in 2.6.4). This fixes a bug reported upstream so I'm keen for the update to make it into wheezy's release. Regards, Tony Houghton -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120622175927.0a014f43@tiber
Re: How to build a source tarball that includes symbolic links?
On Thu, 7 Jun 2012 05:42:56 +0200 David Lindelöf linde...@ieee.org wrote: The source of my project includes symbolic links to other source trees (notably, the CppUTest framework and a library used by several of our projects). When I call `dpkg-buildpackage` to build a debian package out of my project, I've found that `dpkg-source` will not follow the symbolic links and leaves them as empty files in the source's tarball. As a result, they cannot be used by `pbuilder` to build the package for another distribution. As a *temporary* workaround could you use hard links instead of symbolic? You'd have to link every file individually though, hard links aren't supported for directories. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120607145215.67da1a39@junior
Re: How to build a source tarball that includes symbolic links?
On Thu, 7 Jun 2012 16:19:05 +0200 David Lindelöf linde...@ieee.org wrote: As a *really temporary* workaround, is there a way I could have the build system copy over the files to their proper locations, just for building the package? And then delete them and reinstate the symbolic links? Yes, in a Makefile you could do something like this: pre-package: rm CppUTest mkdir CppUTest ln ../../CppUTest/* CppUTest/ # or cp if they're on a different file system or if you # want to handle recursive directories easily (cp -r) post-package: rm -r CppUTest ln -s ../../CppUTest CppUTest -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120607162339.711d8bc8@junior
Bug#674961: RFS: roxterm/2.6.4-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package roxterm * Package name: roxterm Version : 2.6.4-1 Upstream Author : Tony Houghton h...@realh.co.uk * URL : http://roxterm.sourceforge.net * License : GPL2+ Section : x11 It builds teose binary packages: roxterm - Multi-tabbed GTK+/VTE terminal emulator - virtual package for GTK3 roxterm-common - Multi-tabbed GTK+/VTE terminal emulator - common files roxterm-gtk2 - Multi-tabbed GTK+/VTE terminal emulator - GTK2 version roxterm-gtk3 - Multi-tabbed GTK+/VTE terminal emulator - GTK3 version 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_2.6.4-1.dsc Changes since the last upload: * Check for valid cwd before using it to spawn processes (Closes: #674843). * Added System to Categories in desktop file. * New version of maitch which supports implicit rules only and makes better use of commonly used flags. * debian/rules: Use appropriate flags from dpkg-buildflags. Regards, Tony Houghton -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120528192730.2e1a719c@tiber
Bug#671651: RFS: roxterm/2.6.3-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package roxterm * Package name: roxterm Version : 2.6.3-1 Upstream Author : Tony Houghton h...@realh.co.uk * URL : http://roxterm.sourceforge.net * License : GPL2+ Section : x11 It builds teose binary packages: roxterm - Multi-tabbed GTK+/VTE terminal emulator - virtual package for GTK3 roxterm-common - Multi-tabbed GTK+/VTE terminal emulator - common files roxterm-gtk2 - Multi-tabbed GTK+/VTE terminal emulator - GTK2 version roxterm-gtk3 - Multi-tabbed GTK+/VTE terminal emulator - GTK3 version 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_2.6.3-1.dsc Changes since the last upload: * Removed disused ..._get_*_under_pointer funcs. * Replaced several instances of Gtk*Box with GtkGrid. * Fixed VtePty life cycle (Closes: #671160). Regards, Tony Houghton -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120505170620.7f06d2d1@junior
Re: Bug#669401: RFS: roxterm/2.6.2-1 (was 2.6.1-1)
retitle 669401 RFS: roxterm/2.6.2-1 thanks The Ubuntu PPA builder for lucid uncovered a backwards compatibility bug so I've updated upstream and replaced the package so that uscan won't complain about its not being the latest upstream. dget -x http://mentors.debian.net/debian/pool/main/r/roxterm/roxterm_2.6.2-1.dsc On Thu, 19 Apr 2012 16:03:13 +0100 Tony Houghton h...@realh.co.uk wrote: I am looking for a sponsor for my package roxterm * Package name: roxterm Version : 2.6.1-1 Upstream Author : Tony Houghton h...@realh.co.uk URL : http://roxterm.sourceforge.net License : GPL2+ Section : x11 It builds those binary packages: * roxterm - Multi-tabbed GTK+/VTE terminal emulator - virtual package for GTK3 * roxterm-common - Multi-tabbed GTK+/VTE terminal emulator - common files * roxterm-gtk2 - Multi-tabbed GTK+/VTE terminal emulator - GTK2 version * roxterm-gtk3 - Multi-tabbed GTK+/VTE terminal emulator - GTK3 version 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_2.6.1-1.dsc More information about roxterm can be obtained from http://roxterm.sourceforge.net Changes since the last upload: * Ensure vte widgets realized before reading xid (Closes: #663736). * Explicitly close pty when deleting a terminal. * Warnings apply to closing windows via menu (Closes: #664887). * Debian packaging now maintained in master branch again. * Changed close warning dialog buttons to Yes/No. * Honour login option when restoring a session (Closes: #663739). * Reread GdkWindow when re-mapping windows when compositing changes. * debian/watch: Corrected pcre syntax for uncaptured bz2/gz suffix. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120420201204.58203ecd@junior
Bug#669401: RFS: roxterm/2.6.1-1
Package: sponsorship-requests Severity: normal [important for RC bugs, wishlist for new packages] Dear mentors, I am looking for a sponsor for my package roxterm * Package name: roxterm Version : 2.6.1-1 Upstream Author : Tony Houghton h...@realh.co.uk URL : http://roxterm.sourceforge.net License : GPL2+ Section : x11 It builds those binary packages: * roxterm - Multi-tabbed GTK+/VTE terminal emulator - virtual package for GTK3 * roxterm-common - Multi-tabbed GTK+/VTE terminal emulator - common files * roxterm-gtk2 - Multi-tabbed GTK+/VTE terminal emulator - GTK2 version * roxterm-gtk3 - Multi-tabbed GTK+/VTE terminal emulator - GTK3 version 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_2.6.1-1.dsc More information about roxterm can be obtained from http://roxterm.sourceforge.net Changes since the last upload: * Ensure vte widgets realized before reading xid (Closes: #663736). * Explicitly close pty when deleting a terminal. * Warnings apply to closing windows via menu (Closes: #664887). * Debian packaging now maintained in master branch again. * Changed close warning dialog buttons to Yes/No. * Honour login option when restoring a session (Closes: #663739). * Reread GdkWindow when re-mapping windows when compositing changes. * debian/watch: Corrected pcre syntax for uncaptured bz2/gz suffix. Regards, Tony Houghton -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120419160313.5f9dccf3@tiber
Can't upload to mentors.debian.net
I can't upload my package (roxterm) to mentors.debian.net. I've set up my .dput.cf as suggested at http://mentors.debian.net/intro-maintainers. If I use the HTTP method I get 403 Forbidden as soon as it tries to upload the .dsc file. The FTP method has partially succeeded but always times out (errno 110) before completing the entire set of files. Perhaps the fact that the .dsc did upload is the cause of the 403 errors because I don't have permission to overwrite existing files? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120418162002.048f3e84@tiber
Re: Can't upload to mentors.debian.net
On Wed, 18 Apr 2012 18:52:47 +0200 Nicolas Dandrimont nicolas.dandrim...@crans.org wrote: Le 18/04/2012 à 17:20, Tony Houghton h...@realh.co.uk écrivit : I can't upload my package (roxterm) to mentors.debian.net. [Snip] You can also poke support@m.d.n if the upload still fails (the files are gone, so it shouldn't). Thanks. I've managed to upload it by HTTP now, although the server still seems very sluggish. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120418200507.1519d560@tiber
Best use of bug tracker for a complicated situation
I maintain roxterm. The source package of that name generates a number of binary packages: roxterm-common, roxterm-gtk2, roxterm-gtk3 and roxterm (a virtual package depending on roxterm-gtk3). A user has reported 2 bugs with slightly different symptoms, one for roxterm-gtk2 and one for roxterm-gtk3. They're actually the same bug, applying to both, and I think also to old versions when there was only one binary package, roxterm. What's the best way to show the bugs affect all three? I used: affects n roxterm roxterm-gtk2 roxterm-gtk3 Would it be better to reassign them to the source package? In my control message how would I distinguish that from the binary packages of the same name? By appending :src? I reassigned them both to roxterm-gtk3 and then tried to merge them, but the merge is failing with what looks like an internal error involving an array where it expected a hash (reported verbatim to owner@bdo). So far I've been copying my comments to both bugs. Meanwhile the user has added a comment to both which looks like there might be a new, separate bug. So I reckon I should forget the merge, continue to discuss the first problem in one of the reports and retitle the other report to reflect the possible new problem. Agreed? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120319173745.5a8ec8ea@junior
Bug#661389: RFS: roxterm/2.5.3-1 (was 2.5.2-1)
The latest version of this package is now 2.5.3-1: * Package name: roxterm Version : 2.5.3-1 Upstream Author : Tony Houghton h...@realh.co.uk * URL : http://roxterm.sourceforge.net * License : GPL-2+, LGPL-3+ Section : x11 It builds these binary packages: roxterm- Multi-tabbed GTK+/VTE terminal emulator - virtual package for GTK3 roxterm-common - Multi-tabbed GTK+/VTE terminal emulator - common files roxterm-gtk2 - Multi-tabbed GTK+/VTE terminal emulator - GTK2 version roxterm-gtk3 - Multi-tabbed GTK+/VTE terminal emulator - GTK3 version 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_2.5.3-1.dsc Changes since the last upload: * New upstream version: + New windows created for dragged-out tabs use configured tab position setting. [2.5.2-1]: * New upstream version: + maitch.py: Reorder args in compiler checks: libs must come after source on some systems. + More flexible close window/tab warnings. + Added global option to use dark theme. + Revamped configlet (Configuration Manager). + --tab only reuses windows on current workspace unless overridden by --title. + SVG-derived pixmaps are included in release tarballs for convenience. + Option to use dark GTK theme variant. * debian/control: Removed imagemagick and librsvg2-bin from Build-Depends (see above). * Debian packaging now maintained with git-buildpackage. * debian/control: + Bump Standards-Version: 3.9.3. + Each binary package has a unique short description. * debian/copyright: New URL for Format. * Changed target back to unstable instead of experimental. I forgot that I should have merged the changes for 2.5.2-1 and 2.5.3-1, but AIUI that's only preferrable, not mandatory, it's uploaded now, and it will make it easier to update my Ubuntu PPA. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120311213033.3b720ecf@junior
Bug#661389: RFS: roxterm/2.5.2-1
On Sun, 26 Feb 2012 21:11:30 + Tony Houghton h...@realh.co.uk wrote: Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package roxterm * Package name: roxterm Version : 2.5.2-1 It's been almost 2 weeks since this RFS. Is there an official procedure for bumping RFS bugs, or am I doing that now? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120310153028.6b54dbf4@junior
Bug#661389: RFS: roxterm/2.5.2-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package roxterm * Package name: roxterm Version : 2.5.2-1 Upstream Author : Tony Houghton h...@realh.co.uk * URL : http://roxterm.sourceforge.net * License : GPL-2+, LGPL-3+ Section : x11 It builds these binary packages: roxterm- Multi-tabbed GTK+/VTE terminal emulator - virtual package for GTK3 roxterm-common - Multi-tabbed GTK+/VTE terminal emulator - common files roxterm-gtk2 - Multi-tabbed GTK+/VTE terminal emulator - GTK2 version roxterm-gtk3 - Multi-tabbed GTK+/VTE terminal emulator - GTK3 version 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_2.5.2-1.dsc Changes since the last upload: * New upstream version: + maitch.py: Reorder args in compiler checks: libs must come after source on some systems. + More flexible close window/tab warnings. + Added global option to use dark theme. + Revamped configlet (Configuration Manager). + --tab only reuses windows on current workspace unless overridden by --title. + SVG-derived pixmaps are included in release tarballs for convenience. + Option to use dark GTK theme variant. * debian/control: Removed imagemagick and librsvg2-bin from Build-Depends (see above). * Debian packaging now maintained with git-buildpackage. * debian/control: + Bump Standards-Version: 3.9.3. + Each binary package has a unique short description. * debian/copyright: New URL for Format. * Changed target back to unstable instead of experimental. Regards, Tony Houghton -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120226211130.5a474285@tiber
Re: RFS: quickrdp
On Mon, 30 Jan 2012 07:42:23 +0100 Tobias Eliasson arnes...@gmail.com wrote: On 01/30/2012 12:13 AM, Jakub Wilk wrote: The default value for Locale telnet/Perl/SSH executable dialogs appears to be gnome-terminal. (??!) It launches a terminal for launching the actual executable. It's not restricted to using that, you may use whatever you wish there. My 2c: a Debian package should default to x-terminal-emulator when launching a terminal if it's desktop-agnostic. Or does XDG have a standard way to find the user's favourite terminal? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120130111837.4622b422@junior
Re: RFS: nbc (2.5 th try)
On Sat, 14 Jan 2012 07:32:46 +0800 Paul Wise p...@debian.org wrote: On Sat, Jan 14, 2012 at 4:46 AM, Slavko li...@slavino.sk wrote: Upstream Author : [fill in name and email of upstream] * URL : [fill in URL of upstreams web site] * License : [fill in] Try reading your emails before you send them. Could debexpo be updated to fill those in? The old mentors template generator used to. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120114000558.413a6256@junior
Re: RFS: roxterm 2.4.2-1 (was 2.4.1-1)
On Thu, 12 Jan 2012 20:52:58 +0800 Kan-Ru Chen kos...@debian.org wrote: Unfortunately there is still one missing build-dep: librsvg2-bin. I have uploaded 2.4.2-1 with this fixed, please fix it in your repository as well :) OK, I've corrected that my end too. Thanks a lot. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120112171855.718a45f0@junior
Re: RFS: roxterm 2.4.2-1 (was 2.4.1-1)
On Fri, 06 Jan 2012 15:12:41 +0100 Tobias Frost t...@frost.de wrote: Am Donnerstag, den 05.01.2012, 13:30 + schrieb Tony Houghton: The debian packaging and upstream are in one repository and I didn't want the contents of the release tarball to be inconsistent with what's in the package. I would also have to change the way I use git tags to generate a version number dynamically. I do it that way: I use a dedicated git branch for the debian stuff, containing the the debian stuff (and the source, but source is not edited in this branch) The developement (on the source) is done in a different branch and whenever I want to make a debian package I just merge the latest source into the debian branch. That sounds like a good idea, I'll probably do it that way. This way your tricks with git-tags could still work. (Anyway, can you elaborate on this, as I am curious about this idea) When I'm about to do a release I tag it with the release version number. The build system uses git describe to generate a version number (with autoconf I did it in the bootstrap.sh by generating configure.ac from configure.ac.in, maitch does it in the configure phase), only converting from the format 2.4.0-1-g1234abcd to 2.4.0.1~g1234abcd. That way anything built between releases has a meaningful and uniquely identifying version number. I also use tags of the form x.y.0 when I add a new feature or set of features, so that versions with a .0 are testing versions for the next release x.y.1. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120107133650.0f0c2449@junior
Re: RFS: roxterm 2.4.2-1 (was 2.4.1-1)
On Thu, 05 Jan 2012 16:16:15 +0800 Thomas Goirand z...@debian.org wrote: On 01/05/2012 01:33 AM, Tony Houghton wrote: Unfortunately I just discovered a bug in the Build-Depends stanza, so please ignore version 2.4.1-1 and upload 2.4.2-1 instead. If that's an issue in the packaging, why did you need to upgrade from 2.4.1 to 2.4.2, and why didn't you just do a 2.4.1-2 instead? It's possible to get this sponsored, even if it wasn't in Debian before, your sponsor would just have to use the -sa flag when building to include the orig.tar.gz in the upload. The debian packaging and upstream are in one repository and I didn't want the contents of the release tarball to be inconsistent with what's in the package. I would also have to change the way I use git tags to generate a version number dynamically. I think I'll separate the debian packaging from upstream soon, it does seem more practical overall. But I still don't really understand how automated tools can find the upstream source as well as the packaging from the Vcs control fields when they're in separate repositories. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120105133015.0ad26b62@junior
RFS: roxterm 2.4.1-1
Dear mentors, I am looking for a sponsor for my package roxterm. * Package name: roxterm Version : 2.4.1-1 Upstream Author : Tony Houghton h...@realh.co.uk * URL : http://roxterm.sourceforge.net/ * License : GPL-2+ Section : x11 It builds those binary packages: roxterm- Multi-tabbed GTK+/VTE terminal emulator roxterm-common - Multi-tabbed GTK+/VTE terminal emulator roxterm-gtk2 - Multi-tabbed GTK+/VTE terminal emulator roxterm-gtk3 - Multi-tabbed GTK+/VTE terminal emulator 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_2.4.1-1.dsc The most significant change in this version is a change of build system, which I've commented about on the package page above. This change obviously means I've had to change debian/rules somewhat too. I would be glad if someone uploaded this package for me. Kind regards, Tony Houghton -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120104165849.69c08021@tiber
RFS: roxterm 2.4.2-1 (was 2.4.1-1)
Unfortunately I just discovered a bug in the Build-Depends stanza, so please ignore version 2.4.1-1 and upload 2.4.2-1 instead. I am looking for a sponsor for my package roxterm. * Package name: roxterm Version : 2.4.2-1 Upstream Author : Tony Houghton h...@realh.co.uk * URL : http://roxterm.sourceforge.net/ * License : GPL-2+ Section : x11 It builds those binary packages: roxterm- Multi-tabbed GTK+/VTE terminal emulator roxterm-common - Multi-tabbed GTK+/VTE terminal emulator roxterm-gtk2 - Multi-tabbed GTK+/VTE terminal emulator roxterm-gtk3 - Multi-tabbed GTK+/VTE terminal emulator 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_2.4.2-1.dsc The most significant change in this version is a change of build system, which I've commented about on the package page above. This change obviously means I've had to change debian/rules somewhat too. I would be glad if someone uploaded this package for me. Kind regards, Tony Houghton -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120104173318.63f857ea@tiber
Re: preserving user changes while managing configuration files
On Wed, 23 Nov 2011 11:53:14 +0100 Dennis van Dok denni...@nikhef.nl wrote: On 23-11-11 10:27, Joseph Gunn wrote: A popular way of accomplishing the task is to support configuration subdirectories It includes all configuration files in that directory. If you publish a name that you will _never_ use then people can add that one as they wish. I'm not sure I'm getting the gist of your suggestion; do you mean the use of /etc/mypackage/conf.d/ or some such? I'm afraid this would require some heavy patching of the upstream code for reading configuration files. Perhaps instead you could add a simple utility to make a master config file out of several snippets in a directory. I think quite a few packages do that. The only one I can think of just now is exim4 but that's probably not a very good example because it's complex. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2023143343.316f542c@junior
Re: leechcraft (closes ITP bug, 33 days have passed)
On Tue, 08 Nov 2011 23:23:06 +0200 Boris Pek tehnic...@yandex.ru wrote: This seems to be a bit excessive. There is no real use in having many tiny packages for every function; please keep in mind that this will make the Packages index even larger (which also affects users that do not even have the package installed). Hmm, I have not thought about such an effect. It's bad news. I will think that can I do to decrease number of packages. This will damage general idea unfortunately but it is really more important. For example, I think many of the leechcraft-azoth-* packages could be merged into a single package: they do not seem to be very large nor introduce large dependencies according to an build log I found on launchpad[1]. Yes, this is true. But its sub-plugins realise different communicating protocols. Of cause they can be disabled in settings dialog, users will not be able to remove unnecessary plugins completely. Also I will look to other similar software. Like kopete, pidgin, etc... gstreamer is also distributed with many plugins per package. I think that approach has more advantages than disadvantages compared to one package per plugin. For users that want to use most of the plugins, having them in individual packages will waste more disc space in package overheads than they'll save by only having the plugins they need. And installing/upgrading many small packages takes longer than one large one. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2009010101.38ab6cfa@tiber
Alternative dependencies
What should you do if you have a dependency which can either use one package or two (or more) different packages. For example, roxterm's man pages can be built either with xmltoman, xmlto or xsltproc, but xsltproc additionally requires docbook-xsl. I don't think control file syntax supports grouping of packages either side of a |, so how should I manage this in Build-Depends? Is the following correct? Build-Depends: xsltproc | xmltoman | xmlto, docbook-xsl | xmltoman | xmlto Or would it be better to choose one and stick to that for the sake of consistency? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111023195403.48bd597f@junior
Re: Alternative dependencies
On Sun, 23 Oct 2011 21:23:41 +0200 Michael Tautschnig m...@debian.org wrote: [...] Build-Depends: xsltproc | xmltoman | xmlto, docbook-xsl | xmltoman | xmlto This would be a correct rewrite to CNF, but ... Or would it be better to choose one and stick to that for the sake of consistency? ... there isn't much of a point doing it here for Build-Depends. The situation is definitely a different one for Depends, but for Build-Depends just go for one of the choices, in the interest of both consistency and simplicity. Which would you recommend? I'm leaning towards xmltoman. Although it depends on some perl packages they were all already installed when I installed it; I guess anything with dh already has a lot of perl stuff installed. xmltoman makes for a much simpler command than xsltproc. So does xmlto but it has a lot of dependencies that I don't normally have installed otherwise. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111024000309.6f83d9c5@junior
Re: berlios closing; where should my projects escape to?
On Tue, 18 Oct 2011 00:02:04 -0500 Paul Elliott pelli...@blackpatchpanel.com wrote: Perhaps this is offtopic, but there are so many packagers here, perhaps I can find an answer. Berlios is closing, I have two small projects, GPLed, that use subversion and publish tarballs, where should I go? I looked at sourceforge, but they are always sending me adds. Too comercial for my taste. tuxfamily.org provides VCS and web services etc for free software. Pros: * You can use your own domain. * Runs on OSS Cons: * No ready-made web applications, you have to set up your website entirely yourself. Some people may prefer that flexibility though. * No bug tracker and the web hosting doesn't include python, so you can't use trac. flyspray can be used though. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111021143117.44922e15@junior
Control file Vcs fields
I'm a bit confused about the Vcs fields in Control files. Many projects have the upstream code and debian packaging maintained separately and I'm not entirely sure what you're supposed to do with the Vcs fields in that case. Should they point to upstream or the packaging? How can tools, such as debcheckout, work properly if they can only fetch the packaging or upstream code, but not both? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111021151006.3738626a@junior
Re: dh --parallel (was: Re: RFS: lebiniou)
On Mon, 17 Oct 2011 12:02:04 +0200 Adam Borowski kilob...@angband.pl wrote: On Mon, Oct 17, 2011 at 12:31:06PM +0800, Paul Wise wrote: You might want to use dh --parallel. I really wonder why it's not debhelper's default. I understand, it can break old packages with buggy makefiles, but it'd be nice to have --parallel both in the examples and as compat 9 default. These days you can't get 1-way regular machines without looking deep, and even phones get more cores. Having package builds utilize only a small part of the machine is pretty ridiculous. I agree, but there's another big problem: autoconf. It runs far more tests than most projects need (especially when using glib which takes care of a large range of compatibility issues for you), and each run takes longer than the actual compilation with a modest 4 core CPU. When building roxterm I think I have to run configure 4 times: before making a tarball with make dist, at the start of debuild before it can make clean, then once for each version of gtk. On top of all that you often have to run bootstrap.sh first. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111017144128.75b22086@junior
Re: dh --parallel (was: Re: RFS: lebiniou)
On Mon, 17 Oct 2011 22:06:00 +0800 Paul Wise p...@debian.org wrote: On Mon, Oct 17, 2011 at 9:41 PM, Tony Houghton wrote: I agree, but there's another big problem: autoconf. It runs far more tests than most projects need (especially when using glib which takes care of a large range of compatibility issues for you), and each run takes longer than the actual compilation with a modest 4 core CPU. When building roxterm I think I have to run configure 4 times: before making a tarball with make dist, at the start of debuild before it can make clean, then once for each version of gtk. On top of all that you often have to run bootstrap.sh first. Best file a couple of bugs about that on autoconf upstream: Please implement autoreconf -jX Please implement ./configure -jX I don't think it's practical to add parallelism to autoconf. Parts of configure scripts depend on earlier tests etc and the syntax doesn't provide a way of specifying dependencies like make does. I think anything that tried to parallelise what configure does would be too complicated. Better to just replace it with something that keeps the number of tests to a minimum and is cleaner instead of bodging m4 and sh together. I think writing build scripts in a language like python is very nice (autoconf is too slow, let's use python, spot the irony :)) but I've found waf and scons don't really suit my needs. So I'm writing my own which combines python with a simple and flexible concept of make-like rules and dependencies. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111017153516.0a5208c1@tiber
Re: dh --parallel (was: Re: RFS: lebiniou)
On Mon, 17 Oct 2011 16:40:43 +0200 Mathieu Malaterre mathieu.malate...@gmail.com wrote: On Mon, Oct 17, 2011 at 4:35 PM, Tony Houghton h...@realh.co.uk wrote: I think writing build scripts in a language like python is very nice (autoconf is too slow, let's use python, spot the irony :)) but I've found waf and scons don't really suit my needs. So I'm writing my own which combines python with a simple and flexible concept of make-like rules and dependencies. cmake does support parallel builds. 2cts Do you mean in its (equivalent of) configure stage? cmake was on my shortlist too, but I decided not to commit to it because its documentation looked a little weak unless you're prepared to buy a book which is quite expensive, especially outside the US. Additionally, I think the fact that it works by generating makefiles would make it share some of the drawbacks that brings to automake. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111017170649.6873f551@tiber
Re: RFS: roxterm (updated package)
On Thu, 06 Oct 2011 23:37:04 +0800 Kan-Ru Chen kos...@debian.org wrote: Tony Houghton h...@realh.co.uk writes: I am looking for a sponsor for my package roxterm. Done. Thanks. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111006172431.0188f78b@junior
Re: RFS: roxterm (updated package)
On Wed, 5 Oct 2011 00:26:51 +0100 Tony Houghton h...@realh.co.uk wrote: On Sun, 2 Oct 2011 21:59:04 +0100 Tony Houghton h...@realh.co.uk wrote: I am looking for a sponsor for my package roxterm. * Package name: roxterm Version : 2.2.1-1 Hold that, I discovered corruption in the GtkBuilder definitions after release (looks like vi finger trouble!) so I'll have to upload a new version. Done. The new details for version 2.2.2-1 are: http://mentors.debian.net/package/roxterm dget -x http://mentors.debian.net/debian/pool/main/r/roxterm/roxterm_2.2.2-1.dsc -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111005200117.7502ea27@tiber
Re: RFS: roxterm (updated package)
On Sun, 2 Oct 2011 21:59:04 +0100 Tony Houghton h...@realh.co.uk wrote: I am looking for a sponsor for my package roxterm. * Package name: roxterm Version : 2.2.1-1 Hold that, I discovered corruption in the GtkBuilder definitions after release (looks like vi finger trouble!) so I'll have to upload a new version. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111005002651.16f0f7af@tiber
RFS: roxterm (updated package)
Dear mentors, I am looking for a sponsor for my package roxterm. * Package name: roxterm Version : 2.2.1-1 Upstream Author : Tony Houghton h...@realh.co.uk * URL : http://roxterm.sourceforge.net * License : GPL-2+ Section : x11 It builds those binary packages: roxterm- Multi-tabbed GTK+/VTE terminal emulator roxterm-common - Multi-tabbed GTK+/VTE terminal emulator roxterm-gtk2 - Multi-tabbed GTK+/VTE terminal emulator roxterm-gtk3 - Multi-tabbed GTK+/VTE terminal emulator 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_2.2.1-1.dsc I would be glad if someone uploaded this package for me. Kind regards, Tony Houghton -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111002210527.07847149@tiber
Re: mentors.debian.net moved to new hardware
On Thu, 22 Sep 2011 01:08:33 +0200 Arno Töll deb...@toell.net wrote: our (not so) old host running http://mentors.debian.net was replaced right before by shiny new hardware. For you, as user you shouldn't hopefully notice the switch. The new hardware is much more powerful and has plenty of disk space. Hence all problems with exhausted disk space and time-outing servers should not occur anymore. Does it include the new version of debexpo that was soon to be deployed? In particular I'm waiting for a bugfix to allow uploading to experimental. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110922145155.5faaa9b0@tiber.centauri
Rejected experimental package (was Re: RFS: roxterm (updated package))
On Tue, 13 Sep 2011 13:28:19 +0100 Tony Houghton h...@realh.co.uk wrote: I think releasing to experimental would be the best option at the moment, so I'll upload a new version later. I tried that and my package was rejected by m.d.n: You are not uploading to one of those Debian distributions: unstablestable-backports oldstable-backports stable-backports-sloppy oldstable-backports Is experimental now disallowed or might I have done something else wrong and triggered a misleading error message? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110915143040.6fd7e9cc@junior
Re: Rejected experimental package (was Re: RFS: roxterm (updated package))
On Thu, 15 Sep 2011 17:45:48 +0200 Arno Töll deb...@toell.net wrote: No need to do. I already fixed that a few days ago [1]. However I didn't merge our master branch to live (i.e. the deployment branch) yet. OK. Please post again when you do so I know when I can try again to upload roxterm. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110915174044.5cb1a931@tiber.centauri
Re: RFS: roxterm (updated package)
On Wed, 14 Sep 2011 12:44:03 +0200 Jakub Wilk jw...@debian.org wrote: * Kan-Ru Chen kos...@debian.org, 2011-09-14, 11:29: That is, more or less, what's happening, so I'll move the bug to libvte9. In case that takes a long time to fix should I manually override the dependency? Yes you can, just put the right version in Depends. This is an excellent recipe to make the Release Team hate you, though. However this means when building with older version of libvte one has to manually adjust the Depends field as well. Wait, you don't want to build your package against *older* versions. And if you even can do that, then your build-depends is broken. What is troublesome in such case is building against a *newer* version, with potentially different SONAME. That's why you should never put shared libraries you're linking against explicitly in Depends. If anything, use Breaks for this purpose. I agree, there's a stronger argument to leave roxterm alone than to try to work around someone else's bug. Anyone with access to roxterm 2.* should also easily be able to upgrade to unstable's vte. That said, #641123 really looks like a serious bug in vte. Should I upgrade the report, do you think? In any case it might be a good idea to mark it as affects roxterm. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110914124457.01d57fae@junior
Re: RFS: roxterm (updated package)
[Note: I'm not sure whether I should remove the personal addresses from
To/Cc, especially in George's case. Please let me know what you'd
prefer. I'm subscribed to the list so I don't need the Cc, but I'm not
bothered about receiving extra copies either.]
On Tue, 13 Sep 2011 10:23:05 +0800
Kan-Ru Chen kos...@debian.org wrote:
Tony Houghton h...@realh.co.uk writes:
On Mon, 12 Sep 2011 22:36:54 +0800
Kan-Ru Chen kos...@debian.org wrote:
You sure you want to upload to unstable, right? Asking because it
was previously uploaded to experimental.
I think so, yes. I didn't really intend to send the previous
version to experimental and wanted to go back to unstable to get
more feedback. However, there are some bugs which can't be solved
as simply as installing roxterm-gtk2 instead of roxterm-gtk3. As
long as these are Outstanding on the bug tracker that will stop
the testing package being updated won't it? I don't want it to be
difficult for anyone who finds version 2.x unusable to revert to
1.x.
The bug has to have severity set to critical, grave or serious. I
think the geometry issue is nearly grave (makes the package in
question unusable or mostly so). IMHO you might want to keep roxterm
pointed to roxterm-gtk2 until the bug was fixed, or enable the
workaround by default. Anyway this is your package, you decide :)
That's a bit tricky because the bug is in libgtk-3-0 and marked as
affects roxterm. It might not be considered as grave in that package
because it only affects a few applications (although they include
gnome-terminal) and when used with what's considered to be a
non-standard window manager.
I think releasing to experimental would be the best option at the
moment, so I'll upload a new version later.
I might also need some help with #641123. It's to do with
${shlibs:Depends} and being able to support a new feature in a
library where possible but also be buildable without the feature to
support older versions. Would it be better to ask on debian-devel
about that sort of thing?
${shlibs:Depends} should be set by debhelper to the minimum version
required by this package upon version information from the library at
build time. If you are using a feature that is only available after
libvte9 1:0.28.1-2 but the dependency says 'libvte9 (= 1:0.24.0)'
then it is a bug of libvte9 package.
That is, more or less, what's happening, so I'll move the bug to
libvte9. In case that takes a long time to fix should I manually
override the dependency?
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110913132819.0e809984@junior
Re: RFS: roxterm (updated package)
On Mon, 12 Sep 2011 22:36:54 +0800
Kan-Ru Chen kos...@debian.org wrote:
Hi Tony,
You sure you want to upload to unstable, right? Asking because it was
previously uploaded to experimental.
I think so, yes. I didn't really intend to send the previous version to
experimental and wanted to go back to unstable to get more feedback.
However, there are some bugs which can't be solved as simply as
installing roxterm-gtk2 instead of roxterm-gtk3. As long as these are
Outstanding on the bug tracker that will stop the testing package
being updated won't it? I don't want it to be difficult for anyone who
finds version 2.x unusable to revert to 1.x.
I might also need some help with #641123. It's to do with
${shlibs:Depends} and being able to support a new feature in a library
where possible but also be buildable without the feature to support
older versions. Would it be better to ask on debian-devel about that
sort of thing?
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110912183740.3bae3a04@junior
RFS: roxterm (updated package)
Dear mentors, I am looking for a sponsor for my package roxterm. * Package name: roxterm Version : 2.1.1-1 Upstream Author : Tony Houghton * URL : http://roxterm.sourceforge.net * License : GPL-3+ Section : x11 It builds these binary packages: roxterm- Multi-tabbed GTK+/VTE terminal emulator roxterm-common - Multi-tabbed GTK+/VTE terminal emulator roxterm-gtk2 - Multi-tabbed GTK+/VTE terminal emulator roxterm-gtk3 - Multi-tabbed GTK+/VTE terminal emulator 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_2.1.1-1.dsc I would be glad if someone uploaded this package for me. Kind regards, Tony Houghton -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110905204848.1b81ab3a@tiber.centauri
experimental or unstable
The last release of roxterm went to experimental instead of unstable. TBH I forgot that I'd changed it to experimental at some point, but after release I thought perhaps it's just as well because of the major changes. However, I think this has resulted in few users noticing the new version and I think it's reliable enough for unstable. There's a new release ready; should I switch back to unstable for it? You're probably thinking if I'm making a new release already it can't be that stable! But only one of the changes relates to something specific to roxterm 2, and it's to make a new feature optional rather than to fix a bug https://sourceforge.net/tracker/?func=detailaid=3365527group_id=124080atid=698431. It also closes a bug in previous unstable releases (#639687). -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110903163211.322e1742@tiber.centauri
Re: RFS: roxterm (updated package)
On Sun, 28 Aug 2011 18:12:30 +0200 Adam Borowski kilob...@angband.pl wrote: Does roxterm-gtk3 have any functionality -gtk2 doesn't have? Unlike QT/GTK, there isn't a big difference there and I quite fail to see the reason to have both. It's a library rather than support for a whole environment, you need to upgrade at some time but I guess it will be half a decade before anyone says a word about removing gtk2. It does have a little advantage of a resize grip under the scrollbar - it can be quite hard to grab skinny window borders sometimes, especially with a touchpad. But mainly I just like everything to be modern and want to make sure the GTK3 version gets well-proven. Thus, if there's a bug but no goodies, you could stick with gtk2 for now. And there's a lot of time before wheezy freezes, so there's a fat chance the bug will be fixed, saving us two transitions (roxterm - roxterm-gtk*, roxterm-gtk* - roxterm). I wouldn't be surprised if #632403 outlives Wheezy's testing phase. I'm thinking of keeping both versions in temrs of years rather than months anyway. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110829131800.10d18492@junior
Re: RFS: roxterm (updated package)
On Mon, 29 Aug 2011 07:47:15 +0800 Kan-Ru Chen kos...@debian.org wrote: Tony Houghton h...@realh.co.uk writes: Yes, this is a known bug (#632403) and that's the main reason I'm still providing a gtk2 package too. As soon as it's uploaded I'll mark the bug as affecting roxterm-gtk3. I should probably have mentioned that in my RFS (although I did discuss the bug and splitting the package on debian-mentors first), so I'm Cc-ing this back to the list. Uploaded. Thanks. I've updated the bug as affecting roxterm-gtk3. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110829182244.2a3522fd@tiber.centauri
Re: RFS: roxterm (updated package)
On Sun, 28 Aug 2011 22:50:46 +0800 Kan-Ru Chen kos...@debian.org wrote: Only one problem when I tested the package. The gtk3 version, the terminal window shrinks its width when I try to move it around. I don't know if it's because of my window manager (awesome) or it also appears on other environment. If you cannot reproduce this, I can upload it first for wider test :) Yes, this is a known bug (#632403) and that's the main reason I'm still providing a gtk2 package too. As soon as it's uploaded I'll mark the bug as affecting roxterm-gtk3. I should probably have mentioned that in my RFS (although I did discuss the bug and splitting the package on debian-mentors first), so I'm Cc-ing this back to the list. signature.asc Description: PGP signature
RFS: roxterm (updated package)
Dear mentors, I am looking for a sponsor for my package roxterm. * Package name: roxterm Version : 2.0.1-1 Upstream Author : Tony Houghton h...@realh.co.uk * URL : http://roxterm.sourceforge.net/ * License : GPL-3 Section : x11 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_2.0.1-1.dsc ROXTerm is an advanced terminal emulator based on VTE. This version will need a more thorough review than normal because it now generates multiple binary packages so that users can choose between GTK+3 and GTK+2 versions. I would be glad if someone uploaded this package for me. Kind regards, Tony Houghton -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110821175313.3675d713@tiber.centauri
Re: Solving lintian warnings for multi-package roxterm
On Thu, 18 Aug 2011 13:51:11 +0100 Tony Houghton h...@realh.co.uk wrote: On Thu, 18 Aug 2011 10:41:33 +0200 David Kalnischkies kalnischk...@gmail.com wrote: [Snip] I'd rather keep the name roxterm for the GTK3 version if that's OK. I don't really want the main package to be named after a library dependency and have to relegate roxterm to a dummy package. I think perhaps I'd better use a dummy package after all, because the GTK3 and GTK2 versions should Conflict with each other, and having one of them with the same name as the old package makes that a bit awkward and I'd be in danger of being beaten up by David :-). Bonus: With my APT hat on i want to add that i will beat the hell out of you if you try to remove the old package with an unversioned Breaks/Conflicts. That is a dist-upgrade nightmare as it does what the maintainer intended only in a subset of situations and in all others the opposite will happen (= no upgrade) - and before someone adds Provides to the list: Remember that dependencies on Provides need to be unversioned. http://wiki.debian.org/Renaming_a_Package says that where one of the new packages Provides the old name it isn't enough for apt to automatically find the correct package to upgrade to (and I can see that if more than one provides it, as would be the case with roxterm, it would be impossible to choose automatically). If the dummy roxterm has: Depends: roxterm-gtk3 | roxterm-gtk2 (plus versions) will that make apt automatically pick roxterm-gtk3 or would I have to make it roxterm-gtk3 only and roxterm-gtk2 users have to uninstall the dummy package? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110819134235.53b32aef@junior
Re: Solving lintian warnings for multi-package roxterm
On Thu, 18 Aug 2011 10:41:33 +0200 David Kalnischkies kalnischk...@gmail.com wrote: On Thu, Aug 18, 2011 at 01:39, Tony Houghton h...@realh.co.uk wrote: package too, eg to roxterm-gtk3. In the latter case would adding Replaces: roxterm cause it to automatically replace roxterm at apt-get upgrade (or only dist-upgrade?) or would I have to make a meta-package? No. 'Replaces: A' is just a hint for dpkg that some (or _maybe_ all) files of package A are replaced with files from your package. (d-policy §7.6 [0]) Especially, this doesn't say anything about the functionality! Some hints on how to correctly rename a package can be found in the wiki [1]. I'd rather keep the name roxterm for the GTK3 version if that's OK. I don't really want the main package to be named after a library dependency and have to relegate roxterm to a dummy package. Bonus: With my APT hat on i want to add that i will beat the hell out of you if you try to remove the old package with an unversioned Breaks/Conflicts. That is a dist-upgrade nightmare as it does what the maintainer intended only in a subset of situations and in all others the opposite will happen (= no upgrade) - and before someone adds Provides to the list: Remember that dependencies on Provides need to be unversioned. Don't worry, I can easily see that abusing Conflicts like that would be stupid :-). Oh, and regarding the name as is: What does upstream intend: Do they treat gtk2 as legacy and will remove support in the long-run or do they want to support it for… lets say 2 years at least? I am upstream. I don't plan to drop gtk2 support soon, especially not before #632403 is resolved or I find a satisfactory workaround. But eventually I suppose gtk2 will be very much a legacy thing and only be used by poorly maintained packages (I can imagine that being at least 2 years away though) and then it will be advantageous to remove a lot of #if... blocks and configure checks - not just for GTK2 vs 3 but for features that only became available midway through gtk2's and vte's lives. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110818135111.249202cd@junior
Solving lintian warnings for multi-package roxterm
I've split roxterm in to three packages: roxterm-legacy: binaries compiled and linked with GTK2 roxterm: binaries compiled and linked with GTK3 roxterm-common: All the other files roxterm-legacy and roxterm Conflict with each other and both depend on roxterm-common. I've got 3 lintian warnings: W: roxterm-legacy: menu-icon-missing usr/share/pixmaps/roxterm.xpm W: roxterm: menu-icon-missing usr/share/pixmaps/roxterm.xpm W: roxterm-common: desktop-command-not-in-package usr/share/applications/roxterm.desktop roxterm Should I solve these by duplicating the offending files in roxterm-legacy and roxterm, or keep common copies in roxterm-common and add lintian overrides? Also, roxterm-common currently only Recommends: roxterm | roxterm-legacy. But I think I should make that Depends, especially if I override that last warning. Policy says it is possible, but should be avoided if possible. Avoidance is possible, but a mutual dependency seems the better option to me in this case. Agreed? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110817211944.00634abc@junior
Re: Solving lintian warnings for multi-package roxterm
On Thu, 18 Aug 2011 01:30:55 +0300 Andrew O. Shadoura bugzi...@tut.by wrote: On Wed, 17 Aug 2011 21:19:44 +0100 Tony Houghton h...@realh.co.uk wrote: roxterm-legacy: binaries compiled and linked with GTK2 roxterm: binaries compiled and linked with GTK3 roxterm-common: All the other files An off-topic question: why've you chosen this naming scheme? Why 'legacy'? In particular, I'm not going to switch to GTK+3 any time soon, and guess I'm not alone, so it can't be legacy, I think. I'm glad you asked TBH, because I wasn't happy about that name either. I think I might use the name roxterm-gtk2 instead. To make it easier for people who want to stay with GTK2 I could either add a line to the GTK3 one's description referring to the GTK2 version or rename the GTK3-based package too, eg to roxterm-gtk3. In the latter case would adding Replaces: roxterm cause it to automatically replace roxterm at apt-get upgrade (or only dist-upgrade?) or would I have to make a meta-package? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110818003937.6f2465f0@junior
Re: Using dh to build 1 binary package with different configure options
On Fri, 12 Aug 2011 10:53:32 +1000 Karl Goetz k...@kgoetz.id.au wrote: On Fri, 12 Aug 2011 00:40:34 +0100 Tony Houghton h...@realh.co.uk wrote: I'm pretty sure I once read something about how to get a single source package to build multiple binary packages from the same source with different configure options. Unfortunately I can't remember what I read and it didn't apply to dh anyway. Can anyone recommend a guide to doing this with dh? Important question: Are you using dh short form or not? Yes, I'm using the short form. Thanks to everyone who showed me how to do this. But I'd also appreciate some feedback on the question of whether it's sensible to provide two versions of roxterm this way or should I pick one version and stick to a simple rules file? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110812133318.0b33ff6e@junior
Using dh to build 1 binary package with different configure options
A new release of roxterm is in the pipeline. I've made a lot of changes, mostly to replace libglade with GtkBuilder and to get it to work with gtk3. I'd ideally like to call it version 2 and have the clear distinction that version 1 was for gtk2 and version 2 is for gtk3. However, I suspect a lot of users would not be happy with switching to gtk3 yet, especially users of xfwm4 and kwin (and others?) due to bug #632403. gtk2/3 can be selected as a configure option. I don't mind continuing to support both for now, but I'd like to look to the future and make sure the gtk3-specific code is well tested as early as possible while still supporting people who want to stick with gtk2. Therefore I'd like to create two packages from the same source, eg roxterm (gtk2) and roxterm2 (gtk3). Or would it be better to rename both of them and make roxterm a meta package which depends on one or the other? They'd share a number of files, eg the .ui (formerly .glade) file, graphics and documentation; should I make a roxterm-data/roxterm-common package for these? Does all this sound like a good idea, or too complex to be worth it? I'm pretty sure I once read something about how to get a single source package to build multiple binary packages from the same source with different configure options. Unfortunately I can't remember what I read and it didn't apply to dh anyway. Can anyone recommend a guide to doing this with dh? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110812004034.20b47535@junior
debexpo RFS template: description
I noticed that RFS's from debexpo don't include a package description. I'd prefer to see at least the short description without having to visit the website, and personally I'd like to see the full description too, at least for new packages. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110805004421.52f7b20b@junior
