Bug#690152: bsaf: FTBFS: Test org.jdesktop.application.TaskMonitorTest failed
On Sun, Mar 3, 2013 at 8:42 AM, gregor herrmann gre...@debian.org wrote: On Sat, 02 Mar 2013 19:12:32 -0500, Andres Mejia wrote: I just rebuilt bsaf on my machine that has the DISPLAY environment variable set and In a chroot or in the normal environment? The normal environment. on a sid and wheezy chroot via sbuild-shell (which in turn uses schroot) that does not have DISPLAY set. All builds succeeded and passed the test suite. That's not surprising, since without DISPLAY the otherwise failing tests are skipped :) FWIW: The tests still fail for me in wheezy and sid cowbuilder amd64 chroots, with DISPLAY set, with or without my earlier patch (to use xvfb). As mentioned earlier in this bug log by Matteo, building with openjdk-7-jdk works in the same setup. Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: David Bowie: Suffragette City At this time, being this late into the release cycle, I would like to support only the default-jdk. I am building with sbuild using a chroot created by sbuild-createchroot as I believe this closely matches what the buildd machines are running. The bsaf package builds and passes the test suite for me fine on my machine running Debian wheezy, inside a wheezy chroot using sbuild, and inside a sid chroot using sbuild. My machine has a display, the chroot environments do not have a display. I will be downgrading this bug to important as I don't believe supporting cowbuilder, xvfb, or openjdk-7-jdk to be release critical. If someone else can reproduce the test case failure with the version of bsaf in the archives as is, then feel free to raise it back, otherwise fixing these other issues of supporting cowbuilder, xvfb, and openjdk-7-jdk can wait. -- ~ Andres -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658335: [firmware-crystalhd] Firmware image signature failure
tags 658335 moreinfo stop Tim, Are you still having an issue with the firmware for crystalhd? If so, are you using the crystalhd-dkms package? Note that the crystalhd-dkms package is being dropped at this time. It is recommended you use the crystalhd driver found in the mainline Linux kernel. On Sun, Mar 4, 2012 at 2:43 PM, Andres Mejia amejia...@gmail.com wrote: Hi, I'm the maintainer of the crystalhd packages in Debian. There's a user that reported the below issue. Do you have any suggestions on what he may try? I'm not sure about any mismatch. The crystalhd library and firmware packages were built from the same git snapshot (repo: http://git.linuxtv.org/jarod/crystalhd.git, commit: fdd2f19ac739a3db1fd7469ea19ceaefe0822e5a). When you reply, please preserve the CC field. -- Forwarded message -- From: Tim Sattarov ti...@sattaroff.name Date: Wed, Feb 1, 2012 at 10:22 PM Subject: Bug#658335: [firmware-crystalhd] Firmware image signature failure To: sub...@bugs.debian.org Package: firmware-crystalhd Version: 0.0~git20120110.fdd2f19-1 Severity: grave --- Please enter the report below this line. --- Hello, I'm trying to use my Broadcom HW decoder bcm70015 here is lspci output 04:00.0 Multimedia controller: Broadcom Corporation BCM70015 Video Decoder [Crystal HD] driver compiles but every time I start video application (xbmc or totem) I'm getting these messages in dmesg [ 5503.584187] Loading crystalhd v3.10.0 [ 5503.584345] crystalhd :04:00.0: Starting Device:0x1615 [ 5503.584430] crystalhd :04:00.0: PCI INT A - GSI 19 (level, low) - IRQ 19 [ 5503.595602] crystalhd :04:00.0: irq 47 for MSI/MSI-X [ 5503.668241] crystalhd :04:00.0: setting latency timer to 64 [ 5527.782089] crystalhd :04:00.0: Opening new user[0] handle [ 5527.852226] crystalhd :04:00.0: Closing user[0] handle with mode [ 5734.101508] crystalhd :04:00.0: Opening new user[0] handle [ 5734.172146] crystalhd :04:00.0: Closing user[0] handle with mode [ 5734.210614] crystalhd :04:00.0: Opening new user[0] handle [ 5734.280237] crystalhd :04:00.0: Closing user[0] handle with mode [ 5734.317633] crystalhd :04:00.0: Opening new user[0] handle [ 5734.668199] crystalhd :04:00.0: [crystalhd_flea_download_fw]: step 7. Error bit occured. RetVal:c00018 [ 5734.668226] crystalhd :04:00.0: [crystalhd_flea_download_fw]: step 7. Firmware image signature failure. [ 5734.668242] crystalhd :04:00.0: Firmware Download Failure!! - -1 [ 5734.784736] crystalhd :04:00.0: Closing user[0] handle via ioctl with mode 1c200 and crystalhd is not used at all. Google says - firmware version does not match driver version. Any ideas how to make it work ? Thanks Tim --- System information. --- Architecture: i386 Kernel: Linux 3.2.0-1-686-pae Debian Release: wheezy/sid 500 unstable www.debian-multimedia.org 500 unstable http.us.debian.org 1 experimental http.us.debian.org --- Package information. --- Package's Depends field is empty. Package's Recommends field is empty. Suggests (Version) | Installed ==-+-=== initramfs-tools | 0.99 linux-image | -- ~ Andres -- ~ Andres -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690152: bsaf: FTBFS: Test org.jdesktop.application.TaskMonitorTest failed
On Monday, January 7, 2013, Joost Yervante Damad wrote: On 01/07/2013 07:48 PM, gregor herrmann wrote: On Sat, 15 Dec 2012 16:13:35 +0100, Joost Yervante Damad wrote: I tried rebuilding the bsaf software in wheezy with default-jdk, which uses the openjdk from openjdk-6-jre-headless_6b24. It builds just fine. Is this really still an issue? It still fails to build for me in wheezy and sid chroots - without my earlier patch because of Can't connect to X11 window server using ':0' as the value of the DISPLAY variable. - with the patch with the long java.beans stack trace I guess you had DISPLAY unset during the build and the problematic tests were skipped? Indeed, I did not have DISPLAY set. Unfortunately I forgot to keep a log of the build around. Joost __ This is the maintainer address of Debian's Java team http://lists.alioth.debian.**org/cgi-bin/mailman/listinfo/** pkg-java-maintainershttp://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. Please use debian-j...@lists.debian.org for discussions and questions. I just rebuilt bsaf on my machine that has the DISPLAY environment variable set and on a sid and wheezy chroot via sbuild-shell (which in turn uses schroot) that does not have DISPLAY set. All builds succeeded and passed the test suite. The chroot environment will not have DISPLAY set of course. In fact, there should be a small number of environment variables set in an chroot environment using schroot. My chroot environment has the following variables set. USER HOME XDG_SESSION_COOKIE SCHROOT_CHROOT_NAME SCHROOT_UID LOGNAME TERM USERNAME PATH SCHROOT_COMMAND SCHROOT_SESSION_ID SCHROOT_ALIAS_NAME SCHROOT_GROUP SCHROOT_USER SHELL PWD SCHROOT_GID -- Andres -- ~ Andres
Bug#699470: crystalhd-dkms: Kernel null pointer BUG in crystalhd_dioq_fetch_wait()
It looks like the crystalhd drivers are buggy with newer kernel releases. I opt for removing the dkms package. I will do this over the weekend. On Thu, Feb 28, 2013 at 4:52 PM, thomas schorpp thomas.scho...@gmail.com wrote: On 28.02.2013 20:41, Julien Cristau wrote: On Thu, Jan 31, 2013 at 19:25:50 +0100, tom schorpp wrote: Package: crystalhd-dkms Version: 1:0.0~git20110715.fdd2f19-7 Severity: critical Tags: patch Justification: breaks the whole system Reproducible NULL pointer BUG at crystalhd-0.0~git20110715.fdd2f19/driver/linux/crystalhd_misc.c:515, triggered by adobe flash plugin from dmo repo, ffmpeg, mplayer, bino or other, mostly on heavy ioq usage or after FETCH_TIMEOUT and/or unclosed driver HANDLEs. Does the maintainer or somebody on pkg-multimedia plan on fixing this RC bug? If not I'll consider a NMU removing the dkms package from crystalhd source. Cheers, Julien Known linux-media Maintainers STAGING - CRYSTAL HD VIDEO DECODER M:Naren Sankar nsan...@broadcom.com M:Jarod Wilson ja...@wilsonet.com M:Scott Davilla davi...@4pi.com M:Manu Abraham abraham.m...@gmail.com seem to have left the Broadcom's legacy driver code, focusing on the new linux-media staging driver, but limited time, one stated lately on the linux-media/LKML, nothing read from the others. I could adapt it to new kernel releases the next 2-3 years, but nothing more, not a experienced kernel driver coder, no debian package/policy maintaining motivation because I do not use dkms or debian kernels packages. If my last patch applies to Your codebase in the debian git repository (mine is from git.linuxtv.org, according to the git changelog more advanced in the gstreamer plugin, merge?) You may consider it hotfixed and release with known multithreading (gstreamer based transcoders/matroska demuxers) and PM ACPI S3 issues? Has not crashed here any more, nor notable side effects with usual playback use cases, including Totem (gstreamer). y tom ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintain...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers -- ~ Andres -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699470: crystalhd-dkms: Kernel null pointer BUG in crystalhd_dioq_fetch_wait()
On Fri, Mar 1, 2013 at 3:55 PM, Julien Cristau jcris...@debian.org wrote: On Fri, Mar 1, 2013 at 21:38:54 +0100, thomas schorpp wrote: So no technical reasons to drop the package? Until and unless the driver is in mainline, there's every reason to drop it. Cheers, Julien I just checked the crystalhd driver in the mainline kernel. The driver seems to be much better maintained over there than at linuxtv.org. See [1]. I'm going to drop the driver from linuxtv.org. If after I drop the package someone has some compelling reason to use the driver from linuxtv.org, they can submit another bug to the crystalhd package and explain why the linuxtv.org driver should be used. 1. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/drivers/staging/crystalhd -- ~ Andres -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671302: Circular Build Dependencies (was Bug#671302: libav: circular dependency between libav and opencv)
On May 4, 2012 4:43 PM, Fabian Greffrath fab...@greffrath.com wrote: libav - x264 - libav AFAICT the x264 frontend uses libav whereas libav uses the libx264 shared library. So theortically (!) this issue could be solved by two separate source packages for the x264 frontend and the library. - Fabian This doesn't resolve the issue with opencv though. ~ Andres
Bug#671302: Circular Build Dependencies (was Bug#671302: libav: circular dependency between libav and opencv)
On May 3, 2012 10:20 AM, Andres Mejia amejia...@gmail.com wrote: On May 3, 2012 9:30 AM, Pino Toscano p...@debian.org wrote: Alle giovedì 3 maggio 2012, Andres Mejia ha scritto: On Thu, May 3, 2012 at 3:44 AM, Pino Toscano p...@debian.org wrote: Package: libav Version: 6:0.8.1-7 Severity: important Hi, libav 6:0.8.1-7 reenables the use of opencv... which itself uses libav libraries. This currently makes libav unbuildable on mipsel and hurd-i386, and generically makes libav no more bootstrap'able without having itself compiled already. Could you please drop the opencv usage again, please? What could be done instead is a binary only upload with opencv support disabled (i.e. use dpkg-buildpackage -B). Doing it on our end will not require changing the version. Once this package is uploaded, the release team can then be asked to do a binNMU for these archs, which will bring back opencv support since the archive will contain the regular *.debian.tar.gz changes that included opencv. I believe this is better than doing a full build on all archs without opencv, then doing another build with opencv. This mess (which is only a mess, not a clean solution) does not solve at all the fact that you cannot do a clean build of libav without having libav compiled already (for opencv). I don't see this as a viable solution, especially if in the future the epoch is raised bringing again conflicts between the old libav libraries and the new one. -- Pino Toscano I'm not entirely certain how build circular dependency issues like this are resolved. Perhaps we should ask for help from the toolchain package maintainers or debian-devel. ~ Andres Hello all, I would like to know if there is a good (perhaps best) approach in resolving issues with packages with circular build dependencies. Libav has various circular build dependencies including. libav - opencv - libav libav - x264 - libav libav - x264 - gpac - libav I found some mention of this issue at [1]. This however doesn't offer any clear solution. 1. http://wiki.debian.org/DebianBootstrap ~ Andres
Bug#671302: libav: circular dependency between libav and opencv
On May 3, 2012 5:36 PM, Julien Cristau jcris...@debian.org wrote: On Thu, May 3, 2012 at 10:20:57 -0400, Andres Mejia wrote: I'm not entirely certain how build circular dependency issues like this are resolved. Perhaps we should ask for help from the toolchain package maintainers or debian-devel. What's wrong with just disabling opencv? Cheers, Julien There's a circular build dependency with x264 and gpac. I rather find anothet way to resolve this issue now then resorting to doing a full rebuild of libav on the buildd network twice. It may just be faster to do what I suggested earlier. ~ Andres
Bug#668404: xbmc-live: dependency on upstart prevents using xbmc with sysvinit
severity 668404 important stop Thanks for your report. xbmc-live requires upstart to be installed. Note that xbmc-live is not necessary to install and use the xbmc package. I did not find anything in policy that says packages cannot require the use of another init system. The only language I found pertaining to this is Debian policy 9.3, which pertains to how maintainer scripts should be provided for the init system, and has language like should or may and not must or require. I'm downgrading this bug to important. -- ~ Andres -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666963: openal-soft: Build failure on many architectures
Package: openal-soft Version: 1:1.14-1 Severity: serious The new upload of openal-soft currently fails to build. Reporting this issue now to remind myself to look into this issue. Any help is welcome however. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658335: Fwd: Bug#658335: [firmware-crystalhd] Firmware image signature failure
Hi, I'm the maintainer of the crystalhd packages in Debian. There's a user that reported the below issue. Do you have any suggestions on what he may try? I'm not sure about any mismatch. The crystalhd library and firmware packages were built from the same git snapshot (repo: http://git.linuxtv.org/jarod/crystalhd.git, commit: fdd2f19ac739a3db1fd7469ea19ceaefe0822e5a). When you reply, please preserve the CC field. -- Forwarded message -- From: Tim Sattarov ti...@sattaroff.name Date: Wed, Feb 1, 2012 at 10:22 PM Subject: Bug#658335: [firmware-crystalhd] Firmware image signature failure To: sub...@bugs.debian.org Package: firmware-crystalhd Version: 0.0~git20120110.fdd2f19-1 Severity: grave --- Please enter the report below this line. --- Hello, I'm trying to use my Broadcom HW decoder bcm70015 here is lspci output 04:00.0 Multimedia controller: Broadcom Corporation BCM70015 Video Decoder [Crystal HD] driver compiles but every time I start video application (xbmc or totem) I'm getting these messages in dmesg [ 5503.584187] Loading crystalhd v3.10.0 [ 5503.584345] crystalhd :04:00.0: Starting Device:0x1615 [ 5503.584430] crystalhd :04:00.0: PCI INT A - GSI 19 (level, low) - IRQ 19 [ 5503.595602] crystalhd :04:00.0: irq 47 for MSI/MSI-X [ 5503.668241] crystalhd :04:00.0: setting latency timer to 64 [ 5527.782089] crystalhd :04:00.0: Opening new user[0] handle [ 5527.852226] crystalhd :04:00.0: Closing user[0] handle with mode [ 5734.101508] crystalhd :04:00.0: Opening new user[0] handle [ 5734.172146] crystalhd :04:00.0: Closing user[0] handle with mode [ 5734.210614] crystalhd :04:00.0: Opening new user[0] handle [ 5734.280237] crystalhd :04:00.0: Closing user[0] handle with mode [ 5734.317633] crystalhd :04:00.0: Opening new user[0] handle [ 5734.668199] crystalhd :04:00.0: [crystalhd_flea_download_fw]: step 7. Error bit occured. RetVal:c00018 [ 5734.668226] crystalhd :04:00.0: [crystalhd_flea_download_fw]: step 7. Firmware image signature failure. [ 5734.668242] crystalhd :04:00.0: Firmware Download Failure!! - -1 [ 5734.784736] crystalhd :04:00.0: Closing user[0] handle via ioctl with mode 1c200 and crystalhd is not used at all. Google says - firmware version does not match driver version. Any ideas how to make it work ? Thanks Tim --- System information. --- Architecture: i386 Kernel: Linux 3.2.0-1-686-pae Debian Release: wheezy/sid 500 unstable www.debian-multimedia.org 500 unstable http.us.debian.org 1 experimental http.us.debian.org --- Package information. --- Package's Depends field is empty. Package's Recommends field is empty. Suggests (Version) | Installed ==-+-=== initramfs-tools | 0.99 linux-image | -- ~ Andres -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659294: [libarchive-discuss] Fwd: Bug#659294: libarchive: FTBFS on various architectures (hurd, mipsel, s390, s390x)
On Feb 22, 2012 12:45 AM, Tim Kientzle t...@kientzle.com wrote: On Feb 21, 2012, at 3:40 AM, Pino Toscano wrote: Hi, (greetings from your favourite Hurd porter) Alle lunedì 13 febbraio 2012, Tim Kientzle ha scritto: So on hurd, I see a couple of interesting failures for bsdtar: [...] Actually, libarchive is pretty fine on Hurd, as it was after I fixed libarchove 3.0.2 (and in 3.0.3 there are no changes leading to issues). The problem is that the test suite run (just like the whole package build) is done within fakeroot (which means fakeroot-tcp), triggering Debian's #534879. Thanks, Pino. Libarchive's test suite does a lot of file operations, including a lot of cross-checks of file modes, ownership, and other properties. The races described in #534789 would likely manifest as essentially random failures in libarchive's test suite. Tim Ok, resolved the issue on hurd. Now that leaves the issues on mipsel and s390x which don't seem random. ~ Andres
Bug#659294: Help resolving libarchive test suite failure for mipsel
Hi. I need a little help in resolving the test suite failure of libarchive for mipsel (see bug #659294). Could someone please install libarchive's build dependencies on one of the mipsel porter boxes so I can attempt to resolve the issue. -- ~ Andres -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659294: Fwd: Bug#659294: [libarchive-discuss] Fwd: Bug#659294: libarchive: FTBFS on various architectures (hurd, mipsel, s390, s390x)
On Sat, Feb 11, 2012 at 6:00 AM, Philipp Kern pk...@debian.org wrote: On Fri, Feb 10, 2012 at 04:34:40PM -0500, Andres Mejia wrote: Hi. The new version of libarchive uploaded to unstable is failing the test suite (and thus failing to build the deb packages). We're going to need copies of the test directories from the test suites, e.g., Details for failing tests: /tmp/libarchive_test.2012-02-06T23.02.12-000 Please provide these test directories to libarchive-disc...@googlegroups.com. For s390(x) you can just use the porter box zelenka. The build-deps are installed. For the other porterboxes you might need to mail the admin list to get them installed. Kind regards, Philipp Kern -- .''`. Philipp Kern Debian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:p...@0x539.de Wanna-Build Admin `- finger pkern/k...@db.debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEAREIAAYFAk82SjsACgkQ7Ro5M7LPzdgQmwCgmaFOa/zkrHa7KEeeG0eLWo7k zKoAn0UzCeZ5fGbfphgtZdHFARD7/aVC =mORi -END PGP SIGNATURE- The issue is resolved for s390 but not for s390x. I see there's no porterbox available for s390x so I won't be able to help out much with the test suite failure in s390x. -- ~ Andres -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659294: Fwd: Bug#659294: [libarchive-discuss] Fwd: Bug#659294: libarchive: FTBFS on various architectures (hurd, mipsel, s390, s390x)
Ok. I see the eder.debian.org porterbox had libarchive's build dependencies installed. I built and ran the test suite several times for mipsel and it passes every time. I even ran the test_read_disk_directory_traversals test about 300 times in a row using a while loop trying to reproduce the build failure. It builds just fine on eder. -- ~ Andres -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659294: libarchive: FTBFS on various architectures (mipsel, s390x)
severity 659294 important stop Downgrading the severity to important since libarchive builds and passes the test suite on the eder porterbox used for mipsel and since there's no porterbox available for s390x. ~ Andres -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659294: Fwd: Bug#659294: [libarchive-discuss] Fwd: Bug#659294: libarchive: FTBFS on various architectures (hurd, mipsel, s390, s390x)
Hi. The new version of libarchive uploaded to unstable is failing the test suite (and thus failing to build the deb packages). We're going to need copies of the test directories from the test suites, e.g., Details for failing tests: /tmp/libarchive_test.2012-02-06T23.02.12-000 Please provide these test directories to libarchive-disc...@googlegroups.com. -- Forwarded message -- From: Tim Kientzle t...@kientzle.com Date: Thu, Feb 9, 2012 at 11:15 PM Subject: Bug#659294: [libarchive-discuss] Fwd: Bug#659294: libarchive: FTBFS on various architectures (hurd, mipsel, s390, s390x) To: libarchive-disc...@googlegroups.com Cc: 659294-forwar...@bugs.debian.org, 659...@bugs.debian.org, Julien Cristau jcris...@debian.org Each of these reports includes the name of the test directory, e.g., Details for failing tests: /tmp/libarchive_test.2012-02-06T23.02.12-000 Can we get the contents of those directories (which include detailed logs for each failure, the files involved, and other details)? Tim On Feb 9, 2012, at 4:20 PM, Andres Mejia wrote: There are some build failures on various architectures in Debian. Note that they're failures in the test suite. -- Forwarded message -- From: Julien Cristau jcris...@debian.org Date: Thu, Feb 9, 2012 at 5:52 PM Subject: Bug#659294: libarchive: FTBFS on various architectures (hurd, mipsel, s390, s390x) To: Debian Bug Tracking System sub...@bugs.debian.org Source: libarchive Version: 3.0.3-3 Severity: serious Justification: fails to build from source (but built successfully in the past) libarchive FTBFS on various buildds, with test failures: https://buildd.debian.org/status/package.php?p=libarchive mipsel: Totals: Tests run: 172 Tests failed: 1 Assertions checked:12407225 Assertions failed: 3 Skips reported: 73 Failing tests: 60: test_read_disk_directory_traversals (3 failures) Details for failing tests: /tmp/libarchive_test.2012-02-06T23.02.12-000 FAIL: libarchive_test s390: Totals: Tests run: 172 Tests failed: 1 Assertions checked:12407234 Assertions failed: 3 Skips reported: 73 Failing tests: 60: test_read_disk_directory_traversals (3 failures) Details for failing tests: /tmp/libarchive_test.2012-02-06T22.43.00-000 FAIL: libarchive_test s390x: Totals: Tests run: 31 Tests failed: 1 Assertions checked: 7460 Assertions failed: 2 Skips reported: 1 Failing tests: 13: test_option_b (2 failures) Details for failing tests: /tmp/bsdtar_test.2012-02-06T22.40.24-000 FAIL: bsdtar_test hurd-i386: Totals: Tests run: 31 Tests failed: 2 Assertions checked: 7459 Assertions failed: 3 Skips reported: 1 Failing tests: 7: test_option_H_upper (1 failures) 8: test_option_L_upper (2 failures) Details for failing tests: /tmp/bsdtar_test.2012-02-07T00.14.52-000 FAIL: bsdtar_test [...] Totals: Tests run: 28 Tests failed: 2 Assertions checked: 923 Assertions failed: 14 Skips reported: 1 Failing tests: 1: test_basic (13 failures) 26: test_passthrough_reverse (1 failures) Details for failing tests: /tmp/bsdcpio_test.2012-02-07T00.22.32-000 FAIL: bsdcpio_test Cheers, Julien -- ~ Andres -- You received this message because you are subscribed to the Google Groups libarchive-discuss group. To post to this group, send email to libarchive-disc...@googlegroups.com. To unsubscribe from this group, send email to libarchive-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/libarchive-discuss?hl=en. -- ~ Andres -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659294: libarchive: FTBFS on various architectures (hurd, mipsel, s390, s390x)
tags 659294 help stop On Thu, Feb 9, 2012 at 5:52 PM, Julien Cristau jcris...@debian.org wrote: Source: libarchive Version: 3.0.3-3 Severity: serious Justification: fails to build from source (but built successfully in the past) libarchive FTBFS on various buildds, with test failures: https://buildd.debian.org/status/package.php?p=libarchive mipsel: Totals: Tests run: 172 Tests failed: 1 Assertions checked:12407225 Assertions failed: 3 Skips reported: 73 Failing tests: 60: test_read_disk_directory_traversals (3 failures) Details for failing tests: /tmp/libarchive_test.2012-02-06T23.02.12-000 FAIL: libarchive_test s390: Totals: Tests run: 172 Tests failed: 1 Assertions checked:12407234 Assertions failed: 3 Skips reported: 73 Failing tests: 60: test_read_disk_directory_traversals (3 failures) Details for failing tests: /tmp/libarchive_test.2012-02-06T22.43.00-000 FAIL: libarchive_test s390x: Totals: Tests run: 31 Tests failed: 1 Assertions checked: 7460 Assertions failed: 2 Skips reported: 1 Failing tests: 13: test_option_b (2 failures) Details for failing tests: /tmp/bsdtar_test.2012-02-06T22.40.24-000 FAIL: bsdtar_test hurd-i386: Totals: Tests run: 31 Tests failed: 2 Assertions checked: 7459 Assertions failed: 3 Skips reported: 1 Failing tests: 7: test_option_H_upper (1 failures) 8: test_option_L_upper (2 failures) Details for failing tests: /tmp/bsdtar_test.2012-02-07T00.14.52-000 FAIL: bsdtar_test [...] Totals: Tests run: 28 Tests failed: 2 Assertions checked: 923 Assertions failed: 14 Skips reported: 1 Failing tests: 1: test_basic (13 failures) 26: test_passthrough_reverse (1 failures) Details for failing tests: /tmp/bsdcpio_test.2012-02-07T00.22.32-000 FAIL: bsdcpio_test Cheers, Julien Note that this time, I'm expecting the test suite to pass for all architectures. It has failed the test suite in the previous version, though test suite failures had been ignored. I'm going to need some help resolving this issue on these architectures. Patches welcome, even if they're against the test suite. -- ~ Andres -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659294: Fwd: Bug#659294: libarchive: FTBFS on various architectures (hurd, mipsel, s390, s390x)
There are some build failures on various architectures in Debian. Note that they're failures in the test suite. -- Forwarded message -- From: Julien Cristau jcris...@debian.org Date: Thu, Feb 9, 2012 at 5:52 PM Subject: Bug#659294: libarchive: FTBFS on various architectures (hurd, mipsel, s390, s390x) To: Debian Bug Tracking System sub...@bugs.debian.org Source: libarchive Version: 3.0.3-3 Severity: serious Justification: fails to build from source (but built successfully in the past) libarchive FTBFS on various buildds, with test failures: https://buildd.debian.org/status/package.php?p=libarchive mipsel: Totals: Tests run: 172 Tests failed: 1 Assertions checked:12407225 Assertions failed: 3 Skips reported: 73 Failing tests: 60: test_read_disk_directory_traversals (3 failures) Details for failing tests: /tmp/libarchive_test.2012-02-06T23.02.12-000 FAIL: libarchive_test s390: Totals: Tests run: 172 Tests failed: 1 Assertions checked:12407234 Assertions failed: 3 Skips reported: 73 Failing tests: 60: test_read_disk_directory_traversals (3 failures) Details for failing tests: /tmp/libarchive_test.2012-02-06T22.43.00-000 FAIL: libarchive_test s390x: Totals: Tests run: 31 Tests failed: 1 Assertions checked: 7460 Assertions failed: 2 Skips reported: 1 Failing tests: 13: test_option_b (2 failures) Details for failing tests: /tmp/bsdtar_test.2012-02-06T22.40.24-000 FAIL: bsdtar_test hurd-i386: Totals: Tests run: 31 Tests failed: 2 Assertions checked: 7459 Assertions failed: 3 Skips reported: 1 Failing tests: 7: test_option_H_upper (1 failures) 8: test_option_L_upper (2 failures) Details for failing tests: /tmp/bsdtar_test.2012-02-07T00.14.52-000 FAIL: bsdtar_test [...] Totals: Tests run: 28 Tests failed: 2 Assertions checked: 923 Assertions failed: 14 Skips reported: 1 Failing tests: 1: test_basic (13 failures) 26: test_passthrough_reverse (1 failures) Details for failing tests: /tmp/bsdcpio_test.2012-02-07T00.22.32-000 FAIL: bsdcpio_test Cheers, Julien -- ~ Andres -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#637758: Distributing static libraries
On Thu, Aug 11, 2011 at 11:40 PM, Felipe Sateler fsate...@debian.org wrote: On Thu, Aug 11, 2011 at 22:29, Andres Mejia mcita...@gmail.com wrote: On Thu, Aug 11, 2011 at 3:46 AM, Fabian Greffrath fab...@greffrath.com wrote: Am 11.08.2011 05:22, schrieb Andres Mejia: I have seen a commit with mp4v2 that disables building of the static library. Though I know binaries in Debian are normally linked with shared libraries, distributing the static library is beneficial to users with different requirements for software they distribute. I have heard of various use cases involving distribution of stand alone binaries (no dependent shared libraries). The problem with this specific library is its license, which prohibits linking against about 99% of packages that come into consideration to make use of it. So most probably any application that statically links against it commits a license violation. :/ Therefore, many applications fall back to dlopen() the library, in which case only the header files (if at all) are required. A similar case is libdvdcss. All applications that I know to make use of it try to dlopen() it instead of explicit linking, because they know that this library is widely considered undistributable - though for other reasons. - Fabian ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintain...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers Ok, I see you're considering to licensing issues with mp4v2. I was referring to the issue of simply providing static libraries in general (not just with mp4v2). To state what I've mentioned another way, we shouldn't disable distribution of static libraries simply because packages in Debian won't link to them. Actually, I think static libraries should be disabled by default and enabled when needed. They provide zero value for most. Those who need it can build the static libraries themselves. And they probably will/should anyways, since static libs will probably be used in some rare context. Going back to the issue of distributing static libs, I suppose it's true that static libs will not be needed by most. However, the users that would need them would expect them to be in the development package of their distro (in Debian's case, the -dev package). We could make these users build the libraries themselves, but then they would also need to build all the build dependencies as well for the library they need. This can be quite a burden on various architectures, such as arm or mips. I'm sure everyone here is aware that for most libraries, it's not just a matter of running './configure make'. It's likely these various users would be under limited time and resources to provide their deliverable, thus I suspect they would simply look elsewhere for precompiled static libraries. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintain...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623007: openal-soft: FTBFS: sed: unterminated 's' command
severity 623007 important tags 623007 unreproducible stop On Saturday 16 April 2011 11:37:30 am Daniel Schepler wrote: Source: openal-soft Version: 1:1.12.854-2 Severity: serious From my pbuilder build log: ... dh_installdeb debian/rules override_dh_gencontrol make[1]: Entering directory `/tmp/buildd/openal-soft-1.12.854' dh_gencontrol sed s/^Depends:.*$/\nRecommends: $(sh debian/var_info LIBPULSE_DEPENDS)/ \ -i debian/libopenal1/DEBIAN/control sed s/^Recommends:.*$/\nSuggests: $(sh debian/var_info LIBPORTAUDIO_DEPENDS)/ \ -i debian/libopenal1/DEBIAN/control sed: -e expression #1, char 44: unterminated `s' command make[1]: *** [override_dh_gencontrol] Error 1 make[1]: Leaving directory `/tmp/buildd/openal-soft-1.12.854' make: *** [binary] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 I am unable to reproduce this problem using sbuild. Also, none of the buildd machines had this particular problem building openal-soft. I would check your pbuilder setup, and perhaps generate a new pbuilder tarball. -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601220: noip2: abuse of debconf
On Thu, Nov 18, 2010 at 7:00 AM, Andreas Henriksson andr...@fatal.se wrote: On Wed, Nov 17, 2010 at 05:31:03PM -0500, Andres Mejia wrote: For anyone looking into resolving this bug, feel free to remove me as uploader. I no longer use the noip service thus I no longer have any interest in maintaining this package. Please google for How to orphan packages properly. -- Andreas Henriksson Well if the last maintainer doesn't respond or says he no longer wants to maintain no-ip, then yes, this package should be orphaned. -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601220: noip2: abuse of debconf
On Sun, Oct 24, 2010 at 8:44 AM, Jakub Wilk jw...@debian.org wrote: Package: noip2 Version: 2.1.9-3 Severity: serious Justification: Policy 10.7 The only place noip2 store configuration data (apart from the debconf cache) is a binary blob in /var/lib/noip2/. This file will be happily overwritten on each upgrade using *only* values supplied by debconf. -- Jakub Wilk -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJMxCocAAoJEC1Os6YBVHX1bBwP/02ty0C3MHO4vcXjLMCnuT4B HTSaoUi/vf+k9PBbtFhaKa5iDE6oSOprOFiGDeuwcFeK+zJU8Hoil3XjheA2x+ak LXsF9OUrQeuOJ63j4HSRnTYspsK7RX3ezKqUzMyOT4PdIgIXxV4WtytX2jWs+oP1 JnbctxKRrwyrfSp9uFvhcc6uUFMZVUGAQRqHq/355qJDKN7b03WFl0gveRFASazn LyLOC5Dvm6T0VFRrwTMuRttZZGaU8RTANaid6fQkS2lC4Wk/U7xHrxhtJqGovx7j CJjH9ZfMuAASPPEJYepNMN6JimLilxl7PYQ8AFLajiK0JOpkIqJsVW7yRLnaIgEc KUKIxShr3tTR48OE+SyiTDU5jRt/+J6cWZz78UgJGfQDnKkNtGu9RYV3Y08Pyy5A cJr7t9iXYrfqcqTigobP7ybB8Wd4kZdNjJN7lKPGTQC7jntPrp7shaBAa7o3SzNa KXIECM2M15hsqZK5bFaV40LTvcmHmUJVM5g4J8pBR4YcJtISzq55uXaYH2DtaixI JvibWOkTdQ4ajHfkEfZzp36PQ+i1Pit55U+KzuRzKCz834eWDtCojLKLsKV63cm8 qDyqZgUchvvUVkWymTRmT2d9vVImfpub5WLrf1BPpz23FaWun+/y/y+JcPjqC79M T99gANkfu3c3BvZQH0Zd =Wlvg -END PGP SIGNATURE- For anyone looking into resolving this bug, feel free to remove me as uploader. I no longer use the noip service thus I no longer have any interest in maintaining this package. -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#603220: libvdpau (updated package)
Hello, The current package of libvdpau in experimental (0.4.1-1) would fix bug #603220. The package in libvdpau is 0.4-5. The differences between the two packages can be found at [1]. The only change by upstream from 0.4 to 0.4.1 were minor documentation changes in the public headers [2]. Question I have is, would it be alright to make an upload of the package from experimental to unstable and if so, could I be granted a freeze exception? 1. http://packages.debian.org/changelogs/pool/main/libv/libvdpau/current/changelog 2. http://cgit.freedesktop.org/~aplattner/libvdpau/diff/?id=76fdf83a7690ce366edbd4816b3c4b6728eeb9eeid2=581d8bbcd36b85fb368446180053204118829fc1 -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#603220: RFS: libvdpau (updated package)
On Thursday 11 November 2010 17:54:53 Michael Gilbert wrote: Hi, Would anyone be willing to sponsor another RC-fix upload? This new libvdpau package fixes bug #603220: http://mentors.debian.net/debian/pool/main/l/libvdpau Thanks, Mike Well, I'm sure the maintainers of libvdpau would be willing to acknowledge the bug you reported merely a few hours ago and correct the issue in a timely manner. -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602209: tar: Fails using '-C' option extracting archive with empty directories
retitle 602209 tar: Fails using '-C' option extracting archive with empty directories thanks Here's clarification of what the issue is. The new tar in unstable fails to extract the empty directories inside an archive when using the '-C' option to change directories. Here are the steps to reproduce with output. Aside from affecting lintian when testing certain packages, this also affects piuparts. $ mkdir test $ tar -czf test.tar.gz test/ $ tar -C /tmp -xzf test.tar.gz tar: test: Cannot utime: No such file or directory tar: test: Cannot stat: No such file or directory tar: Exiting with failure status due to previous errors -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602209: tar: [PATCH] Fails using '-C' option extracting archive with empty directories
The other link provided earlier is down. Here's the fix in upstream's git repo. http://git.savannah.gnu.org/cgit/tar.git/commit/?id=acb77ac5bd4bf9248070c9c512525eee8258aebd -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595559:
Hello, My name is listed in the Uploaders field, yet I did send a notification to Federico long ago that I wouldn't maintain freeimage any longer. For me, it would be OK to take over freeimage maintenance, but of course you should make the attempt to contact the other maintainers. You might consider asking them about ogre maintenance as well. On Sun, Sep 5, 2010 at 11:07 AM, Cosme Domínguez Díaz cosme.dd...@gmail.com wrote: Hi, I'm interesting in maintain freeimage. I have my 3.13.1 release of freeimage in Ubuntu: http://packages.ubuntu.com/source/maverick/freeimage And the latest 3.14.1 in OGRE PPA: https://launchpad.net/~ogre-team/+archive/ogre/+packages FreeImage is a dependency of OGRE 3D and I'm working with that engine. The problem is that I'm not a DD and I don't know how submit packages to Debian... -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585821: libvpx: includes non-free MD5 implementation
Package: libvpx
Version: 0.9.0-6
Severity: serious
Justification: Policy 2.2.1
md5_utils.[ch] is an implementation of the MD5 algorithm from
RSA Data Security, Inc. This implementation is considered non-free. Here is
some explainations as to why [1] [2].
Attached is a patch that replaces the non-free implementation of the MD5
algorithm with a public domain implementation. This implementation is derived
from the MD5 implementation found in dpkg.
1. http://lists.debian.org/debian-mentors/2009/08/msg00082.html
2. http://bugs.debian.org/340538
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
This patch replaces the non-free RSA Data Security, Inc. implementation of the
MD5 algorithm with a public domain implementation.
--- libvpx-0.9.0.orig/ivfdec.c
+++ libvpx-0.9.0/ivfdec.c
@@ -235,9 +235,9 @@ void *out_open(const char *out_fn, int d
if (do_md5)
{
#if CONFIG_MD5
-md5_ctx_t *md5_ctx = out = malloc(sizeof(md5_ctx_t));
+MD5Context *md5_ctx = out = malloc(sizeof(MD5Context));
(void)out_fn;
-md5_init(md5_ctx);
+MD5Init(md5_ctx);
#endif
}
else
@@ -259,7 +259,7 @@ void out_put(void *out, const uint8_t *b
if (do_md5)
{
#if CONFIG_MD5
-md5_update(out, buf, len);
+MD5Update(out, buf, len);
#endif
}
else
@@ -276,7 +276,7 @@ void out_close(void *out, const char *ou
uint8_t md5[16];
int i;
-md5_finalize(out, md5);
+MD5Final(md5, out);
free(out);
for (i = 0; i 16; i++)
--- libvpx-0.9.0.orig/md5_utils.c
+++ libvpx-0.9.0/md5_utils.c
@@ -1,299 +1,240 @@
/*
- * Copyright (c) 2010 The VP8 project authors. All Rights Reserved.
+ * This code implements the MD5 message-digest algorithm.
+ * The algorithm is due to Ron Rivest. This code was
+ * written by Colin Plumb in 1993, no copyright is claimed.
+ * This code is in the public domain; do with it what you wish.
*
- * Use of this source code is governed by a BSD-style license
- * that can be found in the LICENSE file in the root of the source
- * tree. An additional intellectual property rights grant can be found
- * in the file PATENTS. All contributing project authors may
- * be found in the AUTHORS file in the root of the source tree.
+ * Equivalent code is available from RSA Data Security, Inc.
+ * This code has been tested against that, and is equivalent,
+ * except that you don't need to include two pages of legalese
+ * with every copy.
+ *
+ * To compute the message digest of a chunk of bytes, declare an
+ * MD5Context structure, pass it to MD5Init, call MD5Update as
+ * needed on buffers full of bytes, and then call MD5Final, which
+ * will fill a supplied 16-byte array with the digest.
+ *
+ * Changed so as no longer to depend on Colin Plumb's `usual.h' header
+ * definitions; now uses stuff from dpkg's config.h.
+ * - Ian Jackson i...@chiark.greenend.org.uk.
+ * Still in the public domain.
*/
+#include sys/types.h/* for stupid systems */
-/*
-Copyright (C) 1991-2, RSA Data Security, Inc. Created 1991. All
-rights reserved.
-
-License to copy and use this software is granted provided that it
-is identified as the RSA Data Security, Inc. MD5 Message-Digest
-Algorithm in all material mentioning or referencing this software
-or this function.
-
-License is also granted to make and use derivative works provided
-that such works are identified as derived from the RSA Data
-Security, Inc. MD5 Message-Digest Algorithm in all material
-mentioning or referencing the derived work.
-
-RSA Data Security, Inc. makes no representations concerning either
-the merchantability of this software or the suitability of this
-software for any particular purpose. It is provided as is
-without express or implied warranty of any kind.
-
-These notices must be retained in any copies of any part of this
-documentation and/or software.
-*/
+#include string.h /* for memcpy() */
#include md5_utils.h
-#include string.h
-
-/* Constants for md5_transform routine.
- */
-#define S11 7
-#define S12 12
-#define S13 17
-#define S14 22
-#define S21 5
-#define S22 9
-#define S23 14
-#define S24 20
-#define S31 4
-#define S32 11
-#define S33 16
-#define S34 23
-#define S41 6
-#define S42 10
-#define S43 15
-#define S44 21
-
-static void md5_transform(uint32_t state[4], const uint8_t block[64]);
-static void Encode(uint8_t *output, const uint32_t *input, unsigned int len);
-static void Decode(uint32_t *output, const uint8_t *input, unsigned int len);
-#define md5_memset memset
-#define md5_memcpy memcpy
-static unsigned char PADDING[64] =
-{
-0x80, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
Bug#585821: libvpx: includes non-free MD5 implementation
Slight update to the patch. I removed mention that the MD5 implementation uses
stuff from dpkg's config.h. It doesn't require config.h at all.
--
Regards,
Andres Mejia
This patch replaces the non-free RSA Data Security, Inc. implementation of the
MD5 algorithm with a public domain implementation.
--- libvpx-0.9.0.orig/ivfdec.c
+++ libvpx-0.9.0/ivfdec.c
@@ -235,9 +235,9 @@ void *out_open(const char *out_fn, int d
if (do_md5)
{
#if CONFIG_MD5
-md5_ctx_t *md5_ctx = out = malloc(sizeof(md5_ctx_t));
+MD5Context *md5_ctx = out = malloc(sizeof(MD5Context));
(void)out_fn;
-md5_init(md5_ctx);
+MD5Init(md5_ctx);
#endif
}
else
@@ -259,7 +259,7 @@ void out_put(void *out, const uint8_t *b
if (do_md5)
{
#if CONFIG_MD5
-md5_update(out, buf, len);
+MD5Update(out, buf, len);
#endif
}
else
@@ -276,7 +276,7 @@ void out_close(void *out, const char *ou
uint8_t md5[16];
int i;
-md5_finalize(out, md5);
+MD5Final(md5, out);
free(out);
for (i = 0; i 16; i++)
--- libvpx-0.9.0.orig/md5_utils.c
+++ libvpx-0.9.0/md5_utils.c
@@ -1,299 +1,240 @@
/*
- * Copyright (c) 2010 The VP8 project authors. All Rights Reserved.
+ * This code implements the MD5 message-digest algorithm.
+ * The algorithm is due to Ron Rivest. This code was
+ * written by Colin Plumb in 1993, no copyright is claimed.
+ * This code is in the public domain; do with it what you wish.
*
- * Use of this source code is governed by a BSD-style license
- * that can be found in the LICENSE file in the root of the source
- * tree. An additional intellectual property rights grant can be found
- * in the file PATENTS. All contributing project authors may
- * be found in the AUTHORS file in the root of the source tree.
+ * Equivalent code is available from RSA Data Security, Inc.
+ * This code has been tested against that, and is equivalent,
+ * except that you don't need to include two pages of legalese
+ * with every copy.
+ *
+ * To compute the message digest of a chunk of bytes, declare an
+ * MD5Context structure, pass it to MD5Init, call MD5Update as
+ * needed on buffers full of bytes, and then call MD5Final, which
+ * will fill a supplied 16-byte array with the digest.
+ *
+ * Changed so as no longer to depend on Colin Plumb's `usual.h' header
+ * definitions
+ * - Ian Jackson i...@chiark.greenend.org.uk.
+ * Still in the public domain.
*/
+#include sys/types.h/* for stupid systems */
-/*
-Copyright (C) 1991-2, RSA Data Security, Inc. Created 1991. All
-rights reserved.
-
-License to copy and use this software is granted provided that it
-is identified as the RSA Data Security, Inc. MD5 Message-Digest
-Algorithm in all material mentioning or referencing this software
-or this function.
-
-License is also granted to make and use derivative works provided
-that such works are identified as derived from the RSA Data
-Security, Inc. MD5 Message-Digest Algorithm in all material
-mentioning or referencing the derived work.
-
-RSA Data Security, Inc. makes no representations concerning either
-the merchantability of this software or the suitability of this
-software for any particular purpose. It is provided as is
-without express or implied warranty of any kind.
-
-These notices must be retained in any copies of any part of this
-documentation and/or software.
-*/
+#include string.h /* for memcpy() */
#include md5_utils.h
-#include string.h
-
-/* Constants for md5_transform routine.
- */
-#define S11 7
-#define S12 12
-#define S13 17
-#define S14 22
-#define S21 5
-#define S22 9
-#define S23 14
-#define S24 20
-#define S31 4
-#define S32 11
-#define S33 16
-#define S34 23
-#define S41 6
-#define S42 10
-#define S43 15
-#define S44 21
-
-static void md5_transform(uint32_t state[4], const uint8_t block[64]);
-static void Encode(uint8_t *output, const uint32_t *input, unsigned int len);
-static void Decode(uint32_t *output, const uint8_t *input, unsigned int len);
-#define md5_memset memset
-#define md5_memcpy memcpy
-static unsigned char PADDING[64] =
-{
-0x80, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
-};
+#ifdef WORDS_BIGENDIAN
+void
+byteSwap(UWORD32 *buf, unsigned words)
+{
+ md5byte *p = (md5byte *)buf;
+
+ do {
+*buf++ = (UWORD32)((unsigned)p[3] 8 | p[2]) 16 |
+ ((unsigned)p[1] 8 | p[0]);
+p += 4;
+ } while (--words);
+}
+#else
+#define byteSwap(buf,words)
+#endif
-/* F, G, H and I are basic MD5 functions.
- */
-#define F(x, y, z) (((x) (y)) | ((~x) (z)))
-#define G(x, y, z) (((x) (z)) | ((y) (~z)))
-#define H(x, y, z) ((x) ^ (y) ^ (z))
-#define I(x, y, z) ((y) ^ ((x) | (~z)))
-
-/* ROTATE_LEFT rotates x left n bits.
- */
-#define ROTATE_LEFT(x, n) (((x) (n)) | ((x) (32-(n
-
-/* FF, GG, HH
Bug#585821: libvpx: includes non-free MD5 implementation
forwarded 585821 https://review.webmproject.org/#change,147 thanks I went ahead and forwarded this issue upstream. I've also had to change the patch to follow their guidelines and also to check for endianness during runtime, since there exists platforms that can be both big endian and little endian. -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#581265: [Pkg-chromium-maint] Bug#581265: release blocking bug
On Wed, May 12, 2010 at 2:50 AM, Gerfried Fuchs rho...@debian.at wrote: Package: chromium-browser Severity: serious Hi! Like mentioned by Moritz from the Security Team in [1] this package is meant to stay out of squeeze. This bugreport is thus filed to ensure that. Please only close it after the squeeze release. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520324#252 Thanks for the work on the package! Rhonda ___ Pkg-chromium-maint mailing list pkg-chromium-ma...@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-chromium-maint You could have also asked the release team to block automatic migration of chromium-browser to testing. I was going to suggest that earlier. -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#577217: [PATCH] speech-dispatcher locks main audio pcm preventing other apps to use sound
tags 577217 patch fixed-upstream thanks Attached is a patch that updates the packaging to make speech-dispatcher use pulse by default instead of alsa. The idea was taken from upstream [1]. This would prevent the locking of audio devices from speech-dispatcher. What would probably be better is to package a new version of speech-dispatcher from the 0.6.8~unofficial~rc2 release [2]. Ubuntu has already done so in lucid. [1] http://git.freebsoft.org/?p=speechd.git;a=commitdiff;h=ce127be6fcfbcb93cb4bd891b662e8483c11f4c5 [2] http://git.freebsoft.org/?p=speechd.git;a=commit;h=a4f04906e633d7577892131620eb138ba94e0a50 -- Regards, Andres Mejia diff --git a/debian/patches/08_pulse-default.dpatch b/debian/patches/08_pulse-default.dpatch new file mode 100755 index 000..f82e0db --- /dev/null +++ b/debian/patches/08_pulse-default.dpatch @@ -0,0 +1,43 @@ +#! /bin/sh /usr/share/dpatch/dpatch-run +## 08_pulse-default.dpatch +## +## All lines beginning with `## DP:' are a description of the patch. +## DP: Fix to make using pulse the default instead of alsa. +## DP: See http://bugs.debian.org/577217 + +...@dpatch@ +diff --git a/config/speechd.conf.in b/config/speechd.conf.in +index abd458f..b657fbf 100644 +--- a/config/speechd.conf.in b/config/speechd.conf.in +@@ -132,7 +132,7 @@ DefaultVolume 100 + # alsa - Advanced Linux Sound System + # nas - Network Audio System + # pulse - PulseAudio +-# ALSA is default and recommended. The recent implementations ++# PulseAudio is default and recommended. The recent implementations + # support mixing of multiple streams. OSS is only provided + # for compatibility with architectures that do not include ALSA. + # NAS is an audio server with higher level of control over +@@ -142,7 +142,7 @@ DefaultVolume 100 + # PulseAudio is a sound server for POSIX and WIN32 systems. + # + +-# AudioOutputMethod alsa ++# AudioOutputMethod pulse + + # What ALSA device to use when Advanced Linux Sound Architecture is + # chosen for the audio output. +diff --git a/src/server/config.c b/src/server/config.c +index 7c8f662..82e34d0 100644 +--- a/src/server/config.c b/src/server/config.c +@@ -431,7 +431,7 @@ load_default_global_set_options() + GlobalFDSet.ssml_mode = 0; + GlobalFDSet.notification = NOTIFY_NOTHING; + +-GlobalFDSet.audio_output_method = strdup(alsa); ++GlobalFDSet.audio_output_method = strdup(pulse); + GlobalFDSet.audio_oss_device = strdup(/dev/dsp); + GlobalFDSet.audio_alsa_device = strdup(default); + GlobalFDSet.audio_nas_server = strdup(tcp/localhost:5450); diff --git a/debian/init.d b/debian/init.d index 08af0ae..0bc4f90 100644 --- a/debian/init.d +++ b/debian/init.d @@ -2,8 +2,8 @@ ### BEGIN INIT INFO # Provides: speech-dispatcher -# Required-Start: -# Required-Stop: +# Required-Start:$remote_fs pulseaudio +# Required-Stop: $remote_fs pulseaudio # Should-Start: festival # Should-Stop: festival # Default-Start: 2 3 4 5 diff --git a/debian/patches/00list b/debian/patches/00list index 1cf25fa..66bc4b0 100644 --- a/debian/patches/00list +++ b/debian/patches/00list @@ -3,3 +3,5 @@ 04_getline.dpatch 05_libspeechd.dpatch 06_extlink.dpatch +08_pulse-default.dpatch
Bug#577896: [PATCH] speech-dispatcher: FTBFS: flite.c:435: undefined reference to `register_cmu_us_kal'
tags 577896 patch thanks Here's a patch that will fix the build failure. flite-1.4 now uses new_voice() instead of register_cmu_us_kal(). -- Regards, Andres Mejia 07_flite-1.4-fix.dpatch Description: application/shellscript
Bug#580113: [mplayer] No audio output to pulse
tags 580113 unreproducible severity 580113 important thanks I too am not able to reproduce this problem. I have no issue using pulse as the audio output driver with latest mplayer. Setting this bug to important as well since more than one user was not able to reproduce the bug, and also since this issue, although it is a major issue if the bug indeed exists, does not make mplayer useless. There is more than one audio output driver that mplayer supports. If you have reportbug installed, please post the output of 'reportbug --template mplayer'. On Monday 03 May 2010 14:30:22 Alexander Hofbauer wrote: Any chance to check with other PA-enabled clients to verify our PA installation? (like vlc with the pulseaudio modules) Just tried vlc with vlc-plugin-pulse: --- pulse audio output: No. of Audio Channels: 2 pulse audio output debug: Pulse mainloop started pulse audio output debug: Pulse stream connected pulse audio output debug: Pulse initialized successfully pulse audio output debug: Buffer metrics: maxlength=141120, tlength=42336, prebuf=35280, minreq=7056 pulse audio output debug: Using sample spec 'float32le 2ch 44100Hz', channel map 'front-left,front-right'. pulse audio output debug: Connected to device alsa_output.pci-_00_1b.0.analog-stereo (0, not suspended). main audio output debug: using audio output module pulse pulse audio output debug: Pulse stream started --- I think this means that pulseaudio is working correctly here. -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#576591: mplayer - gmplayer fails by default
On Tuesday 06 April 2010 01:17:32 Reinhard Tartler wrote: On Tue, Apr 06, 2010 at 00:50:17 (CEST), Bastian Blank wrote: On Tue, Apr 06, 2010 at 12:08:46AM +0200, Reinhard Tartler wrote: why do you consider this grave? It only affects gmplayer, which is deprecated upstream. The package still depends on mplayer-skin, which is only used in gmplayer. So it is considered a central part in the Debian package. I cannot follow this reasoning; this upstream maintenance status has nothing to do with this dependency. Dropping gmplayer would allow us to remove mplayer-skin from debian. This bug is not relevant anymore since gmplayer is no longer provided in current mplayer packages. Should this bug be closed? -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#576592: mplayer - Tries to use OSS first
On Monday 05 April 2010 17:19:38 Bastian Blank wrote: Package: mplayer Version: 1.0~rc3+svn20090405-1+b1 Severity: grave mplayer tries to use OSS first. With gmplayer this even produces an warning dialog box. Using OSS is bad because the default implementation (the kernel OSS emulation for ALSA) does not support multiplexing and therefor disallows any other access to the sound device. Bastian Ok. I do see this to be an issue on systems with ALSA or Pulseaudio, but why the severity grave? This to me seems to merit severity of important. I thought ALSA already handles OSS emulation by default, and it's certainly possible to do the same with Pulseaudio. On top of that, you can set /etc/mplayer/mplayer.conf to use any audio output driver as default. -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573269: pidgin segfaults upon startup since gst-plugins-bad0.10 version 0.10.18-1
On Tuesday 23 March 2010 22:24:02 Ari Pollak wrote: I can't seem to reproduce this. Can you send the output of gconftool -R /system/gstreamer/0.10/default ? Here it is. $ gconftool -R /system/gstreamer/0.10/default musicaudiosink_description = Default videosink = autovideosink visualization = goom audiosink = autoaudiosink musicaudiosink = autoaudiosink chataudiosink_description = Default audiosrc_description = Default audiosink_description = Default chataudiosink = autoaudiosink audiosrc = autoaudiosrc videosrc = v4l2src -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573269: pidgin segfaults upon startup since gst-plugins-bad0.10 version 0.10.18-1
Package: pidgin Version: 2.6.6-2 Severity: grave Justification: renders package unusable Since the upload of gst-plugins-bad0.10 version 0.10.18-1, pidgin segfaults upon startup. Message on the command line is: $ pidgin ERROR: Caught a segmentation fault while loading plugin file: /usr/lib/gstreamer-0.10/libgstlv2.so Please either: - remove it and restart. - run with --gst-disable-segtrap and debug. A workaround is to remove the file in question. $ ln -sf /dev/null /usr/lib/gstreamer-0.10/libgstlv2.so Not sure if this is a problem with pidgin, or really with the new version of gst-plugins-bad0.10. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages pidgin depends on: ii gconf2 2.28.0-1GNOME configuration database syste ii libatk1.0-0 1.28.0-1The ATK accessibility toolkit ii libc62.10.2-6Embedded GNU C Library: Shared lib ii libcairo21.8.10-2The Cairo 2D vector graphics libra ii libdbus-1-3 1.2.20-2simple interprocess messaging syst ii libdbus-glib-1-2 0.84-1 simple interprocess messaging syst ii libfontconfig1 2.8.0-2 generic font configuration library ii libfreetype6 2.3.11-1FreeType 2 font engine, shared lib ii libglib2.0-0 2.22.4-1The GLib library of C routines ii libgstreamer0.10-0 0.10.28-1 Core GStreamer libraries and eleme ii libgtk2.0-0 2.18.7-1The GTK+ graphical user interface ii libgtkspell0 2.0.16-1a spell-checking addon for GTK's T ii libice6 2:1.0.6-1 X11 Inter-Client Exchange library ii libpango1.0-01.26.2-1Layout and rendering of internatio ii libpurple0 2.6.6-2 multi-protocol instant messaging l ii libsm6 2:1.1.1-1 X11 Session Management library ii libstartup-notification0 0.10-1 library for program launch feedbac ii libx11-6 2:1.3.3-1 X11 client-side library ii libxml2 2.7.6.dfsg-2+b1 GNOME XML library ii libxss1 1:1.2.0-2 X11 Screen Saver extension library ii perl 5.10.1-11 Larry Wall's Practical Extraction ii perl-base [perlapi-5.10. 5.10.1-11 minimal Perl system ii pidgin-data 2.6.6-2 multi-protocol instant messaging c Versions of packages pidgin recommends: ii gstreamer0.10-plugins-base0.10.28-1 GStreamer plugins from the base ii gstreamer0.10-plugins-good0.10.21-1 GStreamer plugins from the good Versions of packages pidgin suggests: pn evolution-data-server none (no description available) ii kdebase-workspace-bin 4:4.3.4-5 core binaries for the KDE 4 base w ii libsqlite3-0 3.6.22-1 SQLite 3 shared library -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568961: FTBFS: configure: error: unable to configure ffmpegthumbnailer support
severity 568961 important tags 568961 fixed-upstream pending thanks On Monday 08 February 2010 21:15:00 Nobuhiro Iwamatsu wrote: Package: mediatomb Version: 0.12.0~svn2018-5 Severity: serious Justification: ftbfs Hi, mediatomb FTBFS on sid. [...] checking for av_register_all in -lavformat... yes checking for av_log_set_callback in -lavutil... yes checking libffmpegthumbnailer/videothumbnailerc.h usability... yes checking libffmpegthumbnailer/videothumbnailerc.h presence... yes checking for libffmpegthumbnailer/videothumbnailerc.h... yes checking for create_thumbnailer in -lffmpegthumbnailer... no checking for create_thumbnailer in -lffmpegthumbnailer... no configure: error: unable to configure ffmpegthumbnailer support make[1]: *** [override_dh_auto_configure] Error 1 make[1]: Leaving directory `/home/iwamatsu/mediatomb/mediatomb-0.12.0~svn2018' [...] ffmpegthumbnailer[0] was updated to 2.0. This doesn't support create_thumbnailer function with 2.0. Please check your pakcage. [0]: http://packages.qa.debian.org/f/ffmpegthumbnailer.html Best regards, Nobuhiro -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.32-trunk-686 (SMP w/2 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash This is fixed for the next package revision that will be uploaded soon. Setting the severity to important so the current version, which already built packages for release architectures, and fixes some other critical bugs, can enter testing. -- Regards, Andres -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560468: Bug#555233: mediatomb: diff for NMU version 0.12.0~svn2018-4.1
On Thursday 04 February 2010 04:36:30 Mehdi wrote: tags 475279 + patch pending tags 555232 + patch pending tags 555233 + patch pending tags 560468 + patch pending thanks Dear maintainer, I've prepared an NMU for mediatomb (versioned as 0.12.0~svn2018-4.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. I updated mediatomb-get-orig-source to remove the embedded prototype.js and use the one from the Debian package libjs-prototype, which seems to work fine with the Web UI. Thank you. I've applied your patch to the packaging for version 0.12.0~svn2018-5 and uploaded it, save for one change. I've left out the change to the meditomb-get-orig-source script, since a new orig tarball is not being uploaded. Also, I prefer to implement a way where mediatomb's build system has an option to either use the system libjs-prototype library, or the internal one. Reason being that using the system library has had other problems before (web interface being completely unusable). -- Regards, Andres -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#567448: vloopback-source: Fails to build with linux-2.6.32
Package: vloopback-source Version: 1.3-1 Severity: grave Tags: patch Justification: renders package unusable Current version of vloopback fails to build with latest Linux kernel 2.6.32. The attached patch was taken from upstream and fixes this issue. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-trunk-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages vloopback-source depends on: ii bzip2 1.0.5-4high-quality block-sorting file co ii debhelper 7.4.11 helper programs for debian/rules ii module-assistant 0.11.3 tool to make module package creati vloopback-source recommends no packages. vloopback-source suggests no packages. -- no debconf information 02_kernel_2.6.32.dpatch Description: application/shellscript
Bug#554953: does not support new source formats
notfound 559533 0.59.0-1 found 559553 0.59.1~rc1 thanks This bug actually only affects sbuild in the git repo. -- Regards, Andres -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544039: mediatomb NMU fixing glibc 2.10 FTBFS.
tags 544039 unreproducible severity 544039 important thanks On Monday 26 October 2009 05:37:14 Andreas Henriksson wrote: Hello! Attached is the diff for the NMU I intend to upload really soon unless there is any activity from the maintainers... I can't reproduce this problem. I have eglibc 2.10.1-5 installed on my system and via a chroot. -- Regards, Andres -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527566: mediatomb-daemon: Installation error due to postinst script
On Monday 31 August 2009 19:43:52 Jeppe Øland wrote: This fix is apparently not making it into testing because it depends on mysql-dfsg-5.1.(And this package was blocked by aba). Any idea when it will move to testing? Ask the debian-release mailing list. -- Regards, Andres -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527566: proposed nmu diff to fix mediatomb-daemon.postinst
On Tuesday 04 August 2009 04:41:13 Andreas Henriksson wrote: Hello! Please see attached NMU diff. I will upload very soon unless someone has any objections! I'll look into this now, so please don't do an NMU. -- Regards, Andres -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525826: flac maintenance RC bug
On Thursday 30 July 2009 03:02:26 Fabian Greffrath wrote: Andres Mejia schrieb: OK. Does anyone want flac to be a multimedia team maintained package? Yes, of course! Ok. I'll submit an ITA bug than. Anyone wanting to start making the necessary changes to flac, go right ahead. I'm currently busy with other things so I won't be able to get to flac right away. -- Regards, Andres -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525826: flac maintenance RC bug
OK. Does anyone want flac to be a multimedia team maintained package? On Wednesday 29 July 2009 11:56:54 Joshua Kwan wrote: Hi Thomas, you're right - please do what you need to. I am too busy these days. -Josh On Wed, Jul 29, 2009 at 09:16:38AM +0200, Thomas Viehmann wrote: Hi Andres, given that Josh did not answer your mail[1] to #525826 about helping with flac and seems to be not too active (public lists seem to have last no posts later than August 2008) at the moment, I would suggest that the multimedia maintainers take over flac unless Josh objects in the next two weeks. I would suggest temporarily dropping Josh from the uploaders and adding him back when he returns to a more active role in maintaining flac in order to not split the maintainer housekeeping in too many steps if he has lost interest. Kind regards T. 1. http://bugs.debian.org/525826#17 -- Thomas Viehmann, http://thomas.viehmann.net/ -- Regards, Andres -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#538753: avifile: contains embedded copy of LAME
Package: avifile Version: 1:0.7.47.20070718 Severity: serious Justification: Policy 2.3 avifile contains an embedded copy of LAME under the directory avifile-0.7.47.20070718/plugins/libmp3lame_audioenc/lame3.70. According to archived discussions at [1], LAME cannot be distributed, even in non-free. This shouldn't have much impact on the functionality of avifile as avifile also supports dlopening the LAME library. I'm also CCing the debian-qa team as it seems the maintainer for avifile is MIA. 1. http://lists.debian.org/debian-devel/2000/06/msg01213.html -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.30-1-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536293: nvidia-glx: shlibs file has obsolete package xlibmesa-gl as a dependency
Package: nvidia-glx Version: 185.18.14-1 Severity: serious Tags: patch Justification: Policy 2.2 For any package that pulls in library dependencies from nvidia-glx.shlibs, the resulting dependency would be 'xlibmesa-gl | libgl1'. This produces lintian error 'E: package: depends-on-obsolete-package depends: xlibmesa-gl' for the corresponding package. xlibmesa-gl is bound to be removed soon, since it was a transition package for Debian etch. Instead the resulting dependency should be 'libgl1-mesa-glx | libgl1' like from the main libgl library. The 'nvidia-glx.shlibs' file should be written like this libGL 1 libgl1-mesa-glx | libgl1 libGLcore 1 libgl1-mesa-glx | libgl1 libXvMCNVIDIA_dynamic 1 nvidia-glx libnvidia-tls 1 nvidia-glx -- Package-specific info: uname -r: Linux andres-desktop 2.6.30-1-686 #1 SMP Sun Jun 14 16:11:32 UTC 2009 i686 GNU/Linux /proc/version: Linux version 2.6.30-1-686 (Debian 2.6.30-1) (wa...@debian.org) (gcc version 4.3.3 (Debian 4.3.3-11) ) #1 SMP Sun Jun 14 16:11:32 UTC 2009 /proc/driver/nvidia/version: 01:00.0 VGA compatible controller: nVidia Corporation G98 [GeForce 8400 GS] (rev a1) -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.30-1-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages nvidia-glx depends on: ii libc6 2.9-19 GNU C Library: Shared libraries ii libgcc1 1:4.4.0-10 GCC support library ii libgl1-mesa-glx [li 7.4.4-1 A free implementation of the OpenG ii libx11-62:1.2.1-1X11 client-side library ii libxext62:1.0.4-1X11 miscellaneous extension librar ii nvidia-kernel-2.6.2 185.18.14-1+2.6.29-5 NVIDIA binary kernel module for Li ii nvidia-kernel-2.6.3 185.18.14-1+2.6.30-1 NVIDIA binary kernel module for Li ii x11-common 1:7.4+3 X Window System (X.Org) infrastruc ii zlib1g 1:1.2.3.3.dfsg-14compression library - runtime nvidia-glx recommends no packages. Versions of packages nvidia-glx suggests: ii nvidia-kernel-source 185.18.14-1 NVIDIA binary kernel module source ii nvidia-settings 180.22-1Tool of configuring the NVIDIA gra -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536293: [pkg-nvidia-devel] Bug#536293: nvidia-glx: shlibs file has obsolete package xlibmesa-gl as a dependency
severity 536293 normal tags 536293 = pending merge 536293 526463 thanks Indeed I didn't see this bug. I'll merge this with the other bug that's been reported. -- Regards, Andres -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534536: nvidia-libvdpau: Shared library doesn't contain soversion in name
Package: nvidia-libvdpau Version: 185.18.14-1 Severity: serious Justification: Policy 8.1 The package name for the libvdpau shared library doesn't contain the soversion in it's name. This will break packages linking to the shared libraries upon a soversion increment. Seeing that libvdpau.so.1 is the symlink to the actual shared library, the package should be renamed to nvidia-libvdpau1. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.29-2-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages nvidia-libvdpau depends on: ii libc6 2.9-18 GNU C Library: Shared libraries ii libx11-6 2:1.2.1-1 X11 client-side library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii x11-common1:7.4+3X Window System (X.Org) infrastruc nvidia-libvdpau recommends no packages. nvidia-libvdpau suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533973: scorched3d: FTBFS: checking for OpenAL support... checking for openal-config... no
On Sunday 21 June 2009 10:55:48 Lucas Nussbaum wrote:
Package: scorched3d
Version: 41.3dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20090620 qa-ftbfs
Justification: FTBFS on amd64
Hi,
During a rebuild of all packages in sid, your package failed to build on
amd64.
Relevant part:
/usr/bin/fakeroot debian/rules clean
dh_testdir
dh_testroot
rm -f build-stamp
[ ! -f Makefile ] || /usr/bin/make distclean
QUILT_PATCHES=debian/patches quilt pop -a -R || test $? = 2
No patch removed
dh_clean debian/scorched3d.png
rm -f data/fonts/test.ttf
rm -f config.log config.status
rm -rf .pc
dh_clean
dpkg-source -b scorched3d-41.3dfsg
dpkg-source: info: using source format `1.0'
dpkg-source: info: building scorched3d using existing
scorched3d_41.3dfsg.orig.tar.gz dpkg-source: info: building scorched3d in
scorched3d_41.3dfsg-1.diff.gz dpkg-source: info: building scorched3d in
scorched3d_41.3dfsg-1.dsc debian/rules build
dh_testdir
QUILT_PATCHES=debian/patches quilt push -a || test $? = 2
Applying patch gcc-4.3.diff
patching file src/common/main.h
patching file src/common/sha2.h
patching file src/common/DefinesFile.cpp
patching file src/common/LoggerI.cpp
Now at patch gcc-4.3.diff
uudecode -o data/fonts/test.ttf debian/test.ttf.uu
./configure \
CFLAGS=-Wall -g -O2 -D_GNU_SOURCE -DHAVE_VASPRINTF \
--host=x86_64-linux-gnu --build=x86_64-linux-gnu \
--prefix=/usr --bindir=\${prefix}/games \
--datadir=\${prefix}/share/games/scorched3d \
--with-docdir=/usr/share/doc/scorched3d \
--mandir=\${prefix}/share/man \
--infodir=\${prefix}/share/info
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking target system type... x86_64-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make sets $(MAKE)... (cached) yes
checking for x86_64-linux-gnu-gcc... x86_64-linux-gnu-gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether x86_64-linux-gnu-gcc accepts -g... yes
checking for x86_64-linux-gnu-gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of x86_64-linux-gnu-gcc... gcc3
checking for x86_64-linux-gnu-g++... x86_64-linux-gnu-g++
checking whether we are using the GNU C++ compiler... yes
checking whether x86_64-linux-gnu-g++ accepts -g... yes
checking dependency style of x86_64-linux-gnu-g++... gcc3
checking for a BSD-compatible install... /usr/bin/install -c
checking for x86_64-linux-gnu-ranlib... no
checking for ranlib... ranlib
checking for beer in -lfridge... no
Warning: No beer found in fridge!
We highly suggest that you rectify this situation immediately.
checking for OpenGL support... yes
configure: error: *** Can't find the openal library. Try:
http://www.openal.org/ checking for OpenAL support... checking for
openal-config... no
*** The openal-config script installed by OpenAL could not be found
*** Make sure openal-config is in your path, or set the OPENAL_CONFIG
*** environment variable to the full path to openal-config.
make: *** [config.status] Error 1
The full build log is available from:
http://people.debian.org/~lucas/logs/2009/06/20/scorched3d_41.3dfsg-1_lsid6
4.buildlog
A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
About the archive rebuild: The rebuild was done on about 50 AMD64 nodes
of the Grid'5000 platform, using a clean chroot. Internet was not
accessible from the build systems.
The new openal will no longer carry openal-config. Either use AC_CHECK_LIB or
pkg-config, whichever is more appropriate.
--
Regards,
Andres
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525826: Help maintaining FLAC
Hello, I noticed that there are open bugs for flac where there's been no response from you, to include this bug. Also, some bugs are over a year old. Did you need help maintaining flac? I'm willing to help out, and I'm sure anyone in the Debian Multimedia team would be willing to help as well. -- Regards, Andres -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533555: libdumb: Licence for DUMB v0.9.3 makes it non-free
Package: libdumb Version: 1:0.9.3 Severity: serious Justification: Policy 2.1 The license to libdumb now has two additional clauses making libdumb non-free. Clause 4 is the only clause that's clarified. Here are the other two. 5. Users who wish to use DUMB for the specific purpose of playing music are required to feed their dog on every full moon (if deemed appropriate). [This clause provided by Allefant, who couldn't remember what Inphernic's clause was.] 6. No clause in this licence shall prevent this software from being depended upon by a product licensed under the GNU General Public Licence. If such a clause is deemed to exist, Debian, then it shall be respected in spirit as far as possible and all other clauses shall continue to apply in full force. I think it's obvious how this fails the Open Source Definition and the DFSG. Here's the full license as found in http://dumb.sourceforge.net/index.php?page=licences Licence for DUMB v0.9.3 /* ___ __ ______ * \_ \ \/ \ / \ \ / / ' ' ' * | | \ \ | ||| | \/ | . . * | | | | | ||| ||\ /| | * | | | | | ||| || \/ | | ' ' ' * | | | | | ||| ||| | . . * | |_/ /\ \__// ||| | * /___/ynamic\/niversal /__\ /\usic /| . . ibliotheque * / \ * / . \ * licence.txt - Conditions for use of DUMB. / / \ \ * | / \_ * If you do not agree to these terms, please| \/ /\ / * do not use DUMB. \_ / / * | \ / / * Information in [brackets] is provided to aid | ' / * interpretation of the licence.\__/ */ Dynamic Universal Music Bibliotheque, Version 0.9.3 Copyright (C) 2001-2005 Ben Davis, Robert J Ohannessian and Julien Cugniere This software is provided 'as-is', without any express or implied warranty. In no event shall the authors be held liable for any damages arising from the use of this software. Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions: 1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, you are requested to acknowledge its use in the product documentation, along with details on where to get an unmodified version of this software, but this is not a strict requirement. [Note that the above point asks for a link to DUMB, not just a mention. Googling for DUMB doesn't help much! The URL is http://dumb.sf.net/;.] [The link was originally strictly required. This was changed for two reasons. Firstly, if many projects request an acknowledgement, the list of acknowledgements can become quite unmanageable. Secondly, DUMB was placing a restriction on the code using it, preventing people from using the GNU General Public Licence which disallows any such restrictions. See http://www.gnu.org/philosophy/bsd.html for more information on this subject. However, if DUMB plays a significant part in your project, we do urge you to acknowledge its use.] 2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software. 3. This notice may not be removed from or altered in any source distribution. 4. If you are using the Program in someone else's bedroom on any Monday at 3:05 pm, you are not allowed to modify the Program for ten minutes. [This clause provided by Inphernic; every licence should contain at least one clause, the reasoning behind which is far from obvious.] 5. Users who wish to use DUMB for the specific purpose of playing music are required to feed their dog on every full moon (if deemed appropriate). [This clause provided by Allefant, who couldn't remember what Inphernic's clause was.] 6. No clause in this licence shall prevent this software from being depended upon by a product licensed under the GNU General Public Licence. If such a clause is deemed to exist, Debian, then it shall be respected in spirit as far as possible and all other clauses shall continue to apply in full force. We regret that we cannot provide any warranty, not even the implied warranty of merchantability or fitness for a particular purpose. Some files generated or copied by automake, autoconf and friends are available in an extra download. These fall under separate licences but are all free to distribute. Please check their licences as
Bug#506179: Fwd: Bug#506179: no-ip: remote code execution vulnerability
I'll upload to unstable. Will someone be handling the upload to stable? -- Regards, Andres signature.asc Description: This is a digitally signed message part.
Bug#501574: warsow: crashes at startup (warsow_bin: shader/slang/slang_emit.c:978 ...)
Here's a new warsow script that could help, but it will disable GLSL regardless of what driver is being used. What could we use to tell if we're using the proprietary ATI or Nvidia drivers? On Fri, Oct 10, 2008 at 12:09 PM, 01 [EMAIL PROTECTED] wrote: Yup, starting the game with... warsow +seta gl_ext_GLSL 0 ...helped. I'm using Intel drivers (chipset: GMA 965). I'm using Lenny packages, I gave libgl1-mesa-dri in experimental a try, warsow did start (with gl_ext_GLSL set to 1) but I experienced much instability with any 3D app and Xorg crashed ;-) Thanks for the tips. ___ Pkg-games-devel mailing list [EMAIL PROTECTED] http://lists.alioth.debian.org/mailman/listinfo/pkg-games-devel -- Regards, Andres Mejia warsow Description: Binary data
Bug#501574: warsow: crashes at startup (warsow_bin: shader/slang/slang_emit.c:978 ...)
Hello Debian X Strike Force. There's a bug in warsow that according to the Warsow developers, is due to a buggy driver. I can reproduce this bug with a machine using a mesa driver, but on a machine with the proprietary nvidia drivers, I can't reproduce this bug. On Wednesday 08 October 2008 04:57:31 pm hangy wrote: Hi, warsow_bin: shader/slang/slang_emit.c:978: emit_move: Assertion `n-Children[0]-Store-Index = 0' failed. according to our coders, this assertion indicates a driver bug. Was the Mesa OpenGL driver updated recently? It might be a good idea to contact one of their maintainers/coders. Also, the Mesa driver probably does not give you the best OpenGL performance for your system. If there are any (possibly proprietary) drivers available for your system (ie. ATI or NVIDIA GPU), try these. -hangy -- Regards, Andres signature.asc Description: This is a digitally signed message part.
Bug#501574: warsow: crashes at startup (warsow_bin: shader/slang/slang_emit.c:978 ...)
Hello Debian X Strike Force. There's a bug in warsow that according to the Warsow developers, is due to a buggy driver. I can reproduce this bug with a machine using a mesa driver, but on a machine with the proprietary nvidia drivers, I can't reproduce this bug. On Wednesday 08 October 2008 04:57:31 pm hangy wrote: Hi, warsow_bin: shader/slang/slang_emit.c:978: emit_move: Assertion `n-Children[0]-Store-Index = 0' failed. according to our coders, this assertion indicates a driver bug. Was the Mesa OpenGL driver updated recently? It might be a good idea to contact one of their maintainers/coders. Also, the Mesa driver probably does not give you the best OpenGL performance for your system. If there are any (possibly proprietary) drivers available for your system (ie. ATI or NVIDIA GPU), try these. -hangy -- Regards, Andres signature.asc Description: This is a digitally signed message part.
Bug#471057: crystalspace: FTBFS with g++-4.3: Unrecognized option -Wno-long-double (patch)
Attached is a patch to fix this bug. We simply don't use -Wno-long-double. -- Regards, Andres --- crystalspace-1.2-20080206.old/debian/rules 2008-10-07 22:38:10.0 -0400 +++ crystalspace-1.2-20080206/debian/rules 2008-10-07 21:55:16.0 -0400 @@ -74,8 +74,12 @@ # this is adding #define CS_NO_QSQRT in CS/include/volatile.h # Don't support until this is dynamic lib # --enable-meta-info-embedding was by default before (enbed .csplugin info) + # Use cs_cv_prog_cxx_ignore_long_double_ok=no to disable use of + # -Wno-long-double. (Closes: #471057). perl -pi -e s:\[crystal\]:\[crystalspace\]: $(CURDIR)/CS/configure.ac - cd CS; ./bin/autogen.sh ; cs_cv_prog_cxx_local_include=no ./configure $(CONFDIR) $(CPUOPTIM) $(PYTHON) $(NEWRENDERER) $(CONFFLAG) + cd CS; ./bin/autogen.sh ; cs_cv_prog_cxx_local_include=no \ + cs_cv_prog_cxx_ignore_long_double_ok=no \ + ./configure $(CONFDIR) $(CPUOPTIM) $(PYTHON) $(NEWRENDERER) $(CONFFLAG) # Install as much as possible #perl -pi -e s/#TO_INSTALL/TO_INSTALL/ $(CURDIR)/CS/cache.mak signature.asc Description: This is a digitally signed message part.
Bug#492920: crystalspace - lintian error fixes (patch)
Here's a patch that will address the errors from lintian, which would justify
the severity of this bug.
The rest of your changes would be severity important I think. Have you tried
contacting the current maintainer in getting all your changes uploaded to
Debian?
--
Regards,
Andres
W: crystalspace source: debian-rules-sets-DH_COMPAT line 15
N:
N: As of debhelper version 4, the DH_COMPAT environment variable is only
N: to be used for temporarily overriding debian/compat. Any line in
N: debian/rules that sets it globally should be deleted and a separate
N: debian/compat file created if needed.
N:
N: Refer to the debhelper(7) manual page for details.
N:
N: Severity: normal; Certainty: certain
N:
W: crystalspace source: substvar-source-version-is-deprecated crystalspace-dev
N:
N: The package uses the now deprecated ${Source-Version} substvar, which
N: has misleading semantics. Please switch to ${binary:Version} or
N: ${source:Version} as appropriate. Support for ${Source-Version} may be
N: removed from dpkg-dev in the future.
N:
N: Severity: normal; Certainty: certain
N:
W: crystalspace source: out-of-date-standards-version 3.7.2.2 (current is 3.8.0)
N:
N: The source package refers to a Standards-Version older than the one
N: that was current at the time the package was created (according to the
N: timestamp of the latest debian/changelog entry). Please consider
N: updating the package to current Policy and setting this control field
N: appropriately.
N:
N: If the package is already compliant with the current standards, you
N: don't have to re-upload the package just to adjust the
N: Standards-Version control field. However, please remember to update
N: this field next time you upload the package.
N:
N: Severity: normal; Certainty: certain
N:
W: crystalspace source: build-depends-on-1-revision build-depends: nasm (= 0.98.08-1)
N:
N: The package declares a build dependency on a version of a package with
N: a -1 Debian revision such as libfoo (= 1.2-1). Such a dependency
N: will not be satisfied by a backport of libfoo 1.2-1 and therefore
N: makes backporting unnecessarily difficult. Normally, the -1 version is
N: unneeded and a dependency such as libfoo (= 1.2) would be
N: sufficient. If there was an earlier -0.X version of libfoo that would
N: not satisfy the dependency, use libfoo (= 1.2-1~) instead.
N:
N: Severity: normal; Certainty: possible
N:
W: crystalspace source: build-depends-on-1-revision build-depends: libogg-dev (= 1.0rc2-1)
E: crystalspace source: build-depends-on-obsolete-package build-depends: xlibmesa-gl-dev
N:
N: The package build-depends on a package that has been superseded. If
N: the superseded package is part of an ORed group, it should not be the
N: first package in the group.
N:
N: Severity: important; Certainty: possible
N:
E: crystalspace source: build-depends-on-obsolete-package build-depends: tetex-bin
E: crystalspace source: build-depends-on-obsolete-package build-depends: x-dev
W: crystalspace: extra-license-file usr/share/crystalspace-1.2/data/maps/castle/license.txt
N:
N: All license information should be collected in the debian/copyright
N: file. This usually makes it unnecessary for the package to install
N: this information in other places as well.
N:
N: Refer to Debian Policy Manual section 12.5 (Copyright information) for
N: details.
N:
N: Severity: normal; Certainty: possible
N:
E: crystalspace: package-section-games-but-contains-no-game
N:
N: This package is marked as part of the section games, but doesn't
N: contain files in /usr/games. Binaries of games must be installed in
N: /usr/games.
N:
N: Refer to Debian Policy Manual section 11.11 (Games) for details.
N:
N: Severity: important; Certainty: certain
N:
W: crystalspace: script-not-executable ./usr/share/crystalspace-1.2/bindings/perl5/perlsimp.pl
N:
N: This file starts with the #! sequence that marks interpreted scripts,
N: but it is not executable.
N:
N: Severity: normal; Certainty: certain
N:
W: crystalspace: script-not-executable ./usr/share/crystalspace-1.2/build/autoconf/config.guess
W: crystalspace: script-not-executable ./usr/share/crystalspace-1.2/build/autoconf/config.sub
W: crystalspace: script-not-executable ./usr/share/crystalspace-1.2/build/autoconf/install-sh
W: crystalspace: script-not-executable ./usr/share/crystalspace-1.2/build/jamtemplate/autogen.template
W: crystalspace: maintainer-script-empty prerm
N:
N: The maintainer script doesn't seem to contain any code other than
N: comments and boilerplate (set -e, exit statements, and the case
N: statement to parse options). While this is harmless in most cases, it
N: is probably not what you wanted, may mean the package will leave
N: unnecessary files behind until purged, and may even lead to problems
N: in rare situations where dpkg would fail if no maintainer script was
N: present.
N:
N: If the
Bug#488686: Fwd: Bug#478789: Vegastrike 0.5.0 Released
Forwarding this message for archival purposes as it pertains to this bug as well. -- Forwarded Message -- Subject: Bug#478789: Vegastrike 0.5.0 Released Date: Saturday 19 July 2008 From: Vincent Fourmond [EMAIL PROTECTED] To: Leo 'costela' Antunes [EMAIL PROTECTED], [EMAIL PROTECTED] Hello ! Leo 'costela' Antunes wrote: Checking the work on[0], I haven't found any conclusion to the 0.5.0 saga. Do you guys still need a hand with anything? I'm not sure how much time I could devote to helping, but if there's still some source splitting to be done, perhaps I could help. What is the final verdict on the source and binary packages? And the removal of the upstream copy of libboost? The following is my opinion only. In its current state, vegastrike will not make it into lenny; it has a RC bug which needs an upgrade to the newer version. The opinion of the ftpmasters on the current vegastrike-data is that it is insanely huge - we don't want mirrors to waste 1 GB of disk space for a package with a popcon score of 200. The only way now to get it into lenny (freeze is starting pretty soon now) is to manage somehow to produce a lighter version of the vegastrike-data package - a source tarball of around 200MB to 250MB would be acceptable. If you feel like doing that, please do it very quickly and have a look at the thread there: http://vegastrike.sourceforge.net/forums/viewtopic.php?t=11276 You might want to downscale some of the textures in order to make them smaller. In this case, you might find the gimp-dds package of use. If you manage to produce a lighter version of vegastrike-data for the 0.5 version that works with vegastrike 0.5 in SVN, please contact me as soon as possible, I'll upload it. Cheers, Vincent, who's unfortunately way too busy to take care of that himself. -- Vincent Fourmond, Debian Developer http://vince-debian.blogspot.com/ The moon was high now, in a sky as black as a cup of coffee that wasn't very black at all. -- Terry Pratchet, Men at arms Vincent, listening to Mercy Street (Peter Gabriel) ___ Pkg-games-devel mailing list [EMAIL PROTECTED] http://lists.alioth.debian.org/mailman/listinfo/pkg-games-devel --- -- Regards, Andres signature.asc Description: This is a digitally signed message part.
Bug#492802: vegastrike-data needs update to 0.5.0 for vegastrike to work
Package: vegastrike-data Severity: serious vegastrike-data needs to be updated to 0.5.0 in order for vegastrike to function correctly, otherwise vegastrike is unusable. -- Regards, Andres signature.asc Description: This is a digitally signed message part.
Bug#490119: vegastrike: starts with Error: no rooms found
On Wednesday 09 July 2008 07:11:59 pm Thomas Knott wrote: Package: vegastrike Version: 0.5~svn12126-2 Severity: grave Justification: renders package unusable NOTE: The following description is copied from https://qa.mandriva.com/show_bug.cgi?id=30533 My experience is exactly the same tho the output is different. The error messages are the same but of course I included the original output my install gave me. (esp since the mandriva-one is about 0.4.3) When Vegastrike starts, it opens with a simple graphic of a ship and a message error: no rooms found. The usual graphics for the base interiors are missing; there's just a single screen providing access to Ships, Upgrades, Cargo, etc. Dynamic aspects like Missions and News are blank. The ship can be launched and can navigate to other locations, but they are also missing the usual interior graphics. No other ships are generated for ship-to-ship interaction. You're bascially alone in the universe. Starting from the command line, I get the following: SyntaxError: invalid syntax Compiling python module modules/dj.py File /home/myusername/.vegastrike-0.4.x/modules/dj.py, line 1 import dj_lib ^ This is repeated a lot of times. Then: SyntaxError: invalid syntax pox -95124024.543917 412089916.256812 -110779667.398050 Traceback (most recent call last): File string, line 2, in module File /usr/share/games/vegastrike/modules/privateer.py, line 2, in module from random_encounters import random_encounters File /usr/share/games/vegastrike/modules/random_encounters.py, line 9, in module import news File /usr/share/games/vegastrike/modules/news.py, line 7, in module dnewsman_ = dynamic_news.NewsManager() File /usr/share/games/vegastrike/modules/dynamic_news.py, line 261, in __init__ self.data = DynamicNewsData() File /usr/share/games/vegastrike/modules/dynamic_news.py, line 120, in __init__ import dynamic_news_content File /usr/share/games/vegastrike/modules/dynamic_news_content.py, line 53 SyntaxError: Non-ASCII character '\xc3' in file /usr/share/games/vegastrike/modules/dynamic_news_content.py on line 53, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details Then some more of the first ones. And finally this: placing ships... ... ... Traceback (most recent call last): File oceandayklkk.py, line 3, in module File /usr/share/games/vegastrike/bases/ocean_lib.py, line 2, in module import dynamic_mission File /usr/share/games/vegastrike/modules/dynamic_mission.py, line 7, in module import dynamic_universe File /usr/share/games/vegastrike/modules/dynamic_universe.py, line 7, in module dnewsman_ = dynamic_news.NewsManager() File /usr/share/games/vegastrike/modules/dynamic_news.py, line 261, in __init__ self.data = DynamicNewsData() File /usr/share/games/vegastrike/modules/dynamic_news.py, line 120, in __init__ import dynamic_news_content File /usr/share/games/vegastrike/modules/dynamic_news_content.py, line 53 SyntaxError: Non-ASCII character '\xc3' in file /usr/share/games/vegastrike/modules/dynamic_news_content.py on line 53, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details dot 0.993099dot 0.993099ERROR: there are no rooms in basefile oceanday.py ... Asking to undock Writing Save Game Autosave-explore_universe_difficultyHi helper play 0 I can reproduce it on two computers, and I tried removing ~/.vegastrike-0.4.x but it didn't help. Could this be because vegastrike is 0.5svn and vegasrike-data is 0.4.3? Greetings, Thomas Try issuing the command 'vegastrike explore_universe.mission'. You can actually replace 'explore_universe.mission' with any mission file in the directory '/usr/share/games/vegastrike/mission/'. This is fixed in SVN packaging of 0.5. -- Regards, Andres signature.asc Description: This is a digitally signed message part.
Bug#485899: ogre-doc: API and Manual under non-free CC-BY-SA-2.5 license
Package: ogre-doc Version: 1.4.6.dfsg1-1 Severity: serious Justification: Policy 2.2.1 The API and Manual are under the non-DFSG CC-BY-SA-2.5 license. These files cannot be distributed through main. Convincing upstream to use the CC-BY-SA-3.0 license would be the best way to resolve this, and would allow the API and manual to be distributed through main, otherwise, the API and manual will have to be distributed in non-free. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- no debconf information signature.asc Description: This is a digitally signed message part.
Bug#482649: fix for 482649
On Saturday 24 May 2008 08:17:14 peter green wrote: tags 482649 +patch thanks This is a g++-4.3 issue add #include limits.h to (I put it just under the inclusion of ogre.h but I doubt the precise location is too important) to fix it. Thanks. I figured it was a problem related to the new gcc. I'll upload the fix after ogre-1.4.8.dfsg1 gets accepted as that would fix another RC bug for funguloids. -- Regards, Andres signature.asc Description: This is a digitally signed message part.
Bug#481861: debpool: No longer useful with packages using 1.8 changes format
Package: debpool
Severity: grave
Tags: patch
X-Debbugs-CC: [EMAIL PROTECTED]
With changes files now being produced in format version 1.8 in unstable,
debpool has become useless as all packages being uploaded will stay in
incoming and have debpool produce a log message similar to this.
2008-05-18 21:59:29 [GENERAL/INFO] Processing
changefile 'ogre_1.4.8.dfsg1-1_i386.changes'
2008-05-18 21:59:29 [PARSE/ERROR] Unrecognized Format version '1.8'
2008-05-18 21:59:29 [GENERAL/ERROR] Failure parsing changes
file 'ogre_1.4.8.dfsg1-1_i386.changes': Unrecognized Format version
I've attached a patch to fix this, and already uploaded to my branch in git.
--
Regards,
Andres
--- a/share/DebPool/Packages.pm
+++ b/share/DebPool/Packages.pm
@@ -305,14 +305,14 @@ sub Parse_Changes {
}
# Now that we should have it, check to make sure we have a Format
-# header, and that it's format 1.7 (the only thing we grok).
+# header, and that it's format 1.7 or 1.8.
if (!defined($result{'Format'})) {
Log_Message(No Format header found in changes file '$file',
LOG_PARSE, LOG_ERROR);
$Error = 'No Format header found';
return undef;
-} elsif ('1.7' ne $result{'Format'}) {
+} elsif (('1.7' ne $result{'Format'}) and ('1.8' ne $result{'Format'})) {
Log_Message(Unrecognized Format version '$result{'Format'}',
LOG_PARSE, LOG_ERROR);
$Error = 'Unrecognized Format version';
signature.asc
Description: This is a digitally signed message part.
Bug#479283: funguloids: crashes with ogre-1.4.6
Package: funguloids Severity: serious funguloids crashes with ogre-1.4.6. I've attached the error log. funguloids however works without a problem (after applying patch for bug #478105) with version 1.4.7 of the ogre libraries. -- Regards, Andres Creating resource group General Creating resource group Internal Creating resource group Autodetect SceneManagerFactory for type 'DefaultSceneManager' registered. Registering ResourceManager for type Material Registering ResourceManager for type Mesh Registering ResourceManager for type Skeleton MovableObjectFactory for type 'ParticleSystem' registered. OverlayElementFactory for type Panel registered. OverlayElementFactory for type BorderPanel registered. OverlayElementFactory for type TextArea registered. Registering ResourceManager for type Font ArchiveFactory for archive type FileSystem registered. ArchiveFactory for archive type Zip registered. FreeImage version: 3.10.0 This program uses FreeImage, a free, open source image library supporting all common bitmap formats. See http://freeimage.sourceforge.net for details Supported formats: bmp,ico,jpg,jif,jpeg,jpe,jng,koa,iff,lbm,mng,pbm,pbm,pcd,pcx,pgm,pgm,png,ppm,ppm,ras,tga,targa,tif,tiff,wap,wbmp,wbm,psd,cut,xbm,xpm,gif,hdr,g3,sgi,exr,j2k,j2c,jp2 DDS codec registering Registering ResourceManager for type HighLevelGpuProgram Registering ResourceManager for type Compositor MovableObjectFactory for type 'Entity' registered. MovableObjectFactory for type 'Light' registered. MovableObjectFactory for type 'BillboardSet' registered. MovableObjectFactory for type 'ManualObject' registered. MovableObjectFactory for type 'BillboardChain' registered. MovableObjectFactory for type 'RibbonTrail' registered. Loading library /usr/lib/OGRE/RenderSystem_GL.so Installing plugin: GL RenderSystem OpenGL Rendering Subsystem created. Plugin successfully installed Loading library /usr/lib/OGRE/Plugin_ParticleFX.so Installing plugin: ParticleFX Particle Emitter Type 'Point' registered Particle Emitter Type 'Box' registered Particle Emitter Type 'Ellipsoid' registered Particle Emitter Type 'Cylinder' registered Particle Emitter Type 'Ring' registered Particle Emitter Type 'HollowEllipsoid' registered Particle Affector Type 'LinearForce' registered Particle Affector Type 'ColourFader' registered Particle Affector Type 'ColourFader2' registered Particle Affector Type 'ColourImage' registered Particle Affector Type 'ColourInterpolator' registered Particle Affector Type 'Scaler' registered Particle Affector Type 'Rotator' registered Particle Affector Type 'DirectionRandomiser' registered Particle Affector Type 'DeflectorPlane' registered Plugin successfully installed Loading library /usr/lib/OGRE/Plugin_BSPSceneManager.so Installing plugin: BSP Scene Manager Plugin successfully installed Loading library /usr/lib/OGRE/Plugin_OctreeSceneManager.so Installing plugin: Octree Terrain Scene Manager Plugin successfully installed Loading library /usr/lib/OGRE/Plugin_EXRCodec.so EXRCodec initialised Loading library /usr/lib/OGRE/Plugin_CgProgramManager.so Installing plugin: Cg Program Manager Plugin successfully installed *-*-* OGRE Initialising *-*-* Version 1.4.6 (Eihort) ArchiveFactory for archive type MPK registered. Creating resource group Bootstrap Added resource location '/usr/share/games/funguloids/bootstrap.mpk' of type 'MPK' to resource group 'Bootstrap' Added resource location '/usr/share/games/funguloids/music' of type 'FileSystem' to resource group 'General' Added resource location '/usr/share/games/funguloids/icon' of type 'FileSystem' to resource group 'General' Added resource location '/usr/share/games/funguloids/funguloids.mpk' of type 'MPK' to resource group 'General' CPU Identifier Features - * CPU ID: GenuineIntel: Intel(R) Pentium(R) D CPU 3.00GHz * SSE: yes * SSE2: yes * SSE3: yes * MMX: yes * MMXEXT: yes *3DNOW: no * 3DNOWEXT: no * CMOV: yes * TSC: yes * FPU: yes * PRO: yes * HT: yes - ** *** Starting GLX Subsystem *** ** GLRenderSystem::createRenderWindow Those Funny Funguloids!, 800x600 windowed miscParams: FSAA=0 title=Those Funny Funguloids! GLXWindow::create Parsing miscParams GLXWindow::create -- Best visual is 36 GL_VERSION = 2.1.2 NVIDIA 169.12 GL_VENDOR = NVIDIA Corporation GL_RENDERER = GeForce 7900 GTX/PCI/SSE2 GL_EXTENSIONS = GL_ARB_color_buffer_float GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_half_float_pixel GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shadow GL_ARB_shader_objects GL_ARB_shading_language_100 GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine
Bug#478105: funguloids: crashes on startup
On Saturday 03 May 2008 3:55:07 am you wrote: Well I tried what you said but it still crashes, although I get different output now. I've attached two logs, one with the new openal-soft library that we're working to replace the old openal library with, and another using the openal si library (the old openal library). Ok, that seems even worse. I think the original way is still better. I'm still guessing that the problem is there in the MPK loading for Ogre.. Don't know what it could be, though. I didn't find any Archive related changes in their changelogs recently.. I'm working on it but I'm about to go to bed for now. I found you can extract the contents of the archive with no problem. I suppose if there were some way to read the file after it's extracted, then there shouldn't be a problem. Ogre uses the various zzip_* functions in the ZipDataStream class to read, seek, tell, etc. from zip files. If mpak could provide the same functionality, maybe this issue could be resolved. -- Regards, Andres -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#478105: funguloids: crashes on startup
On Saturday 03 May 2008 2:03:31 pm Mika Halttunen wrote: :( Would you be willing to place those files in a zip file instead? I've been trying to resolve this making changes to the funguloids code, with no results. -- Regards, Andres -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#478105: funguloids: crashes on startup (patch)
Hello,
I found the problem. Seems the size and chunks used when calling fread() were
in reverse (it was probably reversed in the previous two revisions of Ogre).
It was just a one line fix. I've attached a patch.
--
Regards,
Andres
Correction for MPakDataStream::read(). This reflects what's done in the
FileHandleDataStream::read() method in OgreDataStream.cpp in the Ogre library.
=
--- src/mpakogre.cpp.bak 2008-05-04 01:05:10.0 -0400
+++ src/mpakogre.cpp 2008-05-04 00:56:05.0 -0400
@@ -219,7 +219,7 @@
}
size_t MPakDataStream::read(void *buf, size_t count) {
- return fread(buf, count, 1, mFileHandle);
+ return fread(buf, 1, count, mFileHandle);
}
void MPakDataStream::skip(long count) {
Bug#475499: mediatomb-daemon: Does not start: ERROR: Group -P not found!
On Friday 11 April 2008 3:01:52 am Christopher Pharo Gl??serud wrote: Package: mediatomb-daemon Version: 0.11.0-2 Severity: grave Justification: renders package unusable /etc/init.d/mediatomb has an error on line 76: DAEMON_ARGS=-c /etc/mediatomb/config.xml -d -u $USER -g $GROUP -P $PIDFILE -l $LOGFILE $INTERFACE_ARG $OPTIONS $GROUP is never declared or assigned in the script, which causes it to fail with group -P not found. What do you have in /etc/default/mediatomb? -- Regards, Andres -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475499: mediatomb-daemon: Does not start: ERROR: Group -P not found!
severity 475499 minor retitle 475499 mediatomb-daemon: Check if $GROUP is specified thanks On Friday 11 April 2008 10:52:10 am Christopher Pharo Glæserud wrote: Andres Mejia, Package: mediatomb-daemon Version: 0.11.0-2 Severity: grave Justification: renders package unusable /etc/init.d/mediatomb has an error on line 76: DAEMON_ARGS=-c /etc/mediatomb/config.xml -d -u $USER -g $GROUP -P $PIDFILE -l $LOGFILE $INTERFACE_ARG $OPTIONS $GROUP is never declared or assigned in the script, which causes it to fail with group -P not found. What do you have in /etc/default/mediatomb? Not what I am supposed to, it seems. Normally, I would expect a .dpkg-dist file, but this is not there. Neither is the original mediatomb file changed. Upon reinstalling the package, the correct version is installed (with USER and GROUP). I would probably attribute this to a local error and not the package, since it works fine on reinstall. Which means that this bug can be dismissed. OK. Actually what I'm going to do is have a check to see if $GROUP is specified and if not, specify it with what's already in $USER. I'll set the severity of this bug to minor and retitle it. -- Regards, Andres
Bug#467386: funguloids: 2
On Sunday 24 February 2008 9:45:50 pm Jerry Quinn wrote: Package: funguloids Version: 1.06-5 Severity: grave Justification: causes non-serious data loss I installed and tried to run this game, which immediately gave me a blank screen, and the machine was unresponsive to keystrokes. I had to reboot the box, causing potential data loss in other programs I had open. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages funguloids depends on: ii libalut01.1.0-1 OpenAL Utility Toolkit ii libc6 2.7-6GNU C Library: Shared libraries ii libgcc1 1:4.3-20080202-1 GCC support library ii liblua5.1-0 5.1.3-1 Simple, extensible, embeddable pro ii libmad0 0.15.1b-2.1 MPEG audio decoder library ii libogg0 1.1.3-3 Ogg Bitstream Library ii libogre14 1.4.3-1+b1 Object-oriented Graphics Rendering ii libois1 0.99+1.0rc1-1+b1 Object Oriented Input System libra ii libopenal0a 1:0.0.8-7OpenAL is a portable library for 3 ii libstdc++6 4.3-20080202-1 The GNU Standard C++ Library v3 ii libvorbis0a 1.2.0.dfsg-3 The Vorbis General Audio Compressi ii libvorbisenc2 1.2.0.dfsg-3 The Vorbis General Audio Compressi ii libvorbisfile3 1.2.0.dfsg-3 The Vorbis General Audio Compressi ii ogre-plugins-cgprogramm 1.4.5-1 Ogre plugin: CgProgramManager funguloids recommends no packages. -- no debconf information ___ Pkg-games-devel mailing list [EMAIL PROTECTED] http://lists.alioth.debian.org/mailman/listinfo/pkg-games-devel What I'm seeing wrong here is that ogre-plugins-cgprogrammanager 1.4.5 is installed along with libogre14 1.4.3. I didn't notice this until now. Ogre versions 1.4.x do have ABI breakage in between versions. This will be fixed with the new ogre libraries uploaded to the archive (version 1.4.6.dfsg1). The libraries are built with a release soname scheme and the library packages are named accordingly (libogremain-1.4.6). A binNMU should then be done for funguloids, causing funguloids (and ogre-plugins-cgprogrammanager) to depend on the correct version of ogre. -- Regards, Andres -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465177: Bug #465177: mediatomb: FTBFS: configure: error: unable to configure inotify support
On Thursday 14 February 2008 5:26:14 am Sergey Jin' Bostandzhyan wrote: On Tue, Feb 12, 2008 at 10:40:20PM -0500, Andres Mejia wrote: Possibly an oldish one, but it shouldn't matter. Whether the kernel supports inotify should be checked at runtime, not build time. Well, this makes sense. I could fix this for the build time. Does mediatomb already check for inotify during runtime? As far as fixing this for build time, I'm guessing the inotify-tools has this check only to serve the purpose of seeing if the linux inotify headers work, and if not, just drop back to it's own implementation. For mediatomb, we should just be worried about the presence and usability of sys/inotify.h. If it turns out there's a problem with the inotify headers, then it should be reported against the linux packages. We do the same fallback thing and use the same header as inotify tools, we do have a runtime check, but I have to see what exactly it is doing (i.e., possible that it will complain at startup and exit) So indeed, we should add an option which would allow compiling with inotify support even if inotify is not present on the build system and do a smarter runtime check. I'll see that we get this fixed for the upcoming release which should not take long anymore. Thanks for the hints. Kind regards, Jin I see that this has been worked on in SVN. I'll test the new changes with the current package in Debian. -- Regards, Andres -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465177: Bug #465177: mediatomb: FTBFS: configure: error: unable to configure inotify support
Hello, I included the changes for the inotify runtime support found in the upstream SVN. The packaging can now be found under: Vcs-git: git://git.debian.org/git/collab-maint/mediatomb.git Vcs-Browser: http://git.debian.org/?p=collab-maint/mediatomb.git Sven, would you mind reveiwing the package direct from the git repository? I could still upload a package to mentors.d.n if you want me to. I switched to git since I thought it would be a good idea to allow a distributed control system for mediatomb. The SVN repository is still up. If nobody has any objections, I'll remove the SVN repository. -- Regards, Andres -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465177: Bug #465177: mediatomb: FTBFS: configure: error: unable to configure inotify support
Here's the specific patch as well.
--
Regards,
Andres
Patch that allows for inotify support to be checked at runtime.
===
--- mediatomb-0.10.0/src/config_manager.cc.bak 2008-02-19 13:44:03.0 -0500
+++ mediatomb-0.10.0/src/config_manager.cc 2008-02-19 13:53:04.0 -0500
@@ -44,6 +44,10 @@
#include string_converter.h
#include metadata_handler.h
+#ifdef HAVE_INOTIFY
+#include mt_inotify.h
+#endif
+
#if defined(HAVE_LANGINFO_H) defined(HAVE_LOCALE_H)
#include langinfo.h
#include locale.h
@@ -839,19 +843,61 @@
_(from), _(to)));
SET_DICT_OPTION(CFG_IMPORT_MAPPINGS_MIMETYPE_TO_UPNP_CLASS_LIST);
+temp = getOption(_(/import/autoscan/attribute::use-inotify), _(auto));
+if ((temp != auto) !validateYesNo(temp))
+throw _Exception(_(Error in config file: incorrect parameter for
+ \autoscan use-inotify=\ attribute));
+
el = getElement(_(/import/autoscan));
-if (el == nil)
-{
-getOption(_(/import/autoscan), _());
-}
+
NEW_AUTOSCANLIST_OPTION(createAutoscanListFromNodeset(el, TimedScanMode));
SET_AUTOSCANLIST_OPTION(CFG_IMPORT_AUTOSCAN_TIMED_LIST);
+bool inotify_supported = false;
+
#ifdef HAVE_INOTIFY
-NEW_AUTOSCANLIST_OPTION(createAutoscanListFromNodeset(el, InotifyScanMode));
-SET_AUTOSCANLIST_OPTION(CFG_IMPORT_AUTOSCAN_INOTIFY_LIST);
+inotify_supported = Inotify::supported();
#endif
-
+
+if (temp == _(YES))
+{
+#ifdef HAVE_INOTIFY
+if (!inotify_supported)
+throw _Exception(_(You specified
+ \yes\ in \autoscan use-inotify=\
+however your system does not have
+ inotify support));
+#else
+throw _Exception(_(You specified \yes\ in \autoscan use-inotify=\
+however this version of MediaTomb was compiled
+ without inotify support));
+#endif
+}
+
+#ifdef HAVE_INOTIFY
+if (temp == _(auto) || (temp == _(YES)))
+{
+if (inotify_supported)
+{
+NEW_AUTOSCANLIST_OPTION(createAutoscanListFromNodeset(el, InotifyScanMode));
+SET_AUTOSCANLIST_OPTION(CFG_IMPORT_AUTOSCAN_INOTIFY_LIST);
+
+NEW_BOOL_OPTION(true);
+SET_BOOL_OPTION(CFG_IMPORT_AUTOSCAN_USE_INOTIFY);
+}
+else
+{
+NEW_BOOL_OPTION(false);
+SET_BOOL_OPTION(CFG_IMPORT_AUTOSCAN_USE_INOTIFY);
+}
+}
+else
+{
+NEW_BOOL_OPTION(false);
+SET_BOOL_OPTION(CFG_IMPORT_AUTOSCAN_USE_INOTIFY);
+}
+#endif
+
el = getElement(_(/server/custom-http-headers));
NEW_STRARR_OPTION(createArrayFromNodeset(el, _(add), _(header)));
SET_STRARR_OPTION(CFG_SERVER_CUSTOM_HTTP_HEADERS);
--- mediatomb-0.10.0/src/mt_inotify.cc.bak 2008-02-19 13:41:48.0 -0500
+++ mediatomb-0.10.0/src/mt_inotify.cc 2008-02-19 13:54:02.0 -0500
@@ -46,6 +46,7 @@
#include unistd.h
#include errno.h
#include assert.h
+#include tools.h
#include mt_inotify.h
@@ -73,10 +74,29 @@
close(inotify_fd);
}
+bool Inotify::supported()
+{
+int test_fd = inotify_init();
+if (test_fd 0)
+return false;
+else
+{
+close(test_fd);
+return true;
+}
+}
int Inotify::addWatch(String path, int events)
{
-return inotify_add_watch(inotify_fd, path.c_str(), events);
+int wd = inotify_add_watch(inotify_fd, path.c_str(), events);
+if (wd 0 errno != ENOENT)
+{
+if (errno == ENOSPC)
+throw _Exception(_(The user limit on the total number of inotify watches was reached or the kernel failed to allocate a needed resource.));
+else
+throw _Exception(mt_strerror(errno));
+}
+return wd;
}
void Inotify::removeWatch(int wd)
--- mediatomb-0.10.0/src/content_manager.cc.bak 2008-02-19 13:56:13.0 -0500
+++ mediatomb-0.10.0/src/content_manager.cc 2008-02-19 14:15:55.0 -0500
@@ -87,6 +87,7 @@
ContentManager::ContentManager() : TimerSubscriberSingletonContentManager()
{
+int i;
cond = RefCond(new Cond(mutex));
ignore_unknown_extensions = 0;
@@ -143,24 +144,31 @@
autoscan_timed = storage-getAutoscanList(TimedScanMode);
#ifdef HAVE_INOTIFY
-RefAutoscanList config_inotify_list =
-cm-getAutoscanListOption(CFG_IMPORT_AUTOSCAN_INOTIFY_LIST);
-
-for (int i = 0; i config_inotify_list-size(); i++)
+if (cm-getBoolOption(CFG_IMPORT_AUTOSCAN_USE_INOTIFY))
{
-RefAutoscanDirectory dir = config_inotify_list-get(i);
-if (dir != nil)
+RefAutoscanList config_inotify_list =
+cm-getAutoscanListOption(CFG_IMPORT_AUTOSCAN_INOTIFY_LIST);
+
+for (i = 0; i config_inotify_list-size(); i++)
{
-String
Bug#465971: nvidia-cg-toolkit: does not install after last sid update
I'm unable to reproduce this bug. I've tested this on an i386 machine, yet I ensured I could get the x86_64 package manually by using the same link from the update-nvidia-cg-toolkit script. On Friday 15 February 2008 12:24:15 pm Krishnamurti L. L. V. Nunes wrote: Package: nvidia-cg-toolkit Version: 2.0.0010 Severity: important I have nvidia-cg-toolkit installed as a dependence for the package ogre-plugins-cgprogrammanager, which is dependence for the game funguloids. The atempt to update funguloids gives me that: nvidia-cg-toolkit E: Sub-process /usr/bin/dpkg returned an error code (1) Because it fails to download Cg-2.0_Dec2007_x86_64.tar.gz from http://developer.download.nvidia.com/cg/Cg_2.0/2.0.0010/ Pressing Ctrl+C to cancel download causes configure to fail: Traceback (most recent call last): File /usr/bin/update-nvidia-cg-toolkit, line 227, in ? toolkit_file = cg_wget(toolkit_target, CG_FILE) File /usr/bin/update-nvidia-cg-toolkit, line 194, in cg_wget dst.write(src.read()) File /usr/lib/python2.4/socket.py, line 277, in read data = self._sock.recv(recv_size) File /usr/lib/python2.4/httplib.py, line 480, in read dpkg: erro processando nvidia-cg-toolkit (--configure): subprocesso post-installation script morto por sinal (Interrupção) Patch is probably pointing the download of Cg-2.0_Dec2007_x86_64.tar.gz to the correct URL at the postinst scripts. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.21-2-amd64 (SMP w/1 CPU core) Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages nvidia-cg-toolkit depends on: ii debconf [debconf-2.0] 1.5.19 Debian configuration management sy ii python2.4.4-6An interactive high-level object-o nvidia-cg-toolkit recommends no packages. -- debconf information: * nvidia-cg-toolkit/http_proxy: * nvidia-cg-toolkit/delete: false * nvidia-cg-toolkit/httpget: true * nvidia-cg-toolkit/local: nvidia-cg-toolkit/not_exist: -- Regards, Andres
Bug#465177: Bug #465177: mediatomb: FTBFS: configure: error: unable to configure inotify support
Hi, There's this issue where mediatomb fails to build on the powerpc. The bug is http://bugs.debian.org/465177. Does anyone here know if inotify is supported on the powerpc? Also, does anyone know what kernel version the powerpc buildd machines are using? Please respond to me and [EMAIL PROTECTED] Thanks. -- Regards, Andres -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465177: Bug #465177: mediatomb: FTBFS: configure: error: unable to configure inotify support
On Tuesday 12 February 2008 7:09:49 pm Michel Dänzer wrote: On Tue, 2008-02-12 at 19:02 -0500, Andres Mejia wrote: There's this issue where mediatomb fails to build on the powerpc. The bug is http://bugs.debian.org/465177. Does anyone here know if inotify is supported on the powerpc? It is. Also, does anyone know what kernel version the powerpc buildd machines are using? Possibly an oldish one, but it shouldn't matter. Whether the kernel supports inotify should be checked at runtime, not build time. Well, this makes sense. I could fix this for the build time. Does mediatomb already check for inotify during runtime? As far as fixing this for build time, I'm guessing the inotify-tools has this check only to serve the purpose of seeing if the linux inotify headers work, and if not, just drop back to it's own implementation. For mediatomb, we should just be worried about the presence and usability of sys/inotify.h. If it turns out there's a problem with the inotify headers, then it should be reported against the linux packages. -- Regards, Andres
Bug#465177: FTBFS: configure: error: unable to configure inotify support
On Monday 11 February 2008 6:14:31 am Sergey 'Jin' Bostandzhyan wrote: Hi, I'm one of the authors of MediaTomb, here is some info on this: do not pass the --enable-inotify parameter to the configure script; presence of inotify will be detected automatically, if not available it will be disabled on the fly. However, when the --enable-inotify parameter is passed by the user, configure will abort with the error that you are seeing if inotify checks fail. This is done on purpose so that no package on a different architecture/kernel builds packages sucessfully with a different set of options enabled, else I'm sure there would be a different set of bugs sooner or later. The inotify option is not enabled for any non-linux kernel using machine. The parameters passed to the configure script can be manually overridden by a user, but they won't be for the buildd machines. What I still need to do is, to adapt the inotify check for cross compiling, right now it will always fail when cross compiled. Actually, no cross compiling is done. The powerpc buildd machine is a powerpc machine. The same goes for the other buildd machines. I hope that info helps. Kind regards, Jin -- Regards, Andres -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465177: FTBFS: configure: error: unable to configure inotify support
On Monday 11 February 2008 3:13:56 pm Sergey Jin' Bostandzhyan wrote: On Mon, Feb 11, 2008 at 01:41:03PM -0500, Andres Mejia wrote: do not pass the --enable-inotify parameter to the configure script; presence of inotify will be detected automatically, if not available it will be disabled on the fly. However, when the --enable-inotify parameter is passed by the user, configure will abort with the error that you are seeing if inotify checks fail. This is done on purpose so that no package on a different architecture/kernel builds packages sucessfully with a different set of options enabled, else I'm sure there would be a different set of bugs sooner or later. The inotify option is not enabled for any non-linux kernel using machine. The parameters passed to the configure script can be manually overridden by a user, but they won't be for the buildd machines. Well, if you are sure that the target machines *do have inotify support* the only thing that could help is the config.log output of the failed configure process. The best thing toward logs are located at http://buildd.debian.org/pkg.cgi?pkg=mediatomb . What I still need to do is, to adapt the inotify check for cross compiling, right now it will always fail when cross compiled. Actually, no cross compiling is done. The powerpc buildd machine is a powerpc machine. The same goes for the other buildd machines. Then it should work; we do check the headers and then we run some small test code which is calling inotify_init(). If the inotify_init() function returns -1 (error) we will compile without inotify support; however - if the --enable-inotify parameter was specified configure will abort because it can not do what the user wanted. So the question: is inotify really working on those systems? Kind regards, Jin I'm finding this behavior strange. Ubuntu accepted mediatomb into their archive, yet now the powerpc architecture goes past the inotify check just fine, but the i386 and amd64 architectures do not. Take a look at https://launchpad.net/ubuntu/+source/mediatomb/0.10.0.dfsg1-1/ I know for the case of the i386, I've been able to successfully build packages using pbuilder. Also, it looks like the Ubuntu buildd machines are giving a different error, for architectures that run the inotify check sucessfully. -- Regards, Andres -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465177: FTBFS: configure: error: unable to configure inotify support
On Monday 11 February 2008 7:59:40 pm Sergey Jin' Bostandzhyan wrote: Hi, On Mon, Feb 11, 2008 at 06:54:10PM -0500, Andres Mejia wrote: Well, if you are sure that the target machines *do have inotify support* the only thing that could help is the config.log output of the failed configure process. The best thing toward logs are located at http://buildd.debian.org/pkg.cgi?pkg=mediatomb . That's the stdout of configure, what I am looking for is the config.log file that is created by configure during the process, but this is not there because everything is purged after the build. Any idea if we can get it? Then it should work; we do check the headers and then we run some small test code which is calling inotify_init(). If the inotify_init() function returns -1 (error) we will compile without inotify support; however - if the --enable-inotify parameter was specified configure will abort because it can not do what the user wanted. So the question: is inotify really working on those systems? I'm finding this behavior strange. Ubuntu accepted mediatomb into their archive, yet now the powerpc architecture goes past the inotify check just fine, but the i386 and amd64 architectures do not. Take a look at https://launchpad.net/ubuntu/+source/mediatomb/0.10.0.dfsg1-1/ This is indeed very strange, it must be somehow related to the setup of the particular machine. What I see is that the default inotify header is not working, then we are retrying with our own and then it is failing. However, without seeing the config.log file I can not say anything... I know for the case of the i386, I've been able to successfully build packages using pbuilder. Yes, I know, Leo has also been using pbuilder to create our custom .deb packages and we did not have any problems with inotify. Is the exact environment that those machines are using available somewhere? Can we reproduce the problem somehow? Also, it looks like the Ubuntu buildd machines are giving a different error, for architectures that run the inotify check sucessfully. Indeed, it seems that the build runs through but there is something wrong with the package, can't say much there either - I have no experience with .deb packages. Kind regards, Jin I've investigated this some more and found that the inotify-tools package fails the test to see if sys/inotify.h actually works for the powerpc and ia64 architectures as well, yet the build continues for that package, unlike in mediatomb. Here's the difference between the two packages' configure.ac *mediatomb's configure.ac* dnl The check below was inspired by configure.ac from the inotify tools dnl package, see the Acknowledgements section in our README file for more dnl information. CXXFLAGS=$CXXFLAGS $INOTIFY_CXXFLAGS AC_MSG_CHECKING([whether sys/inotify.h works]) AC_RUN_IFELSE( AC_LANG_PROGRAM([[#include sys/inotify.h]], [[return (-1 == inotify_init());]] ), [ AC_MSG_RESULT([yes]); AC_DEFINE([SYS_INOTIFY_H_OK],[1],[sys/inotify.h exists and works correctly])], [ AC_MSG_RESULT([no, using own inotify headers]) AC_MSG_CHECKING([whether inotify-nosys.h works]) AC_RUN_IFELSE( AC_LANG_PROGRAM([[#include src/inotify-nosys.h]], [[return (-1 == inotify_init());]] ), [ AC_MSG_RESULT([yes]); INOTIFY_OK=yes ], [ AC_MSG_RESULT([no, disabling inotify support]) INOTIFY_OK=missing ]) ]) fi *inotify-tools configure.ac* # Checks for header files. AC_CHECK_HEADERS([sys/inotify.h mcheck.h]) AC_LANG(C) AC_MSG_CHECKING([whether sys/inotify.h actually works]) AC_RUN_IFELSE( AC_LANG_PROGRAM([[#include sys/inotify.h]], [[return (-1 == inotify_init());]] ), [AC_MSG_RESULT([yup]); AC_DEFINE([SYS_INOTIFY_H_EXISTS_AND_WORKS],[1], [sys/inotify.h exists and works correctly])], [AC_MSG_RESULT([nope, using own inotify headers])] ) Perhaps I'm wrong about what kernel each buildd machine is using. This would explain why this check fails on these architectures, but I can't find a straight answer. Sven, do you know the answer to this? The buildd machines use sbuild, which uses debootstrap for creating the chroot environment, so I'm sure at least the latest version of linux-libc-dev is installed. In case some buildd machines don't support inotify, the check to see if inotify works should be left out. -- Regards, Andres -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465177: Fwd: Re: Bug#465177: FTBFS: configure: error: unable to configure inotify support
Hello Sven, I don't know if you were tracking this, but there's this bug where certain architectures are failing to build mediatomb. Now as I understand it, the buildd machines builds packages in a chroot environment, with all packages found under unstable (the kernel, gcc, etc.). Isn't this correct? Here I'm forwarding a mail to you from one of the developers of Mediatomb. Can you help with this? -- Forwarded Message -- Subject: Re: Bug#465177: FTBFS: configure: error: unable to configure inotify support Date: Monday 11 February 2008 From: Sergey Jin' Bostandzhyan [EMAIL PROTECTED] To: Andres Mejia [EMAIL PROTECTED] Hi, On Mon, Feb 11, 2008 at 06:54:10PM -0500, Andres Mejia wrote: Well, if you are sure that the target machines *do have inotify support* the only thing that could help is the config.log output of the failed configure process. The best thing toward logs are located at http://buildd.debian.org/pkg.cgi?pkg=mediatomb . That's the stdout of configure, what I am looking for is the config.log file that is created by configure during the process, but this is not there because everything is purged after the build. Any idea if we can get it? Then it should work; we do check the headers and then we run some small test code which is calling inotify_init(). If the inotify_init() function returns -1 (error) we will compile without inotify support; however - if the --enable-inotify parameter was specified configure will abort because it can not do what the user wanted. So the question: is inotify really working on those systems? I'm finding this behavior strange. Ubuntu accepted mediatomb into their archive, yet now the powerpc architecture goes past the inotify check just fine, but the i386 and amd64 architectures do not. Take a look at https://launchpad.net/ubuntu/+source/mediatomb/0.10.0.dfsg1-1/ This is indeed very strange, it must be somehow related to the setup of the particular machine. What I see is that the default inotify header is not working, then we are retrying with our own and then it is failing. However, without seeing the config.log file I can not say anything... I know for the case of the i386, I've been able to successfully build packages using pbuilder. Yes, I know, Leo has also been using pbuilder to create our custom .deb packages and we did not have any problems with inotify. Is the exact environment that those machines are using available somewhere? Can we reproduce the problem somehow? Also, it looks like the Ubuntu buildd machines are giving a different error, for architectures that run the inotify check sucessfully. Indeed, it seems that the build runs through but there is something wrong with the package, can't say much there either - I have no experience with .deb packages. Kind regards, Jin --- -- Regards, Andres -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465177: FTBFS: configure: error: unable to configure inotify support
Source: mediatomb Version: 0.10.0.dfsg1-1 Severity: serious Mediatomb is failing to build on some architectures with these last entries. The architectures it's failing to build on is powerpc and ia64. checking sys/inotify.h usability... yes checking sys/inotify.h presence... yes checking for sys/inotify.h... yes checking whether sys/inotify.h works... no, using own inotify headers checking whether inotify-nosys.h works... no, disabling inotify support configure: error: unable to configure inotify support make: *** [configure-stamp] Error 1 dpkg-buildpackage: failure: debian/rules build gave error exit status 2 For the powerpc, powerpc packages have been created before (http://mediatomb.cc/pages/download#debian_ubuntu). The link to the powerpc packages is dead however. -- Regards, Andres -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464205: libcompress-bzip2-perl: Error compressing empty files
Package: libcompress-bzip2-perl Version: 2.09-1 Severity: serious When using the Compress::Bzip2 Perl module to compress an empty file, the resulting compressed file becomes corrupted. The bzip2 program however compresses them just fine. Although I know compressing an empty file won't save much space, there is a program I'm working on called debpool which sometimes would need to compress empty files anyway (like the Packages/Sources files for distributions that have no packages uploaded yet). I've attached a simple script that could be used to replicate the problem. I've also attached a script that compresses a file into gzip format using the Compress::Zlib module, just as a comparison, and to show it works with Compress::Zlib. -- Regards, Andres bzip2test Description: Perl program gziptest Description: Perl program
Bug#454365: funguloids: #454365 - segafults after pressing any key
I tried this on my lenny system and was unable to reproduce this issue. This is the card on my system. It's an onboard video card. 01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 65x/M650/740 PCI/AGP VGA Display Adapter -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459516: libupnp: Non-DFSG license for upnp/src/uuid/md5.c and upnp/src/inc/md5.h
Source: libupnp
Severity: serious
Tags: patch
upnp/src/uuid/md5.c and upnp/src/inc/md5.h contain this clause.
/* Copyright (C) 1991-2, RSA Data Security, Inc. Created 1991. All
rights reserved.
License to copy and use this software is granted provided that it
is identified as the quot;RSA Data Security, Inc. MD5 Message-Digest
Algorithmquot; in all material mentioning or referencing this software
or this function.
License is also granted to make and use derivative works provided
that such works are identified as quot;derived from the RSA Data
Security, Inc. MD5 Message-Digest Algorithmquot; in all material
mentioning or referencing the derived work.
RSA Data Security, Inc. makes no representations concerning either
the merchantability of this software or the suitability of this
software for any particular purpose. It is provided quot;as isquot;
without express or implied warranty of any kind.
These notices must be retained in any copies of any part of this
documentation and/or software.
*/
This is non-DFSG as there's no explicit permission to distribute
derivative works (fails DFSG#3).
I suggest using the implementation used for dpkg. Attached are the two
files from dpkg (lib/md5.c and lib/md5.h) and a patch that was
delivered to mediatomb.cc for the same issue (they use an internal
copy of libupnp, so it should be relatively easy to apply).
--
Regards,
Andres Mejia
/*
* This code implements the MD5 message-digest algorithm.
* The algorithm is due to Ron Rivest. This code was
* written by Colin Plumb in 1993, no copyright is claimed.
* This code is in the public domain; do with it what you wish.
*
* Equivalent code is available from RSA Data Security, Inc.
* This code has been tested against that, and is equivalent,
* except that you don't need to include two pages of legalese
* with every copy.
*
* To compute the message digest of a chunk of bytes, declare an
* MD5Context structure, pass it to MD5Init, call MD5Update as
* needed on buffers full of bytes, and then call MD5Final, which
* will fill a supplied 16-byte array with the digest.
*
* Changed so as no longer to depend on Colin Plumb's `usual.h' header
* definitions; now uses stuff from dpkg's config.h.
* - Ian Jackson [EMAIL PROTECTED].
* Still in the public domain.
*/
#include config.h
#include string.h /* for memcpy() */
#include sys/types.h /* for stupid systems */
#include netinet/in.h /* for ntohl() */
#include md5.h
#ifdef WORDS_BIGENDIAN
void
byteSwap(UWORD32 *buf, unsigned words)
{
md5byte *p = (md5byte *)buf;
do {
*buf++ = (UWORD32)((unsigned)p[3] 8 | p[2]) 16 |
((unsigned)p[1] 8 | p[0]);
p += 4;
} while (--words);
}
#else
#define byteSwap(buf,words)
#endif
/*
* Start MD5 accumulation. Set bit count to 0 and buffer to mysterious
* initialization constants.
*/
void
MD5Init(struct MD5Context *ctx)
{
ctx-buf[0] = 0x67452301;
ctx-buf[1] = 0xefcdab89;
ctx-buf[2] = 0x98badcfe;
ctx-buf[3] = 0x10325476;
ctx-bytes[0] = 0;
ctx-bytes[1] = 0;
}
/*
* Update context to reflect the concatenation of another buffer full
* of bytes.
*/
void
MD5Update(struct MD5Context *ctx, md5byte const *buf, unsigned len)
{
UWORD32 t;
/* Update byte count */
t = ctx-bytes[0];
if ((ctx-bytes[0] = t + len) t)
ctx-bytes[1]++; /* Carry from low to high */
t = 64 - (t 0x3f); /* Space available in ctx-in (at least 1) */
if (t len) {
memcpy((md5byte *)ctx-in + 64 - t, buf, len);
return;
}
/* First chunk is an odd size */
memcpy((md5byte *)ctx-in + 64 - t, buf, t);
byteSwap(ctx-in, 16);
MD5Transform(ctx-buf, ctx-in);
buf += t;
len -= t;
/* Process data in 64-byte chunks */
while (len = 64) {
memcpy(ctx-in, buf, 64);
byteSwap(ctx-in, 16);
MD5Transform(ctx-buf, ctx-in);
buf += 64;
len -= 64;
}
/* Handle any remaining bytes of data. */
memcpy(ctx-in, buf, len);
}
/*
* Final wrapup - pad to 64-byte boundary with the bit pattern
* 1 0* (64-bit count of bits processed, MSB-first)
*/
void
MD5Final(md5byte digest[16], struct MD5Context *ctx)
{
int count = ctx-bytes[0] 0x3f; /* Number of bytes in ctx-in */
md5byte *p = (md5byte *)ctx-in + count;
/* Set the first char of padding to 0x80. There is always room. */
*p++ = 0x80;
/* Bytes of padding needed to make 56 bytes (-8..55) */
count = 56 - 1 - count;
if (count 0) { /* Padding forces an extra block */
memset(p, 0, count + 8);
byteSwap(ctx-in, 16);
MD5Transform(ctx-buf, ctx-in);
p = (md5byte *)ctx-in;
count = 56;
}
memset(p, 0, count);
byteSwap(ctx-in, 14);
/* Append length in bits and transform */
ctx-in[14] = ctx-bytes[0] 3;
ctx-in[15] = ctx-bytes[1] 3 | ctx-bytes[0] 29;
MD5Transform(ctx-buf, ctx-in);
byteSwap(ctx-buf, 4);
memcpy(digest, ctx-buf, 16);
memset(ctx, 0, sizeof(ctx)); /* In case it's sensitive */
}
#ifndef ASM_MD5
/* The four core functions - F1 is optimized somewhat */
/* #define F1(x, y, z) (x y | ~x z
Bug#449475: vegastrike: src/cmd/collide/prapid.* cannot be distributed
I've sent a message upstream about this and received a reply. I'll let their reply do the talking. Link to the thread is at http://vegastrike.sourceforge.net/forums/viewtopic.php?t=10013 I was under the impression Crystal Space is GPL code. That remark you quoted says nothing about the license. It specifically says based on an implementation originally Copyright ... Unless this method of collision was patented, I believe it should be fine. However we are using a significantly older version, and it's possible that the code we included with Vega Strike was on legally shady ground at the time. Let's see what the Debian Legal team says about this issue. In the meantime, I would be interested in this older version from 1995 (If the legal bug submitter had actually posted a link to the original source code). It's possible he used that as a reference implementation, but wrote the GPL code himself. This Debian report really ought to have been directed to Crystal Space, but it's true that we include a specific revision of their collision engine that might specifically be at fault. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#446515: Could not reproduce
severity 446515 important tags 446515 unreproducible thanks I could not reproduce this bug. It's possible that you are experiencing this problem because of a limitation in your opengl hardware. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430842: Fixed in collab-maint
Fixed in collab-maint. The noip2.conf file will be stored in /var/lib/noip2. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#449475:
This just tells me that it's dual-licensed. Shouldn't this be asked at debian-legal? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#441435: Author still allowing redistribution
The author (acid) is still allowing redistribution of his work, under the condition that it not be modified. It is explained more at http://www.warsow.net/?page=blogid=24comments=1 Here's further clarification on this. added by: [EMAIL PROTECTED]/09/2007 @ 15:15 Oh and to clarify: We can release the maps in their current state in our packages (or the maps wouldn't be in 0.32; acid left before that). For 0.4 we are working on some renderupdates which demand texture/mapmodifications which we aren't allowed to do, hence we have no choice but to drop the maps. And here's a comment by the author. added by: [EMAIL PROTECTED]/09/2007 @ 10:39 The team is still allowed to add the current wdm2 state to every following release and even if it will not, then community members may still add the map as a custom map to their basewsw folder. So wdm2 is everything else than lost. Same for wdm11 and wctf2. In the case of Debian, this means these files can still be redistributed but without modifications. The copyright file of warsow-data already says this. This is true for version 0.32 of warsow as well, which is the current release. -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435468:
I would like to make another suggestion and use xmessage or Xdialog instead of zenity. Both require less dependencies of their own. -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433671:
On 8/4/07, Victor Luchits [EMAIL PROTECTED] wrote: Filenames for game modules need the arch suffix so that they can be distinguished at load time. All game modules for all archs are packed into a single .pk3 file which is used for pure servers. Clients that connect to pure servers are forced to download, unpack this .pk3 and load the game modules of their arch. A typical modules.pk3 file (which is essentially a .zip file) looks something like this: game_x86.dll game_x64.dll game_x86.so game_x86_x64.so ... Why would it be preferable to force the download of these modules, pure or not? Why can't the binaries that ship with the client just be used? Also, the Debian packages contain some bug fixes already, and I'm sure there will be more to come. From what you've said, this means that clients connecting to these pure servers are still going to have a problem anyways. Also, Michel has a point. This is a problem when cross compiling. -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#419681:
fixed 419681 1.4.3-1 thanks This should be fixed in version 1.4.3. I was able to compile ogre-1.4.3-1 in both sid and lenny. -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426872:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 libboost-python-dev now uses either -lboost_python-st or -lboost_python-mt. See http://bugs.debian.org/424038 boost_python-st was intended to be the default so modifications were made to the disable_internal_boost and rebootstrap patches and commited in SVN. Now a different problem occurs. g++ -pipe -O2 -ffast-math -falign-loops=2 -falign-jumps=2 -falign-functions=2 -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -pthread -pipe -L/usr/X11R6/lib -L/usr/X11R6/lib -o vegastrike vsfilesystem.o posh.o stardate.o star_system_xml.o star_system_generic.o universe_generic.o universe_util_generic.o galaxy.o galaxy_xml.o galaxy_gen.o faction_generic.o hashtable.o configxml.o easydom.o xml_serializer.o xml_support.o lin_time.o endianness.o faction_util_generic.o load_mission.o savegame.o pk3.o vs_globals.o debug_vs.o gfxlib_struct.o in_joystick.o force_feedback.o faction_util.o in_kb.o in_sdl.o in_mouse.o in_main.o in_handler.o main_loop.o physics.o star_system_jump.o star_system.o universe.o universe_util.o config_xml.o macosx_math.o cg_global.o main.o networking/netserver_devices.o networking/libnetclient.a networking/lowlevel/libnetlowlevel.a cmd/script/script_call_briefing.o cmd/script/libscript.a cmd/script/c_alike/libc_alike.a python/briefing_wrapper.o cmd/libcmd.a cmd/base_init.o python/libpython.a gfx/libgfx.a gldrv/libgldrv.a cmd/ai/libai.a gui/libgui.a networking/libnet.a cmd/collide/libcollide.a gfx/nav/libnav.a aldrv/libaldrv.a -lboost_python-st -lz -lvorbisfile -lvorbis -logg -lutil -L/usr/lib -lSDL -lGL -lGLU -lglut -lXi -lXmu -lexpat -lpng -ljpeg -lopenal -lalut -lvorbisfile -lvorbis -logg -lpython2.4 -Xlinker -export-dynamic -pthread /usr/lib/libboost_python-st.so: undefined reference to `PyErr_WarnEx' collect2: ld returned 1 exit status make[4]: *** [vegastrike] Error 1 make[4]: Leaving directory `/tmp/buildd/vegastrike-0.4.3.debian/src' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/tmp/buildd/vegastrike-0.4.3.debian/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/tmp/buildd/vegastrike-0.4.3.debian' make[1]: *** [all] Error 2 make[1]: Leaving directory `/tmp/buildd/vegastrike-0.4.3.debian' make: *** [build-stamp] Error 2 pbuilder: Failed autobuilding of package - Aborting with an error - unmounting dev/pts filesystem - unmounting proc filesystem - cleaning the build env - removing directory /var/cache/pbuilder/sid/build//2619 and its subdirectories -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: http://firegpg.tuxfamily.org iD8DBQFGZMtRgsFbAuXxMZYRArbLAKCPBgnbdVA7yKnrDMd+0nE58MfidgCgr5Tf rphz0CQnReop0rhrva1//h4= =8RkP -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
