Bug#349017: Does not appear here...
Hi! Against a fresh install of kde 3.5 here, kaudiocreator is fully functionnal... Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#367427: Is it a bug?
severity 367427 normal tags 367427 moreinfo, unreproducible thanks -- Hi! Are you sure you did not do anything bad? I have tested the install on a fresh server here, and it is definitly zorking.. Few hints: -- Base path for files is specified in your apache config, and is supposed to be set to /var/lib/mediawiki1.5, not /usr/share/mediawiki1.5 -- Then, there should exist a link /var/lib/mediawiki1.5/LocalSettings.php pointing to your LocalSettings.php in /etc/mediawiki1.5 With those two things, mediawiki bootstrap should work.. However, I agree that 600 is to restricted, specially for users running php as cgi as normal user.. But this does not seem to be your case, as you provided this depend: -- ii php4 4:4.4.0-2 server-side, HTML-embedded scripti Then it may be overriden but your apache config. In conclusion, please look more closely to your apache config, this is where the bug should come from... Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#368747: libgtk-mozembed-ruby1.8: Does not work here on powerpc...
Package: libgtk-mozembed-ruby1.8 Version: 0.3.1-5 Severity: grave Justification: renders package unusable Hi! Since release -5 and new dependency against libxul-dev, package is not working anymore.. I have a ruby application using it and allready packaged that I can give if you want to test. Romain -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-powerpc Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) Versions of packages libgtk-mozembed-ruby1.8 depends on: ii libatk1.0-0 1.11.4-2 The ATK accessibility toolkit ii libc6 2.3.6-9 GNU C Library: Shared libraries ii libcairo2 1.0.4-2 The Cairo 2D vector graphics libra ii libfontconfig1 2.3.2-5.1generic font configuration library ii libglib2.0-02.10.2-2 The GLib library of C routines ii libgtk2.0-0 2.8.17-2 The GTK+ graphical user interface ii libnspr4-0d 1.8.0.1-11 NetScape Portable Runtime Library ii libpango1.0-0 1.12.1-3 Layout and rendering of internatio ii libruby1.8 1.8.4-2 Libraries necessary to run Ruby 1. ii libx11-62:1.0.0-6X11 client-side library ii libxcursor1 1.1.5.2-5X cursor management library ii libxext61:1.0.0-4X11 miscellaneous extension librar ii libxfixes3 1:3.0.1.2-4 X11 miscellaneous 'fixes' extensio ii libxi6 1:1.0.0-5X11 Input extension library ii libxinerama11:1.0.1-4X11 Xinerama extension library ii libxrandr2 2:1.1.0.2-4 X11 RandR extension library ii libxrender1 1:0.9.0.2-4 X Rendering Extension client libra ii libxul0d1.8.0.1-11 Gecko engine library ii mozilla-browser 2:1.7.12-1.1 The Mozilla Internet application s libgtk-mozembed-ruby1.8 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#342213: Allready noticed.
Hi!
Thxs for the report.
I had noticed it yesterday.
The thing is AFAIK that this file needs an asm/atomic.h include.
And I discovered that this include was provided by the linux kernel jeaders.
Now come the tricky part: pbuilder chroot allready has those headers
installed, so it is no use to detect this.
I will upload a correct package ASAP.
Romain
--
while ( love & passion ) {
for( fight = 0 ; rights < freedom ; rights++ )
fight = standup( rights );
free( babylon );
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#342213: Allready noticed.
Le Mardi 6 Décembre 2005 12:11, Bastian Blank a écrit : > On Tue, Dec 06, 2005 at 11:58:22AM +0100, Romain Beauxis wrote: > > The thing is AFAIK that this file needs an asm/atomic.h include. > > And I discovered that this include was provided by the linux kernel > > jeaders. > > And a userspace program MUST NOT include this headers directly. Hum.. So what is the correct way of doing things then? Romain -- Not even the dog That piss against the wall of Babylon, Shall escape his judgement
Bug#342213: Allready noticed.
Le Mardi 6 Décembre 2005 12:14, Romain Beauxis a écrit : > > And a userspace program MUST NOT include this headers directly. > > Hum.. > So what is the correct way of doing things then? Hi! I have googled this and found out that it had to be re-implemented in userland. I search around for a library providing this, and I could not find anything interesting.. But alsa libs had a perfect implementation of the file, so I used their file. Now the package builds and run fine without the asm/atmoic.h I have submited the patch upstream. Hope to upload a new package ASAP Romain -- Why's this fussing and a-fighting? I wanna know, Lord, I wanna know Why's this bumping and a-boring? I wanna know, Lord, I wanna know now
Bug#357005: Patche added
tags 357005 + patch
thanks
Hi!
Please find a patch attached to correct this bug.
Romain
--
Lord is my light and my salvation. Who shall I be afraid of?
- The Gladiators - My Thoughts
The Lord is my light and my salvation; whom shall I fear?
- Psalm 27:1
diff -urN libgtk-mozembed-ruby-0.3.1/debian/changelog libgtk-mozembed-ruby-0.3.1.nmu/debian/changelog
--- libgtk-mozembed-ruby-0.3.1/debian/changelog 2006-03-27 17:13:47.0 +0200
+++ libgtk-mozembed-ruby-0.3.1.nmu/debian/changelog 2006-03-27 15:44:10.0 +0200
@@ -1,3 +1,10 @@
+libgtk-mozembed-ruby (0.3.1-4.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Added missing dependances for libgtk-mozembed-ruby1.8 (Closes: #357005)
+
+ -- Romain Beauxis <[EMAIL PROTECTED]> Mon, 27 Mar 2006 15:42:54 +0200
+
libgtk-mozembed-ruby (0.3.1-4) unstable; urgency=low
* Fixing wrong directory to install gtkmozembed.so.
diff -urN libgtk-mozembed-ruby-0.3.1/debian/control libgtk-mozembed-ruby-0.3.1.nmu/debian/control
--- libgtk-mozembed-ruby-0.3.1/debian/control 2006-03-27 17:13:47.0 +0200
+++ libgtk-mozembed-ruby-0.3.1.nmu/debian/control 2006-03-27 15:45:41.0 +0200
@@ -14,7 +14,7 @@
Package: libgtk-mozembed-ruby1.8
Architecture: any
-Depends: ${shlibs:Depends}
+Depends: ${shlibs:Depends}, mozilla-browser
Description: ruby 1.8 binding of GtkMozEmbed, gecko renderer
Ruby 1.8/GtkMozEmbed is a Ruby binding of GtkMozEmbed a widget embedding a
Mozilla Gecko renderer.
pgpaWEyCQnnUg.pgp
Description: PGP signature
Bug#359950: linux-image-2.6.16-1-powerpc: Fails to build ramdisk with mkinitramfs-kpkg
Package: linux-image-2.6.16-1-powerpc Version: 2.6.16-4 Severity: grave Justification: renders package unusable Hi! Upgrading my kernel here, I got: Finding valid ramdisk creators. Using mkinitramfs-kpkg to build the ramdisk. /usr/sbin/mkinitramfs-kpkg: line 55: supported_host_version: unbound variable mkinitramfs-kpkg failed to create initrd image. Failed to create initrd image. dpkg : erreur de traitement de linux-image-2.6.16-1-powerpc (--configure) : I know it can be a bug from the ramdisk creator, but I don't want to go further on that issue, and it seems to be a script related error. Thanks for your work! Romain -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-powerpc Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) Versions of packages linux-image-2.6.16-1-powerpc depends on: ii initramfs-tools [linux-initra 0.59 tools for generating an initramfs ii mkvmlinuz 18 create a kernel to boot a PowerPC ii module-init-tools 3.2.2-2tools for managing Linux kernel mo linux-image-2.6.16-1-powerpc recommends no packages. -- debconf information: linux-image-2.6.16-1-powerpc/postinst/bootloader-error-2.6.16-1-powerpc: linux-image-2.6.16-1-powerpc/preinst/already-running-this-2.6.16-1-powerpc: linux-image-2.6.16-1-powerpc/preinst/initrd-2.6.16-1-powerpc: linux-image-2.6.16-1-powerpc/preinst/overwriting-modules-2.6.16-1-powerpc: true linux-image-2.6.16-1-powerpc/postinst/old-system-map-link-2.6.16-1-powerpc: true linux-image-2.6.16-1-powerpc/postinst/depmod-error-2.6.16-1-powerpc: false linux-image-2.6.16-1-powerpc/prerm/would-invalidate-boot-loader-2.6.16-1-powerpc: true linux-image-2.6.16-1-powerpc/preinst/elilo-initrd-2.6.16-1-powerpc: true linux-image-2.6.16-1-powerpc/postinst/bootloader-test-error-2.6.16-1-powerpc: linux-image-2.6.16-1-powerpc/postinst/old-dir-initrd-link-2.6.16-1-powerpc: true linux-image-2.6.16-1-powerpc/preinst/abort-overwrite-2.6.16-1-powerpc: linux-image-2.6.16-1-powerpc/postinst/kimage-is-a-directory: linux-image-2.6.16-1-powerpc/postinst/depmod-error-initrd-2.6.16-1-powerpc: false linux-image-2.6.16-1-powerpc/preinst/lilo-has-ramdisk: linux-image-2.6.16-1-powerpc/preinst/lilo-initrd-2.6.16-1-powerpc: true linux-image-2.6.16-1-powerpc/preinst/failed-to-move-modules-2.6.16-1-powerpc: linux-image-2.6.16-1-powerpc/prerm/removing-running-kernel-2.6.16-1-powerpc: true linux-image-2.6.16-1-powerpc/preinst/bootloader-initrd-2.6.16-1-powerpc: true linux-image-2.6.16-1-powerpc/postinst/create-kimage-link-2.6.16-1-powerpc: true linux-image-2.6.16-1-powerpc/preinst/abort-install-2.6.16-1-powerpc: linux-image-2.6.16-1-powerpc/postinst/old-initrd-link-2.6.16-1-powerpc: true
Bug#357005: libgtk-mozembed-ruby1.8: does not works: missing dependencies
Package: libgtk-mozembed-ruby1.8 Version: 0.3.1-4 Severity: grave Justification: renders package unusable Hi! this package is not working because of missing dependencies. The ldd on /usr/lib/ruby/1.8/powerpc-linux/gtkmozembed.so has the following missing libraries: libgtkembedmoz.so => not found libxpcom.so => not found Romain -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-powerpc Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) Versions of packages libgtk-mozembed-ruby1.8 depends on: ii libatk1.0-0 1.10.3-1 The ATK accessibility toolkit ii libc6 2.3.6-3GNU C Library: Shared libraries an ii libcairo2 1.0.2-3The Cairo 2D vector graphics libra ii libfontconfig12.3.2-5generic font configuration library ii libglib2.0-0 2.8.6-1The GLib library of C routines ii libgtk2.0-0 2.8.13-1 The GTK+ graphical user interface ii libpango1.0-0 1.10.4-1 Layout and rendering of internatio ii libruby1.81.8.4-1Libraries necessary to run Ruby 1. ii libx11-6 6.9.0.dfsg.1-4 X Window System protocol client li ii libxcursor1 1.1.3-1X cursor management library ii libxext6 6.9.0.dfsg.1-4 X Window System miscellaneous exte ii libxi66.9.0.dfsg.1-4 X Window System Input extension li ii libxinerama1 6.9.0.dfsg.1-4 X Window System multi-head display ii libxrandr26.9.0.dfsg.1-4 X Window System Resize, Rotate and ii libxrender1 1:0.9.0.2-1X Rendering Extension client libra libgtk-mozembed-ruby1.8 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#347847: vlc: Not installable on powerpc unstable
Package: vlc Severity: grave Justification: renders package unusable Hi! VLC is not instalable on powerpc because of two missing packages: Les paquets suivants contiennent des dépendances non satisfaites : vlc: Dépend: dbus-1 (>= 0.23.4) mais il n'est pas installable Dépend: libhal0 (>= 0.4.0) mais il n'est pas installable and: Aucune version du paquet dbus-1 n'est disponible, mais il existe dans la base de données. Cela signifie en général que le paquet est manquant, qu'il est devenu obsolète ou qu'il n'est disponible que sur une autre source Cependant les paquets suivants le remplacent : dbus with: E: Aucun paquet ne correspond au paquet libhal0 Both of them are now replaced by more recent ones, so maybe a rebuild of vlc would solve the issue.. Romain Beauxis -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-powerpc Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1)
Bug#328696: gallery2: Dependencies mistakes..
Package: gallery2 Severity: grave Justification: renders package unusable >From the last package from sid, I get: Version: 2.0-1 Depends: apache | apache-ssl | apache-perl | apache2, php4 | php4-cgi | libapache2-mod-php4 | php5 | php5-cgi | libapache2-mod-php5, netpbm (>= 9.20), debconf (>= 0.2.26), mysql-client, wwwconfig-common, php4-mysql | php5-mysql Recommends: imagemagick, jhead, unzip, libjpeg-progs, php4-gd | php5-gd, dcraw, ffmpeg, mysql-server-4.1 | mysql-server, postgresql-7.4 | postgresql-8.0 First of all, the libapache-mod-php4 is not present, so the package is not installable for apache 1 users.. Hence setting this bug as 'grave' Just to be sure I rebuilt the package with added dependency and it worked - was not a surprise.. Also, if I refer to the webpage: "In order to automatically generate thumbnails and resized versions of your photos, Gallery requires either ImageMagick or NetPBM. Gallery 2 additionally supports GD and GraphicsMagick" So, the dependency over netpbm should otherwise propose imagemagick, and not only recommend it. And it should also be check is gd or gm only would be enought.. Romain -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13.1-bogue Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#332531: Bug still not solved
reopen 332531 -- As I can see here: http://buildd.debian.org/fetch.php?&pkg=mediawiki&ver=1.4.11-1&arch=s390&stamp=1128652949&file=log&as=raw This problem still occurs at least during buildd Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#332531: Bug pending.
tags 332531 pending -- This bug will be fixed in next upload.. Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#332531: Half corrected
Hi! This bug is corrected in mediawiki-1.4.11-1 becasue the arch where it cannot be built have been removed from the list. But, the correct way to solve it is to build a bytecode where there si no native encoder which is allready done and waiting for upload.. Hence setting the severity of this bug to normal, and closing it when the next version will be uploaded. Romain -- We should really love each other In peace and harmony Instead, instead, we're fussing and fighting Like we ain't supposed to be, tell me why pgp6aG0FrIUSN.pgp Description: PGP signature
Bug#392941: [EMAIL PROTECTED]: Your message to Pkg-mediawiki-devel awaits moderator approval]
Le samedi 14 octobre 2006 14:06, Bill Allombert a écrit : > Dear Maintenance team for the mediawiki package, Hi! > Please make sure this kind of bounce never ever happen in the future. > > Given at this stage the bug is already recorded in the BTS, this bounce > serve no purpose except wasting resource. Well, given that your bug is the kid of use that we would never hava had in real life -- installing 1.7-math module and 1.5 main at the same time is not really intersting isn't it?, and that we indeed will have to handle such a stupid bug tagged serious by a new upload and a backport of the changes to the forthcoming 1.8 package, I would say that the main waste of ressource does not really came from us today... Have a good day BTW. Romain -- The lips of the righteous feed many: but fools die for want of wisdom. - Proverbs 10:21 The lips of the righteous teaches many But fools die for want of wisdom - Peter Tosh, Fools Die
Bug#433141: Licence clarified but..
Hi ! Why didn't you use the php package I uploaded to fix this issue ? In particular, there are licence issues when including something licenced with the PHP licence in a software not being part of PHP itself. Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#466539: gnome-peercast: CVE-2007-6454 heap-based buffer overflow possibly leading to code execution
Package: gnome-peercast Version: 0.5.4-1.1 Severity: grave Tags: security Justification: user security hole Hi ! CVE-2007-6454 as been fixed for peercast, but since this package includes a static version of the code, the vulnerability still applies there. As a side note, I've already done a lot of things to try to fix this, but upstream seems not to care at all, and didn't maintain this package for 1 year (last upload was my NMU)... Romain -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-rc7-mactel (SMP w/2 CPU cores; PREEMPT) Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#466539: gnome-peercast: CVE-2007-6454 heap-based buffer overflow possibly leading to code execution
Le Tuesday 19 February 2008 14:08:46 Thijs Kinkhorst, vous avez écrit : > > As a side note, I've already done a lot of things to try to fix this, > > but upstream seems not to care at all, and didn't maintain this package > > for 1 year (last upload was my NMU)... > > So am I right to conclude that we'd better remove this package rather than > to try and fix it? Well, popcon is not zero, but unless maintainer is willing to support it (he is upstream too), then yes, that's my point too. Romain
Bug#433141: gallery: incorrect licence for file HTMLSax3.php
Package: gallery Version: 1.5.5-pl1-1.1 Severity: serious Justification: Policy 2.3 Hi ! The file /usr/share/gallery/classes/XML_HTMLSax3/HTMLSax3.php has a licence that causes issues with debian free software guidelines, see #431026 and #431025 for similar issues. Romain -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.20-1-amd64 (SMP w/1 CPU core) Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#433141: Clarifications on issues for this bug
Hi maintainers ! These bugs have different issues to solve before we may close them.. * Licence version: the licence under which the file is licenced (either 2 or 3.01) has to be cleared. * Location of the file: We already have three packages using it, with SPIP it will be 4, so it's time to think about packaging a separate package for the pear module. Furthermore, it's the only way to fulfill with the PHP licence since the licence applies to PHP and Zend only (and pear by extension I guess...) * Maintainability of the code: Although we can see that the base code provided by this file is valuable, the PEAR project seems dead or unmaintained... Is it possible to package a pear module that we know is dead ? Of coourse, a fork, or better, a commit access to the project would be perfect, but I don't have enough time for this.. Hope to hear so good news from you or anyone else ... Romain -- son, daddy left you were from you were four I've got to struggle 'cos I am poor she said, food is a very hard thing to find sometime I feel like I'm going out of my mind -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#433141: Clarifications on issues for this bug
Le Wednesday 18 July 2007 03:59:40 Romain Beauxis, vous avez écrit : > Of coourse, a fork, or better, a commit access > to the project would be perfect, but I don't have enough time for this.. Another possibility is to switch back to some other codebase.. The basic question for me is: could php's xml parsing functions do an equivalent job for your application ? http://www.php.net/manual/fr/function.xml-parse.php Romain -- Ask no question, hear no lies !
Bug#433788: Not reproducible
severity 433788 important
tags 433788 unreproducible moreinfo
thanks
Hi !
I cannot reproduce this bug, please give a way to do so.
Romain
--
while ( love & passion ) {
for( fight = 0 ; rights < freedom ; rights++ )
fight = standup( rights );
free( babylon );
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#451973: Adapt severity
severity 451973 important thanks Hi ! Allthough I beleive fglrx is somewhat broken (...), it works at least for some configurations, like mine... Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#454163: Ack
severity 454163 whishlist retitle 454163 "Cannot downgrade to 8.40.4 or below" thanks Hi ! Yes indeed, diversion support in previous packages was rather odd to my point. However, there will be no possibility to downgrade at all when X will be moved to testing since 8.40.4 and below will not be compatible at all... Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#454164: Upstream
severity 454164 important thanks Hi ! Upstream has dropped support for those cards, there's not much I can do... Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#454467: v8.43.2-1 crashes X with ATI Mobility FireGL V5200
severity 454467 important forcemerge 454467 454164 thanks Le Wednesday 05 December 2007 13:55:19 Alexander Mader, vous avez écrit : > Hello, Hi ! > at first: many thanks for maintaining the fglrx-package! Thanks! But please try to read some documentation and check wether your bug doesn't exist before submiting a new one. ATI has dropped (temporarily I hope) support for your card, and a bug was already opened for that.. > After the update and w/o changing xorg.conf X doesn't start any more. Both > the vesa and the Xorg-ATI-driver aren't an option for me because they > aren't working as well :-( Try radeonhd from experimental. Romain
Bug#454467: Files and related reports
Le Wednesday 05 December 2007 14:25:17 Mader, Alexander (N-MSR), vous avez écrit : > Hello, Hi ! > attached you'll find the promised files. > > Pls, let me mention that I read the reports #454163 and #454164 So you should have noticed that the last one is precisly your issue.. Romain
Bug#454751: Glibc detects double free corruption when running fglrxinfo or any 3d apps
severuty 454751 important thanks Le Friday 07 December 2007 15:45:45 Daniel Paquet, vous avez écrit : > New installation of Lenny > Same problem happen when running stock lenny kernel > > Glibc detects a double free corruption when I try to run 3d apps, I > have this error > at everytimes I run fglrxinfo. > > Machine crash some times > No display when I exit X > I have to type "blind" to reboot the machine or press power. > > As I am not familiar with bug reporting I dont really know what > information to give you. Well, for this non free blob, there's almost nothing more to say, I can't do much more to fix.. Only you can check with futur releases wether it is fixed or not, and report it here.. But the severity is too strong there, since the driver still works, only not with some 3D applications.. Romain
Bug#457457: fglrx-driver: locks up my system when the x server starts
severity 457457 important thanks Le Saturday 22 December 2007 16:25:40 Sam Morris, vous avez écrit : > Package: fglrx-driver > Version: 8.44.3-1 > Severity: grave > Justification: renders package unusable Not for everyone... > My system freezes when the X server is started and the version of fglrx > from unstable is used. The version of fglrx currently in testing works > fine. Hum.. The first time I switched to this release, the X server froze too, but it went ok after a full restart.. However, the driver works for others (like me), besides its bad resolutions and all previous bugs of course... Romain
Bug#457725: resolution stuck at 1280x1024
forcemerge 457298 457725 thanks Le Tuesday 25 December 2007 01:20:51 Thomas Bushnell BSG, vous avez écrit : > Package: fglrx-driver > Version: 8.44.3-1 > Severity: serious Driver still working.. > This is not at all ready for the unstable distribution, and belongs in > experimental. The ChangeLog suggests that you uploaded this *knowing* > it would have this bug, which makes it essentially useless on any modern > hardware. Please try not to open new bugs that are already reported. More than the changelog, *I* have opened it. This release is the first one to support fireGL again, which has also been an important complain recently. And at least, you've got it working which was not the case for fireGL owners, and you may also use radeonhd for widescreen resolutions. I don't have other options than uploading to sid, as I say, it's the usual fglrx's tango. Romain
Bug#443129: Re(4): Bug#443129: incompatible xorg 7.3 (modules 1.4.0)
Le Friday 05 October 2007 10:40:11 [EMAIL PROTECTED], vous avez écrit : > what's wrong with version 8.40.4-2 for i386? Why hasnt'it built for i386 > yet? I don't know, but with the latest Xorg there's no point in building it again since its binary incompatible with Xorg Romain
Bug#443129: same error, fglrx-driver incompatible with Xorg 7.3
Le Tuesday 09 October 2007 16:49:07 Khristian, vous avez écrit : > And I can't try the avivo or radeonhd suggestion, I don't think it > will work with my Radeon XPress 1100 card (x300 core). It works on my mac book pro, but only 2d... Romain -- Everyone is crying out for peace, yes None is crying out for justice I don't want no peace I want equal rights and justice
Bug#446500: Severity
severity 446500 wishlist thanks Hi ! Thanks for the report, but this certainly not a serious bug. Current roundcube works with current db-config, so there's no bug. If you need a proper dependency for your backports, do it there. Romain -- So anywhere I go, I want the world to know, Rasta never fail ! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#446502: more information
severity 446502 normal tags 446502 moreinfo thanks Hi ! I don't understand your report, which file and which section of the policy are you refering to ? Romain -- Could not recognize the faces standing over me; They were all dressed in uniforms of brutality. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#446500: Severity
severity 446500 normal thanks Le Sunday 14 October 2007 02:55:07 Julien Cristau, vous avez écrit : > On Sun, Oct 14, 2007 at 01:49:27 +0200, Romain Beauxis wrote: > > severity 446500 wishlist > > thanks > > > > Hi ! > > > > Thanks for the report, but this certainly not a serious bug. > > > > Current roundcube works with current db-config, so there's no bug. > > Yes there is. Breaking partial upgrades between releases is a RC bug. Please don't play severity ping pong. Roundcube is *not* in etch, so I don't see what's broken between releases. As far as I know we don't handle backports for stable updates, do we ? Romain -- Why do they fight against the poor youth of today? 'Cause without these youths, they would be gone - All gone astray
Bug#443129: closed by Romain Beauxis <[EMAIL PROTECTED]> (Bug#443129: fixed in fglrx-driver 8.42.3-1)
Le Wednesday 24 October 2007 21:27:45 Encolpe Degoute, vous avez écrit : > Do you take us for idiots ! Please retain you language, I'm not here to read such things. > It's the second time you close a bug after only upload the amd64 package! > > Please upload at least one x86 package or reopen the bug. Seems you don't understand the way package upload works. I build a package for the architecture I am using, and then the package is automatically built for others. Beside, it just have been uploaded for i386, so you should just keep it quite next time. Romain -- He say 'im that he's the first one Who discover Jamaica, I an' I say that: What about the Awarak indians ?
Bug#443129: closed by Romain Beauxis <[EMAIL PROTECTED]> (Bug#443129: fixed in fglrx-driver 8.42.3-1)
Le Wednesday 24 October 2007 22:13:03 Encolpe Degoute, vous avez écrit : > For last version it was not. The i386 packages were made lately (See > #440186). > Then you should wait that these packages have been generated before to > close one bug. > Or you can just said that the bug is fixed upstream without show us your > amd64 logs that we don't care. Just read again the whole bug report. Do you realise that it was about "incompatible xorg 7.3 (modules 1.4.0)" ? So first of all you have to report one issue per report if you want them to be fixed. Secondly I don't think there's anything I "should" do based on the way you write your requests. This bug is closed since the module now installs with latest xorg package. Furthermore, if you feel frustrated with current fglrx state, you should imagine that me too. Especially since it took me some hours to prepare this crapy package, so I'd appreciate some considerations for that, not agressive requests. I'm not from ATI neither do I support fglrx in any way, please keep that in mind. Romain -- There is a land far, far away Where there's no night, there's only day Look into the book of life and you will see That there's a land far, far away
Bug#431026: Bug#431025: Bug#431026: [PEAR-DEV] Quality assurance proposition for HTMLSax3
Le Tuesday 30 October 2007 23:28:42 Michael Schultheiss, vous avez écrit : > > he has fixed the licence problem with HtmlSax and HTMLSax3 in CVS of > > pear. You can see it here: > > http://cvs.php.net/viewvc.cgi/pear/XML_HTMLSax/ > > All Harry did was switch to the PHP 3.0 license, which does nothing to > solve the license problem. A license such as the BSD or Expat license > would solve the problem. Now that licence is cleared, I think we can choose to use 3.01, as stated... " 5. The PHP Group may publish revised and/or new versions of the license from time to time. Each version will be given a distinguishing version number. Once covered code has been published under a particular version of the license, you may always continue to use it under the terms of that version. You may also choose to use such covered code under the terms of any subsequent version of the license published by the PHP Group. No one other than the PHP Group has the right to modify the terms applicable to covered code created under this License." Or do I miss a point ? Romain -- Took us away from civilization Brought us to slave in this big plantation Fussing and fighting, among ourselves Nothing to achieve this way, it's worser than hell, I say
Bug#431026: Bug#431025: Bug#431026: [PEAR-DEV] Quality assurance propositionfor HTMLSax3
On Tue, 30 Oct 2007 20:03:31 -0400, Michael Schultheiss <[EMAIL PROTECTED]> wrote: > PHP 3.01 is still GPL incompatible. There's also many people under the > impression that the PHP license is only valid for code from the PHP > Group. To solve the license issue, a GPL compatible license needs to be > chosen. http://www.fsf.org/licensing/licenses/ lists numerous GPL > Compatible Free Software Licenses. But who said we need a GPL compatible licence ? This issue is getting on my nerves now, so please stop throwing pointless issues. Debian can accept software packaged under PHP licence 3.01 provided that they ship only php-related files. I you have a doubt, look at php5's package licence. *So* I have prepared a pakcage shipping *only* this pear package and uploaded it to new. It's still stuck there, but I hope that since the licence is cleared, it will be accepted. Now my question was wether there was something I didn't figured out in *this* scenario, not yet another occasion to feed the troll on GPL vs. PHP licence. Romain -- If you are the big three, We are the small axe...
Bug#431025: Bug#433141: Bug#431025: Bug#431026: [PEAR-DEV] Quality assurancepropositionfor HTMLSax3
On Wed, 31 Oct 2007 10:00:45 -0400, Michael Schultheiss <[EMAIL PROTECTED]> wrote: > Romain Beauxis wrote: >> On Tue, 30 Oct 2007 20:03:31 -0400, Michael Schultheiss >> <[EMAIL PROTECTED]> wrote: >> > PHP 3.01 is still GPL incompatible. There's also many people under > the >> > impression that the PHP license is only valid for code from the PHP >> > Group. To solve the license issue, a GPL compatible license needs to > be >> > chosen. http://www.fsf.org/licensing/licenses/ lists numerous GPL >> > Compatible Free Software Licenses. >> >> But who said we need a GPL compatible licence ? > > The 3 Debian bugs cc'd remain open due to incompatible licenses. They are *unclear* issues mainly. >> This issue is getting on my nerves now, so please stop throwing >> pointless issues. Debian can accept software packaged under PHP >> licence 3.01 provided that they ship only php-related files. >> >> I you have a doubt, look at php5's package licence. > > Debian accepts PHP licensed code if it's from the PHP Group. As it seems this can extend to pear packages, see php-xml-parser. It is even lioenced under version 3... >> *So* I have prepared a pakcage shipping *only* this pear package and >> uploaded it to new. It's still stuck there, but I hope that since the >> licence is cleared, it will be accepted. >> >> Now my question was wether there was something I didn't figured out in >> *this* scenario, not yet another occasion to feed the troll on GPL vs. >> PHP licence. > > My whole involvement in this issue is due to the license incompatibility > and the release critical bugs in two of my packages due to that license > issue. I'm not trying to troll, I'm trying to resolve issues affecting > my packages and the software teams I'm part of. Sorry for suggesting so. The fact is that I feel this is a lame issue that should have been solved quickly but it's not (yet) the case.. Romain -- If you are the big three, We are the small axe...
Bug#431025: Bug#431026: Bug#433141: Bug#431025: Bug#431026: [PEAR-DEV] Quality assurancepropositionfor HTMLSax3
Le Friday 02 November 2007 21:53:29 Frank Habermann, vous avez écrit : > Hi, Hi ! > FYI: Harry is adding LGPL to HTMLSax and HTMLSax3. > > So it will be ok for debian or not? PHP license version 3 was already ok. A debian package php-xml-htmlsafe3 has just entered debian, and should allow packagers to resolve this issue. Thanks for your patience so far.. Romain -- You can fool some people sometimes, But you can't fool all the people all the time.
Bug#450903: libocamlnet-ssl-ocaml: segfault on custom ssl bindings
Package: libocamlnet-ssl-ocaml
Version: 2.2.8.1-1
Severity: grave
Tags: patch
Justification: renders package unusable
Hi !
While playing with the ssl_client.ml example, I ended up correcting two
issues:
* ssl_client.ml must use:
let cl_ctx = Ssl.create_context Ssl.TLSv1 Ssl.Client_context in
to use the correct function from ocaml-ssl
* The example segfaulted..
After some introspection, helped by Sam, we found out that the package
ships its custom ssl extra-bindings.
These are out-of-date and caused the segfault.
Attached is patch that fixes them.
Of course, those bindings may be directly provided by ocaml-ssl, this
would help to get them in sync with latest ocaml-ssl has well as
debugging them along the others...
Romain
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.22-1-amd64 (SMP w/1 CPU core)
Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Versions of packages libocamlnet-ssl-ocaml depends on:
ii libc6 2.6.1-6GNU C Library: Shared libraries
ii libocamlnet-ocaml 2.2.8.1-1 OCaml application-level Internet l
ii libssl-ocaml 0.4.2-3OCaml bindings for OpenSSL
ii ocaml-base-nox [ocaml-base-no 3.10.0-8 Runtime system for ocaml bytecode
libocamlnet-ssl-ocaml recommends no packages.
-- no debconf information
--- ocamlnet-2.2.8.1.orig/src/equeue-ssl/ssl_exts_stubs.c
+++ ocamlnet-2.2.8.1/src/equeue-ssl/ssl_exts_stubs.c
@@ -6,41 +6,29 @@
#include
#include
#include
-
+#include
#include
#include
#include
#include
#include
-
-/* The following definitions are copied from ssl_stubs.c: */
-
-struct ssl_socket__t
-{
- SSL *handler;
- int fd;
-};
-
-typedef struct ssl_socket__t ssl_socket_t;
-
-static ssl_socket_t* ssl_socket_of_block(value block)
-{
- return (ssl_socket_t*)Field(block, 1);
-}
+#define SSL_val(v) (*((SSL**)Data_custom_val(v)))
CAMLprim value ocaml_ssl_single_shutdown(value socket)
{
CAMLparam1(socket);
int ret;
- ssl_socket_t *ssl = ssl_socket_of_block(socket);
- ret = SSL_shutdown(ssl->handler);
+ SSL *ssl = SSL_val(socket);
+ caml_enter_blocking_section();
+ ret = SSL_shutdown(ssl);
if (ret == -1) {
raise_with_arg(*caml_named_value("ssl_exn_shutdown_error"),
- Val_int(SSL_get_error(ssl->handler, ret)));
+ Val_int(SSL_get_error(ssl, ret)));
};
+ caml_leave_blocking_section();
CAMLreturn(Val_unit);
}
@@ -52,8 +40,10 @@
CAMLlocal3(rcvd,sent,ret);
int r;
- ssl_socket_t *ssl = ssl_socket_of_block(socket);
- r = SSL_get_shutdown(ssl->handler);
+ SSL *ssl = SSL_val(socket);
+ caml_enter_blocking_section();
+ r = SSL_get_shutdown(ssl);
+ caml_leave_blocking_section();
rcvd = Val_bool(r & SSL_RECEIVED_SHUTDOWN);
sent = Val_bool(r & SSL_SENT_SHUTDOWN);
ret = alloc_tuple(2);
@@ -71,8 +61,10 @@
BIO *b;
int eof;
-ssl_socket_t *ssl = ssl_socket_of_block(socket);
-b = SSL_get_rbio(ssl->handler);
+SSL *ssl = SSL_val(socket);
+caml_enter_blocking_section();
+b = SSL_get_rbio(ssl);
+caml_leave_blocking_section();
if (b == NULL)
failwith("Ssl.get_rbio_eof: No rbio found");
eof = BIO_eof(b);
@@ -87,8 +79,10 @@
CAMLparam1(socket);
CAMLlocal1(ret);
long m;
-ssl_socket_t *ssl = ssl_socket_of_block(socket);
-m = SSL_get_mode(ssl->handler);
+SSL *ssl = SSL_val(socket);
+caml_enter_blocking_section();
+m = SSL_get_mode(ssl);
+caml_leave_blocking_section();
ret = alloc_tuple(3);
Store_field(ret, 0, Val_bool(m & SSL_MODE_ENABLE_PARTIAL_WRITE));
Store_field(ret, 1, Val_bool(m & SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER));
@@ -100,12 +94,14 @@
{
CAMLparam2(socket,mode);
long m;
-ssl_socket_t *ssl = ssl_socket_of_block(socket);
+SSL *ssl = SSL_val(socket);
m = 0;
if (Bool_val(Field(mode, 0))) m |= SSL_MODE_ENABLE_PARTIAL_WRITE;
if (Bool_val(Field(mode, 1))) m |= SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER;
if (Bool_val(Field(mode, 2))) m |= SSL_MODE_AUTO_RETRY;
-SSL_set_mode(ssl->handler, m);
+caml_enter_blocking_section();
+SSL_set_mode(ssl, m);
+caml_leave_blocking_section();
CAMLreturn(Val_unit);
}
Bug#431025: php-xml-htmlsax3 entered unstable !
Hi all ! php-xml-htmlsax3 entered unstable today. That means you can now fix these bugs properly I've also packaged php-html-safe which together make what was often shipped as 'safehtml'. You may now remove those files for your archive, and include the files shipped with those packages. I've uploaded a spip package that implements this. So far, everything seemed to go fine. Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#458449: Starting of x.org fails with "PreInitDAL failed"
severity 458449 important thanks Le Monday 31 December 2007 14:57:54 Georgi Naplatanov, vous avez écrit : > Package: fglrx-driver > Version: 8.44.3-1 > Severity: critical Not for everyone... > After installation of fglrx-driver 8.44.3-1, x.org did not start. It would be nice if you could add hardware details on your board.. Romain
Bug#459852: fglrx-driver: Driver forces large virtual size
severity 459852 important thanks > I am using a Radeon X300 with a monitor running at 1280x1024. The driver > is forcing a virtual size with twice the X dimension even though there is > no second display attached. > > I have attempted a number of things to get around this, but none worked: > 1) Set 'Virtual' to 1280 1024 in the Display section of xorg.conf > 2) Forcing Xinerama to be disabled > 3) Using the fglrx option "DesktopSetup" to "single" > 4) Specifying a specific modeline and turning off EDID or DDC > > None of these had any effect. It seems that the driver is just ignoring > everything I tell it. And in the case of #4 where I specified a modeline, > the X server just crashed at startup. > > While the driver is scanning through all sorts of modes (I don't know where > it gets them) I see at the beginning: > > (II) fglrx(0): Total of 50 modes found for primary display. > (--) fglrx(0): Virtual size is 1280x1024 (pitch 0) > (**) fglrx(0): *Mode "1280x1024": 135.0 MHz (scaled from 0.0 MHz), 80.0 > kHz, 75.0 Hz (II) fglrx(0): Modeline "1280x1024" 135.00 1280 1296 1440 > 1688 1024 1025 1028 1066 > > This looks correct. But as the modes keep passing by, I see: > > (**) fglrx(0): Default mode "320x200": 12.6 MHz (scaled from 0.0 MHz), > 31.5 kHz, 60.0 Hz (D) (II) fglrx(0): Modeline "320x200" 12.59 320 336 > 384 400 200 457 459 524 doublescan (--) fglrx(0): Display dimensions: > (330, 240) mm > (--) fglrx(0): DPI set to (98, 108) > (--) fglrx(0): Virtual size is 2560x1024 (pitch 2560) > (**) fglrx(0): *Mode "1280x1024": 135.0 MHz (scaled from 0.0 MHz), 80.0 > kHz, 75.0 Hz (II) fglrx(0): Modeline "1280x1024" 135.00 1280 1296 1440 > 1688 1024 1025 1028 1066 > > It then proceeds to run though the same list of modelines three more times. > The end result is that the single monitor is indeed running at 1280x1024 > @75Hz, but the virtual size is at 2560x1024 and I can't change it. > > Perhaps this is related to the widescreen resolutions bug? I also tried > the previous version, 8.43.2-2, but it did the same thing. I am upgrading > from 8.39.4-1. Should be related to the widescreen issue, but it's hard to tell regarding the closed-source nature of the driver. Also upstream report those issues: > Connecting a display device that supports 1680x1050 to a system running Linux may result in a maximum display resolution of 1280x1024 only being available > Custom mode lines in xorg.conf may be ignored by the fglrx driver Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#427021: FATAL: Module ov51x_jpeg not found.
Le Friday 01 June 2007 13:19:04 Rafal Czlonka, vous avez écrit : > Hi, > Module builds and installs, but when I try to load it: > # modprobe ov51x-jpeg > FATAL: Module ov51x_jpeg not found. > > The module is build using module-assistant if that makes any difference. Did you actually *installed* the generated module ? Romain
Bug#427021: FATAL: Module ov51x_jpeg not found.
Le Friday 01 June 2007 14:08:27, vous avez écrit : > Romain Beauxis wrote: > > Did you actually *installed* the generated module ? > > Yes I did install (not installed) it. Who do you take me for? Sorry for previous question, but I needed to ask... > The only module in the package which got build was ov51x-jpeg, there > wasn't any ov51x_jpeg. Naming with - or _ should not be an issue, they are the same You should check wether the module has been built and installed for the good kernel version you are using, some thing like comparing: dpkg -L ov51x-module-$yourversion and uname -r Romain
Bug#427021: Not confirmed
tags 427021 unreproducible moreinfo severity 427021 important thanks Hi ! Tagging and downgrading the bug until it can be reproduced and confirmed.. Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#427494: Precise issue...
Hi ! You are not clear enough with your last message. The question is to know wether the ATI driver works but beryl not or if it does not work at all... Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#428096: liquidsoap: needs libcamomile-ocaml-data
Package: liquidsoap
Version: 0.3.2-3
Severity: grave
Justification: renders package unusable
liquidsoap needs libcamomile-ocaml-data in order to work:
20:56 [EMAIL PROTECTED] ~% liquidsoap
Fatal error: exception
Sys_error("/usr/share/camomile/database/general_category.mar: No such file or
directory")
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.21.4-mactel (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Versions of packages liquidsoap depends on:
ii adduser 3.102 Add and remove users and groups
ii libao2 0.8.8-2 Cross Platform Audio Output Librar
ii libc62.5-10 GNU C Library: Shared libraries
ii libid3tag0 0.15.1b-10 ID3 tag reading library from the M
ii libmad0 0.15.1b-2.1 MPEG audio decoder library
ii libncurses5 5.6-3 Shared libraries for terminal hand
ii libogg0 1.1.3-2 Ogg Bitstream Library
ii libshout32.2.2-1 MP3/Ogg Vorbis broadcast streaming
ii libspeex11.1.12-3The Speex Speech Codec
ii libtheora0 0.0.0.alpha7.dfsg-2 The Theora Video Compression Codec
ii libvorbis0a 1.1.2.dfsg-1.2 The Vorbis General Audio Compressi
ii libvorbisenc21.1.2.dfsg-1.2 The Vorbis General Audio Compressi
ii libvorbisfile3 1.1.2.dfsg-1.2 The Vorbis General Audio Compressi
ii wget 1.10.2-2retrieves files from the web
Versions of packages liquidsoap recommends:
pn icecast2 (no description available)
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#442020: fails to download my ebay items
severity 442020 important thanks Le Wednesday 12 September 2007 17:30:46 martin f krafft, vous avez écrit : > jbidwatcher stopped working and does not display items I am > watching in My eBay anymore, even after I tell it to download them. > The software has basically become unusable, probably because eBay > changed something. Hi ! Indeed, ebay has a pretty much instable API - it not even an API.. However, jbidwatcher's author is very responsive to this. In particular, have you tried the "check for update" option in "File" menu. normally launched upon startup, this function mays also update some definitions when the change in ebay's API is recoverable.. See: http://forum.jbidwatcher.com/forums/9/topics/1075 "Greetings, If you’re having trouble with 1.0.2, go to the ‘File’ menu, and choose ‘Check for Updates’. It’ll tell you there are no new updates, but it will have silently loaded the two new strings for the matching code. Your auctions should immediately start updating again. Thanks to Laurence Passmore again, for the fix. I took his patch, and just put it (pretty much) straight into the update file, and it worked. — Morgan Schweers, CyberFOX!" I'm downgrading the bug until you can confirm that this does not work for you. It worked for me as far as I can test.. Romain
Bug#443129: incompatible xorg 7.3 (modules 1.4.0)
Hi ! Le Wednesday 19 September 2007 00:27:55 Encolpe Degoute, vous avez écrit : > Package: fglrx-driver > Version: 8.38.6-2 > Severity: grave > > --- Please enter the report below this line. --- > > This package provides xserver-xorg-video-1.0 that is in conflict with > xserver-xorg-core 1.4-2 > > > With 8.40.4 installed from --buildpkg with ati runner I can get this error: > > (II) LoadModule: "fglrx" > (II) Loading /usr/lib/xorg/modules/drivers//fglrx_drv.so > (II) Module fglrx: vendor="FireGL - ATI Technologies Inc." > compiled for 7.1.0, module version = 8.40.4 > Module class: X.Org Video Driver > ABI class: X.Org Video Driver, version 1.0 > (EE) module ABI major version (1) doesn't match the server's version (2) > (II) UnloadModule: "fglrx" > (II) Unloading /usr/lib/xorg/modules/drivers//fglrx_drv.so > (EE) Failed to load module "fglrx" (module requirement mismatch, 0) > > I suppose that 8.38.6-2 is built against xserver-xorg-core 1.3. This issue is that it provides a virtual package related to old xorg. Even worse, it cannot be fixed here since it's a binary ABI incompatibility, so it needs a new release from upstream. > One other thing: 8.40.4 is built for amd64 architecture and only > fglrx-control is available in this version. Autobuilder didn't do their job so far.. Romain
Bug#443129: incompatible xorg 7.3 (modules 1.4.0)
Le Wednesday 19 September 2007 16:05:59, vous avez écrit : > Did you request autobuilding as in Yes I did. Romain
Bug#443216: impossible to install fglrx-driver due to unmet dependencies.
forcemerge 443129 443216 thanks Hi ! Please try at least to check if your bug is not already listed... Romain Le Wednesday 19 September 2007 20:20:00 Romain JACQUET, vous avez écrit : > Package: fglrx-driver > Version: 8.38.6-2 > Severity: grave > > --- Please enter the report below this line. --- > > The output of the command is: > apt-get install fglrx-driver > Reading package lists... Done > Building dependency tree > Reading state information... Done > Some packages could not be installed. This may mean that you have > requested an impossible situation or if you are using the unstable > distribution that some required packages have not yet been created > or been moved out of Incoming. > > Since you only requested a single operation it is extremely likely that > the package is simply not installable and a bug report against > that package should be filed. > The following information may help to resolve the situation: > > The following packages have unmet dependencies: > fglrx-driver: Depends: xserver-xorg (>= 1:7.1.0) but it is not going > to be installed > E: Broken packages > > > --- System information. --- > Architecture: i386 > Kernel: Linux 2.6.22perso1 > > Debian Release: lenny/sid > 500 unstable ftp.proxad.net > > --- Package information. --- > Depends (Version) | Installed > -+- > libc6 (>= 2.6-1) | 2.6.1-5 > libgcc1 (>= 1:4.2-20070516) | 1:4.2.1-5 > libstdc++5 (>= 1:3.3.4-1) | 1:3.3.6-15 > libx11-6 | 2:1.0.3-7 > libxext6 | 1:1.0.3-2 > libxrandr2 (>= 2:1.2.0) | 2:1.2.2-1 > libxrender1 | 1:0.9.4-1 > xserver-xorg (>= 1:7.1.0) | 1:7.3+2 -- Hours beat, the scene moving right When all on a sudden Bam, bam, bam, a knocking pon the door "Who is dat?", aksed Weston, feeling right "Open up, it's the police, come on, open up" "What address do you want?" "Number 66, come on, open up" Weston, feeling high, replied, "Yes, this is Street 66, step right in and take some licks."
Bug#444495: Same with Kad
Hi ! I've got the same issue when updating KAD's nodes... Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#433141: Quality assurance proposition for HTMLSax3
[Note]: Apologize for the non-english readers... Hi all ! While packaging SPIP for debian, I came across files that where extracted from the PEAR package HTMLSax3 [1] We have had some trouble with them for the following reasons: * Licence headers claim they are un der PHP licence version 2.02 but gives a link to version 3 for details. * A PHP licenced packaged should be distributed only as a php related package, for licencing claims issues. * Only version 3 is accepted, under previous condition. So, we'd like to clarify licence to version 3, which is at least what's claimed as its content, and then package it as a php-* package. We have tried to contact maintainers and filled a bug on PEAR [2], but did not receive any answer. As it seems, the project is not maintained since 2004. I don't know if you do some similar work that our QA does, but until original maitainer speaks up, or we find any candidate to maintain it and if you don't already do this, I'd like to propose some QA maintenance on HTMLSax3. I cannot at all maintain the package, but at least I could clarify licencing and apply any security related patch that could be sumbited. That's basicaly the work that a debian maintainer does for its stable packages. That is not a good solution, but's that the least we can do, since this code is already is some of our packages (gallery, gallery2 and knowledgeroot) and possibly used by many other webapps projects.. Romain [1]: http://pear.php.net/package/XML_HTMLSax3 [2]: http://pear.php.net/bugs/12159 -- If you are the big tree, We are the small axe, Ready to cut you down, Sharpen to cut you down... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#482222: camlp5: FTBFS: Makefile:4: ../config/Makefile: No such file or directory
Le Wednesday 21 May 2008 15:33:30 Lucas Nussbaum, vous avez écrit : > Relevant part: > > make[3]: Entering directory `/build/user/camlp5-5.07/ocaml_stuff' > > Makefile:4: ../config/Makefile: No such file or directory > > make[3]: *** No rule to make target `../config/Makefile'. > > make[3]: Failed to remake makefile `../config/Makefile'. > > if test "" = "../ocaml_stuff/"; then \ > > set -e; \ > > for i in /utils /parsing; do \ > > cd $i; /usr/bin/make clean EXE=; cd ../..; \ > > done; \ > > fi > > make[3]: Leaving directory `/build/user/camlp5-5.07/ocaml_stuff' > > make[2]: *** [clean_hot] Error 2 No, it is: > make[1]: Leaving directory `/build/user/camlp5-5.07' > touch debian/stamp-patched > ./configure -name camlp5 -mandir /usr/share/man > > Sorry: the compatibility with ocaml version "3.10.2" > is not yet implemented. Please report. Which can be safetly ignored, since it will be fixed with next upload... Romain -- The rich man's wealth is his strong city: the destruction of the poor is their poverty. - Proverbs 10:15 The rich man's wealth is in the city Vexation of the soul is vanity Destruction of the poor is their poverty - Peter Tosh, Fools Die -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#483870: [Pkg-fglrx-devel] Bug#483870: [fglrx-kernel-src] Build does not correctly detect kernel headers
severity 483870 important thanks Le Saturday 31 May 2008 15:07:50 Jason Graham, vous avez écrit : > The build fails when trying to build the fglrx kernel module by running > make.sh, because the kernel path is not properly set to the kernel headers. > It is set to the kernel source directory and the required header files are > not present. Ok thanks for the report. I will look at your issue but I don't really understand what you are trying to do. In particular, the recommended way to build the module is to invoke module-assistant: module-assistant -t a-i fglrx Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#501820: [Pkg-fglrx-devel] Bug#501820: fglrx-driver breaks DRI for xserver-xorg-video-radeon
severity 501820 normal tag 501820 wontfix thanks Le Friday 10 October 2008 19:57:50 Felix Homann, vous avez écrit : > Hi, Hi ! > when fglrx-driver is installed DRI is broken for the open source radeon/ati > driver. Here's an excerpt of glxinfo: Yep, this is surely a consequence of the private version of libGL installed by fglrx. Just uninstall it and it should be fixed. Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#501820: [Pkg-fglrx-devel] Bug#501820: fglrx-driver breaks DRI for xserver-xorg-video-radeon
Le Friday 10 October 2008 23:07:34 Felix Homann, vous avez écrit : > Hi Romain, Hi ! > if it's a "wontfix" there should at least be a note about the issue in > the package documentation. > > If it's not mentioned anywhere people who have tried (and thus installed > ) the fglrx driver will think the radeon driver is broken. At least > that's what I thought... Humm... Right, I tagged wontfix since we won't remove the private libGL package. However, this issue could be stated in its description. Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#502959: general: raff.debian.org uses non-free software
Le Tuesday 21 October 2008 13:10:28 Peter Clifton, vous avez écrit : > Having no source-code for firmware is hardly that different to having a > completely open-source driver which does un-told magic by poking > un-documented registers in a complex chip. Think Intel graphics before > they released documentation for (some of) their chips. Agreed, though it does not restrain us from asking for free firmware. If I recall well, one of the origin of the GNU fondation was the fact that having free drivers alowed one to actually *fix* issues he may have with his *own* hardware. Then, the very same reasoning can apply to binary firmware. So, yes this is a brand new issue, that comes from the new way of designing hardware. But that doesn't mean we should give up and remain behind the line that was drawn 20 (or so) years ago. We now should also ask for open source firmware for the very same reason that this huge effort toward free drivers was done. If we did it for drivers, there's no reason we can't suceed for firmwares. Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#502959: general: raff.debian.org uses non-free software
Le Tuesday 21 October 2008 22:28:31 Lennart Sorensen, vous avez écrit : > > If I recall well, one of the origin of the GNU fondation was the fact > > that having free drivers alowed one to actually *fix* issues he may have > > with his *own* hardware. Then, the very same reasoning can apply to > > binary firmware. > > Having driver source code lets you fix the drivers and port htem to > other operating systems and architectures. Having firmware source makes > no difference to that problem as long as the firmware is working. If it > isn't working, you would probably know soon enough and return the > defective hardware. Firmware updates also happen to fix bugs.. Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#393837: More informations..
Hi all !
The issue can be isolated in this line:
window.openDialog('chrome://pippki/content/deletecert.xul', "",
'chrome,centerscreen,modal', params);
in certManager.js.
If you remove this line, and comment the next if, then you simply remove the
confirmation box. Could be a workaround perhaps if nothing better can be
find ?
If you remove from the file delecert.js everything related to gParams, then it
works, but does nothing.
I'm strongly suspecting some sort of javascript failure, related to the
gParams variable, but, as usual, it really lacks a good damn javascript
debugging console.
Romain
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#497042: [Pkg-mediawiki-devel] Bug#497042: mediawiki: populateCategory.php script fails with PostgreSQL
severity 497042 important thanks Le Friday 29 August 2008 15:18:33 Jaume Sabater, vous avez écrit : > Package: mediawiki > Version: 1:1.13.0-1 > Severity: grave > Justification: renders package unusable Well, not really, mysql users and fresh postgresql users can still use the package.. > Using PostgreSQL 8.3.3 and Mediawiki 1.13. Upgraded from Mediawiki 1.12 > to 1.13. Had to execute the populateCategory.php script inside > maintenance due to the changes made by upstream in the software, so that > new category and categorylinks tables are populated. > > When doing so, it fails and leaves the pages plenty of corrupted > information, displaying tons of links/pages that should not be there. > Please note the segmentation fault at the end. The update.php executed > before also ended in a segmentation fault error, but seemed to work > fine. Ok, this issue seems to come from a custom debian patch. Could you try with the original file, attached with this mail ? Romain DatabasePostgres.php Description: application/php
Bug#497543: [Pkg-fglrx-devel] Bug#497543: fglrx-driver: fglrxinfo fails
severity 497543 normal thanks Le Tuesday 02 September 2008 15:08:18 Marcus Lundblad, vous avez écrit : > Package: fglrx-driver > Version: 1:8-7-2 > Severity: grave > Justification: causes non-serious data loss Please don't put grave for this kind of issues, unless it really breaks your system.. I will try to see what I can do for this. Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#485793: [Pkg-fglrx-devel] Bug#485793: fglrx-source: cannot load module: Unknown symbol init_mm
severity 485793 important thanks Le Wednesday 11 June 2008 16:11:16 Mattia Monga, vous avez écrit : > Severity: grave > Justification: renders package unusable Fglrx is working without the module, but without 3D acceleration. > The module is built successfully, but when loaded dmseg reports > > fglrx: module license 'Proprietary. (C) 2002 - ATI Technologies, Starnberg, > GERMANY' taints kernel. fglrx: Unknown symbol init_mm Ok, there is a similar issue, I will try to see what's the problem.. Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#488630: linuxdcpp: Two remote DoS
Le Monday 30 June 2008 09:53:15 Steffen Joeris, vous avez écrit : > The patchsets are not included in the current sid version. CVE ids for both > DoS are pending. > Please also upload with high urgency, so that the package hits testing > soon. Thanks for the report. However, I have an issue with linuxdcpp's licence and SSL link. I have filed a bug upstream months ago, tried to contact the main developper to fix it, but so far, nothing happened. Hence, if this licence issue is not fixed very soon, I will have no choice but to ask for a removal from the archive, at least until this gets fixed. Of course, you can expect a quick upload otherwise. Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#488630: linuxdcpp: Two remote DoS
Le Monday 30 June 2008 11:18:18 Steffen Joeris, vous avez écrit : > > Of course, you can expect a quick upload otherwise. > > Thanks for the information. However, we are still distributing the package > in our archives at the moment. It might be a good idea to fix the issue in > unstable and let it migrate to testing. You can still ask for a removal > later on, which is fine. But in the meanwhile, the fixes are included and > the package would be distributed anyway. If the RC bug is not fixed quickly, the package will automatically be droped from testing. Besides, I don't want to upload again with the SSL issue. First time it was by mistake, now that I'm aware of it, I wouldn't like to do it on purpose. Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#488630: SSL about to be fixed..
Hi ! Steven Sheehy told me he should make SSL compilation optional very soon. Hence, I'll upload a package fixing these bugs very soon, and proceed with SSL later. Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#488630: linuxdcpp: Two remote DoS
Hi ! Le Wednesday 02 July 2008 23:13:52 Moritz Muehlenhoff, vous avez écrit : > > Besides, I don't want to upload again with the SSL issue. First time it > > was by mistake, now that I'm aware of it, I wouldn't like to do it on > > purpose. > > Can you make a separate RC bug about the SSL license issue? The SSL issue was less problematic than expected. In fact, DC++'s original license allows linking against SSL, so linuxdcpp will be relicensed within the next few days as promised by Steven Sheehy. Then I'll update the package immediately. Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#478573: got CVE id
Le Wednesday 30 April 2008 16:41:51 Nico Golde, vous avez écrit : > Hi, Hi ! > CVE-2008-2040 was assigned to that, please mention the CVE > id in the changelog if you fix this bug. Do you have fix by the way ? Romain -- We sick an' tired of-a your ism-skism game - Dyin' 'n' goin' to heaven in-a Jesus' name, Lord. We know when we understand: Almighty God is a living man. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#493718: [Pkg-fglrx-devel] Bug#493718: possible patch
Le Wednesday 06 August 2008 07:46:59 Thomas Bushnell BSG, vous avez écrit : > See http://nopaste.debianforum.de/9635 for what might be a good patch > for this bug. Seems so. However, it doesn't fit the current packaging: firegl_public.c is heavily patched in the package I'll be away until the 11th, so I won't be able to upload it before. If you can help making it work with current packaging, I'll be thankfull. Romain -- Oh what a competition But Jah is mi highest region Rocking trough revelation Chanting to Jah holy nation -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#495371: [Pkg-fglrx-devel] Bug#495371: fglrx-kernel-src: Does not build against 2.6.26
forcemerge 493718 495371 thanks Le Saturday 16 August 2008 22:12:51 Richard Antony Burton, vous avez écrit : > Package: fglrx-kernel-src > Version: 1:8-6-2 > Severity: grave > Justification: renders package unusable Please, try to read existing reports before submiting a new one.. Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#495371: [Pkg-fglrx-devel] Bug#495371: fglrx-kernel-src: Does not build against 2.6.26
Le Saturday 16 August 2008 21:37:13, vous avez écrit : > > Please, try to read existing reports before submiting a new one.. > > I did, and there were no relevant bugs for this package. I didn't > realise the package I was using had become a transitional package. I > will keep this in mind for future reference. No pb. In case you didn't notice it, there is a fixed package available in the SVN [1], only I don't have time to finish the upload for now.. Romain [1]: See: http://svn.debian.org/ and/or svn://svn.debian.org/pkg-fglrx/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#489702: liquidsoap: race condition in playlist operator
Package: liquidsoap Version: 0.3.7-3 Severity: grave Justification: renders package unusable Liquidsoap has an issue with playlists: a race condition in the scheduler may lead to the feeding task not being started anymore. We are working on fixing this quickly. Until then, I submit this bug to prevent the current package from moving to testing. Romain -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF8, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages liquidsoap depends on: ii adduser 3.108add and remove users and groups ii libao2 0.8.8-4 Cross Platform Audio Output Librar ii libasound2 1.0.16-2 ALSA library ii libc6 2.7-12 GNU C Library: Shared libraries ii libcamomile-ocaml-data 0.7.1-3 Unicode data for OCaml ii libgcc1 1:4.3.1-4GCC support library ii libjack00.109.2-3JACK Audio Connection Kit (librari ii libmad0 0.15.1b-3MPEG audio decoder library ii libmagic1 4.24-4 File type determination library us ii libogg0 1.1.3-4 Ogg Bitstream Library ii libpcre37.6-2Perl 5 Compatible Regular Expressi ii libportaudio2 19+svn20071022-2 Portable audio I/O - shared librar ii libsamplerate0 0.1.3-1 audio rate conversion library ii libshout3 2.2.2-4 MP3/Ogg Vorbis broadcast streaming ii libsoundtouch1c21.3.1-2 sound stretching library ii libstdc++6 4.3.1-4 The GNU Standard C++ Library v3 ii libtagc01.5-3TagLib Audio Meta-Data Library (C ii libvorbis0a 1.2.0.dfsg-3.1 The Vorbis General Audio Compressi ii libvorbisenc2 1.2.0.dfsg-3.1 The Vorbis General Audio Compressi ii libvorbisfile3 1.2.0.dfsg-3.1 The Vorbis General Audio Compressi ii wget1.11.4-1 retrieves files from the web Versions of packages liquidsoap recommends: ii logrotate 3.7.1-3Log rotation utility -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#490070: libshout3: fails to send mp3 data
Package: libshout3 Version: 2.2.2-4 Severity: grave Justification: renders package unusable Hi ! Since the latest upload, shout stoped to send mp3 data correctly with liquidsoap. The issue clearly goes away when failling back to 2.2.2-3. I believe the patch applied for bug #358434 was incorrect and lead to this grave issue. I plan to prepare a quick upload if no one's disagree. Romain -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF8, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#492530: jbidwatcher: is this DFSG compatible ?
Le Sunday 27 July 2008 23:18:34 Rémi Letot, vous avez écrit : > Romain Beauxis a écrit : > > Le Saturday 26 July 2008 23:53:06 Rémi Letot, vous avez écrit : > > > > > >> while searching for an ebay tool, I found that : > >> > >> http://www.jbidwatcher.com/commercial_resale.shtml > >> > >> Doesn't that make jbidwatcher non-free ? > >> > > > > Hi ! > > > > I don't think so: > > "As several people have asked, this isn't an addendum to the license" > > > > Yes, that page is not very coherent : > > "If you have a commercial need for a subsection of the program that you > would like to ask about, or if you have a need that you feel the > JBidwatcher code can meet but you'll need to resell it for some reason, > please feel free to contact me <mailto:[EMAIL PROTECTED]>, > and I'll see if my employer and I can work out the legalities in a way > that handles it cleanly." > > I'm not an expert, but IMHO the safe side is non-free, unless we have a > (non debian specific) clarification from the developper. > > Yet the final decision is yours, I won't reopen the bug report myself if > you feel confident about the "freeness" of this package, nor will I > bother you anymore Hi again ! I of course noticed this when preparing the package. Hence, I got at this time a notification from the author that this is indeed not a license restriction, nor debian specific. Now, if you really want a written mail from the author, I could contact him again, but I don't think it's necessary... Romain -- And all the crowd comes in day by day No one stop it in anyway And all the peacemaker turn war officer Hear what I say -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#469857: libmagic-ocaml-dev: native module binary broken
Package: libmagic-ocaml-dev Version: 0.6-3 Severity: grave Tags: patch Justification: renders package unusable Hi ! Latest uploaded package (0.6-2) is currently broken when compiling in native mode. This is due to a mistake in the build sequence. The package is fixed in the svn, if you want to test: svn://svn.debian.org/svn/pkg-ocaml-maint/trunk/packages/ocaml-magic/trunk I'll upload the fixed package when the transition is over.. Romain -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-rc7-mactel (SMP w/2 CPU cores; PREEMPT) Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages libmagic-ocaml-dev depends on: ii libmagic-dev 4.23-2 File type determination library us ii libmagic-ocaml0.6-3 OCaml bindings for the File type d ii ocaml-nox [ocaml-nox-3.10.0] 3.10.0-13 ML language implementation with a libmagic-ocaml-dev recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#473297: so slow its output isn't reproducible
severity 473297 important
thanks
Le Saturday 29 March 2008 21:11:25 Robert Millan, vous avez écrit :
> When I try to broadcast a stream, the output provided by peercast feeds
> data at such a slow rate that it is impossible to reproduce something
> audible from it (I think the average is 10 bytes/s or so).
>
> While this happens, the peercast processes isn't taking any significant
> share of the cpu, or the bandwidth. A strace reveals that it is repeatedly
> calling nanosleep({1, 0}, NULL).
>
> I reproduced the same behaviour on two very different systems:
>
> - amd64 with 2 cpu cores, behind a firewall/NAT (but with tcp7144 being
> forwarded).
> - i386 with 1 cpu core and no firewall/NAT.
>
> The stream I used for my tests:
>
> http://vorbis.nm.cbc.ca:80/cbcr1-toronto.ogg
Yes, indeed, I have had troubles too with peercast.
I'll try to dig more on this issue.
Romain
--
We should really love each other
In peace and harmony
Instead, instead, we're fussing and fighting
Like we ain't supposed to be, tell me why
Bug#475007: [Pkg-fglrx-devel] Bug#475007: fglrx-glx: clashing diversions
severity 475007 important thanks Hi ! Le Tuesday 08 April 2008 13:40:34 Carl Fürstenberg, vous avez écrit : > When trying to install fglrx-glx, it borks on clashing diversion with > fglrx-driver. Following output is shown: Hummm Can you tell me exactly what was the state before you installed fglrx-glx ? As you can see, the clashing diversion should have been removed prior to adding the new one, so I'm wondering wether there could be an issue on your side.. Indeed, the script has been designed in order to work independently: it first looks for all possible diversions owned by fglrx like modules on /usr/lib/libGL.so.1.2, removes them and adds its own.. So far I couldn't find issues on my tests, so I would need more informations from your side before I can fix. Setting severity to important until then.. Romain -- Blessed is the man that walketh not in the counsel of the ungodly, nor standeth in the way of sinners, nor sitteth in the seat of the scornful. - Psalm 1:1
Bug#474895: gst-plugins-good0.10: FTBFS: libtool: link: `/usr/lib/libspeex.la' is not a valid libtool archive
Hi ! > > Relevant part: > > > ar cru .libs/libgstshout2.a libgstshout2_la-gstshout2.o > > > ranlib .libs/libgstshout2.a > > > creating libgstshout2.la > > > /bin/sed: can't read /usr/lib/libspeex.la: No such file or directory > > > libtool: link: `/usr/lib/libspeex.la' is not a valid libtool archive > > > make[4]: *** [libgstshout2.la] Error 1 > > That's a bug in libshout: It's .la file references the libspeex .la file > which does not exist anymore in the new version. A binNMU or sourceful > upload should fix this: reassigning. Can you explain me more about the issue, I don't understand why a rebuild can fix it.. ? Romain -- How many river do we have to cross, Before we can talk to the boss? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#476027: ocaml-shout: FTBFS: make[3]: *** No rule to make target `Makefile.shoutfile'. Stop.
Le Monday 14 April 2008 12:24:28 Lucas Nussbaum, vous avez écrit :
> This rebuild was done with gcc 4.3 instead of gcc 4.2, because gcc 4.3 is
> now the default on most architectures (even if it's not the case on i386
> yet). Feel free to downgrade this bug to 'important' if your package is
> only built on i386, and this bug is specific to gcc 4.3 (i.e the package
> builds fine with gcc 4.2).
>
> Relevant part:
> > make[3]: Entering directory `/build/user/ocaml-shout-0.2.5/examples'
> > make[3]: Makefile.shoutfile: No such file or directory
> > make[3]: *** No rule to make target `Makefile.shoutfile'. Stop.
> > make[3]: Leaving directory `/build/user/ocaml-shout-0.2.5/examples'
> > make[2]: *** [clean-shoutfile] Error 2
No, this is not, the relevant part is:
> ./configure --host=i486-linux-gnu --build=i486-linux-gnu --prefix=/usr
> --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info configuring
> ocaml-shout 0.2.5
> checking for ocamlc... /usr/bin/ocamlc
> ocaml version is 3.10.1
> ocaml library path is /usr/lib/ocaml/3.10.1
> checking for ocamlopt... /usr/bin/ocamlopt
> checking ocamlopt version... ok
> checking for ocamlc.opt... no
> checking for ocamlopt.opt... no
> checking for ocamldep... /usr/bin/ocamldep
> checking for ocamllex... /usr/bin/ocamllex
> checking for ocamlyacc... /usr/bin/ocamlyacc
> checking for ocamldoc... /usr/bin/ocamldoc
> checking for ocamlmktop... /usr/bin/ocamlmktop
> checking for i486-linux-gnu-gcc... i486-linux-gnu-gcc
> checking for C compiler default output file name...
> configure: error: C compiler cannot create executables
So, exactly the same as the dozen of other serious report we just get.
Now, for the issue itself, I'm pretty surprised since it seems to fail in
something that is not really relevant for either the package or the software,
the configure script.
We rely on general and external functions, so there are two possibilities:
(1) We need to regenerated those scripts
(2) There is something broken between configure and gcc 4.3
(3) There was something broken in your build configuration.
I tend to think it would have been more clever to find out if (2) oe (3) is
the culprit, since all the reports would not be in the good place in this
case.
I'll try to look at this.
Romain
--
Could not recognize the faces standing over me;
They were all dressed in uniforms of brutality.
Bug#476154: subversion: https urls broken
Package: subversion Version: 1.4.6dfsg1-2 Severity: grave Justification: renders package unusable Hi ! As it seems, the latest NMU broke https urls: > 20:19 [EMAIL PROTECTED] ~/sources/svn/savonet/trunk/ocaml-alsa% LANG=C svn up > svn: Unrecognized URL scheme for > 'https://savonet.svn.sourceforge.net/svnroot/savonet/trunk/ocaml-alsa' > zsh: exit 1 LANG=C svn up The issue clearly goes away when installed the previous version (1.4.6dfsg1-2) I don't know if the issue is from subversion or libsvn1, so setting it there for now.. Romain -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-rc7-mactel (SMP w/2 CPU cores; PREEMPT) Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages subversion depends on: ii libapr1 1.2.12-1 The Apache Portable Runtime Librar ii libc6 2.7-10 GNU C Library: Shared libraries ii libsvn1 1.4.6dfsg1-2 Shared libraries used by Subversio subversion recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#504279: ebay changes break jbidwatcher for most german auctions
Hi ! Le Sunday 02 November 2008 12:59:08 Erich Schubert, vous avez écrit : > Just from what I figured from the forums. > Upstream is already working on that, but for the 2.0 versions. Yes, I came to that conclusion. However, the only solution that I find is to ask for a removal jbidwatcher from lenny since it's almost sure that the current package will not be usable at all.. Unless there is another solution, I'll do this move within the next days.. Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503878: fglrx-atieventsd: authatieventsd.sh uses finger without depending on it and is unreliable
Le Tuesday 04 November 2008 06:56:33 Mark Purcell, vous avez écrit : > On Wednesday 29 October 2008 10:16:21 Luca Niccoli wrote: > > I've attached the modified script, to be diffed against the upstream one. > > Romain & Bertrand, Hi ! > This RC bug effecting lenny, with a patch, has been sitting without a > response for a week. > > Are you in a position to prepare a fixed package? I will try to prepare a fixed package as soon as possible, which means at least this week end. Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503878: [Pkg-fglrx-devel] Bug#503878: fglrx-atieventsd: authatieventsd.sh uses finger without depending on it and is unreliable
Le Tuesday 04 November 2008 16:15:18 Bertrand Marc, vous avez écrit : > Hi! Hi ! > I just sent a new version to the svn with a reasonable changelog (based > on #500077) and the patch for atienventsd. I think it is ready to upload > to unstable, but I can't test it as I don't have a ATI card anymore... Problem is that even though we could have considered asking for a testing update from sid since fglrx is crappy in any version, I don't know wether it is reasonable now, since it would need some decent testing. The plan could be to fix the package in lenny, as well as uploading a new package for sid, wait for the bugs to come, and if it is still possible, consider proposing an update. The issue is that it is quite hard for me to test the hardware now. Actually, I don't plan on continuing the maintenance of this package after lenny is released. Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#504445: Reported..
Just for the record: I have contacted upstream about this issue and am waiting for his answer. Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#504279: Wodering..
Hi ! After some discussion with upstream, it appears that the issue cannot be fixed for the version currently in testing. I'm now with two alternatives: * Ask for a removal of the package * Excplicitely mark jbidwatcher as "US only". What do users think about these two alternatives ? Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#504279: Wodering..
Le Thursday 06 November 2008 22:25:13 Moritz Muehlenhoff, vous avez écrit : > > What do users think about these two alternatives ? > > jbidwatcher will likely break for the US ebay page at some point > in time as well once Ebay changes their website the next time. > > I'd recommend to remove it from Lenny and provide jbidwatcher > through volatile.debian.org only. Agreed, I didn't think of volatile, it indeed perfectly fits, thanks. I'll make the move very soon. Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503878: [Pkg-fglrx-devel] Bug#503878: fglrx-atieventsd: authatieventsd.sh uses finger without depending on it and is unreliable
Le Saturday 08 November 2008 11:51:25 Adeodato Simó, vous avez écrit : > I don't think a new upstream version is going to be appropriate, but we > can talk about it later when this bug is fixed in Lenny. I don't like > the idea of uploading the fix together with this new version, which > means that if the new version is not suitable, the fix for this bug will > have to go via testing-proposed-updates, which doesn't get any user > testing at all. Done and uploaded in 1:8-7-3. Changes are minimal, so you can consider this version for a testing update if everything goes fine. Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#504279: Wodering..
Le Thursday 06 November 2008 23:50:02 Romain Beauxis, vous avez écrit : > > I'd recommend to remove it from Lenny and provide jbidwatcher > > through volatile.debian.org only. > > Agreed, I didn't think of volatile, it indeed perfectly fits, thanks. > > I'll make the move very soon. Done in #505030 Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#508860: mediawiki: several security issues, help wanted !
Package: mediawiki Severity: grave Tags: security Justification: user security hole Hi all ! Several security issues have unfortunately been noticed [1] in mediawiki that may affect for some any version of the software. Unfortunately too, I will most likely be overhelmed during the next few months. As a consequence, any help is much desired on this issue. That package is SVN maintained so it shouldn't be difficult for any interested contributor. Romain [1]: http://lists.wikimedia.org/pipermail/mediawiki-announce/2008-December/80.html -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF8, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#508869: [Pkg-mediawiki-devel] Bug#508869: fixed in mediawiki 1:1.13.3-1
Le Monday 12 January 2009 07:51:54 Luk Claes, vous avez écrit : > Hi Hi ! > This 'security' update was uploaded to unstable, but seems to be still > outstanding for testing. Unblocking the version from unstable doesn't > seem to be an option: > > 1130 files changed, 253693 insertions(+), 131172 deletions(-) Yes. Unstable version is new. > Can an upload be prepared with targeted fixes for the security issues? It can, it is not difficult, there is a security-fix patch upstream. The main problem is that this patch is huge and includes new stuff and does not ony fix existing stuff. The solution is to apply the security patch and have it reviewed and accepted by the security team. However, I am way too busy these days to handle this. I have mentioned this in my original bug report (#508860) wich was later closed in favour of two more detailed ones. I have also contacted the security team but didn't get any feedbacks. I know they are busy, of course. The two issues should be quite easy to handle for any interested contributor looking at this message. Romain -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#508870: [Pkg-mediawiki-devel] Bug#508870: mediawiki: NMU to fix CVE-2008-5249, CVE-2008-5250, CVE-2008-5252
Le Sunday 18 January 2009 12:17:01 Giuseppe Iuculano, vous avez écrit : > Hi, Hi ! > the attacked debdiff is for a proposed NMU to fix CVE-2008-5249, > CVE-2008-5250, CVE-2008-5252 in lenny. (Backported from mediawiki 1.12.3) Many thanks for this patch and your work ! I have build a fixed package and tested it, it works ok. Also, the changes looks clean from the packaging point. However, I won't comment on the content of the patch, I don't have enough time for that. I hope someone else can help reviewing it. Romain > mediawiki (1:1.12.0-2lenny2) testing-security; urgency=high > > * Security update, NMU to fix fix CVE-2008-5249, CVE-2008-5250, > CVE-2008-5252 * > debian/patches/CVE-2008-5249_CVE-2008-5250_CVE-2008-5252.patch: - Fixed > output escaping for reporting of non-MediaWiki exceptions. Potential XSS if > an extension throws one of these with user input. - Avoid fatal error in > profileinfo.php when not configured. > - Fixed CSRF vulnerability in Special:Import. Fixed input validation in > transwiki import feature. > - Add a .htaccess to deleted images directory for additional protection > against exposure of deleted files with known SHA-1 hashes on default > installations. > - Fixed XSS vulnerability for Internet Explorer clients, via file > uploads which are interpreted by IE as HTML. > - Fixed XSS vulnerability for clients with SVG scripting, on wikis > where SVG uploads are enabled. Firefox 1.5+ is affected. > - Avoid streaming uploaded files to the user via index.php. This allows > security-conscious users to serve uploaded files via a different > domain, and thus client-side scripts executed from that domain cannot > access the login cookies. Affects Special:Undelete, img_auth.php and > thumb.php. - When streaming files via index.php, use the MIME type detected > from the file extension, not from the data. This reduces the XSS attack > surface. - Blacklist redirects via Special:Filepath. Such redirects > exacerbate any XSS vulnerabilities involving uploads of files containing > scripts. Closes: #508869, #508870 > > -- Giuseppe Iuculano Sun, 18 Jan 2009 11:54:02 > +0100 > > > > > Cheers, > Giuseppe -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#525328: [Pkg-fglrx-devel] Bug#525328: fglrx-driver: Installation failed and leave the system in an unusable state
Le Thursday 23 April 2009 14:23:59 Encolpe DEGOUTE, vous avez écrit : > Hello, Hi ! > When I'm trying to install this new release the installation never ended: > > Unpacking fglrx-driver (from .../fglrx-driver_1%3a9-4-1_i386.deb) ... > Leaving `diversion of /usr/lib/xorg/modules/extensions/libdri.so to > /usr/lib/fglrx/diversions/libdri.so by fglrx-driver' Adding `diversion of > /usr/lib/xorg/modules/extensions/libglx.so to > /usr/lib/fglrx/diversions/libglx.so by fglrx-driver' dpkg-divert: rename > involves overwriting `/usr/lib/fglrx/diversions/libglx.so' with different > file `/usr/lib/xorg/modules/extensions/libglx.so', not allowed dpkg: error > processing /var/cache/apt/archives/fglrx-driver_1%3a9-4-1_i386.deb > (--unpack): subprocess pre-installation script returned error exit status 2 What version are you upgrading from ? Romain -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#525328: [Pkg-fglrx-devel] Bug#525328: Bug#525328: fglrx-driver: Installation failed and leave the system in an unusable state
Le Friday 24 April 2009 08:55:28 Encolpe Degoute, vous avez écrit : > > After a reboot the 'dpkg-divert --list' doesn't list any diversion on > > /usr/lib/xorg/modules/extensions/* > > > > If I move the file /usr/lib/fglrx/diversions/libglx.so the installation > ends correctly. > Like this 9.4 driver dropped the support of my Radeon Mobility X1400 > card I will stop to test it. I fail to see how this file can exist if you are installing and not upgrading... Romain -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#537634: [Pkg-mediawiki-devel] Bug#537634: intent to NMU
Le dimanche 26 juillet 2009 18:12:24, Nico Golde a écrit : > Hi, Hi ! > intent to upload a 0-day NMU to fix this bug. > > Patch available on: > http://people.debian.org/~nion/nmu-diff/mediawiki-1.15.0-1_1.15.0-1.1.patch Ok, thanks. I am very busy these days... Romain -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#540735: Almost there !
Hi ! With the above links, I have the following messages in the console: Traceback (most recent call last): File "/usr/share/kde4/apps/system-config-printer-kde/system-config-printer- kde.py", line 68, in from cupsutils import cupshelpers, options ImportError: cannot import name options The windows appear but it tells that there was something going wrong. Nice to see some progress, however :-) Romain -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#514547: mediawiki: new upstream release, fixes security issues in the installer
Package: mediawiki
Version: 1:1.12.0-2lenny3
Severity: grave
Tags: security
Justification: user security hole
Hi all !
A new upstream release of mediawiki was done in order to fix security
issues in the installer:
"This is a security release of 1.13.4, 1.12.4 and 1.6.12.
A number of cross-site scripting (XSS) security vulnerabilities were
discovered in the web-based installer (config/index.php). These vulnerabilities
all
require a live installer -- once the installer has been used to
install a wiki, it is deactivated.
Note that cross-site scripting vulnerabilities can be used to attack
any website in the same cookie domain. So if you have an uninstalled copy of
MediaWiki on the same site as an active web service, MediaWiki could be used to
attack the active service.
If you are hosting an old copy of MediaWiki that you have never
installed, we advise you to remove it from the web.
Additionally, we are releasing 1.14.0rc1, the first release candidate
of the 2009 Q1 branch. Brave souls are encouraged to download it and
try it out.
Note that we have disabled SQLite installation in 1.14, due to the
incompleteness of the implementation. We intend to restore it in 1.15.
We're not sure how many people are using SQLite, so contact us if our
treatment of it is causing you problems."
I have already imported the patch in the lenny/ branch on the SVN[1], but I
have absolutely
no time to do serious testings, so any interested contributor would be much
welcome :)
Romain
[1]: svn{+ssh}://svn.debian.org/svn/pkg-mediawiki/mediawiki/lenny
-- System Information:
Debian Release: 5.0
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF8, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages mediawiki depends on:
ii apache2-mpm-worker [httpd 2.2.11-1 Apache HTTP Server - high speed th
ii debconf [debconf-2.0] 1.5.24 Debian configuration management sy
ii mime-support 3.44-1 MIME files 'mime.types' & 'mailcap
ii php5 5.2.6.dfsg.1-2 server-side, HTML-embedded scripti
ii php5-mysql5.2.6.dfsg.1-2 MySQL module for php5
Versions of packages mediawiki recommends:
ii mysql-server-5.0 [mysql-s 5.0.67-1 MySQL database server binaries
ii php5-cli 5.2.6.dfsg.1-2 command-line interpreter for the p
Versions of packages mediawiki suggests:
pn clamav (no description available)
ii imagemagick 7:6.3.7.9.dfsg1-2.1+lenny1 image manipulation programs
pn mediawiki-mat (no description available)
pn memcached (no description available)
-- debconf information:
mediawiki/webserver: apache2
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#518589: ocaml-xmlplaylist_0.1.1-3(mips/unstable): FTBFS on mips
Hi ! Le Saturday 07 March 2009 11:50:57 Peter De Schrijver, vous avez écrit : > Package: ocaml-xmlplaylist > Version: 0.1.1-3 > Severity: serious > > There was an error while trying to autobuild your package: (...) > > dh_install -plibxmlplaylist-ocaml-dev > > dh_install: libxmlplaylist-ocaml-dev missing files > > (/usr/lib/ocaml/3.11.0/xmlplaylist/*.a), aborting make: *** > > [binary-install/libxmlplaylist-ocaml-dev] Error 1 Thanks for the report. The issue is trigered because this architecture does not have a native compiler, hence the build does not generate any *.a file. However, I have seen this problem before and I never really understood the behaviour of dh_install with this. In particular, it used to work, like for ocaml-lastfm: https://buildd.debian.org/fetch.cgi?&pkg=ocaml-lastfm&ver=0.1.3-1&arch=mips&stamp=1221672104&file=log In this build, no *.a file are generated, however dh_install doesn't fail. The liblastfm-ocaml-dev.install file is the same as libxmlplaylist-ocaml-dev.install for this issue: they both list *.a in the files to install. Was there any kind of change in the behaviour of dh_install ? Romain -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
