Bug#899318: virtualbox: FTBFS: vboxssdt-standard.hex:16:23: error: expected initializer before '-' token
On Fri, May 25, 2018 at 07:07:53AM +0900, Mattia Dongili wrote: [...] > Gianfranco, > if you need a work-around, changing the file prefix to something that is > a legal C identifier might help. Gianfranco, so are you going to patch virtualbox? In terms of severity, I think this bug against acpica-unix should be "Important" rather than "Serious". Thanks -- mattia :wq!
Bug#899318: virtualbox: FTBFS: vboxssdt-standard.hex:16:23: error: expected initializer before '-' token
On Thu, May 24, 2018 at 06:33:45AM +0900, Mattia Dongili wrote: > On Wed, May 23, 2018 at 02:56:55PM +0200, Gianfranco Costamagna wrote: > > control: reassign -1 src:acpica-unix > > control: found -1 20180508-1 > > control: affects -1 virtualbox > > > > On Tue, 22 May 2018 19:12:32 +0200 Emilio Pozuelo Monfort > > wrote: > > > Package: virtualbox > > > Version: 5.2.12-dfsg-1 > > > Severity: serious > > > > > > virtualbox fails to build on a clean sid chroot here: > > > > > > In file included from > > > /build/virtualbox-5.2.12-dfsg/src/VBox/Devices/PC/ACPI/VBoxAcpi.cpp:45:0: > > > /build/virtualbox-5.2.12-dfsg/out/obj/VBoxDD/vboxssdt-standard.hex:16:23: > > > error: expected initializer before '-' token > > > unsigned char vboxssdt-standard_aml_code[] = > > >^ > > > /build/virtualbox-5.2.12-dfsg/src/VBox/Devices/PC/ACPI/VBoxAcpi.cpp: In > > > function 'int acpiPrepareDsdt(PPDMDEVINS, void**, size_t*)': > > > /build/virtualbox-5.2.12-dfsg/src/VBox/Devices/PC/ACPI/VBoxAcpi.cpp:371:32: > > > error: 'AmlCode' was not declared in this scope > > > cbAmlCodeDsdt = sizeof(AmlCode); > > > ^~~ > > > /build/virtualbox-5.2.12-dfsg/src/VBox/Devices/PC/ACPI/VBoxAcpi.cpp: In > > > function 'int acpiPrepareSsdt(PPDMDEVINS, void**, size_t*)': > > > /build/virtualbox-5.2.12-dfsg/src/VBox/Devices/PC/ACPI/VBoxAcpi.cpp:423:30: > > > error: 'AmlCodeSsdtCpuHotPlug' was not declared in this scope > > > pabAmlCode = AmlCodeSsdtCpuHotPlug; > > > ^ > > > /build/virtualbox-5.2.12-dfsg/src/VBox/Devices/PC/ACPI/VBoxAcpi.cpp:428:30: > > > error: 'AmlCodeSsdtStandard' was not declared in this scope > > > pabAmlCode = AmlCodeSsdtStandard; > > > ^~~ > > > kmk: *** [/usr/share/kBuild/footer-pass2-compiling-targets.kmk:226: > > > /build/virtualbox-5.2.12-dfsg/out/obj/VBoxDD/PC/ACPI/VBoxAcpi.o] Error 1 > > For the record, the DSL files are here: > https://salsa.debian.org/pkg-virtualbox-team/virtualbox/tree/master/src/VBox/Devices/PC > > and are compiled and post-processed as: > https://salsa.debian.org/pkg-virtualbox-team/virtualbox/blob/master/src/VBox/Devices/Makefile.kmk#L829-857 So, apparently upstream is aware of this. See comments on https://github.com/acpica/acpica/commit/f9a88a4c1cd020b6a5475d63b29626852a0b5f37#diff-95e84a7c99c268ce5433dea47cf17ec0 Gianfranco, if you need a work-around, changing the file prefix to something that is a legal C identifier might help. Either way, unless the offending change is not backed out (as Bob suggested in the discussion I linked), the "AmlCode" identifier is gone for good, so things like $(QUIET)$(SED) -e "s/AmlCode/AmlCodeSsdtStandard/g" \ $(QUIET)$(SED) -e "s/AmlCode/AmlCodeSsdtCpuHotPlug/g" \ won't work. -- mattia :wq!
Bug#899318: virtualbox: FTBFS: vboxssdt-standard.hex:16:23: error: expected initializer before '-' token
On Wed, May 23, 2018 at 02:56:55PM +0200, Gianfranco Costamagna wrote: > control: reassign -1 src:acpica-unix > control: found -1 20180508-1 > control: affects -1 virtualbox > > On Tue, 22 May 2018 19:12:32 +0200 Emilio Pozuelo Monfort > wrote: > > Package: virtualbox > > Version: 5.2.12-dfsg-1 > > Severity: serious > > > > virtualbox fails to build on a clean sid chroot here: > > > > In file included from > > /build/virtualbox-5.2.12-dfsg/src/VBox/Devices/PC/ACPI/VBoxAcpi.cpp:45:0: > > /build/virtualbox-5.2.12-dfsg/out/obj/VBoxDD/vboxssdt-standard.hex:16:23: > > error: expected initializer before '-' token > > unsigned char vboxssdt-standard_aml_code[] = > >^ > > /build/virtualbox-5.2.12-dfsg/src/VBox/Devices/PC/ACPI/VBoxAcpi.cpp: In > > function 'int acpiPrepareDsdt(PPDMDEVINS, void**, size_t*)': > > /build/virtualbox-5.2.12-dfsg/src/VBox/Devices/PC/ACPI/VBoxAcpi.cpp:371:32: > > error: 'AmlCode' was not declared in this scope > > cbAmlCodeDsdt = sizeof(AmlCode); > > ^~~ > > /build/virtualbox-5.2.12-dfsg/src/VBox/Devices/PC/ACPI/VBoxAcpi.cpp: In > > function 'int acpiPrepareSsdt(PPDMDEVINS, void**, size_t*)': > > /build/virtualbox-5.2.12-dfsg/src/VBox/Devices/PC/ACPI/VBoxAcpi.cpp:423:30: > > error: 'AmlCodeSsdtCpuHotPlug' was not declared in this scope > > pabAmlCode = AmlCodeSsdtCpuHotPlug; > > ^ > > /build/virtualbox-5.2.12-dfsg/src/VBox/Devices/PC/ACPI/VBoxAcpi.cpp:428:30: > > error: 'AmlCodeSsdtStandard' was not declared in this scope > > pabAmlCode = AmlCodeSsdtStandard; > > ^~~ > > kmk: *** [/usr/share/kBuild/footer-pass2-compiling-targets.kmk:226: > > /build/virtualbox-5.2.12-dfsg/out/obj/VBoxDD/PC/ACPI/VBoxAcpi.o] Error 1 For the record, the DSL files are here: https://salsa.debian.org/pkg-virtualbox-team/virtualbox/tree/master/src/VBox/Devices/PC and are compiled and post-processed as: https://salsa.debian.org/pkg-virtualbox-team/virtualbox/blob/master/src/VBox/Devices/Makefile.kmk#L829-857 -- mattia :wq!
Bug#857126: cpufrequtils: Fails to install/upgrade (syntax error in init script)
On Sat, Mar 11, 2017 at 05:06:39PM +0100, Sebastian Humenda wrote: > Hi Hi, it looks like we almost overlapped in our replies. > Andreas Henriksson schrieb am 08.03.2017, 21:55 +0100: > >On Wed, Mar 08, 2017 at 10:57:38AM +0100, Sebastian Humenda wrote: ... > >> Mar 08 10:54:47 kraftkrust cpufrequtils[13461]: /etc/init.d/cpufrequtils: > >> 3: /etc/default/cpufrequtils: Syntax error: Unterminated quoted string ... > >Could you please attach your /etc/init.d/cpufrequtils ? Do you know > >if this file was ever modified by you or not? > It is attached. It has not been modified by me, especially I have just purged > it > and the issue persists. Just to reiterate, it's /etc/default/cpufrequtils that has an unterminated quoted string, not /etc/init.d/cpufrequtils. Could you check that? Thanks -- mattia :wq! signature.asc Description: PGP signature
Bug#857126: cpufrequtils: Fails to install/upgrade (syntax error in init script)
On Wed, Mar 08, 2017 at 09:55:02PM +0100, Andreas Henriksson wrote: > Control: tags -1 + moreinfo > > Hello Sebastian Humenda, > > Thanks for your bug report > > On Wed, Mar 08, 2017 at 10:57:38AM +0100, Sebastian Humenda wrote: > > Package: cpufrequtils > > Version: 008-1+b1 > > Severity: grave > > Justification: renders package unusable > [...] > > Mar 08 10:54:47 kraftkrust cpufrequtils[13461]: /etc/init.d/cpufrequtils: > > 3: /etc/default/cpufrequtils: Syntax error: Unterminated quoted string > [...] > > The /etc/init.d/cpufrequtils file is not shipped in the package since > cpufrequtils 002-2.1 (a very long time ago, prior to old-old-stable). as the error suggests, the unterminated string is in /etc/default/cpufrequtils rather than in the init script. /etc/init.d/cpufrequtils sources the defaults file, so that too has to be correctly parseable by /bin/sh. if [ -f /etc/default/cpufrequtils ] ; then . /etc/default/cpufrequtils fi /etc/default/cpufrequtils is not a file managed by the package. Sebastian, Let me know if you need help writing the defaults file. I'm closing this bug report. -- mattia :wq!
Bug#840852: please make libcpupower-dev depend on libcpupower1 (= ${binary:Version})
tags 840852 + patch
thanks
Ben,
On Sat, Oct 15, 2016 at 06:13:55PM +0300, Vlad Orlov wrote:
...
> Please make libcpupower-dev depend on libcpupower1 (= ${binary:Version}),
> like it's usually done with all the other -dev packages.
I realize the patch is trivial, but anyway here's one that is build
tested and working.
Regards
--
mattia
:wq!
commit 8cee65c3229f5f692ad97df9bca117ef194c9ac7
Author: Mattia Dongili
Date: Sun Oct 16 18:08:41 2016 -0700
libcpufreq-dev depends on its corresponding binary package
Closes: #840852
Signed-off-by: Mattia Dongili
diff --git a/debian/changelog b/debian/changelog
index 995c950..eef97ea 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -32,6 +32,10 @@ linux (4.8.1-1~exp1) UNRELEASED; urgency=medium
* [arm64] Enable SERIAL_8250_EXTENDED, SERIAL_8250_SHARE_IRQ and
SERIAL_8250_BCM2835AUX, needed for Raspberry Pi 3.
+ [ Mattia Dongili ]
+ * make libcpufreq-dev depend on its corresponding binary package
+(Closes: #840852)
+
-- Ben Hutchings Sat, 01 Oct 2016 21:51:33 +0100
linux (4.8~rc8-1~exp1) experimental; urgency=medium
diff --git a/debian/templates/control.tools.in b/debian/templates/control.tools.in
index 7c95172..e9318e3 100644
--- a/debian/templates/control.tools.in
+++ b/debian/templates/control.tools.in
@@ -31,7 +31,7 @@ Package: libcpupower-dev
Build-Profiles:
Section: libdevel
Architecture: linux-any
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: libcpupower1 (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends}
Provides: libcpufreq-dev
Conflicts: libcpufreq-dev
Replaces: libcpufreq-dev
Bug#817708: uml-utilities marked for removal
On Tue, Jul 12, 2016 at 06:29:14PM +0200, Ritesh Raj Sarraf wrote: ... > PS: And I just noticed you did some work with uml-utilities. Thanks. Yes, I'm trying to upload a new revision. -- mattia :wq!
Bug#817708: uml-utilities marked for removal
On Tue, Jul 05, 2016 at 05:58:58PM +0200, Ritesh Raj Sarraf wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hi, > > As per the tracker, uml-utilities is marked for removal from the archive on > the > 19th of July. > https://tracker.debian.org/pkg/uml-utilities > > > Are there any plans for fixing it ? No. At the moment it doesn't make much sense to keep uml-utilities in the archive. Even if/when UML is re-added, it should be considered whether uml-utilities are all that useful. > PS: I'm trying to bring back user-mode-linux back into the archive. So any > help > on retaining uml-utilities in the archive will be nice. Thanks for doing that. I'd like to say that I'm trying too, but effectively I have a lot of ideas but very little time to go after them. Specifically, the biggest problem I had with the previous packaging was that it required too much maintenance burden. UML should be one of the artifacts created by the regular Debian kernel builds. -- mattia :wq!
Bug#742016: user-mode-linux: build-depends on linux-source-3.12 which is no longer in the archive
On Tue, Apr 15, 2014 at 07:44:08PM +0200, Jakub Wilk wrote: > * Jakub Wilk , 2014-04-15, 15:39: > >The package builds successfully and seems to work on i386. I'll test on > >amd64 later. > > It works on amd64 works, too. :) > > Would it be okay if I NMUed the package? sure, without any delay would be great. Please, make sure this bug report has the latest patch so that I can import it in the git repository. Thanks a lot for your help! -- mattia :wq! -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#742016: user-mode-linux: build-depends on linux-source-3.12 which is no longer in the archive
On Mon, Apr 14, 2014 at 09:48:01PM +0200, Jakub Wilk wrote:
> * Ansgar Burchardt , 2014-03-18, 12:04:
> >user-mode-linux build-depends on linux-source-3.12 which is no longer in
> >the archive. The current version is linux-source-3.13.
>
> Any news on this? Do you need help?
Yes, at the moment I'm busy and cannot work on this (I might in the next
two weeks though). And unfortunately I'm the only "active" maintainer in
the team.
Updating the user-mode-linux package is just a matter of setting the
correct version in debian/{rules,control}, updating the kernel
configuration (there are debian/rules targets to help with that -
oldconfig{32,64} - policy is M for everything) and building the package.
If there are no major issues, this is it.
Let me know if you can help. Else I can try towards the weekend.
Thanks
--
mattia
:wq!
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#741075: user-mode-linux: Occasional memory corruption on startup under high load
On Sat, Mar 08, 2014 at 07:04:56AM +, Anton Ivanov wrote: > Package: user-mode-linux > Version: 3.2-2um-1+deb7u2+b1 > Severity: grave > Tags: patch > Justification: causes non-serious data loss > > Dear Maintainer, > > This bug is perennial. If we go through old bugs with > "cannot reproduce" tag 50% of them are this one, the other > 50% are the "you should not use pipe for interprocess IPC" > which we will submit shortly. > > Manifestation of the problem - UML dies on startup for no > reason with a memory corruption message. Occurs only on > heavily loaded systems and usually when running a lot of > UMLs. Thanks for the patch. I have noticed that you submitted these patch-set (together with the other two you sent here and more) upstream and they will be in the stable branch. The easiest path here is also to go through the stable release of linux-source where uml is built from. I'll keep an eye on the stable tree but it'd be very helpful if you could add the stable tree commit ids once the patches get included. Same story for the other two bugs. Thanks! -- mattia :wq! -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#712234: user-mode-linux: build-depends on linux-source-3.2
On Sun, Oct 20, 2013 at 12:15:59PM +0200, Ansgar Burchardt wrote: > Ansgar Burchardt writes: > > Ansgar Burchardt writes: > >> user-mode-linux build-depends on linux-source-3.2 which is no longer > >> available in unstable. > > > > That's still the case. And user-mode-linux in testing/unstable now seems > > to get security updates via stable as well... > > > > user-mode-linux | 3.2-2um-1+deb7u1 | unstable | source, amd64, i386 > > And nothing has changed so far, except more updates to testing/unstable > that arrived via stable: > > user-mode-linux |3.2-2um-1+deb7u2 | unstable | source > user-mode-linux | 3.2-2um-1+deb7u2+b1 | unstable | amd64, i386 > > I'm considering to request removal as the package doesn't seem to be > maintained any longer. There are three reverse dependencies that would Apologies for the delay, I just uploaded a package based on 3.11. Unfortunatly the way UML is built right now is far from ideal as it's a separate package from linux-image and friends and so it's a lot of chasing and rebuilding. Trying to integrate the package with the debian kernel build system requires time that I currently don't have. -- mattia :wq! -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#700169: non-free license: requires to obey US export regulation even, when not in the US
On Thu, Mar 28, 2013 at 02:17:18PM +0100, Michael Stapelberg wrote: ... > Can we just ignore this bug for wheezy? To me, the licensing intention > seems very clear. Can it be closed even? I don't think this bug applies at all. -- mattia :wq! -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#700169: non-free license: requires to obey US export regulation even, when not in the US
On Wed, Mar 27, 2013 at 05:06:35PM +, Adam D. Barratt wrote: > On 27.03.2013 13:44, Michael Stapelberg wrote: > >Mattia Dongili writes: > >>yes it is, that's what Al did already: > >>http://ftp-master.debian.org/new/acpica-unix_20130214-0.3.html > >I see. > > > >release-team: What’s your take on this? Can we get the new version > >into > >Debian in time for wheezy or how should we handle this? > > It's somewhat difficult to tell without seeing what's involved. (We > can't exactly debdiff against NEW...) Michael, I don't see a valid reason to get a newer version in wheezy at this stage of the freeze. Regards, -- mattia :wq! -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#700169: non-free license: requires to obey US export regulation even, when not in the US
On Wed, Mar 27, 2013 at 11:47:33AM +0100, Michael Stapelberg wrote: > Hi Ansgar, Mattia, > > Ansgar Burchardt writes: > > I also checked the initial Debian package on snapshot.debian.org > > (version 20050930-1). It also has only the non-free license in the > > individual files, but states "Dual GPLv2/ACPICA Licence" in d/copyright. > > It also has the BSD-3-clause-or-GPL-2 bit in d/copyright. > > > > It's likely that it was already dual-licensed, but that this wasn't > > documented in the tarball itself. I'm not sure why they now have two > > tarballs instead of one with both licenses... The "GNU General Public > > License or via a separate license that may be more favorable to > > commercial OSVs" (from the FAQ) seems also wrong given there are *three* > > licenses: the non-free one, a 3-clause BSD and the GPL-2 > Well, according to https://github.com/acpica/acpica/commit/84b8d0fd, the > dual-license tarballs are only available starting from version > 20110211. That version can indeed be downloaded as unix2 tarball. > > Mattia: is it reasonable to update this package to a newer version, > based on one of the unix2 tarballs? yes it is, that's what Al did already: http://ftp-master.debian.org/new/acpica-unix_20130214-0.3.html In any case, most of the code of the old packages have been included in the linux kernel for years and the original download page states: The Linux package includes the same functionality as the previous two, but has been modified to integrate smoothly with the Linux kernel source. This includes conversion of the ACPI CA source code to the Linux kernel coding standard, and licensing under the GNU General Public License. ... Linux The latest IASL compiler for Linux can be built from the Unix source package: download acpica-unix-VERSION.tar.gz $ tar xzf acpica-unix-VERSION.tar.gz $ cd acpica-unix-VERSION/compiler $ make Starting with Linux kernel 2.4, ACPI CA is in the Linux kernel. (taken from a randomly old snapshot: http://web.archive.org/web/20050911035003/http://developer.intel.com/technology/iapc/acpi/downloads.htm) from the commit log you referenced the explicit licence on source files was requested by FreeBSD but ACPICA has always been dual licensed. -- mattia :wq! -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#697300: src:user-mode-linux: missing Built-Using on linux (for linux-source-*)
On Fri, Jan 04, 2013 at 10:12:07AM +0100, Ansgar Burchardt wrote:
> Hi,
>
> I looked at your changes and found one error:
>
> +BUILT_USING := $(shell dpkg-query -f '$${binary:Package} (=
> $${source:Version}), ' -W linux-source-$(kernel_version))
>
> It needs to be $${source:Package} here as the Built-Using fields
> references other source packages. You should get something like
>
> Built-Using: linux (= 3.2.35-2)
>
> in the resulting binary package.
Yes, I actually changed it on purpose compared to the gcc-avr package
you pointed at.
Re-reading the policy though I get your point. I'll change that before
upload.
Thanks for checking
--
mattia
:wq!
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#697300: src:user-mode-linux: missing Built-Using on linux (for linux-source-*)
tags 697300 + pending thanks On Thu, Jan 03, 2013 at 07:21:19PM +0100, Ansgar Burchardt wrote: > Package: src:user-mode-linux > Version: 3.2-1um-1 > Severity: serious Thanks, I made the necessary changes to the package, I will upload a fixed version later today. -- mattia :wq! -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#599950: acpidump: FTBFS on ia64: error: unknown register name 'ebx' in 'asm'
On Sat, Oct 30, 2010 at 12:15:20PM +0200, Mike Hommey wrote: > On Tue, Oct 12, 2010 at 01:55:26PM +0200, Cyril Brulebois wrote: > > Source: acpidump > > Version: 20100513-1 > > Severity: serious > > Justification: FTBFS > > User: debian-i...@lists.debian.org > > Usertags: ia64 > > > > Hi, > > > > your package no longer builds on ia64: > > | make[2]: Entering directory > > `/build/buildd-acpidump_20100513-1-ia64-CL0nDr/acpidump-20100513/turbostat' > > | cc -Wall -g -O2 turbostat.c -o turbostat ... > Note it doesn't make sense to build turbostat on ia64 as it is a tool to > gather data on intel CPUs with the turbo boost technology. AFAIK, no > ia64 CPU has that. yes, you are right. let's see if I can find a minute to fix the package to skip turbostat on ia64. thanks -- mattia :wq! -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#587609: new version breaks virtualbox-ose compilation
retitle 587609 FTBFS: DSDT errors reassign 587609 virtualbox-ose thanks On Wed, Jun 30, 2010 at 12:12:22PM +0200, Michael Meskes wrote: > Package: iasl > Version: 20100528-2 > Severity: serious > Tags: sid > > Since upgrading iasl virtualbox-ose doesn't compile anymore: > > ... > kBuild: iasl DevicesR3 - > /home/michael/technik/sources/archive/virtualbox-ose/virtualbox-ose/src/VBox/Devices/PC/vbox.dsl > /home/michael/technik/sources/archive/virtualbox-ose/virtualbox-ose/src/VBox/Devices/PC/vbox.dsl >998: 0xdfdf, // Range Length > (calculated > Error4118 - > Length is not equal to fixed Min/Max window ^ > > ASL Input: > /home/michael/technik/sources/archive/virtualbox-ose/virtualbox-ose/src/VBox/Devices/PC/vbox.dsl > - 1305 lines, 46189 bytes, 288 keywords > Compilation complete. 1 Errors, 0 Warnings, 0 Remarks, 404 Optimizations > ... where can I find this DSDT? > Please note that I do not know if this is a iasl problem or a virtualbox-ose > one, although all older versions up to 20090521-1 worked without a problem. I > set this report to serious just in case it's an iasl problem to prevent > migration, so we have a working version left in squeeze. A couple of points to note: - 20090521 didn't have these sanity checks on resource templates - the aml file should be generated despite the error(s) that iasl reports Ok, never mind. While searching for the DSDT file to take a look myself I found this: http://www.mail-archive.com/freebsd-emulat...@freebsd.org/msg00196.html read the whole thread it appears VBox's DSDT has a number of problems. Bug reassigned accordingly -- mattia :wq! -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539427: Segmentation fault of iasl on non i386/amd64
On Tue, Oct 27, 2009 at 10:11:10PM +0900, Mattia Dongili wrote: > On Sun, Oct 25, 2009 at 01:15:06AM +0200, Guillem Jover wrote: > > Hi! > > > > [ Removing #516057 as it's a closed bug about a bison error. ] > > > > On Sat, 2009-10-24 at 18:19:51 +0200, Luk Claes wrote: > > > Can you please have a look at fixing the segfaults of iasl on non > > > i386/amd64 or do you think it would be better to remove the support of > > > iasl on non i386/amd64. If so, bochs is the only affected reverse dep of > > > iasl if you would restrict iasl to i386/amd64. > > > > I don't see why iasl would not be able to run on any architecture, > > it's just a compiler for byte-code. We ported it some time ago, but > > it seems it has regressed in the latest upload (probably problems with > > unaligned accesses or little endian assumptions, as before). I uploaded a new package with a pile of fixes for BE support. Let's see how it goes. -- mattia :wq! -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#577822: cpufreqd: causes hardware damage by ignoring sensor lines after removing libsenors3
severity 577822 normal tags 577822 - patch thanks On Wed, Apr 14, 2010 at 11:04:50PM +0200, Helmut Grohne wrote: > Package: cpufreqd > Version: 2.4.1-1 > Severity: critical > Tags: patch > Justification: causes hardware damage > > Since no package on my system depends on libsensors3 I removed it. With > it the file /etc/sensors.conf went away. This is a file cpufreqd > requires to use for the sensors plugin. Without that file it will not > trigger on temperature changes and possibly cause your hardware to > overheat. Would you mind describing what you're actually experiencing rather than an ipotetical (and quite unlinkely) situation? I can assume you're having problems with the sensors plugin from your submission... Also please, provide logs (running cpufreqd with -V7 generates a lot of useful output to trak down issues). > A quick solution is to depend on libsensors3 as it provides the required > file. cpufreqd depends on libsensors4, have you considered using /etc/sensors3.conf? I guess a possible issue here is that cpufreqd _requires_ a sensors config file while it's not really necessary to use one when initializing the library.. -- mattia :wq! -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#557410: cannot remove `/etc/rc0.d/K20cpufrequtils': No such file or directory"
On Sat, Nov 21, 2009 at 11:41:05PM +0100, Frank Gevaerts wrote: > Package: cpufrequtils > Version: 006-1 > Severity: normal > > Seems to be caused by > > [ -f $link ] || rm $link > > which obviously needs to be && instead Spotted :) the new package is queued and built on most architectures already. Regards, -- mattia :wq! -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#557420: cpufrequtils: Tries to remove non-existing symlinks
forcemerge 557420 557410 thanks On Sun, Nov 22, 2009 at 12:25:08AM +0100, Michael Biebl wrote: > Package: cpufrequtils > Version: 006-1 > Severity: serious > Justification: fails to upgrade > > pluto:~# ls /etc/rc?.d/???cpufrequtils > /etc/rc2.d/S20cpufrequtils /etc/rc3.d/S20cpufrequtils > /etc/rc4.d/S20cpufrequtils /etc/rc5.d/S20cpufrequtils yeah, shame on me. 006-2 is queued since last night already. -- mattia :wq! -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#557252: negate the match for keyboard capabilities
severity 557291 grave forcemerge 557252 557291 thanks On Fri, Nov 20, 2009 at 03:20:54PM -0500, Aleksey Kliger wrote: > --- 11-x11-synaptics.fdi.orig 2009-11-20 15:18:09.0 -0500 > +++ 11-x11-synaptics.fdi 2009-11-20 15:08:49.0 -0500 > @@ -4,7 +4,7 @@ > > > - > + >synaptics apologies, turns out that the laptop where I tested the change had a custom fdi file that was adding the synaptics driver anyway. I'm about to upload a fixed package. -- mattia :wq! -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539427: Segmentation fault of iasl on non i386/amd64
On Sun, Oct 25, 2009 at 01:15:06AM +0200, Guillem Jover wrote: > Hi! > > [ Removing #516057 as it's a closed bug about a bison error. ] > > On Sat, 2009-10-24 at 18:19:51 +0200, Luk Claes wrote: > > Can you please have a look at fixing the segfaults of iasl on non > > i386/amd64 or do you think it would be better to remove the support of > > iasl on non i386/amd64. If so, bochs is the only affected reverse dep of > > iasl if you would restrict iasl to i386/amd64. > > I don't see why iasl would not be able to run on any architecture, > it's just a compiler for byte-code. We ported it some time ago, but > it seems it has regressed in the latest upload (probably problems with > unaligned accesses or little endian assumptions, as before). yeah, dispite the fact that the patch applied, there were other changes that are causing a consistent segfault. > I might try to take a look at fixing it, but not now. Anyway regarding > bochs, it's not really a problem as iasl is only used when building > architecture independent packages, thus the Build-Depends-Indep. I tried debugging it when the bug first appeared after I uploaded the package with not much success but now I'm definitely lacking the time to look at it. As an emergency fix, if it's not a big deal for bochs, disabling the failing architectures is an option. thanks -- mattia :wq! -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#537208: Fails to upgrade (cannot access `/usr/lib/dbus-1.0/dbus-daemon-launch-helper': No such file or directory)
severity 537208 serious retitle 537208 Fails to upgrade (cannot access `/usr/lib/dbus-1.0/dbus-daemon-launch-helper': No such file or directory) thanks confirmed, today's upgrade here failed due to dbus. Cheers -- mattia :wq! -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#527711: xf86-input-evtouch: FTBFS: evtouch.c:33:25: error: xf86Version.h: No such file or directory
On Thu, May 14, 2009 at 08:36:26PM +0900, Mattia Dongili wrote: > On Wed, May 13, 2009 at 05:52:01PM +0200, Julien Cristau wrote: ... > > Also debian/copyright confuses me, it says the code is MIT, but somehow > > upstream has GPL-2 in COPYING, and the above patch says it's GPL as > > well. Could you clarify this? > > what a mess! the source files are definitly MIT, I'm pretty sure I asked > upstream about the COPYING file long time ago, I'll see if I can find > that discussion again, or even ask him again. > Although I'm quite sure our conversation ended up with him saying the > software is indeed MIT licensed. I found the old discussion. At that time I pointed out the misleading COPYING file, but I guess he never got around to amend it. I'll point it out again. -- mattia :wq! -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#527711: xf86-input-evtouch: FTBFS: evtouch.c:33:25: error: xf86Version.h: No such file or directory
On Sun, May 17, 2009 at 07:42:17PM +0200, Julien Cristau wrote: > On Thu, May 14, 2009 at 13:51:31 +0200, Julien Cristau wrote: > > > On Thu, May 14, 2009 at 20:36:26 +0900, Mattia Dongili wrote: > > > > > On Wed, May 13, 2009 at 05:52:01PM +0200, Julien Cristau wrote: > > > > Hi Mattia, > > > > > > > > I started to look at this as evtouch is one of the few drivers not > > > > building against server 1.6, but I'm a bit stuck. > > > > Patch 06_xf86-input-evtouch-0.8.7-misc.patch doesn't apply on 0.8.8, > > > > http://www.postnuklear.de/xorg-patches/ hasn't been updated in quite a > > > > long time. > > > > > > yeah, I think there is no need for that patch in 0.8.8. > > > I removed it from git a while ago after I imported the 0.8.8 sources. > > > > > Bah it looks like I somehow forgot to git fetch yesterday before looking > > at it, so I didn't notice you had already imported 0.8.8. Sorry about > > that. > > > After a bit more patching, I got it to build. Can you check/upload, or > should I do it (I don't have any way to test the package though)? I can test it later tonight. If everything is good I'll upload the package straight away. Thanks -- mattia :wq! -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#527711: xf86-input-evtouch: FTBFS: evtouch.c:33:25: error: xf86Version.h: No such file or directory
On Wed, May 13, 2009 at 05:52:01PM +0200, Julien Cristau wrote: > Hi Mattia, > > I started to look at this as evtouch is one of the few drivers not > building against server 1.6, but I'm a bit stuck. > Patch 06_xf86-input-evtouch-0.8.7-misc.patch doesn't apply on 0.8.8, > http://www.postnuklear.de/xorg-patches/ hasn't been updated in quite a > long time. yeah, I think there is no need for that patch in 0.8.8. I removed it from git a while ago after I imported the 0.8.8 sources. > Also debian/copyright confuses me, it says the code is MIT, but somehow > upstream has GPL-2 in COPYING, and the above patch says it's GPL as > well. Could you clarify this? what a mess! the source files are definitly MIT, I'm pretty sure I asked upstream about the COPYING file long time ago, I'll see if I can find that discussion again, or even ask him again. Although I'm quite sure our conversation ended up with him saying the software is indeed MIT licensed. > (debian/copyright also has an outdated upstream url, > http://www.conan.de/touchscreen/evtouch.html has the new release) > > ubuntu has 0.8.8 building on new xserver, so that would probably be > worth looking at as well. Sure, I'll take a look. Thanks -- mattia :wq! -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#516057: NMU?
On Wed, Mar 18, 2009 at 09:15:04PM -0400, Mike O'Connor wrote: > Maintainer, > > The attached patch does indeed seem to get this package building again. > Do you intend to make an uplaod soon? Would you like to have this bug > NMUed? Feel free to go on but make sure that the test case runs successfully. Thanks -- mattia :wq! signature.asc Description: Digital signature
Bug#510656: [Pkg-uml-pkgs] unmerging 478717, cloning 478717, reassign -1 to linux-2.6, found -1 in 2.6.18.dfsg.1-23etch1 ...
On Sun, Jan 04, 2009 at 02:21:36AM +, Ben Hutchings wrote: > unmerge 478717 > clone 478717 -1 -2 -3 ... > reassign -3 user-mode-linux > found -3 2.6.18-1um-2etch.23etch1 > found -3 2.6.26-1um-2 > fixed -3 2.6.18-1um-2etch.24 not sure UML is really affected by this bug, after all UML is x86 and x86_64 only ;) -- mattia :wq! -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#509355: cpufreqd: segfault while reading acpi battery info
On Tue, Dec 23, 2008 at 07:57:00PM +0100, Stefan Bühler wrote: > The problem is that check_timeout is reset after the first battery got > updated, so the values for the second battery are never read. > > This results in status->value == NULL, and strncmp segfaults. > > The solution is to update check_timeout after all battery values are updated. excellent, thanks -- mattia :wq! signature.asc Description: Digital signature
Bug#509355: cpufreqd: segfault while reading acpi battery info
On Sun, Dec 21, 2008 at 04:40:28PM +0100, Jonas Zeiger wrote:
> Package: cpufreqd
> Version: 2.3.3-3
> Severity: grave
> Justification: renders package unusable
>
>
> I've been trying to run cpufreqd on a Dell Latitude D530
> Laptop with a Intel Core2Duo 2.00Ghz CPU, 3GB of DDR2 RAM
> and two attached battery units using the stock Debian kernel
> version 2.6.26, but the problem is exactly the same with my
> custom kernel 2.6.26zlinux (tuned for install on SSD).
>
> Cpufreqd keeps segfaulting when starting up the system:
...
> acpi_battery_init: found 2 Batteries
> acpi_battery_update : BAT0 - present
> read_battery : BAT0 - reading battery levels
> read_battery : BAT0 - remaining capacity: 520
> acpi_battery_update : battery life for BAT0 is 109%
> acpi_battery_update : BAT1 - present
> acpi_battery_update : BAT1 - estimating battery life (timeout: 30.00 -
> status: (null))
> Speicherzugriffsfehler /* german locale, it' a segfault! :( */
can you run cpufreqd in a gdb session (make sure to start it with -D so
that is doesn't deamonize) and get a stack trace of the segfault?
Also, don't forget to build it with debug symbols.
> Ok, i've already tried to patch cpufreqd_2.3.3-3 with some patch found
> on the net:
>
> (Downloaded cpufreqd_2.3.3-3.diff and cpufreqd_2.3.3.orig.tar.gz)
> $ tar xvzf cpufreqd_2.3.3.orig.tar.gz
> $ patch -p0 < cpufreqd_2.3.3-3.diff
> $ cd cpufreqd-2.3.3
> $ sudo apt-get install libsensors-dev libcpufreqd-dev
> $ patch -p0
> Index: src/cpufreqd_acpi.c
> ===
> RCS file: /cvsroot/cpufreqd/sources2/src/cpufreqd_acpi.c,v
> retrieving revision 1.8
> diff -u -r1.8 cpufreqd_acpi.c
> --- src/cpufreqd_acpi.c 31 Aug 2008 01:17:25 - 1.8
> +++ src/cpufreqd_acpi.c 1 Oct 2008 12:22:23 -
> @@ -246,8 +246,8 @@
>
> /* read `clsname` devices */
> devs = sysfs_get_class_devices(cls);
> - if (!cls) {
> - clog(LOG_INFO, "class '%s' not found (%s)\n", clsname,
> + if (!devs) {
> + clog(LOG_INFO, "class device '%s' not found (%s)\n", clsname,
> strerror(errno));
> sysfs_close_class(cls);
> return -1;
this shouldn't even apply as it's already applied to the debian package
when building.
thanks
--
mattia
:wq!
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#495655: cpufreqd: uses "energy_full" instead of "charge_full" under /sys/...
On Wed, Aug 20, 2008 at 09:19:06AM +0200, alberto maurizi wrote: > Package: cpufreqd > Followup-For: Bug #495655 > > > the error message is: > cpufreqd: get_class_device_attribute: couldn't open > /sys/class/power_supply/BAT0/energy_full (No such file or directory) > [...] > kernel: [19344.165939] cpufreqd[24816]: segfault at 40 ip b7e04283 sp > bfb30770 error 4 in libc-2.7.so[b7d8e000+155000] > > under /sys/class/power_supply/BAT0/ path I can see a "charge_full" > rather than "energy_full". Maybe some inconsistency in naming > convention? well, apparently both of them are acceptable names. There is already a patch available attached to this bug report bus.debian.org/495655 I'm going to upload a new version as soon as possible -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#484467: cpufreqd, 484467 (grave) and CONFIG_ACPI_PROCFS_POWER in Lenny
On Tue, Aug 12, 2008 at 09:59:23PM +0200, Luk Claes wrote: > Mattia Dongili wrote: >> Hi, > > Hi > >> from the debian linux-2.6 svn repository it looks like >> CONFIG_ACPI_PROCFS_POWER is not going to be set for 2.6.26. >> >> cpufreqd has a grave bug filed (#484467) for the broken ACPI battery >> level support. ... > > Sorry for the late answer. > > I unblocked cpufreqd and set age-days to 15. Ohey! no worries and actually thanks. I was going to ping the list again once I verified that cpufreqd was running with no major issues in unstable. thanks a lot. -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#494721: [Pkg-uml-pkgs] Bug#494721: linux-patch-skas: Doesn't apply against Lenny release kernel
On Mon, Aug 11, 2008 at 07:52:58PM +0200, Moritz Muehlenhoff wrote: > Package: linux-patch-skas > Severity: grave > Justification: renders package unusable > > This package only provide a kernel patch up to 2.6.18 and doesn't > apply against later kernels (especially due to the unification > of the x86 architecture). I'm filing a request for removal now. I haven't seen updates to the skas3 patchset in quite a long time and development has moved to skas4 which, at some point, will be pushed upstream. cheers -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#484467: cpufreqd, 484467 (grave) and CONFIG_ACPI_PROCFS_POWER in Lenny
Hi, from the debian linux-2.6 svn repository it looks like CONFIG_ACPI_PROCFS_POWER is not going to be set for 2.6.26. cpufreqd has a grave bug filed (#484467) for the broken ACPI battery level support. I (with the cpufreqd upstream hat on) released a new cpufreqd (2.3.0) that reads from sysfs rather than /proc but the change is quite invasive and I (with the cpufreqd maintainer hat on) am now wondering if I should upload it (which I will do anyway in the next days) and ask for a freeze exception or not. The other option would be to ask for CONFIG_ACPI_PROCFS_POWER to be enabled in Lenny which I'm unsure if it's a good idea but it'd also allow battery support in gkrellm (#463779). The diff for the new cpufreqd version is attached (gzipped), in short it touches most of the acpi info reading code to make it go to sysfs (using libsysfs2) plus some trivial fixes here and there. Any suggestion? -- mattia :wq! cpufreqd-2.3.diff.gz Description: Binary data
Bug#491921: user-mode-linux: FTBFS on amd64 -- no more __memcpy with gcc 4.3
On Tue, Jul 22, 2008 at 03:20:41PM -0400, Aaron M. Ucko wrote: > Package: user-mode-linux > Version: 2.6.25-1um-1 > Severity: serious > Tags: patch > Justification: no longer builds from source > > user-mode-linux fails to build on amd64 with the following error: > > | CC arch/um/sys-x86_64/ksyms.o > | arch/um/sys-x86_64/ksyms.c:16: error: '__memcpy' undeclared here (not in a > function) > | arch/um/sys-x86_64/ksyms.c:16: warning: type defaults to 'int' in > declaration of '__memcpy' > | make[2]: *** [arch/um/sys-x86_64/ksyms.o] Error 1 > | make[1]: *** [arch/um/sys-x86_64] Error 2 > > The problem is that arch/um/sys-x86_64/ksyms.c unconditionally tries > to export __memcpy even though include/asm-x86/string_64.h declares it > only for GCC 4.2 and older, newer versions presumably being smart > enough not to need it. I'm attaching a patch that conditionalizes the > EXPORT_SYMBOL call accordingly, and have confirmed that it allows the > build to complete without errors. (FTR, arch/um/os-Linux/user_syms.c > already exports memcpy itself, so ksyms.c need not do so in any case.) > > FWIW, you can find a full log illustrating the error at > http://buildd.debian.org/fetch.cgi?pkg=user-mode-linux;ver=2.6.25-1um-1;arch=amd64;stamp=1216481207 > > -- System Information: > Debian Release: lenny/sid > APT prefers unstable > APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 2.6.25.11 (SMP w/2 CPU cores) > Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) > Shell: /bin/sh linked to /bin/dash > Index: linux-source-2.6.25/arch/um/sys-x86_64/ksyms.c > === > --- linux-source-2.6.25.orig/arch/um/sys-x86_64/ksyms.c 2008-04-16 > 22:49:44.0 -0400 > +++ linux-source-2.6.25/arch/um/sys-x86_64/ksyms.c2008-07-22 > 14:10:47.0 -0400 > @@ -13,4 +13,6 @@ > EXPORT_SYMBOL(__up_wakeup); > > /*XXX: we need them because they would be exported by x86_64 */ > +#if (__GNUC__ == 4 && __GNUC_MINOR__ < 3) || __GNUC__ < 4 > EXPORT_SYMBOL(__memcpy); > +#endif current linux git uses a slightly different solution http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8bfd04b974689f700bbd053ad6e66b0a95fb80c9 which is after all conditionally exports memcpy or __memcpy with the same logic as their definition. Will apply, and reupload later today. Thanks. -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#484467: query power status in /sys not in /proc
retitle 484467 cpufreqd: Depends on obsolete /proc/acpi interface thanks On Sat, Jun 28, 2008 at 10:36:26PM +0100, Ben Hutchings wrote: > /proc/acpi is scheduled for removal in Linux in July 2008, so there is > little point in reenabling it in the Debian kernel now. > > cpufreqd looks dead upstream, so it may be time to remove it. There I am upstream, can't say I'm actively developing cpufreqd these days (months? years?) but changing it to read from /sys is not a huge effort. Let me see if I can come up with something. > would need to be a release note to make sure people remove it before > upgrading if this shutdown rule is part of the standard configuration. the shutdown rule is not part of the standard configuration, at all (I'm not that crazy). cheers -- mattia :wq! signature.asc Description: Digital signature
Bug#484467: query power status in /sys not in /proc
On Fri, Jun 06, 2008 at 10:56:53AM +0200, maximilian attems wrote: > reassign 484467 cpufreqd > severity 484467 serious > retitle 484467 query power status in /sys not in /proc > stop > > > On Fri, Jun 06, 2008 at 08:11:16AM +0200, LÉVAI Dániel wrote: > > It reboots because there is a rule in /etc/cpufreqd.conf which halts the > > system when it detects a 0-1% battery charge. cpufreqd uses the > > legacy /proc way to gather battery status information, thus with the > > new kernel it doesn't work, and instantly halts because it thinks that > > no juice left. > > ok thanks a lot for the info, reassigning properly. > up to the cpufreqd maintainer to react. Any chance you could instead re-enable the deprecated /proc/acpi support? I don't think cpufreqd is the only one breaking. Cheers -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#484467: query power status in /sys not in /proc
On Tue, Jun 10, 2008 at 01:51:34PM +0200, psycheye wrote: > > One could argue that removing /proc/acpi now may break other programs > > and that it would be nice to have it enabled in the kernel for some more > > time. > doing: cpufreq-get I see: > No cpufreqd socket found > > (but in /var/run there's the pid about cpufreqd) you need a unix socket, not a pid file :) you can enable this feature in the config file (see also man cpufreqd.conf) > so, if I try to set cpu clock with cpufreq-selector (cpufreq-selector -c 0 -c > 1 -f 800) the command run, but the cpu clock doesn't change :-/ oh, this is not from the cpufreqd package and actually conflicts with what cpufreqd thinks the current frequency is. > So, I don't understand if "No cpufreqd socket found" is about the bug of > package or other errors. no, unrelated. This bug is about the /proc/acpi directory not being available in recent debian kernels. > What I will do? see above. Enable the unix socket and try again. cheers -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#484467: query power status in /sys not in /proc
On Tue, Jun 10, 2008 at 12:22:19PM +0200, psycheye wrote: > In the last kernels (2.6.24.x) proc is setted how obsolete, there is /sys > directory. > Using 2.6.25.4, could I've any problems? apparently yes... One could argue that removing /proc/acpi now may break other programs and that it would be nice to have it enabled in the kernel for some more time. bah -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#461760: xserver-xorg-input-synaptics: Synaptics touchpad completely stops working under gdm, xdm, kdm ... and X (gnome, openbox, kde...)
On Sat, Apr 26, 2008 at 10:24:38AM +0200, David Paleino wrote: > On Tue, 22 Apr 2008 20:55:07 +0200, Julien Cristau wrote: > > > Hi, > > Hi, > > > you reported a problem with the synaptics driver not reporting any > > events for your touchpad. > > Well, "not detecting the touchpad at all" would have been a better > description ;) > > > Can you attach the contents of /proc/bus/input/devices to this bug? > > Sure, but I can anticipate that the touchpad isn't listed in that file. then the Xorg driver has very little to do here and this sounds like a different bug. (Sorry I never replied to your other bug submission) ... > I can't make the touchpad working now, even with the versions reported above. > I > suspect it's something udev(?)-related, or, however, with hardware detection. > :( I agree here. If the touchpad is not listed in /proc/bus/input/devices then is't most probably kernel related. Did you notice anything suspicious in your kernel log? cheers -- mattia :wq! signature.asc Description: Digital signature
Bug#443726: Fixed upstream?
On Sat, Feb 02, 2008 at 01:33:29PM +0900, Mattia Dongili wrote: > On Wed, Jan 23, 2008 at 09:18:23PM +0900, Mattia Dongili wrote: > > On Wed, Jan 23, 2008 at 12:23:24PM +0100, Per Olofsson wrote: > > > Hi, > > > > > > Upstream's CHANGELOG[1] says: > > > > > > 0.8.8 > > > - Make it work for current Xorg-GIT > > > > > > However, no version 0.8.8 has been released yet. Maybe we can ask > > > upstream for a > > > patch in the mean time? > > > > sure!!! will do. > > sigh... no answer from upstream yet. And no 0.8.8 has been released yet. wow, I nic euser pointed to this: http://www.postnuklear.de/xorg-patches/files/xf86-input-evtouch-0.8.7-misc.patch (description at: http://www.postnuklear.de/xorg-patches/) I'll give it a try this weekend. hurray -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#443726: Fixed upstream?
On Wed, Jan 23, 2008 at 09:18:23PM +0900, Mattia Dongili wrote: > On Wed, Jan 23, 2008 at 12:23:24PM +0100, Per Olofsson wrote: > > Hi, > > > > Upstream's CHANGELOG[1] says: > > > > 0.8.8 > > - Make it work for current Xorg-GIT > > > > However, no version 0.8.8 has been released yet. Maybe we can ask upstream > > for a > > patch in the mean time? > > sure!!! will do. sigh... no answer from upstream yet. And no 0.8.8 has been released yet. -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#461760: xserver-xorg-input-synaptics: I confirm this bug
On Thu, Jan 31, 2008 at 11:53:11PM +0100, Michael Schmitt wrote: > Package: xserver-xorg-input-synaptics > Version: 0.14.7~git20070706-2 > Followup-For: Bug #461760 > > I can confirm this bug. It seems this does not break all touchpads but at > least some. > I have a ALPS touchpad in a Toshiba Satellit 2100 Pro and after uprade it > breaks the > touchpad completely. Downgrade to the current lenny version 0.14.6-1 fixes > this issue. > Here are the refering fragments of Xorg.0.log with a working touchpad (lennys > package): ... > (EE) No Input driver matching `synaptics' yep, as you can see the synaptics driver is completely bypassed and a different one is taking over. ... > (II) Synaptics touchpad driver version 0.14.6 (1406) > (--) ALPS Touchpad auto-dev sets device to /dev/input/event3 > (**) Option "Device" "/dev/input/event3" > (**) Option "SHMConfig" "On" > (**) Option "LeftEdge" "150" > (**) Option "RightEdge" "900" > (**) Option "TopEdge" "170" > (**) Option "BottomEdge" "680" > (**) Option "VertScrollDelta" "50" > (**) Option "HorizScrollDelta" "50" > (**) Option "EdgeMotionMinSpeed" "500" > (**) Option "EdgeMotionMaxSpeed" "500" > (**) Option "FingerLow" "25" > (**) Option "FingerHigh" "30" > (**) Option "MaxTapTime" "180" > (**) Option "MaxTapMove" "110" > (**) Option "EmulateMidButtonTime" "75" > (**) Option "UpDownScrolling" "1" > (**) Option "LeftRightScrolling" "1" > (**) Option "LockedDrags" "0" > (**) Option "RTCornerButton" "3" > (**) Option "LTCornerButton" "2" > (**) Option "CircularScrolling" "0" > (**) Option "PalmDetect" "1" > (**) Option "PalmMinWidth" "10" > (**) Option "PalmMinZ" "20" > (--) ALPS Touchpad touchpad found > (**) Option "AlwaysCore" > (**) ALPS Touchpad: doesn't report core events > (II) evaluating device (ALPS Touchpad) > (II) XINPUT: Adding extended input device "ALPS Touchpad" (type: MOUSE) > (II) evaluating device (USB Mouse) > (II) XINPUT: Adding extended input device "USB Mouse" (type: MOUSE) > (II) evaluating device (Keyboard0) > (II) XINPUT: Adding extended input device "Keyboard0" (type: KEYBOARD) > (--) ALPS Touchpad auto-dev sets device to /dev/input/event3 > (**) Option "Device" "/dev/input/event3" > (--) ALPS Touchpad touchpad found this really puzzles me... completely dead? does synclient report any activity? > Your assumption was true... if xorg complains about the synaptics module > it works (another driver taking its part?) and if the synaptics module > recognizes the touchpad it does not work. Right now I realised those > touchpad specific options (scrolling at the edges etc.) do not work anymore > either (with lennys package) what makes sense to me. But I am almost 100% > sure it worked completely. what happens if you just try to run with the default options? i.e.: comment everything except > Section "InputDevice" >Driver "synaptics" >Identifier "ALPS Touchpad" >Option "Protocol" "auto-dev" >Option "Device""/dev/input/mouse1" >Option "Always Core" "1" >Option "SHMConfig" "On" > EndSection thanks for the report -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#443726: Fixed upstream?
On Wed, Jan 23, 2008 at 12:23:24PM +0100, Per Olofsson wrote: > Hi, > > Upstream's CHANGELOG[1] says: > > 0.8.8 > - Make it work for current Xorg-GIT > > However, no version 0.8.8 has been released yet. Maybe we can ask upstream > for a > patch in the mean time? sure!!! will do. Thanka a lot for the note -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#461760: xserver-xorg-input-synaptics: Synaptics touchpad completely stops working under gdm, xdm, kdm ... and X (gnome, openbox, kde...)
On Sun, Jan 20, 2008 at 05:18:20PM +0100, Laurent CARON wrote: > Julien Cristau wrote: >> You don't say which version works for you. You also didn't send your X >> log. Please fix that (ideally with logs for both the working and >> non-working versions). > > Hi, > > Working version: working.log > By working i mean: X starts, but the synaptics functionality is broken > The "working" version is: > xserver-xorg-input-synaptics_0.14.6-1_i386.deb > > Non-Working version: non-working.log hmmm. Odd, you non-working version has no errors while your working has. I guess in the working case the device is taken by a different driver. This is from the working.log: > (II) LoadModule: "synaptics" > (II) Loading /usr/lib/xorg/modules/input//synaptics_drv.so > dlopen: /usr/lib/xorg/modules/input//synaptics_drv.so: undefined symbol: > miPointerGetMotionEvents > (EE) Failed to load /usr/lib/xorg/modules/input//synaptics_drv.so > (II) UnloadModule: "synaptics" > (EE) Failed to load module "synaptics" (loader failed, 7) while the non-working has everything in place. What does synclient -l issue with the current xserver-xorg-input-synaptics? Also, do you have any gsynaptics/ksynaptics/qsynaptics installed? Thanks -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#457931: /etc/init.d/cpufrequtils fails because of translations
On Thu, Dec 27, 2007 at 12:03:44PM +0100, Torsten Marek wrote: > Package: cpufrequtils > Version: 002-6 > Severity: serious > > Hi, > > because of #449307, cpufrequtils now uses cpufreq-info to enumerate CPUs and > cores. Unfortunately, > the sed pattern only works for the English messages of cpufreq-info and fails > if LANG != (C|en) and > a translation is present (which is the case for de, fr & it). In this case, > the init script > fails without any error message and does not set and governors etc. gah... very sorry about that. I hope I'll be able to upload a new package in the next couple of days. cheers -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#457753: loadcpufreq does nothing by default, cpufrequtils unusable
On Tue, Dec 25, 2007 at 12:53:11PM +0100, Kai Weber wrote: > Package: cpufrequtils > Version: 002-6 > Severity: grave > Justification: renders package unusable > > > The script init.d/loadcpufreq is disabled by default, so no modules for > cpu frequency scaling are loaded. This makes init.d/cpufrequtils fail > as well. > > If I read REDAME.Debian correctly this is not the desired behaviour. > loadcpufreq should be enabled by default and if someone wishes to > override this he should create a file /etc/default/loadcpufreq like > the provided example. > > I guess in the loadcpufreq script a default ENABLED=true is missing. damn, you're right... thanks for spotting it so quickly, will upload an new package asap cheers -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#446729: [Pkg-uml-pkgs] Bug#446729: rootstrap: MAKEDEV: No such file or directory
On Mon, Oct 22, 2007 at 04:03:11PM +0200, Marcus Better wrote: > package rootstrap > tag 446729 patch > thanks > > This patch appears to fix it. > > --- modules/uml~2006-09-26 10:57:22.0 +0200 > +++ modules/uml 2007-10-22 10:18:43.0 +0200 > @@ -5,7 +5,7 @@ > for i in 1 2 3 4 5 6 7 8; do > NEW_TTY="$NEW_TTY tty$i" > done > -chroot $TARGET /bin/sh -c "cd /dev && ./MAKEDEV ubd std pty $NEW_TTY" > +chroot $TARGET /bin/sh -c "cd /dev && /sbin/MAKEDEV ubd std pty $NEW_TTY" > chroot $TARGET umount /proc thanks, I hope I'll heve some time to update the package soon -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#443726: xserver-xorg-input-evtouch: input coordinates not scaled
Package: xserver-xorg-input-evtouch Version: 0.8.7-2 Severity: grave Justification: renders package unusable the driver's conversion_proc is not called in xorg-1.4 xf86PortMotionEvent making the driver fail to scale the input coordinates to the screen size. The net result is the pointer not responding correctly to taps. I'm already working on a fix, but this is to avoid that the package enters lenny if I fail to fix it in a timely fashion. mattia -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (300, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.23-rc1-mm1-1 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_GB, LC_CTYPE=ja_JP (charmap=EUC-JP) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#398091: php[45]-xcache for PHP 5.2
Hello Risko, since I needed to have a working xcache for etch I updated you package to upstream version 1.2.0. You can find my work here: http://people.debian.org/~malattia/packages/xcache/ (It was built in a clean etch chroot) Something that the changelog doesn't list is the fact that I added an xcache.ini to be installed in /etc/php[45]/conf.d, it installs with the cache actually disabled but loading the extension. Thanks -- mattia :wq! signature.asc Description: Digital signature
Bug#407708: optimization problem
severity 407708 important retitle 407708 iasl optimization generates a broken DSDT thanks On Sat, Jan 20, 2007 at 07:38:33PM +0100, emisca wrote: > I was wrong. I tried older version of iasl, and all have this behaviour. I discovered the same with a more recent one (20061109). > I tried disabling optimizations (iasl -oa -tc), and the code generated > seems good. Perhaps there is something wrong with optimization logic. I see, I'll try to ping upstream about that. By the way, I assume booting with the mis-optimized DSDT has't been successful, correct? Thanks -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#401153: NMU uploaded
On Tue, December 19, 2006 1:09 am, Andreas Barth said: > * Andreas Barth ([EMAIL PROTECTED]) [061214 08:41]: >> I uploaded an NMU of your package to experimental to see if the test >> case really works on buildds. > > It failed as expected on powerpc and also on sparc, and worked on at > least amd64 and powerpc - so I think this package can be uploaded to > unstable, unless there is reason not to do it. > > In other words, I intend to upload it to unstable during the next days. please go on, I won't have time enough in the next days. Thanks -- mattia :wq!
Bug#401153: backtrace for iasl bug #401153
On Mon, Dec 04, 2006 at 07:53:49PM +0100, Andreas Barth wrote: > * Andreas Henriksson ([EMAIL PROTECTED]) [061204 19:44]: > > I can confirm that the patch provided by Guillem Jover seems to fix > > the testcase in the original bug-report for me on Debian Testing > > PowerPC. > > I would propose to upload the fixed package ASAP. In case you want, I > can do an NMU as well. No problem, I'm already working on it. Thanks. -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#401153: backtrace for iasl bug #401153
On Mon, Dec 04, 2006 at 04:38:26PM +0100, Andreas Henriksson wrote: > On Sun, Dec 03, 2006 at 08:58:31PM +0200, Guillem Jover wrote: > [...] > > The attached patch fixes the segfault, and corrects the CFLAGS > > handling for upstream and Debian, it also adds alpha to the list of > > 64 bit arches. The fix for compiler/aslopcodes.c is needed because > > the macros ACPI_UINT32_MAX: and ACPI_INTEGER_MAX are the same if > > ACPI_INTEGER is defined to be 32 bits. > > > > regards, > > guillem > > I can confirm that the patch provided by Guillem Jover seems to fix > the testcase in the original bug-report for me on Debian Testing > PowerPC. > > $ iasl -tc ../acpi-dsdt.dsl > > Intel ACPI Component Architecture > ASL Optimizing Compiler version 20060912 [Dec 4 2006] > Copyright (C) 2000 - 2006 Intel Corporation > Supports ACPI Specification Revision 3.0a > > ASL Input: ../acpi-dsdt.dsl - 561 lines, 18338 bytes, 209 keywords > AML Output: acpi-dsdt.aml - 2098 bytes 104 named objects 105 executable > opcodes > > Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 68 Optimizations > $ Ok, I'll see if it doesn't introduce evident regressions (eg by compiling some of the DSDT's available on acpi.sf.net + my own here) and eventually include it in the package. Robert: does the patch looks correct to you? Thanks -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#401153: backtrace for iasl bug #401153
On Sat, Dec 02, 2006 at 02:27:40AM +0100, Andreas Henriksson wrote: > On fre, 2006-12-01 at 15:43 -0800, Moore, Robert wrote: > > I'm not sure I understand what you are describing, please clarify. > > Please see http://bugs.debian.org/401153 for the original bug report. > Basically, iasl successfully compiles the atteched dsl file on a regular > i386 pc, but when running the same program on PowerPC (Debian GNU/Linux) > then you get a segmentation fault. There is probably a bug in the > program somewhere which seems to only trigger on powerpc at the moment. > > It has been tracked down to being related to Asl.Value.String being > NULL. This state seems invalid and makes the program crash. Do you have > any idea what might have failed and how this variable could be > uninitialized? It would be really appreciated if you have any hints > about possible failures that we can investigate... Just as a side note, I tried compiling the mentioned DSDT on an ARM platform and I get a different error: $ ./acpica-unix-20060912/compiler/iasl acpi-dsdt.dsl Intel ACPI Component Architecture ASL Optimizing Compiler version 20060912 [Oct 2 2006] Copyright (C) 2000 - 2006 Intel Corporation Supports ACPI Specification Revision 3.0a ACPI Warning (nssearch-0421): Found bad character(s) in name, repaired: [_GP*] [20060912] And no AML is generated. -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#401153: backtrace for iasl bug #401153
Hi Robert, I've been submitted a bug from the powerpc Debian's folks (see below or point your browser at [1]). In short the story is: we enabled building iasl for powerpc in order to buld DSDT tables for qemu which is available on powerpc and can emulate the x86. So we have a DSDT which makes iasl segfault while building on powerpc, it doesn't on i386. The DSDT is here: http://bugs.debian.org/cgi-bin/bugreport.cgi/acpi-dsdt.dsl?bug=401153;msg=5;att=1 Can you help putting some light where the problem may hide? Thanks [1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401153 - Forwarded message from Andreas Henriksson <[EMAIL PROTECTED]> - Subject: Bug#401153: backtrace for iasl bug #401153 From: Andreas Henriksson <[EMAIL PROTECTED]> Date: Fri, 1 Dec 2006 16:45:37 +0100 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Message-ID: <[EMAIL PROTECTED]> User-Agent: Mutt/1.5.9i Reply-To: Andreas Henriksson <[EMAIL PROTECTED]>, [EMAIL PROTECTED] On Fri, Dec 01, 2006 at 03:42:51PM +0100, Andreas Henriksson wrote: > Program received signal SIGSEGV, Segmentation fault. > 0x10019570 in TrAmlTransformWalk () > (gdb) bt > #0 0x10019570 in TrAmlTransformWalk () > #1 0x1001758c in TrWalkParseTree () > #2 0x1000b728 in CmDoCompile () > #3 0x10011250 in main () > (gdb) > I forgot to mention, this is on Debian Testing PowerPC with iasl recompiled with DEB_BUILD_OPTIONS="noopt, nostrip". Some additional printf debugging shows this: TrAmlTransformWalk -> TrTransformSubtree -> TrDoDefinitionBlock File compiler/asltransform.c line 432: if (!ACPI_COMPARE_NAME (Next->Asl.Value.String, ACPI_SIG_DSDT)) it blows up here Next->Asl.Value.String is NULL... All the macro/pointer obfuscation got me lost here... HTH -- Regards, Andreas Henriksson - End forwarded message - -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#401153: backtrace for iasl bug #401153
On Fri, Dec 01, 2006 at 04:45:37PM +0100, Andreas Henriksson wrote: > On Fri, Dec 01, 2006 at 03:42:51PM +0100, Andreas Henriksson wrote: > > Program received signal SIGSEGV, Segmentation fault. > > 0x10019570 in TrAmlTransformWalk () > > (gdb) bt > > #0 0x10019570 in TrAmlTransformWalk () > > #1 0x1001758c in TrWalkParseTree () > > #2 0x1000b728 in CmDoCompile () > > #3 0x10011250 in main () > > (gdb) > > > > I forgot to mention, this is on Debian Testing PowerPC with iasl > recompiled with DEB_BUILD_OPTIONS="noopt, nostrip". > > > Some additional printf debugging shows this: > TrAmlTransformWalk -> TrTransformSubtree -> TrDoDefinitionBlock > > File compiler/asltransform.c line 432: > if (!ACPI_COMPARE_NAME (Next->Asl.Value.String, ACPI_SIG_DSDT)) > > it blows up here Next->Asl.Value.String is NULL... All the > macro/pointer obfuscation got me lost here... Thanks, I'm forwading the thing upstream -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#400580: cpufreqd: fails to change governor when goes with battery
On Tue, November 28, 2006 7:25 pm, leandro noferini said: > "Mattia Dongili" <[EMAIL PROTECTED]> writes: > > > [...] > >> the kernel. could you please lower the severity and reassign? > > Ok! > > How could I do that? first ensure that the bug is reproducible with debian's stock kernels, then reassign, read here: http://www.debian.org/Bugs/server-refcard.html anyway if you need help for the second step, just ask :) -- mattia :wq!
Bug#400580: cpufreqd: fails to change governor when goes with battery
On Tue, November 28, 2006 6:20 pm, leandro noferini said: > "Mattia Dongili" <[EMAIL PROTECTED]> writes: > > [...] > >>> Now I read more carefully. >>> >>> My platform is a last generation iBook G4 and cpufreqd worked fine >>> also >>> with the kernel 2.6.17 home compiled. cpufreqd stops working from >>> an >>> upgrade on. >> >> ok, and your logs say that _the_kernel_ is unable to load the ondemand >> governor, hence cpufreqd fails. So your problem is to be searched >> elsewhere. > > Any tip from where to begin? the kernel. could you please lower the severity and reassign? thanks -- mattia :wq!
Bug#400580: cpufreqd: fails to change governor when goes with battery
On Tue, November 28, 2006 1:44 pm, leandro noferini said: > "Mattia Dongili" <[EMAIL PROTECTED]> writes: > > [...] > >> kernel bug? cpufreqd correctly complains about not being able to switch >> to >> ondemand. If this governor doesn't work for your platform, just >> reconfigure cpufreqd to avoid using it. > > Now I read more carefully. > > My platform is a last generation iBook G4 and cpufreqd worked fine also > with the kernel 2.6.17 home compiled. cpufreqd stops working from an > upgrade on. ok, and your logs say that _the_kernel_ is unable to load the ondemand governor, hence cpufreqd fails. So your problem is to be searched elsewhere. -- mattia :wq!
Bug#400580: cpufreqd: fails to change governor when goes with battery
On Mon, November 27, 2006 12:33 pm, Debian BTS said:
> This is the log from syslog
...
> Package: cpufreqd
> Version: 2.2.0-2
> Severity: grave
> Justification: renders package unusable
>
> Nov 27 12:19:35 janni kernel: ondemand governor failed to load due to too
> long transition latency
> Nov 27 12:19:37 janni cpufreqd: cpufreqd_set_profile : Couldn't set
> profile "On Demand High" set for cpu0
> Nov 27 12:19:37 janni cpufreqd: cpufreqd_loop: Cannot set
> policy, Rule unchanged ("AC Rule").
> Nov 27 12:19:37 janni kernel: ondemand governor failed to load due to too
> long transition latency
>
> The kernel is a 2.6.18 home compiled but this happens also with a 2.6.17
kernel bug? cpufreqd correctly complains about not being able to switch to
ondemand. If this governor doesn't work for your platform, just
reconfigure cpufreqd to avoid using it.
--
mattia
:wq!
Bug#397917: gsynaptics - lists s390 as supported
On Sat, Nov 11, 2006 at 02:11:24PM +0900, Osamu Aoki wrote: > Hi, > > On Fri, Nov 10, 2006 at 05:59:07PM -0800, Steve Langasek wrote: > ... > > > Option 3) > > > * Set "Architecture: alpha amd64 arm hppa i386 ia64 m68k mips mipsel > > > powerpc sparc" > > > * Ask ftp-master for removal of package for s390 > > > * Make entry in quinn-diff not to build on s390 > > > > This is an acceptable solution, > ... > > > Option 4) > > > * Set "Architecture: any" > > > * Have fancy script to fail in s390. > > > * Ask ftp-master for removal of package for s390 > > > * Make entry in quinn-diff not to build on s390 > > > > This is an acceptable solution. > > I like the latter so I do not interfare with builoding kfreebsd-i386 etc. Well, the synaptics driver is quite Linux specific, isn't it? And since xserver-xorg-driver-synaptics is also not built on that architecture the gsynaptics package will be uninstallable anyway. -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#397917: gsynaptics - lists s390 as supported
On Fri, Nov 10, 2006 at 11:17:57PM +0900, Osamu Aoki wrote: > On Fri, Nov 10, 2006 at 02:00:32PM +0100, Bastian Blank wrote: > > Package: gsynaptics > > Version: 0.9.7-1 > > Severity: serious > > > > gsynaptics lists s390 as supported (Architecture: any) but > > xserver-xorg-input-synaptics is not available. This leads to > > uninstallable binary packages. > > I see. But xserver-xorg-input-synaptics has > > Architecture: alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc sparc it was "Architecture: any" with a quinn-diff[1] entry in the past, and s390 was not supported because xserver-xfree86 wasn't available there. > This looks agry. Because I need to track new architectures. > > Can I do > > Architecture: !s390 > > Anyone have suggestion? This is ok until you have to add one more unsupported arch to the list. I think the trade-off here is if you want to add new supported or unsupported architectures, the latter implying you may need to ask for removal of the binary (as in the current case for s390), the former implying a new upload. Here the discussion I had some time ago: http://www.mail-archive.com/debian-mentors@lists.debian.org/msg12969.html Currently (AFAICT) xserver-xorg-input-synaptics seems to be installable on s390 but maybe it doesn't make much sense... [1]: http://buildd.debian.org/quinn-diff/Packages-arch-specific -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#375851: possibly just the wrong encoding?
Hi Enrico, is this the same problem addressed in /usr/share/doc/festvox-itapc16k/README.Debian? (Encoding of accented letters) I did write a stupid program (using glade and gtk2) to play with festival[1], see launch_festival(void *x) in src/callbacks.c for some code to do the same as the suggested `recode stuff`. It needs librecode-dev to build. [1]: http://people.debian.org/~malattia/packages/parlami-0.1.tar.gz -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#374582: [Pkg-uml-pkgs] Bug#374582: base-config is been invoked in rootstrap, although it doesn't exist anymore
severity 374582 minor thanks On Tue, Jun 20, 2006 at 08:10:18AM +0300, alex bodnaru wrote: > Package: rootstrap > Version: 0.3.22-1 > Severity: grave > Justification: renders package unusable > > base-config has been removed from etch, hence it's invokation fails. > you may execute it on condition if exists, or just ignore it's failure > like with || true. Uh, but the base-config module is not even included in the default configuration. I wouldn't even consider this a bug, at least until sarge (with base-config) disappears. I'm very tempted to close this bug, I don't really see any bug here. Surely this is not "grave" at all. Maybe just documenting this issue can help? thanks -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#372498: News about this bug? (ksynaptics: incompatible with xfree86-driver-synaptics 0.14.5-1)
Hello Arnaud, On Wed, Jun 14, 2006 at 09:22:05PM +0200, Arnaud Quette wrote: [...] > A last thanks to Modestas for putting me in touch with Fathi, and to > Mattia for his work on the synaptics driver. sorry for not getting back to you earlier, I've been on a 2day business trip and anyway I didn't hear anything from the guy I asked help for [kq]synaptics. BYe -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#372259: user-mode-linux: the uml_switch control file is not been searched as in uml-utilities package
On Sun, Jun 11, 2006 at 09:35:51AM +0200, Stefano Melchior wrote: > On Sun, Jun 11, 2006 at 07:19:46AM +0300, alex bodnaru wrote: [...] > > fortunately, this has changed in um2 version, and now upgrading is smoother. > > > thus does this mean that "-2um" version fixed the bug you submitted? If > so, if you feel it should be fixed, please let me know it, because I would > like to close the bug, please. it already is. thanks -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#370155: cpufreqd: init script does not stop the daemon and hangs until user input
On Sat, Jun 03, 2006 at 11:04:55PM +0200, Norbert Preining wrote:
> Hi all!
>
> On Sam, 03 Jun 2006, Mattia Dongili wrote:
> > I suppose it should be
> > cat /var/run/cpufreqd.pid | read pid
> > instead.
>
> changed it to this, and it didn't work, at least it didn't stop the
> cpufreqd.
oh... running it on the command line[1] seems to work, but you're right, the
script still is not stopping cpufreqd (pidofproc returns 2).
[1]: if [ -f /var/run/cpufreqd.pid ] ; then cat /var/run/cpufreqd.pid |
read pid ; fi ; if [ -n "${pid:-}" ]; then echo "$pid" ; fi
> So let the lsb-base maintainers fix this.
I have to agree :)
--
mattia
:wq!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#370155: cpufreqd: init script does not stop the daemon and hangs until user input
reassign 370155 lsb-base 3.1-6 retitle 370155 pidofproc reads from stdin and hangs waiting for user input severity 370155 critical thanks On Sat, Jun 03, 2006 at 10:28:11PM +0200, Norbert Preining wrote: > Hi Mattia! > > On Sam, 03 Jun 2006, Mattia Dongili wrote: > > I can't reproduce it here, can you run the script with -x and send the > > output to see where it hangs? > > It hangs in the read pid: Yes, upgraded my lsb-base (was at -5 here) and it's fully reproducible. > gandalf:~# bash -x /etc/init.d/cpufreqd stop > + PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin [...] > + pidfile=/var/run/cpufreqd.pid > + '[' -f /var/run/cpufreqd.pid ']' > + read pid > > ENTER I suppose it should be cat /var/run/cpufreqd.pid | read pid instead. It seems to be an lsb-base bug, reassigning. Severity is critical as it breaks unrelated software. Thanks for reporting. -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#370155: cpufreqd: init script does not stop the daemon and hangs until user input
On Sat, Jun 03, 2006 at 08:48:36PM +0200, Norbert Preining wrote: > Package: cpufreqd > Version: 2.0.0-1 > Severity: serious > > Hi! > > My cpufreqd init script hangs indefinitely when stopping. I have to press > the enter key to make it continue, also that doesn't stop the daemon. > > I consider this serious as remote reboot is not possible anymore. > And the shutdown process has to be attended. I can't reproduce it here, can you run the script with -x and send the output to see where it hangs? Thanks -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#365395: user-mode-linux: UML will not boot from ISO
severity 365395 important thank On Sat, Apr 29, 2006 at 11:48:16AM -0700, Todd A. Jacobs wrote: > Package: user-mode-linux > Version: 2.6.16-1um-1 > Severity: grave > Justification: renders package unusable it's not really unusable, severity is inappropriate IMO. > I reported on the UML mailing list that I was unable to boot from an ISO > image, even after various gyrations. Jeff Dike suggested that the binary > was probably compiled without proper block support (specifically > CONFIG_BLK_DEV_UBD, although there may be issues with ISO9660 support as > well). > > Here is the actual error and command-line: > > $ linux mem=64M umid=debian ubd0r=debian-testing-i386-netinst.iso You're mixing things up. You can't boot from the install image, you need to extract the initrd from the iso [1] and boot from the initrd [2]. Then you can proceed and install the system (you'll also have to manually tell the installer where the cdrom is -you'll be asked during installation, in my example you can use /dev/ubdb). [1]: mount -o loop debian-testing-i386-netinst.iso /mnt cp /mnt/install/2.6/initrd.gz /anywhere [2]: linux ramdisk_size=12000 mem=128M umid=debian initrd=initrd.gz root=/dev/ram0 ubd0=rootfs ubd1=debian-testing-i386-netinst.iso eth0=tuntap,,,172.20.0.1 As said in the uml-devel ML I have the new package ready here, I'll upload it tomorrow. [...] > Console initialized on /dev/tty0 > Initializing software serial port version 1 > ubda: unknown partition table > Kernel panic - not syncing: VFS: Unable to mount root fs on > unknown-block(98,0) In fact you get this same error running: linux mem=64M umid=debian ubd0r=/dev/zero The problem here is that netinst.iso doesn't contain a regular filesystem to boot with. This works with regular PCs because the bootloader helps this process (loading and running the initrd). Thanks -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#362058: [Pkg-uml-pkgs] Bug#362058: uml-utilities: ships port-helper under /usr/lib64 on amd64
tags 362058 +confirmed +pending thanks On Tue, Apr 11, 2006 at 07:57:40PM -0400, Aaron M. Ucko wrote: [...] > uml-utilities goes out of its way to force use of /usr/lib64 on amd64, > which is a big no-no on Debian and clashes with libc6: Ops, sorry. > > Unpacking replacement libc6 ... > > dpkg: error processing /var/cache/apt/archives/libc6_2.3.6-6_amd64.deb > > (--unpack): > > trying to overwrite `/usr/lib64', which is also in package uml-utilities > > Could you please fix this? done, fixed in our svn repository. I'll upload -3 tomorrow. bye -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345436: xlibs: Keyboard not working properly after upgrade to 6.9.0.dfsg.1-1
On Sat, Dec 31, 2005 at 12:26:39PM -0200, Paulo Marcel Coelho Aragao wrote: > Package: xlibs > Version: 6.9.0.dfsg.1-1 > Severity: grave > Justification: renders package unusable > > After the upgrade to 6.9.0.dfsg.1-1, the keyboard stopped working properly > under X. I've noticed the following: > > 1. ctrl-alt-fn doesn't switch to other virtual consoles > 2. The key with characters '/' and '?' is dead > > Not switching to virtual consoles can be lived with, but the lack of '/' and > '?' makes X unusable. > > Needless to say, the keyboard works properly on the consoles, and it worked > properly before the upgrade. [...] > Versions of packages xlibs depends on: [...] > ii libxtst6 6.9.0.dfsg.1-1 X Window System event recording > an > ii xlibs-data 6.8.2.dfsg.1-11 X Window System client data ^ maybe you only missed the xlibs-data update? -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337479: yaird: should use /usr/bin/perl, not /usr/local/bin/perl
On Wed, Nov 09, 2005 at 08:16:08PM +0100, Laurent Bonnaud wrote:
> On sam, 2005-11-05 at 16:31 +0100, Mattia Dongili wrote:
[...]
> > I's like
> > configuring a package with silly ./configure options and pretending it
> > works everywhere. :)
>
> I did not intervene in the build process. I used this command:
>
> apt-get -b source yaird
>
> With this command I expect to get a working package as long as I do not
> mess up the system. And putting files in /usr/local/ is clearly allowed
> and does not count as "messing up the system".
Yes, sorry. I was thinking of a lot of silly corner cases when I wrote
that (I hit the same issue when playing with ./configure and stuff so
that's what I had in mind in the first place).
By the way, Erik, Jonas I'm attaching a patch to the configure.in to add
--with-perl option (defaults to autodetection if not given).
I'm sorry I'm not into cdbs enough to provide a patch for debian/rules
also :)
--
mattia
:wq!
Index: configure.in
===
--- configure.in(revision 4760)
+++ configure.in(working copy)
@@ -47,8 +47,29 @@
[Define to nuke initramfs before moving to real root])
fi
+# Force a specific perl binary
+AC_ARG_WITH(perl,
+ AC_HELP_STRING([--with-perl=PATH],
+ [Force a specific perl executable path (autodetected by
default)]),
+ [
+ case "${withval}" in
+ yes|auto)
+ with_perl=auto ;;
+ *) PERL=${withval}
+ if ! test -x ${PERL} ; then
+ AC_MSG_ERROR(bad value ${PERL} for --with-perl)
+ fi
+ AC_SUBST(PERL)
+ ;;
+ esac
+ ],[
+ with_perl=auto
+ ])
+if test "$with_perl" = auto; then
+ AC_PATH_PROG(PERL,perl)
+fi
+
# Checks for programs.
-AC_PATH_PROG(PERL,perl)
AC_PROG_CC
AC_PROG_RANLIB
Bug#336598: cannot parse /etc/fstab file with SMB share
On Mon, Oct 31, 2005 at 09:06:59PM +0100, Jonas Smedegaard wrote: [...] > On Mon, 31 Oct 2005 20:26:35 +0100 > Mattia Dongili <[EMAIL PROTECTED]> wrote: > > > I sent another mail telling that the correct fix is probably checking > > if ($#fields < 3) as also the fs options are (ehrm...) optional :) > > I disagree. Judging from the manpage of fstab the 4th entry "contains > at least the type of mount", so cannot be left out. anyway mount allows the presence of such lines: sysfs /sys sysfs /dev/hda5 /mnt/tmp0 reiser4 the above 2 lines both work here without any complaint from mount (I did notice I left out opts-dump-pass entried only trying out yaird :)) -- mattia :wq! signature.asc Description: Digital signature
Bug#336598: cannot parse /etc/fstab file with SMB share
On Mon, Oct 31, 2005 at 08:09:35PM +0100, Jonas Smedegaard wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Mon, 31 Oct 2005 18:19:56 +0100 > Mattia Dongili <[EMAIL PROTECTED]> wrote: > > > this is actually the same as #336585: > > "The fs_freq and fs_passno fields in /etc/fstab are optional" > > Yes. Thanks, Mattia. > > The attached patch should fix this issue. Looks like a simple oversight > from upstream (he noticed they are irrelevant but checks for them > anyway). I'm sorry, it seems it take a couple of hours to my messages to be delivered. I sent another mail telling that the correct fix is probably checking if ($#fields < 3) as also the fs options are (ehrm...) optional :) BTW: the mere failed because of mismatching severity -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#336598: cannot parse /etc/fstab file with SMB share
On Mon, Oct 31, 2005 at 06:19:56PM +0100, Mattia Dongili wrote: > merge 336585 336598 > thanks doh! failed because of severity. I'll let kernel mainteiners decide on that then. sorry for the noise -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#336598: cannot parse /etc/fstab file with SMB share
merge 336585 336598 thanks On Mon, Oct 31, 2005 at 12:45:25PM +, Martin Michlmayr wrote: > Package: yaird > Version: 0.0.11-10 > Severity: grave > > yaird fails when /etc/fstab contains a SMB share, such as: > > \\mlpc-serv-fs1.eng.cam.ac.uk\homes /srv/mlpc-serv-fs1 smbfs > noauto,user,uid=tbm,gid=tbm,credentials=/etc/samba/private/msm34 this is actually the same as #336585: "The fs_freq and fs_passno fields in /etc/fstab are optional" -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#319387: problems starting kde 3.4
tags 319387 + moreinfo severity 319387 important thanks On Thu, Jul 21, 2005 at 08:19:18PM +0200, Bastian Venthur wrote: > Package: xfree86-driver-synaptics > Version: 0.14.2-2 > Severity: serious > > When booting and starting in kdm, the touchpad works fine, but when kde > 3.4 (from alioth) starts after login, the touchpad is disabled again. > > The only way to get it back to work is: > > sudo modprobe -r psmouse && sudo modprobe psmouse > > in kde, and the touchpad is on again. Could you provide X (/var/log/Xorg.0.log) and kernel (from dmesg) logs? Thanks -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
