Bug#683078: l10n UI unreadable at all (can't load international font)
Package: blender Version: 2.63a-1 When starting Blender, I get many annoying warnings as follows: Can't load font: default from memory!! Warning: Can't found default font!! Warning: Can't found default font!! Warning: Can't found default font!! Warning: Can't found default font!! Warning: Can't found default font!! Warning: Can't found default font!! Warning: Can't found default font!! Warning: Can't found default font!! Warning: Can't found default font!! Warning: Can't found default font!! Warning: Can't found default font!! Warning: Can't found default font!! Warning: Can't found default font!! Warning: Can't found default font!! Warning: Can't found default font!! Warning: Can't found default font!! Warning: Can't found default font!! Warning: Can't found default font!! Warning: Can't found default font!! Warning: Can't found default font!! Warning: Can't found default font!! Warning: Can't found default font!! Warning: Can't found default font!! Warning: Can't found default font!! Warning: Can't found default font!! Warning: Can't found default font!! Warning: Can't found default font!! Warning: Can't found default font!! Warning: Can't found default font!! Warning: Can't found default font!! Warning: Can't found default font!! Warning: Can't found default font!! Warning: Can't found default font!! Warning: Can't found default font!! Warning: Can't found default font!! Warning: Can't found default font!! Warning: Can't found default font!! Warning: Can't found default font!! Warning: Can't found default font!! And indeed UI is not displayed with Droid Sans Regular font. Especially, if I attempt to use UI translated into Japanese, all Japanese characters appear as unreadable blank squares. I investigated 0009-look_for_droid_ttf_with_fontconfig.patch and found that BLI_file_to_mem() in fileops.c doesn't work. fread() in this function returns 0 or 1, not actual readsize, so the font file cannot be read to memory area properly. To fix this bug, readsize= fread(mem+size, chunk_size,1,file); has to be modified as follows: readsize= fread(mem+size, 1, chunk_size, file); -- IRIE Shinsuke ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#682948: Incorrect versioning scheme disturbs upgrading
Package: blender Version: 2.63a-1 Severity: important Please don't change the versioning scheme, and don't use upstream version string a, b, etc. Old blender package for 2.49b used the package version 2.49.2 to avoid the upgrade issue. Changelog of 2.49.2~dfsg-1 says: This is actually 2.49b, but using a +dfsg suffix breaks comparing 2.49+dfsg and 2.49b+dfsg. Use .2 instead of b accordingly. And switch to using a ~dfsg suffix. So, 2.63a should be translated into 2.63.1 for the same reason. In my PPA in Launchpad, I have maintained blender trunk package for Ubuntu and the package version uses +svn suffix like 2.63.1+svn49102-0irie1~precise1. Since Debian package system compares the versions as 2.63a+svn 2.63+svn 2.63.1+svn, if the official Debian/Ubuntu package uses the wrong versioning scheme such as 2.63a, I can no longer provide the trunk packages having a version suffix +svn. -- IRIE Shinsuke ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#682948: Incorrect versioning scheme disturbs upgrading
I forgot to say that actually there were official deb packages using +cvs suffix in the past (ex. 2.25b+cvs.2003.02.17-1). So, +svn suffix might be used for the future versions of the official packages. I mean the versioning scheme like 2.63.1 is generally necessary, not only for my PPA's packages. -- IRIE Shinsuke ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#682948: Incorrect versioning scheme disturbs upgrading
Hi, 12/07/27, Matteo F. Vescovi wrote: I'm not going to use SVN revisions other than the stable releases. So Debian Blender package is not going to face this issue at all. Since I'm actually the only active maintainer for this package, I don't see any issue in naming using upstream's version numbering. Hmm... I see, that is what I have worried about. What about another numbering scheme using . between the minor version and the version character as follows? 2.63, 2.63.a, 2.63.b, ... This scheme is very similar to the upstream version numbering, and should never cause the upgrade issue even if a version suffix is necessary. -- IRIE Shinsuke ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#683042: debian/copyright: No information of embedded external libraries
Package: blender Version: 2.63a-1 debian/copyright doesn't include the copyright information of the external libraries such as libmv, Eigen3, and Bullet Physics which are included in orig.tar.bz2 file and will be statically linked. Also, there are some codes partially imported from external projects. For example, functions for detecting a pen tablet device were copied from Wine 1.1.13 (See intern/ghost/intern/GHOST_WindowX11.cpp). -- IRIE Shinsuke ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#683046: Thumbnailer is not registered automatically
Package: blender Version: 2.63a-1 blender-thumbnailer.py is installed in /usr/bin, but not working unless we manually register it by creating .thumbnailer file in ~/.local/share/thumbnailers. I think deb package should make system-wide setting for it, so please install /usr/share/thumbnailers/blender.thumnailer as follows: START === [Thumbnailer Entry] TryExec=blender-thumbnailer.py Exec=blender-thumbnailer.py %u %o MimeType=application/x-blender; E N D === -- IRIE Shinsuke ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#683046: Thumbnailer is not registered automatically
Oops, sorry, the thumbnailer is installed in /usr/lib/blender/scripts/. -- IRIE Shinsuke ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#683046: Thumbnailer is not registered automatically
The thumbnailer should work with the following .thumbnailer file: START === [Thumbnailer Entry] TryExec=/usr/lib/blender/scripts/blender-thumbnailer.py Exec=/usr/lib/blender/scripts/blender-thumbnailer.py %i %o MimeType=application/x-blender; E N D === -- IRIE Shinsuke ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
