[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