Bug#1026259: linux: SW RAID to JFS intermittent boot fail with NULL pointer dereference
Source: linux Severity: normal X-Debbugs-Cc: rattusrat...@debian.org Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Images testing for SW RAID release 11.6 * What exactly did you do (or not do) that was effective (or ineffective)? Installation testing option test matrix option #3 with the following disk partitions sda1 primary 1GB B K raid (#1) sda3 primary 15GBK raid (#0) sda5 logical 1GBF swap swap RAID1 #0 jfs / RAID1 #1 ext2 /boot * What was the outcome of this action? kernel crash with [2.671938] BUG: kernel NULL pointer dereference, address: 0028 (console output attached) * What outcome did you expect instead? Boot into fresh installed system :-) * More details (1) I have demonstrated this to Sledge on MULTIPLE instalations, both BIOS and UEFI and various degraded RAID configurations. (2) It appears to be Machine spacific; i.e. Sledge has been unable to reproduce the problem on his hardware (3) We have seen the problem on installations of debian 11.5 as well (4) Occasionally I have been able to get lucky and the system has booted. This, coupled with #2 might suggest a race hazard / timing issue? Sorry /Andy RAID_JFS_kernel_bug_console_out Description: application/json
Bug#1011343: WISHLIST: Offical ALL-IN-ONE images?
On 20 May 2022 15:11:09 BST, Zhang Boyang wrote: >Package: debian-cd > >Hello, > >I suggest debian release a new variant of ISO images, the all-in-one images. >These all-in-one image contains ALL debian packages in a single ISO image >(possibly all source packages in another all-in-one ISO image). Of course >there is no such optical media can hold such a big image, but it is useful for >virtual-machines, remotely managed servers, and archival purposes. The >theoretical size limit of an ISO9660 filesystem is about 8TB, which is >sufficient for including all debian packages. > >For the name of this variant, I suggest 'everything', 'allinone', 'world', >'virt'. > >p.s. This is my personal interest, and I would appreciate if you can kindly >consider my suggestion. > > >Best Regards, >Zhang Boyang > > Sorry to put a dampener on your suggestion but why would you need that? Why not just mirror the archive to a local disk instead? Then you have your copy of everything and can just point a netinst at your local mirror so you can install from there. I think that would deliver on every use case that you would be able to use your big ISO image and more
Bug#996000: general: System does not boot with second monitor attached
Control: Severity -1 normal Package: general Severity: important X-Debbugs-Cc: gaff...@live.com Dear Maintainer, I installed Debian 11 on a new computer (with a single monitor during installation, connected with HDMI). Installation went well, but the monitor came up with a very limited resolution (1024x768, I think). That isn't surprising, the installer (DI) will try and use only a minimum set of possible configurations, in order to function with most hardware it encounters After a bit of googling, I found that the drivers for the Intel graphics on this board (Rocket Lake, UHD 750) were not included in the 5.10 kernel that came with Debian Bullseye. I installed kernel 5.14 from Debian Testing, and that seemed to solve the issue - I got full resolution (still with a single monitor attached). Ack that sounds about right to me too: AFAICT Rocket Lake, UHD 750 is not yet officially supported in the linux kernel; i915 series has a generic driver, but not with full support for all devices in the series this is perhaps a bit too new, and you may have to wait a while for the kernel drivers to arrive. [0] Taking the system into use as my main system, I set it up with two monitors, one connected with an HDMI cable, one with a DVI cable. (Both monitors are Benq 24 inch 1920x1080.) Booting the system, it hangs during boot, with a message "VMC (outside TXT) disabled by bios". This is stating that that you haven't enabled 'Intel virtualization technology' - this should have no effect on the graphic driver support, you would need to enable this if you want to run Virtual Machines. Booting the system with only the HDMI-connected monitor attached works as expected, the system completes the boot sequence, I can log in and use the system. Attaching the second monitor after boot also works, both monitors are recognized and works As a workaround, I tried enabling "Intel virtualization technology" in the BIOS. Booting with both monitors attached, there is no longer any error message, but the system still hangs during boot (with a blank screen). I would expect the system to boot also with two monitors attached. I would expect this as well - but until there is official support in the kernel for your new hardware then I am afraid that you may have to put up with only connecting the monitor after boot. Trying newer, back ported kernels, when they become available, is probably your best bet. You could try watching the kernel.org releases looking specifically for the mentions of i915, Rocket Lake, or UHD 750 beforue you try [1] Very best wishes, and good luck with trying new kernels when they arrive /Andy (RattusRattus) [0] https://gist.github.com/Postrediori/556706b28aff3b831d9e41acb47418c5 [1] https://www.kernel.org/
Bug#989619: task-kde-desktop: Wrong wallpaper installed on clean installation of Bullseye (Desktop & Lock)
Package: task-kde-desktop Version: 3.67 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Testing Weekly builds of DI ready for release (build 2021-06-07) * What exactly did you do (or not do) that was effective (or ineffective)? Clean installation into seporate VMs of all installation media. Only KDE desktop is affected. All other desktops correctly install and select the 'Homeworld' wallpaper and lock screens. * What was the outcome of this action? KDE desktopinstallation had 'shell' as default walpaper and as 'lockscreen' * What outcome did you expect instead? I expected to see 'Homeworld' as the default wallpaper and lock screen - it wasn't 'shell' was set as the default. Homeworld was installed, just not as the active setting Login screen correctly showed 'homeworld' I beleive that this would be an embarissment if we fail to correctly theme the default desktop on KDE by bullseye release. Note I have also tested GNOME, XFCE, Gnome FlashBack, Cinnamon, Mate, LXQt, LXDE all sucessfully. /RattusRattus *** End of the template - remove these template lines ***
Bug#973683: some images blacklisted by Google Chrome safe browsing
Of cause firefox claims that the browser is working as intended and this is correct behavior (relying on the Google safe browsing API) Google on the other hand don't provide a working, reliable method to resolve their proprietary API database issues. Perhaps it is time to push for the feture to be removed from firefox or carry a local patch because I struggle to see how we are going to get a usable solution other than replacing mirrors with our own dedicated CDN. On 3 November 2020 11:02:59 GMT, Thomas Schmitt wrote: >Hi, > >> For all they will know, Debian has been pwned :-/ > >Yeah. I tried hard to keep my previous mail in a civilized tone towards >the intellectual entities who decided to deduce the purity of Debian >ISOs >from .exe files on the same server. >(Quotation marks in the air are a warning sign towards myself that i am >about to start a rant.) > >The only mitigation i can imagine is to put warning signs on pages like > https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/ >which say something like: > >- The browser warnings are known to be bogus. They appear because >Google > mistrusts especially our swedish mirrors. > >- Please fulfill the (standard) request not to download by a web >browser. > See first paragraphs of https://www.debian.org/CD/http-ftp/ . > >- If you have to use a web browser, you might be able to avoid the >classification as malware by using a mirror server from the lower three > quarters of >https://www.debian.org/CD/http-ftp/ > > >Have a nice day :) > >Thomas -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#941333: Wifi network detection during installation. Suggested improvement.
Right now you would get a "no network device found" / "no netwirk found" / "unable obtain an IP address" message. Is this not sufficiant? You are given the option to go back and try again. Please remember that it is also possible that no wifi device wiuld have been detected either. Lets face it if you do happen to have a wifi adapter that has been detected (or you have loaded non free firmware for) and it does not detect the network AND offer you any other wifi ssid to pick from, then you are already going to notice that somthing isn't right. /Andy On 28 September 2019 23:38:48 BST, Clinton H <49studeba...@gmail.com> wrote: >Package: cdrom > >If no wifi networks are detected, could you display a "If using a >laptop, check that the manual wifi switch is set to ON." warning >message and then retry detecting wifi networks. If the manual wifi >switch is set to OFF, then wifi networks will not be detected. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#872635: Info received (util-linux: FTBFS on armel: test failure)
control: severity -1 important Downgrading to important this is not RC I should have done this on previous email. /Andy
Bug#907427: openssl 1.1.1 breaks ssl tests
control: tag -1 unreproducible control: severity -1 important A clean chroot build does not reproduce this bug pulls in: libssl1.1 (= 1.1.1b-1) current build logs suggest this also builds successfully with: openssl_1.1.1a-1 Suspect that this was a transient bug /Andy (with help from jmw)
Bug#917711: grantlee5: FTBFS: dh_auto_test: cd obj-x86_64-linux-gnu && make -j2 test ARGS\+=-j2 returned exit code 2
Bug reproduces on build tests as of 2019-03-07 Possibly a regression in whatever library this calls in, as these tests do not appear to have been touched in some time. Upsteam has sime activity - an a yearly(ish) basis. This will need more experienced C++ / QT / Archaeologist skills than we have available at Cambs BSP... Sorry /Andy
Bug#872635: util-linux: FTBFS on armel: test failure
I have had a look at this as part of the Cambridge BSP 2019-03-09 I am able to reproduce this 'bug', on multiple architectures the following is copy/paste from buster on my AMD64 laptop :-p Simply running the test by hand Assuming you have a working / reliable resolver / untainted cache then the command succeeds: ../util-linux-2.33.1/tests/ts/utmp$ last -f wtmp-ipv6.LE -d root IPv6 root a.root-servers.n Wed Aug 28 21:30 - 21:40 (00:10) wtmp-ipv6.LE begins Wed Aug 28 21:30:40 2013 ../util-linux-2.33.1/tests/ts/utmp$ last -f wtmp-ipv6.LE -w -d root IPv6 root a.root-servers.net Wed Aug 28 21:30 - 21:40 (00:10) wtmp-ipv6.LE begins Wed Aug 28 21:30:40 2013 ../util-linux-2.33.1/tests/ts/utmp$ last -f wtmp-ipv6.LE -a -d root IPv6 root Wed Aug 28 21:30 - 21:40 (00:10) a.root-servers.net wtmp-ipv6.LE begins Wed Aug 28 21:30:40 2013 causing a failure can be done simply by unplugging the machine from the network, thus... ../util-linux-2.33.1/tests/ts/utmp$ last -f wtmp-ipv6.LE -d root IPv6 root dns-server Wed Aug 28 21:30 - 21:40 (00:10) wtmp-ipv6.LE begins Wed Aug 28 21:30:40 2013 ../util-linux-2.33.1/tests/ts/utmp$ last -f wtmp-ipv6.LE -w -d root IPv6 root dns-server Wed Aug 28 21:30 - 21:40 (00:10) wtmp-ipv6.LE begins Wed Aug 28 21:30:40 2013 /util-linux-2.33.1/tests/ts/utmp$ last -f wtmp-ipv6.LE -a -d root IPv6 root Wed Aug 28 21:30 - 21:40 (00:10) dns-server wtmp-ipv6.LE begins Wed Aug 28 21:30:40 2013 From this I conclude that the test itself is poor - it is assuming that there is a consistently good network / resolver for the duration of the test, something that can not be assumed to always be true. Theoretically glitches can happen anywhere, at any time. Question. What is the purpose of these 3 specific tests? If we are confirming that 'last' is formatting output in the manor specified by the switches then the tests are successful: the reported output may contain EITHER a.root-servers.net XOR dns-server If we are testing that the lookup has happened then it is perfectly acceptable that it will not be possible due to a transitory network failure. this does not mean that last itself is not working correctly only that this test did not PASS (i.e. !PASS is not the same as FAIL) Maybe remove/disable the test, or add retries? Maybe add detection for a timeout failure and simply return a different value to warn about this? signature.asc Description: OpenPGP digital signature
Bug#911036: reproducing bug / testing
Confirmed in DI daily build debian-testing-amd64-netinst.iso dated 2019-03-09 11:14 About to test with your patch at https://salsa.debian.org/installer-team/partman-lvm/merge_requests/2 (waiting for build) /Andy signature.asc Description: OpenPGP digital signature
Bug#919826: - update
Follow up following more investigation I have since re-installed my system (again from DI beta4). I have reconfirmed that yes following an upgrade after the install the system still fails to boot. However at Sledge's suggestion (and with his help) I reverted to the versions of grub that are included on the DVD set of DI beta 4 that is to say I followed the following steps: 1) reboot failed system using USB stick containing image debian-buster-DI-alpha4-arm64-DVD-1.iso 2) mount the partition on my hard disk for / /boot /boot/efi 3) downgrade grub2 to the versions found on debian-buster-DI-alpha4-arm64-DVD-1.iso i.e. dpkg -i grub-efi-arm64-bin_2.02+dfsg1-8_arm64.deb\ grub-efiarm64_2.02+dfsg1-8_arm64.deb\ grub2-common_2.02+dfsg1-8_arm64.deb \ grub-common_2.02+dfsg1-8_arm64.deb 4) reboot At this point I am able to correctly start both my old kernel (found on DI beta4 - Linux 4.18.0-3-arm64) and the current Buster kernel image (Linux 4.19.0-1-arm64) Conclusion: I have wrongly attributed this bug to the kernel - it should be re assigned to grub2 /Andy
Bug#919826: linux-image-4.19.0-1-arm64: Loading Linux 4.19.0-1-arm64 Loading initial ramdisk error: out of memory system panic
Package: linux-image-4.19.0-1-arm64 Severity: critical Justification: breaks the whole system Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? upgrading kernel in Buster from 4.18.0-3-arm64 via apt-get dist-upgrade * What exactly did you do (or not do) that was effective (or ineffective)? root@sally:~# uname -a Linux sally 4.18.0-3-arm64 #1 SMP Debian 4.18.20-2 (2018-11-23) aarch64 GNU/Linux root@sally:~# ## update apt/sources to point to a mirror (was DVD) root@sally:~# apt-get update Hit:1 http://ftp.uk.debian.org/debian buster InRelease Hit:2 http://security.debian.org/debian-security buster/updates InRelease Reading package lists... Done root@sally:~# apt-get dist-upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages were automatically installed and are no longer required: libhunspell-1.6-0 liblvm2app2.2 liblvm2cmd2.02 libpython3.6-minimal libpython3.6-stdlib python3.6 python3.6-minimal Use 'apt autoremove' to remove them. The following NEW packages will be installed: apparmor firmware-linux-free irqbalance libaio1 libdns-export1104 libhunspell-1.7-0 libisc-export1100 liblvm2cmd2.03 libnftables0 libnftnl11 libnuma1 libpython3.7-minimal libpython3.7-stdlib libuchardet0 linux-image-4.19.0-1-arm64 nftables python3.7 python3.7-minimal The following packages will be upgraded: adwaita-icon-theme apt apt-utils bash-completion bind9-host bsdutils dash dbus dbus-user-session dconf-gsettings-backend dconf-service dmeventd dmsetup e2fsprogs enchant fdisk file gcc-8-base gir1.2-atk-1.0 gir1.2-freedesktop gir1.2-gdkpixbuf-2.0 gir1.2-glib-2.0 gir1.2-gtk-3.0 gir1.2-pango-1.0 gir1.2-vte-2.91 glib-networking glib-networking-common glib-networking-services gpgv grep groff-base grub-common grub-efi-arm64 grub-efi-arm64-bin grub-efi-arm64-signed grub2-common gtk-update-icon-cache gzip init init-system-helpers iproute2 iptables isc-dhcp-client isc-dhcp-common klibc-utils krb5-locales libapparmor1 libapt-inst2.0 libapt-pkg5.0 libatk1.0-0 libatk1.0-data libbind9-161 libblkid1 libc-bin libc-l10n libc6 libcairo-gobject2 libcairo2 libcap-ng0 libcom-err2 libcroco3 libcryptsetup12 libcups2 libdbus-1-3 libdconf1 libdebconfclient0 libdevmapper-event1.02.1 libdevmapper1.02.1 libdns1104 libedit2 libefiboot1 libefivar1 libelf1 libenchant1c2a libext2fs2 libfdisk1 libfribidi0 libfstrm0 libfuse2 libgcc1 libgcrypt20 libgdk-pixbuf2.0-0 libgdk-pixbuf2.0-bin libgdk-pixbuf2.0-common libgirepository-1.0-1 libglib2.0-0 libglib2.0-data libgmp10 libgnutls30 libgpg-error0 libgraphite2-3 libgssapi-krb5-2 libgtk-3-0 libgtk-3-bin libgtk-3-common libharfbuzz0b libhogweed4 libicu63 libip4tc0 libip6tc0 libiptc0 libisc1100 libisccc161 libisccfg163 libjansson4 libjson-glib-1.0-0 libjson-glib-1.0-common libk5crypto3 libklibc libkrb5-3 libkrb5support0 libldap-2.4-2 libldap-common liblwres161 liblz4-1 libmagic-mgc libmagic1 libmount1 libnettle6 libnghttp2-14 libpam-modules libpam-modules-bin libpam-runtime libpam-systemd libpam0g libpango-1.0-0 libpangocairo-1.0-0 libpangoft2-1.0-0 libpangoxft-1.0-0 libperl5.28 libpixman-1-0 libpng16-16 libproxy1v5 libpython3-stdlib libpython3.6-minimal libpython3.6-stdlib librsvg2-2 librsvg2-common libsemanage-common libsemanage1 libsmartcols1 libsoup-gnome2.4-1 libsoup2.4-1 libsqlite3-0 libss2 libstdc++6 libsystemd0 libudev1 libuuid1 libvte-2.91-0 libvte-2.91-common libxcb-render0 libxcb-shm0 libxcb1 libxml2 libxtables12 libzstd1 linux-image-arm64 locales lvm2 man-db mount openssh-client openssh-server openssh-sftp-server os-prober perl perl-base perl-modules-5.28 publicsuffix python3 python3-chardet python3-debianbts python3-gi python3-gi-cairo python3-minimal python3-pkg-resources python3-pycurl python3-pysimplesoap python3-six python3.6 python3.6-minimal rsyslog sed systemd systemd-sysv sysvinit-utils tar task-english task-ssh-server tasksel tasksel-data telnet tzdata ucf udev util-linux util-linux-locales vim-common vim-tiny wget xdg-user-dirs xxd 203 upgraded, 18 newly installed, 0 to remove and 0 not upgraded. Need to get 144 MB of archives. After this operation, 260 MB of additional disk space will be used. Do you want to continue? [Y/n] --- 8< --- Get:207 http://ftp.uk.debian.org/debian buster/main arm64 linux-image-4.19.0-1-arm64 arm64 4.19.12-1 [39.7 MB] Get:208 http://ftp.uk.debian.org/debian buster/main arm64 linux-image-arm64 arm64 4.19+101 [7,952 B] --- 8< --- Processing triggers for systemd (240-4) ... Setting up grub-efi-arm64 (2.02+dfsg1-10) ... Installing for arm64-efi platform. Installation finished. No error reported. Generating grub configuration file ... Found linux image: /boot/vmlinuz-4.19.0-1-arm64 Found initrd
Bug#912087: reassign to systemd #912087 | openssh-server: Slow startup after the upgrade to 7.9p1
Follow up report: Bare metal install onto an APM Mustang board (see debian arm64 buildds) of debian-buster-DI-alpha4-arm64-DVD-1.iso [1] sshd takes > 7 min to start [2] This is clearly going to be a problem for Buster as things stand... /Andy [1] DI alpha4 uses kernel 4.18.20-2 (2018-11-23) I am not updating the current Buster kernel (4.19.0-1-arm64) because I am seeing a problem with it causing mustangs to panic during init (this is the next bug I will report) [2] root@sally:~# systemctl status ssh ssh.service - OpenBSD Secure Shell server Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enab Active: activating (start-pre) since Sat 2019-01-19 21:23:39 GMT; 2min 16s ag Docs: man:sshd(8) man:sshd_config(5) Cntrl PID: 459 (sshd) Tasks: 1 (limit: 4915) Memory: 2.8M CGroup: /system.slice/ssh.service ��└��─459 /usr/sbin/sshd -t syslog extract: Jan 19 21:30:49 sally systemd[1]: Starting OpenBSD Secure Shell server... Jan 19 21:31:01 sally CRON[516]: (root) CMD ( test -x /etc/cron.daily/popularity-contest && /etc/cron.daily/popularity- contest --crond) Jan 19 21:31:58 sally kernel: [ 442.940274] random: crng init done Jan 19 21:31:58 sally kernel: [ 442.940280] random: 7 urandom warning(s) missed due to ratelimiting Jan 19 21:31:58 sally systemd[1]: Started OpenBSD Secure Shell server. On Wed, 2 Jan 2019 14:45:18 +0100 Olaf van der Spek wrote: > Op do 29 nov. 2018 om 14:58 schreef Olaf van der Spek : > > > > Op do 29 nov. 2018 om 14:54 schreef Sebastian Andrzej Siewior > > : > > > > > > On 2018-11-28 13:43:07 [+0100], Olaf van der Spek wrote: > > > > > > They might just as well install haveged or configure virtio-rng in > > > > > > such > > > > > > a case. > > > > > > > > > > Right. Do you think, that it would necessary to add something to the > > > > > release notes? > > > > > > > > I do. ;) > > > > What's the workaround for VMware? > > > > > > > > Does it just take longer to start or do some services not start at all? > > > > > > It will take longer to start, it will start. Let me pass that workaround > > > > Are you sure? > > I've had php-fpm not start due to this, I think: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906686 > > Today on a Digital Ocean VM: > Jan 2 13:22:29 www systemd[1]: php7.3-fpm.service: Start operation > timed out. Terminating. > Jan 2 13:22:29 www systemd[1]: ssh.service: Start-pre operation timed > out. Terminating. > Jan 2 13:22:29 www systemd[1]: nginx.service: Start-pre operation > timed out. Terminating. > Jan 2 13:22:29 www systemd[1]: php7.3-fpm.service: Main process > exited, code=killed, status=15/TERM > Jan 2 13:22:29 www systemd[1]: php7.3-fpm.service: Failed with result > 'timeout'. > Jan 2 13:22:29 www systemd[1]: Failed to start The PHP 7.3 FastCGI > Process Manager. > Jan 2 13:22:29 www systemd[1]: nginx.service: Control process exited, > code=killed, status=15/TERM > Jan 2 13:22:29 www systemd[1]: nginx.service: Failed with result 'timeout'. > Jan 2 13:22:29 www systemd[1]: Failed to start A high performance web > server and a reverse proxy server. > Jan 2 13:22:29 www systemd[1]: ssh.service: Control process exited, > code=killed, status=15/TERM > Jan 2 13:22:29 www systemd[1]: ssh.service: Failed with result 'timeout'. > Jan 2 13:22:29 www systemd[1]: Failed to start OpenBSD Secure Shell server. > Jan 2 13:22:29 www systemd[1]: Reached target Multi-User System. > Jan 2 13:22:29 www systemd[1]: Starting Execute cloud user/final scripts... > Jan 2 13:22:29 www systemd[1]: Reached target Graphical Interface. > Jan 2 13:22:29 www systemd[1]: Starting Update UTMP about System > Runlevel Changes... > Jan 2 13:22:29 www kernel: [ 97.513700] urandom_read: 3 callbacks > suppressed > Jan 2 13:22:29 www kernel: [ 97.513702] random: cloud-init: > uninitialized urandom read (24 bytes read) > Jan 2 13:22:29 www systemd[1]: systemd-update-utmp-runlevel.service: > Succeeded. > Jan 2 13:22:29 www systemd[1]: Started Update UTMP about System > Runlevel Changes. > Jan 2 13:22:29 www systemd[1]: ssh.service: Service RestartSec=100ms > expired, scheduling restart. > Jan 2 13:22:29 www systemd[1]: ssh.service: Scheduled restart job, > restart counter is at 1.
Bug#886782: pulseaudio: Audio playback is slow (sample rate mismatch?)
Control: reassign -1 linux-image-4.9.0-5-amd64 Control: retitle -1 Audio playback is slow over DisplayPort on AMD Tahiti hardware (sample rate mismatch?) Control: version -1 4.9.65-3+deb9u2 On 15/01/18 23:18, Felipe Sateler wrote: On Tue, Jan 9, 2018 at 5:44 PM, Andy Simpkins <rattusrat...@debian.org> wrote: Package: pulseaudio Version: 10.0-1+deb9u1 Severity: important Dear Maintainer, Following the upgrade to stretch sound on my system has stopped working correctly. Instead of normal sounding playback, all audio now plays back slower than it should. This feels like it could be a sample rate issue. The only speakers on my system are on my monitors and derive their audio over display port. As part of the Squeeze upgrade I am aware that my Graphic Card drivers got changed from the 'non-free ATI drivers to the recommended FLOSS driver so it could be something there... Could you try with the trivial resampler? That should rule out the resampler as a source of the slowness. The driver change sounds a lot more likely to be the cause. Could you try booting with the jessie kernel to see if the slowness goes away? Also relevant, is the slowness present when playing to any output, or only on one (HDMI, internal, etc)? Another avenue to try is to set default-fragment-size-msec to some very high value, like 250ms. Hi Again Sorry for the long time to respond, I needed to get time with someone who knows what they are doing so they can sit with me (many thanks Sledge) OK so we have tried the following: 1) reverted back to the Jessie Kernel with free drivers, and that does not work with sound through the hdmi display port at all (the OLD fglrx catalyst non-free driver was what I used to use in Jessie did however work) 2) tested analogue output (PC motherboard) and sound works correctly. 3) moving back to Stretch, 4.9.X kernel and we have also tested using the Analogue sound port. this plays output correctly. 4) switching to hdmi / display port and the sound problem returns 5) when we try playback from different applications we get different results. Playback through VLC is 'bursty': that is sound plays for a fraction of a second, stops, then starts again having skipped some of a track. playback is also SLOW as previously reported, it sounds like VLC might be trying to re-sync. When using Quod Libet the playback is just slow (without the skipping that VLC appears to do to 'resync') Finally using speaker-test with a 1khz sine output this to my ears also sounds off pitch. 6) setting the resample method to trivial has no obvious effect (audio is still slow) 7) setting default fragment size to 0.25s only changes the 'chunk' of audio duration, playback speed is still slow, and it still pauses and skips before playing the next 'chunk' of audio (using VLC) Many thanks for your help and suggestions, this is now sounding like a driver issue. We'll re-assign this to the appropriate linux-image package I'm using and CC the kernel folks too. Dear kernel folks - sorry, looks like this is your bug (and clearly upstream!). Cheers /Andy
Bug#864925: wiki.debian.org: gridlines in tables
Package: wiki.debian.org Severity: wishlist Dear Maintainer, It would be wonderful if it were possible to explisitly enable gridlines within tables as part of the wiki markup. Better still would be to have the ability to have alternate rows with differant background colour (old school listing style tractor paper) currently table framing is set as part of the css theme. /Andy
Bug#777511: kernels tested
Ben I have tested against the following kernels on snapshot.d.o Pass 4.2.1-1 4.0.0-1 3.16.36-1 Fails 3.16.7-ckt4-3 /Andy
Bug#777511: update
Hi, it has been a while since there has been any activity against this bug. it is marked as grave, this means that it is Release Critical for Stretch. I have just run Cyril's md-mirror-resync-broken-v2.sh script on a machine running stretch rc1 (Linux debian 4.4.0-2amd64 #1 SMP Debian 4.8.15-2 (2017-01-04) x86_64 GNU/Linux) and this reports Ok, bug not found I guess that means that the regression of this bug is now fixed... Thanks /Andy signature.asc Description: OpenPGP digital signature
Bug#790796: sensord
Hi there, Back in August *2015* there was a short discussion regarding removing sonsord from lm-sensors as a result of this bug. Because it is marked as GRAVE, this bug is release critical for Stretch. Is this really a grave bug, should it be down graded? Can Sensord be removed? Is there another option? It seams to me that if you depend on the structure of a file that changes you could simply re-initialise sensord passing it the new structure. However I suspect that I am trivialising the underlying issue... /Andy
Bug#665334: [Pkg-fonts-devel] Bug#665334: non-DFSG & Type 1 Postscript embedded fonts
On 29/01/17 13:18, Paul Wise wrote: > On Sun, Jan 29, 2017 at 7:35 PM, Andy Simpkins wrote: > >> It is our belief that this is sufficient; that the package FontForge, >> and type 1 fonts generated by this package are now DFSG compliant >> because Apache 2.0 is GPL2+ compatible. > The FSF believes that Apache 2.0 is only compatible with GPLv3+ not GPLv2. > > https://www.gnu.org/licenses/license-list.html#apache2 > https://www.apache.org/licenses/GPL-compatibility.html > Well Paul you are entirely correct. Would you believe that pretty much everyone here missed that one - despite the fact that nearly every person did proof this :-) OK so what does that mean? GPL2 stuff could be problematic but ultimately the suggested action(s) would still appear valid... Karen your thoughts on this would be greatly appreciated /Andy signature.asc Description: OpenPGP digital signature
Bug#795055: Any progress or updates?
Hi Anibal, It has been a long time since we last caught up! As part of the Cambridge BSP this weekend [1] I have been looking at lisence violations such as the one in this bug that is marked as RC. It is my understanding that there is no problems with the "All rights reserved" statement included in many of the files without then including the 3-clause BSD licence text as there is no requirement (only a recommendation) for licences to appear inside each file only an overriding external licence text. This is present. HOWEVER Dmitry also points out that there are several files with 4-Clause BSD licences explicit within them, namely: src/crypt_client.c tirpc/rpcsvc/crypt.x As Dmitry points out that this is non-DFSG compliant, so it is these two files that are the cause for concern This bug was raised August 2015, and I have not been able to find any activity since. Do you have a plan of how to deal with this issue prior to the release of Stretch? [1] https://wiki.debian.org/BSP/2017/01/gb/Cambridge signature.asc Description: OpenPGP digital signature
Bug#840733: Please remove...
Hi Ted, I am currently sat at the Cambridge BSP looking at Debian RC bugs [1]. Looking at this bug report we believe that on balance the best course of action would be to remove lib/et/test_cases/imap_err.et from e2fsprogs. As you have offered to do this in your capacity as "upstream" [2] may we please ask you to do this at your earliest opportunity. Would you mind performing this as an atomic operation as this would make the process of freeze exception straight forwards. Many thanks in advance, /Andy [1] https://wiki.debian.org/BSP/2017/01/gb/Cambridge#Attendees [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840733#10 signature.asc Description: OpenPGP digital signature
Bug#665334: non-DFSG & Type 1 Postscript embedded fonts
Hi Karen, At the Cambridge BSP (Jan 27/28 2017) we have been looking at the following bugs pertaining to non-DFSG compliance with fonts embedded with non-free code: * http://bugs.debian.org/665334 opened 23 Mar 2012, last update 01 Aug 2016 modulo spam * http://bugs.debian.org/694320 opened 25 Nov 2012, last update 30 Aug 2014 blocked by #665334 * http://bugs.debian.org/694323 opened 25 Nov 2012, last update 30 Aug 2014 blocked by #665334 Synopsis: Type 1 fonts that are made using the package FontForge include font hinting code which is marked "copyright Adobe all rights reserved". This issue logically extends to every package that contains fonts that have been made using FontForge. Current State Reading #665334 it appears that FontForge historically contained fragments of code with Adobe asserted rights. We believe that this is now resolved with "autohint code is now all open source". The github repo is top licensed Apache 2.0 [1] It is our belief that this is sufficient; that the package FontForge, and type 1 fonts generated by this package are now DFSG compliant because Apache 2.0 is GPL2+ compatible. * Is our understanding of the above correct? i.e. Does the github repository top-licensing (to Apache) of the Adobe 'hinting' properly apply? * Are the font hinting fragments, that are Adobe copyright, embedded into fonts produced in FontForge, the same code as in the above repository (we *think* that this is the case)? * Thus, are these fonts (generated by the above) now covered by Apache 2.0? * And, consequently: are the fonts in the Debian archive, produced by FontForge, now to be considered under Apache 2.0; and is this sufficient to cover the embedded fragments under Apache 2.0? Assuming the above is all correct then, in order to resolve this issue, we believe that all packages that contain fonts that are generated using FontForge should contain an appropriate licence text for the font. A Mass bug filing could then be made against these packages requesting the appropriate update to the licence file. However we see this a potential minefield, and therefore seek clarification and advice before we continue. /Andy PP Debian BSP Cambridge Jan 2017 [2] [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=665334#168 [2] https://wiki.debian.org/BSP/2017/01/gb/Cambridge signature.asc Description: OpenPGP digital signature
Bug#668352: [PATCH] ed: Helping to update to packaging format 3.0
On 20/02/16 16:39, Martin Zobel-Helas wrote: > Hi, > > On Sat Feb 20, 2016 at 13:25:33 +0000, Andy Simpkins wrote: >> Dear Martin, >> >> You have marked the suggested move from format 1 to format 3 as "won't >> fix",. >> As part of the Cambridge BSP JMW has uploaded a fix for #799702, this >> would not have arisen had ed been using format 3 packaging. >> Is there a specific reason for not moving to format 3, or should we >> apply this move as well? > is there a reason that does not allow to stay with package format > version 1? i would like to stay with version 1 with this package? > > Beside that, all my packages are on low-NMU except ed. I would like to > have seen that respected or at least a delay-3 upload. > > Thanks, > Martin Martin, Many thanks for the fast response. That adds the context I was looking for. I'll leave the bug report alone. Best regards, /Andy signature.asc Description: OpenPGP digital signature
Bug#815284: RM: tmake -- RoQA; low pop-con, RC buggy, no updates since 2006
Package: ftp.debian.org Severity: normal Following up on #800280 as part of Cambridge BSP, tmake doesn't apper to be maintained (no update since 2006). Lintian output suggests that nobody cares any more... /Andy
Bug#668352: [PATCH] ed: Helping to update to packaging format 3.0
Dear Martin, You have marked the suggested move from format 1 to format 3 as "won't fix",. As part of the Cambridge BSP JMW has uploaded a fix for #799702, this would not have arisen had ed been using format 3 packaging. Is there a specific reason for not moving to format 3, or should we apply this move as well? best regards /Andy signature.asc Description: OpenPGP digital signature
Bug#799702: ed: ships /usr/share/info/dir.gz on arm64
As part of cambridge bsp we have investigated this bug. The suggested patch does not actuly fix the bug (the -B option still includes /usr/share/info/dir.gz) // info and is not just limited to arm64 Problem was caused by build rules missing build-arch target, and therefore not applying patched during autobuilder builds. JMW has uploaded fix. /Andy signature.asc Description: OpenPGP digital signature
Bug#801781: Possibly fixed.
Hi Salvo, I am looking back though open bugs at the moment and see that the mail traffic for the bug you reported stopped back at the end of October, with people suggesting that this has now gone away. Have you seen this? Have recent updates fixed the problem for you? If so can you please respond and we can close off the bug. If not can you just let us know that you are still seeing the problem and what versions you are currently running. Many thanks /Andy signature.asc Description: OpenPGP digital signature
Bug#773400: USB
Hi Vagrant, I see from your Bug report that USB isn't working on your BBB. I also see that you have a revision B or earlier BBB (Rev C moved to 4GB eMMC). In revision A6A, amongst other things that changed, was capacitor C106. This needs to be 1uF (although my testing suggests slightly higher would be better still). It affects the USB system start up, and without it hot plug just does not work. Can you please check that you are using a revision B or greater revision of the BeagleBone Black. /Andy (RattusRattus #debian-uk) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775069: installation-reports: Sucessful install Jessie-DI-rc1-amd64-netinst
Package: installation-reports Severity: normal Tags: d-i Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? install test * What exactly did you do (or not do) that was effective (or ineffective)? installed from USB stick onto bare PC * What was the outcome of this action? Sucess * What outcome did you expect instead? Sucess *** End of the template - remove these template lines *** -- Package-specific info: Boot method: usb stick Image version: cdimage.debian.org/cdimage/.jessie_di_rc1/amd64/iso-cd/debian-Jessie-DI-rc1-amd64-netinst.iso Date: Date and time of the install Machine: scan 3XS - i7 4790 cpu | asus Z97-P mobo | 16GB RAM | XFC R9-280X GPU (twin DP displays) Partitions: df -Tl will do; the raw partition table is preferred Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [o ] Detect network card:[o ] Configure network: [o ] Detect CD: [ ] Load installer modules: [o ] Clock/timezone setup: [o ] User/password setup:[o ] Detect hard drives: [o ] Partition hard drives: [o ] Install base system:[o ] Install tasks: [o ] Install boot loader:[o ] Overall install:[o ] Comments/Problems: It is Debian - It Just works (tm) Minor wobble at detect hw stage - DI reported that firmware for NIC was missing (rtl_nic/rtl8168g-2.fw) but after ignooring the error everything just worked perhaps if the NIC is working you shouldn't report an error message (first time installers may just give up at that point) I Like the fact I can now select the X desktop environment(s) I want to install from a list about time too! Well done :-) Thank you. -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION=Debian GNU/Linux installer DISTRIB_RELEASE=8 (jessie) - installer build 20150107 X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux RattusTest 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt2-1 (2014-12-08) x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 4th Gen Core Processor DRAM Controller [8086:0c00] (rev 06) lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:8534] lspci -knn: Kernel driver in use: hsw_uncore lspci -knn: 00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x16 Controller [8086:0c01] (rev 06) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation 9 Series Chipset Family USB xHCI Controller [8086:8cb1] lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:8534] lspci -knn: Kernel driver in use: xhci_hcd lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation 9 Series Chipset Family ME Interface #1 [8086:8cba] lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:8534] lspci -knn: 00:1a.0 USB controller [0c03]: Intel Corporation 9 Series Chipset Family USB EHCI Controller #2 [8086:8cad] lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:8534] lspci -knn: Kernel driver in use: ehci-pci lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation 9 Series Chipset Family HD Audio Controller [8086:8ca0] lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:8615] lspci -knn: Kernel driver in use: snd_hda_intel lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation 9 Series Chipset Family PCI Express Root Port 1 [8086:8c90] (rev d0) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1c.2 PCI bridge [0604]: Intel Corporation 9 Series Chipset Family PCI Express Root Port 3 [8086:8c94] (rev d0) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1c.3 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev d0) lspci -knn: 00:1d.0 USB controller [0c03]: Intel Corporation 9 Series Chipset Family USB EHCI Controller #1 [8086:8ca6] lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:8534] lspci -knn: Kernel driver in use: ehci-pci lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation 9 Series Chipset Family Z97 LPC Controller [8086:8cc4] lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:8534] lspci -knn: 00:1f.2 SATA controller [0106]: Intel Corporation 9 Series Chipset Family SATA Controller [AHCI Mode] [8086:8c82] lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:8534] lspci -knn: Kernel driver in use: ahci lspci -knn:
Bug#745034: GPIO is limited to just 32 pins
Submitted upstream #42158 (https://savannah.nongnu.org/bugs/index.php?42158) /Andy On Thursday 17 Apr 2014 18:19:18 Michael Biebl wrote: Am 17.04.2014 14:10, schrieb Andy Simpkins: Package: avrdude Version: 6.1-1 Severity: important tags: upstream, jessie, sid Hi there, This is an upstream bug that is causing me problems with implementing bit bashed sysfs gpio on armhf (in this case a beagle bone black and derivative) i.e. type = linuxgpio attempting to configure GPIO line 45 failed with the error message: pin must be in the range 0-31 As is convention I am reporting this bug to the Debian BTS and not to the upstream maintainer :-) Actually, since this is an upstream bug, I would prefer if you file it upstream and report back with the link to upstream bug number so I can mark it as forwarded. Thanks, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745034: GPIO is limited to just 32 pins
Package: avrdude Version: 6.1-1 Severity: important tags: upstream, jessie, sid Hi there, This is an upstream bug that is causing me problems with implementing bit bashed sysfs gpio on armhf (in this case a beagle bone black and derivative) i.e. type = linuxgpio attempting to configure GPIO line 45 failed with the error message: pin must be in the range 0-31 As is convention I am reporting this bug to the Debian BTS and not to the upstream maintainer :-) Many thanks for all your hard work. /Andy THE FIX: The definition HAVE_LINUX_GPIO is used to set PIN_MAX between either 31 (default) or 255, however it is called HAVE_LINUXGPIO in the rest of the codebase. pindefs.h:62 #ifdef HAVE_LINUX_GPIO becomes #ifdef HAVE_LINUXGPIO TO REPRODUCE: I use a custom config file: lwb-avrdude.conf programmer id= keyboard; desc = Toby Churchill Ltd. LWB platform, keyboard; type = linuxgpio; reset = ~45; sck = 2; mosi = 3; miso = 5; ; call avrdude thus: avrdude -v -p m32 -C ./lwb-avrdude.conf -c keyboard -e returns: avrdude: Version 6.1, compiled on Apr 16 2014 at 17:41:25 Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/ Copyright (c) 2007-2014 Joerg Wunsch System wide configuration file is ./lwb-avrdude.conf avrdude: error at line 5 of ./lwb-avrdude.conf: pin must be in the range 0-31 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#707004: upgrade-reports: sysklogd removed when upgrading from squeeze to wheezy (system existed under lenny) NO log deamon installed to replace it
Package: upgrade-reports Severity: important Dear Maintainer, As part of the upgrade to Wheezy, sysklogd got removed. There was no replacement log system installed in its place. The system was origanlly installed under Lenny, before an upgrade squeeze. This means that rsyslogd was not installed on the system. To reproduce this: 1) Create a squeeze chroot with standard debootstrap 2) install sysklogd manually 3) Change apt.sources to wheezy 4) apt-get update 5) apt-get dist-upgrade OR apt-get initscripts (sysklogd was removed from wheezy due to an RC bug) Suggested fix could be to install a transitional package into wheezy proposed updates called sysklogd at a version sufficient for the Breaks: given in init-scrpts in wheezy, letting this package Depends: on rsyslog /Andy RattusRattus -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699092: kwalletmanager multiple wallets / default wallet
Package: kwalletmanager Severity: normal Version: 4:4.8.4-3 forwarded: https://bugs.kde.org/show_bug.cgi?id=286768 Scope Affects KDE systems with more than one wallet Description When selecting the default wallet (or a different wallet for local passwords - they both perform in the same way) the drop down box is populated with the same number of wallets you have, but the options consist of all of the wallets listed in alphabetical order however listitem[0] is shown with the same name as listitem[1]. i.e. all of the wallets are shown in alphabetical order EXCEPT the first wallet in the list which is shown the same as the 2nd. Selecting the first wallet in the list has the same effect as selecting the 2nd wallet i.e. listitem[0] and listitem[1] have the same effect. It is not possible to select the first wallet (in alphabetical order) Example: create three wallets in the system in this sequance: C_test B_test A_test It will not be possibel to make the A_test wallet the default wallet. The dropdown box will show (in this order) B_test B_test C_test Let us select the first B_test as the default wallet Mow delete C_test and B_test wallets It is still not possible to make A_test the default wallet Rebooting the system will now cause the system to create a wallet called B_test and you still can not select A_test as your default wallet. to do so you will need to create a wallet of lower alphabetical order i.e 'A' You can now select the default wallet as A_test and then delete the wallet A -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699094: UPGRADE-REPORTS: Squeeze to Wheezy KDE WiFi managment
Package: upgrade-reports Severity: normal When upgrading from squeeze to wheezy WiFi stopped working. This was because the KNetworkManager has been dropped, and replaced with Plasma-widget-networkmanagment. Adding the new network managment widget into the system tray enabled wireless networking to finction again, however the upgrade probably should have migrated to the new widget automaticly Recomendation - an advisory note be genorated for the release notes to warn about the possible loss of wireless networking in KDE and how to resolve the issue. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669878: Reproduced 669878 - Could not perform immediate configuration on 'phonon-backend-vlc'
Ran into this problem today at the cambridge BSP when performing a dist-upgrade from squeeze. again the reported problem was: E: Could not perform immediate configuration on 'phonon-backend-vlc'. Please see man 5 apt.conf under APT::Immediate-Configure for details. I performed apt-get upgrade as reccomended then tried dist-upgrade again still failing with the same error I got out of the problem by apt-get install apt initramfs-tools nfs-common where initramfs-tools nfs-common were required to be upgraded because of increased dependancy requirements. I guess this doesn't help resolve the bug, but at least shows that it is reproduceable. BR Andy NOTE: CC'd to debian-release at request of JMW as this will affect dist- upgrades for kde users -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695163: missing file debian/watch
Package: 9base Version: 1:6-5 Severity: minor Tags: patch User: andy-deb...@koipond.org.uk Usertags: debian-qa-watch Debian policy is packages should provide a watch file where possible. having looked through the package the attached watchfile appears sufficiant for the current version. Please consider including it. Andy Simpkins (RattusRattus) andy-deb...@koipond.org.uk -- 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/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash version=3 http://dl.suckless.org/tools/9base-(.*).tar.gz
Bug#548389: additional information
I performed similar task (dist upgrade to squeeze) and ended up with the chain loader (what I wanted). the chain loader to grub 2 worked just fine, I was happy with the operation of grub2, everything appeared to work correctly (all boot options checked out), so followed the option to remove grub-legacy upgrade-from-grub-legacy after which system failed to boot, no menu options where prescented Problem resolved by booting from a live CD, chroot to my linux partition then grub-instal /dev/sda Sorry can't remember exact grub error message... 8--- Additional: having run grub 2 for about a week now the bootloader failed again. this time Grub 2 would start but would inform me that it couldn't find any installed modules, continuing would prescent the usual BIOS can't find system disk error Adian ruuning grub-instal /dev/sda appears to have recovered the system, and I once again have my boot options for a few kernels, 'doze and 'doze re-install on the lappy. Regards Andy
Bug#533727: Any news on this bug?
Did you submit this bug upstream? Can you please provide me with some more information so that I can attempt to reproduce this: 1) What is your .vhd file (vhdl?) 2) Can you please send me a copy of the file (just in case the problem is specific to all or part of the file sequence) 3) Any other information that you think may be relevant to tracking down this problem... Kind regards Andy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532331: bwm-ng: reported average speeds become 'nan'
Package: bwm-ng Version: 0.6-2 Severity: normal When monitoring bandwidth averaged over 30s, after a while transfer speeds reported change to 'nan'. This doesn't effect reported rate or max rate (sorry I din't check if sum reports correctly). Suspect a variable 'wrapping' to a negative value Regards Andy -- System Information: Debian Release: 5.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-686 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages bwm-ng depends on: ii libc6 2.7-18 GNU C Library: Shared libraries ii libncurses5 5.7+20081213-1 shared libraries for terminal hand ii libstatgrab6 0.16-0.1 library being useful interface to bwm-ng recommends no packages. bwm-ng 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
