Bug#894079: date command prints wrong date for "yesterday" and "tomorrow" near DST switch
Package: coreutils Version: 8.26-3 Near midnight of the night when DST starts, as well as soon after midnight the next night, the "date" command prints wrong dates for "yesterday" and "tomorrow". It seems as if the date for "24 hours ago" and "+24 hours" is printed instead. Examples: (The DST switch in our country was on 2018-03-25 03:00 this year) # date --set="2018-03-24 23:30" # Half an hour before midnight when DFT switch will occur. Sat Mar 24 23:30:00 EET 2018 # date '+%Y-%m-%d' 2018-03-24 # Correct date for today. # date '+%Y-%m-%d' --date=tomorrow 2018-03-26 # Incorrect. Tomorrow is 2018-03-25. # date --set="2018-03-26 00:30" # Half an hour into the day after the DST switch occurred. Mon Mar 26 00:30:00 EEST 2018 # date '+%Y-%m-%d' 2018-03-26 # Correct date for today. # date '+%Y-%m-%d' --date=yesterday 2018-03-24 # Incorrect. Yesterday was 2018-03-25. If the format string is omitted, it becomes obvious that the "date" command just adds or subtracts 24 hours from the present time. For example, at the time of the first example (2018-03-24 23:30), the following is printed: # date --date=tomorrow Mon Mar 26 00:30:17 EEST 2018 It is hard to tell, what would be correct, but intuitively I would expect Sun Mar 25 23:30:17 EEST 2018 instead. In common usage, "tomorrow" is always the next day after today, and "yesterday" is the previous day, irrespective of any DST switches. The date commands with "yesterday" and "tomorrow" were used in scripts which prepare directories to be used the next day, or their content analyzed the day after, and these failed in different ways during the last two nights. It can be worked around, but a proper fix would be appreciated. -- Toomas Tamm Tallinn (GMT+2/GMT+3), Estonia.
Bug#855057: Should no longer use /etc/default/rcS to set TMPTIME
Package: tmpreaper Version: 1.6.13+nmu1 The script /etc/cron.daily/tmpreaper searches for TMPTIME in /etc/default/rcS as a way to configure the ageing time of temporary files. Since Debian stretch, the systemd package no longer depends on "initscripts" package, which provides the /etc/default/rcS . Thus by default there is no such file, or it is empty as it happens to be on my test system. Also the comments in /etc/tmpreaper.conf recommend setting TMPTIME in /etc/default/rcS. This may confuse newcomers when this file is no longer present. I suggest that a warning mechanism should be provided against this change, or possibly the dependence on /etc/default/rcS should be removed altogether in favour of /etc/tmpreaper.conf as the sole configuration file for tmpreaper. Toomas Tamm Estonia
Bug#854454: D-I RC2 under KVM; some wishlist items included.
uot;standard system utilities" were available for review before the user commits to the install. In my situation, I just killed the virtual host and started all over. The second time around, everything was very smooth and I got a bootable minimal system (no options selected in tasksel) just fine. -- Toomas Tamm Estonia
Bug#782505: libxrender1 still blocks *all* security updates on affected systems
On Tue, Apr 28, 2015 at 06:38:24PM +0200, Julien Cristau wrote: Did you read that error message? apt-get -f install should fix it... If it were a single computer, it would be trivial indeed. However, issuing apt-get -f install on a large number of remotely managed systems (which is the case here) sounds like a risky proposition. Looks like I need to take the risk... Besides, has it been tested with various automated update methods? I think even apt-get comes with some kind of crontab entry nowadays; we are using locally written scripts here so I do not know the specifics. Regards, Toomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782505: libxrender1 still blocks *all* security updates on affected systems
As of 28-apr-2015 (11 days after the bug was claimed fixed), on systems where both 32- and 64-bit libxrender1 is installed, all upgrades remain blocked due to this bug. For example, the kernel security fix of 27-apr-2015 does not get installed on affected systems. Affected system: # apt-get upgrade Reading package lists... Done Building dependency tree Reading state information... Done You might want to run 'apt-get -f install' to correct these. The following packages have unmet dependencies: libxrender1 : Breaks: libxrender1:i386 (!= 1:0.9.7-1+deb7u1) but 1:0.9.7-1+deb7u1+b1 is installed libxrender1:i386 : Breaks: libxrender1 (!= 1:0.9.7-1+deb7u1+b1) but 1:0.9.7-1+deb7u1 is installed E: Unmet dependencies. Try using -f. Unaffected system: # apt-get upgrade Reading package lists... Building dependency tree... Reading state information... The following packages will be upgraded: linux-headers-3.2.0-4-amd64 linux-headers-3.2.0-4-common linux-image-3.2.0-4-amd64 linux-libc-dev 4 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 28.5 MB of archives. After this operation, 9,490 kB of additional disk space will be used. [snip] IMO this deserves grave classification and appropriate handling because unrelated software is affected and security fixes do not get installed. If manual intervention is needed, please provide appropriate instructions at bugs.debian.org. Regards, Toomas Tamm Estonia -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752892: coreutils: cp --update --archive unnecessarily deletes and re-creates hard links
Package: coreutils
Version: 8.20-3
Severity: normal
cp --update --archive can be used to make and maintain backup copies of
directory
trees. I am using this in a script with --verbose (I post-process the output in
this script). After upgrading to wheezy (coreutils 8.20) from lenny (coreutils
6.10), the cp output has included a lot of lines like
removed ‘path/to/certain/file’
All the listed files have more than one hard link. The following test case
illustrates
the behaviour:
$ mkdir x
$ date x/a
$ ln x/a x/b
$ ls -l x
total 8
-rw-rw-r-- 2 toomas toomas 30 Jun 27 16:36 a
-rw-rw-r-- 2 toomas toomas 30 Jun 27 16:36 b
$ cp --update --archive --verbose --no-target-directory ./x ./y
‘./x’ - ‘./y’
‘./x/b’ - ‘./y/b’
‘./x/a’ - ‘./y/a’
$ ls -l y
total 8
-rw-rw-r-- 2 toomas toomas 30 Jun 27 16:36 a
-rw-rw-r-- 2 toomas toomas 30 Jun 27 16:36 b
$ # The following command is the one which is showing the problem:
$ cp --update --archive --verbose --no-target-directory ./x ./y
removed ‘./y/a’
$ # The following listing shows that the link was actually re-created:
$ ls -l y
total 8
-rw-rw-r-- 2 toomas toomas 30 Jun 27 16:36 a
-rw-rw-r-- 2 toomas toomas 30 Jun 27 16:36 b
Doing a strace on the last cp reveals the following sequence of events:
lstat(./x/b, {st_mode=S_IFREG|0664, st_size=30, ...}) = 0
stat(./y/b, {st_mode=S_IFREG|0664, st_size=30, ...}) = 0
lstat(./x/a, {st_mode=S_IFREG|0664, st_size=30, ...}) = 0
stat(./y/a, {st_mode=S_IFREG|0664, st_size=30, ...}) = 0
linkat(AT_FDCWD, ./y/b, AT_FDCWD, ./y/a, 0) = -1 EEXIST (File exists)
unlink(./y/a) = 0
linkat(AT_FDCWD, ./y/b, AT_FDCWD, ./y/a, 0) = 0
So even though the program has stat()ed both y/a and y/b and should know
that they already have identical inode numbers, is still tries to link y/a
to y/b, fails, removes y/a, and re-creates the hard link again.
With large directory trees containing numerous hard links this seems like
an unnecessary waste of resources, in addition to creating the initially
very confusing removed ‘path/to/certain/file’ messages on the verbose
output.
In my opinion, the correct behaviour should omit the linkat(), unlink(),
linkat() sequence after comparing the inode numbers of existing files.
Toomas Tamm
-- System Information:
Debian Release: 7.5
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages coreutils depends on:
ii dpkg 1.16.15
ii install-info 4.13a.dfsg.1-10
ii libacl1 2.2.51-8
ii libattr1 1:2.4.46-8
ii libc6 2.13-38+deb7u1
ii libselinux1 2.1.9-5
coreutils recommends no packages.
coreutils suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743849: linux-image-3.2.0-4-686-pae: Reboots without useful diagnostic on VIA C3 (non-PAE)
Package: linux-image-3.2.0-4-686-pae Severity: normal I was installing Debian onto an old system powered by the VIA C3 (Nehemiah) CPU. Initially I was not aware that the CPU does not support PAE. For the record, I booted off an USB stick using grub 1.99 with intent to start FAI (Fully Automatic Installation). Observed behaviour: the 686-PAE kernel reboots the system immediately after the Uncompressing kernel message flashes on the screen for an extremely brief time, giving the operator no hint about what is wrong. Expected behaviour: the kernel should display a clear message that the hardware does not support PAE (and consequently the 686-pae kernel), and give the operator sufficient time to read it (possibly halting the machine until power is turned off). Wishlist item: a suggestion that a 486 series kernel is required might be displayed as well. Toomas Tamm Estonia -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#646955: Not fixed in wheezy as of 03 May 2013
As embarrassing as it seems, two days before the release of wheezy,
my test installation still claims I am having Debian Verison 7.0,
not version.
From /etc/init.d/linuxlogo:
${DAEMON} -t Debian Verison $(cat /etc/debian_version) -f
/etc/issue.linuxlogo
${DAEMON} -t Debian Verison $(cat /etc/debian_version) -a
-f /etc/issue.linuxlogo.ascii
and further down
${DAEMON} -t Debian Verison $(cat /etc/debian_version)
Toomas Tamm
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#646955: The version in wheezy is still 5.11-1
... and the reason why this is not fixed in wheezy is quite obvious: the version of linuxlogo in wheezy is 5.11-1. Why did the new version not migrate from sid to testing in ten months (the bug was fixed 05-jul-2012)? Perhaps it is possible to force this migration after wheezy release, for the next dot release? Toomas Tamm -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698786: zope2.12: logrotate script ends with status code 1 if the last instance is not running
Package: zope2.12 Version: 2.12.22-1~bpo60+1 Severity: normal I have several zope2.12 instances set up. The last one (alphabetically) of these is currently not running, so the file /var/lib/zope2.12/instance/NAME/var/Z2.pid does not exist. The postrotate script defined in /etc/logrotate.d/zope2.12 checks for the existence of this file, to see if the log file should be reopened. If the last configured instance (in alphabetic order) does not have the Z2.pid file, the postrotate script exits with exit code 1 and an e-mail is sent to root: /etc/cron.daily/logrotate: error: error running shared postrotate script for '/var/log/zope2.12/*/Z2.log /var/log/zope2.12/*/event.log ' run-parts: /etc/cron.daily/logrotate exited with return code 1 While not show-stopping, these e-mails are annoying. Note: I am running zope2.12 from backports under squeeze. -- System Information: Debian Release: 6.0.6 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages zope2.12 depends on: ii debconf [debconf-2.0] 1.5.36.1 Debian configuration management sy ii libc6 2.11.3-4 Embedded GNU C Library: Shared lib ii lsb-base3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip ii python 2.6.6-3+squeeze7 interactive high-level object-orie ii python-clientform 0.2.10-2.1 module for handling HTML forms on ii python-docutils 0.7-2utilities for the documentation of ii python-initgroups 2.13.0-1~bpo60+1 Python binding of initgroups ii python-mechanize0.1.11-1.1 stateful programmatic web browsing ii python-pkg-resources0.6.14-4 Package Discovery and Resource Acc ii python-support 1.0.10 automated rebuilding support for P ii python-tz 2010b-1 Python version of the Olson timezo ii python2.6 2.6.6-8+b1 An interactive high-level object-o ii zope-common 0.5.51~bpo60+1 common settings and scripts for Zo zope2.12 recommends no packages. Versions of packages zope2.12 suggests: pn python-profiler none (no description available) pn python-unit none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532670: confirming that the problem still exists
Package: network-manager Version: network-manager_0.6.6-3 Followup-For: Bug #532670 Hello! I am another admin hit by this problem. I think the bug needs a proper fix. The situation is made worse by the fact that it does not initially manifest itself as a network-manager / ldap issue. Instead, the first symptom is complete system lockup at X starting stage (only the cursor can be moved with mouse) and no way to recover the box (no response to keyboard, no network connectivity for remote login). Through several tries, all ending in hitting the power switch, I lost the integrity of a disk partition and had to reinstall the whole system! Then it takes several hours of studying the logs and reading on the net before one can reach the conclusion that it is a netmanager + ldap problem. Several workarounds have been proposed, the easiest being uninstalling (or not starting) networkmanager. It should be noted that network-manager (through dependency on network-manager-gnome) is installed by default as a part of the gnome-desktop task. Once LDAP authentication gets configured (usually later after installation), the box no longer boots properly. -- Toomas Tamm e-mail: tt-deb (at) kky.ttu.ee Chair of Inorganic Chemistryvoice: INT+372-620-2810 Tallinn University of Technologyfax:INT+372-620-2828 Ehitajate tee 5, EE-19086 Tallinn, Estonia http://www.kk.ttu.ee/toomas/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#603675: device2grub not needed for grub2
On Thu, 2010-11-25 at 18:07 +0100, Thomas Lange wrote: The script device2grub is not needed for grub2. In FAI we have the class GRUB_PC which uses the script GRUB_PC/10-setup for setting up grub2 configuration. Also have a look at #604938 which fixes a problem in this script. FAI will use grub-probe (instead of device2grub) for grub2. IMO we can close this bug. The bug was seen in 4.0~beta2+experimental23 . I have verified that neither the current experimental (4.0~beta2+experimental41) nor the version in squeeze (3.4.4) make use of device2grub. I think the version of GRUB_PC/10-setup in experimental should be preferred over the version in 3.4.4 because it installs Grub into $BOOT_DEVICE, thus solving the problem which was recently discussed on the linux-fai list with subject host does not boot with grub_pc and /dev/sdd as boot disk. I agree that the bug can be closed. -- Toomas Tamm e-mail: tt-fai (at) kky.ttu.ee Chair of Inorganic Chemistryvoice: INT+372-620-2810 Tallinn University of Technologyfax:INT+372-620-2828 Ehitajate tee 5, EE-19086 Tallinn, Estonia http://www.kk.ttu.ee/toomas/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#604667: tramp-unload-tramp when executed from .emacs causes error
Package: emacs22-common Version: 22.2+2-5 I need to use Ange-FTP to access some remote files from Emacs. Therefore I want to unload Tramp. I can do this interactively via M-x tramp-unload-tramp without problems. However, if I put (tramp-unload-tramp) into my .emacs, I get this message in the minibuffer when emacs starts: Symbol's function definition is void: tramp-register-completion-file-name-handler I have not yet found a documented method to disable tramp permanently. -- Toomas Tamm e-mail: tt-deb (at) kky.ttu.ee Chair of Inorganic Chemistryvoice: INT+372-620-2810 Tallinn University of Technologyfax:INT+372-620-2828 Ehitajate tee 5, EE-19086 Tallinn, Estonia http://www.kk.ttu.ee/toomas/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#603675: device2grub not compatible with grub_pc
Package: fai-client Version: 4.0~beta2+experimental23 According to Grub 2 (aka grub_pc) documentation http://www.dedoimedo.com/computers/grub-2.html : Critical! GRUB 2 uses PARTITION notation that starts with 1 and not 0 like GRUB legacy! This is terribly important to remember! However, the program device2grub which comes as part of FAI (I am using the experimental series, version 4.0~beta2+experimental23 at the moment) does not appear to differentiate between grub legacy and grub 2. This program is called from scripts/GRUB_PC/10-setup and will produce off-by-one partition numbers for grub 2. The bug is manifested only if grub is to be installed into an unusual paritition, like /dev/sda6 . The usual /dev/sda case is handled gracefully because the translated name (hd0) does not contain a partition number. I was hit by this when /dev/sda6 was translated incorrectly into (hd0,5) and grub2 got installed on top of an NTFS Windows partition (/dev/sda5), destroying the filesystem structure. Luckily, I had backups available... I think device2grub needs a flag which would inhibit the decrement of partition number in case it is used in conjunction with grub_pc and scripts/GRUB_PC/10-setup needs to make use of this flag. I also think that this should be fixed before squeeze is released (do I need to file a bug report into Debian BTS to make it official?) because grub_pc is the default bootloader for squeeze and this bug has potential of corrupting unsuspecting people's data if they install dual-boot systems. -- Toomas Tamm e-mail: tt-deb (at) kky.ttu.ee Chair of Inorganic Chemistryvoice: INT+372-620-2810 Tallinn University of Technologyfax:INT+372-620-2828 Ehitajate tee 5, EE-19086 Tallinn, Estonia http://www.kk.ttu.ee/toomas/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600733: Examples from the documentation do not run
On Sun, 2010-10-24 at 02:26 +0200, Jörg Sommer wrote: This tutorial refers to an old version of Xindy. In the current version, you have to use % xindy -t ex1.xlg -M style1.xdy ex1.raw I'll forward this problem to Xindy's mailinglist. Thank you! When the -l option is removed, running $ xindy style1.xdy ex1.raw results in the error message: Cannot locate xindy modules directory at /usr/bin/xindy.v2 line 162. This looks strage. You call xindy, but get a error message from xindy.v2. If you look into /usr/bin/xindy, near line 378, you will see that if certain conditions are met, it enters compatibility mode by executing xindy.v2 . Did you really call xindy? What's the output of % which xindy /usr/bin/xindy % xindy --version xindy release: unknown xindy script version: 1.08 xindy kernel version: 2.3 xindy run time engine: i486-linux-gnu, version 2.2 CLISP version 2.44 (2008-02-02) (built on mithrandir.pool8175.interbusiness.it [127.0.1.1]) architecture: I686 Xindy.v2 is obsolate and was removed from the package in version 2.4-1. Was the code of xindy modified accordingly, by removing the call to the xindy.v2 executable? Also please urge the upstream to update the on-line documentation at sourceforge.net to match the current version. Best regards, Toomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600733: Examples from the documentation do not run
Package: xindy Version: 2.3-2 An attempt to run the examples from the tutorial: http://www.xindy.org/doc/tutorial-2.html eg the command: $ xindy -l ex1.xlg style1.xdy ex1.raw results in the error message: Unknown option: l usage: xindy [-V?h] [-qv] [-d magic] [-o outfile.ind] [-t log] \ [-L lang] [-C codepage] [-M module] [-I input] \ [--interactive] [--mem-file xindy.mem] \ [idx0 idx1 ...] [rest of message truncated for brevity of bug report - TT ] When the -l option is removed, running $ xindy style1.xdy ex1.raw results in the error message: Cannot locate xindy modules directory at /usr/bin/xindy.v2 line 162. The second problem can be fixed by editing /usr/bin/xindy.v2 lines 157-158 replacing the existing modules path with /usr/share/xindy . A similar change has been made in /usr/bin/xindy by the package maintainers, but xindy.v2 is not patched. -- Toomas Tamm e-mail: tt-deb (at) kky.ttu.ee Chair of Inorganic Chemistryvoice: INT+372-620-2810 Tallinn University of Technologyfax:INT+372-620-2828 Ehitajate tee 5, EE-19086 Tallinn, Estonia http://www.kk.ttu.ee/toomas/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586309: Cfagent no longer reports missing files with Inform=on
Package: cfengine2 Version: 2.2.8-1 Consider the following cfagent.conf: --- control: actionsequence = ( copy ) Inform = ( on ) copy: any:: /home/toomas/sample dest=/tmp/sample-dest If the file /home/toomas/sample does not exist, under etch, cfengine2 would report: Can't stat /home/toomas/sample in copy while under lenny, it silently ignores the missing file. In a simple copy operation like this I expect to be told if my source file is missing. Reading on the internet and checking the sources (do.c line 2576 and following), the message is now only reported in verbose mode. Apparently some users saw spurious Can't stat messages which they considered annoying and decided that such messages should be silenced. The patch is possibly the one posted at https://cfengine.org/pipermail/help-cfengine/2007-February/000916.html By doing so, they also silenced important diagnostics which are very useful in debugging cfagent configuration files. In real life the cfagent.conf files are hundreds of lines long and occasional typos in file names do occur. Previously, such errors were immediately reported. Now I would need to run cfagent in verbose mode, which, with real-life inputs, creates hundreds of lines of output. Since the message is buried among the verbose diagnostics, I need to grep the file for specific error messages. With dozens of hosts one just cannot keep doing this all the time. That is the reason for error messages in the first place. A missing source file is clearly an error. I think that the patch sould be reversed and the users who are annoyed by these messages could remove them with grep themselves. In the long run, a separate flag should be introduced for suppressing just these particular messages if they cause trouble for some people while being useful for others. -- Toomas Tamm e-mail: tt-deb (at) kky.ttu.ee Chair of Inorganic Chemistryvoice: INT+372-620-2810 Tallinn University of Technologyfax:INT+372-620-2828 Ehitajate tee 5, EE-19086 Tallinn, Estonia http://www.kk.ttu.ee/toomas/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565991: nscd on 32-bit etch depends on libc6-amd64 after security update
Package: nscd Version: 2.3.6.ds1-13etch10 After the latest security update (DSA-1973-1, 19 January 2010) of etch (oldstable), the i386 version of nscd package has suddenly started to depend on libc6-amd64 (= 2.3.5-1). On 32-bit systems, I see no reason for such dependence. For us, this would mean installing a useless package on a number of legacy 32-bit systems. In the previous version (2.3.6.ds1-13etch9+b1), the dependence was on libc6 (= 2.3.6-6). This has now been replaced with the 64-bit version as quoted above. I believe the change needs to be reverted to a 32-bit version. -- Toomas Tamm e-mail: tt-deb (at) yki.ttu.ee Chair of Inorganic Chemistryvoice: INT+372-620-2810 Tallinn University of Technologyfax:INT+372-620-2828 Ehitajate tee 5, EE-19086 Tallinn, Estonia http://www.kk.ttu.ee/toomas/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#456641: xserver-xorg: X server crashes while running gdmgreeter when clock is adjusted backwards
Package: xserver-xorg Version: 1:7.1.0-19 Severity: important We installed a computer classroom of 20 workstations over the course of several days, using fully automatic installation (FAI). After the first day, we discovered that the system hardware clock was better set to LOCAL, not UTC, since the machines are dual-boot and Windows does not display proper time if the clock is set to UTC. Thus part of the computers were installed with clock set to UTC, and the rest with clock set to LOCAL (these strings occur in /etc/adjtime, and correspond to UTC=yes and UTC=no in /etc/default/rcS). Soon we noticed that the systems with hardware clock set to local would crash X within 5-15 minutes after boot, while still in gdmgreeter (no-one had logged in yet). Students also occasionally reported random X crashes after logging in, but we could not reproduce these. gdm then posts a small window saying it will atempt to use a different login program and, after selecting OK, starts gdmlogin. That one has never crashed (so far). I attached strace to X, gdm and gdmgreeter and verified that X is recieving SIGSEGV, causing gdmgreeter to exit. The following backtrace remains in Xorg0.log.old: Backtrace: 0: /usr/bin/X(xf86SigHandler+0x84) [0x80c4374] 1: [0xb7fb3420] 2: /usr/bin/X(Dispatch+0x81) [0x8086bb1] 3: /usr/bin/X(main+0x489) [0x806e6b9] 4: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xc8) [0xb7dbdea8] 5: /usr/bin/X(FontFileCompleteXLFD+0xa5) [0x806d9f1] Fatal server error: Caught signal 11. Server aborting (II) AIGLX: Suspending AIGLX clients for VT switch Since we had so many similarly-configures computers to play with, we looked at possible differences between the crashing and non-crashing computers. The UTC versus LOCAL issue came up, and we changed the hardware clock from LOCAL to UTC on some machines. None of these which recieved the change have crashed after that. My guess is that the system clock is initially wrong (assumed to be UTC while actually is LOCAL, set so by the reboot/shutdown scripts, and the crash is related to the moment when NTP (which we are also running) adjusts the time backwards by 2 hours. We are in UTC+2 time zone, thus at, eg 15:00 UTC our local time is 17:00. The system would take that 17:00 from hard- ware clock as if it were UTC and set local time to 19:00. After 5-15 minutes NTP synchronizes to time server and sets the clock to, eg, 15:10 UTC / 17:10 local. I verified this by stopping NTP and manually setting the clock 2 hours backwards on one host (which used UTC and thus had been up for a while). Approximately one minute later, X crashed just like in case of hosts with hardware clock set to LOCAL time. One final note: the bug seems to be independent of X driver: part of the computers have via-driven video cards (like the one I am writing this on) while the rest have nv video driver. Both exhibit similar behaviour. -- Package-specific info: Contents of /var/lib/x11/X.roster: xserver-xorg /etc/X11/X target does not match checksum in /var/lib/x11/X.md5sum. X server symlink status: lrwxrwxrwx 1 root root 13 2007-12-14 11:05 /etc/X11/X - /usr/bin/Xorg -rwxr-xr-x 1 root root 1598380 2007-09-04 04:27 /usr/bin/Xorg Contents of /var/lib/x11/xorg.conf.roster: xserver-xorg VGA-compatible devices on PCI bus: 01:00.0 VGA compatible controller: VIA Technologies, Inc. VT8378 [S3 UniChrome] Integrated Video (rev 01) /etc/X11/xorg.conf does not match checksum in /var/lib/x11/xorg.conf.md5sum. Xorg X server configuration file status: -rw-r--r-- 1 root root 3242 2007-12-14 11:12 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: # /etc/X11/xorg.conf (xorg X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the /etc/X11/xorg.conf manual page. # (Type man /etc/X11/xorg.conf at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # If you have edited this file but would like it to be automatically updated # again, run the following command: # sudo dpkg-reconfigure -phigh xserver-xorg Section Files FontPath/usr/share/fonts/X11/misc FontPath/usr/X11R6/lib/X11/fonts/misc FontPath/usr/share/fonts/X11/cyrillic FontPath/usr/X11R6/lib/X11/fonts/cyrillic FontPath/usr/share/fonts/X11/100dpi/:unscaled FontPath/usr/X11R6/lib/X11/fonts/100dpi/:unscaled FontPath/usr/share/fonts/X11/75dpi/:unscaled FontPath/usr/X11R6/lib/X11/fonts/75dpi/:unscaled FontPath/usr/share/fonts/X11/Type1 FontPath/usr/X11R6/lib/X11/fonts/Type1 FontPath/usr/share/fonts/X11/100dpi FontPath/usr/X11R6/lib/X11/fonts/100dpi FontPath
Bug#431431: TFTP directory location is hard-coded into make-fai-nfsroot
Package: fai-server Version: 3.1.8 This is a wishlist item. The location of TFTP directory /srv/tftp is hard-coded into make-fai-nfsroot. In situations where the TFTP server is shared with other functions (eg booting of diskless computers) another path may need to be used. It would be desirable if the path to TFTP directory were made a configuration option, settable in make-fai-nfsroot.cfg. Thank you, -- Toomas Tamm tt-deb (at) kky.ttu.ee -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430139: Incorrect quotes in find(1) man page - examples do not work.
Package: findutils Version: 4.2.28-1 The examples in the man page for find(1) use incorrect quotes. When you copy and paste (rather than re-type) the examples from the man page which contain quotes, such as find . -wholename ’./src/emacs’ -prune -o -print they do not work as expected. The example should read as find . -wholename './src/emacs' -prune -o -print It is annoying (and hard to figure out because the difference in appearance of the quotes is small) when examples copied and pasted from man pages do not work. -- Toomas Tamm tt-deb at kky.ttu.ee Tallinn, Estonia
Bug#419071: Package descriptions on packages.debian.org are not helpful
Package: fai-client Version: 3.1.8 After the FAI package was split into fai-client, fai-nfsroot, fai-server, etc, the package descriptions are all very similar and not helpful in deciding, which of the packages should be installed in which instances. http://packages.debian.org/stable/admin/fai-client http://packages.debian.org/stable/admin/fai-nfsroot http://packages.debian.org/stable/admin/fai-server The homepage referred to from the above pages does not provide any obvious and immediate help in this matter either. I suggest that the descriptions should include something like: Install this package if you only intend to When in doubt, install the fai-quickstart package instead. -- Toomas Tamm e-mail: tt-deb (at) kky.ttu.ee Chair of Inorganic Chemistryvoice: INT+372-620-2810 Tallinn University of Technologyfax:INT+372-620-2828 Ehitajate tee 5, EE-19086 Tallinn, Estonia http://www.kk.ttu.ee/toomas/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344536: Booting off a logical partition should be allowed
Package: fai Version: 2.8.4 Severity: wishlist For some reason, FAI does not believe in bootable logical partitions and fails to create such partitions. I have been booting Debian off /dev/hda5 (the first logical partition in the first extended one) since the days of hamm (1998) on more than a dozen of hosts and never had a serious problem. I think the installer (not FAI) of woody refused to configure LILO correctly for this situation, but a trivial manual intervention fixed the problem. This also covers the case where the disk is shared between two OS'es and one wishes to put the whole Debian into one partition, with the boot loader in the same partition. Thus, bootable logical paritions are supported by both lilo and grub and I suggest FAI should also support them. -- Toomas Tamm e-mail: tt-deb (at) kky.ttu.ee Chair of Inorganic Chemistryvoice: INT+372-620-2810 Tallinn University of Technologyfax:INT+372-620-2828 Ehitajate tee 5, EE-19086 Tallinn, Estonia http://www.kk.ttu.ee/toomas/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
