Bug#946193: workaround
I encountered the same problem upgrading from (jessie to) stretch to buster today. I was successful using the simpler workaround of deleting compatibility.ini from my profile. Once Firefox started, it recreated a new compatibility.ini file automatically. Here is a comparison of the old and new files: ota@alfriston:~$ diff ~/.mozilla/firefox/bhojq6pr.default/compatibility.ini ~/firefox-pre-buster-profile/compatibility.ini 2c2 < LastVersion=68.3.0_20191203235607/20191203235607 --- > LastVersion=68.3.0_20191204133900/20191204133900 ota@alfriston:~$ firefox --version Mozilla Firefox 68.3.0esr ota@alfriston:~$ cat /etc/debian_version 10.2 ota@alfriston:~$ dpkg -l | grep firefox ii firefox-esr 68.3.0esr-1~deb10u1 amd64Mozilla Firefox web browser - Extended Support Release (ESR) ota@alfriston:~$ cat /etc/debian_version 10.2 So this minor versioning glitch appears to explain the problem as described above. I also found the Mozilla bug(s) from July that addresses a similar problem, but which apparently doesn't handle this case. https://bugzilla.mozilla.org/show_bug.cgi?id=1554029 https://bugzilla.mozilla.org/show_bug.cgi?id=1568252 HtH, Ted
Bug#947860: release-notes: Sec 4.3 preparing sources.list omits explicit statement of key change
Package: release-notes Severity: normal Dear Maintainer, When upgrading from Jessie to Stretch, I was confused about when I was supposed to actually edit the sources.list file. I found section 4.3 "Preparing APT source-list files" unclear on when to perform this critical step. I investigated the apt-get dist-upgrade command, but it does not edit sources.list for me. I also found earlier mention that I should be careful that all deb lines should mention "jessie" and later (in section 4.4 "Upgrading packages") the comment "double-check that the APT source entries [...] refer either to ''stretch'' or to ''stable''". Apparently, between these two I was supposed to edit the file to replace jessie with stretch. The corresponding text for Buster is about the same in this respect. I think adding a summary sentence to this effect at the beginning of section 4.3 would be sufficient. While I've used Debian, and Ubuntu before that, for years, my exposure to apt/aptitude has been sporadic and doubtless my mental model of its operation is askew. Making the obvious steps more explicit would help less experienced users with this upgrade process. Perhaps changing the first sentence of 4.3 to: Before starting the upgrade you must reconfigure APT's source-list files (/etc/apt/sources.list and files under /etc/apt/sources.list.d/) to add sources for stretch and remove sources for jessie . Thank you for your consideration. Ted Anderson -- System Information: Debian Release: 8.11 APT prefers oldoldstable APT policy: (500, 'oldoldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.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 Init: systemd (via /run/systemd/system)
Bug#756571: Loops: modify_ldt: Invalid argument; err:module:find_forwarded_export ... for 'krnl386.exe16.MapLS'
Package: wine Version: 1.4.1-4 Severity: normal Tags: upstream Dear Maintainer, * What led up to the situation? After 57 days of uptime, I rebooted and picked up a new kernel (there were several kernel updates since early June). However, I was unable to start Notes7 under Wine. The result is that the program looped after generating these messages: p11-kit: couldn't load module: /usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: /usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: cannot open shared object file: No such file or directory modify_ldt: Invalid argument modify_ldt: Invalid argument modify_ldt: Invalid argument modify_ldt: Invalid argument modify_ldt: Invalid argument err:module:find_forwarded_export module not found for forward 'krnl386.exe16.MapLS' used by Lc:\\windows\\system32\\KERNEL32.dll I'm pretty sure the first of these is irrelevant. * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? Web searching for terms in the final error message were unenlightening. Eventually, I was lead to a launchpad bug 1327532[1] and a Linux Kernel Mailing List discussion[2]. I was able to confirm that setting ldt16 to 1 resolved the problem and allowed Notes7 to start. # echo 1 /proc/sys/abi/ldt16 From the linux-image-amd64 change log I saw that these two patches were included in the kernel on 29 Jun 2014 (linux (3.2.60-1) wheezy; urgency=medium). I installed this kernel on July 7th. - [amd64] modify_ldt: Ban 16-bit segments on 64-bit kernels - [amd64] modify_ldt: Make support for 16-bit segments a runtime option Eventually, I found Wine bug 36664[3] and FAQ-10.22[4]. The diagnosis was made difficult because my error message was unusual in containing find_forwarded_export and my program is a 32-bit application. Apparently, even some 32-bit applications make use of 16-bit DLLs or functions. [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1327532 [2] https://lkml.org/lkml/2014/5/7/508 [3] https://bugs.winehq.org/show_bug.cgi?id=36664 [4] http://wiki.winehq.org/FAQ#head-bf26e320f9d279ba6d2e039f7d91f0a60a433f88 -- System Information: Debian Release: 7.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash % uname -a Linux anapneo 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u3 x86_64 GNU/Linux IBM Lotus Notes, version 7.0.3. Versions of packages wine depends on: ii debconf [debconf-2.0] 1.5.49 ii wine-bin 1.4.1-4 wine recommends no packages. Versions of packages wine suggests: pn binfmt-support none pn klamav | clamavnone pn ttf-mscorefonts-installer none pn winbindnone pn wine-doc none Versions of packages libwine depends on: ii debconf [debconf-2.0] 1.5.49 ii libc6 2.13-38+deb7u3 ii libdbus-1-31.6.8-1+deb7u3 ii libfontconfig1 2.9.0-7.1 ii libfreetype6 2.4.9-1.1 ii libgnutls262.12.20-8+deb7u2 ii libice62:1.0.8-2 ii libjpeg8 8d-1+deb7u1 ii libmpg123-01.14.4-1 ii libncurses55.9-10 ii libodbc1 2.2.14p2-5 ii libpng12-0 1.2.49-1 ii libsm6 2:1.2.1-2 ii libssl1.0.01.0.1e-2+deb7u11 ii libtiff4 3.9.6-11 ii libtinfo5 5.9-10 ii libx11-6 2:1.5.0-1+deb7u1 ii libxcomposite1 1:0.4.3-2 ii libxcursor11:1.1.13-1+deb7u1 ii libxext6 2:1.3.1-2+deb7u1 ii libxi6 2:1.6.1-1+deb7u1 ii libxinerama1 2:1.1.2-1+deb7u1 ii libxml22.8.0+dfsg1-7+wheezy1 ii libxrandr2 2:1.3.2-2+deb7u1 ii libxrender11:0.9.7-1+deb7u1 ii libxslt1.1 1.1.26-14.1 ii libxxf86vm11:1.1.2-1+deb7u1 ii multiarch-support 2.13-38+deb7u3 ii zlib1g 1:1.2.7.dfsg-13 Versions of packages libwine recommends: ii libgsm1 1.0.13-4 ii libv4l-00.8.8-3 ii libwine-alsa1.4.1-4 ii libwine-gl 1.4.1-4 ii ttf-liberation 1.07.2-6 Versions of packages libwine suggests: pn libwine-cms none pn libwine-gphoto2 none pn libwine-ldap none pn libwine-openal none pn libwine-printnone pn libwine-sane none pn wine-doc none -- 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#717120: cscope: 64-bit build reports no matches for some symbols the 32-bit build finds.
Package: cscope Version: 15.7a Severity: normal I recently moved from Ubuntu Lucid 10.04.4 LTS (i386) to Debian Wheezy (amd64). I have used cscope for years and depend upon it for helping navigate a large C++ code base. I recently found that the version of cscope that comes with Wheezy for the amd64 architecture cannot find some symbols that surely exist. Specifically, a symbol whose name is syncFsEverywhere. Experimentation showed that searching for .yncFsEverywhere and [s]yncFsEverywhere .*cFsEverywhere produced the expected matches, but syncEveryw.* produced no results. Using the binary from my old Lucid installation, I was able to remove and rebuild the cscope database and it was able to locate 11 instances of this symbol. Next I tried uninstalling Wheezy's 64-bit version and replacing it with the i386 package. This was also able to find the symbols. Then I installed the Wheezy cscope source package using apt and built the 64-bit binary myself. This version worked the same as the repository's 64-bit version: no results. Finally, I downloaded the 15.8a release from SourceForge (http://sourceforge.net/projects/cscope/files/cscope/15.8a/) and built it. That version works fine compiled for the amd64 architecture, producing the expected 11 results. I reviewed the change log between the Debian version 15.7a and the SourceForge version 15.8a and didn't see anything obvious to explain the change. Perhaps just upgrading Wheezy to the latest upstream version would be the best approach. I notice that Debian bug #689198 also suggests this. -- System Information: Debian Release: 7.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/2 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 cscope depends on: pn ed none ii libc62.13-38 ii libncurses5 5.9-10 ii libtinfo55.9-10 cscope recommends no packages. Versions of packages cscope suggests: pn cscope-el none -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
