Bug#788314: zyne: Zyne is not starting due to import error (No module named zyne.Resources.variables)
Package: zyne Version: 0.1.2-1 Followup-For: Bug #788314 I get the same bug, even after installing the missing python-wxversion dependency. -g -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.0.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages zyne depends on: ii python 2.7.9-1 ii python-pyo 0.7.5-2 zyne recommends no packages. zyne suggests no packages. -- no debconf information ___ 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#789481: musescore: FTBFS on architectures where char is not signed
Source: musescore
Version: 2.0.1+dfsg-1
Severity: serious
Many architectures FTBFS:
https://buildd.debian.org/status/package.php?p=musescoresuite=unstable
from the arm64 log:
[ 10%] Building CXX object mstyle/CMakeFiles/mstyle.dir/menubarengine.cpp.o
In file included from command-line:0:0:
/usr/include/stdc-predef.h:59:1: warning:
/«BUILDDIR»/musescore-2.0.1+dfsg/build.release/all.h.gch: not used because
`_FORTIFY_SOURCE' is defined [-Winvalid-pch]
#endif
^
In file included from
/«BUILDDIR»/musescore-2.0.1+dfsg/libmscore/stafftype.h:16:0,
from /«BUILDDIR»/musescore-2.0.1+dfsg/libmscore/xml.h:17,
from /«BUILDDIR»/musescore-2.0.1+dfsg/fluid/sfont.cpp:30:
/«BUILDDIR»/musescore-2.0.1+dfsg/libmscore/element.h:48:18: error: enumerator
value -1 is outside the range of underlying type 'char'
NO_GRIP = -1,
^
In file included from /«BUILDDIR»/musescore-2.0.1+dfsg/libmscore/note.h:24:0,
from
/«BUILDDIR»/musescore-2.0.1+dfsg/libmscore/durationtype.h:17,
from /«BUILDDIR»/musescore-2.0.1+dfsg/libmscore/stafftype.h:19,
from /«BUILDDIR»/musescore-2.0.1+dfsg/libmscore/xml.h:17,
from /«BUILDDIR»/musescore-2.0.1+dfsg/fluid/sfont.cpp:30:
/«BUILDDIR»/musescore-2.0.1+dfsg/libmscore/pitchspelling.h:56:42: error:
enumerator value -1 is outside the range of underlying type 'char'
enum class NoteCaseType : char { AUTO = -1, CAPITAL = 0, LOWER, UPPER };
^
There is also another problem on x86:
musescore-soundfont-gm/amd64 unsatisfiable Depends: timgm6mb-soundfont
musescore-soundfont-gm/i386 unsatisfiable Depends: timgm6mb-soundfont
Andreas
___
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#789506: No VP9 support
Package: mplayer2 Version: 2.0-728-g2c378c7-4+b1 Severity: normal Many videos, including current YouTube videos, use VP9 these days. mplayer2 doesn't seem to have any support for VP9, though other players do. Please consider building in support for VP9, using ffvp9. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.0.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mplayer2 depends on: ii liba52-0.7.4 0.7.4-18 ii libasound21.0.28-1 ii libass5 0.12.2-1 ii libavcodec56 6:11.4-2 ii libavformat56 6:11.4-2 ii libavresample26:11.4-2 ii libavutil54 6:11.4-2 ii libbluray11:0.8.1-1 ii libbs2b0 3.1.0+dfsg-2.1 ii libc6 2.19-18 ii libcaca0 0.99.beta19-2 ii libcdio-cdda1 0.83-4.2 ii libcdio-paranoia1 0.83-4.2 ii libcdio13 0.83-4.2 ii libdca0 0.0.5-7 ii libdirectfb-1.2-9 1.2.10.0-5.1 ii libdv41.0.0-6 ii libdvdread4 5.0.0-1 ii libenca0 1.16-1 ii libfaad2 2.8.0~cvs20150510-1 ii libgif4 4.1.6-11 ii libgl1-mesa-glx [libgl1] 10.5.7-1 ii libjack-jackd2-0 [libjack-0.116] 1.9.10+20140719git3eb0ae6a~dfsg-2 ii libjpeg62-turbo 1:1.4.0-7 ii liblcms2-22.6-3+b3 ii liblircclient00.9.0~pre1-1.2 ii libmad0 0.15.1b-8 ii libmpg123-0 1.20.1-2 ii libogg0 1.3.2-1 ii libpng12-01.2.50-2+b2 ii libpostproc52 6:0.git20120821-4 ii libpulse0 6.0-2 ii libquvi7 0.4.1-3 ii libsdl1.2debian 1.2.15-11 ii libsmbclient 2:4.1.17+dfsg-4 ii libspeex1 1.2~rc1.2-1 ii libswscale3 6:11.4-2 ii libtheora01.1.1+dfsg.1-6 ii libtinfo5 5.9+20150516-2 ii libvdpau1 1.1-1 ii libvorbis0a 1.3.4-2 ii libx11-6 2:1.6.3-1 ii libxext6 2:1.3.3-1 ii libxinerama1 2:1.1.3-1+b1 ii libxss1 1:1.2.2-1 ii libxv12:1.0.10-1+b1 ii libxvidcore4 2:1.3.3-1 ii libxxf86vm1 1:1.1.4-1 ii zlib1g1:1.2.8.dfsg-2+b1 mplayer2 recommends no packages. mplayer2 suggests no packages. -- no debconf information ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
qmidiroute 0.3.0-2 MIGRATED to testing
FYI: The status of the qmidiroute source package in Debian's testing distribution has changed. Previous version: 0.3.0-1 Current version: 0.3.0-2 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See https://release.debian.org/testing-watch/ for more information. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
ir.lv2 1.3.2~dfsg0-2 MIGRATED to testing
FYI: The status of the ir.lv2 source package in Debian's testing distribution has changed. Previous version: 1.3.2~dfsg0-1 Current version: 1.3.2~dfsg0-2 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See https://release.debian.org/testing-watch/ for more information. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
vco-plugins 0.3.0-3 MIGRATED to testing
FYI: The status of the vco-plugins source package in Debian's testing distribution has changed. Previous version: 0.3.0-2 Current version: 0.3.0-3 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See https://release.debian.org/testing-watch/ for more information. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
mcp-plugins 0.4.0-3 MIGRATED to testing
FYI: The status of the mcp-plugins source package in Debian's testing distribution has changed. Previous version: 0.4.0-2 Current version: 0.4.0-3 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See https://release.debian.org/testing-watch/ for more information. ___ 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#789254: This sample seems not to be processable by FFmpeg
BS1770GAIN is based on FFmpeg. If a file is not processable by FFmpeg it
is not processable by BS1770GAIN.
This particular sample file seems not to be processable by FFmpeg. Try
e.g. the following command
$ ffmpeg -i samples/20030213-cvs.mpeg -acodec copy -vcodec copy -y
20030213-cvs.mpeg
The workaround is to pre-process the file first by mkvmerge into an
intermediate MKV file and then process the resulting intermediate MKV
file by BS1770GAIN
$ mkvmerge samples/20030213-cvs.mpeg -o samples/20030213-cvs.mkv
mkvmerge v8.0.0 ('Til The Day That I Die') 64bit
'samples/20030213-cvs.mpeg': Using the demultiplexer for the format 'MPEG
program stream'.
'samples/20030213-cvs.mpeg' track 0: Using the output module for the
format 'MPEG-1/2'.
'samples/20030213-cvs.mpeg' track 1: Using the output module for the
format 'MP3'.
The file 'samples/20030213-cvs.mkv' has been opened for writing.
Warning: 'samples/20030213-cvs.mpeg' track 1: This MPEG audio track
contains 279 bytes of non-MP3 data which were skipped. The audio/video
synchronization may have been lost.
Progress: 100%
The cue entries (the index) are being written...
Muxing took 1 second.
NOTE: Please observe the warning!
$ ./mingw32/bin/bs1770gain ./samples/20030213-cvs.mkv -ao norm
analyzing ...
[1/1] 20030213-cvs.mkv:
integrated: -34.7 LUFS / 11.7 LU
transcoding ...
[1/1] 20030213-cvs.mkv
done.
Regards,
Peter Belkner
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
GREETINGS TO YOU
GREETINGS TO YOU, I WRITE TO TELL YOU OF A MATTER THAT REQUIRED AN URGENT ATTENTION WITHREGARDS TO YOUR REPOSED PERSONALITY AS A RELIABLE, TRUSTWORTHY AND GODFEARING PERSON. IN BRIEF INTRODUCTION, I AM THE ONLY DAUGTHER OF LATE MRMOHAMMAD PELAEZ FROM SIERRA-LEONE.I AND MY JUNIOR BROTHER AHMED AREPRESENTLY STAYING IN ABIDJAN COTE D'IVOIRE AS A REFUGEES. MY PARENTS WERE AMONG THE MINISTERS OF JOHNNY PAUL KOROMAH'S REGIME INSIERRA-LEONE.DURING THE INTERVENTION OF THE ECOMOG SOLDIERS TO RESTORETHE PRESIDENCY OF ALHJI TEJAN KABBAH FROM JOHNNY KOROMAH, MY FATHER WASAMONG THE 23 EXECUTED MINISTERS. BUT BEFORE THE DEATH OF MY FATHER THEREWAS A DEPOSIT OF USD$12.5 MILLION MADE BY MY LATE FATHER IN ONE OF THE FINACIAL PRIVATE SECURITY BANK IN COTE D'IVOIRE , BUT OUR CONDITION ANDPOSSIBILITIES MAKES IT VERY DIFFICULT FOR ME AND MY BROTHER AHMED TOAPPROACH ANY PERSON FOR RECOMMENDATION. EVER SINCE THEN WE HAVE BEEN RECEIVING HELP FROM OUR CAMP BECAUSE WE ARESTAYING IN REFUGES CAMP. I HOPE YOU WILL BE TOUCHED TO UNDERSTAND OURREQUEST. WE WILL LIKE YOU TO HELP US GET THIS MONEY TRANSFER TO YOURACCOUNT AND PROVIDE OR LOOK FOR A LUCRATIVE VENTURE WHERE THIS MONEY CANBE INVESTED IN YOUR COUNTRY TOGETHER WITH YOU. WE HAVE AGREED TO INVESTOUR MONEY VIABLE IN ANY OVERSEAS COUNTRY THROUGH YOUR ASSISTANCE AND DIRECTIVES. BEFORE PROCEEDING WE WILL GET TO BE MORE FAMILIAR AND ALSO GO INTO ANUNDERSTANDING WORKING AGREEMENT BECAUSE MY FAMILY'S FUTURE NON DEPEND ONTHIS VERY MONEY, I HAVE AGREED TO GIVE YOU 20% OF THE TOTAL SUM OFUSD$12.5 MILLION FOR YOUR ASSISTANCE TO US WHILE THE REST WILL BE USE TORUN THE INVESTMENT TOGETHER WITH YOU. WE SINCERELY WISH TO INTRODUCE AND MAKE YOU OUR BUSINESS PARTNER ANDADVISORY CONSULTANT OF OUR PROPOSED INVESTMENT IN YOUR COUNTRY. SO IFYOU CAN BE ABLE TO ASSIST ME PLEASE DO URGENTLY REPLY ME SO THAT I WILLLINK YOU FOR FURTHER DETAILS, AND DON'T FORGET TO GIVE ME YOUR PRIVATE TELEPHONE NUMBERS WHILE REPLYING THIS LETTER. THANKS AND BEST REGARDS YOURS SINCERELY, MISS GLORIA PELAEZ ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
lv2core 6.0+dfsg0-3 MIGRATED to testing
FYI: The status of the lv2core source package in Debian's testing distribution has changed. Previous version: 6.0+dfsg0-2 Current version: 6.0+dfsg0-3 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See https://release.debian.org/testing-watch/ for more information. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: change build deps from fltk 1.1 to 1.3
2015-06-20 12:33 GMT+02:00 Sebastian Ramacher sramac...@debian.org: On 2015-06-20 12:30:54, Sebastian Ramacher wrote: On 2015-06-20 09:45:19, Jaromír Mikeš wrote: Hi all, I recently changed build dep of yoshimi package from fltk 1.1 to 1.3. Only because this change package wanted links against 2 new libs libjpeg9-dev libxft-dev which I needed to add to build deps too to get package build. To me it is strange because if fltk 1.3 needs these libs they should be added automatically during resolving deps and I shouldn't need to add them to package build deps. But I might be wrong ;) Can someone enlighten me what is going on? Similar happen when I for test tried with zynaddsubfx package. Looks like this is caused by linking against fltk statically: | Linking CXX shared module yoshimi_lv2.so | cd /tmp/yoshimi-1.3.5/obj-x86_64-linux-gnu/LV2_Plugin /usr/bin/cmake -E cmake_link_script CMakeFiles/yoshimi_lv2.dir/link.txt --verbose=1 | /usr/bin/c++ ... /usr/lib/x86_64-linux-gnu/libfltk_images.a /usr/lib/x86_64-linux-gnu/lib/fltk_forms.a /usr/lib/x86_64-linux-gnu/libfltk_gl.a -lGL /usr/lib/x86_64-linux-gnu/libfltk.a ... This is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756563 Thank you Sebastian for investigating this issue. There is no other way than adding these extra build-deps at the moment I guess. regards mira ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
brp-pacu is marked for autoremoval from testing
brp-pacu 2.1.1+git20111020-5 is marked for autoremoval from testing on 2015-07-21 It (build-)depends on packages with these RC bugs: 786694: fftw: FTBFS with TZ=GMT-14 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
ams is marked for autoremoval from testing
ams 2.1.1-1 is marked for autoremoval from testing on 2015-07-21 It (build-)depends on packages with these RC bugs: 786694: fftw: FTBFS with TZ=GMT-14 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
sndobj is marked for autoremoval from testing
sndobj 2.6.6.1-3 is marked for autoremoval from testing on 2015-07-21 It (build-)depends on packages with these RC bugs: 786694: fftw: FTBFS with TZ=GMT-14 ___ 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#789254: This sample seems not to be processable by FFmpeg
Hi Carl Eugen, thanks for sharing. The issue under the hood is seems to be that avcodec_decode_audio4() returns with error [mp2 @ 0x9e527c0] Header missing. How to continue in such a case? Thanks and regards, Peter On 21.06.2015 23:09, Carl Eugen Hoyos wrote: On Sunday 21 June 2015 10:28:55 pm Peter Belkner wrote: What BS1770GAIN does is best approximated by the following FFmpeg command (copying the video stream, transcoding the audio stream into FLAC and muxing both into a MKV container): $ ffmpeg -i sample/20030213-cvs.mpeg -vcodec copy -acodec flac -y ffmpeg/20030213-cvs.mkv $ ffmpeg -fflags +genpts -i 20030213-cvs.mpeg -vcodec copy -acodec flac out.mkv Carl Eugen ___ 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#789254: This sample seems not to be processable by FFmpeg
[Peter Belkner] BS1770GAIN is based on FFmpeg. If a file is not processable by FFmpeg it is not processable by BS1770GAIN. This particular sample file seems not to be processable by FFmpeg. Try e.g. the following command $ ffmpeg -i samples/20030213-cvs.mpeg -acodec copy -vcodec copy -y 20030213-cvs.mpeg Thank you for looking into this, and it is good to have a way to detect if the file should work with bs1770gain or not. But are you sure the stuttering sound is due to the messages from ffmpeg in this case? I picked the MPEG file because it showed the problem and was publicly available. But as I mentioned, I see the problem with other files too, and discovered it using a non-public DV file. Here is an example DV file from the set where I discovered the problem first: % ffmpeg -i makercon-50.dv -acodec copy -vcodec copy -y makercon-50-new.dv ffmpeg version 2.7-1 Copyright (c) 2000-2015 the FFmpeg developers built with gcc 4.9.2 (Debian 4.9.2-20) configuration: --prefix=/usr --extra-version=1 --build-suffix=-ffmpeg --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --enable-gpl --enable-shared --disable-stripping --enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-librtmp --enable-libschroedinger --enable-libshine --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libxvid --enable-opengl --enable-x11grab --enable-libdc1394 --enable-libiec61883 --enable-libzvbi --enable-libzmq --enable-frei0r --enable-libx264 --enable-libsoxr --enable-openal --enable-libopencv - -enable-libx265 libavutil 54. 27.100 / 54. 27.100 libavcodec 56. 41.100 / 56. 41.100 libavformat56. 36.100 / 56. 36.100 libavdevice56. 4.100 / 56. 4.100 libavfilter 5. 16.101 / 5. 16.101 libavresample 2. 1. 0 / 2. 1. 0 libswscale 3. 1.101 / 3. 1.101 libswresample 1. 2.100 / 1. 2.100 libpostproc53. 3.100 / 53. 3.100 [dv @ 0x1524ce0] Estimating duration from bitrate, this may be inaccurate Input #0, dv, from 'makercon-50.dv': Metadata: timecode: 05:32:37:05 Duration: 00:00:03.96, start: 0.00, bitrate: 28800 kb/s Stream #0:0: Video: dvvideo, yuv420p, 720x576 [SAR 64:45 DAR 16:9], 28800 kb/s, 25 fps, 25 tbr, 25 tbn, 25 tbc Stream #0:1: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s Output #0, dv, to 'makercon-50-new.dv': Metadata: timecode: 05:32:37:05 encoder : Lavf56.36.100 Stream #0:0: Video: dvvideo, yuv420p, 720x576 [SAR 64:45 DAR 16:9], q=2-31, 28800 kb/s, 25 fps, 25 tbr, 25 tbn, 25 tbc Stream #0:1: Audio: pcm_s16le, 48000 Hz, stereo, 1536 kb/s Stream mapping: Stream #0:0 - #0:0 (copy) Stream #0:1 - #0:1 (copy) Press [q] to stop, [?] for help makercon-50.dv: Input/output error frame= 99 fps=0.0 q=-1.0 Lsize= 13922kB time=00:00:03.96 bitrate=28800.0kbits/s video:13922kB audio:742kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown % If I transcode it using bs1770gain, I end up with a file with stuttering audio. If you lack a DV file to test from, you can try yourself using the 1.1 GiB file available from URL: http://ftp.frikanalen.tv/media/625330/broadcast/DavidGallo_2007.dv . -- Happy hacking Petter Reinholdtsen ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi Reinhard, On 19.06.2015 23:50, Reinhard Tartler wrote: On Jun 18, 2015 7:15 PM, Andreas Cadhalpun andreas.cadhal...@googlemail.com wrote: The altivec optimizations on powerpc are still disabled, but I don't think this should delay the transition. I intend to fix this one way or another before stretch is released anyway. That is something that the libav package handles just fine. May I ask how you intend to address the altivec issue? Preferably the upstream build system would be changed to (optionally) only build the parts actually using hand-written altivec optimizations with '-maltivec', but not the others. This would make it possible to rely on runtime cpu detection also on powerpc. I looked into this a bit now and it's not trivial to do that, because not all uses of altivec.h are well separated from the rest of the code: * The SwsContext in libswscale's swscale_internal.h uses some vector variables and thus needs altivec.h. This and the corresponding code in libswscale/utils.c would need to get factored out into the ppc subdirectory. * The libpostproc library includes the postprocess_altivec_template.c directly in the main postprocess.c, which would also have to be factored out into a ppc subdirectory. Help with above would be very welcome. ;) If this would turn out to be infeasible in the end, we could still build a separate altivec flavor, as currently done by the libav package. The new packaging for sure builds faster, but is build time really a problem? Unnecessarily letting the build take longer than it needs is certainly not good. For example building the ffmpeg package on m68k takes about half a day and if the tests are run a full day, while the libav package takes about 3-5 days. And this is also a problem, when building with qemu for different architectures. And currently FFmpeg 2.7 failed to build on ppc64 (due to changes in configure, fixed upstream) and sparc (unaligned access causing SIGBUS, problem has been there for ages, but the test coverage increased recently, patch sent upstream). I expect FFmpeg 2.7.1 will fix those, so once that is in unstable, it would be a good time to upload the package for the transition to experimental. I'm not sure if we had consensus on what packaging should be used. Well, I have no intention of maintaining a pre-dh7-style debian/rules file. That pretty much settles the question for me. In the new packaging, libavcodec-extra is a virtual package, while the jessie This is done, so that the GPLv2-only packages can build-conflict with libavcodec-extra. shipped with a real package. How will that play with backports, that is, is there any chance that apt would prefer the libavcodec-extra package that drags in the old packages over the libavcodec-extra-NN package, which provides libavcodec-extra? That's a good catch. I tried it and apt would install the old libavcodec-extra package. So it seems we'd need to provide a transitional libavcodec-extra package from src:ffmpeg for one cycle. Best regards, Andreas ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Quoting Andreas Cadhalpun (2015-06-21 14:24:43) On 19.06.2015 23:50, Reinhard Tartler wrote: On Jun 18, 2015 7:15 PM, Andreas Cadhalpun andreas.cadhal...@googlemail.com wrote: And currently FFmpeg 2.7 failed to build on ppc64 (due to changes in configure, fixed upstream) and sparc (unaligned access causing SIGBUS, problem has been there for ages, but the test coverage increased recently, patch sent upstream). I expect FFmpeg 2.7.1 will fix those, so once that is in unstable, it would be a good time to upload the package for the transition to experimental. I'm not sure if we had consensus on what packaging should be used. Well, I have no intention of maintaining a pre-dh7-style debian/rules file. That pretty much settles the question for me. Then use a post-dh-style debian/rules file instead, as done with libav. Embedding negative connotations rarely help in discussions. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ 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#789254: This sample seems not to be processable by FFmpeg
What BS1770GAIN does is best approximated by the following FFmpeg command (copying the video stream, transcoding the audio stream into FLAC and muxing both into a MKV container): $ ffmpeg -i sample/20030213-cvs.mpeg -vcodec copy -acodec flac -y ffmpeg/20030213-cvs.mkv FFmpeg aborts with the following error message: [matroska @ 02a9ae00] Can't write packet with unknown timestamp av_interleaved_write_frame(): Invalid argument Google for that error. You will see that it is known for a long time. It's not the aim of BS1770GAIN to work around FFmpeg's bugs (it is impossible anyway). We hope that some day the bugs in FFmpeg will be fixed (a lot of them are meanwhile gone, some fixes I've provided myself.) The best way for organizing your workflow is as a first step before running BS1770gain is to remux all your files into a proper MKV using mkvmerge. In my opinion, choosing MKV as the intermediate container while working with multimedia files is the best choice anyway. Best regards, Peter ___ 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#789254: This sample seems not to be processable by FFmpeg
On Sunday 21 June 2015 10:28:55 pm Peter Belkner wrote: What BS1770GAIN does is best approximated by the following FFmpeg command (copying the video stream, transcoding the audio stream into FLAC and muxing both into a MKV container): $ ffmpeg -i sample/20030213-cvs.mpeg -vcodec copy -acodec flac -y ffmpeg/20030213-cvs.mkv $ ffmpeg -fflags +genpts -i 20030213-cvs.mpeg -vcodec copy -acodec flac out.mkv Carl Eugen ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
On 21.06.2015 22:09, Jonas Smedegaard wrote: Quoting Andreas Cadhalpun (2015-06-21 14:24:43) Well, I have no intention of maintaining a pre-dh7-style debian/rules file. That pretty much settles the question for me. Then use a post-dh-style debian/rules file instead, as done with libav. That doesn't make any difference. Embedding negative connotations rarely help in discussions. This has nothing to do with connotations. The problem is that libav's debian/rules file contains a lot of boilerplate and is rather complex. Thus it is hard to maintain. Best regards, Andreas ___ 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#789254: This sample seems not to be processable by FFmpeg
I've made an educated guess on how to continue: simply skip the package,
and it seems to work smoothly:
diff -rc ./bs1770gain-0.4.3/libffsox-2/ffsox_frame_reader.c
./bs1770gain-0.4.4-beta2/libffsox-2/ffsox_frame_reader.c
*** ./bs1770gain-0.4.3/libffsox-2/ffsox_frame_reader.c 2015-06-14
18:11:19.0 +0200
--- ./bs1770gain-0.4.4-beta2/libffsox-2/ffsox_frame_reader.c 2015-06-22
00:22:18.0 +0200
***
*** 145,152
}
if ((size=avcodec_decode_audio4(cc,frame,got_frame,pkt))0) {
! DMESSAGE(decoding audio);
! return -1;
}
pkt-size-=size;
--- 145,153
}
if ((size=avcodec_decode_audio4(cc,frame,got_frame,pkt))0) {
! // skip the package.
! pkt-size=0;
! return 0;
}
pkt-size-=size;
On 21.06.2015 23:56, Peter Belkner wrote:
Hi Carl Eugen,
thanks for sharing. The issue under the hood is seems to be that
avcodec_decode_audio4() returns with error [mp2 @ 0x9e527c0] Header
missing. How to continue in such a case?
Thanks and regards,
Peter
On 21.06.2015 23:09, Carl Eugen Hoyos wrote:
On Sunday 21 June 2015 10:28:55 pm Peter Belkner wrote:
What BS1770GAIN does is best approximated by the following FFmpeg
command (copying the video stream, transcoding the audio stream into
FLAC and muxing both into a MKV container):
$ ffmpeg -i sample/20030213-cvs.mpeg -vcodec copy -acodec flac -y
ffmpeg/20030213-cvs.mkv
$ ffmpeg -fflags +genpts -i 20030213-cvs.mpeg -vcodec copy
-acodec flac out.mkv
Carl Eugen
___
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#690744: Problem is present in jessie after upgrade from wheezy
Hi, It was working on wheezy. I have had to add an entry into /etc/rc.local to have it sleep for 10 seconds before doing a service restart. Without the sleep the network is still not ready in time. dmesg shows: [0.00] Booting Linux on physical CPU 0x0 [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.16.0-4-kirkwood (debian-ker...@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 Debian 3.16.7-ckt11-1 (2015-05-24) [0.00] CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=0005397f [0.00] CPU: VIVT data cache, VIVT instruction cache [0.00] Machine: QNAP TS-119/TS-219 [0.00] Ignoring unrecognised tag 0x41000403 [0.00] Memory policy: Data cache writeback [0.00] On node 0 totalpages: 262144 [0.00] free_area_init_node: node 0, pgdat c05d2ca4, node_mem_map eeff9000 [0.00] DMA zone: 1520 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 194560 pages, LIFO batch:31 [0.00] HighMem zone: 528 pages used for memmap [0.00] HighMem zone: 67584 pages, LIFO batch:15 [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260624 [0.00] Kernel command line: console=ttyS0,115200 root=/dev/ram initrd=0xa0,0x90 ramdisk=34816 [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Memory: 1024016K/1048576K available (3899K kernel code, 360K rwdata, 1440K rodata, 277K init, 289K bss, 24560K reserved, 270336K highmem) [0.00] Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xffc0 - 0xffe0 (2048 kB) vmalloc : 0xf000 - 0xff00 ( 240 MB) lowmem : 0xc000 - 0xef80 ( 760 MB) pkmap : 0xbfe0 - 0xc000 ( 2 MB) modules : 0xbf00 - 0xbfe0 ( 14 MB) .text : 0xc0008000 - 0xc053ee3c (5340 kB) .init : 0xc053f000 - 0xc058472c ( 278 kB) .data : 0xc0586000 - 0xc05e0068 ( 361 kB) .bss : 0xc05e0068 - 0xc062846c ( 290 kB) [0.00] NR_IRQS:114 [0.08] sched_clock: 32 bits at 200MHz, resolution 5ns, wraps every 21474836475ns [7.436581] Console: colour dummy device 80x30 [7.436602] Calibrating delay loop... 1974.27 BogoMIPS (lpj=3948544) [7.452420] pid_max: default: 32768 minimum: 301 [7.452501] Security Framework initialized [7.452538] Yama: disabled by default; enable with sysctl kernel.yama.* [7.452597] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes) [7.452611] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes) [7.453193] Initializing cgroup subsys memory [7.453223] Initializing cgroup subsys devices [7.453261] Initializing cgroup subsys freezer [7.453280] Initializing cgroup subsys net_cls [7.453314] Initializing cgroup subsys blkio [7.453339] Initializing cgroup subsys perf_event [7.453366] Initializing cgroup subsys net_prio [7.453439] CPU: Testing write buffer coherency: ok [7.453508] ftrace: allocating 16319 entries in 32 pages [7.468454] Setting up static identity map for 0x3b04b0 - 0x3b0508 [7.470826] devtmpfs: initialized [7.472930] pinctrl core: initialized pinctrl subsystem [7.473274] regulator-dummy: no parameters [7.473597] NET: Registered protocol family 16 [7.473871] DMA: preallocated 256 KiB pool for atomic coherent allocations [7.474711] cpuidle: using governor ladder [7.474731] cpuidle: using governor menu [7.474784] Kirkwood: MV88F6282-Rev-A1, TCLK=2. [7.474801] Feroceon L2: Enabling L2 [7.474828] Feroceon L2: Cache support initialised. [7.475287] initial MPP regs: 0111 43303311 [7.475302] final MPP regs: 0155 03303311 [7.476130] Kirkwood PCIe port 0: link up [7.476135] Kirkwood PCIe port 1: link up [7.476140] PCI: bus0 uses PCIe port 0 [7.476289] PCI host bridge to bus :00 [7.476302] pci_bus :00: root bus resource [mem 0xe000-0xe7ff] [7.476309] pci_bus :00: root bus resource [io 0x1000-0x] [7.476316] pci_bus :00: No busn resource found for root bus, will use [bus 00-ff] [7.476337] pci :00:00.0: [11ab:6282] type 00 class 0x058000 [7.476354] pci :00:00.0: reg 0x10: [mem 0xf100-0xf10f 64bit pref] [7.476363] pci :00:00.0: reg 0x18: [mem 0x-0x3fff] [7.476396] pci :00:00.0: supports D1 D2 [
Bug#789256: cmus: Pulls in unwanted and potentially dangerous DECnet packages through libroar2
On Sat, Jun 20, 2015 at 07:31:50PM -0500, Jonas Smedegaard wrote: Quoting Don Armstrong (2015-06-20 14:38:25) There's clearly a bug here, but even after reading this bug log, I've had to do research on my own to determine what that issue is. If the libroar2 maintainers which to keep decnet support, then someone should probably figure out how to circumvent waiting for the DECnet to settle when it isn't actually configured, and propose a patch to do that. Even just checking for the existence of dnet-common or similar would probably be enough. As I understand it, these are the issues raised here: a) libdnet is unmaintained and thus potentially dangerous to link against b) dnet-common commonly (or always by default?) cause whole system to hang I disagree that any of above are bugs in cmus. The bit where you and Adrian appear to be talking past each other is: c) cmus Recommends roar. (which it didn't in the Wheezy release) So anyone installing cmus on a default system (or upgrading from Wheezy) gets pulled into this. Demoting that to (at least) Suggests was discussed before this bug was opened (in a thread that unfortunately didn't hit the BTS since it was CC'd to an archived bug when Adrian reported it). Alessio already acknowledged that would be a good idea and suggested that Adrian open this bug to discuss whether even the Suggests was still appropriate if installing that suggestion had the same outcome. To quote Alessio replying to Adrian on that: I acknowledge your request, it seems legit to me to demote libroar2 from Recommends to Suggests. Could you please file a bug and set its severity to important? Furthermore, since I have removed 680...@bugs.debian.org from the CC: field as the bug is archived and no longer accepts mails, It would be great if you could attach our discussion to the report for future reference. [1] and his earlier reply re DECNet to Stephan: While it might not be a common feature, it is a feature none the less. One that relies on functionalities provided by a factually dead software; please get rid of it. Meanwhile I'll be demoting cmus's libroar dependency from Recommends to Suggests. If roaraudio's maintainers do not show willingness to cooperate, then we'll hand this to the TC and see. I don't have a dog in this race, beyond being CC'd to request some background clarification in the initial thread, and hoping you all get on the same page about it soon so it will stop filling my inbox. I don't particularly care what you choose to do, but roar pulls in DECNet - DECNet breaks people's existing systems is hardly a new problem. People mostly just had a brief respite from it, since for Wheezy packages that people did actually want stopped pulling in roar ... Now that problem is back. The solutions are all pretty easy, you just need to pick one. Ignoring it isn't really in the solution set though, so please do pick one some way or another :) hth, Ron ___ 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#789256: cmus: Pulls in unwanted and potentially dangerous DECnet packages through libroar2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/21/2015 02:31 AM, Jonas Smedegaard wrote: Even just checking for the existence of dnet-common or similar would probably be enough. As I understand it, these are the issues raised here: You understand incorrectly then. a) libdnet is unmaintained and thus potentially dangerous to link against b) dnet-common commonly (or always by default?) cause whole system to hang *Not* dnet-common, _libdnet_, seriously, read what I wrote! I disagree that any of above are bugs in cmus. Again, you are not reading what I wrote. Please leave the discussion if you refuse to do so! Alessio Teglia, one of the cmus maintainers himself said Please file a bug report against cmus and ask for libroar2 to be demoted from Recommends to Suggests. Fy fæn, Jonas. Les hva folk skrev før to du svarer eposten! Adrian - -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVhnXhAAoJEHQmOzf1tfkTzrgP/R7g/iExaetW+ERX6ciKWmCA 5UcsgGBIRqdYiweQ92KvXoAJjCj4RdnkaibGf/Pu9PmNOIaPgYvAaokfYioUtmq4 ctklcoqUADTjO5Kpx6hTaZYIVtfcTMfC+34kZAVcXDFo+7MBcLQ9fwv/M+MMxpP9 EqAq0OGn1+EnBs6eaQJmaA3clNRI18pntl6L9um5MJ5H6OIwTasdOGNeFI+0RQ6V 2S82O2HmkQUxrNu7G9rkF/jGSBciHOCb9HQBvmNKi70Pk34tew52DallgtNDyK97 a781ez7iKHf9Zgs3q2C3rwIxWWPaeRvGA2uj+PP+e2VuWuPAh1Y8CBCMkstyzKV4 0egyMNQCrJXxK6X+1IHTh5IgqUd8NVzdloCNcrDBaW8S7UD11h8tPW0xNIuDvJ/4 PeUyv5rKpy98AdR9oywdzHe/b/vnujYKqwdVmpDWRscePYHKZKph98Mzh7OX81Rk 4yRtcp0hZRCslpJUuInJYl6Ai0fTsUgBXOvta2WnFE84fHOCmpDDomZLVwg5R5ji FkyWydO8QbgzP7XSrlK9f9uh1wh1rQVHgZkFIkc/U/SDiuyYNxwPe6+kMwkOg/HW pGIVnA92WsONW61AMj3uTXx3y7+hVvoykrm7TRyhPEh/aLhkOUgkAD2U1Zs1a2HZ frDyVUPWxnNVYzjBnNIF =uXlC -END PGP SIGNATURE- ___ 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#789256: cmus: Pulls in unwanted and potentially dangerous DECnet packages through libroar2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/21/2015 02:36 AM, Jonas Smedegaard wrote: Quoting John Paul Adrian Glaubitz (2015-06-20 15:16:28) You are still trying to boil this down to the mere problem with cmus, This bugreport is filed against cmus, is it not? This is correct. Upon the request of the maintainer of cmus who already prepared an upload which is why the bug is set to pending. but that's just a side effect. The real point is that roaraudio depends on an unmaintained piece of core software which Debian would like to get rid of. Then please reassign and retitle the bugreport to discuss the real issue where it belongs. No, we won't, because: a) Alessio asked for this bug report b) Patrick Matthei refuses to make any changes to libroar2 to help fix this problem c) You apparently continue to refuse to read what people write to explain the situation Thanks, Adrian - -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVhnZVAAoJEHQmOzf1tfkTno8P/jF985wsP8axAb03BEVLZsfl 9F8R7Q+C6EJDtRXRvl2oauGyqC7sB4ci9yqFpGb5E+dkMnNqNRfZv0qiJaxqqul+ iW9KpJqHK/1Kfd+LphWPMl7UfFORDmmoNU9t7Af89s+WwLnf7nlKRI/m9JRBSBCH Tt16iHYRnwFSlNWSI1oBFh2MHUdXkB6TwYL+NxCRQZcTvdn+v8cCZugAGNBNwxn9 4SU/KJPePET3I6GECed+tTnBBEDsd57Dos8eL/TTcs0G5DgUPSi8mXUKecfCIanq yOkuU60eUfOFte3mmvOtwu5DDx1bdZc8+u+Z0zep8dLfFAMq+iYO6ShpVu0He1IF sDop02C0D90DppJpA6c2UA/+/dlIhPnuR6nOMejej8iNNhGlgq/DYq0zuIkaYvhg AOHFIlO2n1N8GNY8bSWdura14E8ltpuESd9uXeIXcjEz2R4Kop9OvOqC3OEaiYSz gPUus8W0rnwRkpzEtVC3zNmdKuGJhK4L1oNLHM34w0F7WaWwKqKo1Ky99B15+I3I qSFs6sqOGnLjSlo6McFYUPBNuQYk48kiB8OMsNoG6rRZZ4Xw3JWYIxwIoKMRhmWi VHycyTfOLbNEbZ0muQsSMdu9IEXpg8gJ1MtfjVyBhAMERjlXJce3Elbe0c/LRuCz O+S9jh+kmhNuZYqek6j4 =YEkB -END PGP SIGNATURE- ___ 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#789256: cmus: Pulls in unwanted and potentially dangerous DECnet packages through libroar2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/21/2015 02:44 AM, Jonas Smedegaard wrote: Jonas, do you actually read what I wrote? Yes. No, you don't, because you constantly say the bug report is not correct even though a) Alessio requested it and b) already tagged this bug as pending which means he already made the change. This very bug report exists because the maintainer of roaraudio refuses to handle any bug reports regarding this issue That is no excuse for barking up the wrong tree: The proper way to escalate is to move the bugreport for the real issue to the technical committee. There is no barking up the wrong tree if the one sitting on the tree asked me to. I don't even know why you jumped into this bug report with apparently not enough background information to join the discussion. Please don't paint me as an ignorant fool when you're the one who is constantly ignoring the facts. I'm really tired of such allegations, I don't deserve being treated like an idiot here for all the work I do in Debian. The sole reason for this bug report is to free cmus from broken and unwanted dependencies. ...and the sole relevancy to discuss in this bugreport is therefore the bug reported. No. This bug report exists because Alessio asked for it because Patrick was asked several times and never responded. That's why the decision was made by several people - including Alessio - to drop libroar2 from Recommends to Suggests. It seems there are disagreement if cmus is broken and if the dependency is unwanted. There is no disagreement between the people in charge. There is just disagreement between the people in charge and bystanders who are apparently not correctly informed because they don't read mail. And since discussing this under these circumstances is futile and Alessio has made the change anyway, I will pull out of this discussion now. Adrian - -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVhnf0AAoJEHQmOzf1tfkTtnwQAIua12zw+7unxpFZdT/l+PZw e3Gd/aR2QULnTKnMVyQxgUrQkS+CtyAjAS1oICM1HHvjh5VEz68xvfFN93yu2Hli 1AUj72Ro3+pXwPcYY8Q1YcDBOrqkgFSajtoi/4/FVgK9q8RZQIATorkOJUBWsZ8P h7OWy3WQ5o4xPQ54SfG/U2N61abU32TA045yI3vRfwSk9H5y9kIpyhC6E5236RdN DnOHJkRXUCHzuasKvQ+MenA29UXmz06FP0ob/wnMpkVONlfahSLSJd/T2wh5mQb1 w6JHcAiNPTzJ/hVOG+EySCkEO/D6ZCOYx8ADuDajlcCrfhRLO6HVY8fsSNHmmhY6 h7S5dqoP5R0cWPCWZYZMWFqxTUTUuRdoApiRa9f3slw+FqFQH3c0xd8juTyQ11WA SpHRi1xe0OS6rNNiIIcVPyzZobzTxBo86hg7CKfPFaQOEkqYj1+RRXY9q7s/VVt/ XcgZT75UjvKqwvWJbg1fHawez0VawWDvQ93BVBnD+0IQX7u4ta7ssIoE7rXsC5u6 cjnm+JrIRJraSeKcAIkGs3vn9PfRkqIwe22lxJXKy/4tMi98ghdXimZBZ7jNGQyv WqRnKpkYV3zTyBNnfQNfKL9XY0FJuCLD469/pntIBZCJZ8gigMLuOffg51ETJFNX IDSva4QYpUpR01vcFgWC =v9bO -END PGP SIGNATURE- ___ 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#788680: openni: FTBFS on mipsel Unknown platform: mips64
Hi. Attached is a patch for enabling building openni for mipsel arch. Can you please do a peer review? Thanks, Gustavo Prado Alkmim Bacharel em Ciência da Computação (UFLA) Doutorando em Ciência da Computação (UNICAMP) -- Do que adianta para o homem ganhar o mundo e perder sua alma??? 2015-06-14 6:56 GMT-03:00 James Cowgill james...@cowgill.org.uk: Control: severity -1 important On Sun, 2015-06-14 at 08:51 +0100, Gustavo Prado Alkmim wrote: Package: openni Version: 1.5.4.0-12 Severity: serious Justification: fails to build from source Dear Maintainer, Package is failing to build on buildd. I'm working on a fix and I will attach it as soon as possible. Full log is attached. Since openni has never built on mipsel (it's in the uncompiled state), this bug is not RC. I see you're working on the mips ports as part of GSoC - patches are welcome :) James diff -rupN openni-1.5.4.0/debian/patches/0015-Add-mipsel-support.patch new.openni-1.5.4.0/debian/patches/0015-Add-mipsel-support.patch --- openni-1.5.4.0/debian/patches/0015-Add-mipsel-support.patch 1970-01-01 00:00:00.0 + +++ new.openni-1.5.4.0/debian/patches/0015-Add-mipsel-support.patch 2015-06-20 21:30:36.359637995 + @@ -0,0 +1,182 @@ +Index: new.openni-1.5.4.0/Include/XnPlatform.h +=== +--- new.openni-1.5.4.0.orig/Include/XnPlatform.h new.openni-1.5.4.0/Include/XnPlatform.h +@@ -37,6 +37,7 @@ + #define XN_PLATFORM_ANDROID_ARM 9 + #define XN_PLATFORM_LINUX_POWERPC 10 + #define XN_PLATFORM_LINUX_AARCH64 11 ++#define XN_PLATFORM_LINUX_MIPSEL 12 + + #define XN_PLATFORM_IS_LITTLE_ENDIAN 1 + #define XN_PLATFORM_IS_BIG_ENDIAN2 +@@ -72,6 +73,8 @@ + #include Linux-AArch64/XnPlatformLinux-AArch64.h + #elif (__linux__ __powerpc__) + #include Linux-Powerpc/XnPlatformLinux-Powerpc.h ++#elif (__linux__ __mips__) ++ #include Linux-Mipsel/XnPlatformLinux-Mipsel.h + #elif _ARC + #include ARC/XnPlatformARC.h + #elif (__APPLE__) +Index: new.openni-1.5.4.0/Platform/Linux/Build/Common/CommonDefs.mak +=== +--- new.openni-1.5.4.0.orig/Platform/Linux/Build/Common/CommonDefs.mak new.openni-1.5.4.0/Platform/Linux/Build/Common/CommonDefs.mak +@@ -22,6 +22,8 @@ else ifneq (,$(findstring aarch64,$(MACH + HOST_PLATFORM = AArch64 + else ifneq (,$(findstring ppc,$(MACHINE))) + HOST_PLATFORM = Powerpc ++else ifneq (,$(findstring mips,$(MACHINE))) ++ HOST_PLATFORM = Mipsel + else + DUMMY:=$(error Can't determine host platform) + endif +Index: new.openni-1.5.4.0/Platform/Linux/Build/Common/Platform.Mipsel +=== +--- /dev/null new.openni-1.5.4.0/Platform/Linux/Build/Common/Platform.Mipsel +@@ -0,0 +1,11 @@ ++export GLUT_SUPPORTED=1 ++ ++ifeq $(CFG) Release ++ ++# Optimization level, minus currently buggy optimizing methods (which break bit-exact) ++CFLAGS += -O3 -fno-tree-pre -fno-strict-aliasing ++ ++# More optimization flags ++CFLAGS += -ftree-vectorize -ffast-math -funsafe-math-optimizations -fsingle-precision-constant ++ ++endif +Index: new.openni-1.5.4.0/Samples/NiViewer/NiViewer.cpp +=== +--- new.openni-1.5.4.0.orig/Samples/NiViewer/NiViewer.cpp new.openni-1.5.4.0/Samples/NiViewer/NiViewer.cpp +@@ -49,7 +49,7 @@ + // + #include XnCppWrapper.h + +-#if (XN_PLATFORM == XN_PLATFORM_LINUX_X86 || XN_PLATFORM == XN_PLATFORM_LINUX_ARM || XN_PLATFORM == XN_PLATFORM_LINUX_AARCH64 || XN_PLATFORM == XN_PLATFORM_LINUX_POWERPC) ++#if (XN_PLATFORM == XN_PLATFORM_LINUX_X86 || XN_PLATFORM == XN_PLATFORM_LINUX_ARM || XN_PLATFORM == XN_PLATFORM_LINUX_AARCH64 || XN_PLATFORM == XN_PLATFORM_LINUX_POWERPC || XN_PLATFORM == XN_PLATFORM_LINUX_MIPSEL) + #define UNIX + #define GLX_GLXEXT_LEGACY + #endif +@@ -79,7 +79,7 @@ using namespace glh; + #if (XN_PLATFORM == XN_PLATFORM_WIN32) + #include conio.h + #include direct.h +-#elif (XN_PLATFORM == XN_PLATFORM_LINUX_X86 || XN_PLATFORM == XN_PLATFORM_LINUX_ARM || XN_PLATFORM == XN_PLATFORM_LINUX_AARCH64 || XN_PLATFORM == XN_PLATFORM_MACOSX || XN_PLATFORM_LINUX_POWERPC) ++#elif (XN_PLATFORM == XN_PLATFORM_LINUX_X86 || XN_PLATFORM == XN_PLATFORM_LINUX_ARM || XN_PLATFORM == XN_PLATFORM_LINUX_AARCH64 || XN_PLATFORM == XN_PLATFORM_MACOSX || XN_PLATFORM_LINUX_POWERPC || XN_PLATFORM == XN_PLATFORM_LINUX_MIPSEL) + #define _getch() getchar() + #endif + +Index: new.openni-1.5.4.0/Source/OpenNI/XnOpenNI.cpp +=== +--- new.openni-1.5.4.0.orig/Source/OpenNI/XnOpenNI.cpp new.openni-1.5.4.0/Source/OpenNI/XnOpenNI.cpp +@@ -7062,7 +7062,7 @@ XN_C_API XnStatus xnScriptNodeRun(XnNode + #define XN_OPEN_NI_FILES_LOCATION \\Data\\ + #elif (CE4100) + #define XN_OPEN_NI_FILES_LOCATION /usr/etc/ni/ +-#elif (XN_PLATFORM ==
Bug#789256: cmus: Pulls in unwanted and potentially dangerous DECnet packages through libroar2
Hi Adrian, On Sun, Jun 21, 2015 at 10:29:21AM +0200, John Paul Adrian Glaubitz wrote: On 06/21/2015 02:31 AM, Jonas Smedegaard wrote: Even just checking for the existence of dnet-common or similar would probably be enough. As I understand it, these are the issues raised here: You understand incorrectly then. a) libdnet is unmaintained and thus potentially dangerous to link against b) dnet-common commonly (or always by default?) cause whole system to hang *Not* dnet-common, _libdnet_, seriously, read what I wrote! libdnet is just a wrapper. You are jumping to unconfirmed conclusions here. I disagree that any of above are bugs in cmus. Again, you are not reading what I wrote. Please leave the discussion if you refuse to do so! Alessio Teglia, one of the cmus maintainers himself said Please file a bug report against cmus and ask for libroar2 to be demoted from Recommends to Suggests. The roar and pulse dependencies are now only installed per suggests. You will probably still get the unconfirmed bug if you use the --install-suggests switch for apt. As that will pullin the stuff. Maybe the proper way might have been to put them into seperate plugin binary packages like it is done for cmus-plugin-ffmpeg? If not then you will encounter the funny problem that cmus might not start anymore if you don't have libroar or libpulse installed. In my test it produced a considerable hang on the first launch while it tried to find a audio output. Btw. I could neither reproduce your bug on a debian jessie - testing upgrade. You did a great job there. 1. Threatening with the Technical Commitee Sledgehammer against cmus 2. Possible usability problems for cmus 3. Doing nothing to fix or locate the original problem The propper course of action, regardless if dnprogs is unmaintained or not, would have been to debugg the problem. After that to clearly isolate the component inside roaraudio/dnet/cmus/whatever and then file a appropriate bug. If this would then be a request to drop the linkage or a bugfix against one of the componts doesn't matter. You could have simply opened a bugrequest against roaraudio to drop the decnet dependency and then if nothing happens consulted the TC. If you would have read the two bugrequests you have linked then you would find out that these were either already answered with a description and a note that dnet-common won't be a recommended dep anymore or that there are next to no informations at all. But neither are you fixing the problem at the right place nor is unclear if you are fixing it at all. What is if its a legitimate bug? Now others will stumble upon it and have to work it out themselves. While it could have been debugged without much invested time on your side. If this is how debian works nowdays I am unsure if i want to continue using it. Why do i even care? Sorry if you see it as insultive, but it seems to me that you fail to see reason and are just mindlessly focussed on getting rid of roaraudio via the wrong methods and actions. Thanks. Fy fæn, Jonas. Les hva folk skrev før to du svarer eposten! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 Kind Regards, Stephan signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
