[Pkg-octave-devel] QtOctave: removal of simplercs

[Thomas Weber]

On Sun, May 09, 2010 at 03:51:47PM -0500, Jordi Gutiérrez Hermoso wrote:
> 2010/5/9 Thomas Weber <thomas.weber.mail at gmail.com>:
> > On Sun, May 09, 2010 at 01:10:41AM -0500, Jordi Gutiérrez Hermoso wrote:
> >> On 8 May 2010 04:16, Thomas Weber <thomas.weber.mail at gmail.com> wrote:
> >> > I'm currently packaging the 0.9.1 release of QtOctave.
> >>
> >> I pushed to git the work I have so far. I think I overwrote a fair
> >> amount of work, since I just blindly stamped over whatever you had
> >> there.
> >
> > I haven't pushed anything yet. However, you did delete quite some
> > changelog entries of packages already in the archive, so we most
> > definitely can't continue from there.
> 
> Yes, I know that was a mistake. I didn't realise I was working from an
> old tarball when I begun the work yesterday.

No problem, shit happens. That's why we have a VCS.

> >> It's a proposal towards moving all that extra crap in the
> >> source package to qtoctave-utils. Still got a few lintian errors, but
> >> overall seems in good shape.
> >
> > Sorry Jordi, but this is the wrong approach. The problem is having 6
> > binaries for just one software; whether they are in one package or in
> > two is not relevant.
> 
> Well, the thing is that by upstream's own admission, four of those
> binaries are mostly irrelevant. One of them wasn't even being built by
> the current build process.
Yes, but the problem is that simplercs has a menu entry. Non-working
menu entries are bugs and frustrate users.
Also, while we do have more VCS in Debian than even I know, none of them
is integrated into QtOctave. Therefore, I'm not sure keeping simplercs
out is a proper solution.

> And it's eight binaries, not six. I guess putting them all in
> /usr/lib/qtoctave might make sense and spare us the chore of splitting
> the binary package but patch the sources instead to look for those
> binaries in that location.
Yes, but upstream is pretty responsive about integrating patches (which
means he integrates them, I rarely hear back about it :))

> > And indeed, the generic names already cause a problem:
> 
> Alright, let's move them. They should go in /usr/lib, according to the
> FHS (internal binaries).
Thanks for looking that up.

> > Jordi, please try to have smaller commits:
> 
> That was a mistake. I documented every little change in the changelog,
> so that should be more informative. 
You don't understand me. If you had made the very same changes, but in
smaller commits, it would have been easier to merge them with the
current HEAD. The problem is not what you changed, but how you commited
it.

> Some of the patches do fix an actual problem with the upstream source,
> such as generating l10n files and building widgetserver which wasn't
> getting built at all. Maybe I can still convince upstream to accept
> those patches for the promised 0.9.2 bugfixing release.
I understand you take care of this? Cool, one less thing for me :)

> Also, sorry I jumped on this, but I didn't want to see another update
> of "my" package without my involvement. ;-) I was already getting
> warnings from Debian admins about my name getting cleaned out from the
> DOG.

Eh no. This was not about DOG, but about you being in Uploaders and no
upload from you for quite some time.

> Btw, Carthago delenda est, qrupdate?
Mi dispiace, ma parlo solo un poco italiano. Non so spagnolo. 

First, I'll try to get the easy things out of the way and update the
octave-forge packages. Then qtoctave, and qrupdate at the end. Sorry,
but qrupdate ships a library and I need to spend some time reading and
checking whether the library still is ABI-compatible (not that I think
it isn't, but I need to learn how to check for that).

Thanks
	Thomas