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 <koster@debian.org> wrote:
> Tony Houghton <h@realh.co.uk> writes:
>
> > On Mon, 12 Sep 2011 22:36:54 +0800
> > Kan-Ru Chen <koster@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?
Reply to: