Accepted mpeg2dec 0.5.1-8 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 09 Jul 2017 21:49:12 +0200 Source: mpeg2dec Binary: libmpeg2-4-dev libmpeg2-4 mpeg2dec Architecture: source amd64 Version: 0.5.1-8 Distribution: unstable Urgency: medium Maintainer: Debian Multimedia Maintainers Changed-By: Loïc Minier Description: libmpeg2-4 - MPEG1 and MPEG2 video decoder library libmpeg2-4-dev - libmpeg2 development libraries and headers mpeg2dec - Simple libmpeg2 video decoder application Changes: mpeg2dec (0.5.1-8) unstable; urgency=medium . * Bump Standards-Version to 4.0.0 * Drop myself from Uploaders Checksums-Sha1: 332e574c2d9dcf93fd8b983b67f228916d02de3a 2171 mpeg2dec_0.5.1-8.dsc 30725dfe46ab593070b7f59ef10d4da99144 10220 mpeg2dec_0.5.1-8.debian.tar.xz f855aa0b7a6761b57c037689afce6b632e12b00d 106144 libmpeg2-4-dbgsym_0.5.1-8_amd64.deb 1e24fa4060dc20b9e264fff3d457ef53d9149829 76336 libmpeg2-4-dev_0.5.1-8_amd64.deb f79564143f4d206a47aa178ee632f3d2a8c4f8f8 62122 libmpeg2-4_0.5.1-8_amd64.deb f60f9d320a1de2b99c74de6648c1171fa06fd95b 63510 mpeg2dec-dbgsym_0.5.1-8_amd64.deb eedf937c8fdab1e8cb78dc55319e2c0ae0d15c06 9023 mpeg2dec_0.5.1-8_amd64.buildinfo 0ad22a217dd97041dc24c31908c6df4f8b791e5a 40610 mpeg2dec_0.5.1-8_amd64.deb Checksums-Sha256: d3ec3ced5655b44da3b3990f6f73bd8300286234d226ac9ced8883598ff6e456 2171 mpeg2dec_0.5.1-8.dsc 6a5da060e35cf010a0d0d01f2ed16bfcd55dd5f0fa40c5667cc99563f080008e 10220 mpeg2dec_0.5.1-8.debian.tar.xz c3cd535b92040fa770c7980dc1c8083f06380ddb8745fc8abe15fd44d4504fea 106144 libmpeg2-4-dbgsym_0.5.1-8_amd64.deb e85aacea14b341b9ba56d3c421f84676091ad0f5596d8f19d0aa7aec849549f1 76336 libmpeg2-4-dev_0.5.1-8_amd64.deb 395454259a0a1bbb94da9dfb50c072909e0699144371866e7f24241504d2359b 62122 libmpeg2-4_0.5.1-8_amd64.deb 97ddf376f608b5e0a2744e29d4eb83ddae2c5f64f8312cedba75979b3d35c4d3 63510 mpeg2dec-dbgsym_0.5.1-8_amd64.deb b40c412485ff4f5d790210fddbc9125ccf13b6aefd52f47f5127706d45bd47e4 9023 mpeg2dec_0.5.1-8_amd64.buildinfo 48c4612c14420cf283aa1d7114db8714260b8bdd7443a91f6b4054f75bbe59af 40610 mpeg2dec_0.5.1-8_amd64.deb Files: 1bb866b7884632441ffde4a314605d4e 2171 libs optional mpeg2dec_0.5.1-8.dsc c870afb3fc45e90994b9b636d71056f4 10220 libs optional mpeg2dec_0.5.1-8.debian.tar.xz d191494127372ad18f774e82578d14d0 106144 debug extra libmpeg2-4-dbgsym_0.5.1-8_amd64.deb db35c082ac22389ba39cb12aa5497511 76336 libdevel optional libmpeg2-4-dev_0.5.1-8_amd64.deb 1b30845c3a7def47754b2a326fa9bab2 62122 libs optional libmpeg2-4_0.5.1-8_amd64.deb c8a58bace5c26ffa23b7b997b007ab18 63510 debug extra mpeg2dec-dbgsym_0.5.1-8_amd64.deb c009f91eb095a6773a6dffce100ae021 9023 libs optional mpeg2dec_0.5.1-8_amd64.buildinfo e03e6411898cb04c5c5d7062716244d9 40610 x11 optional mpeg2dec_0.5.1-8_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJZYqYQAAoJEPEUCEwIYRER4E8P/ixNU/n/WAAYlrmoEHBB1wxr 5/BIIPOZAFW07HgYeSsvJFvR7/PeefYEtJAgDFm4OslQrGXuL+PZiVZhBMJbS+Ou tC4LoBMUEq+fEqsPcqVHQFJ9aJbmM39we4dpxdBMiazTbCQg3UgX28DfC92ZCNQb cDTSCiAngqwzNxDD5Kl5ndYg3bTt4iSn71+Ymk3hvzz6exq9lYjGD+fgR8PtzCZ+ stf7xQcDyHgnUWzv48l9O/LE9LO4liQvPkGAWNP8gXJaFDRXyWK6qIoTEqHZVx2K isw9EVaGSpcScB46KjUb50uatvYPM6QpuoScLnP236aOm1XOc2JRDGVr6xurbGH7 A1VPbjXMaoSoJ/rnRZkxOcyiglgarSb1/T/Zc82aOMiLEF4CX/NdLtAcx2QjSlrt yHS/Mp7euQteE+cm7ROZbEAsUHZN4TfoB8S+6WiY+deX0uztP+7rwXnirg/Rx3rR 1A5gpgpNyhaRu2XGQlWOomc/haAWTzCbw9fDs4XWI8Mh2OOW69n3Ec04Fxoyf3gd EPo49ZkAcueLOjiaItl+hP4AswabpDl5HqqlPZ3JdoKZNeKEhUqSSa6h5BeY2Pmm S8yy4XOMvYkvs4kDjXORmUFAtaJa+zdP46rv6RpaB/o4JGLHzX8cT2q0/UEcwTST +Sgwk8DSHvRjoV5MVT2p =920w -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#693040: [libav-devel] Strange build failure on several archs in Debian.
Hey, On Tue, Nov 13, 2012, Reinhard Tartler wrote: > In the context of bug #693040, Måns had an unrelated question that I > would like to forward to you, as you have tuned the package flavors > for arm. (Cc:ing #693040) > On Tue, Nov 13, 2012 at 3:23 PM, Måns Rullgård wrote: > > BTW, why are you building armv4+vfp? > > That makes no sense whatsoever since VFP has never been used with > > anything prior to armv5, and in practice it is only found with armv6 and > > later. First some context: Debian and Ubuntu maintain(ed) multiple ARM ports; usually one port per ABI. "arm" is an obsolete OABI port. Debian and Ubuntu used mainly an "armel" port for some years which was EABI and soft-float calling conventions, and both now have an increasingly popular "armhf" port for EABI with hard-float calling conventions. Debian or Ubuntu releases or any distro derivative can pick different toolchain optimization defaults for the armel and armhf ports -- as long as they honor the calling conventions -- so that Debian squeeze or wheezy or Ubuntu lucid or precise can have different levels of optimizations (armv4, armv5, armv6, armv7 etc.). Some even turn VFP on in the armel port (softfp). The Debian/Ubuntu libav packaging ships multiple builds depending on the distro toolchain defaults. If the toolchain doesn't enable VFP by default, then a VFP pass is built; if the toolchain doesn't enable NEON by default, then a NEON pass is built; etc. I guess the libav build you're seeing with armv4 + softfp is the VFP pass for the Debian armel port. It's using the toolchain defaults (armv4 + float-abi=soft) for the main build and turns on VFP (-mfpu=vfp --float-abi=softfp) for the VFP pass. If there's absolutely NO ARMv4 hardware with VFP ever going to run Debian armel and if enabling ARMv5 would greatly benefit the builds, then we could special case this and force -march=armv5 for the vfp pass if the toolchain defaults to armv4. However, if there's some ARMv4 hardware with VFP around, the vfp flavor of libav might get picked up by hwcaps and that will cause SIGILL at runtime if we enable ARMv5 instructions. I'm afraid I have no knowledge of what ARMv4 hardware we still care for in Debian, nor whether there's a hwcap for ARMv5 that we could use here; happy to follow recommendations! Cheers, -- Loïc Minier ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Accepted mpeg2dec 0.5.1-5 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 01 Jul 2012 23:35:15 +0200 Source: mpeg2dec Binary: libmpeg2-4-dev libmpeg2-4 mpeg2dec Architecture: source amd64 Version: 0.5.1-5 Distribution: unstable Urgency: low Maintainer: Debian Multimedia Maintainers Changed-By: Loïc Minier Description: libmpeg2-4 - MPEG1 and MPEG2 video decoder library libmpeg2-4-dev - libmpeg2 development libraries and headers mpeg2dec - Simple libmpeg2 video decoder application Changes: mpeg2dec (0.5.1-5) unstable; urgency=low . * Update patch 65_arm-test-with-compiler to only set ARCH_ARM when optimizations are built; ARCH_ARM is really used as a test for whether to use ARM optimizations or not in the sources; also cleanup autotools syntax with proper AC_LANG(C), AC_LANG_SOURCE and quoting. Checksums-Sha1: 2c2b270102bee3eec0fde40e7be323143bd769e0 1557 mpeg2dec_0.5.1-5.dsc 16f89836d6992d7a892a58c8fb6c2fdbd74351e7 569123 mpeg2dec_0.5.1-5.debian.tar.gz 21222e2afc2728f29b7282da2f298959a3796ef5 88856 libmpeg2-4-dev_0.5.1-5_amd64.deb 15992c9a839e1b3cacb6964f2b8aeaf67ac787d2 71530 libmpeg2-4_0.5.1-5_amd64.deb f2488b1df9f20434f88d797f970b6245460c4fd7 43790 mpeg2dec_0.5.1-5_amd64.deb Checksums-Sha256: 6f91c1d3f71fefa4604ad43e46f20008db89b22a4f935a46aedc50886bfe836f 1557 mpeg2dec_0.5.1-5.dsc 1b5f9050728b77214e44cad5b8cf8dea01ea9a2a0374dbd624d22991fadda2f7 569123 mpeg2dec_0.5.1-5.debian.tar.gz 323041367d1ef83372fc3847a7874e4d5360e279c2b2f0658193921f9d47b410 88856 libmpeg2-4-dev_0.5.1-5_amd64.deb d745d1434dcadc9de834e9c1b8aadf8a7a323d4a8e0cfa40e49cfb6820327538 71530 libmpeg2-4_0.5.1-5_amd64.deb d775d71f0e50a9b9c3ee418a1cc3660d3538bde5e8ed55e5c8e81f078dd43ac3 43790 mpeg2dec_0.5.1-5_amd64.deb Files: 09251de6b76753dc1bb9eef47fe89806 1557 libs optional mpeg2dec_0.5.1-5.dsc 5563ed9132f14be530bc29ff17649804 569123 libs optional mpeg2dec_0.5.1-5.debian.tar.gz c5a3cfd6e342b63a25aa8507bc466a77 88856 libdevel optional libmpeg2-4-dev_0.5.1-5_amd64.deb c6e4ee4416cd3ea21e0fa0046a22acc1 71530 libs optional libmpeg2-4_0.5.1-5_amd64.deb 8b6763027266d5ae4dc3e8c50288522f 43790 x11 optional mpeg2dec_0.5.1-5_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk/wxTAACgkQ4VUX8isJIMD9tgCeOePeMbciK2rEvge38gLgM7Pr ttMAn0LgBBMRZ1wWofXIRbLM41abmOEs =qQRY -END PGP SIGNATURE- Accepted: libmpeg2-4-dev_0.5.1-5_amd64.deb to main/m/mpeg2dec/libmpeg2-4-dev_0.5.1-5_amd64.deb libmpeg2-4_0.5.1-5_amd64.deb to main/m/mpeg2dec/libmpeg2-4_0.5.1-5_amd64.deb mpeg2dec_0.5.1-5.debian.tar.gz to main/m/mpeg2dec/mpeg2dec_0.5.1-5.debian.tar.gz mpeg2dec_0.5.1-5.dsc to main/m/mpeg2dec/mpeg2dec_0.5.1-5.dsc mpeg2dec_0.5.1-5_amd64.deb to main/m/mpeg2dec/mpeg2dec_0.5.1-5_amd64.deb ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Accepted mpeg2dec 0.5.1-4 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 01 Jul 2012 16:57:29 +0200 Source: mpeg2dec Binary: libmpeg2-4-dev libmpeg2-4 mpeg2dec Architecture: source amd64 Version: 0.5.1-4 Distribution: unstable Urgency: low Maintainer: Debian Multimedia Maintainers Changed-By: Loïc Minier Description: libmpeg2-4 - MPEG1 and MPEG2 video decoder library libmpeg2-4-dev - libmpeg2 development libraries and headers mpeg2dec - Simple libmpeg2 video decoder application Closes: 679178 Changes: mpeg2dec (0.5.1-4) unstable; urgency=low . * Fix ARM tests in configure.ac to check for availability of the "pld [r1]" assembly snippet rather than relying on triplets; drop ARM specific logic from rules; closes: #679178. NB: these ARM specific optimizations aren't picked up at runtime due to lack of autodetection on ARM. Checksums-Sha1: be984287ae44c3e0143c6d1c82aa727bd388b102 1557 mpeg2dec_0.5.1-4.dsc 49282c95d045ffd494e2f67014c5020b02e7d230 569019 mpeg2dec_0.5.1-4.debian.tar.gz 5487af3653880caf23128c6f6ca2194e71a82b1b 88750 libmpeg2-4-dev_0.5.1-4_amd64.deb c483c92634433a8b579a476dedf389427c304fd0 71418 libmpeg2-4_0.5.1-4_amd64.deb 608ab05e0892996f194289d295cf87a64a6cbae5 43658 mpeg2dec_0.5.1-4_amd64.deb Checksums-Sha256: e0ecac49af6f4f340dd730ff9cb5a7312e1cf525ab8e9ed80c5dfce8ed847b4b 1557 mpeg2dec_0.5.1-4.dsc 1d0016a009225df1c9e3ecc629d997e038ccca893d7b6b20f379d6bc49f82f9c 569019 mpeg2dec_0.5.1-4.debian.tar.gz 5e2d7719521f93ff8245b69f0df8efa5ead3ad89a4a7e01cbd4eab183c7cf9aa 88750 libmpeg2-4-dev_0.5.1-4_amd64.deb 485a5f83c69e622311f886d73556e054f12a722d77531ba1240ac6d95d46532f 71418 libmpeg2-4_0.5.1-4_amd64.deb b0b3c02049c62d70d88285e31a8226c1ccfce97206e30f052d94aa56f98ea469 43658 mpeg2dec_0.5.1-4_amd64.deb Files: e1b42020179dc7ab5634e71363f0d437 1557 libs optional mpeg2dec_0.5.1-4.dsc a25d3ce191b9234cff32f4314733f3ea 569019 libs optional mpeg2dec_0.5.1-4.debian.tar.gz b8c36b7dcc442e13c93e2b4e8080c42d 88750 libdevel optional libmpeg2-4-dev_0.5.1-4_amd64.deb 7ac9ce9c7b49434266d40252c2c08854 71418 libs optional libmpeg2-4_0.5.1-4_amd64.deb 23c3bec2d4b7344ea41db12ab5d0228e 43658 x11 optional mpeg2dec_0.5.1-4_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk/wbVgACgkQ4VUX8isJIMBungCeLNKARtD+eiKkxGGc9DWSuNWm 7wsAoKU7hfeDiSACDomIJRH26v2NwzhM =4V4s -END PGP SIGNATURE- Accepted: libmpeg2-4-dev_0.5.1-4_amd64.deb to main/m/mpeg2dec/libmpeg2-4-dev_0.5.1-4_amd64.deb libmpeg2-4_0.5.1-4_amd64.deb to main/m/mpeg2dec/libmpeg2-4_0.5.1-4_amd64.deb mpeg2dec_0.5.1-4.debian.tar.gz to main/m/mpeg2dec/mpeg2dec_0.5.1-4.debian.tar.gz mpeg2dec_0.5.1-4.dsc to main/m/mpeg2dec/mpeg2dec_0.5.1-4.dsc mpeg2dec_0.5.1-4_amd64.deb to main/m/mpeg2dec/mpeg2dec_0.5.1-4_amd64.deb ___ 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#657885: ffmpeg: Illegal instruction on dreamplug (arm cpu)
Te wrote: > > > Package: ffmpeg > > > Version: 4:0.8-1 > > > Severity: normal > > > > > > > > > Dear Maintainer, > > > > > > > > > [16:16 - 1.25] > > > [user@debian 1] ~ > ffmpeg > > > Illegal instruction > > > [16:16 - 1.25] > > > [user@debian 2] ~ > gdb ffmpeg > > > GNU gdb (GDB) 7.3-debian > > > Copyright (C) 2011 Free Software Foundation, Inc. > > > License GPLv3+: GNU GPL version 3 or later > > > <http://gnu.org/licenses/gpl.html> > > > This is free software: you are free to change and redistribute it. > > > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > > > and "show warranty" for details. > > > This GDB was configured as "arm-linux-gnueabi". > > > For bug reporting instructions, please see: > > > <http://www.gnu.org/software/gdb/bugs/>... > > > Reading symbols from /usr/bin/ffmpeg...(no debugging symbols > > > found)...done. > > > (gdb) run > > > Starting program: /usr/bin/ffmpeg > > > [Thread debugging using libthread_db enabled] > > > > > > Program received signal SIGILL, Illegal instruction. > > > 0x00018cf8 in ?? () > > > (gdb) disassemble $pc, $pc+0x20 > > > Cannot access memory at address 0x0 > > > Dump of assembler code from 0x18cf8 to 0x18d18: > > > => 0x00018cf8: movwlr, #2011 ; 0x7db > > > 0x00018cfc: ldr r2, [pc, #148] ; 0x18d98 > > > 0x00018d00: ldr r4, [pc, #148] ; 0x18d9c > > > 0x00018d04: ldr r12, [r12] > > > 0x00018d08: ldr r3, [r3, r2] > > > 0x00018d0c: add r4, pc, r4 > > > 0x00018d10: ldr r2, [pc, #136] ; 0x18da0 > > > 0x00018d14: str lr, [sp, #4] > > > End of assembler dump. > > > > > > > > > More system information: > > > > > > Initializing cgroup subsys cpu > > > Linux version 3.1.10 (kelly@bbb.internal) (gcc version 4.4.1 (Sourcery > > > G++ Lite 2010q1-202) ) #1 PREEMPT Fri Jan 20 10:47:05 MST 2012 > > > CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977 > > > CPU: VIVT data cache, VIVT instruction cache > > > Machine: Marvell GuruPlug Reference Board > > > > I see. Your machine is not ARMv7 capable, yet, the baseline flavor of > > libavcodec does seem to use ARMv7 instructions. cf. > > http://blogs.arm.com/software-enablement/251-how-to-load-constants-in-assembly-for-arm-architecture/ > > > > Can you please retrieve a backtrace with libav-dbg installed? I need > > to know where exactly in the code the offending instruction occurs in > > order to determine if it's an upstream bug or a configuration issue. > > > > Thanks > > Reinhard > > > > -- > > regards, > > Reinhard > -- Loïc Minier ___ 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: Fwd: Bug#657885: ffmpeg: Illegal instruction on dreamplug (arm cpu)
Sure
On Mon, Jun 25, 2012, Reinhard Tartler wrote:
> Hi Loïc,
>
> Can you perhaps have a look at this bugreport? Either the dynamic
> loader is doing something wrong here on armel, or the libavcodec
> baseline shared library builds do enable armv7 instructions after all.
>
> AFAIUI, this does not only affect the dreamplug but also the (supposly
> popular) raspberry pi. Can/Shall we do something about it before the
> freeze?
>
> Cheers,
> Reinhard
>
>
> -- Forwarded message --
> From: Darwin Te
> Date: Sun, Jan 29, 2012 at 5:27 PM
> Subject: Bug#657885: ffmpeg: Illegal instruction on dreamplug (arm cpu)
> To: Debian Bug Tracking System
>
>
> Package: ffmpeg
> Version: 4:0.8-1
> Severity: normal
>
>
> Dear Maintainer,
>
>
> [16:16 - 1.25]
> [user@debian 1] ~ > ffmpeg
> Illegal instruction
> [16:16 - 1.25]
> [user@debian 2] ~ > gdb ffmpeg
> GNU gdb (GDB) 7.3-debian
> Copyright (C) 2011 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "arm-linux-gnueabi".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /usr/bin/ffmpeg...(no debugging symbols found)...done.
> (gdb) run
> Starting program: /usr/bin/ffmpeg
> [Thread debugging using libthread_db enabled]
>
> Program received signal SIGILL, Illegal instruction.
> 0x00018cf8 in ?? ()
> (gdb) disassemble $pc, $pc+0x20
> Cannot access memory at address 0x0
> Dump of assembler code from 0x18cf8 to 0x18d18:
> => 0x00018cf8: movw lr, #2011 ; 0x7db
> 0x00018cfc: ldr r2, [pc, #148] ; 0x18d98
> 0x00018d00: ldr r4, [pc, #148] ; 0x18d9c
> 0x00018d04: ldr r12, [r12]
> 0x00018d08: ldr r3, [r3, r2]
> 0x00018d0c: add r4, pc, r4
> 0x00018d10: ldr r2, [pc, #136] ; 0x18da0
> 0x00018d14: str lr, [sp, #4]
> End of assembler dump.
>
>
> More system information:
>
> Initializing cgroup subsys cpu
> Linux version 3.1.10 (kelly@bbb.internal) (gcc version 4.4.1 (Sourcery
> G++ Lite 2010q1-202) ) #1 PREEMPT Fri Jan 20 10:47:05 MST 2012
> CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977
> CPU: VIVT data cache, VIVT instruction cache
> Machine: Marvell GuruPlug Reference Board
>
>
> -- System Information:
> Debian Release: wheezy/sid
> APT prefers testing
> APT policy: (500, 'testing')
> Architecture: armel (armv5tel)
>
> Kernel: Linux 3.1.10 (PREEMPT)
> Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=locale: Cannot
> set LC_CTYPE to default locale: No such file or directory
> locale: Cannot set LC_MESSAGES to default locale: No such file or directory
> locale: Cannot set LC_ALL to default locale: No such file or directory
> ANSI_X3.4-1968)
> Shell: /bin/sh linked to /bin/dash
>
> Versions of packages ffmpeg depends on:
> ii libav-tools 4:0.8-1
>
> ffmpeg recommends no packages.
>
> ffmpeg suggests no packages.
>
> -- debconf information:
> perl: warning: Setting locale failed.
> perl: warning: Please check that your locale settings:
> LANGUAGE = (unset),
> LC_ALL = (unset),
> LANG = "en_CA.UTF-8"
> are supported and installed on your system.
> perl: warning: Falling back to the standard locale ("C").
> locale: Cannot set LC_CTYPE to default locale: No such file or directory
> locale: Cannot set LC_MESSAGES to default locale: No such file or directory
> locale: Cannot set LC_ALL to default locale: No such file or directory
>
>
>
> ___
> pkg-multimedia-maintainers mailing list
> pkg-multimedia-maintainers@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
>
>
> --
> regards,
> Reinhard
>
--
Loïc Minier
___
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: flumotion (ITA)
On Wed, Mar 07, 2012, IOhannes m zmoelnig wrote: > now update-rc.d doesn't restart anything. Oh right, it's just update-rc.d that you changed; nevermind > if you find the CDBS documentation, please tell me so i can check > myself... the only documentation i know of lives in denmark and > expressed willingness to "have a look" :-) haha -- yeah, CDBS doc is best accessed with `rgrep /usr/share/cdbs` :-) -- Loïc Minier ___ 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: flumotion (ITA)
Hey, On Tue, Mar 06, 2012, forum::für::umläute wrote: > the "flumotion" package has been in a bad state for some years now. > i talked with it's current maintainer (CC: Loïc Minier) at IRC and he > said he would not spend much more time on this package, and would be ok, > if i adapted the package. yeah; thanks a lot for stepping up to take it! > git+ssh://git.debian.org/git/pkg-multimedia/flumotion I've had a look at the changes; thanks for moving to latest packaging standards (3.0 (quilt), git-bp, pycompat and such) and thanks for adding the history of uploads by importing the .dsc files. I checked your new changes, and most seem good, concerning: 4fe1e976fd8b49ff2511f7170a13d5ff6de6d2ac update-rc.d is automagically called by dh_installinit IIRC, the byte-compilation was happening by some stanza inserted in #DEBHELPER# back then, and it was good to restart flumotion after the byte-compilation had taken place. Otherwise, dh_installinit might insert the restart snippet before or after byte-compilation, but not consistenly restart flumotion after byte-compilation. Nowadays, I'm not sure how to ensure that the daemon is started with the .py files already byte-compiled. The other packaging changes also relate to packaging style, and made sense in my reading, but I didn't check every single change against the CDBS documentation or such. > PS: the package has not gone through a regular orphanage/ITA cycle. is > this necessary? Nope; I wont complain :-) Thanks! -- Loïc Minier ___ 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#659705: libmpeg2-4: Upload 0.5.x to unstable?
On Tue, Feb 14, 2012, Alessio Treglia wrote: > I think you are right so I've created two repositories, one for libdvb > and another for mpeg2dec, right by git-import-dscs'ing on the packages > from the archive. > Please have a look, we'll never wipe their old corrispective SVN > repos, so fine grained history is preserved. I had a look at the new mpeg2dec one; it seemed fine; I had one weirdness that I don't understand: "git show dc81e27ddf6c6058cfd66ca4c2675f456e9728ea" and "git diff dc81e27ddf6c6058cfd66ca4c2675f456e9728ea^..dc81e27ddf6c6058cfd66ca4c2675f456e9728ea" give different results for debian/changelog, I don't really get why. Anyway, looks good! (Obviously Vcs-Svn will need to be updated before upload) -- Loïc Minier ___ 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#659705: libmpeg2-4: Upload 0.5.x to unstable?
On Mon, Feb 13, 2012, Alessio Treglia wrote: > I've converted the SVN repo into a new git one, here is the result: > http://anonscm.debian.org/gitweb/?p=pkg-multimedia/mpeg2dec.git There are in my eyes two ways to deal with importing the history of this package: a) start from the history in the packaging SVN repo pros: - fine grained history cons: - doesn't intermix with upstream history very well - mixes "upstream files in working tree" with "just debian/ in working tree" - no strict relationship to archive contents b) start from the Debian upload history (.dsc files as downloaded from snapshot.debian.org or from Launchpad, or convert bzr history from lp:debian/mpeg2dec) pros: - matches archive contents - consistenly "upstream files in working tree" - easy to mix with upstream tarball history cons: - doesn't mix with upstream git history if any Your git repo has partial SVN history, I don't know why; if I svn log the unstable mpeg2dec branch in pkg-multimedia it goes down to commits of David Lehn in October 2000 and has imports of the CVS history; these I don't see in your git repo. I would personally think this kind of deep history isn't terribly useful because its form is inconsistent (e.g. debian/ alone or not) so that you would only be able to git blame certain debian/* files. That's why I would personally recommend b), even if that means not seeing some of the finer grained history (my commits for instance). In any case, we must keep the SVN history somewhere; never wipe the SVN repo (you can commit an empty the tree though). To create b), I think I would either download the .dscs from Launchpad using a script or from snapshot.d.o, and then run git-import-dsc on them. Another separate question is how to integrate with upstream history; you could try mixing it with the Debian history, but you need to ensure that the Debian upload tags in the git repo correspond to uploaded .dscs. It's usually trickier to get this right, and it's really useful when dealing with a large set of cherry-picked upstream patches directly committed in your git repo, not useful when using a patch system though. I would recommend sticking to the branch of imported tarballs as the branch mixing history with the Debian one. You can always push some upstream git-ified history to the repo if you like and cherry-pick from it or export patches to debian/patches from it. Cheers, -- Loïc Minier ___ 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#659705: libmpeg2-4: Upload 0.5.x to unstable?
On Mon, Feb 13, 2012, Alessio Treglia wrote: > Loïc, you are listed as the real maintainer of the package and I've > seen you used to keep the VCS of mpeg2dec into the pkg-multimedia's > ancient SVN repository. > Do you agree to move the package under the new Debian Multimedia > Maintainers' git area and let us work on it [1]? Yup; that sounds good! Did you get the history from the SVN or from importing the .dscs from e.g. snapshot or launchpad? I also have a strong preference for full source tree in the git repo rather than just debian/ -- Loïc Minier ___ 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: spam on pkg-multimedia-maintainers
On Fri, Feb 11, 2011, Fabian Greffrath wrote: > Sam Hocevar, maybe? He founded this team and set up the whole > infrastructure IIRC. Reinhard and myself are admins as well I looked at the rules, there are a bunch of whitelisting rules for mails comig from debbugs, dak etc. I've just added a new rule that messages with spam-level 3 or above will be put on hold. This should catch about half the spam coming to this list (25 messages out of 48 in my mailbox). What I personally do in general is hide spam-level: *** messages from my mailboxes, and auto-expire all messages which I didn't open but I've at least seen in the inbox. I might change the settings to something like Discard if I only ever catch spam with ***. -- Loïc Minier ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Generous offer for debimedia / Help Wanted!
On Tue, Dec 07, 2010, Reinhard Tartler wrote: > In Message-ID: <4cfd7048.6050...@debian.org>, Thomas Goirand made the > very generous offer for DDs to Host a machine for any debian > purpose. I've accepted the offer to host drive the debimedia archive This is awesome! I understand the server you're running on could be borrowed to serve as spare parts for other servers if needed; I'm not sure the contents of your vm are backed up, is this something you know about? Recently, Emdebian lost their full single server which wasn't backed up at all, and it set them back to the dark ages -- Loïc Minier ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: xbmc-bin armel
On Thu, Nov 25, 2010, Gábor Majoros wrote: > Please check > http://ppa.launchpad.net/team-xbmc/ppa/ubuntu/dists/lucid/main/binary-armel/Packages > Just installed Ubuntu to my Beagleboard, and wanted to put xbmc on it, > but it stopped due to xbmc-bin package. Package: xbmc-data depends on > it, but the repo does not contain it. Could you please fix it? PPAs don't support armel at the moment Either this software would get included into Ubuntu, or PPAs need to grow armel support -- Loïc Minier ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Patches in morituri repo
On Wed, Nov 10, 2010, Jonas Smedegaard wrote: > * Inform us via the email address in the maintainer field, rather > than (only) to me. And use the maintainer field in our VCS to > ensure you get the latest one, in case it changed since last > packaging release. Sure, well I guessed you were the only one committing and in the Uploaders field, so pretty much the most caring person for the package; I guessed other people interested in the package would notice the commits on IRC or on the commits list, but I didn't want to disrupt your work since you had unuploaded changes > * Include Bug hint in patch or at least provide a URL, instead of > just tagging Forwarding: yes. Even if others (i.e. me) didn't > do it for other patches. > More info at http://dep.debian.net/deps/dep3/ Yeah, I just opted for the lazy option; also, there's a chicken and egg: I write the patch, include it in the packaging, test it before I have an URL for the upstream bug, then I forward it when I've tested it. I've added URLs now > * Follow patch naming scheme as documented in debian/patches/README. > Specifically - since you did not provide a Bug: hint - I suspect > that the provided patches was cherry-picked from upstream VCS > (rather than _pushed_ upstream) and thus more appropriately should > use a leading 0, not 1. Actually I did read the README and I did write and propose the patches upstream, which is why I named them 1xxx > I dare cc the Multimedia team this email. Hope you are ok with that. Sure thing -- Loïc Minier ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#594093: NEON pass failure on ffmpeg
On Fri, Aug 27, 2010, Reinhard Tartler wrote: > the general idea is to start an upload with an 'dummy' debian/changelog > entry indicating the next version, and finalize it using git-dch(1) just > before the upload. Would you mind creating it with "UNRELEASED" as the target dist? This helps dch figure out that it should add to the current changelog rather than increment the version in the changelog. Thanks! -- Loïc Minier ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#594093: NEON pass failure on ffmpeg
On Thu, Aug 26, 2010, Reinhard Tartler wrote: > For the base flavor, I totally agree. For the specialized neon flavor, > I'm not sure if that's so important. But I have to admit that I'm really > not an expert for armel, so I fully trust your judgement here. Actually my test logic was wrong; I realized when implementing the v7 part I mentioned: if v7 isn't enabled by default, then the NEON pass should enable it since NEON implies v7. v6t2 was a distraction, I removed it. I committed this to ffmpeg git, but I didn't understand the way the changelog was maintained (apparently you create an entry after the last upload?). Mind fixing it up? Thanks! -- Loïc Minier ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#594093: NEON pass failure on ffmpeg
On Thu, Aug 26, 2010, Reinhard Tartler wrote: > For the base flavor, I totally agree. For the specialized neon flavor, > I'm not sure if that's so important. But I have to admit that I'm really > not an expert for armel, so I fully trust your judgement here. It's a fair point; I don't think it's too big a deal either way, it's just that I don't feel comfortable overriding more than I strictly need. -- Loïc Minier ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#594093: NEON pass failure on ffmpeg
On Wed, Aug 25, 2010, Reinhard Tartler wrote: > Hm, why can't we unconditionally turn on armv7-a for the neon flavor? I'd prefer not overriding the toolchain defaults, only overriding the minimum set of things. For instance, it could be selecting a special core. -- Loïc Minier ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#594093: NEON pass failure on ffmpeg
tags 594093 + patch confirmed
stop
On Wed, Aug 25, 2010, Riku Voipio wrote:
> Neither is it a toolchain bug nor do we have any NEON capable buildds.
It's ok, we don't need NEON capable buildds; this builds an alternate
set of ffmpeg libs for NEON (available via hwcaps).
> And, btw ubfx is not even a NEON instruction. It is a ARMv7 instruction.
It actually seems to have been added in armv6t2+ (even in ARM mode).
> The error is caused by debians toolchain default flags. you need to pass
> -march=armv7-a for the debian-neon pass to get armv7 instructions accepted.
Now the NEON flavor implies armv7-a, so that's what we should turn on.
Riku, Reinhard, I only checked the gcc tests in the attached debdiff,
but didn't do a full build under Debian; would you mind trying it out?
Now one thing which this patch does NOT do is turn on armv7-a for the
NEON flavour if the toolchain defaults to armv6t2, so we might be
missing some small optimizations, but I didn't check how to test for
armv7-a versus armv6t2. If ffmpeg relies on the some armv7-a-only
assembly, then we will quickly find out :-)
Thanks,
--
Loïc Minier
diff -u ffmpeg-0.6~svn20100505/debian/confflags
ffmpeg-0.6~svn20100505/debian/confflags
--- ffmpeg-0.6~svn20100505/debian/confflags
+++ ffmpeg-0.6~svn20100505/debian/confflags
@@ -33,11 +33,14 @@
has_vfp := $(call check_asm, $(vfp_asm))
neon_asm := vadd.i16 q0, q0, q0
has_neon := $(call check_asm, $(neon_asm))
+v6t2_asm := ubfx r0, r0, 0, 1
+has_v6t2 := $(call check_asm, $(v6t2_asm))
-# only build
+# only build a VFP flavour if the toolchain doesn't enable VFP by default
ifneq ($(has_vfp),1)
FLAVORS += vfp
endif
+# only build a NEON flavour if the toolchain doesn't enable NEON by default
ifneq ($(has_neon),1)
FLAVORS += neon
endif
@@ -161,6 +164,12 @@
# NB: NEON always implies v7+ and ffmpeg's NEON implementation requires VFP
neon_build_confflags += $(confflags)
neon_build_confflags += --shlibdir=/usr/lib/neon/vfp
+# the NEON pass now requires ubfx which was introduced in armv6t2; we need to
+# enable at least armv6t2 for the NEON pass to build, but NEON implies armv7-a
+# so pass armv7-a
+ifneq ($(has_v6t2),1)
+neon_build_confflags += --extra-cflags="-marmv7-a"
+endif
neon_build_confflags += --extra-cflags="-mfpu=neon -mfloat-abi=softfp -fPIC
-DPIC"
neon_build_confflags += --enable-shared
neon_build_confflags += --disable-static
diff -u ffmpeg-0.6~svn20100505/debian/changelog
ffmpeg-0.6~svn20100505/debian/changelog
--- ffmpeg-0.6~svn20100505/debian/changelog
+++ ffmpeg-0.6~svn20100505/debian/changelog
@@ -1,3 +1,12 @@
+ffmpeg (4:0.6~svn20100505-2) UNRELEASED; urgency=low
+
+ * debian/confflags: detect whether the toolchain supports armv6t2 ("ubfx")
+by default as that's now needed for the NEON pass; if it's not enabled by
+default, pass -marmv7-a in extra-cflags for the NEON pass since NEON
+implies ARMv7; closes: #594093.
+
+ -- Loïc Minier Wed, 25 Aug 2010 21:42:57 +0200
+
ffmpeg (4:0.6~svn20100505-1) experimental; urgency=low
* update to new upstream. Closes: #569727
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Verbose build log
On Thu, Jun 10, 2010, Christophe Mutricy wrote: > We can revert to the old fully verbose behaviour if we like. > > Do you know if there is a Debian or pkg-multimedia policy/best-practice on > this matter. > > Verbose log can help debug FTBFS but increase the size of the log by 2 or 3 > order of magnitude I understand the best practice is to use verbose build logs for package builds so that we can still grep them for flags and the like. -- Loïc Minier ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#560644: clxclient: FTBFS: dpkg-gensymbols fails
On Sun, Dec 13, 2009, Jaromír Mikeš wrote:
> $ find /home/mira/zita-convolver -exec grep -i "X_window::x_map()" /dev/null
> {} \;
> and
> $ find /home/mira/zita-convolver -exec grep -i "X_window" /dev/null {} \;
> giving nothing
You might want "grep -r" instead of find ... -exec grep which will exec
grep for each file and is very inefficient. i.e.:
grep -ir X_window::x_map /home/mira/zita-convolver
> I checked also manually ... no definition of 'X_window::x_map() const'
Well *that* is the actual problem: the symbol is listed in
debian/libclxclient3.symbols.*, but is not exported.
It's not good enough to grep for X_window::x_map, this function is
actually defined in the X_window class directly, see clxclient.h:
class X_window
{
public:
[...]
int x_map (void) const { return XMapWindow (_disp->_dpy, _wind); }
While we're at it, why does this package build-depend on
libasound2-dev and declares itself in section "sound"?? Seems
completely wrong to me.
--
Loïc Minier
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#560543: vls: FTBFS: parsers.cpp:125: undefined reference to `C_Vector::C_Vector(unsigned int, unsigned char)'
On Fri, Dec 11, 2009, Loïc Minier wrote: > Yes, removal definitely makes sense; this is a dead project upstream. > I think a company might be maintaining a fork, but I doubt anybody > still uses vls nor anybody could support it at this point. Surprisingly, there was a release in 2008 after 4 years of inactivity: http://download.videolan.org/pub/videolan/vls/ I still doubt it's of any use, and upstream recommends using vlc instead now: http://www.videolan.org/vlc/streaming.html -- Loïc Minier ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#560543: vls: FTBFS: parsers.cpp:125: undefined reference to `C_Vector::C_Vector(unsigned int, unsigned char)'
On Fri, Dec 11, 2009, Reinhard Tartler wrote: > popcon doesn't look too bright either: > http://qa.debian.org/popcon.php?package=vls > Sounds like a good removal candidate to me. > Loic, you seem to be the last uploader of the package. What do you > think, shall we ask for vls to be removed? Yes, removal definitely makes sense; this is a dead project upstream. I think a company might be maintaining a fork, but I doubt anybody still uses vls nor anybody could support it at this point. -- Loïc Minier ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
