Bug#426581: meshlab - anyone still working on this
I was trying to finalize a 1.2 release for the end of july Most of the new stuff is rather stable now. We have a serious bug with a gentoo distribution (the very important filter dialog does not show up on some linux distributions), and a couple of plugins that needs a bit of polishing, but nothing that colud not solved in a week or two. I think that the list of plugins will be finalized by next week. So from next week you could try to help us in the compiling/testing on debian. I made my best to integrate most of the mods that were done to the main trunk of meshlab. so the effort for packaging should be easier this time. Hopefully :) . Cheers Paolo On Fri, Jul 11, 2008 at 3:41 PM, Teemu Ikonen <[EMAIL PROTECTED]> wrote: > On Thu, Jul 10, 2008 at 10:34 PM, Yaroslav Halchenko > <[EMAIL PROTECTED]> wrote: >> any new updates on meshlab situation? > > Ftp-master rejected the 1.1.1 version because of incomplete copyright > information. This was promptly fixed in the upstream SVN version, so > now I'm waiting for the 1.2 release. > > Other options would be to either backport the copyright fixes to > version 1.1.1, or to package an SVN snapshot, but I'm somewhat > reluctant to do either of these. I hope we'll get a new version soon. > Paolo, could you please give a guesstimate on when this might happen? > > Best, > > Teemu > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426581: meshlab - anyone still working on this
On Thu, Jul 10, 2008 at 10:34 PM, Yaroslav Halchenko <[EMAIL PROTECTED]> wrote: > any new updates on meshlab situation? Ftp-master rejected the 1.1.1 version because of incomplete copyright information. This was promptly fixed in the upstream SVN version, so now I'm waiting for the 1.2 release. Other options would be to either backport the copyright fixes to version 1.1.1, or to package an SVN snapshot, but I'm somewhat reluctant to do either of these. I hope we'll get a new version soon. Paolo, could you please give a guesstimate on when this might happen? Best, Teemu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426581: meshlab - anyone still working on this
any new updates on meshlab situation?
On Wed, 18 Jun 2008, Ian Jackson wrote:
> Yaroslav Halchenko writes ("Re: Bug#426581: meshlab - anyone still working on
> this"):
> > ok -- upload is sponsored [stuff]
> Thanks for picking this up while I dropped off the face of the Debian
> planet for a couple of months.
> Ian.
--
.-.
=-- /v\ =
Keep in touch// \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko /( )\ ICQ#: 60653192
Linux User^^-^^[17]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426581: meshlab - anyone still working on this
Yaroslav Halchenko writes ("Re: Bug#426581: meshlab - anyone still working on
this"):
> ok -- upload is sponsored [stuff]
Thanks for picking this up while I dropped off the face of the Debian
planet for a couple of months.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426581: meshlab - anyone still working on this
ok -- upload is sponsored but for the next upload set a little more precise dependencies since libqt4-opengl-dev is not available on hurd-i386, sparc, and you have architecture any, thus it will be FTBFS on those architectures. Now we should just hope that no major problems will be detected by ftpmaster ;-) also that would be great if you work out with upstream some nice plan to define paths, so you could over-define them without hard-patching the code/build system. And I want to emphasize that you should use pbuilder with up-to-date chroot any time you are building package to be sponsored. It should be a must, ok? (I have a cron job which updates all my pbuilder chroots every night and I advice you do setup the same thingie) In any case -- thanks for a nice work and patience! On Fri, 16 May 2008, Teemu Ikonen wrote: > On Thu, May 15, 2008 at 6:13 PM, Yaroslav Halchenko > <[EMAIL PROTECTED]> wrote: > > got into problem with uptodate sid chroot for pbuilder, although it builds > > fine > > with mixed lenny/sid box (so some versions are from lenny) and it boils > > down to the recent split in libqt4-dev which now has opengl relevant > > headers in libqt4-opengl-dev... > Sigh. Maybe some day I remember to run all these checks myself. I > added the missing build-dep to libqt4-opengl-dev and uploaded the new > version to mentors. > Teemu -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik signature.asc Description: Digital signature
Bug#426581: meshlab - anyone still working on this
On Thu, May 15, 2008 at 6:13 PM, Yaroslav Halchenko <[EMAIL PROTECTED]> wrote: > got into problem with uptodate sid chroot for pbuilder, although it builds > fine > with mixed lenny/sid box (so some versions are from lenny) and it boils > down to the recent split in libqt4-dev which now has opengl relevant headers > in libqt4-opengl-dev... Sigh. Maybe some day I remember to run all these checks myself. I added the missing build-dep to libqt4-opengl-dev and uploaded the new version to mentors. Teemu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426581: meshlab - anyone still working on this
got into problem with uptodate sid chroot for pbuilder, although it builds fine with mixed lenny/sid box (so some versions are from lenny) and it boils down to the recent split in libqt4-dev which now has opengl relevant headers in libqt4-opengl-dev... for some reason http://packages.debian.org/search?suite=sid&arch=i386&searchon=contents&keywords=QGLWidget still says that QGLWidget belongs to libqt4-dev although split was done a week ago... and libqt4-dev recommends -opengl-dev but I guess in pbuilder recommends are not forced to be installed? So I guess you need to tune up dependecies here is a little log /usr/bin/uic-qt4 ui/congratsDialog.ui -o ui_congratsDialog.h g++ -c -pipe -O2 -Wall -W -D_REENTRANT -DDEBIAN -D__DISABLE_AUTO_STATS__ -DQT_NO_DEBUG -DQT_XML_LIB -DQT_OPENGL_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtOpenGL -I/usr/include/qt4/QtXml -I/usr/include/qt4/QtXml -I/usr/include/qt4 -I. -I../../../sf -I../../../code/lib/glew/include -I/usr/X11R6/include -I. -I. -o main.o main.cpp In file included from mainwindow.h:180, from main.cpp:51: glarea.h:140:21: error: QGLWidget: No such file or directory In file included from mainwindow.h:180, from main.cpp:51: glarea.h:255: error: invalid use of incomplete type 'struct QGLWidget' /usr/include/qt4/QtGui/qpixmap.h:247: error: forward declaration of 'struct QGLWidget' glarea.h: In member function 'void GLArea::setFileName(QString)': glarea.h:288: error: 'setWindowTitle' was not declared in this scope glarea.h: In member function 'void GLArea::showTrackBall(bool)': glarea.h:303: error: 'updateGL' was not declared in this scope glarea.h: In member function 'void GLArea::toggleHelpVisible()': glarea.h:308: error: 'update' was not declared in this scope glarea.h: In member function 'void GLArea::endEdit()': glarea.h:341: error: 'update' was not declared in this scope glarea.h: In member function 'void GLArea::suspendEditToggle()': glarea.h:352: error: 'setCursor' was not declared in this scope glarea.h:355: error: 'cursor' was not declared in this scope /usr/include/qt4/QtCore/qobject.h: In function 'T qobject_cast(QObject*) [with T = GLArea*]': mainwindow.h:315: instantiated from here /usr/include/qt4/QtCore/qobject.h:436: error: invalid static_cast from type 'QObject*' to type 'GLArea*' make[2]: *** [main.o] Error 1 make[2]: Leaving directory `/tmp/buildd/meshlab-1.1.1/meshlab/src/meshlab' make[1]: *** [sub-meshlab-make_default] Error 2 make[1]: Leaving directory `/tmp/buildd/meshlab-1.1.1/meshlab/src' On Mon, 12 May 2008, Teemu Ikonen wrote: > Hi all, > I just put a new version of the meshlab package to mentors.debian.net: > http://mentors.debian.net/debian/pool/main/m/meshlab/ > All the problems mentioned previously should be now solved, so to > whoever who wants to sponsor this, please do so. > Teemu -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426581: meshlab - anyone still working on this
On Mon, May 12, 2008 at 7:33 PM, Yaroslav Halchenko <[EMAIL PROTECTED]> wrote: > seems to be missing space upfront of signature... may be smth else as > well -- just make sure to run lintian on fixed package to assure that it is > ok > > btw -- since you are altering changelog, might be useful to replace > unstable to UNRELEASED in all prior versions, since they never were in > unstable actually. Ok, the changelog is now fixed and the new package is at mentors.debian.net. I also uploaded the source to the new debian-science repository at git.debian.org: http://git.debian.org/?p=debian-science/meshlab.git;a=summary I hope somebody can finally upload meshlab now :) Teemu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426581: meshlab - anyone still working on this
GREAT! but 1 hiccup *$> lintian -i meshlab_1.1.1-2_i386.changes W: meshlab: syntax-error-in-debian-changelog line 14 "badly formatted heading line" N: N: While parsing the Debian changelog, an syntax error was found. N: N: Refer to Policy Manual, section 4.4 for details. N: W: meshlab: syntax-error-in-debian-changelog line 16 "found start of entry where expected more change data or trailer" seems to be missing space upfront of signature... may be smth else as well -- just make sure to run lintian on fixed package to assure that it is ok btw -- since you are altering changelog, might be useful to replace unstable to UNRELEASED in all prior versions, since they never were in unstable actually. On Mon, 12 May 2008, Teemu Ikonen wrote: > Hi all, > I just put a new version of the meshlab package to mentors.debian.net: > http://mentors.debian.net/debian/pool/main/m/meshlab/ > All the problems mentioned previously should be now solved, so to > whoever who wants to sponsor this, please do so. > Teemu -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426581: meshlab - anyone still working on this
Hi all, I just put a new version of the meshlab package to mentors.debian.net: http://mentors.debian.net/debian/pool/main/m/meshlab/ All the problems mentioned previously should be now solved, so to whoever who wants to sponsor this, please do so. Teemu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426581: meshlab - anyone still working on this
Thank you Paolo! just 2 cents from me: to don't bother with learning [tg]roff (or whatever is native man language) I would suggest to make use of help2man tool http://packages.debian.org/sid/help2man but for that cmdline tools should have reasonable output on --help ;) doing it that way you solve 2 user interface problems ;-) and nobody would be lost on the way On Thu, 08 May 2008, Paolo Cignoni wrote: > Hi, > for the man pages i have just committed two files named meshlab.1 and > meshlabserver.1 under the docs directory of the new SVN repository of > meshlab. > I have no experience in the formatting language of man so, please > someone should check that > In the next days I would like to try incorporate the patches of Teemu > as much as possible inside the main trunk . > Cheers -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426581: meshlab - anyone still working on this
Hi, for the man pages i have just committed two files named meshlab.1 and meshlabserver.1 under the docs directory of the new SVN repository of meshlab. I have no experience in the formatting language of man so, please someone should check that In the next days I would like to try incorporate the patches of Teemu as much as possible inside the main trunk . Cheers P. On Thu, May 1, 2008 at 11:07 PM, Yaroslav Halchenko <[EMAIL PROTECTED]> wrote: > Hi Teemu, > > Sorry for a delay -- had a look at it: > > Here are my comments: > > * update copyright years in debian/copyright since there was a new upstream > release this year > > * why to have those > #if defined(DEBIAN) > if we are patching sources anyways? > > and those points about hardcoded paths already were mentioned in the thread > in d-s mailing list... may be upcoming release 1.2.0 will address them > so debian patch shrinks? or may be it is time to cherry-pick few patches from > upcoming 1.2.0 which already fixed build structure a bit? > > > * *MAN pages are needed*, though there are no cmdline arguments, at least to > give > very brief info on WTF is that > >is meshlabserver a useful tool on its own (pardon my ignorance -- never > used > meshlab before)? if so, then cool - just man page, if not, would be better > to > move it away from /usr/bin under /usr/lib/meshlab. > Since there is no man page I can't figure it out > > So updated copyright years + man pages and I would upload the beast... > > Long-going idea: since there are quite a few libraries which might be useful > outsize of meshlab GUI tool, it would be neat to have libmeshlab, > libmeshlab-dev packages (with appropriate versioning in the names). What do > you think? > > > > > > On Wed, 30 Apr 2008, Teemu Ikonen wrote: > > > On Tue, Apr 29, 2008 at 3:59 AM, Yaroslav Halchenko > > <[EMAIL PROTECTED]> wrote: > > > first -- just to make sure > > > http://esko.osmas.info/~tmx/meshlab/meshlab_1.1.1-1.dsc > > > this one? not the newer by mod date but not in version > > > http://esko.osmas.info/~tmx/meshlab/meshlab_1.1.0b~cvs20070528-1.dsc > > > > right? > > > or was it sponsored already? (I just get into the mailing list for a > > > while and that is where my procmail put the email... sorry about the > > > delay > > > Hi, > > > I uploaded the latest version of the meshlab source package to > > mentors.debian.net in an effort to find a sponsor: > > > http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=meshlab > > > The package still has no sponsor, so please consider becoming one :) > > > Best regards, > > > Teemu > > > > > -- > Yaroslav Halchenko > Research Assistant, Psychology Department, Rutgers-Newark > Student Ph.D. @ CS Dept. NJIT > Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 > 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 > WWW: http://www.linkedin.com/in/yarik > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426581: meshlab - anyone still working on this
Teemu Ikonen writes ("Re: Bug#426581: meshlab - anyone still working on this"):
> The package has not been updated to 1.1.1, and I may not have time to
> do it very soon. Ian did promise to sponsor the package, but I haven't
> heard anything from him lately.
I do exist but don't let me stop anyone else from helping. I've been
very busy.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426581: meshlab - anyone still working on this
Hi Teemu, Sorry for a delay -- had a look at it: Here are my comments: * update copyright years in debian/copyright since there was a new upstream release this year * why to have those #if defined(DEBIAN) if we are patching sources anyways? and those points about hardcoded paths already were mentioned in the thread in d-s mailing list... may be upcoming release 1.2.0 will address them so debian patch shrinks? or may be it is time to cherry-pick few patches from upcoming 1.2.0 which already fixed build structure a bit? * *MAN pages are needed*, though there are no cmdline arguments, at least to give very brief info on WTF is that is meshlabserver a useful tool on its own (pardon my ignorance -- never used meshlab before)? if so, then cool - just man page, if not, would be better to move it away from /usr/bin under /usr/lib/meshlab. Since there is no man page I can't figure it out So updated copyright years + man pages and I would upload the beast... Long-going idea: since there are quite a few libraries which might be useful outsize of meshlab GUI tool, it would be neat to have libmeshlab, libmeshlab-dev packages (with appropriate versioning in the names). What do you think? On Wed, 30 Apr 2008, Teemu Ikonen wrote: > On Tue, Apr 29, 2008 at 3:59 AM, Yaroslav Halchenko > <[EMAIL PROTECTED]> wrote: > > first -- just to make sure > > http://esko.osmas.info/~tmx/meshlab/meshlab_1.1.1-1.dsc > > this one? not the newer by mod date but not in version > > http://esko.osmas.info/~tmx/meshlab/meshlab_1.1.0b~cvs20070528-1.dsc > > right? > > or was it sponsored already? (I just get into the mailing list for a > > while and that is where my procmail put the email... sorry about the > > delay > Hi, > I uploaded the latest version of the meshlab source package to > mentors.debian.net in an effort to find a sponsor: > http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=meshlab > The package still has no sponsor, so please consider becoming one :) > Best regards, > Teemu -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426581: meshlab - anyone still working on this
On Wed, Apr 30, 2008 at 11:58:35AM +0200, Teemu Ikonen wrote: > On Tue, Apr 29, 2008 at 3:59 AM, Yaroslav Halchenko > <[EMAIL PROTECTED]> wrote: > > first -- just to make sure > > http://esko.osmas.info/~tmx/meshlab/meshlab_1.1.1-1.dsc > > this one? not the newer by mod date but not in version > > http://esko.osmas.info/~tmx/meshlab/meshlab_1.1.0b~cvs20070528-1.dsc > > > > right? > > or was it sponsored already? (I just get into the mailing list for a > > while and that is where my procmail put the email... sorry about the > > delay > > Hi, Hi! > I uploaded the latest version of the meshlab source package to > mentors.debian.net in an effort to find a sponsor: > http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=meshlab > > The package still has no sponsor, so please consider becoming one :) > I am ok to sponsor this package. Please find my comments below: - In debian/copyright, you should add the copyright entries from src/meshlab/shaders to the Copyright: section at the top of the file. - The clean target in debian/rules is a bit too complex. You can call "make distclean" instead of "make clean", in order to replace all the find calls. - The section should probably be "graphics" to match with the menu entry. - The more recent changelog entry should close the bug#426581. For that, please add a "Upload to unstable" entry. Please tell me when those minor problems are resolved, I'll upload the package. Cheers, Aurelien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426581: meshlab - anyone still working on this
On Tue, Apr 29, 2008 at 3:59 AM, Yaroslav Halchenko <[EMAIL PROTECTED]> wrote: > first -- just to make sure > http://esko.osmas.info/~tmx/meshlab/meshlab_1.1.1-1.dsc > this one? not the newer by mod date but not in version > http://esko.osmas.info/~tmx/meshlab/meshlab_1.1.0b~cvs20070528-1.dsc > > right? > or was it sponsored already? (I just get into the mailing list for a > while and that is where my procmail put the email... sorry about the > delay Hi, I uploaded the latest version of the meshlab source package to mentors.debian.net in an effort to find a sponsor: http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=meshlab The package still has no sponsor, so please consider becoming one :) Best regards, Teemu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426581: meshlab - anyone still working on this
first -- just to make sure http://esko.osmas.info/~tmx/meshlab/meshlab_1.1.1-1.dsc this one? not the newer by mod date but not in version http://esko.osmas.info/~tmx/meshlab/meshlab_1.1.0b~cvs20070528-1.dsc right? or was it sponsored already? (I just get into the mailing list for a while and that is where my procmail put the email... sorry about the delay PS I took this conversation offlist On Tue, 15 Apr 2008, Teemu Ikonen wrote: > On Fri, Apr 4, 2008 at 6:21 PM, Teemu Ikonen <[EMAIL PROTECTED]> wrote: > > On Fri, Apr 4, 2008 at 4:15 PM, Yaroslav Halchenko > > <[EMAIL PROTECTED]> wrote: > > > So what was the outcome? ;-) 1.1.1 upstream is out but ITP is still > > > open. Is help/sponsoring needed? > Ok, I updated the package to 1.1.1, it can be found at > http://esko.osmas.info/~tmx/meshlab/ > I found no problems in my testing, so I think the package is close to > being ready. Now the only thing missing is a sponsor. Ian, Yaroslav? > Teemu -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426581: meshlab - anyone still working on this
On Fri, Apr 4, 2008 at 6:21 PM, Teemu Ikonen <[EMAIL PROTECTED]> wrote: > On Fri, Apr 4, 2008 at 4:15 PM, Yaroslav Halchenko > <[EMAIL PROTECTED]> wrote: > > So what was the outcome? ;-) 1.1.1 upstream is out but ITP is still > > open. Is help/sponsoring needed? Ok, I updated the package to 1.1.1, it can be found at http://esko.osmas.info/~tmx/meshlab/ I found no problems in my testing, so I think the package is close to being ready. Now the only thing missing is a sponsor. Ian, Yaroslav? Teemu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426581: meshlab - anyone still working on this
On Fri, Apr 4, 2008 at 4:15 PM, Yaroslav Halchenko <[EMAIL PROTECTED]> wrote: > So what was the outcome? ;-) 1.1.1 upstream is out but ITP is still > open. Is help/sponsoring needed? The package has not been updated to 1.1.1, and I may not have time to do it very soon. Ian did promise to sponsor the package, but I haven't heard anything from him lately. Best, Teemu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426581: meshlab - anyone still working on this
So what was the outcome? ;-) 1.1.1 upstream is out but ITP is still open. Is help/sponsoring needed? On Mon, 17 Mar 2008, Teemu Ikonen wrote: > On Sat, Mar 8, 2008 at 7:00 PM, Paolo Cignoni <[EMAIL PROTECTED]> wrote: > > we are going to release the v1.1.1 of meshlab > > and i have arranged the source with hopefully all the issues that you > > have raised. > > Before releasing officially , could you check that the following sources > > are ok? > > http://vcg.isti.cnr.it/~cignoni/meshlab_20080308.tgz > Hi, > I've updated my package to this version. The new source package is at > http://esko.osmas.info/~tmx/meshlab/ > and at the launchpad site. > Best, > Teemu -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426581: meshlab - anyone still working on this
On Sat, Mar 8, 2008 at 7:00 PM, Paolo Cignoni <[EMAIL PROTECTED]> wrote: > we are going to release the v1.1.1 of meshlab > and i have arranged the source with hopefully all the issues that you > have raised. > > Before releasing officially , could you check that the following sources are > ok? > http://vcg.isti.cnr.it/~cignoni/meshlab_20080308.tgz Hi, I've updated my package to this version. The new source package is at http://esko.osmas.info/~tmx/meshlab/ and at the launchpad site. Best, Teemu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426581: meshlab - anyone still working on this
Dear all,
we are going to release the v1.1.1 of meshlab
and i have arranged the source with hopefully all the issues that you
have raised.
Before releasing officially , could you check that the following sources are ok?
http://vcg.isti.cnr.it/~cignoni/meshlab_20080308.tgz
If someone does not want the automatic checking for new releases of
the software
(e.g. the feature that would imply phoning home)
it is sufficient to define the symbol __DISABLE_AUTO_STATS__ during
the compilation
the automatic checkForUpdates call is guarded in the following way:
#if not defined(__DISABLE_AUTO_STATS__)
checkForUpdates(false);
#endif
Let me know for any compilation problem or other issues. I will try to
patch them.
Cheers
P.
On Wed, Feb 27, 2008 at 3:15 AM, Ian Jackson
<[EMAIL PROTECTED]> wrote:
> Paolo Cignoni writes ("Re: Bug#426581: meshlab - anyone still working on
> this"):
>
> > We use QT with QSettings mechanism for saving config files in a portable way
>
> Can these files be written other than by Qt ? Our configuration
> management systems often need to write to configuration in situations
> where the application in question is not available. Often there will
> not be a graphical display and sometimes not even a user to interact
> with (eg, preloading for automated operating system installs).
>
>
> > (i would like to avoid to put any OS specific code inside meshlab)
>
> I understand that view.
>
> If you make a hook that we can use to control the behaviour, we can
> happily add any necessary Debian-specific code to our version.
>
>
> > The mechanism i am going to implement is the following
> > An asking dialog popup at first run.
> > The result of the dialog will be saved in a persistent place using
> qsettings.
> > If this value is already set No dialog will never popup (so an
> > installer can set these values before first run)
>
> I think this isn't the right answer for Debian. We wouldn't want it
> popping up its own dialogues. But it sounds like it would provide a
> place for us to plumb in our own configuration. So if you do it that
> way then that's fine by us but we will adjust the configuration
> arrangements a bit for our users. I hope that's OK with you.
>
> The beauty of Free Software is that we can all have the version we
> want.
>
> Regards,
> Ian.
>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426581: meshlab - anyone still working on this
Paolo Cignoni writes ("Re: Bug#426581: meshlab - anyone still working on this"):
> We use QT with QSettings mechanism for saving config files in a portable way
Can these files be written other than by Qt ? Our configuration
management systems often need to write to configuration in situations
where the application in question is not available. Often there will
not be a graphical display and sometimes not even a user to interact
with (eg, preloading for automated operating system installs).
> (i would like to avoid to put any OS specific code inside meshlab)
I understand that view.
If you make a hook that we can use to control the behaviour, we can
happily add any necessary Debian-specific code to our version.
> The mechanism i am going to implement is the following
> An asking dialog popup at first run.
> The result of the dialog will be saved in a persistent place using qsettings.
> If this value is already set No dialog will never popup (so an
> installer can set these values before first run)
I think this isn't the right answer for Debian. We wouldn't want it
popping up its own dialogues. But it sounds like it would provide a
place for us to plumb in our own configuration. So if you do it that
way then that's fine by us but we will adjust the configuration
arrangements a bit for our users. I hope that's OK with you.
The beauty of Free Software is that we can all have the version we
want.
Regards,
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426581: meshlab - anyone still working on this
On Tue, Feb 26, 2008 at 8:01 PM, Ian Jackson
<[EMAIL PROTECTED]> wrote:
> Paolo Cignoni writes ("Re: Bug#426581: meshlab - anyone still working on
> this"):
>
> > So adding a compile option disabling the default home phoning is
> > probably the best idea.
>
> That would certainly suffice.
>
Ok, i'll do it in the next days.
>
> > At least can I ask for enabling at the first run?
> > Or even this is evil? :)
>
> I think that would be fine from an ethical point of view.
>
> But in Debian we already have established mechanisms for the
> configuration of software, and it would be good to be able to use
> those.
>
> So rather than writing code in meshlab to put up a dialogue, I would
> suggest code in meshlab to read a configuration file or two. The
> Debian maintainers would arrange for these files to contain the right
> answers, according to the questions asked of the system administrator
> and/or user.
We use QT with QSettings mechanism for saving config files in a portable way
(i would like to avoid to put any OS specific code inside meshlab)
The mechanism i am going to implement is the following
An asking dialog popup at first run.
The result of the dialog will be saved in a persistent place using qsettings.
If this value is already set No dialog will never popup (so an
installer can set these values before first run)
Hopefully this should suffice :)
P.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426581: meshlab - anyone still working on this
Paolo Cignoni writes ("Re: Bug#426581: meshlab - anyone still working on this"):
> So adding a compile option disabling the default home phoning is
> probably the best idea.
That would certainly suffice.
> At least can I ask for enabling at the first run?
> Or even this is evil? :)
I think that would be fine from an ethical point of view.
But in Debian we already have established mechanisms for the
configuration of software, and it would be good to be able to use
those.
So rather than writing code in meshlab to put up a dialogue, I would
suggest code in meshlab to read a configuration file or two. The
Debian maintainers would arrange for these files to contain the right
answers, according to the questions asked of the system administrator
and/or user.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426581: meshlab - anyone still working on this
On Sun, Feb 24, 2008 at 6:42 PM, Ian Jackson
<[EMAIL PROTECTED]> wrote:
> Paolo Cignoni writes ("Re: Bug#426581: meshlab - anyone still working on
> this"):
>
> > Ok, I understand your point, I respect and, as i told you since
> > beginning, i agree on disabling it for very pure, and ethically
> > coherent distributions like Debian.
> >
> > As you understood, this data collecting it is something that i need
> > for supporting the meshlab development, so i would like to find a
> > solution that, make as easy as possible for debian to get rid of this
> > (a bit nasty) phoning home, but i seems to me a bit silly to disable
> > this feature for less coherent distributions like ubuntu for example.
>
> When we make modifications in Debian to make the software work the way
> we feel it ought to, we don't in general make those modifications
> conditional on the package being built strictly for Debian. Indeed,
> this is one of the reasons why people choose to derive from Debian.
> So I don't think this is the right approach.
>
Ok , got even this point.
So adding a compile option disabling the default home phoning is
probably the best idea.
At least can I ask for enabling at the first run?
Or even this is evil? :)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426581: meshlab - anyone still working on this
Paolo Cignoni writes ("Re: Bug#426581: meshlab - anyone still working on this"):
> Ok, I understand your point, I respect and, as i told you since
> beginning, i agree on disabling it for very pure, and ethically
> coherent distributions like Debian.
>
> As you understood, this data collecting it is something that i need
> for supporting the meshlab development, so i would like to find a
> solution that, make as easy as possible for debian to get rid of this
> (a bit nasty) phoning home, but i seems to me a bit silly to disable
> this feature for less coherent distributions like ubuntu for example.
When we make modifications in Debian to make the software work the way
we feel it ought to, we don't in general make those modifications
conditional on the package being built strictly for Debian. Indeed,
this is one of the reasons why people choose to derive from Debian.
So I don't think this is the right approach.
> I am only searching the best way to modify my personal interest (that
> in some sense conflicts with these policies).
I'm sympathetic to your concerns and I would like to find a way to
address them as well as we can without compromising the privacy of our
users in a way that we would consider unacceptable. I can't speak for
Teemu but I think we in Debian should regard the users of derivative
distros as our users too, insofar as our decisions affect those users.
I've asking in the internal Debian policy-setting fora whether we
would be able to collect on your behalf, on an opt-in basis, some of
the additional data which meshlab currently reports directly to you.
I know that the most important Debian derivatives also collect popcon
data (some of them don't change the reporting address, so that their
users' data is included in our analysis).
You mentioned Ubuntu. Ubuntu is somewhat less careful than Debian
about this kind of thing, they too are worried about privacy; I don't
think Ubuntu's developers would want their version of meshlab phoning
home like the Windows version either. It's probably worthwhile you
negotiating with Ubuntu's management to ask them whether they would be
able to help you by giving you popcon data and/or some interpretation
of it.
If you need help with your funding bodies to explain this kind of
thing, particularly to explain why the data is less complete for
Debian users, I would be happy to help.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426581: meshlab - anyone still working on this
On Sun, Feb 24, 2008 at 2:54 PM, Ian Jackson
<[EMAIL PROTECTED]> wrote:
> Paolo Cignoni writes ("Re: Bug#426581: meshlab - anyone still working on
> this"):
>
> > Yes, it phones home regularly.
> >
> > It is well written in the docs
> > http://meshlab.sourceforge.net/wiki/index.php/Licenses
>
> Thanks for the reference.
>
>
> > It seems to me that it is not against the Debian social contract nor
> > against the Debian Free Software Guidelines (DFSG).
>
> This kind oof thing is written down anywhere in those documents
> because at the time those documents were written it would have been
> obvious to everyone concerned that it would be considered
> unacceptable.
>
> Not everything that we think is unacceptable is in those documents. I
> don't want to make outrageous comparisons, but just to give a more
> clear example (and I'm not saying this phoning home is as bad) we
> don't have a statement saying that Debian packages shouldn't install a
> backdoor allowing the developers to take over the user's computer, and
> we don't have one saying that Debian image display programs shouldn't
> send copies of all of the pictures to a private Debian mailing list
> for our personal entertainment.
>
> Given that software which phones home is becoming more and more
> common, and it seems that even honest and reasonable developers like
> yourself are starting to implement such functionality, I think we will
> have to update the Debian policy documents to make it clear that this
> is not acceptable in a Debian program. This is something that I will
> take care of internally.
>
Ok, I understand your point, I respect and, as i told you since
beginning, i agree on disabling
it for very pure, and ethically coherent distributions like Debian.
As you understood, this data collecting it is something that i need
for supporting the meshlab development, so i would like to find a
solution that, make as easy as possible for debian to get rid of this
(a bit nasty) phoning home, but i seems to me a bit silly to disable
this feature for less coherent distributions like ubuntu for example.
So a possible reasonable, solution is that i detect at compile time if
you are compiling meshlab on a debian system, and ONLY in that case,
disable any phoning home option. Adding a compile time option would be
something that a lazy package maintainer could directly copy from your
work of meshlab packaging (that is what most of the derivative
packaging systems like fink,macports, do, even those for very close
systems like macs...).
So what are the specific preprocessor symbols defined by default when
compiling on a Debian?
(do not fear to create any friction here, I understand and truly
respect debian policies,
I am only searching the best way to modify my personal interest (that
in some sense conflicts with these policies).
Cheers
P.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426581: meshlab - anyone still working on this
Paolo Cignoni writes ("Re: Bug#426581: meshlab - anyone still working on this"):
> Yes, it phones home regularly.
>
> It is well written in the docs
> http://meshlab.sourceforge.net/wiki/index.php/Licenses
Thanks for the reference.
> It seems to me that it is not against the Debian social contract nor
> against the Debian Free Software Guidelines (DFSG).
This kind oof thing is written down anywhere in those documents
because at the time those documents were written it would have been
obvious to everyone concerned that it would be considered
unacceptable.
Not everything that we think is unacceptable is in those documents. I
don't want to make outrageous comparisons, but just to give a more
clear example (and I'm not saying this phoning home is as bad) we
don't have a statement saying that Debian packages shouldn't install a
backdoor allowing the developers to take over the user's computer, and
we don't have one saying that Debian image display programs shouldn't
send copies of all of the pictures to a private Debian mailing list
for our personal entertainment.
Given that software which phones home is becoming more and more
common, and it seems that even honest and reasonable developers like
yourself are starting to implement such functionality, I think we will
have to update the Debian policy documents to make it clear that this
is not acceptable in a Debian program. This is something that I will
take care of internally.
> If I am wrong forgive my ignorance. In any case i need this feature so
> i could disable it but only for Debian builds.
If you don't want to disable it then of course you are free to make
that choice. Your website is clear enough I think. But, in our
Debian builds we will have to disable it.
It would be acceptable from a privacy point of view to ask the user's
permission but I think this is a poor way of addressing your needs.
If I were the Debian maintainer for the program I would want to
compile it out.
> Is it possible to know at compile time if the runnining system is a
> 100% debian?
> I mean, i need that feature, and disabling it for 'easy' distribution
> like ubuntu seems me non very reasonable.
It would probably be best if you simply provided a configuration
option to completely remove it from the build.
Teemu Ikonen writes ("Re: Bug#426581: meshlab - anyone still working on this"):
> I don't like this either, but is this really against the letter of the
> DFSG, policy or the social contract?
As the Debian maintainer you have the responsibility to provide the
software which best meets the needs of our users. With Free Software,
you have the ability, and in Debian the duty, to modify the software
as appropriate - even if upstream disagrees.
It is of course good to work cooperatively with upstream. It is best
if everyone keeps on good terms, and it is of course a good idea to
find out why upstream did something before changing it in our
package. But ultimately if the upstream maintainer and the Debian
maintainer disagree about something, then each is free to distribute
to their users the software in the form and with the behaviour that
they prefer. Hopefully that won't cause friction.
> On the other hand Paolo
> (perhaps?) needs to collect statistics in order to secure funding for
> his work. [...]
I think that a better option would be for us to help Paulo interpret
popcon data. That won't give him information about what kind of
meshes people are using, but it will give some estimated deployment
figures.
> At least when open source software phones home, one has the
> possibility to check what information is being sent. Maybe the best
> solution would be to have a pop-up dialog asking permission to phone
> home, with an "Always allow / deny from now on" option. In Windows
> this dialog comes with the firewall :)
Debian systems do not come with firewalls configured to defend the
user from programs on the computer; we rely on the programs themselves
to behave in an appropriate way.
If we are to make this configurable, then a better option would be a
debconf question feeding some configuration files. It is important to
make this machinery fail-block: that is, to ensure that at every level
of the configuration processing, the default is not to phone home.
Many users get very upset about unannounced phoning home and we
must absolutely prevent doing so by accident.
> Patches to the packaging are of course welcome. Unified diffs by mail
> are probably the least inconvenient option.
Right.
Thanks,
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426581: meshlab - anyone still working on this
Paolo Cignoni writes ("Re: Bug#426581: meshlab - anyone still working on this"):
> (shortened and with intermixed answers...)
Thanks, that's absolutely the right way to respond. So much so that
we don't normally feel the need to mention it :-).
> On Fri, Feb 22, 2008 at 10:00 PM, Ian Jackson
> > xwininfo: Window id: 0xc40009b "Plugin"
>
> Gotcha.
> It's a problem of the interacton between QT and your window manager,
> On win mac and some other wm this windows do not appear.
> the creation code is the following one
...
> stddialog->hide();
...
> I do not know how to patch this. I could ad a SetGeometry to make it
> very small, but it seems me a workaroud.
I think this is a bug in Qt. I imagine it's trying to hide the window
by setting a window manager hint, rather than unmapping it. It's not
a hideous problem. When we have uploaded a version to Debian (which
will enable Debian's Qt maintainer to reproduce the problem) I will
file a bug.
I don't think changing the size is a goood workaround. It is probably
best not to change meshlab at all.
> Yes it is a mess, the whole activation/deactivation mechanism of the
> plugins will change
> in 1.2.
Ah, good.
> > I don't think this would be appropriate in Debian. Users would expect
> > --help to print some information to stdout. So a simple message with
> > a URL in it, or some documentation, would be ideal from our point of
> > view.
>
> ok. np.
> I'll do this in this weekend.
Oh, thank you :-).
> [re U3D and idtfconverter]
> currently if the binary is missing it just report that the exporting
> has failed becouse the binary is missing.
That's good.
> and thanks again for you help.
Thank you for the software !
Regards,
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426581: meshlab - anyone still working on this
On Fri, Feb 22, 2008 at 10:06 PM, Ian Jackson
<[EMAIL PROTECTED]> wrote:
> Teemu Ikonen writes ("Re: Bug#426581: meshlab - anyone still working on
> this"):
> > > After I built it (on lenny), I ran meshlab from an xterm. It opened
> > > an entirely blank override-redirect pale grey window covering the top
> > > left area of my display, as well as the main window. What is that
> > > blank window for ? Can it be got rid of ?
> > I cannot repeat this.
> What is your window manager ? See my mail just sent for more
> information about this.
I run standard Gnome with Metacity. Looking at Paolos mail on this
subject, this may be a bug in QT, or in the window manager you are
using.
> However I have discovered one thing that we in Debian ought to
> consider release-critical: I have discovered that the program prompted
> me that a new version had been released. This is presumably achieved
> by contacting some upstream server to check.
>
> Paulo, is that correct ?
>
> I'm afraid that it is not acceptable for a program packaged for Debian
> to phone home like this and that feature must be disabled before we
> upload it even to unstable.
I don't like this either, but is this really against the letter of the
DFSG, policy or the social contract? On the other hand Paolo
(perhaps?) needs to collect statistics in order to secure funding for
his work. This is a common problem with software written by scientists
on grant money, and I'm afraid the usual solution is binary-only
releases and not allowing redistribution, which then supposedly makes
download statistics somewhat representative of actual usage.
At least when open source software phones home, one has the
possibility to check what information is being sent. Maybe the best
solution would be to have a pop-up dialog asking permission to phone
home, with an "Always allow / deny from now on" option. In Windows
this dialog comes with the firewall :)
> > > If I run the program with --help or -h, it tries to open them as
> > > files. It ought at least to bomb out with a message saying please
> > > refer to the meshlab wiki (with a URL).
> > Upstream.
> If I provide a patch will you incorporate it in your package ? I can
> do it as a bzr branch or an emailed diff, whichever you prefer.
Patches to the packaging are of course welcome. Unified diffs by mail
are probably the least inconvenient option.
Teemu
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426581: meshlab - anyone still working on this
On Fri, Feb 22, 2008 at 10:06 PM, Ian Jackson
<[EMAIL PROTECTED]> wrote:
> Teemu Ikonen writes ("Re: Bug#426581: meshlab - anyone still working on
> this"):
>
> However I have discovered one thing that we in Debian ought to
> consider release-critical: I have discovered that the program prompted
> me that a new version had been released. This is presumably achieved
> by contacting some upstream server to check.
>
> Paulo, is that correct ?
>
> I'm afraid that it is not acceptable for a program packaged for Debian
> to phone home like this and that feature must be disabled before we
> upload it even to unstable.
>
Yes, it phones home regularly.
It is well written in the docs
http://meshlab.sourceforge.net/wiki/index.php/Licenses
in the windows installer users have to agree on that before the
installation begins.
It seems to me that it is not against the Debian social contract nor
against the Debian Free Software Guidelines (DFSG).
If I am wrong forgive my ignorance. In any case i need this feature so
i could disable it but only for Debian builds.
Is it possible to know at compile time if the runnining system is a
100% debian?
I mean, i need that feature, and disabling it for 'easy' distribution
like ubuntu seems me non very reasonable.
People installing skype could also tolerate meshlabs that phones home.
>
> > > If I run the program with --help or -h, it tries to open them as
> > > files. It ought at least to bomb out with a message saying please
> > > refer to the meshlab wiki (with a URL).
> >
> > Upstream.
>
> If I provide a patch will you incorporate it in your package ? I can
> do it as a bzr branch or an emailed diff, whichever you prefer. I
> think this is quite important. The behaviour atm is rather poor if
> you're trying just to figure out how to run the program.
>
An emailed diff is ok,
Thanks
P.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426581: meshlab - anyone still working on this
(shortened and with intermixed answers...)
On Fri, Feb 22, 2008 at 10:00 PM, Ian Jackson
<[EMAIL PROTECTED]> wrote:
> Paolo Cignoni writes ("Re: Bug#426581: meshlab - anyone still working on
> this"):
>
> > After I built it (on lenny), I ran meshlab from an xterm. It opened
> > > an entirely blank override-redirect pale grey window covering the top
> > > left area of my display, as well as the main window. What is that
> > > blank window for ? Can it be got rid of ?
> >
> > This is not a the exepected behaviour. if meshlab is invoked without any
> > mesh it should ask for a file to open with the standard filedialog.
>
> So as a test today I'm running
> meshlab t.stl
> where t.stl is a file generated by a prograam of my own.
>
> I get two windows. One is the main meshlab window which has my object
> in in, the various menus, and so on. That is fine.
>
> The other window is blank, 800x700, at the top left corner of the
> screen, and is somehow bypassing the X11 window manager. xwininfo
> says this:
>
> xwininfo: Window id: 0xc40009b "Plugin"
Gotcha.
It's a problem of the interacton between QT and your window manager,
On win mac and some other wm this windows do not appear.
the creation code is the following one
void MainWindow::createStdPluginWnd()
{
stddialog = new MeshlabStdDialog(this);
stddialog->setAllowedAreas (Qt::NoDockWidgetArea );
addDockWidget(Qt::RightDockWidgetArea,stddialog);
stddialog->setFloating(true);
stddialog->hide();
}
I do not know how to patch this. I could ad a SetGeometry to make it
very small, but it seems me a workaroud.
> > > If I ask for `Edit / Measure' I can't get the rest of the edit menu
> > > back without clicking on the measuring tape in the toolbar. I assume
> > > this is unintentional and is an upstream UI bug.
> > >
> >
> > ahem . probably it is not a very intuitive pattern of action but eventually
> > it was intentional
> >
> > http://meshlab.sourceforge.net/wiki/index.php/Interactive_editing_tools
>
> I think this should be addressed at some point. If one is not
> supposed to be able to drive the program from the menu then there is
> little point having the menu item. Perhaps it would be better if the
> menu items (and indeed the other tools in the toolbar) were not greyed
> out ? Selecting them could then go straight from the old mode to the
> new.
Yes it is a mess, the whole activation/deactivation mechanism of the
plugins will change
in 1.2.
> > > If I run the program with --help or -h, it tries to open them as
> > > files. It ought at least to bomb out with a message saying please
> > > refer to the meshlab wiki (with a URL).
> >
> > quite a good idea.
> > if started with -h or --help it could directly open the meshlab wiki by
> > using the defaul os browser.
>
> I don't think this would be appropriate in Debian. Users would expect
> --help to print some information to stdout. So a simple message with
> a URL in it, or some documentation, would be ideal from our point of
> view.
ok. np.
I'll do this in this weekend.
>
> > > lintian says:
> > ...
> > I raise another issue:
> >
> > U3D. meshlab, to export files into u3d format, needs a binary
> > (idtfconverter), that is compiled out of the u3d open source library.
> > So i see that here there is another dependency here and perhaps there is the
> > need for someone to NMU sourceforge.net/projects/*u3d*
>
> I think for Debian this isn't critical, if meshlab at least doesn't
> crash if the binary isn't found. Although of course importing u3d
> files would be good.
>
> (`NMU' isn't the right term. You can probably just say `package'.)
>
Ok,
currently if the binary is missing it just report that the exporting
has failed becouse the binary is missing.
Cheers
and thanks again for you help.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426581: meshlab - anyone still working on this
Teemu Ikonen writes ("Re: Bug#426581: meshlab - anyone still working on this"):
> Thanks for the review. I fixed the problems you found except these:
> > After I built it (on lenny), I ran meshlab from an xterm. It opened
> > an entirely blank override-redirect pale grey window covering the top
> > left area of my display, as well as the main window. What is that
> > blank window for ? Can it be got rid of ?
>
> I cannot repeat this.
What is your window manager ? See my mail just sent for more
information about this.
> Edit / Vertex painting works here. The shaders crash here as well, but
> AFAIK they need hardware support to work, which I do not have here.
> Meshlab should check if GL_ARB_vertex_shader and
> GL_ARB_fragment_shader extensions are available, before trying to use
> them. I don't have time to start fixing this, or other upstream bugs.
> Paolo, can you help here?
Well, I don't think these are release-critical bugs.
However I have discovered one thing that we in Debian ought to
consider release-critical: I have discovered that the program prompted
me that a new version had been released. This is presumably achieved
by contacting some upstream server to check.
Paulo, is that correct ?
I'm afraid that it is not acceptable for a program packaged for Debian
to phone home like this and that feature must be disabled before we
upload it even to unstable.
> > If I run the program with --help or -h, it tries to open them as
> > files. It ought at least to bomb out with a message saying please
> > refer to the meshlab wiki (with a URL).
>
> Upstream.
If I provide a patch will you incorporate it in your package ? I can
do it as a bzr branch or an emailed diff, whichever you prefer. I
think this is quite important. The behaviour atm is rather poor if
you're trying just to figure out how to run the program.
> I updated the package and put it to again to
> http://esko.osmas.info/~tmx/meshlab/
> but as there are still problems (mainly with the shaders), maybe the
> package is not quite ready yet.
I haven't looked at this yet but I think we're definitely getting
there. If you can fix it so it doesn't phone home I'll upload it.
(The lib3ds package whose new upstream version I NMU'd has just
migrated to testing and I haven't yet heard an objection from its
maintainer.)
Thanks,
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426581: meshlab - anyone still working on this
Paolo Cignoni writes ("Re: Bug#426581: meshlab - anyone still working on this"):
> I am a bit ignorant about debian package creation so be patient with my
> naiveness :)
> I would try to help as I can.
> My comments intermixed below.
Thanks for your reply and sorry for the delay in getting back to you.
> After I built it (on lenny), I ran meshlab from an xterm. It opened
> > an entirely blank override-redirect pale grey window covering the top
> > left area of my display, as well as the main window. What is that
> > blank window for ? Can it be got rid of ?
>
> This is not a the exepected behaviour. if meshlab is invoked without any
> mesh it should ask for a file to open with the standard filedialog.
So as a test today I'm running
meshlab t.stl
where t.stl is a file generated by a prograam of my own.
I get two windows. One is the main meshlab window which has my object
in in, the various menus, and so on. That is fine.
The other window is blank, 800x700, at the top left corner of the
screen, and is somehow bypassing the X11 window manager. xwininfo
says this:
xwininfo: Window id: 0xc40009b "Plugin"
Absolute upper-left X: 0
Absolute upper-left Y: 0
Relative upper-left X: 0
Relative upper-left Y: 0
Width: 800
Height: 480
Depth: 24
Visual Class: TrueColor
Border width: 0
Class: InputOutput
Colormap: 0x20 (installed)
Bit Gravity State: NorthWestGravity
Window Gravity State: NorthWestGravity
Backing Store State: NotUseful
Save Under State: yes
Map State: IsViewable
Override Redirect State: no
Corners: +0+0 -800+0 -800-720 +0-720
-geometry 800x480+0+0
It's basically pale grey. Looking at it in xmag it's a uniform shade
with rgb = 0xefef 0xefef 0xefef. A closer examination shows two small
darker squares side by side in the top right corner, coloured rgb =
0x 0xdfdf 0xe4e4.
My window manager is vtwm, in case that's relevant.
I have taken a screenshot of my whole desktop and put it at
http://www.chiark.greenend.org.uk/~ian/t.2008-02-22/screenshot.png
(this is after I resized the main meshlab window, which usually
starts to fill the whole screen).
> > If I ask for `Edit / Measure' I can't get the rest of the edit menu
> > back without clicking on the measuring tape in the toolbar. I assume
> > this is unintentional and is an upstream UI bug.
> >
>
> ahem . probably it is not a very intuitive pattern of action but eventually
> it was intentional
>
> http://meshlab.sourceforge.net/wiki/index.php/Interactive_editing_tools
I think this should be addressed at some point. If one is not
supposed to be able to drive the program from the menu then there is
little point having the menu item. Perhaps it would be better if the
menu items (and indeed the other tools in the toolbar) were not greyed
out ? Selecting them could then go straight from the old mode to the
new.
> > If I run the program with --help or -h, it tries to open them as
> > files. It ought at least to bomb out with a message saying please
> > refer to the meshlab wiki (with a URL).
>
> quite a good idea.
> if started with -h or --help it could directly open the meshlab wiki by
> using the defaul os browser.
I don't think this would be appropriate in Debian. Users would expect
--help to print some information to stdout. So a simple message with
a URL in it, or some documentation, would be ideal from our point of
view.
> > lintian says:
> ...
>
> I did not fully understand the above, but i hope that i can ignore them :)
These are Debian-specific things which as upstream you do not need to
worry about :-).
> I raise another issue:
>
> U3D. meshlab, to export files into u3d format, needs a binary
> (idtfconverter), that is compiled out of the u3d open source library.
> So i see that here there is another dependency here and perhaps there is the
> need for someone to NMU sourceforge.net/projects/*u3d*
I think for Debian this isn't critical, if meshlab at least doesn't
crash if the binary isn't found. Although of course importing u3d
files would be good.
(`NMU' isn't the right term. You can probably just say `package'.)
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426581: meshlab - anyone still working on this
On Feb 9, 2008 7:08 PM, Ian Jackson <[EMAIL PROTECTED]> wrote:
> Teemu Ikonen writes ("Re: Bug#426581: meshlab - anyone still working on
> this"):
> > http://esko.osmas.info/~tmx/meshlab/
> I've reviewed this and it's looking reasonably good.
Hi Ian, Paolo and others,
Thanks for the review. I fixed the problems you found except these:
> After I built it (on lenny), I ran meshlab from an xterm. It opened
> an entirely blank override-redirect pale grey window covering the top
> left area of my display, as well as the main window. What is that
> blank window for ? Can it be got rid of ?
I cannot repeat this.
> I tested it on a .off from the [EMAIL PROTECTED] library and it seemed to more
> or less work. However there were a couple of things which made it
> segfault. For example, if I select any shader other than none, or if
> I ask for `Edit / Vertex painting' and then click on the object. I
> assume that these are installation problems of some kind (ie, bugs in
> the packaging).
Edit / Vertex painting works here. The shaders crash here as well, but
AFAIK they need hardware support to work, which I do not have here.
Meshlab should check if GL_ARB_vertex_shader and
GL_ARB_fragment_shader extensions are available, before trying to use
them. I don't have time to start fixing this, or other upstream bugs.
Paolo, can you help here?
> If I run the program with --help or -h, it tries to open them as
> files. It ought at least to bomb out with a message saying please
> refer to the meshlab wiki (with a URL).
Upstream.
> Eyeballing the patch I notice an awful lot of
> -INCLUDEPATH += ../.. ../../../../sf ../../../../code/lib/glew/include
> +INCLUDEPATH += ../.. ../../../../sf
> Maybe it would be possible to suggest to prepare a patch for upstream
> submission which replaces ../../../../code/lib/glew/include with
> $(GLEWINCLUDEPATH) or some such, which would be set in one place.
> Likewise various places where glew.c is referred to.
I cleaned up my build / directory / etc. hacks a bit, and attached
separate patches to this mail for Paolos convenience, if he chooses to
implement them in his sources. Although I'm sure he'll find better
solutions himself :)
I updated the package and put it to again to
http://esko.osmas.info/~tmx/meshlab/
but as there are still problems (mainly with the shaders), maybe the
package is not quite ready yet.
Teemu
=== modified file 'meshlab/src/meshlab/interfaces.h'
--- meshlab/src/meshlab/interfaces.h 2008-01-30 15:46:19 +
+++ meshlab/src/meshlab/interfaces.h 2008-02-11 15:14:21 +
@@ -223,12 +223,16 @@
static QString getPluginDirPath()
{
+ #if defined(DEBIAN)
+ QDir pluginsDir(QString("/usr/lib/meshlab"));
+ #else
QDir pluginsDir(getBaseDirPath());
if(!pluginsDir.exists("plugins"))
QMessageBox::warning(0,"Meshlab Initialization","Serious error. Unable to find the plugins directory.");
pluginsDir.cd("plugins");
- return pluginsDir.absolutePath();
+ #endif
+ return pluginsDir.absolutePath();
}
};
=== modified file 'meshlab/src/meshlab/meshlab.pro'
--- meshlab/src/meshlab/meshlab.pro 2008-02-11 11:51:26 +
+++ meshlab/src/meshlab/meshlab.pro 2008-02-11 15:14:21 +
@@ -71,6 +71,7 @@
DEFINES += GLEW_STATIC
LIBS += -lGLEW
+DEFINES += DEBIAN
INCLUDEPATH += . ../../../sf ../../../code/lib/glew/include
CONFIG += stl
=== modified file 'meshlab/src/meshlabplugins/filter_ao/filter_ao.cpp'
--- meshlab/src/meshlabplugins/filter_ao/filter_ao.cpp 2008-01-30 15:46:19 +
+++ meshlab/src/meshlabplugins/filter_ao/filter_ao.cpp 2008-02-11 15:14:21 +
@@ -711,8 +711,10 @@
void AmbientOcclusionPlugin::set_shaders(char *shaderName, GLuint &v, GLuint &f, GLuint &pr)
{
- QDir shadersDir = QDir(qApp->applicationDirPath());
-
+#if defined(DEBIAN)
+QDir shadersDir = QDir(QString("/usr/share/meshlab/shaders"));
+#else
+QDir shadersDir = QDir(qApp->applicationDirPath());
#if defined(Q_OS_WIN)
if (shadersDir.dirName() == "debug" || shadersDir.dirName() == "release" || shadersDir.dirName() == "plugins" )
@@ -734,7 +736,8 @@
QMessageBox::information(0, "Ambient Occlusion Plugin","Unable to find the shaders directory.\nNo shaders will be loaded.");
return;
}
-
+#endif // DEBIAN
+
f = glCreateShader(GL_FRAGMENT_SHADER);
v = glCreateShader(GL_VERTEX_SHADER);
=== modified file 'meshlab/src/meshlabplugins/filter_ao/filter_ao.pro'
--- meshlab/src/meshlabplugins/filter_ao/filter_ao.pro 2008-02-11 11:51:26 +
+++ meshlab/src/meshlabplugins/filter_ao/filter_ao.pro 2008-02-11 15:14:21 +
@@ -13,6 +13,7 @@
.
DEFINES += GLEW_STATIC
LIBS += -lGLEW
+DEFINES += DEBIAN
Bug#426581: meshlab - anyone still working on this
Hi to all,
I am a bit ignorant about debian package creation so be patient with my
naiveness :)
I would try to help as I can.
My comments intermixed below.
(Thanks for your effort!)
After I built it (on lenny), I ran meshlab from an xterm. It opened
> an entirely blank override-redirect pale grey window covering the top
> left area of my display, as well as the main window. What is that
> blank window for ? Can it be got rid of ?
This is not a the exepected behaviour. if meshlab is invoked without any
mesh it should ask for a file to open with the standard filedialog.
If I ask for `Edit / Measure' I can't get the rest of the edit menu
> back without clicking on the measuring tape in the toolbar. I assume
> this is unintentional and is an upstream UI bug.
>
ahem . probably it is not a very intuitive pattern of action but eventually
it was intentional
http://meshlab.sourceforge.net/wiki/index.php/Interactive_editing_tools
> If I run the program with --help or -h, it tries to open them as
> files. It ought at least to bomb out with a message saying please
> refer to the meshlab wiki (with a URL).
>
quite a good idea.
if started with -h or --help it could directly open the meshlab wiki by
using the defaul os browser.
>
>
> lintian says:
>
> W: meshlab: menu-item-uses-apps-section /usr/share/menu/meshlab:2
> W: meshlab: menu-item-creates-new-section Apps/Technical
> /usr/share/menu/meshlab:2
> W: meshlab: description-contains-homepage
> W: meshlab source: debian-rules-ignores-make-clean-error line 38
>
> These should be fixed I think. To get these messages say
> lintian meshlab_1.1.0-1_i386.deb
> lintian meshlab_1.1.0-1.dsc
> and you can get a fuller explanation with `lintian -i'.
>
>
I did not fully understand the above, but i hope that i can ignore them :)
>
> Eyeballing the patch I notice an awful lot of
> -INCLUDEPATH += ../.. ../../../../sf ../../../../code/lib/glew/include
> +INCLUDEPATH += ../.. ../../../../sf
> Maybe it would be possible to suggest to prepare a patch for upstream
> submission which replaces ../../../../code/lib/glew/include with
> $(GLEWINCLUDEPATH) or some such, which would be set in one place.
> Likewise various places where glew.c is referred to.
>
> Changing the same thing in many places like this is asking for merge
> conflicts in the future.
>
TRUE. We have to make a bit of order in our .pro files.
In any case i have seen (if i am still able to read diff's) that all the
references to glew src code in the plugins have been removed.
they were intentional. I think that this could cause some problem in the
various plugins
>
> There are quite a few places where we see things like this
> +#if defined(DEBIAN)
> +QDir shadersDir = QDir(QString("/usr/share/meshlab/shaders"));
> +#else
> QDir shadersDir = QDir(qApp->applicationDirPath());
>
> I'm not sure -DDEBIAN is the right answer here. If possible I would
> try to persuade upstream to provide a compilation option for FHS
> compliance.
>
>
>
> In the same area, I note that you appear to have been slighly careless
> with the whitespace in one of these:
>
> - QDir shadersDir = QDir(qApp->applicationDirPath());
> -#if defined(Q_OS_WIN)
> +#if defined(DEBIAN)
> +QDir shadersDir = QDir(QString("/usr/share/meshlab/shadersrm"));
> +#else
> + QDir shadersDir = QDir(qApp->applicationDirPath());
> +# if defined(Q_OS_WIN)
>
> Note that the indentation of the the applicationDirPath()-based
> initialisation has changed (perhaps due to tab/space conversion). It
> is a good idea to be very careful not to do this as it just causes
> spurious merge conflicts in the future.
>
>
> I notice that you had to change two very similar sets of code
> initialising a shadersDir. You should submit a patch upstream to move
> this into a single function to avoid repetition (if you haven't
> already).
>
> Yet another good suggestion. Initialization of application dirs (plugins,
shaders, textures) is a mess.
On same OS like macs is rather tricky...
Some cleaning strongly needed here :)
I raise another issue:
U3D. meshlab, to export files into u3d format, needs a binary
(idtfconverter), that is compiled out of the u3d open source library.
So i see that here there is another dependency here and perhaps there is the
need for someone to NMU sourceforge.net/projects/*u3d*
Cheers
and thanks again for your brave efforts.
P.
Bug#426581: meshlab - anyone still working on this
Teemu Ikonen writes ("Re: Bug#426581: meshlab - anyone still working on this"):
> http://esko.osmas.info/~tmx/meshlab/
I've reviewed this and it's looking reasonably good.
Firstly, two general observations:
* You should run lintian, particularly after making a wholly new
package.
* With a new package you should run it and play with its features.
This is a good way to find bugs :-).
Now for my detailed comments:
After I built it (on lenny), I ran meshlab from an xterm. It opened
an entirely blank override-redirect pale grey window covering the top
left area of my display, as well as the main window. What is that
blank window for ? Can it be got rid of ?
I tested it on a .off from the [EMAIL PROTECTED] library and it seemed to more
or less work. However there were a couple of things which made it
segfault. For example, if I select any shader other than none, or if
I ask for `Edit / Vertex painting' and then click on the object. I
assume that these are installation problems of some kind (ie, bugs in
the packaging).
If I ask for `Edit / Measure' I can't get the rest of the edit menu
back without clicking on the measuring tape in the toolbar. I assume
this is unintentional and is an upstream UI bug.
If I run the program with --help or -h, it tries to open them as
files. It ought at least to bomb out with a message saying please
refer to the meshlab wiki (with a URL).
lintian says:
W: meshlab: menu-item-uses-apps-section /usr/share/menu/meshlab:2
W: meshlab: menu-item-creates-new-section Apps/Technical
/usr/share/menu/meshlab:2
W: meshlab: description-contains-homepage
W: meshlab source: debian-rules-ignores-make-clean-error line 38
These should be fixed I think. To get these messages say
lintian meshlab_1.1.0-1_i386.deb
lintian meshlab_1.1.0-1.dsc
and you can get a fuller explanation with `lintian -i'.
lintian also says:
W: meshlab: latest-debian-changelog-entry-without-new-version
which is because of your poorly chosen `1.1.0b~cvs20070528-1' version
number. This can be ignored if you like, or you could retrospectively
add a ~ after 1.1.0 if you feel like it.
(You may get different messages with sid's lintian - please check.)
This looks like a mistake:
+++ meshlab-1.1.0/debian/install
...
+meshlab/src/meshlab/shaders/*.frag usr/share/meshlab/shaders
+meshlab/src/meshlab/shaders/*.gdp usr/share/meshlab/shaderss
+meshlab/src/meshlab/shaders/*.vert usr/share/meshlab/shaders
Note the extra `s' in `shaderss'.
I think the things I've mentioned so far ought to be addressed somehow
(for the bugs, perhaps just mentioned in a README) before an upload.
The rest is icing on the cake:
Eyeballing the patch I notice an awful lot of
-INCLUDEPATH += ../.. ../../../../sf ../../../../code/lib/glew/include
+INCLUDEPATH += ../.. ../../../../sf
Maybe it would be possible to suggest to prepare a patch for upstream
submission which replaces ../../../../code/lib/glew/include with
$(GLEWINCLUDEPATH) or some such, which would be set in one place.
Likewise various places where glew.c is referred to.
Changing the same thing in many places like this is asking for merge
conflicts in the future.
There are quite a few places where we see things like this
+#if defined(DEBIAN)
+QDir shadersDir = QDir(QString("/usr/share/meshlab/shaders"));
+#else
QDir shadersDir = QDir(qApp->applicationDirPath());
I'm not sure -DDEBIAN is the right answer here. If possible I would
try to persuade upstream to provide a compilation option for FHS
compliance.
In the same area, I note that you appear to have been slighly careless
with the whitespace in one of these:
- QDir shadersDir = QDir(qApp->applicationDirPath());
-#if defined(Q_OS_WIN)
+#if defined(DEBIAN)
+QDir shadersDir = QDir(QString("/usr/share/meshlab/shadersrm"));
+#else
+ QDir shadersDir = QDir(qApp->applicationDirPath());
+# if defined(Q_OS_WIN)
Note that the indentation of the the applicationDirPath()-based
initialisation has changed (perhaps due to tab/space conversion). It
is a good idea to be very careful not to do this as it just causes
spurious merge conflicts in the future.
I notice that you had to change two very similar sets of code
initialising a shadersDir. You should submit a patch upstream to move
this into a single function to avoid repetition (if you haven't
already).
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426581: Fwd: Bug#426581: meshlab - anyone still working on this
Teemu Ikonen writes ("Fwd: Bug#426581: meshlab - anyone still working on this"):
> Since you asked about meshlab packages a while ago, are you still
> interested in sponsoring them? I have packages ready for review, see
> the mail below for details.
Thanks.
Teemu Ikonen <[EMAIL PROTECTED]> writes:
> Great! This makes packaging really much easier. I remade my packaging branch
> at
> https://code.launchpad.net/meshlab to use the new release. I think the
> package is now close to being good enough to upload to the archive,
> the only obstacle is the obsolete lib3ds-dev in Debian. That just
> requires someone to NMU it since the changes needed to build the new
> version are really small, and given in a patch at bug #463108.
I'm about to NMU lib3ds-dev 1.3.0-0.1 into the 7-day delayed queue.
> In order to get the package uploaded, I would need a sponsor /
> co-maintainer. Any volunteers?
Yes, me. I don't mind whether you call me co-maintainer but I don't
expect to be doing a great deal of responding to bug reports and that
kind of thing so it's probably best to make just you be the
maintainer.
I'm looking at your package now and will send detailed comments.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426581: meshlab - anyone still working on this
On Jan 29, 2008 6:42 PM, Paolo Cignoni <[EMAIL PROTECTED]> wrote:
> Hi to all,
> With the new release 1.1.0
> i have prepared, as you requested, a tarball with (hopefully) all the
> needed sources (including vcg)
> it is available at sourceforge at
>
> http://downloads.sourceforge.net/meshlab/MeshLabSrc_v110.tgz
Great! This makes packaging really much easier. I remade my packaging branch at
https://code.launchpad.net/meshlab to use the new release. I think the
package is now close to being good enough to upload to the archive,
the only obstacle is the obsolete lib3ds-dev in Debian. That just
requires someone to NMU it since the changes needed to build the new
version are really small, and given in a patch at bug #463108.
For people who want to test the package without using bzr, the source
package is also at
http://esko.osmas.info/~tmx/meshlab/
Remember to use version 1.3.0 of lib3ds.
In order to get the package uploaded, I would need a sponsor /
co-maintainer. Any volunteers?
As for the meshlab release, I found a couple of small issues that
should be fixed upstream (but are now patched in the Debian source):
- ui_painttoolbox.h is not created during build
- build fails due to private variable access in one of the plugins,
see attached patch
Teemu
> Once untarred it should contain most of the needed libs.
> The only depending stuff that should be managed by hand
> is the lib3ds, for which we need the 1.3 version
>
> I have set up a page of the documentation explaining what is needed
> and how to compile
> http://meshlab.sourceforge.net/wiki/index.php/Compiling
>
> Let me know if i can help in some way
>
> p.
=== modified file 'meshlab/src/meshlabplugins/render_rm/glstateholder.h'
--- meshlab/src/meshlabplugins/render_rm/glstateholder.h
2008-01-30 15:46:19 +
+++ meshlab/src/meshlabplugins/render_rm/glstateholder.h
2008-01-31 15:09:44 +
@@ -160,7 +160,7 @@
class GLStateHolder : public QObject
{
Q_OBJECT
-
+friend class RmMeshShaderRenderPlugin;
// private data members
private:
Bug#426581: meshlab - anyone still working on this
Hi all, I made a small effort to bring the meshlab package up to date with the current CVS version, but had to give up. There were some errors on the code, such as missing functions or declarations (I probably hit the CVS on a wrong day), but what stopped me was that the dependency on lib3ds-dev is to version 1.3.0, which is not in Debian yet (bug report filed, see #463108). In order to let others take a stab on packaging, I will let launchpad host my bzr branches, and will grant access to anyone who's interested (Gurkan?). Launchpad should also automatically import code from the sourceforge CVS to the "trunk" branch. See https://code.launchpad.net/meshlab if interested. Code tarballs from upstream with the useful parts from vcg needed to build meshlab would really help. Now the meshlab-debian branch at launchpad has these bits copied manually from a CVS checkout made on the same day as meshlab was updated. Best, Teemu On Jan 24, 2008 10:38 PM, Paolo Cignoni <[EMAIL PROTECTED]> wrote: > Hi, > I do not have a debian machine directly available for testing,nor i > know how to build debian packages, > but I can help any volunteer in this task. > > Version 1.1.0 is almost ready > so if also a debian version would be ready i will be really happy. > > Feel free to ask me, (and/or to the meshlab devel maililing list) > > Cheers > > Paolo Cignoni > (the lead devel of meshlab) > > > > On Jan 24, 2008 8:50 PM, Ian Jackson <[EMAIL PROTECTED]> wrote: > > Is anyone still working on the meshlab package (and the vcg library) ? > > > > I have a use for it and hoped to find a package, or failing that I > > might try to put one together myself. > > > > How far has anyone got ? Any information or pointers would be > > valuable. > > > > I found this: > > http://gnu.ethz.ch/debian/meshlab/ > > which is shall we say a surprising way of distributing source for > > Debian and is clearly very much a work in progress. > > > > If someone wants to make a package suitable for me to sponsor that > > would be fine by me too. > > > > Regards, > > Ian. > > > > > > -- > > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > > > > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426581: meshlab - anyone still working on this
Hi, I do not have a debian machine directly available for testing,nor i know how to build debian packages, but I can help any volunteer in this task. Version 1.1.0 is almost ready so if also a debian version would be ready i will be really happy. Feel free to ask me, (and/or to the meshlab devel maililing list) Cheers Paolo Cignoni (the lead devel of meshlab) On Jan 24, 2008 8:50 PM, Ian Jackson <[EMAIL PROTECTED]> wrote: > Is anyone still working on the meshlab package (and the vcg library) ? > > I have a use for it and hoped to find a package, or failing that I > might try to put one together myself. > > How far has anyone got ? Any information or pointers would be > valuable. > > I found this: > http://gnu.ethz.ch/debian/meshlab/ > which is shall we say a surprising way of distributing source for > Debian and is clearly very much a work in progress. > > If someone wants to make a package suitable for me to sponsor that > would be fine by me too. > > Regards, > Ian. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426581: meshlab - anyone still working on this
On 2008-01-24 20:50:41 +0100 Ian Jackson <[EMAIL PROTECTED]> wrote: Is anyone still working on the meshlab package (and the vcg library) ? I can do that, I just didn't because there was an ITP and I didn't want to do doublework. But since I didn't recieve any reply to my ping, I guess I'll just pick it to me and be glad that you offer sponsorship. I have a use for it and hoped to find a package, or failing that I might try to put one together myself. Well if you want you can do the vcg stuff and I do the meshlab, or even better we both co-maintain the both? How far has anyone got ? Any information or pointers would be valuable. I think it'll build and work fine, I already maintain a few QT based packages, they often are very simple and flawless. I found this: http://gnu.ethz.ch/debian/meshlab/ which is shall we say a surprising way of distributing source for Debian and is clearly very much a work in progress. That really was just a quick try, I'll continue working on that though (they got some update just right now already). If someone wants to make a package suitable for me to sponsor that would be fine by me too. I'll continue when I have something working, tested and ready for Debian. Regards, Ian. Thank you and regards, Guerkan -- while(!asleep()) sheep++; -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426581: meshlab - anyone still working on this
Is anyone still working on the meshlab package (and the vcg library) ? I have a use for it and hoped to find a package, or failing that I might try to put one together myself. How far has anyone got ? Any information or pointers would be valuable. I found this: http://gnu.ethz.ch/debian/meshlab/ which is shall we say a surprising way of distributing source for Debian and is clearly very much a work in progress. If someone wants to make a package suitable for me to sponsor that would be fine by me too. Regards, Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
