Bug#689668: ltsp-client-core: SERVER in lts.conf ignored, wrong order in ltsp_config.d
On vr, 2012-10-05 at 11:18 -0700, Vagrant Cascadian wrote:
On Thu, Oct 04, 2012 at 11:09:50PM +0200, Tim Dijkstra (tdykstra) wrote:
Package: ltsp-client-core
Severity: normal
What version of ltsp are you running? From the ltsp server, please paste the
output of runnning:
ltsp-info
root@ltspd:~# ltsp-info
server information:
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux testing (wheezy)
Release:testing
Codename: wheezy
server packages:
ii ldm-server 2:2.2.11-2
un ltsp-client-core none
un ltsp-docs none
ii ltsp-server 5.4.2-2
un ltsp-utils none
ii ltspfs 1.1-2
packages in chroot: /opt/ltsp/amd64
ii ldm 2:2.2.11-2
ii ldm-themes 12.07.1
ii ltsp-client 5.4.2-2
ii ltsp-client-core 5.4.2-2
ii ltspfsd 1.1-2
ii ltspfsd-core 1.1-2
found: /opt/ltsp/amd64/etc/lts.conf
In my setup the server that is logged into is different from the NFS
server serving the rootfs. By default ltsp assumes those are the same,
to override one can set the SERVER variable in lts.conf.
You probably should use LDM_SERVER (or XDM_SERVER) to select the login server,
not the SERVER variable.
Well, with server you said all *_SERVER vars.
However this doesn't work. This is because in ltsp_config.d the script
01-getltscfg comes before 01-ltspconfig-cache, which means the later
will override the SERVER variable from lts.conf with a guess based on
the NFS server IP.
The solution is simple, just rename 01-ltspconfig-cache to
00-ltspconfig-cache
This may have other other unintended side-effects- I'll look into it.
Doing a simple grep, it seems that the only thing that is happening is
that in init-ltsp.d a few variables are cached and reloaded in
01-ltspconfig-cache.
It is documented everywhere that you can override these variables by
setting it in /etc/lts.conf, in the current setup you can't.
root@ltspd:/usr/share/ltsp# grep -r /var/cache/ltsp/ltsp_config */*
init-ltsp.d/01-clean-cache:rm -f /var/cache/ltsp/ltsp_config
/var/cache/ltsp/ltsp_config_env
init-ltsp.d/03-kernel-cmdline:fi /var/cache/ltsp/ltsp_config
init-ltsp.d/04-server:echo NBD_ROOT_HOST=${server}
/var/cache/ltsp/ltsp_config
init-ltsp.d/04-server:echo NBD_ROOT_NAME=${name}
/var/cache/ltsp/ltsp_config
init-ltsp.d/04-server:echo NBD_ROOT_PORT=${port}
/var/cache/ltsp/ltsp_config
init-ltsp.d/04-server:echo NFS_SERVER=${server}
/var/cache/ltsp/ltsp_config
init-ltsp.d/04-server:echo SERVER=$SERVER /var/cache/ltsp/ltsp_config
init-ltsp.d/50-client-mac:echo LTSP_CLIENT_MAC=$LTSP_CLIENT_MAC
/var/cache/ltsp/ltsp_config
ltsp_config.d/00-ltspconfig-cache:# Source /var/cache/ltsp/ltsp_config
ltsp_config.d/00-ltspconfig-cache:if [ -f /var/cache/ltsp/ltsp_config ]; then
ltsp_config.d/00-ltspconfig-cache:. /var/cache/ltsp/ltsp_config
ltsp_config.d/00-ltspconfig-cache:cat /var/cache/ltsp/ltsp_config
${ltsp_config_env} || true
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689668: ltsp-client-core: SERVER in lts.conf ignored, wrong order in ltsp_config.d
Package: ltsp-client-core Severity: normal In my setup the server that is logged into is different from the NFS server serving the rootfs. By default ltsp assumes those are the same, to override one can set the SERVER variable in lts.conf. However this doesn't work. This is because in ltsp_config.d the script 01-getltscfg comes before 01-ltspconfig-cache, which means the later will override the SERVER variable from lts.conf with a guess based on the NFS server IP. The solution is simple, just rename 01-ltspconfig-cache to 00-ltspconfig-cache grts Tim -- System Information: Debian Release: 6.0.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-xen-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#668454: python-twisted: New upstream available
Package: python-twisted Severity: wishlist Hi, I'm working on packaging the latest release of CalendarServer. It claims to depend on the newest release of twisted: 12. Are there any plans to package it? Maybe in experimental? I know very little about twisted, but I think I could assist in the package upgrade if any help is needed. -- System Information: Debian Release: 6.0.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-xen-amd64 (SMP w/4 CPU cores) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509539: digitaldj: Should this package be removed?
Op Mon, 22 Dec 2008 23:01:44 -0500 schreef Barry deFreese bdefre...@debian.org: Package: digitaldj Version: 0.7.5-6.1 Severity: normal User: debian...@lists.debian.org Usertags: proposed-removal Dear Maintainer, While reviewing some packages, your package came up as a possible candidate for removal from Debian, because: * Inactive upstream (No activity since 2003/2004). * Build-depends on libgnome-dev which is scheduled for removal. * Alternatives exist. (Lots of mp3 players out there, though not necessarily SQL based ones) There is still some interest. There is even somebody how ported it to gnome2. I'll see if I can get it in. grts Tim -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#459420: uswsusp maintainer script modifies /etc/uswsusp.conf
On Sat, Nov 22, 2008 at 03:24:11PM +0100, Peter Palfrader wrote: On Thu, 24 Jul 2008, Tim Dijkstra wrote: md2 is not usually enabled as a swapping device. It only gets enabled when I want to suspend to it. Ah, there is the problem then. I think this is fixed in a later version. It's not fixed in lenny either. Are you sure? If you do not have the partition you intend to use for suspend active as swap, you should get a question asking if you want to continue or not. Didn't you see that question? Could you please send the output of $ debconf-show uswsusp And it's still a policy violation. I don't see how you can justify downgrading this to normal. Because it will not happen except in very special cases. Also I thought this was already fixed for some time, I was just waiting for your conformation to close this bug. grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459420: uswsusp maintainer script modifies /etc/uswsusp.conf
On Sat, Nov 22, 2008 at 08:53:02PM +0100, Peter Palfrader wrote: On Sat, 22 Nov 2008, Tim Dijkstra wrote: It's not fixed in lenny either. Are you sure? If you do not have the partition you intend to use for suspend active as swap, you should get a question asking if you want to continue or not. Didn't you see that question? Could you please send the output of $ debconf-show uswsusp I saw no such question during upgrade. However manually running dpkg-reconfigure asked it, broke the config one last time and now it doesn't do it anymore. I do not understand why it wasn't asked on upgrade. It is asked at priority critical. Even if you, for some reason, did not see it, the default is to continue with your config file unchanged. But you say it broke it one more time? That is hard to believe. I've tested this quite a bit ... just did some more testing; I can't reproduce it. Where is that setting saved? debconf is not a registry so it must not be used for keeping state. The fact that you answered the question is remembered by debconf. That is a feature that is used by ALL packages. You can also be lucky that it does that or else you would go mad during every upgrade, because you would have to answer all question of the packages you upgrade all over again. If for some reason you blow away your debconf database, that is no problem. You will just have to answer the question again; That is right debconf is not a registry and we do not use it as one. grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#505793: pm-utils: please provide scriptlet to unmount network filesystems
Florian Lohoff schreef: On Sat, Nov 15, 2008 at 05:25:19PM +0100, Michael Biebl wrote: Florian Lohoff wrote: Package: pm-utils Version: 1.1.2.4-1 Severity: wishlist Hi, please provide a sleep scriptlet to unmount network filesystems. I am currently using this basically copied from /etc/init.d/umountnfs.sh which does more than needed (unmounting sysfs etc) ... This needs to be done before network manager is instructed to shut down networking e.g. i used priority 07 ... Why is it necessary to unmount the network filesystems and shouldn't they mounted on resume again. Because typically your network filesystems will not be there after resume. At least thats my typical use case - suspending at home - going to work - resuming - Well, that maybe typically for you;) TCP based filesystems will even timeout on the server as the tcp connection endpoint is gone and your tcp session will timeout. The only sane state is to unmount all network based filesystems on suspend. I never have had any problems with suspend and nfs (granted that is not TCP IIRC). We have machines with nfs home-dirs that do that daily here. A sane way could be to refuse suspend if there are open files on the network storage as the state could get severly garbled if suspending with potentially dirty cache content or even resuming with some expectation about the files state (which might have changed in the last hours while we were suspended) so you could garble servers files on resume because somebody else already appended to the file etc I do not have any profound knowledge about netword filesystems, but I do think this is highly unlikely. I mean, a network filesystem must be (by nature of going over an unreliable medium) tolerant to timeouts and clients comming back after being disconnected, etc. Also these filesystems are almost certainly developed with a multi-user environment in mind, so your argument about somebody else altering the file and causing corruption seems unlikely. Of course a user who resumes his machine could of course save his old file over a new one, but that wouldn't be different from somebody leaving his machine on for the night, comming back and doing the same. To conclude, I don't think thers is a technical reason to honour your whislist request in pm-utils. I do think there is probably a demant for something like this, but the best place to do something about it would be some higher level app. A level where people can interact and say yes/no or set a default, like gnome-volumne-manager or so. IIRC, it does already complain about mounted USD devices... grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#505793: pm-utils: please provide scriptlet to unmount network filesystems
Florian Lohoff schreef: On Mon, Nov 17, 2008 at 12:08:04PM +0100, Tim Dijkstra wrote: A sane way could be to refuse suspend if there are open files on the network storage as the state could get severly garbled if suspending with potentially dirty cache content or even resuming with some expectation about the files state (which might have changed in the last hours while we were suspended) so you could garble servers files on resume because somebody else already appended to the file etc I do not have any profound knowledge about netword filesystems, but I do think this is highly unlikely. I mean, a network filesystem must be (by nature of going over an unreliable medium) tolerant to timeouts and clients comming back after being disconnected, etc. Also these filesystems are almost certainly developed with a multi-user environment in mind, so your argument about somebody else altering the file and causing corruption seems unlikely. Of course a user who resumes his machine could of course save his old file over a new one, but that wouldn't be different from somebody leaving his machine on for the night, comming back and doing the same. The point is you halt the application in the middle of saving and continue to save on resume - Nothing the user can prevent - you are stopping the whole system. That seems a bit hard to trigger. You press save in your app and then you immediately try to suspend the system without waiting to see saving had finished? Still, I do not think that corruption on the server could be caused by this. Most likely your app would generate some error, in the worst case I think it would crash. To conclude, I don't think thers is a technical reason to honour your whislist request in pm-utils. I do think there is probably a demant for something like this, but the best place to do something about it would be some higher level app. A level where people can interact and say yes/no or set a default, like gnome-volumne-manager or so. The point is that all other tools to suspend have this option and it is used a lot. Suspend also takes down networking (/usr/lib/pm-utils/sleep.d/10NetworkManager) whats the point in this? I mean if you take down networking you also should take care of taking down network filestems before disabling networking. This is inconsitent behaviour ... That file is or should be part of NetworkManager. I must confess, I'm not using NetworkManager so I didn't notice it doing evil stuff. FWIW, I'm against bringing down network interfaces during suspend. Besides that, I thought that ifupdown already has some functionality that brings down networked filesystems if you bring down the interface. grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#505793: pm-utils: please provide scriptlet to unmount network filesystems
Florian Lohoff schreef: On Mon, Nov 17, 2008 at 03:01:09PM +0100, Tim Dijkstra wrote: Suspend also takes down networking (/usr/lib/pm-utils/sleep.d/10NetworkManager) whats the point in this? I mean if you take down networking you also should take care of taking down network filestems before disabling networking. This is inconsitent behaviour ... That file is or should be part of NetworkManager. I must confess, I'm not using NetworkManager so I didn't notice it doing evil stuff. FWIW, I'm against bringing down network interfaces during suspend. Thats just a false assumption - suspend/resume is for 100% of the Notebook users a mobility issue - so all assumptions about the outer world dont hold up on a suspend/resume cycle. You might be away 10 minutes and come back on the same network (unlikely) or stay away for years or move thousands of kilometers. Thats why usb disconnects all devices (user might decide to unplug) and all pcmcia devices should get ejected, network should be shut down and network filesystems should be unmounted. The world will most likely look different when you wakeup so dont take wrong assumptions. There must be also quite some people that suspend their notebook on their desk. Besides that most modern desktops I've seen also suspend just fine. Anyway, what I wanted to say in all my argumentation so far is that bringing down the network (and with it networked filesystems) is IMHO a policy decision that could be presented as a question by some highlevel app. Also to maybe give the user some time so save their stuff, etc. It should not default to `bring down' at the lowest layer (pm-utils), exactly because there is no reason to do it. Since most wired and wireless network cards have been fixed to survive a suspend/resume cycle there is no _need_ to bring them down. grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#503337: Bug present in unstable but not in testing
notfound 503337 0.7-1.2 found 503337 0.8-1 thanks Christian Perrier schreef: From what I read in the bug log and what I remember from the history of uswsusp, this RC bug is *not* present in testing. Testing has a 0.7-1.2 version which does not have the config change described by Tim Dijkstra in the bug log. As a consequence, I think we can safely decide that the following should be sent to [EMAIL PROTECTED]: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#503885: [Splashy-devel] Bug#503885: splashy fails to detect framebuffer-mode if used with lilo
Luis Mondesi schreef: On Tue, Oct 28, 2008 at 8:24 PM, Darshaka Pathirana [EMAIL PROTECTED] wrote: Package: splashy Version: 0.3.10-2 Severity: normal Hi! /etc/init.d/splashy tries to detect a valid framebuffer mode by looking in /proc/cmdline (to start splashy if not started in initramfs). The problem is that lilo has it's own vga= line and therefore /proc/cmdline does neither contain vga nor video. valid point! I thought nobody really uses lilo anymore... is there anything that says i'm using lilo while the system is booting? we might need to just check for splash on the cmdline file and try to start splashy ... the worse that can happen is that the user will get a -2 error (directfb cannot get a framebuffer). Yes, I agree, all this checking and double checking is a bit useless. The check in splashy itself should be enough. grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495319: debconf uses first value for select if old choice doesn't exist anymore; should at least be default
clone 495319 -1 retitle -1 On upgrades the default power off mode ends up as reboot severity -1 serious reassign -1 uswsusp thanks On Wed, Oct 22, 2008 at 03:25:18PM +0200, Bas Wijnen wrote: reassign 495319 debconf retitle 495319 debconf: uses first choice for select if old choice doesn't exist anymore thanks Hi, On Wed, Sep 03, 2008 at 10:13:14PM +0200, Tim Dijkstra wrote: Somehow the problem is caused by the fact that one of the config options changed name from 'poweroff' to 'shutdown'. If you previously had poweroff that value was no-longer valid, somehow you not end up with 'platform' which is the default... I was surprised to see that reboot is an option at all. But that isn't a bug, of course. :-) It is there for testing. The problem, AFAICS, is that debconf should treat this situation as unanswered question (which would result in asking again, or using the default), but does instead treat it as answered as [first choice]. A workaround for uswsusp would be to make platform the first choice (in debian/uswsusp.templates). Note that while new installs are not affected, upgrades from etch to lenny are, and there are about to be a whole lot of those. That's why I've now cloned the bug and set severity to serious. I'll upload a fix to testing proposed updates. grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501997: [Splashy-devel] Bug#501997: splashy: FTBFS when DEB_BUILD_OPTIONS is set to noopt, nostrip
Adam D. Barratt schreef: Tim Dijkstra wrote, 2008-10-15 12:38 +0200: Bradley Smith schreef: tags 501997 +patch I've tested this and it does indeed fix the problem. I have attached a patch with the actual changes needed. Let me know if you would like an NMU. I would first want to know why we need that header. Why does it only show up if you try to build with these special build options? If you're building with optimisations enabled, as a Debian package will by default, then libintl.h will pull in locale.h for you: [...] /* Optimized version of the function above. */ #if defined __OPTIMIZE__ !defined __cplusplus [...] /* We need LC_MESSAGES for `dgettext'. */ # include locale.h [...] DEB_BUILD_OPTIONS=noopt calls gcc with -O0, thereby not defining __OPTIMIZE__ and not implicitly pulling in locale.h. OK, very clear. I'll add this when I'm working on splashy for fixing the RC bug. grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501997: [Splashy-devel] Bug#501997: splashy: FTBFS when DEB_BUILD_OPTIONS is set to noopt, nostrip
Bradley Smith schreef: tags 501997 +patch I've tested this and it does indeed fix the problem. I have attached a patch with the actual changes needed. Let me know if you would like an NMU. I would first want to know why we need that header. Why does it only show up if you try to build with these special build options? grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486400: [Splashy-devel] Bug#486400: Bug#486400: Splashy works with hibernation, but ...
Luis Mondesi schreef: On Mon, Oct 13, 2008 at 6:13 AM, Tim Dijkstra [EMAIL PROTECTED] wrote: We tried to fix this in various ways from Splashy's end but we were not successful. It looks like uswsusp starts (dfb init) the framebuffer again when resuming at boot. Meaning, /sbin/splashy starts from initramfs and later uswsusp starts libsplashy again. When I was first looking at this, I made uswsusp start resume (and libsplashy) from initramfs _before_ the regular splashy. That way, there would never be two initialisations. The only drawback is that we have to start splashy somewhat later in the boot process. So apparently splashy's initscript was moved up in priority since the last time I looked at it. We weren't sure how to go about making both of them work. If you can point me in the right direction I can implement a fix. (Not sure about uswsusp as I have never seen the source code for it -- yet.) I'm planning to look at this bug wednesday evening. grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486400: [Splashy-devel] Bug#486400: Bug#486400: Splashy works with hibernation, but ...
Luis, Unfortunately I haven't looked at splashy (or any other FOSS project for that matter) for a while, but I noticed this bug is RC. The bug log shows you've been commenting on it, do you know the status? grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500794: uswsusp - s2ram does not follow kernel
Bastian Blank schreef: On Sun, Oct 05, 2008 at 11:39:15PM +0200, Tim Dijkstra wrote: Op Sun, 5 Oct 2008 14:55:30 +0200 schreef Bastian Blank [EMAIL PROTECTED]: On Thu, Oct 02, 2008 at 09:54:33AM +0200, Tim Dijkstra wrote: I looked at some numbers. We currently have +/- 400 machines listed, of which +/1 100 need no work around. Which is around 25% of all listed ones. correct It fixes suspend for more machines than it breaks. Without it (or similar functionality that can be provided by pm-utils in combination with various other packages) it will leave 75% of laptop users without a functioning suspend/resume. We already have a lot machines that do not need a quirk whitelisted, so the number of people we are `hurting' is far less than 25%. It hurts 100% of my machines, my workstation, my really old notebook, my current notebook and my test notebook. The notebooks have proper ACPI support for suspending. That is only you -- a minority of users. Let me reiterate. Suspend/resume support in the kernel is broken in the kernel for ~ 75% of machines. The symptoms are a freezing system or a system that comes up without video. Now, we have two options for suspend out of the box: 1) Let machines just try to suspend and risk dataloss 2) Only suspend machines of which we know it will work Of course in case 2) an unsupported machine doesn't mean it will never work for that machine. The person that has such a machine just has to actively figure out what `quirks' it needs, use the CLI and tell upstream so it will be added to the whitelist. Anyway: How do you intend to update the whitelist during the release cycle? Maybe I missed a mail on debian-release regarding this. That is indeed not so easy. Note that uswsusp was also part of etch. Note that nowadays in the most desktop environments suspend is triggered through HAL which has its own whitelist, uswsusp is than merely used as a back-end to execute all the quirks. IIRC, HAL's whitelist uses the same logic as uswusp: only suspend machines of which we know it will come up again. grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500794: uswsusp - s2ram does not follow kernel
Op Sun, 5 Oct 2008 14:55:30 +0200 schreef Bastian Blank [EMAIL PROTECTED]: On Thu, Oct 02, 2008 at 09:54:33AM +0200, Tim Dijkstra wrote: First of all, if you know what command-line arguments you need to suspend you can use those with --force. If you use hal (via gnome-power-manager) you can create a .fdi file that will by-pass the white-list. This is no scalable solution. No this is a way of getting your machine suspend in case you are not whitelisted yet. Do you have a number which amount of machines have problems? The number of machines that didn't came up by itself always used to be much bigger than the number that did. I looked at some numbers. We currently have +/- 400 machines listed, of which +/1 100 need no work around. linux-acpi is the responsible list for most of the problems. There is a standard interface for that. What do you mean standard interface? At the moment we have +/- 6 different ways of mucking around with the video card to get the resume succeed. Note that this application is mostly developed by two kernel-hackers (Pavel Machek and Rafael Wysocki) who have also authored a lot of the suspend/resume code in the kernel (especially software suspend). The reasoning always was: better safe than sorry. Let users first figure out what is safe consciously, before trying to suspend without knowing resume will succeed (and risking data-loss). Okay, then I insist that uswsusp is not installed along any Debian provided kernels and will enforce that with a conflict because it breaks suspend for many machines. This is nonsense. It fixes suspend for more machines than it breaks. Without it (or similar functionality that can be provided by pm-utils in combination with various other packages) it will leave 75% of laptop users without a functioning suspend/resume. We already have a lot machines that do not need a quirk whitelisted, so the number of people we are `hurting' is far less than 25%. grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500794: uswsusp - s2ram does not follow kernel
severity 500794 whishlist tags 500794 +willnotfix thanks First of all, if you know what command-line arguments you need to suspend you can use those with --force. If you use hal (via gnome-power-manager) you can create a .fdi file that will by-pass the white-list. Bastian Blank schreef: On Wed, Oct 01, 2008 at 07:54:54PM +0200, Sven Joachim wrote: But it does not know whether the machine will come up again, and even if that's the case, the screen may remain blank forever. Such is the case on my desktop. :-( Each kernel driver is allowed to veto suspension. The video card in a machine and its driver is of course of great influence on the ability of the machine to supsend and resume, but the not the only factor. There is also for example the BIOS. There's little point in suspending a machine that won't resume correctly afterwards. Do you have a number which amount of machines have problems? The number of machines that didn't came up by itself always used to be much bigger than the number that did. I must confess that I'm not following that number that well at the moment. Also there are some maior changes in very new kernels (.27 ?) that will change that number dramatically. The reasoning always was: better safe than sorry. Let users first figure out what is safe consciously, before trying to suspend without knowing resume will succeed (and risking data-loss). grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488144: #488144 - not all quirks redundant with 2.6.26 (please drop 98smart-kernel-video)
Op Sun, 28 Sep 2008 17:37:42 +0200 schreef Luk Claes [EMAIL PROTECTED]: Andres Salomon wrote: Hi, This works quite well for me on my x40. What do you think about including the new pm-utils in lenny? It'd be nice to have working suspend/resume for lenny for people w/ x40s. pm-utils unblocked Uhh, Michael, do we want the current version of pm-utils to go into Lenny? grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498917: uswsusp: hibernate de-formats swap partition
Claudio Sacerdoti Coen schreef: Package: uswsusp Version: 0.8-1.1 Severity: grave Justification: renders package unusable *** Please type your report below this line *** The bug only affects version 0.8-1.1 and not 0.7-1.2 and it is independent from the kernel version. During hibernation (s2disk), the swap partition is sort of de-formatted. At the next reboot the swap partition is no longer recognized and the system does not wake up. Moreover, it is now necessary to mkswap the partition in order to swap-on it again. The swap partition is used to store the system state during hibernation, that is why it is `de-formatter' as you call it. In case of a failed resume from hibernation mkswap should recognise that and `reformat' the swap-partition. So it seems that already something went wrong in the going down phase. Did you get any error messages during s2disk? grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497313: [Splashy-devel] Bug#497313: Bug#497313: splashy: deb hooks don't rebuild initramfs for all installed kernels
Mark Hedges schreef: 1) When I installed splashy with apt-get I was running my custom kernel. When I removed splashy I was running the stock kernel, but it rebuilt initramfs for the custom kernel. So it did not by default only rebuild the initramfs of the current kernel. You're right. It is not updating the initramfs of the current kernel (the one you are running), but it is updating the initramfs of a kernel which is sorted as highest by some algorithm I do not remember the details of. What is most important is that it will always be the same kernel, whatever one you are running at the moment. I think the sorting is such that under normal circumstances (as in: you just track the debian kernels) it will update the newest kernel. 2) What happens if I rebuilt the initramfs of kernel A to include splashy, but then I boot kernel B and remove the splashy package, then reboot to kernel A? Won't the kernel load the boot screen that was included? But I've removed it so what will happen after switching root? If you boot an initramfs with splashy included while it is removed from the root system, splashy will be started from initramfs as usual. The process will probably just survive the root-switching. There will however not be a splashy-update command on the root file system, so the progress bar will not be updated. Splashy will however timeout at some point. You will also still be able to kill splashy manually. So nothing dramatic will happen. You can also change the kernel command-line from grub and add nosplash to supress splashy. I think there should be a splashy update that wraps update-initramfs (or yaird or whatever you have selected) and keeps track of which kernels have splashy installed. That sounds much to fragile. Then `splashy_config -s theme` can call that automatically. (That was something that took me a while to figure out that I needed to do BTW.) [ this is not relevant for the current discussion, but it is probably a good idea to let splashy_config rebuild the initramfs as if it were a package update] As I explained before it was agreed under all maintainers supplying initramfs additions that rebuilding more than one initramfs on upgrades/removals is not going to happen by default. This is what was the concensus. Also `normal' users will find their system working as usual. It will only give (minor) problems if you start installing custom kernels. As I said, there is the possibility to configure initramfs-tools to rebuild all initramfses on removal, why isn't that a solution for your use case? Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497313: [Splashy-devel] Bug#497313: Bug#497313: splashy: deb hooks don't rebuild initramfs for all installed kernels
Op Wed, 3 Sep 2008 11:03:18 -0700 (PDT) schreef Mark Hedges [EMAIL PROTECTED]: As I said, there is the possibility to configure initramfs-tools to rebuild all initramfses on removal, why isn't that a solution for your use case? Oh I see, I didn't get that. That would work. Maybe a debconf option for Splashy that lets the user choose to configure it that way (non-default) would be a good thing for average desktop users who would want splashy on for all kernels but who don't want to mess with initramfs-tools config files or don't know how. Well, because it is an option of initramfs-tools it should be a debconf-option for that package. But yes, that would be an idea. I even implemented it already;), only the initramfs-tools maintainer chose not to use the patch. grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495319: Problem with renaming config option
severity 495319 important thanks Hi, Somehow the problem is caused by the fact that one of the config options changed name from 'poweroff' to 'shutdown'. If you previously had poweroff that value was no-longer valid, somehow you not end up with 'platform' which is the default... To conclude, this is not a problem for first installs, only for upgrades. So I don't think this bug is `grave'. grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497313: [Splashy-devel] Bug#497313: Bug#497313: splashy: deb hooks don't rebuild initramfs for all installed kernels
tags 497313 +wontfix thanks Mark Hedges schreef: I was going to write that this was an update-initramfs problem, but I just found in the manpage that one can call update-initramfs -u -k all to update initramfs for all kernel versions. I guess splashy should do this? Yeah I saw that too after I filed. Makes sense to me. If I installed splashy, then I want boot splash screens, right? Well, this is what splashy used to do, but there were complains about this. Some people want to keep old initramfses around which are known to work. Also updating all initramfses could potentially take a very long time. It is now agreed, that all packages that want to alter an initamfs are now supposed to call the same command which by default only rebuilds the initramfs of the current kernel. If you do want to rebuild all initramfses on an updte you can configure update-initramfs-tools to do that. I do not know the configuration file by hard but you can probably find it easily under /etc/. grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489939: Announce of the upcoming NMU for the uswsusp package
Hi Christian, I'll be away for two weeks. Please NMU for the string update if you feel like it. Grts TIm -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486352: can't confirm this bug
Richard Hartmann schreef: I just ran s2ram and it worked. I then was unable to revive the system, but looking on the keyboard, I saw a liitle blue half moon on F4.. Hmm.. Pressing Fn-F4 revives the system just fine. One note though (should I file a new bug for this?): /proc/acpi/ibm/fan loses its contents, fan speed is not reset to the prrvious value. That would be a bug in the kernel driver for your fan. It would be best if you report this to the linux bugzilla.kernel.org. grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489939: uswsusp Japanese po-debconf file is not updated correctly.
Hideki Yamane schreef: reopen 489939 stop Hi uswsusp Thank you for including translated po files. Thanks and thanks! But... debian/po/*.po file, especially ja.po is OLD one (maybe others too), Hmm, yes, somehow Japanese has almost everything fuzzy. The templates for the other languages are OK, though (so it seems). and unnecessary debian/po/ff/ directory was created. (and you update template.pot? empty and fuzzy line are created). Well, I changed the kernel config variable CONFIG_SOFTWARE_SUPSEND to CONFIG_HIBERNATION. I changed all the po files and unfuzzied them. I used ed to do that automatically, but somehow for Japanese this didn't work. Please use replace attached ja.po file to your package, then re-close this bug. Thanks. I'll do that. grts Tin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493560: uswsusp: LFS.patch should be applied directly
Op Sun, 03 Aug 2008 10:41:47 +0200 schreef Michael Biebl [EMAIL PROTECTED]: Package: uswsusp Version: 0.8-1 Severity: normal Hi Tim, debian/patches/LFS.patch modifies debian/rules and sets CFLAGS/LDFLAGS. As the patch is applied *after* debian/rules has been called, they will not have any effect. The general rule of thumb is, that changes to debian/ should be applied directly and changes to the upstream sources should be applied via distinct patches in debian/patches/. Hmm, isn't that one of yours? Uhm, no, indeed it was attached to the bug, seemed harmless and I dropped it into place. But, I guess your right. I'll have to fix it in the next upload. grts TIm -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490068: [Splashy-devel] Bug#490068: Bug#490068:
Luis Mondesi schreef: Try the same with evey other Debian package. Files under /etc are not removed unless you use --purge. See Splashy README and the FAQ section on the wiki. Indeed, it is in policy. That doesn't we should fix the symptom. But a) The problem is harmless; it's just an error message on a upgrade b) It only happens with people who used to have splashy and sysvinit and then remove both. That can't be that many people. grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443818: setting package to uswsusp, tagging 443818, tagging 443677
# Automatically generated email from bts, devscripts version 2.10.18.1 # # uswsusp (0.8-1) unstable; urgency=low # # * Disable erroneous comress ratio output. This is fixed upstream by now, but #it's not worth the trouble backporting IMHO. (closes: #443677, #443818) # package uswsusp tags 443818 + pending tags 443677 + pending -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488541: uswsusp: hangs system at startup
severity 488541 normal tags 488541 +moreinfo,+unreproducible thanks Op Sun, 29 Jun 2008 08:59:26 -0700 schreef [EMAIL PROTECTED]: Package: uswsusp Version: 0.7-1.2 Severity: critical Justification: breaks the whole system *** Please type your report below this line *** I installed uswsusp inadvertently because it is a recommendation of pmutils. The machine runs unattended 4 days of the week. During 4 unattended operation a power failure forced a reboot. Startup paused at the prompt from uswsusp and waited for three days until I was able to intervene. Normal email retrieval and other services were unavailable during this time. This is unacceptable behaviour. First of all, the bug you describe doesn't break anything. It just halts the boot process. Second, you shouldn't have uswsusp or pm-utils for that matter on a server, that's desktop software. Third, this shouldn't happen if you didn't suspend before the powerfailure. What message did you got? Without that information this report is not at all usefull. In the default case or installed case startup should resume if there is no intervention after a minute or two. There is a whistlist bug for that (382168). I'm still grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491418: setting package to uswsusp, tagging 491418, tagging 448484, tagging 470861, tagging 487656 ... ... ...
# Automatically generated email from bts, devscripts version 2.10.18.1 # # uswsusp (0.8-0.1) unstable; urgency=low # # * New models in the whitelist (closes: #473160, #467109, #475367, #448484, ##458566, #458566, #470314, #487656) # * Change CONFIG_SOFTWARE_SUSPEND to CONFIG_HIBERNATION (closes: #452030, #470861) # * Debconf translation updates (closes: #470578, #491418, #489939) #Thanks: Vincent Zweije [nl], Martin à gren [sv], Hideki Yamane [jp] # package uswsusp tags 491418 + pending tags 448484 + pending tags 470861 + pending tags 487656 + pending tags 489939 + pending tags 470314 + pending tags 458566 + pending -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488541: uswsusp: hangs system at startup
severity 488541 normal tags 488541 +moreinfo,+unreproducible thanks Op Sun, 29 Jun 2008 08:59:26 -0700 schreef [EMAIL PROTECTED]: Package: uswsusp Version: 0.7-1.2 Severity: critical Justification: breaks the whole system *** Please type your report below this line *** I installed uswsusp inadvertently because it is a recommendation of pmutils. The machine runs unattended 4 days of the week. During 4 unattended operation a power failure forced a reboot. Startup paused at the prompt from uswsusp and waited for three days until I was able to intervene. Normal email retrieval and other services were unavailable during this time. This is unacceptable behaviour. First of all, the bug you describe doesn't break anything. It just halts the boot process. Second, you shouldn't have uswsusp or pm-utils for that matter on a server, that's desktop software. Third, this shouldn't happen if you didn't suspend before the powerfailure. What message did you got? Without that information this report is not at all usefull. In the default case or installed case startup should resume if there is no intervention after a minute or two. There is a whistlist bug for that (382168). I'm still grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488541: uswsusp: hangs system at startup
severity 488541 normal tags 488541 +moreinfo,+unreproducible thanks Op Sun, 29 Jun 2008 08:59:26 -0700 schreef [EMAIL PROTECTED]: Package: uswsusp Version: 0.7-1.2 Severity: critical Justification: breaks the whole system *** Please type your report below this line *** I installed uswsusp inadvertently because it is a recommendation of pmutils. The machine runs unattended 4 days of the week. During 4 unattended operation a power failure forced a reboot. Startup paused at the prompt from uswsusp and waited for three days until I was able to intervene. Normal email retrieval and other services were unavailable during this time. This is unacceptable behaviour. First of all, the bug you describe doesn't break anything. It just halts the boot process. Second, you shouldn't have uswsusp or pm-utils for that matter on a server, that's desktop software. Third, this shouldn't happen if you didn't suspend before the powerfailure. What message did you got? Without that information this report is not at all usefull. In the default case or installed case startup should resume if there is no intervention after a minute or two. There is a whistlist bug for that (382168). I'm still grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457963: setting package to uswsusp, tagging 457963
# Automatically generated email from bts, devscripts version 2.10.18.1 # # uswsusp (0.8-0.1) unstable; urgency=low # # * Do not hang when user supplies an empty passphrase. Thanks Mikko Rapeli #for the patch. (closes: #457963) # package uswsusp tags 457963 + pending -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488541: uswsusp: hangs system at startup
severity 488541 normal tags 488541 +moreinfo,+unreproducible thanks Op Sun, 29 Jun 2008 08:59:26 -0700 schreef [EMAIL PROTECTED]: Package: uswsusp Version: 0.7-1.2 Severity: critical Justification: breaks the whole system *** Please type your report below this line *** I installed uswsusp inadvertently because it is a recommendation of pmutils. The machine runs unattended 4 days of the week. During 4 unattended operation a power failure forced a reboot. Startup paused at the prompt from uswsusp and waited for three days until I was able to intervene. Normal email retrieval and other services were unavailable during this time. This is unacceptable behaviour. First of all, the bug you describe doesn't break anything. It just halts the boot process. Second, you shouldn't have uswsusp or pm-utils for that matter on a server, that's desktop software. Third, this shouldn't happen if you didn't suspend before the powerfailure. What message did you got? Without that information this report is not at all usefull. In the default case or installed case startup should resume if there is no intervention after a minute or two. There is a whistlist bug for that (382168). I'm still grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#448450: setting package to uswsusp, tagging 448450, tagging 474389
# Automatically generated email from bts, devscripts version 2.10.18.1 # # uswsusp (0.8-1) unstable; urgency=low # # * Fix typo in README (closes: #448450) # * Remove libzf licence from copyright file (closes: #474389) package uswsusp tags 448450 + pending tags 474389 + pending -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#471120: setting package to uswsusp, tagging 471120
# Automatically generated email from bts, devscripts version 2.10.18.1 # # uswsusp (0.8-0.1) unstable; urgency=low # # * Make CLI arguments consistent, update manpages (closes: #471120) package uswsusp tags 471120 + pending -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486352: Need moreinfo
tags 486352 +moreinfo thanks Please send the output of s2ram -i thanks, Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490568: uswsusp: 'shutdown method' should be documented
The option 'shutdown method' is needed for my laptop for s2disk to function. The option is not documented anywhere in the included documentation. Where it should at least appear is 'man uswsusp.conf', which supposedly documents all options recognized by the program. Well, yes it shouldn't really be necessary, that is why I didn't add it. But I'll add it now... you're the second person requesting it. Also this might be in place: WARNING! Currently debconf overwrites this file, so changes should be made with dpkg-reconfigure uswsusp, or special care taken when updating the file (see Debian bug report 459420) That was a bug in an older version. Actually debconf doesn't override your local values. grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490568: setting package to uswsusp, tagging 470578, tagging 475367, tagging 490568
# Automatically generated email from bts, devscripts version 2.10.18.1 # # uswsusp (0.8-0.1) unstable; urgency=low # # * New models in the whitelist (closes: #473160, #467109, #475367) # * Document shutdown_method (closes: #490568) # * Debconf translation updates (closes: #470578) #Thanks: Vincent Zweije [nl], # package uswsusp tags 470578 + pending tags 475367 + pending tags 490568 + pending -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459420: severity of 459420 is normal
# Automatically generated email from bts, devscripts version 2.10.18.1 #Breaks only akward setups, is probably fixed for new installs severity 459420 normal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490068: [Splashy-devel] Bug#490068: is this splashy? looks like something else
reassign 490068 splashy,system-tools-backends
/etc/lsb-base-logging.sh: line 259: runlevel: command not found
/usr/sbin/invoke-rc.d: line 274: /sbin/runlevel: No such file or
This happened during today's upgrade. I know nothing more. I used to
have package splashy installed which apparently messes with some of
the lsb settings (it's ubuntufying them, making the startup sequence
look like Ubuntu's).
FYI, it has nothing to do with ubuntu.
Apparently splashy left /etc/lsb-base-logging.sh installed.
As it should on remove. You probably didn't purge splashy.
I'd report this bug to both splashy and system-tools-backends if I knew
how to. It's certainly splashy wreaking havoc, too, but I upgraded many
packages yesterday and none has complained except system-tools-backends
Niko Cavallini Araya schreef:
Lines 259 and 264 of lsb-base-logging.sh are:
_
255 # Splashy code
256 # Stop splashy on *dm but not if we are rebooting/shutting down
257 if [ -z ${RUNLEVEL:-} ]; then
258 # we need only the current level
259 RUNLEVEL=`runlevel | sed 's/^. //'`
260 # Bug # 470816
261 if [ -z $RUNLEVEL ]; then
262 # if we can't figure out the runlevel (such as when run
263 # from a cron job) then don't do anything with Splashy
264 exit $1
265 fi
266 fi
267 if [ x$RUNLEVEL = x6 ] || [ x$RUNLEVEL = x0 ]; then
268 return 0
269 fi
_
This are checking for $RUNLEVEL which in the first line of the error is
not found, so this looks like it comes from elsewhere not splashy.
No, you didn't read it right. If $RUNLEVEL is not defined it will run
/sbin/runlevel to find the $RUNLEVEL . Apparently the users machine
doesn't have a runlevel as you can see from the two error messages.
Now the question is: why not? Probably the user doesn't have sysvinit for
booting (but upstart or so?)...
Now splashy should have a dependency on sysvinit, but that doesn't help;
if it is _removed_ /etc/lsb-base-logging.sh is still there. The solution
to this (minor) problem would be to check for the splashy executable and
bail out if it is not there.
grts Tim
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443434: setting package to uswsusp, tagging 443434, tagging 459844, tagging 467109, tagging 473160 ... ...
# Automatically generated email from bts, devscripts version 2.10.18.1 # # uswsusp (0.8-0.1) unstable; urgency=low # # * New upstream release (closes: #459844). # * Add patch for LFS (closes: #451249) # * Remove use of grep in initramfs (closes: #443434) # * New models in the whitelist (closes: #473160, #467109) # * Ask shutdown_method at low priority (closes: #448536) package uswsusp tags 443434 + pending tags 459844 + pending tags 467109 + pending tags 473160 + pending tags 448536 + pending tags 451249 + pending -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452030: setting package to uswsusp, tagging 452030
# Automatically generated email from bts, devscripts version 2.10.18.1 # # uswsusp (0.8-0.1) unstable; urgency=low # # * Change CONFIG_SOFTWARE_SUSPEND to CONFIG_HIBERNATION (closes: #452030) package uswsusp tags 452030 + pending -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458308: setting package to uswsusp, tagging 458308
# Automatically generated email from bts, devscripts version 2.10.18.1 # # uswsusp (0.8-0.1) unstable; urgency=low # # * Update whitelist for MacBook1,1 (closes: #458308) package uswsusp tags 458308 + pending -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459420: uswsusp maintainer script modifies /etc/uswsusp.conf
Hi, First of all: the uswsusp maintainer scripts go to great length to keep all local modifications (I do NOT use debconf as a registry). It even keeps comments in the file. I consider any changes not kept bugs. That said, the script does some checks and such. It also has support for swap files, which make it necessary to recalculate the /dev node. In your case this seems to result in a mapping from /dev/md5 to /dev/mapper/cswap. It seems very likely to me that both have the same inode-number and are hence equivalent. If this is the case I do not consider it a serious bug, it is more a cosmetic issue. The more uswsusp only uses the device node to get the inode number. grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#448536: dpkg-reconfigure does not ask me which shutdown_method I want
Hi, Yes, I didn't see the need to ask the question; shutdown shouldn't be necessary, but I needed the debconf question to keep locally changed uswsusp.conf files. But I think you just convinced me to ask it with Low priority. grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459420: uswsusp maintainer script modifies /etc/uswsusp.conf
Op Wed, 23 Jul 2008 23:26:36 +0200 schreef Peter Palfrader [EMAIL PROTECTED]: On Wed, 23 Jul 2008, Tim Dijkstra wrote: That said, the script does some checks and such. It also has support for swap files, which make it necessary to recalculate the /dev node. In your case this seems to result in a mapping from /dev/md5 to /dev/mapper/cswap. It seems very likely to me that both have the same inode-number and are hence equivalent. You are mistaken. I see... Could you please test with the latest version (in unstable). Can you also send `cat /proc/swaps`? grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459420: uswsusp maintainer script modifies /etc/uswsusp.conf
Op Wed, 23 Jul 2008 23:58:48 +0200 schreef Peter Palfrader [EMAIL PROTECTED]: On Wed, 23 Jul 2008, Tim Dijkstra wrote: Could you please test with the latest version (in unstable). Not easily. Half the build-deps don't exist in stable. I think you can also test with an old version of the package with the _current_ maintainer scripts. Judging from your e-mail address you should be able to create such a package;) Can you also send `cat /proc/swaps`? md2 is not usually enabled as a swapping device. It only gets enabled when I want to suspend to it. Ah, there is the problem then. I think this is fixed in a later version. If your swap device isn't activated during configuration you should get a question asking you if you want to continue or not, saying yes should keep your configuration intact. grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#478395: uswsusp: FTBFS: libpci-dev replaced pciutils-dev
AnÃbal Monsalve Salazar schreef: Package: uswsusp Severity: serious Version: 0.7-1.1 Tags: sid Justification: fails to build from source pciutils-dev is now deprecated and uninstallable (strict versioned-dependency on pciutils). It was superseded by libpci-dev. Thanks for the NMU! grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#471120: uswsusp: inconsistent command line args / documentation
Op Sun, 16 Mar 2008 06:29:36 +0100 schreef Michael Biebl [EMAIL PROTECTED]: Package: uswsusp Version: 0.7-1.1 Severity: normal s2ram has a -f command line option. The man page says: [-f config_file] .. [-f, --force] The first -f config_files seems to be wrong. Indeed, I think it is On the other hand s2both has a -f option which seems to be -f config_file. This is inconsistent with s2ram. That is true, this is because s2both inherets funtionality from s2ram and s2disk.. We have decided to make the long command-line options consitent and depricate the short ones. IIRC the -f is from configfile. In addition, there seems to be no way for s2both to pass quirks to s2ram (as -f $quirks does for s2ram). That means, for a successful s2both, the machine must be whitelisted. Passing the options (from HAL) doesn't work for s2both. I need to update the manpage, but $ sudo s2both --help Usage: s2both [-h|--help] [-f|--config config] [-s|--image_size image_size] [-o|--resume_offset resume_offset] [--force] [--vbe_save] [--vbe_post] [--vbe_mode] [--radeontool] [--pci_save] [--acpi_sleep acpi_sleep] [resume_device] grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#456841: Bug in splashy
Hi, This is more a bug in splashy.h, it is solved in splashy svn by not using the gboolean types, but proper ints. grts Tim signature.asc Description: PGP signature
Bug#452367: [PATCH] Fix pm-is-supported
On Mon, 11 Feb 2008 00:41:33 -0500 Matthew William Cox [EMAIL PROTECTED] wrote: Hello, Stumbled across this bug tonight while trying to fix my pbook's hal suspend. Pursuant to Michael Biebl's Message #73, I cooked up the attached patch (also pasted inline for review): case $ARG in suspend) - grep -q mem /sys/power/state || exit 1 + grep -q mem /sys/power/state || + [ -c /dev/pmu -a -x /usr/sbin/s2ram ] || exit 1 ;; hibernate) grep -q disk /sys/power/state || exit 1 This checks that /dev/pmu exists and that we can run s2ram. Now, it doesn't check that the PMU actually is willing to suspend the machine, to do that, we need to tap the PMU_IOC_CAN_SLEEP ioctl on /dev/pmu. No way to do THAT from a shell script, but as far as I know, any machine with a PMU can suspend. That is not true. We could use `s2ram --test', that does the PMU_IOC_CAN_SLEEP test. Gnome-power-manager is willing and able to suspend my machine now. Yay! Very good. I hope that there will be an upload for pm-utils soonish... grts Tim signature.asc Description: PGP signature
Bug#452909: [PATCH] Support PMU Suspend Detection
On Sat, 02 Feb 2008 04:12:07 +0100 Michael Biebl [EMAIL PROTECTED] wrote: first of all, thanks for your efforts. The original intent of Tim Dykstra, who removed pm-pmu from the Debian pm-utils package, was, that the functionality of pm-pmu is already existent in s2ram (from the uswsusp package). Dropping pm-pmu from pm-utils also made pm-utils an architecture:all package, which means, it only contains shell scripts. This has the advantage, that pm-utils doesn't have to be compiled for all the different architectures. Adding some background to this... I did this also because I think the different interface to suspend the machine on powerpc is a kernel bug. Fixes for bugs/quirks are in the s2ram binary, hence that seemed to be the right place for this one too. Also, when I decided this, there was a kernel-patch (by Johannes Berg IIRC) with a fix for this behavior. At that time I got the impression that it was about to be accepted upstream. That strengthened my believe that pm-pmu shouldn't be in pm-utils. It appears the patch still isn't applied, I still think however that the current setup in debian is correct and the way to go. (If we manage to get a one line fix in one of pm-utils scripts.) grts Tim signature.asc Description: PGP signature
Bug#459020: php5-recode: Patch already in debian version
Package: php5-recode Version: 5.2.0-8+etch7 Followup-For: Bug #459020 Hi, I'm seeing similar behaviour. I tried to apply the patch in the php bts, but alas the debian etch version already has it. In other words this bug is not fixed by that patch. grts Tim -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-amd64 Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to nl_NL.utf8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459457: [Splashy-devel] Bug#459457: splashy: should not start if requirements aren't satistfied
On Mon, 07 Jan 2008 02:03:13 +0100 Luca Capello [EMAIL PROTECTED] wrote: Hi Tim, thank you for your fast reply and excuse me about my wrong statement in my previous mail, read below ;-) On Sun, 06 Jan 2008 23:08:18 +0100, Tim Dijkstra wrote: On Sun, 06 Jan 2008 18:56:19 +0100 Luca Capello [EMAIL PROTECTED] wrote: - when no vga= or video= command line is provided, AFAIK even if fbcon and vesafb are inserted (on Debian kernel they're compiled in by default), /proc/fb is present, but with zero size. Thus, when checking for /proc/fb to create /dev nodes we should check for its size (test -s). However, according to [6] and [7], if no vga= or video= parameter is specified, fb is not initialised ([2] and [4]). I'm using a system without vesafb, but with the ati vesa driver, which name I'm to lazy to look up now:) But anyway, I don't need a vga= parameter on /proc/cmdline. I've a ThinkPad T42p with an ATI card (radeonfb), but ATM its LCD is broken, so I cannot test (since I don't have any other external monitor at home). IIRC I wrote the initramfs scripts to test for some specific contents in /dev/fb, not just its size. If I'm right, the initramfs script does the following. 1) check if /sbin/splashy is executable: this is required 2) check if /proc/cmdline contains 'splash' (exits if not) or 'single' (exits if present): I'd prefer this tests as `splashy enable` It is nice to have a way to bail out the initramfs-script as early as possible. That way you can skip as many bugs as possible if your system doesn't boot because we introduced a problem in splashy. 3) insert fbcon and vesafb: at least on Debian stock kernels, these two modules are compiled in the kernel by default, so this step would be unnecessary, but splashy must support even non-stock and non-Debian kernels... 4) create the necessary device nodes WRT to /proc/fb: if that file exists, one node per each entry, otherwise only the first node. Here the problem: if /proc/fb exists but it's empty, no device node is created. This situation happens for example with the intelfb module without specifying any video mode at boot: = intelfb: Framebuffer driver for Intel(R) 830M/845G/852GM/855GM/865G/915G/915GM/945G/945GM chipsets intelfb: Version 0.9.4 intelfb: 00:02.0: Intel(R) 945GM, aperture size 256MB, stolen memory 7932kB intelfb: Non-CRT device is enabled ( LVDS port ). Disabling mode switching. intelfb: Video mode must be programmed at boot time. = Thus we should check if /proc/fb esists and it's not empty. FWIW, I found that the same erroneous check is present in the frambeffuer initramfs script [1]. Normally udev should create these nodes, but I guess it should work without udev too. 5) create the necessary device nodes for the consoles: required I think this should already have been done by some other initramfs script. 6) grep for VESA|VGA in /proc/fb: this was the check I erroneously stated it hadn't never worked for me, but I was wrong (since we're talking about initramfs here and indeed it works). I'd prefer this test to be performed inside splashy (which seems to be the case since 0.3.9), thus checking for /proc/fb *and* /dev/fb0 Yes, I think this was the test I talked about. Now, as a prophane, I see some improvements here: - point 2) and 6) should be managed inside splashy (giving verbose output if requested, so we can reuse it with the LSB functions) I think I agree about 6). About 2): well parsing /proc/cmdline seems a bit to distro specific. I would think this is best done in the initramfs. After all /proc/cmdline, is the boot cmdline, not splashy's. - while point 3), 4) and 5) could be completely managed by the framebuffer initramfs script (and they seem to be fully copied from there), as I already stated it seems necessary for non-stock and non-Debian kernels So, indeed in the debian package we can skip that part and just depend on the framebuffer script. Well, I'm not really overseeing the situation, but I think mandating vga= is not the proper way to go. I fully agree, but for the general case (vesafb) vga= is required by The patch I provided was a proof-of-concept: it works, now and without anything special. Since my C skills are poor, I haven't even tried to implement it in splashy, but the best solution will be there. I haven't got the time. I should actually be replying to this e-mail;) grts Tim signature.asc Description: PGP signature
Bug#459457: [Splashy-devel] Bug#459457: splashy: should not start if requirements aren't satistfied
On Sun, 06 Jan 2008 18:56:19 +0100 Luca Capello [EMAIL PROTECTED] wrote: - when no vga= or video= command line is provided, AFAIK even if fbcon and vesafb are inserted (on Debian kernel they're compiled in by default), /proc/fb is present, but with zero size. Thus, when checking for /proc/fb to create /dev nodes we should check for its size (test -s). However, according to [6] and [7], if no vga= or video= parameter is specified, fb is not initialised ([2] and [4]). I'm using a system without vesafb, but with the ati vesa driver, which name I'm to lazy to look up now:) But anyway, I don't need a vga= parameter on /proc/cmdline. IIRC I wrote the initramfs scripts to test for some specific contents in /dev/fb, not just its size. Well, I'm not really overseeing the situation, but I think mandating vga= is not the proper way to go. grts Tim signature.asc Description: PGP signature
Bug#458425: [INTL:nl] New po-debconf translation in Dutch for dash.
Package: dash Version: 0.4.18 Severity: wishlist Tags: patch,l10n This is the new po-debconf template translation in Dutch. Greetings Tim Dijkstra# #Translators, if you are not familiar with the PO format, gettext #documentation is worth reading, especially sections dedicated to #this format, e.g. by running: # info -n '(gettext)PO Files' # info -n '(gettext)Header Entry' # #Some information specific to po-debconf are available at #/usr/share/doc/po-debconf/README-trans # or http://www.debian.org/intl/l10n/po-debconf/README-trans # #Developers do not need to manually edit POT or PO files. # msgid msgstr Project-Id-Version: dash 0.4.18\n Report-Msgid-Bugs-To: Source: [EMAIL PROTECTED] POT-Creation-Date: 2007-11-11 19:37+\n PO-Revision-Date: 2007-11-12 20:52+0100\n Last-Translator: Tim Dijkstra [EMAIL PROTECTED]\n Language-Team: Debian Dutch [EMAIL PROTECTED]\n MIME-Version: 1.0\n Content-Type: text/plain; charset=iso-8859-15\n Content-Transfer-Encoding: 8bit\n #. Type: boolean #. Description #: ../dash.templates.in:2001 msgid Install dash as /bin/sh? msgstr dash als /bin/sh installeren? #. Type: boolean #. Description #: ../dash.templates.in:2001 msgid The default /bin/sh shell on Debian and Debian-based systems is bash. msgstr De standaard /bin/sh shell op Debian en Debian-gebaseerde systemen is bash. #. Type: boolean #. Description #: ../dash.templates.in:2001 msgid However, since the distribution policy requires all shell scripts using /bin/ sh to be POSIX compliant, any shell that conforms to POSIX, such as dash, can serve as /bin/sh. You may wish to do this because dash is faster and smaller than bash. msgstr Debian-beleid eist echter dat alle shell-scripts die /bin/sh gebruiken moeten voldoen aan de POSIX-standaard. Elke shell die zich conformeert aan POSIX, zoals dash, kan dienst doen als /bin/sh. Een reden om dit te overwegen is dat dash sneller en kleiner is dan bash.
Bug#452367: hal: can no longer suspend
On Fri, 14 Dec 2007 15:29:36 + Benoît Dejean [EMAIL PROTECTED] wrote: Le dimanche 25 novembre 2007 à 22:27 +0100, Michael Biebl a écrit : Benoît Dejean schrieb: Le dimanche 25 novembre 2007 à 20:11 +0100, Tim Dijkstra a écrit : On Thu, 22 Nov 2007 21:44:49 +0100 Benoît Dejean [EMAIL PROTECTED] wrote: \echo -n mem /sys/power/state -bash: echo: write error: Invalid argument Than suspend to ram has never worked on your machine with pm-utils. It was not recommended with previous versions, so i haven't got it. So this needs a quirk/fix/workaround in pm-utils. All quirks are in the uswsusp package. If you install it you'll have a binary s2ram, that will use some iotcl to suspend the machine. pm-utils recommends it, so under normal circumstances you should have it. Since uswusp is not installable on PPC ... Well, initially pm-utils contained a small utility called pm-pmu, which just did that: poke /dev/pmu via ioctl, to put ppc machines to sleep. Tim decided to keep pm-utils a arch:all package and not ship this tool in pm-utils and instead rely on s2ram from uswsusp, to avoid duplicated functionality (and imho his reasons are sound). Tim, why is uswsusp not available on PPC (and only for i386/amd64)? Is it because of s2ram or s2disk? Should the uswsusp packge be split? Could we support more platforms this way? Any news ? s2ram is now installable on ppc and works. But hall doesn't yet? Can you see what output you get from: pm-is-supported --suspend echo yup! s2ram --test /dev/null echo yup! grts Tim signature.asc Description: PGP signature
Bug#455593: uswsusp: Prompts for resume device when I boot up
On Tue, 11 Dec 2007 01:02:19 + Sam Morris [EMAIL PROTECTED] wrote: Package: uswsusp Version: 0.3~cvs20060928-7 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Since I installed linux-image-2.6.23-2-686, every time I boot up, I get the following message: Could not stat the resume device file '/dev/mapper/swap2'. Please type in the full path name to try again, or press ENTER to boot the system. Did you rename your swap device? Is /dev/mapper/swap2 still present? If not rerun ``dpkg-reconfigure uswususp''. But this happens even though I boot up having not just hibernated the system. That's because it has to look at the swap device to determine if there is a hibernate-image or not, or in other words, if you did hibernate or not. grts Tim signature.asc Description: PGP signature
Bug#300231: O: libghttp -- original GNOME HTTP client library - run-time kit
Lucas Nussbaum schreef: libghttp has been orphaned since 2005. It would be great to get rid of it, but some packages are still using it: * digitaldj (dep on libghttp): could probably be removed. we already have a lot of MP3 players in the archive. Well, it still has some users (according to popcon some 90 have it installed) and there doesn't seem a lot wrong with it. Any comments? You want to get rid of libghttp because of it being a qa-maitaince burden? grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452367: hal: can no longer suspend
On Sun, 25 Nov 2007 22:27:38 +0100 Michael Biebl [EMAIL PROTECTED] wrote: Benoît Dejean schrieb: Le dimanche 25 novembre 2007 à 20:11 +0100, Tim Dijkstra a écrit : On Thu, 22 Nov 2007 21:44:49 +0100 Benoît Dejean [EMAIL PROTECTED] wrote: \echo -n mem /sys/power/state -bash: echo: write error: Invalid argument Than suspend to ram has never worked on your machine with pm-utils. It was not recommended with previous versions, so i haven't got it. So this needs a quirk/fix/workaround in pm-utils. All quirks are in the uswsusp package. If you install it you'll have a binary s2ram, that will use some iotcl to suspend the machine. pm-utils recommends it, so under normal circumstances you should have it. Since uswusp is not installable on PPC ... Well, initially pm-utils contained a small utility called pm-pmu, which just did that: poke /dev/pmu via ioctl, to put ppc machines to sleep. Tim decided to keep pm-utils a arch:all package and not ship this tool in pm-utils and instead rely on s2ram from uswsusp, to avoid duplicated functionality (and imho his reasons are sound). Tim, why is uswsusp not available on PPC (and only for i386/amd64)? Is it because of s2ram or s2disk? Should the uswsusp packge be split? Could we support more platforms this way? I added ppc support to uswsusp and also update the control file with an `Architecture: i386 amd64 powerpc' line. But apparently it doesn't get build. I now vaguely remember that there also is some override somewhere. Maybe I have to bug ftp-master for that? Any idea Michael? grts Tim signature.asc Description: PGP signature
Bug#452848: s2ram: After suspend cpufreq governer for cpu1 changed to performance
On Sun, 25 Nov 2007 17:36:06 +0100 Kurt Roeckx [EMAIL PROTECTED] wrote: Package: uswsusp Version: 0.3~cvs20060928-7 Hi, I have a dual core system and installed cpufrequtils which sets my both cores governer to ondemand. And after I do a suspend to ram, and it comes back, the second core is now set to performance instead of ondemand while the first is still set to ondemand. I don't know if this is a kernel bug or not. Please reassign if needed. I think this is pm-utils bug: 452620. grts Tim signature.asc Description: PGP signature
Bug#452367: hal: can no longer suspend
On Thu, 22 Nov 2007 21:44:49 +0100 Benoît Dejean [EMAIL PROTECTED] wrote: Le jeudi 22 novembre 2007 à 11:29 +0100, Martin Pitt a écrit : Hi, Benoît Dejean [2007-11-22 10:42 +0100]: hal can no longer suspend my laptop. gnome-power-manager no longer shows the suspend option and $ sudo /usr/sbin/pm-suspend Error: kernel cannot suspend to ram. Just a quick note: This is an issue in pm-utils. On powerpc, /sys/power/state only contains 'disk', not 'mem'. I don't you suspend to disk, on suspend to ram. On powerpc with a PMU the prefered way of querying sleep capability and causing suspend-to-ram is to use a sysctl (see attached script from Ubuntu's powermanagement-interface). I believe that echoing 'mem' to /sys/power/state works, too, though. Not really, this has never worked on my ibook \echo -n mem /sys/power/state -bash: echo: write error: Invalid argument Than suspend to ram has never worked on your machine with pm-utils. So this needs a quirk/fix/workaround in pm-utils. All quirks are in the uswsusp package. If you install it you'll have a binary s2ram, that will use some iotcl to suspend the machine. pm-utils recommends it, so under normal circumstances you should have it. grts Tim signature.asc Description: PGP signature
Bug#450601: pm-utils suck hard on non-ACPI systems
On Thu, 15 Nov 2007 17:49:30 +0100 Johannes Berg [EMAIL PROTECTED] wrote: I thought s2disk was also tested and working, but apparently not. If you could point me at some code that does the job or some docs, I could add it to s2disk. s2disk needs to not try to set the platform method if that method is unavailable. I think it does by default. It's also an config option. pm-hibernate has no such option and thus breaks. Not sure why s2disk is involved at all? s2disk isn't involved per se, but it can bring your machine in hibernation. It can work as a `back end' in pm-hibernate. ... I'm not sure we're understanding each other. In my understanding, on a powermac, the interface /sys/power/state was not working for suspend-to-ram. If I read your e-mails to this report it isn't working for hibernation either. Right? Now, for S3 there were some ioctl that had to be used. This is now in the s2ram binary. Are you saying that for S4 we need something similar (eg. some binary that pokes some ioclts?) If yes, I think we'll have to add that to uswsusp. pm-utils is just a bunch of (arch: all) scripts, that uses the /sys/power/state interface. grts Tim signature.asc Description: PGP signature
Bug#450601: pm-utils suck hard on non-ACPI systems
On Tue, 13 Nov 2007 14:09:37 +0100 Johannes Berg [EMAIL PROTECTED] wrote: I consider the non-functioning /sys/power/state interface a kernel bug. That's fine for the part about suspend to RAM. However, with suspend to disk, the interface is functioning *perfectly*, it just doesn't offer the platform method. ah, ok. I'll look into that. I thought s2disk was also tested and working, but apparently not. If you could point me at some code that does the job or some docs, I could add it to s2disk. s2disk needs to not try to set the platform method if that method is unavailable. I think it does by default. It's also an config option. grts Tim signature.asc Description: PGP signature
Bug#450601: pm-utils suck hard on non-ACPI systems
On Fri, 09 Nov 2007 13:10:40 +0100 Johannes Berg [EMAIL PROTECTED] wrote: uswsusp should work nowadays. If not, please file a bug there. Actually, it doesn't, but that's unrelated, I don't want to use it. I consider the non-functioning /sys/power/state interface a kernel bug. s2ram and s2disk provide extra features and workarounds for machines where the bare interface doesn't work. It is mostly video-adapter related hacks but in the case of powerpc s2ram it uses some ioctls to get it to suspend to ram. I thought s2disk was also tested and working, but apparently not. If you could point me at some code that does the job or some docs, I could add it to s2disk. grts Tim signature.asc Description: PGP signature
Bug#450601: pm-utils suck hard on non-ACPI systems
On Thu, 08 Nov 2007 14:55:21 +0100 Johannes Berg [EMAIL PROTECTED] wrote: Package: pm-utils Version: 0.99.2-3 Severity: normal pm-utils are unable to hibernate my powermac. I do not have a 'platform' /sys/power/disk mode and this makes pm-utils give up on hibernating. pm-utils are unable to suspend my powerbook. powerbooks don't support suspending via /sys/power/state but need to use the PMU ioctls instead. uswsusp should work nowadays. If not, please file a bug there. grts Tim signature.asc Description: PGP signature
Bug#448137: the parameters --quirk-s3-* forbid any other parameter to be passed to s2ram
On Fri, 26 Oct 2007 11:54:32 +0200 Mau [EMAIL PROTECTED] wrote: Package: pm-utils Version: 0.99.2-3 Severity: serious Tags: patch --- Please enter the report below this line. --- When any of the --quirk-s3-* parameters is passed to pm-suspend, all the other parameters are lost: in the pm-action script the value of a variable is being replaced instead of being concatenated. Ah, good catch. Will fix it in the new upload. grts Tim signature.asc Description: PGP signature
Bug#446948: /usr/bin/directfb-config: Patches from unstable not in experimental version
Package: libdirectfb-dev Version: 1.0.1-2 Severity: important File: /usr/bin/directfb-config It seems you forgot to update some of the patches in debian/patches in your experimental branch. For example bug #407935 was fixed in 0.9.25.1-6, but the updated patch isn't present in 1.0.1-2 grts Tim -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (700, 'testing'), (99, 'unstable'), (19, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22.6 Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to nl_NL.utf8) Shell: /bin/sh linked to /bin/dash Versions of packages libdirectfb-dev depends on: ii libdirectfb-1.0-0 1.0.1-2 direct frame buffer graphics - sha ii libdirectfb-extra 0.9.25.1-6 direct frame buffer graphics - ext ii libfreetype6-dev2.3.5-1+b1 FreeType 2 font engine, developmen ii libjpeg62-dev 6b-14Development files for the IJG JPEG ii libmpeg3-dev1.5.4-5 Headers and static libraries for l ii libpng12-dev1.2.15~beta5-2 PNG library - development ii libsysfs-dev2.1.0-2+b1 interface library to sysfs - devel ii libx11-dev 2:1.0.3-7X11 client-side library (developme ii libxext-dev 1:1.0.3-2X11 miscellaneous extensions libra ii x11proto-core-dev 7.0.11-1 X11 core wire protocol and auxilia ii zlib1g-dev 1:1.2.3.3.dfsg-6 compression library - development libdirectfb-dev recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#446009: menu: [intl:nl] Add untranslated strings in update.
Package: menu Version: 2.1.35 Followup-For: Bug #446009 This nl.po adds the missing strings in my previous nl.po -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (700, 'testing'), (99, 'unstable'), (19, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22.6 Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to nl_NL.utf8) Shell: /bin/sh linked to /bin/dash Versions of packages menu depends on: ii dpkg 1.14.5 package maintenance system for Deb ii libc6 2.6.1-1+b1 GNU C Library: Shared libraries ii libgcc1 1:4.2.1-4 GCC support library ii libstdc++64.2.1-4The GNU Standard C++ Library v3 menu recommends no packages. -- no debconf information msgid msgstr Project-Id-Version: menu\n Report-Msgid-Bugs-To: [EMAIL PROTECTED] POT-Creation-Date: 2007-10-05 07:30+0200\n PO-Revision-Date: 2007-10-14 21:49+0200\n Last-Translator: Tim Dijkstra [EMAIL PROTECTED]\n Language-Team: Debian l10n Dutch [EMAIL PROTECTED]\n MIME-Version: 1.0\n Content-Type: text/plain; charset=iso-8859-15\n Content-Transfer-Encoding: 8bit\n #: ../install-menu/functions.cc:92 msgid Zero-size argument to print function. msgstr Afdrukfunctie heeft een argument van grootte nul. #: ../install-menu/install-menu.cc:202 msgid install-menu: checking directory %1\n msgstr install-menu: controleren van map %1\n #: ../install-menu/install-menu.cc:215 msgid install-menu: creating directory %1:\n msgstr install-menu: aanmaken van map %1:\n #: ../install-menu/install-menu.cc:217 msgid Could not create directory(%1): %2 msgstr Kon map(%1) niet maken: %2 #: ../install-menu/install-menu.cc:219 msgid Could not change directory(%1): %2 msgstr Kon map(%1) niet veranderen: %2 #: ../install-menu/install-menu.cc:222 msgid install-menu: directory %1 already exists\n msgstr install-menu: de map %1 bestaat al\n #. Do not translate supported #: ../install-menu/install-menu.cc:447 msgid install-menu: [supported]: name=%1\n msgstr install-menu: [supported]: naam=%1\n #: ../install-menu/install-menu.cc:464 msgid Menu entry lacks mandatory field \%1\.\n msgstr De menu-ingang mist een verplicht veld \%1\.\n #: ../install-menu/install-menu.cc:470 msgid Unknown value for field %1=\%2\.\n msgstr Onbekende waarde voor veld %1=\%2\.\n #. Do not translate quoted text #: ../install-menu/install-menu.cc:617 msgid install-menu: \hotkeycase\ can only be \sensitive\ or \insensitive\\n msgstr install-menu: \hotkeycase\ kan alleen \sensitive\ of \insensitive\ zijn\n #: ../install-menu/install-menu.cc:647 msgid install-menu: Warning: Unknown identifier `%1' on line %2 in file %3. Ignoring.\n msgstr install-menu: Waarschuwing: Onbekende identifier '%1' op regel %2 in bestand %3. Wordt genegeerd.\n #: ../install-menu/install-menu.cc:657 msgid install-menu: %1 must be defined in menu-method %2 msgstr install-menu: %1 moet gedefinieerd zijn in menumethode %2 #: ../install-menu/install-menu.cc:824 msgid Cannot open file %1 (also tried %2).\n msgstr Kan het bestand %1 niet openen (ook %2 is geprobeerd).\n #: ../install-menu/install-menu.cc:832 ../install-menu/install-menu.cc:839 #: ../install-menu/install-menu.cc:847 msgid Cannot open file %1.\n msgstr Kan het bestand %1 niet openen.\n #: ../install-menu/install-menu.cc:849 msgid In order to be able to create the user config file(s) for the window manager,\n the above file needs to be writeable (and/or the directory needs to exist).\n msgstr Om de configuratiebestanden van de gebruiker voor de vensterbeheerder te kunnen maken,\n moet het bovenstaande bestand schrijfbaar zijn (en/of de map moet bestaan).\n #: ../install-menu/install-menu.cc:871 msgid Warning: the string %1 did not occur in template file %2\n msgstr Waarschuwing: de string %1 komt niet voor in het sjabloonbestand %2\n #. Don't translate quoted string #: ../install-menu/install-menu.cc:896 msgid install-menu [-vh] menu-method\n Read menu entries from stdin in \update-menus --stdout\ format\n and generate menu files using the specified menu-method.\n Options to install-menu:\n -h --help: this message\n --remove : remove the menu instead of generating it.\n -v --verbose : be verbose\n msgstr install-menu [-vh] menumethode\n Lees menu-ingangen van stdin in \update-menus --stdout\ indeling\n en maak menubestanden gebruikmakend van de opgegeven menumethode.\n Opties voor install-menu:\n -h --help: dit bericht\n --remove : verwijder het menu in plaats van het aan te maken.\n -v --verbose : wees uitvoerig\n #: ../install-menu/install-menu.cc:943 msgid install-menu: no menu-method script specified! msgstr install-menu: geen menumethode-script opgegeven! #: ../install-menu/install-menu.cc:956 msgid Cannot open script %1 for reading.\n msgstr Kan het script %1 niet lezen.\n #: ../install-menu/install-menu.cc:979 msgid Warning: script %1
Bug#446009: [intl:nl] Updated nl.po for menu
Package: menu Version: 2.1.35 Severity: wishlist Tags: patch l10n Find attached the updated nl.po, grts Tim -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (700, 'testing'), (500, 'stable'), (99, 'unstable'), (19, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22.6 Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to nl_NL.utf8) Shell: /bin/sh linked to /bin/dash Versions of packages menu depends on: ii dpkg 1.14.5 package maintenance system for Deb ii libc6 2.6.1-1+b1 GNU C Library: Shared libraries ii libgcc1 1:4.2.1-4 GCC support library ii libstdc++64.2.1-4The GNU Standard C++ Library v3 menu recommends no packages. -- no debconf information msgid msgstr Project-Id-Version: menu\n Report-Msgid-Bugs-To: [EMAIL PROTECTED] POT-Creation-Date: 2007-10-05 07:30+0200\n PO-Revision-Date: 2007-10-09 21:08+0200\n Last-Translator: Tim Dijkstra [EMAIL PROTECTED]\n Language-Team: Debian l10n Dutch [EMAIL PROTECTED]\n MIME-Version: 1.0\n Content-Type: text/plain; charset=iso-8859-15\n Content-Transfer-Encoding: 8bit\n #: ../install-menu/functions.cc:92 msgid Zero-size argument to print function. msgstr Afdrukfunctie heeft een argument van grootte nul. #: ../install-menu/install-menu.cc:202 msgid install-menu: checking directory %1\n msgstr install-menu: controleren van map %1\n #: ../install-menu/install-menu.cc:215 msgid install-menu: creating directory %1:\n msgstr install-menu: aanmaken van map %1:\n #: ../install-menu/install-menu.cc:217 msgid Could not create directory(%1): %2 msgstr Kon map(%1) niet maken: %2 #: ../install-menu/install-menu.cc:219 msgid Could not change directory(%1): %2 msgstr Kon map(%1) niet veranderen: %2 #: ../install-menu/install-menu.cc:222 msgid install-menu: directory %1 already exists\n msgstr install-menu: de map %1 bestaat al\n #. Do not translate supported #: ../install-menu/install-menu.cc:447 msgid install-menu: [supported]: name=%1\n msgstr install-menu: [supported]: naam=%1\n #: ../install-menu/install-menu.cc:464 msgid Menu entry lacks mandatory field \%1\.\n msgstr De menu-ingang mist een verplicht veld \%1\.\n #: ../install-menu/install-menu.cc:470 msgid Unknown value for field %1=\%2\.\n msgstr Onbekende waarde voor veld %1=\%2\.\n #. Do not translate quoted text #: ../install-menu/install-menu.cc:617 msgid install-menu: \hotkeycase\ can only be \sensitive\ or \insensitive\\n msgstr install-menu: \hotkeycase\ kan alleen \sensitive\ of \insensitive\ zijn\n #: ../install-menu/install-menu.cc:647 msgid install-menu: Warning: Unknown identifier `%1' on line %2 in file %3. Ignoring.\n msgstr install-menu: Waarschuwing: Onbekende identifier '%1' op regel %2 in bestand %3. Wordt genegeerd.\n #: ../install-menu/install-menu.cc:657 msgid install-menu: %1 must be defined in menu-method %2 msgstr install-menu: %1 moet gedefinieerd zijn in menumethode %2 #: ../install-menu/install-menu.cc:824 msgid Cannot open file %1 (also tried %2).\n msgstr Kan het bestand %1 niet openen (ook %2 is geprobeerd).\n #: ../install-menu/install-menu.cc:832 ../install-menu/install-menu.cc:839 #: ../install-menu/install-menu.cc:847 msgid Cannot open file %1.\n msgstr Kan het bestand %1 niet openen.\n #: ../install-menu/install-menu.cc:849 msgid In order to be able to create the user config file(s) for the window manager,\n the above file needs to be writeable (and/or the directory needs to exist).\n msgstr Om de configuratiebestanden van de gebruiker voor de vensterbeheerder te kunnen maken,\n moet het bovenstaande bestand schrijfbaar zijn (en/of de map moet bestaan).\n #: ../install-menu/install-menu.cc:871 msgid Warning: the string %1 did not occur in template file %2\n msgstr Waarschuwing: de string %1 komt niet voor in het sjabloonbestand %2\n #. Don't translate quoted string #: ../install-menu/install-menu.cc:896 msgid install-menu [-vh] menu-method\n Read menu entries from stdin in \update-menus --stdout\ format\n and generate menu files using the specified menu-method.\n Options to install-menu:\n -h --help: this message\n --remove : remove the menu instead of generating it.\n -v --verbose : be verbose\n msgstr install-menu [-vh] menumethode\n Lees menu-ingangen van stdin in \update-menus --stdout\ indeling\n en maak menubestanden gebruikmakend van de opgegeven menumethode.\n Opties voor install-menu:\n -h --help: dit bericht\n --remove : verwijder het menu in plaats van het aan te maken.\n -v --verbose : wees uitvoerig\n #: ../install-menu/install-menu.cc:943 msgid install-menu: no menu-method script specified! msgstr install-menu: geen menumethode-script opgegeven! #: ../install-menu/install-menu.cc:956 msgid Cannot open script %1 for reading.\n msgstr Kan het script %1 niet lezen.\n #: ../install-menu/install-menu.cc:979 msgid
Bug#445998: ITP: eaccelerator -- PHP accelerator, optimizer, and dynamic content cache
On Tue, 09 Oct 2007 21:29:38 +0400 Alexander Gerasiov [EMAIL PROTECTED] wrote: Package: wnpp Severity: wishlist Owner: Alexander Gerasiov [EMAIL PROTECTED] * Package name: eaccelerator Version : 0.9.5.2 Upstream Author : eaccelerator team http://eaccelerator.net/wiki/Team * URL : http://eaccelerator.net * License : GPL Programming Lang: C Description : PHP accelerator, optimizer, and dynamic content cache Some dummy packages available for now in my repository at http://gq.net.ru/debian I'm going to upload it after fixing some packaging issues. Feel free to kick me by mail, if I'm too slow. Are the license issues finally solved then? Last time I checked binaries were not distributable, see for example: http://www.mailarchives.org/list/debian-devel/msg/2005/08164 grts Tim signature.asc Description: PGP signature
Bug#443539: uswsusp: resume complains at boot and fails with missing libpcre.so.3 resuming after s2disk
On Sat, 22 Sep 2007 11:03:43 +0200 chryjs [EMAIL PROTECTED] wrote: Package: uswsusp Version: 0.7-1 Severity: normal resume fails loading image on RESUME device, complaining missing libpcre.so.3 at boot. The boot continues as if there was no uswsusp image stored (and then goes on fsck's...). After the system is back to normal op's : $ ldd /usr/lib/uswsusp/resume [...] libpcre.so.3 = /usr/lib/libpcre.so.3 (0x2aab5c41d000) [...] NB: not any missing lib between brackets. Well, that is doubly weird: first because the i386 version doesn't have that dependency, and second because the initramfs script should have copied all dependencies automatically... Can you maybe make a copy of your current initramfs and run update-initramfs -u? grts Tim signature.asc Description: PGP signature
Bug#443235: uswsusp: does not update initrd
On Thu, 20 Sep 2007 08:19:54 +0200 [EMAIL PROTECTED] wrote: Tim Dijkstra wrote: Did you read the NEWS file? Yes I did. But as I understand the initrd of the *current* kernel version should have been updated anyway which is not the case although the .conf file contains the line update_initramfs=yes. OK. How did you check that the initramfs was not updated? In that case you should just get a message from resume about non matching versions, not a BUG(). A manual update-initramfs did work? grts Tim signature.asc Description: PGP signature
Bug#443235: uswsusp: does not update initrd
On Wed, 19 Sep 2007 22:09:11 +0200 Cihan [EMAIL PROTECTED] wrote: Package: uswsusp Version: 0.7-1 Severity: normal After updating the package from 0.6~cvs20070618-1 to 0.7-1 the initrd images are not recreated which is why resume fails with a kernel BUG after suspending to disk. Did you read the NEWS file? grts Tim signature.asc Description: PGP signature
Bug#442470: uswsusp: s2disk should try and warn that correct kernel no longer available
On Sun, 16 Sep 2007 14:23:03 +0100 Dominic Hargreaves [EMAIL PROTECTED] wrote: Package: uswsusp Version: 0.3~cvs20060928-7 Severity: minor If the kernel is upgraded and system subsequently suspended, it will not be possible to resume (the resume scripts check for this condition and abort). Hmm, I agree this is a nice possibility to shoot yourself in the foot. But I also think that most people that have just done an kernel upgrade will reboot. It would be nice if s2disk could try and detect whether the booted kernel is still available, and abort if not. As this is probably needs to be a Debian-specific feature, perhaps a wrapper script to s2disk would be best. If you think this is a good idea, I am happy to implement the feature (and test it on unstable; currently I only use s2disk on an etch system but I believe that this bug report is valid for the version in unstable too). Depends a bit on how you think to do this. And how fragile the implementation will be. Can you maybe explain how you think to detect this? grts Tim signature.asc Description: PGP signature
Bug#437094: uswsusp: s2disk fails with kernels 2.6.21 and 2.6.22
On Fri, 10 Aug 2007 14:38:25 +0200 Teemu Ikonen [EMAIL PROTECTED] wrote: Could you maybe have a look at: http://bugzilla.kernel.org/show_bug.cgi?id=7780#c59 There is a patch. But on top of that, you should also add your machine to a list. You'll need dmidecode for that. grts Tim signature.asc Description: PGP signature
Bug#436064: uswsusp: dell precision m90 needs to be whitelisted
Hi Manoi, On Fri, 03 Aug 2007 22:09:59 -0500 Manoj Srivastava [EMAIL PROTECTED] wrote: I have a shiny new Dell Precision M90 laptop, and much to my pleasant surprise, both s2disk and s2ram -f work with no changes (I am running the non-free nvidia drivers, and ipw3945 modules); I've seen your discussion on the devel list (stefan usually adds the new machines to the list). If I'm not mistaken the addition is still pending on the question if it also works from the console. Could you please test that? TIA, Tim signature.asc Description: PGP signature
Bug#438773: uswsusp: Should restore font too
On Sun, 19 Aug 2007 18:30:00 +0200 Samuel Thibault [EMAIL PROTECTED] wrote: It works fine except that I'm using a standard VGA console with an 8x8 font (i.e. /etc/kbd/config, I have CONSOLE_FONT=lat9w-08), hence 80x50 console. The problem is that after restore, the console is still 80x50 (thanks to VBE_SAVE), but with an 8x16 font (probably the default vga font), so that letters are half-cut. BTW, s2ram --force --vbe_save is enough for that machine, --vbe_post is not needed. s2ram --force --vbe_mode gives a black screen. Did you try adding --acpi_sleep=1 or 2 or 3? grts Tim signature.asc Description: PGP signature
Bug#432754: [Suspend-devel] uswsusp: Freeze after resume with kernels 2.6.21 and 2.6.22
Julien, Could you please retry with 2.6.23-rc (or final). If the issue is still there, please file a bug at bugzilla.kernel.org. (I can help you with that if you'd like, but it is easier debugging if you do it) grts Tim signature.asc Description: PGP signature
Bug#427104: still apears to be broken with d-i
Hi Stable-RMs,
This is an e-mail to ask if the patch below would be acceptable for a
point release. If so I believe I have to upload to
stable-proposed-updates, right?
This is about bug 427104, a summary of the bug:
D-I in etch uses devfs-style naming for devices. This means that
discovering the swap-device and writing it to a file will result in
having the wrong file name. Luckily the installer writes a file with a
`correct' device filename.
This was discovered quite close to the release. I thought I fixed the
issue with an upload during the freeze. That fix just uses the device
file name from the file the installer wrote and disables a check for
the existence of the swap-file for one pass.
Unfortunately the tests I performed (installing the fixed package with
dpkg -i) didn't capture the normal use case. If the install goes
through apt the package will be pre-configured, which means that the
package gets configured twice. The second run the normal check is on
again, which results in a confusing message to the user.
In other words: everybody who installs the laptop task gets a useless
and confusing question. In joeys words:
... the laptop task is broken, and something has to be done about this.
It's sort of on the edge between a cosmetic problem and a serious bug,
so the best way to make sure it's accepted will be to have a good and
clear patch.
The patch below will set a flag on a debconf question to signal we disabled
the check in d-i and we should not ask the question. In posinst the flag is
cleared so that in the further life of the package the test will be done.
Index: uswsusp.config
===
--- uswsusp.config (revision 490)
+++ uswsusp.config (working copy)
@@ -85,8 +85,11 @@
# found to the list of valid swaps without checking. This is because
# what is in /proc/swaps uses devfs style naming...
if [ -n $USERSWAP ] ! echo $SWAPLIST | grep -q -e '\(^\|,
\)'$USERSWAP'\(,\|$\)'; then
- SWAPLIST=${SWAPLIST}${KOMMA}${USERSWAP}
- SWAPDEFAULT=${USERSWAP}
+ # We do that by making sure we skip the continue_without_swap question.
+ # We'll clear this in postinst.
+ db_set uswsusp/continue_without_swap true
+ db_fset uswsusp/continue_without_swap seen true
+ db_fset uswsusp/continue_without_swap d_i true
fi
fi
@@ -98,6 +101,8 @@
SWAPLIST=${SWAPLIST}${KOMMA}${USERSWAP} ;
SWAPDEFAULT=${USERSWAP}
fi
+elif [ -n $USERSWAP ]; then
+SWAPDEFAULT=${USERSWAP}
fi
# We had to move this untill after the config file parsing, because
Index: uswsusp.postinst
===
--- uswsusp.postinst(revision 490)
+++ uswsusp.postinst(working copy)
@@ -24,6 +24,15 @@
[ $RET = false ] || exit 0;
db_fget uswsusp/no_snapshot seen
[ $RET = false ] || exit 0;
+
+ # If we've set this under d-i to skip the sanity checks, reset it
+ db_fget uswsusp/continue_without_swap d_i
+ if [ $RET = true ]; then
+ db_fset uswsusp/continue_without_swap seen false
+ db_fset uswsusp/continue_without_swap d_i false
+ db_reset uswsusp/continue_without_swap
+ fi
+
# If we don't have /proc or /sys we can't work, this will probably
# be a chroot or so.
mountpoint -q /sys || exit 0;
signature.asc
Description: PGP signature
Bug#427104: still apears to be broken with d-i
On Tue, 11 Sep 2007 14:40:42 -0400 Joey Hess [EMAIL PROTECTED] wrote: Jérémy Bobbio wrote: The good news is: d-i finally got rid of devfs-style device names in its development builds. Joey, can you confirm that the bug is now gone for with the daily built images? Yes, just tested and /proc/swaps uses standard names and so the message doesn't appear. That is nice. Tim Dijkstra wrote: I was a bit low on debian time lately. But I was planning to package the new release of uswsusp, so maybe we can have another shot at this. But before we do, I would want to have some reassurance that the peorple who manage stable updates find this problematic enough to warrant an update. I'm not sure what a new upstream release has to do with an update of the version in stable? Nothing, it was bad wording. I meant to say that I was going to do some work on this package anyway, so that would be a good time to also have another look at this bug. BTW, you'd be suprised how many times I see this bug confusing users. To many users, it looks like the installer is warning that there is no swap set up. Yes, I understand. As you can read from the bug log, before the release I thought I fixed it. But as it turned out the only convenient way of testing the old device name problem was not really testing the same code path. Anyway, my last question remains. Joey, you probably have most experience with stable point releases: Do you think a fix for this will make it to a etch point release? Otherwise there is not much use of fixing this. I could also go ask debian-release@ ... grts Tim signature.asc Description: PGP signature
Bug#427104: still apears to be broken with d-i
On Thu, 6 Sep 2007 14:55:14 +0200 Jérémy Bobbio [EMAIL PROTECTED] wrote: Hi! I am coming back with this issue, as I recently had more feedbacks about it... On Mon, Jun 04, 2007 at 02:08:48PM -0400, Joey Hess wrote: Tim Dijkstra wrote: I'm tempted to wait until d-i finally dumps the devfs style naming. And I don't think that a change that tries to fix this will be allowed into an update for etch, do you? Removing devfs device names from d-i is a long-term goal, not a matter of flipping a switch. There remains an unknown amount of work to reach that goal. In the meantime, the laptop task is broken, and something has to be done about this. That's how I see it. The good news is: d-i finally got rid of devfs-style device names in its development builds. Joey, can you confirm that the bug is now gone for with the daily built images? The less good news: I'd like to get a fix for this in the next Etch point release, as the error message, even harmless, is really confusing less experienced users. Tim, would you be inclined to work on an update for version 0.3~cvs20060928-7 with me? I was a bit low on debian time lately. But I was planning to package the new release of uswsusp, so maybe we can have another shot at this. But before we do, I would want to have some reassurance that the peorple who manage stable updates find this problematic enough to warrant an update. grts Tim signature.asc Description: PGP signature
Bug#433872: uswsusp: nx6325 fails to resume from s2ram
Hi Ludovic, Before I forward this to the suspend list for some more input. I have some questions: What video driver do you use? (If you use the binary nvidia or ati drivers, could you try with the floss ones?) Are you using framebuffer? (If so could you try without?) Can you maybe first try the latest version? Grts Tim signature.asc Description: PGP signature
Bug#434630: s2ram: whitelist for HP OmniBook XE3 GC
Hi Stefan, It seems you have the best view on the whitelist, can you add this machine with `-s'? TIA, Tim On Wed, 25 Jul 2007 14:20:46 +0200 Frederic Mothe [EMAIL PROTECTED] wrote: Package: uswsusp Version: 0.3~cvs20060928-7 Severity: wishlist Hello, Could you please add this computer to the s2ram whitelist ? It seems to work fine with the following command lines: s2ram -f -s s2ram -f -p -s s2ram -f -a 1 -s s2ram -f -a 2 -s s2ram -f -a 3 -s (without -s, it does not work with the framebuffer) I forgot to mention that yes, it works both from X and the console. There are almost no problems (some screen garbage) with the framebuffer if the -s option is used. This machine can be identified by: sys_vendor = Hewlett-Packard sys_product = HP OmniBook PC sys_version = HP OmniBook XE3 GC bios_version = GC.M1.63 Thank you! Frédéric Mothe signature.asc Description: PGP signature
Bug#383060: [Splashy-devel] Bug#383060: splashy: Shouldn't move to Etch until we manage to solve initramfs issues
On Thu, 19 Jul 2007 20:13:06 +0200 Torsten Werner [EMAIL PROTECTED] wrote: Hi, are there any plans to fix this bug? I've tried. It is a hard bug. Debugging something in a boot process is not funny even with qemu or so. I've come to conclude that something in the directfb library doesn't like the switch from initramfs to regular init. Upstart doesn't have this problem. Why exactly I don't know, but it means if the desktop task switches to upstart we can close this bug. grts Tim signature.asc Description: PGP signature
Bug#433382: Gdm won't start if splashy isn't
Package: splashy Version: 0.3.4 Severity: normal When splashy isn't running a call to splashy_update fails which makes the /etc/init.d/gdm script fail = result is gdm won't start. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (600, 'unstable'), (500, 'stable'), (19, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22.1 Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to nl_NL.utf8) Shell: /bin/sh linked to /bin/dash Versions of packages splashy depends on: ii libc6 2.6-2GNU C Library: Shared libraries ii libglib2.0-02.12.12-1+b1 The GLib library of C routines ii libmagic1 4.21-1 File type determination library us ii libsplashy1 0.3.4Library to draw splash screen on b ii lsb-base3.1-23.1 Linux Standard Base 3.1 init scrip ii zlib1g 1:1.2.3.3.dfsg-5 compression library - runtime splashy recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411851: Patch to make pm-utils restart sl-modem-daemon
On Tue, 10 Jul 2007 19:10:23 +0200 Julien Valroff [EMAIL PROTECTED] wrote: Hi Tim, Le jeudi 17 mai 2007 à 21:54 +0200, Tim Dijkstra (tdykstra) a écrit : Package: sl-modem-daemon Followup-For: Bug #411851 As discussed, the best I can do is make pm-utils restart sl-modem-daemon. I'll attach a patch, I verified that the sl-modem-daemon package has the correct content now, I don't know about sl-modem-source. With the attached patch, I have an error in the pm-suspend.log: /var/run/pm-suspend: line 1: export `sl-modem-daemon_SERVICE_ACTIVATE=yes': not a valid identifier This is a bug in pm-utils. It doesn't accept a dash `-' in the service name, which is a bit stupid. I'll try to fix that. grts Tim signature.asc Description: PGP signature
Bug#433179: pm-utils: restartsevice is broken for services with a dash
Package: pm-utils Version: 0.99.2-2 Severity: important Services with a dash in their name can't use restartservice. Example: /var/run/pm-suspend: line 1: export `sl-modem-daemon_SERVICE_ACTIVATE=yes': not a valid identifier -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (600, 'unstable'), (500, 'stable'), (19, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.21.5 Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to nl_NL.utf8) Shell: /bin/sh linked to /bin/dash Versions of packages pm-utils depends on: ii powermgmt-base1.29 Common utils and configs for power Versions of packages pm-utils recommends: ii hal0.5.9.1-1 Hardware Abstraction Layer pn radeontool none(no description available) ii uswsusp0.6~cvs20070513-1 tools to use userspace software su ii vbetool0.7-1.1 run real-mode video BIOS code to a -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#427104: still apears to be broken with d-i
On Mon, 4 Jun 2007 14:08:48 -0400 Joey Hess [EMAIL PROTECTED] wrote: Tim Dijkstra wrote: I'm tempted to wait until d-i finally dumps the devfs style naming. And I don't think that a change that tries to fix this will be allowed into an update for etch, do you? Removing devfs device names from d-i is a long-term goal, not a matter of flipping a switch. There remains an unknown amount of work to reach that goal. In the meantime, the laptop task is broken, and something has to be done about this. That's how I see it. OK. What is a way to trigger this bug. When is a package pre-configured? If there are more than one packages in the install run? I couldn't find anything about it in policy. grts Tim signature.asc Description: PGP signature
Bug#426384: cpufreqd: non-stopping daemon prevents suspending/hibernating with uswsusp
On Sun, 03 Jun 2007 18:35:50 +0200 Julien Valroff [EMAIL PROTECTED] wrote: Things were working fine until recently, but I am not able to tell which upgrade could cause this issue (kernel, uswsusp, other?). pm-utils does some fiddling with cpufreqd, you could try to disable the script by touch /etc/pm/sleep.d/94cpufreq (just create an empty, non-executable file.). And see if that helps. grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#427104: still apears to be broken with d-i
On Fri, 1 Jun 2007 17:54:18 -0400 Joey Hess [EMAIL PROTECTED] wrote: In my tests installing the laptop task in lenny, uswsusp still prompts with uswsusp/continue_without_swap. I've looked at this some. It seems that the first time the config script runs, all is ok. uswsusp/resume_device is not set, and /etc/initramfs-tools/conf.d/resume exists and gets parsed and the d-i hack used. The problem occurs the second time the config script runs. Remember, the config script typically runs once during preconfiguration, and a second time when the package is actually installed. I hadn't remembered... Also during my test it didn't show up. I tested it by going to a shell in the installer and installing the package by hand. In such a situation it doesn't get pre-configured, I guess. I don't know a way out at the moment. I seems we're back at trying to figure out if we're run under d-i or not. I could write to some state variable the first configuration run, and then clean this var when we have run postinst. But this is becoming more and more ugly... I'm tempted to wait until d-i finally dumps the devfs style naming. And I don't think that a change that tries to fix this will be allowed into an update for etch, do you? grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#427253: pm-utils: broken suspend-hybrid
On Sat, 02 Jun 2007 20:13:37 +0200
Florian Ragwitz [EMAIL PROTECTED] wrote:
just move the
ACTION=${ACTION/-/_} statement from before the case statement to its
end, before pm_main gets called. So the current case statement matches
and the call to pm-is-supported works as well.
Also this was a know problem and already fixed in svn.
Sorry to cause you some trouble on know problems. Maybe I should file
bugs on my own packages and tag them pending if I find a problem...
grts Tim
signature.asc
Description: PGP signature
Bug#427254: pm-utils: broken configuration parser
On Sat, 02 Jun 2007 20:30:00 +0200 Florian Ragwitz [EMAIL PROTECTED] wrote: Package: pm-utils Version: 0.99.2-1 Severity: important Hi, I tried configuring pm-utils to pass the options needed for my system to s2ram. Therefor I created a new file in /etc/pm/config.d/ which looked like this: S2RAM_OPTS=--force --acpi_sleep 3 This didn't work as expected. This is known. We're expecting to upload a new version fixing this behaviour pretty soon know. grts Tim signature.asc Description: PGP signature
Bug#426878: uswsusp: [INTL:vi] Vietnamese debconf templates translation update
On Thu, 31 May 2007 22:41:49 +0930 Clytie Siddall [EMAIL PROTECTED] wrote: Package: uswsusp Version: 0.5-2 Severity: minor Tags: l10n, patch The updated Vietnamese translation for the debconf file: uswsusp Thanks for the updated translation, unfortunately you translated an somewhat older template. I attached a new version with a few fuzzies. It could very well be that some are only whitespace fixes btw. grts Tim # Vietnamese translation for uswsusp. # Copyright © 2007 Free Software Foundation, Inc. # Clytie Siddall [EMAIL PROTECTED], 2006-2007. # msgid msgstr Project-Id-Version: uswsusp 0.5-2\n Report-Msgid-Bugs-To: [EMAIL PROTECTED] POT-Creation-Date: 2007-04-20 22:19+0200\n PO-Revision-Date: 2007-05-31 22:17+0930\n Last-Translator: Clytie Siddall [EMAIL PROTECTED]\n Language-Team: Vietnamese [EMAIL PROTECTED]\n MIME-Version: 1.0\n Content-Type: text/plain; charset=utf-8\n Content-Transfer-Encoding: 8bit\n Plural-Forms: nplurals=1; plural=0;\n X-Generator: LocFactoryEditor 1.6.3b1\n #. Type: select #. Description #: ../uswsusp.templates:1001 msgid The swap space to resume from: msgstr Vùng trao Äá»i từ Äó cần tiếp tục: #. Type: select #. Description #: ../uswsusp.templates:1001 #, fuzzy msgid To be able to suspend your system, uswsusp needs a swap partition or file to write a snapshot of your system to. Provided is a list of suitable swap spaces, sorted by size, the largest first. msgstr Äá» ngÆ°ng há» thá»ng, uswsusp cần thiết má»t phân vùng trao Äá»i (swap) hay táºp tin và o Äó Äá» ghi ảnh chụp há» thá»ng. Cung cấp danh sách các vùng trao Äá»i thÃch hợp, sắp xếp theo kÃch cỡ, lá»n hÆ¡n trÆ°á»c. #. Type: error #. Description #: ../uswsusp.templates:3001 msgid No swap space found; userspace software suspend will not work msgstr Không tìm thấy vùng trao Äá»i; khả nÄng ngÆ°ng phần má»m vùng ngÆ°á»i dùng sẽ không hoạt Äá»ng Äược #. Type: error #. Description #: ../uswsusp.templates:3001 #, fuzzy msgid To be able to suspend your system, uswsusp needs a swap partition or file to write a snapshot of your system to. Your system doesn't seem to have such a space. Please make one, preferably with twice the size of your physical ram. Then run dpkg-reconfigure or setup the configuration file yourself. msgstr Äá» ngÆ°ng há» thá»ng, uswsusp cần thiết má»t phân vùng trao Äá»i (swap) hay táºp tin và o Äó Äá» ghi ảnh chụp há» thá»ng. Có vẻ là há» thá»ng nà y không có vùng nhÆ° váºy. Hãy tạo nó, tá»t hÆ¡n có kÃch cỡ hai lần bá» nhá» RAM váºt lý. Sau Äó, chạy lá»nh cấu hình lại « dpkg-reconfigure » hoặc tá»± thiết láºp táºp tin cấu hình. #. Type: note #. Description #: ../uswsusp.templates:4001 msgid Your kernel doesn't support userspace software suspend msgstr Hạt nhân nà y không há» trợ khả nÄng ngÆ°ng phần má»m kiá»u vùng ngÆ°á»i dùng #. Type: note #. Description #: ../uswsusp.templates:4001 #, fuzzy msgid Your kernel doesn't support userspace software suspend. Please reconfigure your kernel to include CONFIG_SOFTWARE_SUSPEND=y and recompile. msgstr Hạt nhân nà y không há» trợ khả nÄng ngÆ°ng phần má»m kiá»u vùng ngÆ°á»i dùng. Hãy cấu hình lại hạt nhân Äá» bao gá»m « CONFIG_SOFTWARE_SUSPEND=y » rá»i biên dá»ch lại. #. Type: boolean #. Description #: ../uswsusp.templates:5001 msgid Continue without a valid swap space? msgstr Tiếp tục mà không có vùng trao Äá»i hợp lá» không? #. Type: boolean #. Description #: ../uswsusp.templates:5001 #, fuzzy msgid The swap file or partition that was found in uswsusp's configuration file is not active. In most cases this means userspace software suspend will not work for you and you will need to choose (or let uswsusp choose) another swap space. In some corner cases however, this can be what you want. msgstr Táºp tin hay phân vùng kiá»u trao Äá»i Äược tìm trong táºp tin cấu hình của uswsusp không phải hoạt Äá»ng. Trong phần lá»n trÆ°á»ng hợp, có nghÄ©a là khả nÄng ngÆ°ng phần má»m vùng ngÆ°á»i dùng sẽ không hoạt Äá»ng Äược nên bạn cần phải chá»n (hoặc cho uswsusp chá»n) vùng trao Äá»i khác. Tuy nhiên, trong má»t sá» trÆ°á»ng hợp Ãt thÆ°á»ng hÆ¡n, bạn tháºt muá»n nhÆ° thế. #. Type: string #. Description #: ../uswsusp.templates:6001 msgid The device node through which uswsusp can talk to the kernel: msgstr Nút thiết bá» qua Äó uswsusp có thá» liên lạc vá»i hạt nhân: #. Type: string #. Description #: ../uswsusp.templates:6001 msgid If you leave this empty, you will get the hardcoded default, /dev/snapshot. This should be OK in almost all cases, don't change this unless you have a good reason to do so. msgstr Bá» rá»ng thì dùng giá trá» mặc Äá»nh cà i cứng, « /dev/snapshot ». Nó nên thÃch hợp gần
Bug#427052: pm-utils: What to do when hal nows we don't need quirks?
Package: pm-utils Version: 0.99.2-1 Severity: normal This is a reminder to myself to discuss a bit about that when I have them. Currently if hal knows we shouldn't use any quirks we still try s2ram's internal list, because we can't distinguish it from `unknown machine'. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable'), (20, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.20 Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to nl_NL.utf8) Versions of packages pm-utils depends on: ii powermgmt-base1.29 Common utils and configs for power Versions of packages pm-utils recommends: ii hal0.5.9-3 Hardware Abstraction Layer pn radeontool none(no description available) ii uswsusp0.6~cvs20070513-1 tools to use userspace software su ii vbetool0.7-1.1 run real-mode video BIOS code to a -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426929: uswsusp: s2disk fails: suspend: Could not stat the resume device file
On Thu, 31 May 2007 12:53:40 -0700 Karsten M. Self [EMAIL PROTECTED] wrote: stat64(/dev/hda5,, 0xbf94d4b0)= -1 ENOENT (No such file or directory) ^^^ Here is the problem, your config file has a trailing comma in the resume device field. But now the question, how did it get there... Do you have only one swap partition? Did you install with d-i? grts Tim signature.asc Description: PGP signature
