Bug#907145: closed by Jeremy Bicha (Re: Bug#907145: gksu: Fails to change PATH according to /ect/sudoers)
Aha! Thank you. Since it was used in the menu shortcut of "Root Terminal" for anyone who used the XFCE desktop, perhaps it should be moved to "xfce4" ? They should probably replace the implementation of the menu since they formerly depended on gksu. I verified after upgrading all packages to current testing that my menu for "Root Terminal" still references gksu. On Fri, Aug 24, 2018 at 10:48 PM Debian Bug Tracking System < ow...@bugs.debian.org> wrote: > This is an automatic notification regarding your Bug report > which was filed against the gksu package: > > #907145: gksu: Fails to change PATH according to /ect/sudoers > > It has been closed by Jeremy Bicha . > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Jeremy Bicha < > jbi...@debian.org> by > replying to this email. > > > -- > 907145: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907145 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems > > > > -- Forwarded message -- > From: Jeremy Bicha > To: toff.till...@gmail.com, 907145-d...@bugs.debian.org > Cc: > Bcc: > Date: Fri, 24 Aug 2018 06:44:24 -0400 > Subject: Re: Bug#907145: gksu: Fails to change PATH according to > /ect/sudoers > On Fri, Aug 24, 2018 at 6:24 AM Chris Tillman > wrote: > > This showed gksu is not changing the path when calling xfce4-terminal. > > gksu was removed from Debian Testing in January and from Unstable 2 > months after that. Therefore, gksu is no longer supported in Testing > at all. > > For your other issues, maybe this explanation will help some: > > https://unix.stackexchange.com/questions/460478/debian-su-and-su-path-differences/460769#460769 > > I am closing this bug because there is nothing we can do in gksu and > it's not obvious to me whether there is another package to reassign > this issue to. > > Thanks, > Jeremy Bicha > > > -- Forwarded message -- > From: Chris Tillman > To: Debian Bug Tracking System > Cc: > Bcc: > Date: Fri, 24 Aug 2018 22:21:37 +1200 > Subject: gksu: Fails to change PATH according to /ect/sudoers > Package: gksu > Version: 2.0.2-9+b1 > Severity: normal > > Dear Maintainer, > >* What led up to the situation? > I was upgrading the testing distribution after several months using > aptitude. I > upgraded about half the packages, but when I went to upgrade the other > half I > received errors from dpkg: > > Preconfiguring packages ... > dpkg: warning: 'ldconfig' not found in PATH or not executable > dpkg: warning: 'start-stop-daemon' not found in PATH or not executable > dpkg: error: 2 expected programs not found in PATH or not executable > Note: root's PATH should usually contain /usr/local/sbin, /usr/sbin and > /sbin > E: Sub-process /usr/bin/dpkg returned an error code (2) > >* What exactly did you do (or not do) that was effective (or > ineffective)? > I searched online and found the cause of the errors was, as the error > states, > the PATH being incorrect. I checked the PATH resulting when I chose "Root > Terminal" from the menu, and this path did not include the sbin > directories. > > root@ctillman:/home/chris# echo $PATH > /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games > > I tried sudo from a regular user terminal window to check the path which > would > come up with it: > > chris@ctillman:~$ sudo bash -c 'echo $PATH' > /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin > > And then, because gksu starts Root Terminal, I tried the equivalent with > gksu: > > chris@ctillman:~$ gksu "bash -c 'echo $PATH'" > gksu-run: gksu/bash -c 'echo > > |usr|local|bin:|usr|bin:|bin:|usr|local|games:|usr|games'/5044-0-ctillman_TIME11346051 > gksu-run: 1f53968cb8fe3d752131e6a334975c84 > > /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games > > This showed gksu is not changing the path when calling xfce4-terminal. > > My /etc/sudoers contents: > > root@ctillman:~# cat /etc/sudoers > # > # This file MUST be edited with the 'visudo' command as root. > # > # Please consider adding local content in /etc/sudoers.d/ instead of > # directly modifying this file. > # > # See the man page for details on how to write a sudoers file. > # > Defaultsenv_reset > Defaultsmail_badpass > Defaults > secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" > > # Host alias specification > > # User alias specification > > # Cmnd alias specif
Bug#907145: gksu: Fails to change PATH according to /ect/sudoers
Package: gksu Version: 2.0.2-9+b1 Severity: normal Dear Maintainer, * What led up to the situation? I was upgrading the testing distribution after several months using aptitude. I upgraded about half the packages, but when I went to upgrade the other half I received errors from dpkg: Preconfiguring packages ... dpkg: warning: 'ldconfig' not found in PATH or not executable dpkg: warning: 'start-stop-daemon' not found in PATH or not executable dpkg: error: 2 expected programs not found in PATH or not executable Note: root's PATH should usually contain /usr/local/sbin, /usr/sbin and /sbin E: Sub-process /usr/bin/dpkg returned an error code (2) * What exactly did you do (or not do) that was effective (or ineffective)? I searched online and found the cause of the errors was, as the error states, the PATH being incorrect. I checked the PATH resulting when I chose "Root Terminal" from the menu, and this path did not include the sbin directories. root@ctillman:/home/chris# echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games I tried sudo from a regular user terminal window to check the path which would come up with it: chris@ctillman:~$ sudo bash -c 'echo $PATH' /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin And then, because gksu starts Root Terminal, I tried the equivalent with gksu: chris@ctillman:~$ gksu "bash -c 'echo $PATH'" gksu-run: gksu/bash -c 'echo |usr|local|bin:|usr|bin:|bin:|usr|local|games:|usr|games'/5044-0-ctillman_TIME11346051 gksu-run: 1f53968cb8fe3d752131e6a334975c84 /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games This showed gksu is not changing the path when calling xfce4-terminal. My /etc/sudoers contents: root@ctillman:~# cat /etc/sudoers # # This file MUST be edited with the 'visudo' command as root. # # Please consider adding local content in /etc/sudoers.d/ instead of # directly modifying this file. # # See the man page for details on how to write a sudoers file. # Defaultsenv_reset Defaultsmail_badpass Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" # Host alias specification # User alias specification # Cmnd alias specification # User privilege specification rootALL=(ALL:ALL) ALL chris ALL=(ALL:ALL) ALL # Allow members of group sudo to execute any command %sudo ALL=(ALL:ALL) ALL # See sudoers(5) for more information on "#include" directives: #includedir /etc/sudoers.d -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_NZ.utf8, LC_CTYPE=en_NZ.utf8 (charmap=UTF-8), LANGUAGE=en_NZ:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gksu depends on: ii gconf-service 3.2.6-4.1 ii libatk1.0-0 2.28.1-1 ii libc6 2.27-5 ii libcairo2 1.15.10-3 ii libfontconfig12.13.0-5 ii libfreetype6 2.8.1-2 ii libgconf-2-4 3.2.6-4.1 ii libgdk-pixbuf2.0-02.36.12-2 ii libgksu2-02.0.13~pre1-9+b2 ii libglib2.0-0 2.56.1-2 ii libgnome-keyring0 3.12.0-1+b2 ii libgtk2.0-0 2.24.32-2 ii libpango-1.0-01.42.4-1 ii libpangocairo-1.0-0 1.42.4-1 ii libpangoft2-1.0-0 1.42.4-1 ii libstartup-notification0 0.12-5 ii sudo 1.8.23-2 Versions of packages gksu recommends: ii gnome-keyring 3.28.2-1 gksu suggests no packages. -- no debconf information
Bug#862397: Bug#868704: Thunar: crashes reproducible when folder content is changed by seafile
On Wed, Feb 21, 2018 at 11:42 PM, Yves-Alexis Perez <cor...@debian.org> wrote: > On Tue, 2018-02-20 at 22:52 +0100, Antonio Cebrián wrote: > > It seems to be the same bug as: > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862397 > > > > Solved in Thunar 1.6.13-2 from testing. > > > Can you all confirm/infirm that? > > Regards, > -- > Yves-Alexis I am currently on Thunar 1.6.13. The script Ken Milmore mentioned did not trigger a Thunar freeze in a "normal" directory. It was flashing furiously, though. When I changed to a large directory (ls * | wc -l = 5,364) the behavior with this script was different. The cursor changed to a "busy" type symbol. But the file manager was still active and functional. This time Ctrl C did not work to quit the process, but I was still able to close both the terminal window and Thunar. I think maybe this is just related to the script. But eventually my machine recovered, there was no crash or freeze, and Thunar always remained responsive to the user. In my case when encountering this problem, I was running tests in EiffelStudio, and these tests resulted in removing / editing a dozen or two log files which were visible in the Thunar window (as I always had it sorted by Date modified with most recent at the top). So that activity is consistent with the reports in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868704 . I tried a sample of my former activity and didn't have any problems with 1.6.13, so I think this probably was the same bug. -- Chris Tillman Developer
Bug#862397: thunar: Thunar crashes when left open for a time showing a folder with thousands of items in it
Package: thunar Version: 1.6.11-1 Severity: important Dear Maintainer, * What led up to the situation? Repeatedly, I was working in another window and came back to the file manager to do something different when I found the window to be totally non-responsive. A couple of times it froze the machine completely so it did not respond to keystrokes at all. I noticed that it only happened when I left it showing the main folder I am working in, which has 4,597 items currently according to ls * | wc -l. Finally I switched to PCManFM and it does not seem to have these issues. -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_NZ.utf8, LC_CTYPE=en_NZ.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages thunar depends on: ii desktop-file-utils 0.23-1 ii exo-utils 0.10.7-1 ii libatk1.0-0 2.22.0-1 ii libc6 2.24-9 ii libcairo2 1.14.8-1 ii libdbus-1-3 1.10.16-1 ii libdbus-glib-1-20.108-2 ii libexo-1-0 0.10.7-1 ii libgdk-pixbuf2.0-0 2.36.5-2 ii libglib2.0-02.50.3-2 ii libgtk2.0-0 2.24.31-2 ii libgudev-1.0-0 230-3 ii libice6 2:1.0.9-2 ii libnotify4 0.7.7-1+b1 ii libpango-1.0-0 1.40.4-1 ii libsm6 2:1.2.2-1+b3 ii libthunarx-2-0 1.6.11-1 ii libxfce4ui-1-0 4.12.1-2 ii libxfce4util7 4.12.1-3 ii libxfconf-0-2 4.12.1-1 ii shared-mime-info1.8-1 ii thunar-data 1.6.11-1 Versions of packages thunar recommends: ii dbus-user-session [default-dbus-session-bus] 1.10.16-1 ii dbus-x11 [dbus-session-bus] 1.10.16-1 ii gvfs 1.30.3-1 ii libfontconfig12.11.0-6.7+b1 ii libfreetype6 2.6.3-3.1 ii libpangocairo-1.0-0 1.40.4-1 ii libpangoft2-1.0-0 1.40.4-1 ii thunar-volman 0.8.1-2 ii tumbler 0.1.31-2+b3 ii xdg-user-dirs 0.15-2+b1 ii xfce4-panel 4.12.1-2 Versions of packages thunar suggests: ii thunar-archive-plugin 0.3.1-4 ii thunar-media-tags-plugin 0.2.1-1+b2 -- no debconf information
Bug#856456: [Pkg-xfce-devel] Bug#856456: xfce4-ter: Clipboard contents erased on child application exit (only when preference is copy on select)
Great news, thanks. Of course, not urgently needed. On Sat, Mar 4, 2017 at 1:10 AM, Yves-Alexis Perez <cor...@debian.org> wrote: > On Fri, Mar 03, 2017 at 06:41:14AM +1300, Chris Tillman wrote: > > The bug has been fixed upstream. I don't really intend to backport the > patch and ask for a freeze exception, but it will be part of the next > version. > > Regards. > -- > Yves-Alexis Perez > -- Chris Tillman Developer
Bug#856456: [Pkg-xfce-devel] Bug#856456: xfce4-ter: Clipboard contents erased on child application exit (only when preference is copy on select)
On Thu, Mar 2, 2017 at 10:06 PM, Yves-Alexis Perez <cor...@debian.org> wrote: > On Thu, 2017-03-02 at 18:06 +1300, Chris Tillman wrote: > > Thank you for the response. > > Please leave the bug on CC. > > > > It does work differently for me, if I turn the option off. Then I use > > Ctrl-Shift C to copy, and that copy persists after exiting the program, > so > > it can be pasted later; rather than the text which was copied by just > > highlighting with the option on, which disappears on exit. They seem to > be > > different mechanisms. > > Actually you're right, there's something more fishy. Assuming you're > running > Xfce, you already run a clipboard manager inside xfsettingsd anyway. > > On Linux/Unixes there are two clipboards: the X selection clipboard > (select/middle click), and the GTK clipboard (ctrl-C/ctrl-V or, in > terminals > shift-ctrl-C/shift-ctrl-V). They are usually not persistent (if you > unselect > or quit the application they're gone), thus the need for a clipboard > manager > to handle persistence. > > In your case I have the feeling that when the application is quit, the > selection is actually emptied, and it is then propagated to the GTK > clipboard. > > I'll forward this upstream so they can have a look. > > Regards, > -- > Yves-Alexis Ah, that would make sense. I wasn't aware there were two different ways of copying using the 2 different subsystems. -- Chris Tillman Developer
Bug#856456: xfce4-ter: Clipboard contents erased on child application exit (only when preference is copy on select)
Package: xfce4-terminal Version: 0.8.3-1 Severity: normal File: xfce4-ter Tags: upstream Dear Maintainer, I noticed the setting for "Automatically copy selection to clipboard" in the Preferences. I thought, that's cool, like Putty does. But it doesn't work quite as reliably as you'd like. Within a given program (e.g. less), it puts whatever you highlight on the clipboard and that can be pasted another place in the program, or to another window. The only issue is if you want to close that program, then open another one or another instance of the same one, and use the copied material. It has evaporated. I determined the point it evaporates is when the program exits. Even more curious, sometimes rather than evaporating, another bit of text (the same length, and from the same columns) from the scrollback of the terminal will get substituted on the clipboard when quitting. I turned it off for now and went back to Ctrl-Shift-C, Ctrl-Shift-V. -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_NZ.utf8, LC_CTYPE=en_NZ.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xfce4-terminal depends on: ii exo-utils 0.10.7-1 ii libatk1.0-0 2.22.0-1 ii libc6 2.24-9 ii libcairo2 1.14.8-1 ii libgdk-pixbuf2.0-0 2.36.4-1 ii libglib2.0-02.50.2-2 ii libgtk-3-0 3.22.8-1 ii libpango-1.0-0 1.40.3-3 ii libvte-2.91-0 0.46.1-1 ii libx11-62:1.6.4-3 ii libxfce4ui-2-0 4.12.1-2 ii libxfce4util7 4.12.1-3 Versions of packages xfce4-terminal recommends: ii dbus-user-session [default-dbus-session-bus] 1.10.16-1 ii dbus-x11 [dbus-session-bus] 1.10.16-1 xfce4-terminal suggests no packages. -- no debconf information
Bug#852779: installation-reports: Mostly successful install amd64 stretch RC1
Google tells me bug 849124 covers the reportbug issues, and installing gir1.2-vte-2.91 did fix the issue. I reckon that is important enough, though, that Stretch should not be released until that fix makes its way into the release candidate. On Fri, Jan 27, 2017 at 10:18 PM, Chris Tillman <toff.till...@gmail.com> wrote: > Package: installation-reports > Severity: normal > Tags: d-i > > Dear Maintainer, > > I used the graphical installer (for the first time). It worked well, but > really provided nothing beyond the curses-based installer. I'd recommend > some artist provide some lovely backgrounds or maybe a Debian history > lesson > playing under the progress bar or something. Just sayin'. > > I Hooked up wifi with no difficulty. Resized my > Windows partition ... took a bit long, could use a progress marker , or > just > a spinning ball or such to let you know it's all still OK. Selected > suggested > scheme for partitions, well done, just what I was planning. > > One minor item, and who knows this may be my hardware. When I was using the > touchpad to try to select the Complete button on any screen, I had a > difficult > time. If I made a small stroke towards the button and lifted my finger, > when > I put the finger down again the cursor would go back to the center of the > screen. I finally learned the way to make it work was to make one > continuous > movement to the Complete button, then I could select it when I got there. > > At the end, when Grub was installing, it did have an incorrect message. It > said it had found a Vista loader when in fact it is Windows 7. After the > install and reboot, turns out it knew this all along ... in the boot menu > it is listed as Windows 7. > > After the boot into the system, I selected reportbug from the menu. It > didn't respond. I then went into a terminal and started it. During setup, > I asked for it to be the graphical version. When it tried to open > graphically, > it gave the attached errors. > > I suspect something wasn't installed during the basic installation to > support > it. I am using XFCE, so maybe not as well supported out of the box. > > Since reportbug seems to work in the text mode, I guess I won't report a > bug > against it ... must be system installation support. > > > > -- Package-specific info: > > Boot method: CD > Image version: Stretch RC1 > Date: > > Machine: HP Probook 4530s > Partitions: > > > Base System Installation Checklist: > [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it > > Initial boot: [ ] > Detect network card:[ ] > Configure network: [ ] > Detect CD: [ ] > Load installer modules: [ ] > Clock/timezone setup: [ ] > User/password setup:[ ] > Detect hard drives: [ ] > Partition hard drives: [ ] > Install base system:[ ] > Install tasks: [ ] > Install boot loader:[ ] > Overall install:[ ] > > Comments/Problems: > >and ideas you had during the initial install.> > > > -- > > 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="9 (stretch) - installer build 20170112" > X_INSTALLATION_MEDIUM=cdrom > > == > Installer hardware-summary: > == > uname -a: Linux ctillman 4.8.0-2-amd64 #1 SMP Debian 4.8.15-2 (2017-01-04) > x86_64 GNU/Linux > lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation > Core Processor Family DRAM Controller [8086:0104] (rev 09) > lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:167c] > lspci -knn: 00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200/2nd > Generation Core Processor Family PCI Express Root Port [8086:0101] (rev 09) > lspci -knn: Kernel driver in use: pcieport > lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation > 2nd Generation Core Processor Family Integrated Graphics Controller > [8086:0116] (rev 09) > lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:167d] > lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation 6 > Series/C200 Series Chipset Family MEI Controller #1 [8086:1c3a] (rev 04) > lspci -knn: Subsystem: Hewle
Bug#852779: installation-reports: Mostly successful install amd64 stretch RC1
it looks like this is the first time you have used
reportbug, we are configuring its behavior. These settings will be saved to the
file "/home/chris/.reportbugrc", which you will be free to edit further.
Please choose the default operating mode for reportbug.
1 noviceOffer simple prompts, bypassing technical questions.
2 standard Offer more extensive prompts, including asking about things that a
moderately sophisticated user would be expected to know about
Debian.
3 advanced Like standard, but assumes you know a bit more about Debian,
including "incoming".
4 expertBypass most handholding measures and preliminary triage routines.
This mode should not be used by people unfamiliar with Debian's
policies and operating procedures.
Select mode: [novice] 2
Please choose the default interface for reportbug.
1 text A text-oriented console user interface
2 gtk2 A graphical (GTK+) user interface.
Select interface: 2
Will reportbug often have direct Internet access? (You should answer yes to
this question unless you know what you are doing and plan to check whether
duplicate reports have been filed via some other channel.) [Y|n|q|?]? y
What real name should be used for sending bug reports?
[Chris Tillman]>
Which of your email addresses should be used when sending bug reports? (Note
that this address will be visible in the bug tracking system, so you may want
to use a webmail address or another address with good spam filtering
capabilities.)
[chris@ctillman]> toff.till...@gmail.com
Do you have a "mail transport agent" (MTA) like Exim, Postfix or SSMTP
configured on this computer to send mail to the Internet? [y|N|q|?]? n
Please enter the name of your SMTP host. Usually it's called something like
"mail.example.org" or "smtp.example.org". If you need to use a different port
than default, use the : alternative format. Just press ENTER if you
don't have one or don't know, and so a Debian SMTP host will be used.
>
Please enter the name of your proxy server. It should only use this parameter
if you are behind a firewall. The PROXY argument should be formatted as a valid
HTTP URL, including (if necessary) a port number; for example,
http://192.168.1.1:3128/. Just press ENTER if you don't have one or don't know.
>
Default preferences file written. To reconfigure, re-run reportbug with the "--
configure" option.
Traceback (most recent call last):
File "/usr/bin/reportbug", line 2233, in
main()
File "/usr/bin/reportbug", line 1107, in main
return iface.user_interface()
File "/usr/bin/reportbug", line 1225, in user_interface
main()
File "/usr/bin/reportbug", line 1084, in main
if newui.initialize():
File "/usr/lib/python3/dist-packages/reportbug/ui/gtk2_ui.py", line 1580, in
initialize
gi.require_version('Vte', '2.91')
File "/usr/lib/python3/dist-packages/gi/__init__.py", line 118, in
require_version
raise ValueError('Namespace %s not available' % namespace)
ValueError: Namespace Vte not available
chris@ctillman:~$ reportbug
Traceback (most recent call last):
File "/usr/bin/reportbug", line 2233, in
main()
File "/usr/bin/reportbug", line 1084, in main
if newui.initialize():
File "/usr/lib/python3/dist-packages/reportbug/ui/gtk2_ui.py", line 1580, in
initialize
gi.require_version('Vte', '2.91')
File "/usr/lib/python3/dist-packages/gi/__init__.py", line 118, in
require_version
raise ValueError('Namespace %s not available' % namespace)
ValueError: Namespace Vte not available
chris@ctillman:~$
Bug#837708: thunar: Segfault after file rename
Package: thunar Version: 1.6.10-2 Severity: normal Dear Maintainer, I have noticed this happening a few times. I closed a text file and then renamed it using the right-click -> Rename ... dialog. After pressing the OK button, the entire File Manager closed. Looking at /var/log immediately afterwards, I found this message in kern.log, syslog and messages: Sep 14 06:37:41 ctillman kernel: [250415.899337] Thunar[29924]: segfault at 0 ip b69f1558 sp bfda338c error 4 in libc-2.23.so[b68c+1ad000] It also appeared in journalctl -a: Wed 2016-09-14 06:37:41.862160 NZST [s=f9fc5517d9584692831266c41d11c485;i=1b44;b=cf144cf8d9474d88a9b17750c3cbeea2;m=3a4df36630;t=53c67e8662f _TRANSPORT=kernel SYSLOG_FACILITY=0 SYSLOG_IDENTIFIER=kernel _BOOT_ID=cf144cf8d9474d88a9b17750c3cbeea2 _MACHINE_ID=13a2be7338e94abbadf3956290aa31b3 _HOSTNAME=ctillman PRIORITY=6 _SOURCE_MONOTONIC_TIMESTAMP=250415899337 MESSAGE=Thunar[29924]: segfault at 0 ip b69f1558 sp bfda338c error 4 in libc-2.23.so[b68c+1ad000] Needless to say, it's inconvenient to need to open File Manager again and navigate back to where I was. Thanks. -- System Information: Debian Release: stretch/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 4.6.0-1-686-pae (SMP w/2 CPU cores) Locale: LANG=en_NZ.utf8, LC_CTYPE=en_NZ.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages thunar depends on: ii desktop-file-utils 0.23-1 ii exo-utils 0.10.7-1 ii libatk1.0-0 2.20.0-1 ii libc6 2.23-4 ii libcairo2 1.14.6-1+b1 ii libdbus-1-3 1.10.8-1 ii libdbus-glib-1-20.106-1 ii libexo-1-0 0.10.7-1 ii libgdk-pixbuf2.0-0 2.34.0-1 ii libglib2.0-02.48.1-2 ii libgtk2.0-0 2.24.30-4 ii libgudev-1.0-0 230-3 ii libice6 2:1.0.9-1+b1 ii libnotify4 0.7.6-2 ii libpango-1.0-0 1.40.1-1 ii libsm6 2:1.2.2-1+b1 ii libthunarx-2-0 1.6.10-2 ii libxfce4ui-1-0 4.12.1-2 ii libxfce4util7 4.12.1-2 ii libxfconf-0-2 4.12.0-2+b1 ii shared-mime-info1.6-1 ii thunar-data 1.6.10-2 Versions of packages thunar recommends: ii dbus-x11 1.10.8-1 ii gvfs 1.28.2-1 ii libfontconfig1 2.11.0-6.4 ii libfreetype6 2.6.3-3+b1 ii libpangocairo-1.0-0 1.40.1-1 ii libpangoft2-1.0-01.40.1-1 ii thunar-volman0.8.1-2 ii tumbler 0.1.31-2+b3 ii xdg-user-dirs0.15-2 ii xfce4-panel 4.12.0-4 Versions of packages thunar suggests: ii thunar-archive-plugin 0.3.1-4 ii thunar-media-tags-plugin 0.2.1-1+b2 -- no debconf information
Bug#833492: Additional info
Just tagging on to say that I've noticed the scroll bar widget isn't properly placed (stays at the top) when I use Ctrl-End to go to the end of the document. Maybe that's where the messages are coming from. If I resize the window, the scroll bar thumb moves to the bottom. -- Chris Tillman
Bug#831453: meld crashed when invoked from command line after recent upgrade (suspect GTK)
Package: meld Version: 3.16.1-1 Severity: normal Dear Maintainer, Hi, I invoked meld with two small documents. $ meld 6100.1.chk 6100.2.chk The result was No protocol specified Unable to init server: Could not connect: Connection refused No protocol specified Unable to init server: Could not connect: Connection refused (meld:14422): Gtk-CRITICAL **: gtk_icon_theme_get_for_screen: assertion 'GDK_IS_SCREEN (screen)' failed Traceback (most recent call last): File "/usr/bin/meld", line 260, in setup_resources() File "/usr/bin/meld", line 193, in setup_resources Gtk.IconTheme.get_default().append_search_path(icon_dir) AttributeError: 'NoneType' object has no attribute 'append_search_path' I noticed bug 830952, so checked my GTK version; it was 3.20.6-2. Perhaps "too new"? When I opened meld through the menu instead, I was able to use it to view the diff. Let me just say that I think meld provides the most attractive diff result display I have ever seen, it's a joy to use just because of that. -- System Information: Debian Release: stretch/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 4.6.0-1-686-pae (SMP w/2 CPU cores) Locale: LANG=en_NZ.utf8, LC_CTYPE=en_NZ.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages meld depends on: ii dconf-gsettings-backend [gsettings-backend] 0.24.0-2 ii gir1.2-gtksource-3.0 3.20.4-1 ii libcanberra-gtk3-module 0.30-2.1 ii libgtk-3-0 3.20.6-2 ii libgtksourceview-3.0-1 3.20.4-1 ii patch2.7.5-1 ii python-gi3.18.2-2+b1 ii python-gi-cairo 3.18.2-2+b1 pn python:any Versions of packages meld recommends: ii yelp 3.20.1-1 meld suggests no packages. -- no debconf information
Bug#814408: aptitude uses all disk space (12G) with recursive trace-dump in /tmp
Package: aptitude Version: 0.7.5-3 Severity: critical Justification: breaks unrelated software Dear Maintainer, * What led up to the situation? I had upgraded all packages a couple of weeks ago to testing current level. Today I opened aptitude, performed update, and it said there were 123 packages to be updated. I marked the Upgradeable line with +. It said it was Resolving Dependencies, and then became unresponsive. I went on to do something else. After 10 minutes or so I found I could not use readline completion in bash because I had run out of disk space on the root device. Going back to the aptitude window, I saw many out of disk space messages. I hit OK on the messages window, and then canceled my pending actions and quit aptitude. Once back on the command line, I confirmed I was out of space with df -h. root@ctillman:/home/chris# df -h Filesystem Size Used Avail Use% Mounted on /dev/sda519G 17G 865M 96% / Conveniently, I had just done df -h before starting the upgrade, so I scrolled back up and verified I had 12G free beforehand. root@ctillman:/home/chris# df -h Filesystem Size Used Avail Use% Mounted on /dev/sda519G 7.0G 11G 41% / I then used du to drill down to where the space was being used. Here are the final few lines. root@ctillman:/home/chris# du --max-depth=1 -h /tmp/aptitude-root.7985\:PR9HPH/ 9.7G/tmp/aptitude-root.7985:PR9HPH/aptitude-trace-dumpubvton 9.7G/tmp/aptitude-root.7985:PR9HPH/ root@ctillman:/home/chris# du --max-depth=1 -h /tmp/aptitude- root.7985\:PR9HPH/* 9.7G/tmp/aptitude-root.7985:PR9HPH/aptitude-trace-dumpubvton/usr 16K /tmp/aptitude-root.7985:PR9HPH/aptitude-trace-dumpubvton/etc 24K /tmp/aptitude-root.7985:PR9HPH/aptitude-trace-dumpubvton/var 9.7G/tmp/aptitude-root.7985:PR9HPH/aptitude-trace-dumpubvton root@ctillman:/home/chris# du --max-depth=1 -h /tmp/aptitude- root.7985\:PR9HPH/usr du: cannot access ‘/tmp/aptitude-root.7985:PR9HPH/usr’: No such file or directory root@ctillman:/home/chris# du --max-depth=1 -h /tmp/aptitude-root.7985\:PR9HPH /aptitude-trace-dumpubvton/usr 9.7G/tmp/aptitude-root.7985:PR9HPH/aptitude-trace-dumpubvton/usr/bin 9.7G/tmp/aptitude-root.7985:PR9HPH/aptitude-trace-dumpubvton/usr root@ctillman:/home/chris# du --max-depth=1 -h /tmp/aptitude-root.7985\:PR9HPH /aptitude-trace-dumpubvton/usr/bin 9.7G/tmp/aptitude-root.7985:PR9HPH/aptitude-trace-dumpubvton/usr/bin/X11 9.7G/tmp/aptitude-root.7985:PR9HPH/aptitude-trace-dumpubvton/usr/bin root@ctillman:/home/chris# du --max-depth=1 -h /tmp/aptitude-root.7985\:PR9HPH /aptitude-trace-dumpubvton/usr/bin/X11 9.7G/tmp/aptitude-root.7985:PR9HPH/aptitude-trace- dumpubvton/usr/bin/X11/X11 9.7G/tmp/aptitude-root.7985:PR9HPH/aptitude-trace-dumpubvton/usr/bin/X11 root@ctillman:/home/chris# du --max-depth=1 -h /tmp/aptitude-root.7985\:PR9HPH /aptitude-trace-dumpubvton/usr/bin/X11/X11/X11/X11/X11/X11/ 9.7G/tmp/aptitude-root.7985:PR9HPH/aptitude-trace- dumpubvton/usr/bin/X11/X11/X11/X11/X11/X11/X11 9.7G/tmp/aptitude-root.7985:PR9HPH/aptitude-trace- dumpubvton/usr/bin/X11/X11/X11/X11/X11/X11/ As you can see, the X11 directory has been recursively created. * What exactly did you do (or not do) that was effective (or ineffective)? Quit aptitude, that freed up about 1G. Then root@ctillman:/home/chris# rm -rf /tmp/aptitude-root.7985:PR9HPH/aptitude- trace-dumpubvton/usr/bin/X11/X11/X11/X11/X11/X11/ * What was the outcome of this action? root@ctillman:/home/chris# df -h Filesystem Size Used Avail Use% Mounted on /dev/sda519G 6.9G 11G 40% / -- Package-specific info: $TERM not set. $DISPLAY is set. which aptitude: /usr/bin/aptitude aptitude version information: aptitude 0.7.5 Compiler: g++ 5.3.1 20151207 Compiled against: apt version 5.0.0 NCurses version 6.0 libsigc++ version: 2.6.2 Gtk+ support disabled. Qt support disabled. Current library versions: NCurses version: ncurses 6.0.20151024 cwidget version: 0.5.17 Apt version: 5.0.0 aptitude linkage: linux-gate.so.1 (0xb771) libapt-pkg.so.5.0 => /usr/lib/i386-linux-gnu/libapt-pkg.so.5.0 (0xb71b8000) libncursesw.so.5 => /lib/i386-linux-gnu/libncursesw.so.5 (0xb7182000) libtinfo.so.5 => /lib/i386-linux-gnu/libtinfo.so.5 (0xb715d000) libsigc-2.0.so.0 => /usr/lib/i386-linux-gnu/libsigc-2.0.so.0 (0xb7156000) libcwidget.so.3 => /usr/lib/i386-linux-gnu/libcwidget.so.3 (0xb7053000) libsqlite3.so.0 => /usr/lib/i386-linux-gnu/libsqlite3.so.0 (0xb6f71000) libboost_iostreams.so.1.58.0 => /usr/lib/i386-linux-gnu/libboost_iostreams.so.1.58.0 (0xb6f58000) libboost_filesystem.so.1.58.0 => /usr/lib/i386-linux-gnu/libboost_filesystem.so.1.58.0 (0xb6f3c000) libboost_system.so.1.58.0 => /usr/lib/i386-linux-gnu/libboost_system.so.1.58.0 (0xb6f37000) libxapian.so.22 => /usr/lib/i386-linux-gnu/sse2/libxapian.so.22 (0xb6d2d000) libpthread.so.0
Bug#814408: aptitude uses all disk space (12G) with recursive trace-dump in /tmp
Sorry, I guess filling disk is not such a bad thing after all. "Everyone else does it." Disregard my sarcasm, you are of course right that the system is now designed to withstand such poorly behaved applications. I also thought configs were usually attached by reportbug, but in any case here is $ cat /etc/apt/sources.list deb http://ftp.citylink.co.nz/debian/ testing main non-free contrib deb-src http://ftp.citylink.co.nz/debian/ testing main non-free contrib deb http://security.debian.org/ jessie/updates main contrib non-free deb-src http://security.debian.org/ jessie/updates main contrib non-free # jessie-updates, previously known as 'volatile' deb http://ftp.citylink.co.nz/debian/ jessie-updates main contrib non-free deb-src http://ftp.citylink.co.nz/debian/ jessie-updates main contrib non-free $ cat ~/.aptitude/config Aptitude ""; Aptitude::ProblemResolver ""; Aptitude::ProblemResolver::Trace-File "/tmp/aptitude.trace"; Aptitude::ProblemResolver::Remove-Level "10001"; I also attached the tarred remainder of the offending aptitude-trace directory in tmp. (Recall I had truncated the recursive directory at aptitude-trace-dumpubvton/usr/bin/X11/X11/X11/X11/X11 ). After removing the Aptitude::ProblemResolver::Trace-File "/tmp/aptitude.trace"; line, I went back in to aptitude to try the same thing again. Upon starting, it immediately suggested 2 installs, 1 keep, 1 upgrade. Remember I had cancelled the pending actions. This action was not suggested last time I was in. keep: libilmbase6v5 install: libilmbase12, libopenexr22 upgrade: libgeg-0.3-0 I entered ! to accept the suggestion, and verified that these actions are now pending, along with removal of libopenexr6v5 (libilmbase6v5 is also being removed because no longer used). I also have a list of 34 packages being held back, including apt and apt-utils at 1.2.1. And 96 being automatically held, the list of which includes many xserver-xorg packages (and xserver-xorg-legacy at 2:1.173-2). I tried hitting + on the Upgradeable line again, and this time the resolution was swift: Suggest 23 keeps. This was all the xserver-xorg packages again. I accepted. I hit the + sign again, and the same suggestion was offered again. I think that must be where the recursiveness is coming in. Let me know if there's something else I can try in this state. On Fri, Feb 12, 2016 at 12:57 AM, Manuel A. Fernandez Montecelo < manuel.montez...@gmail.com> wrote: > Control: severity -1 minor > > > Hi, > > 2016-02-11 10:00 Chris Tillman: > >> Package: aptitude >> Version: 0.7.5-3 >> Severity: critical >> Justification: breaks unrelated software >> > > This is not a critical bug by any strectch, anymore than wget or any > browser might break unrelated software if you download a partition > without enough space (when other packages depend on empty space in that > partition to work fine). Many packages use /tmp and can cause this > problem under various circumstances, even with much smaller files. > > Simply downloading files in aptitude for an upgrade can fill up > /var/cache/apt/archives, which might mean / and /tmp if it's a single > partition, and aptitude never stopped to be released because of that > behaviour. > > There is a simple workaround for that, I suspect, which is to use the > defaults and not enable options related with trace-dumps. > > It would be useful though if you could mention the exact config or > command line options that you enabled to make this happen. > > > Cheers. > -- > Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com> > -- Chris Tillman Developer aptitude-traces.tgz Description: GNU Zip compressed data
Bug#802178: llvm-toolchain-3.7: Various warnings in llvm-3.7 build
Source: llvm-toolchain-3.7
Severity: minor
Tags: upstream
Dear Maintainer,
* What led up to the situation?
Build using apt-get source -b
* What was the outcome of this action?
Warnings and a few errors.
I grepped the upstream warnings and errors out of the full build log and
attached the result. Mostly unused variables and improper casts, and one test
script recurring error, but possibly a useful list for someone to look at
anyway.
Full build log (10M) is available if desired.
-- System Information:
Debian Release: stretch/sid
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 4.1.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_NZ.utf8, LC_CTYPE=en_NZ.utf8 (charmap=UTF-8)
--
/home/chris/eiffel/projects/Eifflix/src/packages/llvm/pre/llvm-toolchain-3.7-3.7/polly/lib/Analysis/ScopDetection.cpp:
In member function 'bool
polly::ScopDetection::hasAffineMemoryAccesses(polly::ScopDetection::DetectionContext&)
const':
/home/chris/eiffel/projects/Eifflix/src/packages/llvm/pre/llvm-toolchain-3.7-3.7/polly/lib/Analysis/ScopDetection.cpp:490:18:
warning: variable 'TermsHasInRegionInst' set but not used
[-Wunused-but-set-variable]
bool TermsHasInRegionInst = false;
^
--
then /bin/mv -f
"/home/chris/eiffel/projects/Eifflix/src/packages/llvm/pre/llvm-toolchain-3.7-3.7/build-llvm/tools/clang/lib/Tooling/Release/CompilationDatabase.d.tmp"
"/home/chris/eiffel/projects/Eifflix/src/packages/llvm/pre/llvm-toolchain-3.7-3.7/build-llvm/tools/clang/lib/Tooling/Release/CompilationDatabase.d";
else /bin/rm
"/home/chris/eiffel/projects/Eifflix/src/packages/llvm/pre/llvm-toolchain-3.7-3.7/build-llvm/tools/clang/lib/Tooling/Release/CompilationDatabase.d.tmp";
exit 1; fi
/home/chris/eiffel/projects/Eifflix/src/packages/llvm/pre/llvm-toolchain-3.7-3.7/tools/clang/lib/Tooling/CompilationDatabase.cpp:328:12:
warning: 'clang::tooling::JSONAnchorDest' defined but not used
[-Wunused-variable]
static int JSONAnchorDest = JSONAnchorSource;
^
--
then /bin/mv -f
"/home/chris/eiffel/projects/Eifflix/src/packages/llvm/pre/llvm-toolchain-3.7-3.7/build-llvm/tools/clang/tools/extra/clang-modernize/tool/Release/ClangModernize.d.tmp"
"/home/chris/eiffel/projects/Eifflix/src/packages/llvm/pre/llvm-toolchain-3.7-3.7/build-llvm/tools/clang/tools/extra/clang-modernize/tool/Release/ClangModernize.d";
else /bin/rm
"/home/chris/eiffel/projects/Eifflix/src/packages/llvm/pre/llvm-toolchain-3.7-3.7/build-llvm/tools/clang/tools/extra/clang-modernize/tool/Release/ClangModernize.d.tmp";
exit 1; fi
/home/chris/eiffel/projects/Eifflix/src/packages/llvm/pre/llvm-toolchain-3.7-3.7/tools/clang/tools/extra/clang-modernize/tool/ClangModernize.cpp:482:12:
warning: 'TransformsAnchorsDestination' defined but not used
[-Wunused-variable]
static int TransformsAnchorsDestination[] = {
^
--
then /bin/mv -f
"/home/chris/eiffel/projects/Eifflix/src/packages/llvm/pre/llvm-toolchain-3.7-3.7/build-llvm/tools/clang/tools/extra/clang-tidy/tool/Release/ClangTidyMain.d.tmp"
"/home/chris/eiffel/projects/Eifflix/src/packages/llvm/pre/llvm-toolchain-3.7-3.7/build-llvm/tools/clang/tools/extra/clang-tidy/tool/Release/ClangTidyMain.d";
else /bin/rm
"/home/chris/eiffel/projects/Eifflix/src/packages/llvm/pre/llvm-toolchain-3.7-3.7/build-llvm/tools/clang/tools/extra/clang-tidy/tool/Release/ClangTidyMain.d.tmp";
exit 1; fi
/home/chris/eiffel/projects/Eifflix/src/packages/llvm/pre/llvm-toolchain-3.7-3.7/tools/clang/tools/extra/clang-tidy/tool/ClangTidyMain.cpp:339:12:
warning: 'clang::tidy::LLVMModuleAnchorDestination' defined but not used
[-Wunused-variable]
static int LLVMModuleAnchorDestination = LLVMModuleAnchorSource;
^
/home/chris/eiffel/projects/Eifflix/src/packages/llvm/pre/llvm-toolchain-3.7-3.7/tools/clang/tools/extra/clang-tidy/tool/ClangTidyMain.cpp:343:12:
warning: 'clang::tidy::GoogleModuleAnchorDestination' defined but not used
[-Wunused-variable]
static int GoogleModuleAnchorDestination = GoogleModuleAnchorSource;
^
/home/chris/eiffel/projects/Eifflix/src/packages/llvm/pre/llvm-toolchain-3.7-3.7/tools/clang/tools/extra/clang-tidy/tool/ClangTidyMain.cpp:347:12:
warning: 'clang::tidy::MiscModuleAnchorDestination' defined but not used
[-Wunused-variable]
static int MiscModuleAnchorDestination = MiscModuleAnchorSource;
^
/home/chris/eiffel/projects/Eifflix/src/packages/llvm/pre/llvm-toolchain-3.7-3.7/tools/clang/tools/extra/clang-tidy/tool/ClangTidyMain.cpp:351:12:
warning: 'clang::tidy::ReadabilityModuleAnchorDestination' defined but not
used [-Wunused-variable]
static int ReadabilityModuleAnchorDestination = ReadabilityModuleAnchorSource;
^
--
/home/chris/eiffel/projects/Eifflix/src/packages/llvm/pre/llvm-toolchain-3.7-3.7/tools/lldb/source/Commands/CommandObjectMemory.cpp:
In member function 'virtual
Bug#802177: llvm-toolchain-3.7: Useless dependency and unknown substitution variable warnings at end of build
Source: llvm-toolchain-3.7 Severity: normal Dear Maintainer, * What led up to the situation? Build llvm-3.7 using apt-get source -b * What was the outcome of this action? Warnings generated by dpkg-shlibdeps and dpkg-gencontrol End of build log shown. Full build log available on request. -- sed -i 's|LLVM_CMAKE_DIR "/usr/lib/llvm-3.7/share/llvm/cmake"|LLVM_CMAKE_DIR "/usr/share/llvm-3.7/cmake"|' /home/chris/eiffel/projects/Eifflix/src/packages/llvm/pre/llvm-toolchain-3.7-3.7/debian/tmp//usr/lib/llvm-3.7/share/llvm/cmake/LLVMConfig.cmake rm -f /home/chris/eiffel/projects/Eifflix/src/packages/llvm/pre/llvm-toolchain-3.7-3.7/build-llvm/Release/lib/python*/site-packages/lldb/_lldb.so if test yes = yes; then \ mkdir -p /home/chris/eiffel/projects/Eifflix/src/packages/llvm/pre/llvm-toolchain-3.7-3.7/debian/libclang-3.7-dev/usr/lib/llvm-3.7/lib/ /home/chris/eiffel/projects/Eifflix/src/packages/llvm/pre/llvm-toolchain-3.7-3.7/debian/libclang-common-3.7-dev/usr/lib/llvm-3.7/include/polly/; \ mv -f /home/chris/eiffel/projects/Eifflix/src/packages/llvm/pre/llvm-toolchain-3.7-3.7/debian/tmp//usr/lib/llvm-3.7/lib/libpolly* \ /home/chris/eiffel/projects/Eifflix/src/packages/llvm/pre/llvm-toolchain-3.7-3.7/debian/libclang-3.7-dev/usr/lib/llvm-3.7/lib/; \ rm -rf /home/chris/eiffel/projects/Eifflix/src/packages/llvm/pre/llvm-toolchain-3.7-3.7/debian/libclang-common-3.7-dev/usr/lib/llvm-3.7/include/polly; \ mv -f /home/chris/eiffel/projects/Eifflix/src/packages/llvm/pre/llvm-toolchain-3.7-3.7/debian/tmp//usr/lib/llvm-3.7/include/polly/ \ /home/chris/eiffel/projects/Eifflix/src/packages/llvm/pre/llvm-toolchain-3.7-3.7/debian/libclang-common-3.7-dev/usr/lib/llvm-3.7/include/; \ fi mv: cannot stat '/home/chris/eiffel/projects/Eifflix/src/packages/llvm/pre/llvm-toolchain-3.7-3.7/debian/tmp//usr/lib/llvm-3.7/lib/libpolly*': No such file or directory make[1]: Leaving directory '/home/chris/eiffel/projects/Eifflix/src/packages/llvm/pre/llvm-toolchain-3.7-3.7' debian/rules override_dh_install make[1]: Entering directory '/home/chris/eiffel/projects/Eifflix/src/packages/llvm/pre/llvm-toolchain-3.7-3.7' dh_install --fail-missing make[1]: Leaving directory '/home/chris/eiffel/projects/Eifflix/src/packages/llvm/pre/llvm-toolchain-3.7-3.7' dh_ocamldoc dh_installdocs dh_installchangelogs dh_installexamples debian/rules override_dh_installman make[1]: Entering directory '/home/chris/eiffel/projects/Eifflix/src/packages/llvm/pre/llvm-toolchain-3.7-3.7' dh_installman rm -f /home/chris/eiffel/projects/Eifflix/src/packages/llvm/pre/llvm-toolchain-3.7-3.7/debian/llvm-3.7/usr/share/man/man1/lli* make[1]: Leaving directory '/home/chris/eiffel/projects/Eifflix/src/packages/llvm/pre/llvm-toolchain-3.7-3.7' dh_lintian dh_perl dh_link dh_link: skipping link from usr/lib/i386-linux-gnu/liblldb-3.7.so.1 to self dh_strip_nondeterminism dh_compress dh_fixperms debian/rules override_dh_strip make[1]: Entering directory '/home/chris/eiffel/projects/Eifflix/src/packages/llvm/pre/llvm-toolchain-3.7-3.7' dh_strip -p libclang1-3.7 --dbg-package=libclang1-3.7-dbg dh_strip -p libllvm3.7 --dbg-package=libllvm3.7-dbg dh_strip -p liblldb-3.7 --dbg-package=liblldb-3.7-dbg dh_strip -a make[1]: Leaving directory '/home/chris/eiffel/projects/Eifflix/src/packages/llvm/pre/llvm-toolchain-3.7-3.7' dh_makeshlibs debian/rules override_dh_shlibdeps make[1]: Entering directory '/home/chris/eiffel/projects/Eifflix/src/packages/llvm/pre/llvm-toolchain-3.7-3.7' LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/chris/eiffel/projects/Eifflix/src/packages/llvm/pre/llvm-toolchain-3.7-3.7/debian/tmp//usr/lib/llvm-3.7/lib/ dh_shlibdeps dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/clang-3.7/usr/lib/llvm-3.7/bin/clang-tblgen debian/clang-3.7/usr/lib/llvm-3.7/bin/clang-tidy debian/clang-3.7/usr/lib/llvm-3.7/bin/c-index-test debian/clang-3.7/usr/lib/llvm-3.7/bin/clang debian/clang-3.7/usr/lib/llvm-3.7/bin/clang-query debian/clang-3.7/usr/lib/llvm-3.7/bin/clang-check debian/clang-3.7/usr/lib/llvm-3.7/bin/clang-rename debian/clang-3.7/usr/lib/llvm-3.7/bin/pp-trace debian/clang-3.7/usr/lib/llvm-3.7/bin/clang-apply-replacements were not linked against libz.so.1 (they use none of the library's symbols) dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/clang-3.7/usr/lib/llvm-3.7/bin/clang-tblgen debian/clang-3.7/usr/lib/llvm-3.7/bin/clang-tidy debian/clang-3.7/usr/lib/llvm-3.7/bin/c-index-test debian/clang-3.7/usr/lib/llvm-3.7/bin/clang debian/clang-3.7/usr/lib/llvm-3.7/bin/clang-query debian/clang-3.7/usr/lib/llvm-3.7/bin/clang-check debian/clang-3.7/usr/lib/llvm-3.7/bin/clang-rename debian/clang-3.7/usr/lib/llvm-3.7/bin/pp-trace debian/clang-3.7/usr/lib/llvm-3.7/bin/clang-apply-replacements were not linked against libffi.so.6 (they use none of the library's symbols)
Bug#782569: lxde: Applications start on laptop when primary monitor is external
Package: lxde Version: 6 Severity: normal Dear Maintainer, I installed a new system from jessie-rc2 last week. I chose LXDE desktop (new to me) when installing. I configured using LXRandR Monitor Settings to have my external monitor above the laptop LCD monitor. Then I'm pretty sure I used the Panel Preferences applet to change the Position of the Task bar from Monitor 2 to Monitor 1 (Monitor 1 is the one in the top position, my external monitor. What happens is, when I initiate almost any application, from a menu or from a desktop icon, the new window opens on the secondary monitor (laptop LCD). It's quite disconcerting, because the menu bar is on the other monitor and I have the laptop lid partly closed so I can see over the top. So it takes me a couple of retries before I figure out the window is opening on the laptop. There are two exceptions I have noticed, where the window opens on the correct monitor: Desktop Preferences and LXSession configuration. My windows manager is listed as openbox, and this bug may belong there. In fact while I was writing this bug I found a menu item under Preferences called Openbox Configuration Manager, and within the Windows tab an item where I could change the Primary Monitor from Fixed Monitor to Active Monitor ... no that didn't fix it .. to Monitor with Mouse Pointer, which resulted in the correct behaviour. BTW, Desktop Settings and LXSession configuration still open correctly after setting the Openbox windows preference. I'm going to file this bug even though I found a solution, because 1) I think the default behaviour is wrong, and 2) so that other people who run across it may find the bug and earn how to solve the issue. -- System Information: Debian Release: 8.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages lxde depends on: ii galculator 2.1.3-1 ii gpicview0.2.4-2+b2 ii leafpad 0.8.18.1-4 ii lxappearance0.6.1-1 ii lxappearance-obconf 0.2.2-1 ii lxde-core 6 ii lxde-icon-theme 0.5.1-1 ii lxinput 0.3.4-1 ii lxrandr 0.3.0-1 ii lxsession [lxsession-edit] 0.5.1-2 ii lxterminal 0.2.0-1 ii xarchiver 1:0.5.4-1 Versions of packages lxde recommends: ii alsamixergui 0.9.0rc2-1-9.1 ii clipit 1.4.2-1 ii deluge 1.3.10-3 ii evince-gtk [pdf-viewer] 3.14.1-2 ii gnome-disk-utility 3.12.1-1+b1 ii gnome-mplayer1.0.9-3 ii gnome-system-tools 3.0.0-4 ii gucharmap1:3.14.1-1 ii iceweasel [www-browser] 31.6.0esr-1 ii lightdm [x-display-manager] 1.10.3-3 ii lxmusic 0.4.6-2 ii lxsession [lxpolkit] 0.5.1-2 ii menu-xdg 0.5 ii network-manager-gnome0.9.10.0-2 ii usermode 1.109-1 ii w3m [www-browser]0.5.3-19 ii xserver-xorg 1:7.7+7 Versions of packages lxde suggests: ii gimp 2.8.14-1+b1 ii libreoffice 1:4.3.3-2 ii lxlauncher 0.2.4-1 ii lxtask 0.1.6-1 pn pidgin none pn update-notifier none pn xfce4-power-manager 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#782498: network-manager: GLib-GObject-CRITICAL **: object NMIfupdownConnection Seen in log (reported fixed in #743166)
Package: network-manager Version: 0.9.10.0-6 Severity: serious Justification: Reporting as serious because the other bug reporting the error was serious and the message says CRITICAL (See attachment generated by reportbug) reportbug-network-manager-20150413-1976-xJuccQ Description: Binary data
Bug#760142: systemd: Assertions from systemd-logind on powerpc during login, with continuing loop
On Sat, Nov 22, 2014 at 11:20 PM, Simon McVittie s...@debian.org wrote: On Wed, 19 Nov 2014 at 21:29:33 +0100, Andreas Messer wrote: I'm observing the same behavior on an x86_64 wheezy system running my HTPC setup after updating the system some weeks ago. Andreas, I think your bug is #769069, which is a recent regression: your system is presumably much less slow than Chris's. ... Chris, with hindsight, your symptoms look a lot like #769069; but they can't be a regression in that version of dbus, because your bug report is older than the change that has caused the regression for others. It would be great if you could install the test package described in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769069#85 which will log a message containing Connection has not authenticated soon enough when authentication takes too long - I suspect that's the failure case that you're reaching. Unfortunately, I've sold my G4 on, so I can't retest. Sounds reasonable though. -- Chris Tillman Developer
Bug#762316: To avoid installer lock-up, iso-scan should always ask if more than one iso image is found
Package: iso-scan Version: 1.53 Severity: important Tags: d-i Dear Debian Install System Team, I found a bug using iso-scan in the installer image downloaded from http://ftp.citylink.co.nz/debian/dists/testing/main/installer-amd64/current/images/hd-media/initrd.gz dated 2 Aug 2014. The bug is only triggered under the following conditions: 1) debconf priority = high or greater 2) More than one iso image in the folder where iso-scan detects an iso. I marked it important, though, because of the consequences. In my case, I started to see this error in console 2 when trying to ls: ls: /lib/libc.so.6: version 'GLIBC_2.15' not found (required by ls) As you can imagine, this meant I couldn't do ANYTHING after this, other than hold the power button down on the computer for 5 seconds. Every menu item fails, including the Abort menu item. The problem was that I had two iso-scan images on the root of the partition. The first one alphabetically was a CD for wheezy, while the second was the one I wanted ... for jessie. What iso-scan did, under high debconf priority, was just use the first iso, even though it was inappropriate for the jessie installer. I got a warning about no modules, and after that was when the GLIBC error started coming up. It didn't matter what response I selected to the modules error; it was already too late. If instead debconf is set to medium or low, iso-scan asks which iso you want to use. This should be the behaviour, no matter what the debconf level, if more than one iso image is found. Otherwise we go from asking for a scan to complete failure, just for having two isos in the folder. Chris
Bug#758932: kernel crash on usb disk removal
Here are the log statements from kern.log on that occasionn. Is there anything else I can supply? Aug 23 10:01:37 121-73-239-129 kernel: [143836.389518] usb 2-6: USB disconnect, device number 3 Aug 23 10:01:37 121-73-239-129 kernel: [143836.591902] FAT-fs (sdb9): unable to read boot sector to mark fs as dirty Aug 23 10:01:37 121-73-239-129 kernel: [143836.764466] Buffer I/O error on device sdb10, logical block 2 Aug 23 10:01:37 121-73-239-129 kernel: [143836.764474] lost page write due to I/O error on sdb10 Chris On Fri, Sep 19, 2014 at 4:57 AM, Riku Voipio riku.voi...@iki.fi wrote: severity 758932 normal reassign 758932 linux-image-3.14-2-686-pae thanks Hi Chris, A kernel crash is usually not the fault of userspace applications - it's a kernel bug. For kernel bugs, full kernel logs are needed for debugging. Riku -- Chris Tillman Developer
Bug#762127: Acknowledgement ()
Sorry, forgot a subject. How about: Stack trace from iwl4965 in boot messages On Fri, Sep 19, 2014 at 7:15 AM, Debian Bug Tracking System ow...@bugs.debian.org wrote: Thank you for filing a new Bug report with Debian. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Debian Kernel Team debian-ker...@lists.debian.org If you wish to submit further information on this problem, please send it to 762...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- 762127: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762127 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- Chris Tillman Developer
Bug#761468: libc6-dev: On new jessie install, FTBFS for libantlr3c-3.2 due to misplaced sys/cdefs.h
Package: libc6-dev Version: 2.19-10 Severity: important Dear Maintainer, * What led up to the situation? On a new jessie install (amd64 installed 11 Sept 2014), I used apt-get source libantlr3c, cd to antlr3c-3.2, ./configure, and make. * What was the outcome of this action? xx@debian:~/antlr/libantlr3c-3.2$ make make all-am make[1]: Entering directory '/home/xx/antlr/libantlr3c-3.2' if /bin/bash ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I. -Iinclude-m32 -O2 -Wall -MT antlr3baserecognizer.lo -MD -MP -MF .deps/antlr3baserecognizer.Tpo -c -o antlr3baserecognizer.lo `test -f 'src/antlr3baserecognizer.c' || echo './'`src/antlr3baserecognizer.c; \ then mv -f .deps/antlr3baserecognizer.Tpo .deps/antlr3baserecognizer.Plo; else rm -f .deps/antlr3baserecognizer.Tpo; exit 1; fi mkdir .libs gcc -DHAVE_CONFIG_H -I. -I. -I. -Iinclude -m32 -O2 -Wall -MT antlr3baserecognizer.lo -MD -MP -MF .deps/antlr3baserecognizer.Tpo -c src/antlr3baserecognizer.c -fPIC -DPIC -o .libs/antlr3baserecognizer.o In file included from /usr/include/stdio.h:27:0, from include/antlr3defs.h:219, from include/antlr3baserecognizer.h:39, from src/antlr3baserecognizer.c:9: /usr/include/features.h:374:25: fatal error: sys/cdefs.h: No such file or directory # include sys/cdefs.h ^ compilation terminated. Makefile:424: recipe for target 'antlr3baserecognizer.lo' failed make[1]: *** [antlr3baserecognizer.lo] Error 1 make[1]: Leaving directory '/home/xx/antlr/libantlr3c-3.2' Makefile:286: recipe for target 'all' failed make: *** [all] Error 2 * What outcome did you expect instead? Build from source Upon investigation, I saw that /usr/include/features.h references sys/cdefs.h, and there is no sys folder in /usr/include. Instead cdefs.h is found in x86_64-linux-gnu/sys. This would be a problem for all these other /usr/include files as well: xx@debian:/usr/include$ grep sys/ * 2 /dev/null aio.h:#include sys/types.h aliases.h:#include sys/types.h ar.h:#include sys/cdefs.h features.h:# include sys/cdefs.h fts.h:#include sys/types.h ftw.h:#include sys/types.h ftw.h:#include sys/stat.h glob.h:#include sys/cdefs.h ifaddrs.h:#include sys/socket.h libio.h:# include sys/cdefs.h link.h:#include sys/types.h mqueue.h:#include sys/types.h pngconf.h:# include sys/types.h poll.h:#include sys/poll.h pty.h:#include sys/ioctl.h regex.h:#include sys/types.h resolv.h:#include sys/types.h resolv.h:# include sys/param.h resolv.h:# include sys/cdefs.h semaphore.h:#include sys/types.h sgtty.h:#include sys/ioctl.h signal.h:# include sys/ucontext.h spawn.h:#include sys/types.h stdlib.h:# include sys/types.h/* we need int32_t... */ syscall.h:#include sys/syscall.h syslog.h:#include sys/syslog.h termcap.h:#include sys/types.h term.h:#include sys/ioctl.h termio.h:#include sys/ioctl.h termios.h:# include sys/ttydefaults.h thread_db.h:#include sys/types.h thread_db.h:#include sys/procfs.h ucontext.h:#include sys/ucontext.h ustat.h:#include sys/ustat.h utmp.h:#include sys/types.h utmpx.h:#include sys/time.h wait.h:#include sys/wait.h I'm no C expert, so maybe I'm missing something obvious. But it sounds a bit like bug #685519, and maybe #637232. Is it possible it's something that would affect a new install more severely, as the old headers might not be removed during an upgrade? I tried root@debian:/usr/include# ln -s x86_64-linux-gnu/sys sys ... but that led to the next error In file included from /usr/include/features.h:374:0, from /usr/include/stdio.h:27, from include/antlr3defs.h:219, from include/antlr3baserecognizer.h:39, from src/antlr3baserecognizer.c:9: /usr/include/sys/cdefs.h:385:27: fatal error: bits/wordsize.h: No such file or directory #include bits/wordsize.h ^ compilation terminated. Likewise I did root@debian:/usr/include# ln -s x86_64-linux-gnu/bits bits Next was In file included from /usr/include/stdio.h:27:0, from include/antlr3defs.h:219, from include/antlr3baserecognizer.h:39, from src/antlr3baserecognizer.c:9: /usr/include/features.h:398:23: fatal error: gnu/stubs.h: No such file or directory #include gnu/stubs.h root@debian:/usr/include# ln -s x86_64-linux-gnu/gnu gnu This is obviously not the right approach. It's now looking for stubs-32.h which doesn't exist: In file included from /usr/include/features.h:398:0, from /usr/include/stdio.h:27, from include/antlr3defs.h:219, from include/antlr3baserecognizer.h:39, from src/antlr3baserecognizer.c:9: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory # include gnu/stubs-32.h xx@debian:~/antlr/libantlr3c-3.2$ ls /usr/include/x86_64-linux-gnu/gnu libc-version.h lib-names.h stubs-64.h stubs.h -- System
Bug#760712: WEP vs WPA2
With this installation I was using WPA2-Personal at the access point. I see the log messages look similar as in bug #741622, deauthenticating immediately after connect. For a later install on the same computer, also to USB target, I used WEP in the installer to connect to the access point (installation report #761148). So possibly the problem has to do with WPA2 as opposed to WEP. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760712: Further info
Here is the picture of the Win 8 WLAN properties which I claimed to have attached originally. -- Chris Tillman Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760712: Further info
On Sun, Sep 7, 2014 at 3:33 PM, Chris Tillman toff.till...@gmail.com wrote: Here is the picture of the Win 8 WLAN properties which I claimed to have attached originally. -- Chris Tillman Developer -- Chris Tillman Developer wlan0-in-windows-conf.pdf Description: Adobe PDF document
Bug#760246: Resurrection 633782
I just realized that problem would actually be in the initrd, which I obtained from http://ftp.citylink.co.nz/debian/dists/testing/main/installer-amd64/current/images/hd-media/initrd.gz rather than in the cdrom. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760142: systemd: Assertions from systemd-logind on powerpc during login, with continuing loop
Yes, it is installed on a USB hard disk. I mentioned it in the first bug report I filed, but that one was rejected because I was inadvertantly booting with the wrong kernel, and I forgot to mention it in the second version. And yes, I think the timing issue could be getting exacerbated because of the slowness of USB. I'm pretty sure the PPC G4 has USB1.1, and I think maybe the little USB hard disk interface box I'm using does too. They are both like 2003 vintage. The speed doesn't matter much to me, as I'm only using the machine to do testing for Debian, not to actually do work on. I installed Wheezy on the actual hard disk for the machine, and I didn't want to disturb that ... hence why I installed on the USB disk instead. If testing _did_ work, I would put together a new release of my Debian-imac collection on Sourceforge with it, and update the actual hard disk. My first forays a few months back with jessie on this machine were complete flops, so I can see the progress that's been made in that time. Chris On Tue, Sep 2, 2014 at 8:12 PM, Simon McVittie s...@debian.org wrote: Chris, your Debian root filesystem appears to be on a USB-attached disk (device ID 067b:2507, which according to https://bbs.archlinux.org/viewtopic.php?id=58737 seems to be a Prolific Technology, Inc. PL2507 Hi-speed USB to IDE bridge controller). Please confirm whether this is the case? (Relevant logs below.) This is something that *should* work, but it's an unusual enough configuration that it would have been helpful to mention it, and if (as I suspect) there are timeout issues here, USB is probably going to hurt performance enough to matter - it looks as though you're not just on a system with a slow CPU, you're also on a system with a slow connection to its disk. Further, it looks as though your USB disk is connected at full speed rather than at high speed. That sounds as though it ought to be a good thing, but it isn't: confusingly, the USB Implementers Forum defines full speed to be the full speed of USB 1 (12 Mbit/s), whereas high speed is the enhanced signalling rate from USB 2 (480 Mbit/s). A disk on a 12 Mbit/s bus is never going to be very fast. If this machine has USB 2, check that you are not using a USB 1 hub to connect the disk. If it does not, consider adding USB 2 via a PCI or Cardbus expansion card, or using an internal disk or Firewire instead. Thanks, S Aug 31 09:07:57 debian kernel: usb 1-1: new full-speed USB device number 2 using ohci-pci Aug 31 09:07:57 debian kernel: usb 1-1: New USB device found, idVendor=067b, idProduct=2507 Aug 31 09:07:57 debian kernel: usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Aug 31 09:07:57 debian kernel: usb 1-1: Product: Mass Storage Device Aug 31 09:07:57 debian kernel: usb 1-1: Manufacturer: Prolific Technology Inc. Aug 31 09:07:57 debian kernel: usb 1-1: SerialNumber: 00 Aug 31 09:07:57 debian kernel: usb-storage 1-1:1.0: USB Mass Storage device detected Aug 31 09:07:57 debian kernel: usb-storage 1-1:1.0: Quirks match for vid 067b pid 2507: 10 Aug 31 09:07:57 debian kernel: scsi3 : usb-storage 1-1:1.0 ... Aug 31 09:07:57 debian kernel: scsi 3:0:0:0: Direct-Access IC25N060 ATMR04-0 MO3O PQ: 0 ANSI: 0 ... Aug 31 09:07:57 debian kernel: sd 3:0:0:0: [sdb] 117210239 512-byte logical blocks: (60.0 GB/55.8 GiB) ... Aug 31 09:07:57 debian kernel: sdb: [mac] sdb1 sdb2 sdb3 sdb4 sdb5 sdb6 sdb7 sdb8 sdb9 sdb10 sdb11 sdb12 sdb13 sdb14 ... Aug 31 09:08:08 debian systemd[1]: Starting Remount Root and Kernel File Systems... Aug 31 09:08:08 debian systemd[1]: Starting Sound Card. Aug 31 09:08:08 debian systemd[1]: Reached target Sound Card. Aug 31 09:08:08 debian kernel: EXT4-fs (sdb12): re-mounted. Opts: errors=remount-ro Aug 31 09:08:09 debian systemd[1]: Started Remount Root and Kernel File Systems. -- Chris Tillman Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760142: systemd: Assertions from systemd-logind on powerpc during login, with continuing loop
Package: systemd Version: 208.8 (note: for some reason reportbug originally inserted the package and version into the subject ...) Dear Maintainer, * What led up to the situation? I installed from a testing CD downloaded in early August. I ran into login problems, but discovered I had booted with a Wheezy kernel originally. After reconfiguring to boot with a correct kernel, and configuring a successful xorg.conf, the problems remained. * What exactly did you do (or not do) that was effective (or ineffective)? I updated the system (all packages) using aptitude to the very latest testing version as of Aug 30. I then shut down the system and booted fresh on Aug 31. That is the log I have attached. * What was the outcome of this action? The lightdm greeter comes up, and I can type in the user name and password, but then the greeter restarts. The greeeter came up again, and this time I just waited. The greeter restarted again. Finally after the greeter came up, I changed to Xfce and entered user name and password. But the greeter still just restarted. In the journal log of the session (attached), I saw assertions from both lightdm and systemd-logind. The first assertion in the log was from systemd-logind, so I filed the bug on systemd. However there were also failures of both packages previous to the first assertion. Here is a grep of only the assertions from the log. Aug 31 09:11:24 debian systemd-logind[908]: Assertion 's-user-slice' failed at ../src/login/logind-session.c:531, function session_start_scope(). Aborting. Aug 31 09:12:48 debian systemd-logind[943]: Assertion 's-user-slice' failed at ../src/login/logind-session.c:531, function session_start_scope(). Aborting. Aug 31 09:14:03 debian systemd-logind[981]: Assertion 's-user-slice' failed at ../src/login/logind-session.c:531, function session_start_scope(). Aborting. Aug 31 09:15:55 debian lightdm[1298]: (lightdm:1298): GLib-GIO-CRITICAL **: g_dbus_connection_call_sync_internal: assertion 'object_path != NULL g_variant_is_object_path (object_path)' failed Aug 31 09:16:47 debian systemd-logind[1318]: Assertion 's-user-slice' failed at ../src/login/logind-session.c:531, function session_start_scope(). Aborting. I also note many timeout log entries. This is a rather slow machine (PowerPC G4) compared to typical modern ones, so the timeouts might be set too short? In addition, when filing this bug report as it said it was gathering additional data, before the question about fstab, this message appeared (I am filing from the console): Activation of org.freedesktop.systemd1 timed out This is reflected by the following log statement. So I suspect the same bug prevented getting additional info. I am happy to provide additional info if needed. Aug 31 09:47:54 debian dbus[775]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out * What outcome did you expect instead? Initiation of graphical environment. -- Package-specific info: -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Kernel: Linux 3.14-2-powerpc Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages systemd depends on: ii acl 2.2.52-1 ii adduser 3.113+nmu3 ii initscripts 2.88dsf-53.4 ii libacl1 2.2.52-1 ii libaudit11:2.3.7-1 ii libblkid12.20.1-5.8 ii libc62.19-9 ii libcap2 1:2.24-4 ii libcap2-bin 1:2.24-4 ii libcryptsetup4 2:1.6.6-1 ii libdbus-1-3 1.8.6-2 ii libgcrypt11 1.5.4-2 ii libkmod2 18-1 ii liblzma5 5.1.1alpha+20120614-2 ii libpam0g 1.1.8-3.1 ii libselinux1 2.3-1 ii libsystemd-daemon0 208-8 ii libsystemd-journal0 208-8 ii libsystemd-login0208-8 ii libudev1 208-8 ii libwrap0 7.6.q-25 ii sysv-rc 2.88dsf-53.4 ii udev 208-8 ii util-linux 2.20.1-5.8 Versions of packages systemd recommends: ii libpam-systemd 208-8 Versions of packages systemd suggests: pn systemd-ui 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#760142: Fwd: systemd: Assertions from systemd-logind on powerpc during login, with continuing loop Package: systemd Version:
Forwarding original attachments to the bug [EXTENDED] /lib/systemd/system/cups.socket - /etc/systemd/system/cups.socket.d/cupsd-listen.conf 1 overridden configuration files found. == /var/lib/systemd/deb-systemd-helper-enabled/pppd-dns.service.dsh-also == /etc/systemd/system/multi-user.target.wants/pppd-dns.service == /var/lib/systemd/deb-systemd-helper-enabled/avahi-daemon.service.dsh-also == /etc/systemd/system/multi-user.target.wants/avahi-daemon.service /etc/systemd/system/sockets.target.wants/avahi-daemon.socket /etc/systemd/system/dbus-org.freedesktop.Avahi.service == /var/lib/systemd/deb-systemd-helper-enabled/dbus-org.freedesktop.NetworkManager.service == == /var/lib/systemd/deb-systemd-helper-enabled/NetworkManager-wait-online.service.dsh-also == /etc/systemd/system/multi-user.target.wants/NetworkManager-wait-online.service == /var/lib/systemd/deb-systemd-helper-enabled/atd.service.dsh-also == /etc/systemd/system/multi-user.target.wants/atd.service == /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/anacron.service == == /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/cron.service == == /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/lm-sensors.service == == /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/NetworkManager.service == == /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/cups-browsed.service == == /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/avahi-daemon.service == == /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/atd.service == == /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/pppd-dns.service == == /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/rsyslog.service == == /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/ModemManager.service == == /var/lib/systemd/deb-systemd-helper-enabled/NetworkManager-dispatcher.service.dsh-also == /etc/systemd/system/dbus-org.freedesktop.nm-dispatcher.service == /var/lib/systemd/deb-systemd-helper-enabled/anacron.service.dsh-also == /etc/systemd/system/multi-user.target.wants/anacron.service == /var/lib/systemd/deb-systemd-helper-enabled/dbus-org.freedesktop.Avahi.service == == /var/lib/systemd/deb-systemd-helper-enabled/sockets.target.wants/avahi-daemon.socket == == /var/lib/systemd/deb-systemd-helper-enabled/sockets.target.wants/cups.socket == == /var/lib/systemd/deb-systemd-helper-enabled/dbus-org.freedesktop.ModemManager1.service == == /var/lib/systemd/deb-systemd-helper-enabled/cups.path.dsh-also == /etc/systemd/system/paths.target.wants/cups.path == /var/lib/systemd/deb-systemd-helper-enabled/syslog.service == == /var/lib/systemd/deb-systemd-helper-enabled/NetworkManager.service.dsh-also == /etc/systemd/system/multi-user.target.wants/NetworkManager.service /etc/systemd/system/dbus-org.freedesktop.NetworkManager.service /etc/systemd/system/dbus-org.freedesktop.nm-dispatcher.service == /var/lib/systemd/deb-systemd-helper-enabled/avahi-daemon.socket.dsh-also == /etc/systemd/system/sockets.target.wants/avahi-daemon.socket == /var/lib/systemd/deb-systemd-helper-enabled/cups-browsed.service.dsh-also == /etc/systemd/system/multi-user.target.wants/cups-browsed.service == /var/lib/systemd/deb-systemd-helper-enabled/cups.service.dsh-also == /etc/systemd/system/sockets.target.wants/cups.socket /etc/systemd/system/paths.target.wants/cups.path /etc/systemd/system/printer.target.wants/cups.service == /var/lib/systemd/deb-systemd-helper-enabled/cups.socket.dsh-also == /etc/systemd/system/sockets.target.wants/cups.socket == /var/lib/systemd/deb-systemd-helper-enabled/dbus-org.freedesktop.nm-dispatcher.service == == /var/lib/systemd/deb-systemd-helper-enabled/lm-sensors.service.dsh-also == /etc/systemd/system/multi-user.target.wants/lm-sensors.service == /var/lib/systemd/deb-systemd-helper-enabled/rsyslog.service.dsh-also == /etc/systemd/system/multi-user.target.wants/rsyslog.service /etc/systemd/system/syslog.service == /var/lib/systemd/deb-systemd-helper-enabled/printer.target.wants/cups.service == == /var/lib/systemd/deb-systemd-helper-enabled/cron.service.dsh-also == /etc/systemd/system/multi-user.target.wants/cron.service == /var/lib/systemd/deb-systemd-helper-enabled/ModemManager.service.dsh-also == /etc/systemd/system/multi-user.target.wants/ModemManager.service /etc/systemd/system/dbus-org.freedesktop.ModemManager1.service == /var/lib/systemd/deb-systemd-helper-enabled/paths.target.wants/cups.path == # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # file system mount point type options dump pass # / was on /dev/sdb12 during installation
Bug#760142: systemd: Assertions from systemd-logind on powerpc during login, with continuing loop
On 9/1/14, Michael Biebl bi...@debian.org wrote: Am 01.09.2014 11:04, schrieb Chris Tillman: Activation of org.freedesktop.systemd1 timed out There are quite a few more D-Bus services besides org.freedesktop.systemd1 which time out. It seems also that all services which use Type=dbus in their .service file enter the failed state. So this seems to be a D-Bus related issue. What's the output of systemctl status dbus.service dbus.socket after the boot? Is this problem reproducible after a reboot? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? Yes, it's the same on every boot. I issue systemctl stop lightdm.service to stop it cycling back to VT7. And it needs systemct stop systemd.login.d to stop the cycling altogether. Here is the systemctl status: dbus.service - D-Bus System Message Bus Loaded: loaded (/lib/systemd/system/dbus.service; static) Active: active (running) since Tue 2014-09-02 09:42:06 NZST; 8min ago Docs: man:dbus-daemon(1) Main PID: 767 (dbus-daemon) CGroup: /system.slice/dbus.service └─767 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation Sep 02 09:44:00 debian dbus[767]: [system] Failed to activate service 'org.freedesktop.Avahi': timed out Sep 02 09:44:01 debian dbus[767]: [system] Failed to activate service 'org.freedesktop.PolicyKit1': timed out Sep 02 09:44:25 debian dbus[767]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out Sep 02 09:44:50 debian dbus[767]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out Sep 02 09:45:15 debian dbus[767]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out Sep 02 09:45:40 debian dbus[767]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out Sep 02 09:46:05 debian dbus[767]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out Sep 02 09:46:30 debian dbus[767]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out Sep 02 09:48:00 debian dbus[767]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out Sep 02 09:49:30 debian dbus[767]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out dbus.socket - D-Bus System Message Bus Socket Loaded: loaded (/lib/systemd/system/dbus.socket; static) Active: active (running) since Tue 2014-09-02 09:42:05 NZST; 8min ago Listen: /var/run/dbus/system_bus_socket (Stream) Sep 02 09:42:05 debian systemd[1]: Starting D-Bus System Message Bus Socket. Sep 02 09:42:05 debian systemd[1]: Listening on D-Bus System Message Bus Socket. -- Chris Tillman Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760246: Resurrection 633782
Package: acl Version: 2.2.52-1 Tags: d-i Bug https://bugs.debian.org/633782 has resurfaced in the hd-media download for Jessie on amd64 http://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-netinst.iso Same exact description as in the original bug, debootstrap is trying to bzcat: /var/cache/apt/archives/acl_2.2.52-1_amd64.deb -- Chris Tillman Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760014: win32-loader This program doesn't support dialog box hidden by browser window
Package: win32-loader Version: 0.7.5 I downloaded the daily-build jessie iso today for amd64. I double clicked on the downloaded file and Windows 8 opened it as disk F:. I tried double clicking setup.exe on F: from within Windows 8. The Choose Language dialog box appeared, and I clicked OK. The computer beeped, a Debian-installer loader message alert box was displayed, and the file:///F:/README.html page was displayed in the browser. The issue I have is that the web page is displayed _last_. The dialog box displaying the problem was hidden behind the browser window. I didn't notice the dialog box until I went to shut down the computer, after having been confused by the nice README information but assuming there must have been some problem anyway. Is there any way to reliably make the dialog box appear _after_ the browser window comes up? That would make more sense in this instance. -- Chris Tillman Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758934: Further info
The segfault results when I set the NoAccel option under Device. to False. It does not occur if I set it to True or don't set it. So I guess that must mean it's in acceleration code. -- Chris Tillman Developer
Bug#758934: Further info
Correction: It's when I set NoAccel to True, not False that the segfault occurs. On Sat, Aug 30, 2014 at 10:03 AM, Chris Tillman toff.till...@gmail.com wrote: The segfault results when I set the NoAccel option under Device. to False. It does not occur if I set it to True or don't set it. So I guess that must mean it's in acceleration code. -- Chris Tillman Developer -- Chris Tillman Developer
Bug#753131: Same result
I tried avian on a PowerPC G4 and got the same result as Rogerio. -- Chris Tillman Developer
Bug#735428: Still active in 3.10-3
On Thu, 24 Apr 2014 14:40:21 -0500 Dale Schroeder d...@briannassaladdressing.com wrote: This driver bug is still active in linux-image-3.13-1-amd64 (3.13.10-1) running on an Intel DQ35JO board. This bug is still active in 3.10-3-686-pae on Intel. The messages spam the consoles, making them all unusable. 121-73-239-129:/home/ctillman# cat /proc/cpuinfo processor: 0 vendor_id: GenuineIntel cpu family: 6 model: 15 model name: Intel(R) Core(TM)2 Duo CPU U7600 @ 1.20GHz Am upgrading now to see if the latest kernel will solve this and another problem. -- Chris Tillman Developer
Bug#735428: Still active in 3.14-2 as well.
QED -- Chris Tillman
Bug#758932: udisksd: Disconnecting USB disk results in kernel crash
Package: udisks2 Version: 2.1.3-2 Severity: critical File: udisksd Justification: breaks the whole system Dear Maintainer, * What led up to the situation? Disconnecting a USB drive * What exactly did you do (or not do) that was effective (or ineffective)? Could not regain access to the system, had to cold boot Here are entries from syslog just after disconnecting the drive until the kernel crash. Aug 23 10:01:37 121-73-239-129 kernel: [143836.389518] usb 2-6: USB disconnect, device number 3 Aug 23 10:01:37 121-73-239-129 udisksd[1529]: Cleaning up mount point /media/ctillman/15d722f2-ca41-4346-9def-d70df88e350f (device 8:28 no longer exist) Aug 23 10:01:37 121-73-239-129 udisksd[1529]: Cleaning up mount point /media/ctillman/win (device 8:25 no longer exist) Aug 23 10:01:37 121-73-239-129 kernel: [143836.591902] FAT-fs (sdb9): unable to read boot sector to mark fs as dirty Aug 23 10:01:37 121-73-239-129 gnome-session[1424]: libmediaart-Message: Mount:'19 GB Volume' with UUID:'15d722f2-ca41-4346-9def-d70df88e350f' now unmounted from:'/media/ctillman/15d722f2-ca41-4346-9def-d70df88e350f' Aug 23 10:01:37 121-73-239-129 udisksd[1529]: Cleaning up mount point /media/ctillman/Mac9.2 (device 8:27 no longer exist) Aug 23 10:01:37 121-73-239-129 udisksd[1529]: Cleaning up mount point /media/ctillman/bootstrap (device 8:26 no longer exist) Aug 23 10:01:37 121-73-239-129 kernel: [143836.764466] Buffer I/O error on device sdb10, logical block 2 Aug 23 10:01:37 121-73-239-129 kernel: [143836.764474] lost page write due to I/O error on sdb10 I believe this occurred because I had a terminal window open in one of the directories on the USB mounted drive when I disconnected it (the 19GB volume which was sdb10). -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.14-2-686-pae (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 udisks2 depends on: ii dbus 1.8.6-1 ii libacl12.2.52-1 ii libatasmart4 0.19-3 ii libc6 2.19-9 ii libglib2.0-0 2.40.0-4 ii libgudev-1.0-0 208-6 ii libpam-systemd 208-6 ii libpolkit-agent-1-00.105-6.1 ii libpolkit-gobject-1-0 0.105-6.1 ii libsystemd-daemon0 208-6 ii libsystemd-login0 208-6 ii libudisks2-0 2.1.3-2 ii parted 3.2-4 ii udev 208-6 Versions of packages udisks2 recommends: ii dosfstools 3.0.26-3 ii eject2.1.5+deb1+cvs20081104-13.1 ii gdisk0.8.8-1 ii ntfs-3g 1:2014.2.15AR.1-5 ii policykit-1 0.105-6.1 Versions of packages udisks2 suggests: pn btrfs-tools none ii cryptsetup-bin 2:1.6.4-4 pn exfat-utils none pn mdadm none pn reiserfsprogs none pn xfsprogsnone -- 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#758934: xserver-xorg: Segfault with Rage 128 driving VGA monitor on powerpc (works on Wheezy)
Package: xserver-xorg Version: 1:7.7+7 Severity: important Tags: d-i Dear Maintainer, * What led up to the situation? First, I tried booting without creating an xorg.conf. The result was a repeating loop of the last 3 lines: [ 267.863] (==) RandR enabled [ 268.004] (II) SELinux: Disabled on system [ 268.028] (II) AIGLX: Screen 0 is not DRI2 capable [ 268.028] (EE) AIGLX: reverting to software rendering [ 268.085] (II) AIGLX: Loaded and initialized swrast [ 268.086] (II) GLX: Initialized DRISWRAST GL provider for screen 0 [ 268.324] (EE) R128(0): R128CCEWaitForIdle: CCE idle -9 [ 268.324] (EE) R128(0): Idle timed out, resetting engine... [ 268.324] (EE) R128(0): R128CCEWaitForIdle: CCE stop -9 [ 268.325] (EE) R128(0): R128CCEWaitForIdle: CCE start -9 [ 268.325] (EE) R128(0): R128CCEWaitForIdle: CCE idle -9 Next, I tried generating a config with X -configure. Same reult. Finally, I tried substituting the config which works under Wheezy on the same machine. That resulted in the reported segfault. * What exactly did you do (or not do) that was effective (or ineffective)? Nothing was effective to get X started. * What was the outcome of this action? No GUI * What outcome did you expect instead? GUI The segfault (full log attached below by reportbug): [ 127.035] (II) R128(0): Page flipping disabled [ 127.035] (!!) R128(0): For information on using the multimedia capabilities of this adapter, please see http://gatos.sf.net. [ 127.035] (--) Depth 24 pixmap format is 32 bpp [ 127.035] (II) R128(0): Acceleration of RENDER operations will be enabled upon successful loading of DRI and EXA [ 127.041] (WW) R128(0): Acceleration disabled, not initializing the DRI [ 127.042] (II) R128(0): Filling in EXA memory info [ 127.042] (II) R128(0): Acceleration disabled [ 127.042] (EE) [ 127.042] (EE) Backtrace: [ 127.043] (EE) 0: /usr/bin/X (xorg_backtrace+0x60) [0x20437130] [ 127.043] (EE) 1: /usr/bin/X (0x20234000+0x2085c0) [0x2043c5c0] [ 127.043] (EE) 2: linux-vdso32.so.1 (__kernel_sigtramp_rt32+0x0) [0x1003a0] [ 127.043] (EE) 3: /usr/lib/xorg/modules/drivers/r128_drv.so (0x1f508000+0xc718) [0x1f514718] [ 127.044] (EE) 4: /usr/lib/xorg/modules/drivers/r128_drv.so (0x1f508000+0xc700) [0x1f514700] [ 127.044] (EE) 5: /usr/bin/X (AddScreen+0x100) [0x2028bc90] [ 127.044] (EE) 6: /usr/bin/X (InitOutput+0x330) [0x202df880] [ 127.045] (EE) 7: /usr/bin/X (0x20234000+0x5c568) [0x20290568] [ 127.045] (EE) 8: /usr/bin/X (0x20234000+0x425a4) [0x202765a4] [ 127.045] (EE) 9: /lib/powerpc-linux-gnu/libc.so.6 (0x1fc7b000+0x232f4) [0x1fc9e2f4] [ 127.046] (EE) 10: /lib/powerpc-linux-gnu/libc.so.6 (0x1fc7b000+0x234b4) [0x1fc9e4b4] [ 127.046] (EE) [ 127.046] (EE) Segmentation fault at address 0xc [ 127.046] (EE) Fatal server error: [ 127.046] (EE) Caught signal 11 (Segmentation fault). Server aborting [ 127.047] (EE) [ 127.047] (EE) I get the same result using startx with this conf. Here is the conf. Section ServerLayout Identifier X.org Configured Screen 0 Screen0 0 0 # Screen 1 Screen1 RightOf Screen0 InputDeviceMouse0 CorePointer InputDeviceKeyboard0 CoreKeyboard EndSection Section Files ModulePath /usr/lib/xorg/modules FontPath /usr/share/fonts/X11/misc FontPath /usr/share/fonts/X11/cyrillic FontPath /usr/share/fonts/X11/100dpi/:unscaled FontPath /usr/share/fonts/X11/75dpi/:unscaled FontPath /usr/share/fonts/X11/Type1 FontPath /usr/share/fonts/X11/100dpi FontPath /usr/share/fonts/X11/75dpi FontPath /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType FontPath built-ins EndSection Section Module Load dbe Load dri2 Load record Load glx Load dri Load extmod EndSection Section InputDevice Identifier Keyboard0 Driver kbd EndSection Section InputDevice Identifier Mouse0 Driver mouse Option Protocol auto Option Device /dev/input/mice Option ZAxisMapping 4 5 6 7 EndSection Section Monitor Identifier Monitor0 VendorName Monitor Vendor ModelNameMonitor Model Modeline 1024x768x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync EndSection #Section Monitor # Identifier Monitor1 # VendorName Monitor Vendor # ModelNameMonitor Model #EndSection Section Device ### Available Driver options are:- ### Values: i: integer, f: float, bool: True/False, ### string: String, freq: f Hz/kHz/MHz, ### percent: f% ### [arg]: arg optional Option NoAccel True # [bool] #Option SWcursor # [bool] #Option Dac6Bit # [bool] #Option Dac8Bit
Bug#758392: systemd: Assertion caused by journalctl --listboots
On Thu, Aug 21, 2014 at 10:38 AM, Michael Biebl bi...@debian.org wrote: Am 17.08.2014 06:11, schrieb Chris Tillman: Package: systemd Version: 208-6 Severity: normal Dear Maintainer, * What led up to the situation? journalctl --list-boots * What was the outcome of this action? Assertion 'size 0' failed at ../src/journal/mmap-cache.c:543, function mmap_cache_get(). Aborting. * What outcome did you expect instead? listing of boots as documented Hi Michael, - Is this problem reproducible (after a reboot Yes - Did you run the command as root or regular user? As root. I haven't been able to boot into the graphic environment as yet, I've been booting single-user. If that's important, I'll disable X so I can get on another console. - Do you have a /var/log/journal directory? If so, what does it contain (ls -Rla /var/log/journal/)? I did create one after reading another bug about multiple session journalctl. In that bug, you thought all that should be necessary was to create the dir. That did work, and here is ls -Rla. The journal file is being appended on each boot, so the backup files are the same size as the main file. /var/log/journal: total 12 drwxr-sr-x 3 root systemd-journal 4096 Aug 17 16:39 . drwxr-xr-x 11 root root4096 Aug 21 17:00 .. drwxr-sr-x 2 root systemd-journal 4096 Aug 21 16:59 42bc3423441b4065acbfbf085d5741df /var/log/journal/42bc3423441b4065acbfbf085d5741df: total 24596 drwxr-sr-x 2 root systemd-journal4096 Aug 21 16:59 . drwxr-sr-x 3 root systemd-journal4096 Aug 17 16:39 .. -rwxr-xr-x 1 root systemd-journal 8388608 Aug 18 19:36 system@000500e26f9ab124-86721527ee2de970.journal~ -rwxr-xr-x 1 root systemd-journal 8388608 Aug 21 16:59 system@0005011c967a9cb6-f1afda7b33407034.journal~ -rw-r- 1 root systemd-journal 8388608 Aug 21 17:04 system.journal - If you move the journal directory away and create a new one, is the problem gone? After moving it out of the way, it returns No journal files found. Same after re-creating /var/log/journal. After moving the directory back, the assertion returns. - Can you install systemd-dbg and create a backtrace using gdb, please. Output: Script started on Thu 21 Aug 2014 17:29:51 NZST root@debian:~# gdb --args journalctl --list-boots GNU gdb (GDB) 7.6.2 (Debian 7.6.2-1.1+b1) Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as powerpc-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /bin/journalctl...Reading symbols from /usr/lib/debug/.build-id/5a/b4971c9db1d4f7674ee6c7b37a6e160f89796c.debug...done. done. (gdb) run Starting program: /bin/journalctl --list-boots Can't read symbols from system-supplied DSO at 0x10: File truncated warning: Could not load shared library symbols for linux-vdso32.so.1. Do you need set solib-search-path or set sysroot? [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/powerpc-linux-gnu/libthread_db.so.1. Assertion 'size 0' failed at ../src/journal/mmap-cache.c:543, function mmap_cache_get(). Aborting. Program received signal SIGABRT, Aborted. 0x0fd5a168 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x0fd5a168 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x0fd5bd50 in __GI_abort () at abort.c:89 #2 0x1000f1bc in log_assert (text=text@entry=0x1003965c size 0, file=file@entry=0x100394a0 ../src/journal/mmap-cache.c, line=line@entry=543, func=func@entry=0x10039450 __PRETTY_FUNCTION__.8083 mmap_cache_get, format=format@entry=0x10035b8c Assertion '%s' failed at %s:%u, function %s(). Aborting.) at ../src/shared/log.c:702 #3 0x1000f798 in log_assert_failed (text=text@entry=0x1003965c size 0, file=file@entry=0x100394a0 ../src/journal/mmap-cache.c, line=line@entry=543, func=func@entry=0x10039450 __PRETTY_FUNCTION__.8083 mmap_cache_get) at ../src/shared/log.c:707 #4 0x10026d54 in mmap_cache_get (m=0x1004f918, fd=9, prot=optimized out, context=context@entry=1, keep_always=keep_always@entry=true, offset=optimized out, size=0, st=0x10060a90, ret=ret@entry=0x0) at ../src/journal/mmap-cache.c:543 #5 0x10018c74 in journal_file_object_keep (offset=optimized out, o=optimized out, f=optimized out) at ../src/journal/journal-file.h:215 #6 sd_journal_enumerate_unique (j=j@entry=0x1004e850, data=data@entry=0xb96c, l=l@entry=0xb970) at ../src/journal/sd-journal.c:2593 #7 0x100039c8 in list_boots (j=0x1004e850) at ../src/journal/journalctl.c:781 #8 main (argc=optimized out, argv=optimized out) at ../src
Bug#758392: systemd: Assertion caused by journalctl --listboots
Filed upstream bug 82894. On Thu, Aug 21, 2014 at 6:27 PM, Michael Biebl bi...@debian.org wrote: Am 21.08.2014 08:19, schrieb Chris Tillman: - If you move the journal directory away and create a new one, is the problem gone? After moving it out of the way, it returns No journal files found. Same after re-creating /var/log/journal. After moving the directory back, the assertion returns. So that looks like a corrupted journal then, causing the abort. It's probably best if you file this issue upstream and share the problematic journal file (if you don't have any privacy concerns), so the upstream developers have a chance reproducing the issue. Once you filed the bug report upstream, please report back so we can link the bug reports. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? -- Chris Tillman Developer
Bug#758394: Acknowledgement (systemd-modules-load is looking in the wrong directory)
I forgot to mention: systemd-modules-load is looking in /lib/modules/3.2.0-4-powerpc/ ... the modules actually exist in /lib/modules/ . On Sun, Aug 17, 2014 at 6:24 PM, Debian Bug Tracking System ow...@bugs.debian.org wrote: Thank you for filing a new Bug report with Debian. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Debian systemd Maintainers pkg-systemd-maintain...@lists.alioth.debian.org If you wish to submit further information on this problem, please send it to 758...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- 758394: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758394 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- Chris Tillman Developer
Bug#758394: systemd-modules-load is looking in the wrong directory
Just did the regular install from the cd netinst image. On Sun, Aug 17, 2014 at 8:40 PM, Martin Pitt mp...@debian.org wrote: Hello Chris, Chris Tillman [2014-08-17 19:07 +1200]: I forgot to mention: systemd-modules-load is looking in /lib/modules/3.2.0-4-powerpc/ ... the modules actually exist in /lib/modules/ . That seems invalid -- which kernel version do they belong to then? kmod/modprobe/etc. deliberately don't look there. How did you get a module installed into that path? Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Chris Tillman Developer
Bug#758391: [Pkg-xfce-devel] Bug#758391: lightdm greeter respawns continuously on jessie powerpc new install
Should I uninstall it? Or just install another display manager? On Sun, Aug 17, 2014 at 7:27 PM, Yves-Alexis Perez cor...@debian.org wrote: control: tag -1 moreinfo unreproducible On dim., 2014-08-17 at 15:19 +1200, Chris Tillman wrote: * What led up to the situation? jessie install from netinst cd downloaded Aug 8 * What exactly did you do (or not do) that was effective (or ineffective)? Booted into new install * What was the outcome of this action? Greeter appears, but cannot type and mouse doesn't work. Greeter respawns. * What outcome did you expect instead? Allow X login to new install Can you try to disable lightdm and see if X works fine by itself? -- Yves-Alexis -- Chris Tillman Developer
Bug#758391: [Pkg-xfce-devel] Bug#758391: lightdm greeter respawns continuously on jessie powerpc new install
I'm prevented from switching to the console, I think because that is locked out while X is starting. But starting in single mode, and running startx from there, I got a different result. Still no mouse or keyboard input available, and no login. It goes straight to a desktop display, with icons on theleft for Home, File System, Trsh, and the disk volumes available. There is a window in front which says Welcome to the first start of the panel in bold, and Choose below which setup you want for the first startup. with two buttons, Use default config or One empty panel. Maybe this could be related to my /llib/modules folder being mis-named? See 758394. That might explain the missing mouse, anyway. The computer is unresponsive at this point, can't switch back to the console. Have to shut it down. And bedtime here with work tomorrow, so next update in 20 hours or so :) Chris On Sun, Aug 17, 2014 at 10:28 PM, Yves-Alexis Perez cor...@debian.org wrote: On dim., 2014-08-17 at 21:21 +1200, Chris Tillman wrote: Should I uninstall it? Or just install another display manager? Just switch to the console, stop it and then start X directly (or use startx). Regards, -- Yves-Alexis -- Chris Tillman Developer
Bug#758394: closed by Michael Biebl bi...@debian.org (Re: Bug#758394: systemd-modules-load is looking in the wrong directory)
Thanks Michael, will check into it tomorrow. Perhaps I got wires crossed somehow in the installation. On Sun, Aug 17, 2014 at 10:51 PM, Debian Bug Tracking System ow...@bugs.debian.org wrote: This is an automatic notification regarding your Bug report which was filed against the systemd package: #758394: systemd-modules-load is looking in the wrong directory It has been closed by Michael Biebl bi...@debian.org. Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Michael Biebl bi...@debian.org by replying to this email. -- 758394: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758394 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- Forwarded message -- From: Michael Biebl bi...@debian.org To: Chris Tillman toff.till...@gmail.com, 758394-d...@bugs.debian.org Cc: Date: Sun, 17 Aug 2014 12:50:04 +0200 Subject: Re: Bug#758394: systemd-modules-load is looking in the wrong directory Am 17.08.2014 12:40, schrieb Chris Tillman: On 8/17/14, Michael Biebl bi...@debian.org wrote: Am 17.08.2014 10:40, schrieb Martin Pitt: Hello Chris, Chris Tillman [2014-08-17 19:07 +1200]: I forgot to mention: systemd-modules-load is looking in /lib/modules/3.2.0-4-powerpc/ ... the modules actually exist in /lib/modules/ . That seems invalid -- which kernel version do they belong to then? kmod/modprobe/etc. deliberately don't look there. How did you get a module installed into that path? And also, that /lib/modules/3.2.0-4-powerpc/modules.dep.bin is missing, means your system is pretty much broken. Could you send use the output of ls -la /lib/modules/ and ls -la /lib/modules/$(uname -r) I was wrong, the modules aren't located in /lib/modules. The modules subfolder just doesn't match the kernel version. This is probably a cdimage problem. # ls -la /lib/modules total 12 drwxr-xr-x 3 root root 4096 Aug 14 17:07 . drwxr-xr-x 20 root root 4096 Aug 14 19:47 .. drwxr-xr-x 3 root root 4096 Aug 14 17:32 3.14-2-powerpc # ls -la /li/modules/$(uname -r) ls: cannot access /lib/modules/3.2.0-4-powerpc: No such file or directory Thanks for reporting back. So it seems you are booted with a wheezy kernel, but the modules directory belongs to a jessie kernel. In any case, this is not a systemd issue, Therefor closing this bug report. You might check your /boot directory and your boot loader configuration. Maybe this is pointing to a copy of the wheezy kernel -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? -- Forwarded message -- From: Chris Tillman toff.till...@gmail.com To: Debian Bug Tracking System sub...@bugs.debian.org Cc: Date: Sun, 17 Aug 2014 18:20:58 +1200 Subject: systemd-modules-load is looking in the wrong directory Package: systemd Version: 208-6 Severity: important Tags: d-i Dear Maintainer, * What led up to the situation? While investigating another bug, I used journalctl. I noticed in the output that modules were not being loaded. * What was the outcome of this action? Later on the sound that depends on the sound module, for example, is inoperative. * What outcome did you expect instead? Modules properly loaded # journalctl PRIORITY=1 PRIORITY=2 PRIORITY=3 PRIORITY=4 PRIORITY=5 -- Logs begin at Sun 2014-08-17 16:38:49 NZST, end at Sun 2014-08-17 17:01:41 NZST. -- Aug 17 16:38:49 debian systemd[1]: Failed to open /dev/autofs: No such file or directory Aug 17 16:38:49 debian systemd-modules-load[192]: could not open moddep file '/lib/modules/3.2.0-4-powerpc/modules.dep.bin' Aug 17 16:38:49 debian systemd-modules-load[192]: Failed to lookup alias 'lp': Function not implemented Aug 17 16:38:49 debian systemd-modules-load[192]: could not open moddep file '/lib/modules/3.2.0-4-powerpc/modules.dep.bin' Aug 17 16:38:49 debian systemd-modules-load[192]: Failed to lookup alias 'ppdev': Function not implemented Aug 17 16:38:49 debian systemd-modules-load[192]: could not open moddep file '/lib/modules/3.2.0-4-powerpc/modules.dep.bin' Aug 17 16:38:49 debian systemd-modules-load[192]: Failed to lookup alias 'parport_pc': Function not implemented Aug 17 16:38:50 debian systemd-modules-load[192]: could not open moddep file '/lib/modules/3.2.0-4-powerpc/modules.dep.bin' Aug 17 16:38:50 debian systemd-modules-load[192]: Failed to lookup alias 'fuse': Function not implemented Aug 17 16:38:50 debian systemd-modules-load[192]: could not open moddep file '/lib/modules/3.2.0-4-powerpc/modules.dep.bin' Aug 17 16:38:50 debian systemd-modules-load[192]: Failed to lookup alias 'apm_emu': Function not implemented Aug 17 16:38:50 debian systemd-modules-load[192]: could not open moddep file '/lib/modules/3.2.0-4-powerpc/modules.dep.bin
Bug#640789: Crash on folder name with spaces
Hi Cyril,
Thanks for your attention. I think that was my patch. (Chris Tillman).
The only line the patch is affecting is the one with find $dir, adding the
quotes to make it find $dir.
The rest of it certainly does look strange, but anyway it works if you just
add the quotes. Maybe another time to refactor it, because we have been
waiting years for this patch already.
I verified today it is still present in the current testing installer.
Chris
On Mon, 7 Jul 2014 03:56:21 +0200 Cyril Brulebois k...@debian.org wrote:
Control: tag -1 -patch
Hi Modestas,
Modestas Vainius mo...@debian.org (2013-12-29):
Control: tags -1 patch
thanks for the patch but I'm not convinced, see below:
--- a/debian/iso-scan.postinst
+++ b/debian/iso-scan.postinst
@@ -162,7 +162,7 @@ scan_device_for_isos() {
elif [ $look_subdirs = 1 ]; then
opt=-type f
fi
- isolist=$(find $dir $opt -name *.iso -o -name *.ISO 2/dev/null)
+ isolist=$(find $dir $opt -name *.iso -o -name *.ISO 2/dev/null)
This part is certainly OK; at least I can't think of a reason why that
wouldn't be a good thing.
TOPLEVEL_DIRS_COUNT=$(($TOPLEVEL_DIRS_COUNT + 1))
for iso in $isolist; do
but then that means we're possibly going to fail here. Example:
kibi@wodi:~/isos$ ls */
baz/:
baz.iso
foo bar/:
foobar.iso
kibi@wodi:~/isos$ isolist=$(find $dir $opt -name *.iso -o -name
*.ISO 2/dev/null)
kibi@wodi:~/isos$ for iso in $isolist; do echo Found ISO $iso; done
Found ISO ./foo
Found ISO bar/foobar.iso
Found ISO ./baz/baz.iso
I guess it would make sense to fix this for real instead of hiding it a
bit further. Unfortunately 4am isn't a great time to set up a reproducer
and to keep on hacking. :/
(Also, sorry for the lag.)
Mraw,
KiBi.
Bug#747384: Acknowledgement (cdimage.debian.org: Powerpc testing image contains mismatched kernel and modules)
This inconsistency appears to be fixed now: ... zlib-modules-3.14-1-powerpc-di_3.14.4-1_powerpc.udeb linux-image-3.14-1-powerpc_3.14.4-1_powerpc.deb linux-image-3.14-1-powerpc-smp_3.14.4-1_powerpc.deb linux-image-3.14-1-powerpc64_3.14.4-1_powerpc.deb At my next opportunity I'll retest. On Thu, May 8, 2014 at 12:30 AM, Debian Bug Tracking System ow...@bugs.debian.org wrote: Thank you for filing a new Bug report with Debian. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. As you requested using X-Debbugs-CC, your message was also forwarded to toff.till...@gmail.com (after having been given a Bug report number, if it did not have one). Your message has been sent to the package maintainer(s): Debian CD-ROM Team debian...@lists.debian.org If you wish to submit further information on this problem, please send it to 747...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- 747384: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747384 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- Chris Tillman Developer
Bug#747684: tracker-miner-fs: Root terminal fails to open; error (tracker-miner-fs:3546): GLib-CRITICAL **: g_timer_continue: assertion 'timer-active == FALSE' failed
Package: tracker-miner-fs Version: 0.16.2-1+b2 Severity: important Dear Maintainer, * What led up to the situation? After upgrading from stable to testing, the root terminal window refuse to open. The permission window opens, and accepts the password, but the root terminal doesn't open. The regular terminal window opens fine. * What exactly did you do (or not do) that was effective (or ineffective)? I used tty1 to access root commands instead. * What was the outcome of this action? The user/.cache/gdm/session.log shows errors when the Root Terminal is attempted to be open. I am attaching logs before and after the attempt right after a restart. * What outcome did you expect instead? Root terminal window opens, no errors in logs. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.10-3-686-pae (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 tracker-miner-fs depends on: ii libc6 2.18-5 ii libglib2.0-0 2.40.0-3 ii libtracker-extract-0.16-0 0.16.2-1+b2 ii libtracker-miner-0.16-00.16.2-1+b2 ii libtracker-sparql-0.16-0 0.16.2-1+b2 ii libupower-glib10.9.23-2+b2 ii procps 1:3.3.9-2 ii tracker0.16.2-1+b2 ii tracker-extract0.16.2-1+b2 tracker-miner-fs recommends no packages. tracker-miner-fs suggests no packages. /etc/gdm3/Xsession: Beginning session setup... localuser:ctillman being added to access control list openConnection: connect: No such file or directory cannot connect to brltty at :0 x-session-manager[3337]: WARNING: Error getting login monitor: -2 x-session-manager[3337]: WARNING: Could not parse desktop file gnome-volume-manager.desktop or it references a not found TryExec binary x-session-manager[3337]: WARNING: Could not parse desktop file update-notifier.desktop or it references a not found TryExec binary GNOME_KEYRING_CONTROL=/run/user/1000/keyring-CNlArG GNOME_KEYRING_CONTROL=/run/user/1000/keyring-CNlArG SSH_AUTH_SOCK=/run/user/1000/keyring-CNlArG/ssh GNOME_KEYRING_CONTROL=/run/user/1000/keyring-CNlArG SSH_AUTH_SOCK=/run/user/1000/keyring-CNlArG/ssh GPG_AGENT_INFO=/run/user/1000/keyring-CNlArG/gpg:0:1 GNOME_KEYRING_CONTROL=/run/user/1000/keyring-CNlArG SSH_AUTH_SOCK=/run/user/1000/keyring-CNlArG/ssh GPG_AGENT_INFO=/run/user/1000/keyring-CNlArG/gpg:0:1 Window manager warning: Log level 16: Attempt to add property Gjs_MonitorConstraint::primary after class was initialised Window manager warning: Log level 16: Attempt to add property Gjs_MonitorConstraint::index after class was initialised JS LOG: GNOME Shell started at Sun May 11 2014 11:54:09 GMT+1200 (NZST) Window manager warning: CurrentTime used to choose focus window; focus window may not be correct. Window manager warning: Got a request to focus the no_focus_window with a timestamp of 0. This shouldn't happen! Tracker-Message: Importing config file to GSettings Tracker-Message: Importing config file to GSettings Tracker-Message: Importing config file to GSettings (tracker-store:3533): Tracker-CRITICAL **: D-Bus service name:'org.freedesktop.Tracker1' is already taken, perhaps the daemon is already running? (tracker-miner-fs:3546): GLib-CRITICAL **: g_timer_continue: assertion 'timer-active == FALSE' failed /etc/gdm3/Xsession: Beginning session setup... localuser:ctillman being added to access control list openConnection: connect: No such file or directory cannot connect to brltty at :0 x-session-manager[3337]: WARNING: Error getting login monitor: -2 x-session-manager[3337]: WARNING: Could not parse desktop file gnome-volume-manager.desktop or it references a not found TryExec binary x-session-manager[3337]: WARNING: Could not parse desktop file update-notifier.desktop or it references a not found TryExec binary GNOME_KEYRING_CONTROL=/run/user/1000/keyring-CNlArG GNOME_KEYRING_CONTROL=/run/user/1000/keyring-CNlArG SSH_AUTH_SOCK=/run/user/1000/keyring-CNlArG/ssh GNOME_KEYRING_CONTROL=/run/user/1000/keyring-CNlArG SSH_AUTH_SOCK=/run/user/1000/keyring-CNlArG/ssh GPG_AGENT_INFO=/run/user/1000/keyring-CNlArG/gpg:0:1 GNOME_KEYRING_CONTROL=/run/user/1000/keyring-CNlArG SSH_AUTH_SOCK=/run/user/1000/keyring-CNlArG/ssh GPG_AGENT_INFO=/run/user/1000/keyring-CNlArG/gpg:0:1 Window manager warning: Log level 16: Attempt to add property Gjs_MonitorConstraint::primary after class was initialised Window manager warning: Log level 16: Attempt to add property Gjs_MonitorConstraint::index after class was initialised JS LOG: GNOME Shell started at Sun May 11 2014 11:54:09 GMT+1200 (NZST) Window manager warning: CurrentTime used to choose focus window; focus window may not be correct. Window manager warning: Got a request to focus the no_focus_window with a timestamp of 0. This shouldn't happen!
Bug#739444: Another report
I investigated the logs after my root terminal window failed to open. One of the errors was from glibtop reported in .cache/gdm/session.log: /etc/gdm3/Xsession: Beginning session setup... localuser:ctillman being added to access control list openConnection: connect: No such file or directory cannot connect to brltty at :0 x-session-manager[3337]: WARNING: Error getting login monitor: -2 x-session-manager[3337]: WARNING: Could not parse desktop file gnome-volume-manager.desktop or it references a not found TryExec binary x-session-manager[3337]: WARNING: Could not parse desktop file update-notifier.desktop or it references a not found TryExec binary GNOME_KEYRING_CONTROL=/run/user/1000/keyring-CNlArG GNOME_KEYRING_CONTROL=/run/user/1000/keyring-CNlArG SSH_AUTH_SOCK=/run/user/1000/keyring-CNlArG/ssh GNOME_KEYRING_CONTROL=/run/user/1000/keyring-CNlArG SSH_AUTH_SOCK=/run/user/1000/keyring-CNlArG/ssh GPG_AGENT_INFO=/run/user/1000/keyring-CNlArG/gpg:0:1 GNOME_KEYRING_CONTROL=/run/user/1000/keyring-CNlArG SSH_AUTH_SOCK=/run/user/1000/keyring-CNlArG/ssh GPG_AGENT_INFO=/run/user/1000/keyring-CNlArG/gpg:0:1 Window manager warning: Log level 16: Attempt to add property Gjs_MonitorConstraint::primary after class was initialised Window manager warning: Log level 16: Attempt to add property Gjs_MonitorConstraint::index after class was initialised JS LOG: GNOME Shell started at Sun May 11 2014 11:54:09 GMT+1200 (NZST) Window manager warning: CurrentTime used to choose focus window; focus window may not be correct. Window manager warning: Got a request to focus the no_focus_window with a timestamp of 0. This shouldn't happen! Tracker-Message: Importing config file to GSettings Tracker-Message: Importing config file to GSettings Tracker-Message: Importing config file to GSettings (tracker-store:3533): Tracker-CRITICAL **: D-Bus service name:'org.freedesktop.Tracker1' is already taken, perhaps the daemon is already running? (tracker-miner-fs:3546): GLib-CRITICAL **: g_timer_continue: assertion 'timer-active == FALSE' failed Window manager warning: Log level 8: Source ID 488 was not found when attempting to remove it Window manager warning: Log level 8: Source ID 496 was not found when attempting to remove it Window manager warning: Log level 8: Source ID 499 was not found when attempting to remove it Window manager warning: Log level 8: Source ID 501 was not found when attempting to remove it Window manager warning: Log level 8: Source ID 508 was not found when attempting to remove it Window manager warning: CurrentTime used to choose focus window; focus window may not be correct. Window manager warning: Got a request to focus the no_focus_window with a timestamp of 0. This shouldn't happen! glibtop: Non-standard uts for running kernel: release 3.10-3-686-pae=3.10.0 gives version code 199168 Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: Error calling StartServiceByName for org.gnome.Terminal: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.gnome.Terminal exited with status 1 -- Chris Tillman Developer
Bug#747384: cdimage.debian.org: Powerpc testing image contains mismatched kernel and modules
Package: cdimage.debian.org Severity: important Tags: d-i Dear Maintainer, * What led up to the situation? I tried to use the jessie installer downloaded from http://ftp.nz.debian.org/debian/dists/jessie/main/installer- powerpc/current/images/powerpc/hd-media/ with the iso downloaded from http://cdimage.debian.org/cdimage/weekly-builds/powerpc/iso-cd/debian-testing- powerpc-netinst.iso dated 2014-05-05 In the installer, I was warned that no modules were available. I checked uname -a, and the installer had linux-image-powerpc-3.13-1 (3.13.5-1). The iso got loaded OK from the hard disk. I then checked the iso contents and verified there were no modules available for that kernel. It looked like some were available for other kernels like image-powerpc-smp and image-powerpc64. After quitting the installation (no installation was possible) I checked in http://cdimage.debian.org/cdimage/weekly-builds/powerpc/list-cd/debian-testing- powerpc-netinst.list.gz It looked like the modules are version 3.14, while the kernels are version 3.13: affs-modules-3.14-1-powerpc-di_3.14.2-1_powerpc.udeb affs-modules-3.14-1-powerpc64-di_3.14.2-1_powerpc.udeb ata-modules-3.14-1-powerpc-di_3.14.2-1_powerpc.udeb ata-modules-3.14-1-powerpc64-di_3.14.2-1_powerpc.udeb btrfs-modules-3.14-1-powerpc-di_3.14.2-1_powerpc.udeb btrfs-modules-3.14-1-powerpc64-di_3.14.2-1_powerpc.udeb core-modules-3.14-1-powerpc-di_3.14.2-1_powerpc.udeb core-modules-3.14-1-powerpc64-di_3.14.2-1_powerpc.udeb crc-modules-3.14-1-powerpc-di_3.14.2-1_powerpc.udeb crc-modules-3.14-1-powerpc64-di_3.14.2-1_powerpc.udeb crypto-dm-modules-3.14-1-powerpc-di_3.14.2-1_powerpc.udeb crypto-dm-modules-3.14-1-powerpc64-di_3.14.2-1_powerpc.udeb crypto-modules-3.14-1-powerpc-di_3.14.2-1_powerpc.udeb crypto-modules-3.14-1-powerpc64-di_3.14.2-1_powerpc.udeb event-modules-3.14-1-powerpc-di_3.14.2-1_powerpc.udeb event-modules-3.14-1-powerpc64-di_3.14.2-1_powerpc.udeb ext4-modules-3.14-1-powerpc-di_3.14.2-1_powerpc.udeb ext4-modules-3.14-1-powerpc64-di_3.14.2-1_powerpc.udeb fancontrol-modules-3.14-1-powerpc64-di_3.14.2-1_powerpc.udeb fat-modules-3.14-1-powerpc-di_3.14.2-1_powerpc.udeb fat-modules-3.14-1-powerpc64-di_3.14.2-1_powerpc.udeb fuse-modules-3.14-1-powerpc-di_3.14.2-1_powerpc.udeb fuse-modules-3.14-1-powerpc64-di_3.14.2-1_powerpc.udeb hfs-modules-3.14-1-powerpc-di_3.14.2-1_powerpc.udeb hfs-modules-3.14-1-powerpc64-di_3.14.2-1_powerpc.udeb hypervisor-modules-3.14-1-powerpc64-di_3.14.2-1_powerpc.udeb isofs-modules-3.14-1-powerpc-di_3.14.2-1_powerpc.udeb isofs-modules-3.14-1-powerpc64-di_3.14.2-1_powerpc.udeb jfs-modules-3.14-1-powerpc-di_3.14.2-1_powerpc.udeb jfs-modules-3.14-1-powerpc64-di_3.14.2-1_powerpc.udeb loop-modules-3.14-1-powerpc-di_3.14.2-1_powerpc.udeb loop-modules-3.14-1-powerpc64-di_3.14.2-1_powerpc.udeb md-modules-3.14-1-powerpc-di_3.14.2-1_powerpc.udeb md-modules-3.14-1-powerpc64-di_3.14.2-1_powerpc.udeb multipath-modules-3.14-1-powerpc-di_3.14.2-1_powerpc.udeb multipath-modules-3.14-1-powerpc64-di_3.14.2-1_powerpc.udeb nbd-modules-3.14-1-powerpc-di_3.14.2-1_powerpc.udeb nbd-modules-3.14-1-powerpc64-di_3.14.2-1_powerpc.udeb nic-modules-3.14-1-powerpc-di_3.14.2-1_powerpc.udeb nic-modules-3.14-1-powerpc64-di_3.14.2-1_powerpc.udeb nic-pcmcia-modules-3.14-1-powerpc-di_3.14.2-1_powerpc.udeb nic-pcmcia-modules-3.14-1-powerpc64-di_3.14.2-1_powerpc.udeb nic-shared-modules-3.14-1-powerpc-di_3.14.2-1_powerpc.udeb nic-shared-modules-3.14-1-powerpc64-di_3.14.2-1_powerpc.udeb pata-modules-3.14-1-powerpc-di_3.14.2-1_powerpc.udeb pata-modules-3.14-1-powerpc64-di_3.14.2-1_powerpc.udeb pcmcia-modules-3.14-1-powerpc-di_3.14.2-1_powerpc.udeb pcmcia-modules-3.14-1-powerpc64-di_3.14.2-1_powerpc.udeb pcmcia-storage-modules-3.14-1-powerpc-di_3.14.2-1_powerpc.udeb pcmcia-storage-modules-3.14-1-powerpc64-di_3.14.2-1_powerpc.udeb ppp-modules-3.14-1-powerpc-di_3.14.2-1_powerpc.udeb ppp-modules-3.14-1-powerpc64-di_3.14.2-1_powerpc.udeb sata-modules-3.14-1-powerpc-di_3.14.2-1_powerpc.udeb sata-modules-3.14-1-powerpc64-di_3.14.2-1_powerpc.udeb scsi-extra-modules-3.14-1-powerpc-di_3.14.2-1_powerpc.udeb scsi-extra-modules-3.14-1-powerpc64-di_3.14.2-1_powerpc.udeb serial-modules-3.14-1-powerpc-di_3.14.2-1_powerpc.udeb serial-modules-3.14-1-powerpc64-di_3.14.2-1_powerpc.udeb squashfs-modules-3.14-1-powerpc-di_3.14.2-1_powerpc.udeb squashfs-modules-3.14-1-powerpc64-di_3.14.2-1_powerpc.udeb udf-modules-3.14-1-powerpc-di_3.14.2-1_powerpc.udeb udf-modules-3.14-1-powerpc64-di_3.14.2-1_powerpc.udeb uinput-modules-3.14-1-powerpc-di_3.14.2-1_powerpc.udeb uinput-modules-3.14-1-powerpc64-di_3.14.2-1_powerpc.udeb usb-serial-modules-3.14-1-powerpc-di_3.14.2-1_powerpc.udeb usb-serial-modules-3.14-1-powerpc64-di_3.14.2-1_powerpc.udeb virtio-modules-3.14-1-powerpc-di_3.14.2-1_powerpc.udeb virtio-modules-3.14-1-powerpc64-di_3.14.2-1_powerpc.udeb xfs-modules-3.14-1-powerpc-di_3.14.2-1_powerpc.udeb xfs-modules-3.14-1-powerpc64-di_3.14.2-1_powerpc.udeb
Bug#737170: Potentially duplicate bug
The error shown Jan 30 21:04:35 main-menu[251]: WARNING **: Configuring 'iso-scan' failed with error code 1 Jan 30 21:04:35 main-menu[251]: WARNING **: Menu item 'iso-scan' failed. is the same symptom shown in iso-scan bug 640789, caused by an unquoted $dir variable in a find command within iso-scan.postinst. OP, did the volume you were trying to query have any paths with spaces in it? That would cause this error. -- Chris Tillman Developer
Bug#628991: Potential bug duplicate
Also see bug 640789, which could be a duplicate.
Bug#712675: Potential duplicate bug
The error shown Jul 10 04:51:52 main-menu[213]: WARNING **: Configuring 'iso-scan' failed with error code 1 Jul 10 04:51:52 main-menu[213]: WARNING **: Menu item 'iso-scan' failed. is the same symptom shown in iso-scan bug 640789, caused by an unquoted $dir variable in a find command within iso-scan.postinst. OP, did the volume you were trying to query have any paths with spaces in it? That would cause this error.
Bug#640789: Same patch applies for more bugs
The patch is a simple fix, and should be applied with urgency. It will also fix some other bugs 628...@bugs.debian.org https://bugs.launchpad.net/ubuntu/+source/iso-scan/+bug/838720 Frans Pop seems to have noticed this in bug 440301 and thought he fixed it in 2007: -- P.S. It does look like there is a minor bug in isoscan (which should not affect this case though). The first call in line 111 uses quotes, the second one in line 166 does not; I think this will make the comparison in line 167 always false (if there are multiple DEVS). I've fixed that. -- So, here it is 7 years later. How can this bug still exist? -- Chris Tillman
Bug#571958: hfsplus supported
Hi, I just wanted to throw in here that the iso images are found successfully on an hfsplus drive (PowerMac G4, MacOS Extended partition). I am getting the same issue as in 628991, so will post my full results over there. But as far as hfsplus, no worries: Feb 9 19:02:40 iso-scan: selected_device(s)='/dev/sda9' Feb 9 19:02:40 kernel: [ 351.164265] FAT-fs (sda9): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! Feb 9 19:02:41 kernel: [ 351.764528] FAT-fs (sda9): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! Feb 9 19:02:41 iso-scan: Mounted /dev/sda9 for first pass Feb 9 19:02:41 iso-scan: Found ISO ./debian-7.3.0-powerpc-netinst.iso on /dev/sda9 Feb 9 19:02:41 kernel: [ 352.324499] ISO 9660 Extensions: Microsoft Joliet Level 3 Feb 9 19:02:41 kernel: [ 352.356792] ISO 9660 Extensions: RRIP_1991A Feb 9 19:02:41 iso-scan: Detected ISO with 'stable' (wheezy) distribution Feb 9 19:02:41 iso-scan: Detected ISO with distribution 'stable' (wheezy) Feb 9 19:02:41 iso-scan: Debian ISO ./debian-7.3.0-powerpc-netinst.iso usable Feb 9 19:02:41 iso-scan: Found ISO ./debian-testing-powerpc-netinst.iso on /dev/sda9 Feb 9 19:02:42 kernel: [ 352.530717] ISO 9660 Extensions: Microsoft Joliet Level 3 Feb 9 19:02:42 kernel: [ 352.557330] ISO 9660 Extensions: RRIP_1991A Feb 9 19:02:42 iso-scan: Detected ISO with 'testing' (jessie) distribution Feb 9 19:02:42 iso-scan: Detected ISO with distribution 'testing' (jessie) Feb 9 19:02:42 iso-scan: Debian ISO ./debian-testing-powerpc-netinst.iso usable Feb 9 19:02:42 iso-scan: Found ISO ./Applications/debian-7.3.0-powerpc-netinst.iso on /dev/sda9 Feb 9 19:02:42 kernel: [ 353.105643] ISO 9660 Extensions: Microsoft Joliet Level 3 Feb 9 19:02:42 kernel: [ 353.141321] ISO 9660 Extensions: RRIP_1991A Feb 9 19:02:42 iso-scan: Detected ISO with 'stable' (wheezy) distribution Feb 9 19:02:42 iso-scan: Detected ISO with distribution 'stable' (wheezy) Feb 9 19:02:42 iso-scan: Debian ISO ./Applications/debian-7.3.0-powerpc-netinst.iso usable Feb 9 19:02:42 main-menu[251]: WARNING **: Configuring 'iso-scan' failed with error code 1 -- Chris Tillman Developer
Bug#628991: Repeated, some more info, patch
Tags: patch Hi, I got the same failure when trying to install on PowerPc. I believe it is related to quoting as the submitter suggested. iso-scan first looks at the root level to find iso's, then scans each first-level directory as well, using the BusyBox find command. When parentheses or spaces are included in the folder name passed to the find command, an error results. To make a long story short, here is the patch that fixed it for my installation: --- iso-scan.postinst rev 1298 +++ iso-scan.postinst.patched @@ -165,165, +165,165 @@ - isolist=$(find $dir $opt -name *.iso -o -name *.ISO 2/dev/null) + isolist=$(find $dir $opt -name *.iso -o -name *.ISO 2/dev/null) -- Chris Tillman Developer
Bug#570377: aptitude chooses to remove packages instead of upgrading
) - Remove icedtea6-plugin [6b18-1.8.13-0+squeeze2 (now, oldstable)] --\ openjdk-6-jre depends upon libjpeg8 - Remove openjdk-6-jre [6b18-1.8.13-0+squeeze2 (now)] ? Something like that. Perhaps that's what the -v --show-why options do. Use 'o' when examining a solution in the curses interface. On the command line, set Aptitude::CmdLine::Resolver-Show-Steps=1. -- Chris Tillman Developer
Bug#570377: Fwd: [Aptitude-devel] Bug#570377: aptitude chooses to remove packages instead of upgrading
Thanks very much for your reply and explanation, Daniel. I can appreciate that fiddling with defaults is a serious consideration. However, the scoring system replaced the tiered system where removals were considered less desirable than upgrades. So longtime users perceived a drastic change in behaviour and in aptitude's attitude. I don't know why, with equal scores, aptitude now prefers the removals option. Even with 3 to remove or 2 to upgrade, it still suggests the removals first. By adjusting the default just one point, its behaviour was completely different and it became a pleasure to use rather than seeming a constant battle. There may not be a philosophical difference between recommending removal of 3 packages including gnome, vs. upgrading 2 packages including the one you asked to upgrade, but there is definitely a psychological difference. So I'd argue that the 1-point advantage given to upgrades would represent that psychological preference. I really wonder about even the philosophical difference being 0. Users are attempting to maintain their system. If a user asks for an install or upgrade, surely more upgrades would be preferable. If they are doing removals or downgrades, then perhaps removals would be the direction they would want to go. Perhaps aptitude could be more sensitive to the requested operation and adjust priorities accordingly. Would you be open to a patch for that? And, in any case, I certainly can't understand why the defaults chosen should be carved in stone. 1, 2, 5 ... these seem to have been set nearly arbitrarily. Do we have any data about real-world user actions, i.e. x choices presented in scored order and score[i] actually chosen, that would allow us to zero in on truly representative weights which minimise i? Thanks, Chris On Tue, Feb 4, 2014 at 6:29 AM, Daniel Hartwig mand...@gmail.com wrote: On 2 February 2014 14:56, Chris Tillman toff.till...@gmail.com wrote: Tags: patch I think the root of the problem (removing being preferential to upgrading in Aptitude's worldview) is that the safe-level and remove-level default scores are the same. Hi Thanks for your interest and patch. Unfortunately, it is not an acceptable solution to apply to the _default_ settings. There is nothing fundamentally better or worse about either removals or installs, in some situations you might find this: solution 1: upgrade 20 packages solution 2: remove 1 Whichever is more preferable in these situations is up to the individual user to decide based on whatever particular packages are suggested for upgrade, install, or removal--aptitude can not know how the user values those individual actions. The point of the safety cost _levels_ is to broadly class categories of actions, and in that sense, installing or upgrading to a package in the target release is no better or worse than removing a non-essential package. Tweaking the default settings as per the patch here is not to be done lightly. Considering the architecture of the problem resolver as a whole, it is not an acceptable solution. I recommend any of Axels suggestions for individual users who are bothered by this, especially the comments about guiding the resolver by e.g. rejecting particular actions _before_ asking for the next solution. This is also covered in the users manual, _Resolving Dependencies Interactively_. That is the most effective way of informing the resolver about your desires. Regards -- Chris Tillman Developer -- Chris Tillman Developer
Bug#570377: aptitude chooses to remove packages instead of upgrading
Tags: patch
Ah, now I got a proper patch from debdiff. I hadn't gotten aptitude built
yet the first time.
In actual usage on my system, it suggests upgrades first rather than
removals (without any prefs in apt.conf or on the cmdline).
.
On Sun, Feb 2, 2014 at 7:56 PM, Chris Tillman toff.till...@gmail.comwrote:
Tags: patch
I think the root of the problem (removing being preferential to upgrading
in Aptitude's worldview) is that the safe-level and remove-level default
scores are the same.
*Table 2.2. Default safety cost levels*
Cost levelDescriptionConfiguration option 10,000 Solutions that include
only safe actions (installing the default target for a package or
keeping a package at its current version) and package removals.
Aptitude::ProblemResolver::Safe-Levelhttp://aptitude.alioth.debian.org/doc/en/ch02s05s05.html#configProblemResolver-Safe-Level,
Aptitude::ProblemResolver::Remove-Levelhttp://aptitude.alioth.debian.org/doc/en/ch02s05s05.html#configProblemResolver-Remove-Level
When I use a level just one more than the default for remove-level, I get
the desired result:
121-73-239-129:/home/ctillman/aptitude-0.6.8.3/src# aptitude -P -o
'Aptitude::ProblemResolver::Remove-Level=1' -vv full-upgrade
gir1.2-evince-3.0
The following packages will be upgraded:
gir1.2-evince-3.0 libevdocument3-4 libevview3-3
3 packages upgraded, 0 newly installed, 0 to remove and 364 not upgraded.
Need to get 0 B/1,934 kB of archives. After unpacking 85.0 kB will be used.
The following packages have unmet dependencies:
evince : Depends: libevdocument3-4 (= 3.8.3-2) but 3.10.0-2 is to be
installed.
Depends: libevview3-3 (= 3.8.3-2) but 3.10.0-2 is to be
installed.
The following actions will resolve these dependencies:
Remove the following packages:
1) evince
2) gnome
3) gnome-core
Leave the following dependencies unresolved:
4) epiphany-browser recommends evince
vs.
121-73-239-129:/home/ctillman/aptitude-0.6.8.3/src# aptitude -P -o
'Aptitude::ProblemResolver::Remove-Level=10001' full-upgrade
gir1.2-evince-3.0
The following packages will be upgraded:
gir1.2-evince-3.0 libevdocument3-4 libevview3-3
3 packages upgraded, 0 newly installed, 0 to remove and 364 not upgraded.
Need to get 0 B/1,934 kB of archives. After unpacking 85.0 kB will be used.
The following packages have unmet dependencies:
evince : Depends: libevdocument3-4 (= 3.8.3-2) but 3.10.0-2 is to be
installed.
Depends: libevview3-3 (= 3.8.3-2) but 3.10.0-2 is to be
installed.
The following actions will resolve these dependencies:
Upgrade the following packages:
1) evince [3.8.3-2 (now) - 3.10.0-2 (testing)]
2) evince-common [3.8.3-2 (now) - 3.10.0-2 (testing)]
I tried to prepare a one-line patch with quilt, as referenced in
http://raphaelhertzog.com/2011/07/04/how-to-prepare-patches-for-debian-packages/
but I only got one .dsc file instead of two. I'm attaching that and the
patch file quilt generated in debian/patches.
On Thu, Jan 30, 2014 at 10:01 PM, Axel Beckert a...@debian.org wrote:
Hi,
Vincent Lefevre wrote:
aptitude sometimes prefers to remove packages instead of upgrading.
Which is IMHO fine in general. I though must admit that it seems to do
that quite often in Debian Unstable.
Chris King wrote:
This is a very annoying behavior
In Debian Unstable, yes. But it is configurable behaviour, too:
Use
Aptitude::ProblemResolver::Remove-Level maximum;
or
Aptitude::ProblemResolver::Hints {
reject !~M :UNINST;
};
in your apt.conf and you're done.
The latter works better for this issue, but no more allows you to
choose solutions which remove packages unless you explicitly select
them for removal with - in the package list or on the commandline.
This can be annoying, too, and is totally unsuited for dist-upgrades
between two stable releases. It hence is _NOT_ a general solution, but
is very suitable for unattended upgrades of security upates.
aptitude-robot uses it for a while now.
The first variant is probably better suited for general use case, but
can still cause packages to not be upgraded at all due to conflicts
with obosolete packages which actually really should be removed. (I
think, this is one of the reasons why this issue is not trivial to fix
generally without regressions in other fields like dist-upgrades
between two stable releases.)
which Aptitude didn't exhibit a year or so ago.
Hrm, I would be curious which patch introduced that change...
Having to hit n twenty times before Aptitude decides to upgrade
one package rather than removing 50 is just silly.
... and not necessary at all, even without the above configuration.
Just type r on all (often suffices to do it only for some) packages
and hit . only afterwards. (I don't know by mind the commandline
keybindings for that -- these are for the TUI -- but typing ? on
the prompt may give you hints
Bug#570377: More information
I found that adding the apt.conf option Aptitude::Always-Use-Safe-Resolver true; results in aptitude selecting the upgrade rather than the removal, but ONLY command-line aptitude. command-line obeys apt.conf, even disregarding the command-line full-upgrade invocation. On the other hand, TUI aptitude seems to have disregarded apt.conf; this may be related to bug #485832https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=485832 . I will continue to look for the root cause and a desirable solution. -- Chris Tillman Developer
Bug#570377: aptitude chooses to remove packages instead of upgrading
Tags: patch
I think the root of the problem (removing being preferential to upgrading
in Aptitude's worldview) is that the safe-level and remove-level default
scores are the same.
*Table 2.2. Default safety cost levels*
Cost levelDescriptionConfiguration option10,000 Solutions that include only
safe actions (installing the default target for a package or keeping a
package at its current version) and package removals.
Aptitude::ProblemResolver::Safe-Levelhttp://aptitude.alioth.debian.org/doc/en/ch02s05s05.html#configProblemResolver-Safe-Level,
Aptitude::ProblemResolver::Remove-Levelhttp://aptitude.alioth.debian.org/doc/en/ch02s05s05.html#configProblemResolver-Remove-Level
When I use a level just one more than the default for remove-level, I get
the desired result:
121-73-239-129:/home/ctillman/aptitude-0.6.8.3/src# aptitude -P -o
'Aptitude::ProblemResolver::Remove-Level=1' -vv full-upgrade
gir1.2-evince-3.0
The following packages will be upgraded:
gir1.2-evince-3.0 libevdocument3-4 libevview3-3
3 packages upgraded, 0 newly installed, 0 to remove and 364 not upgraded.
Need to get 0 B/1,934 kB of archives. After unpacking 85.0 kB will be used.
The following packages have unmet dependencies:
evince : Depends: libevdocument3-4 (= 3.8.3-2) but 3.10.0-2 is to be
installed.
Depends: libevview3-3 (= 3.8.3-2) but 3.10.0-2 is to be installed.
The following actions will resolve these dependencies:
Remove the following packages:
1) evince
2) gnome
3) gnome-core
Leave the following dependencies unresolved:
4) epiphany-browser recommends evince
vs.
121-73-239-129:/home/ctillman/aptitude-0.6.8.3/src# aptitude -P -o
'Aptitude::ProblemResolver::Remove-Level=10001' full-upgrade
gir1.2-evince-3.0
The following packages will be upgraded:
gir1.2-evince-3.0 libevdocument3-4 libevview3-3
3 packages upgraded, 0 newly installed, 0 to remove and 364 not upgraded.
Need to get 0 B/1,934 kB of archives. After unpacking 85.0 kB will be used.
The following packages have unmet dependencies:
evince : Depends: libevdocument3-4 (= 3.8.3-2) but 3.10.0-2 is to be
installed.
Depends: libevview3-3 (= 3.8.3-2) but 3.10.0-2 is to be installed.
The following actions will resolve these dependencies:
Upgrade the following packages:
1) evince [3.8.3-2 (now) - 3.10.0-2 (testing)]
2) evince-common [3.8.3-2 (now) - 3.10.0-2 (testing)]
I tried to prepare a one-line patch with quilt, as referenced in
http://raphaelhertzog.com/2011/07/04/how-to-prepare-patches-for-debian-packages/
but I only got one .dsc file instead of two. I'm attaching that and the
patch file quilt generated in debian/patches.
On Thu, Jan 30, 2014 at 10:01 PM, Axel Beckert a...@debian.org wrote:
Hi,
Vincent Lefevre wrote:
aptitude sometimes prefers to remove packages instead of upgrading.
Which is IMHO fine in general. I though must admit that it seems to do
that quite often in Debian Unstable.
Chris King wrote:
This is a very annoying behavior
In Debian Unstable, yes. But it is configurable behaviour, too:
Use
Aptitude::ProblemResolver::Remove-Level maximum;
or
Aptitude::ProblemResolver::Hints {
reject !~M :UNINST;
};
in your apt.conf and you're done.
The latter works better for this issue, but no more allows you to
choose solutions which remove packages unless you explicitly select
them for removal with - in the package list or on the commandline.
This can be annoying, too, and is totally unsuited for dist-upgrades
between two stable releases. It hence is _NOT_ a general solution, but
is very suitable for unattended upgrades of security upates.
aptitude-robot uses it for a while now.
The first variant is probably better suited for general use case, but
can still cause packages to not be upgraded at all due to conflicts
with obosolete packages which actually really should be removed. (I
think, this is one of the reasons why this issue is not trivial to fix
generally without regressions in other fields like dist-upgrades
between two stable releases.)
which Aptitude didn't exhibit a year or so ago.
Hrm, I would be curious which patch introduced that change...
Having to hit n twenty times before Aptitude decides to upgrade
one package rather than removing 50 is just silly.
... and not necessary at all, even without the above configuration.
Just type r on all (often suffices to do it only for some) packages
and hit . only afterwards. (I don't know by mind the commandline
keybindings for that -- these are for the TUI -- but typing ? on
the prompt may give you hints.)
Martin von Wittich wrote:
Could this be caused by packages that are not marked as automatically
installed?
In case of conflicts with newer packages, this is possible. But it's
rather seldom the case according to my experience.
Chris Tillman wrote:
I second (3rd? 4th?) this request.
You're also free to submit a patch!
Regards, Axel
Bug#570377: Held packages
I second (3rd? 4th?) this request. I upgraded to the latest 0.6.8.3 and it still does the same thing. Choice between 1) 48 removals or 2) 1 upgrade. I do have a lot of manually held packages as well, so I think Martin von Wittich might be on the right track. The worst part is that non-experienced users can trash their system quite easily. -- Chris Tillman Developer
Bug#604156: Me too
I just performed an upgrade from lenny to sketch and also ran into this problem. I'm attaching the related script excerpts. As mentioned, I successfully did dpkg-reconfigure sysv-rc afterwards, But at the end of the attachment is the list of still-obsolete conffiles which includes /etc/default/bluetooth ae42b399df9a58ce830427cd53705f49 obsolete /etc/init.d/bluetooth 72d771738fa8480c1ad8caade6889f93 obsolete /etc/bluetooth/rfcomm.conf 0a87d3eddd29683c1456688907e67b4f obsolete /etc/bluetooth/hcid.conf 8acc8583c7d040696a64584749092d20 obsolete Preparing to replace vim-tiny 1:7.1.314-3+lenny2 (using .../vim-tiny_2%3a7.2.445+hg~cb94c42c0e1a-1_i386.deb) ... Unpacking replacement vim-tiny ... Preparing to replace vim-common 1:7.1.314-3+lenny2 (using .../vim-common_2%3a7.2.445+hg~cb94c42c0e1a-1_i386.deb) ... Unpacking replacement vim-common ... dpkg: warning - unable to delete old directory `/usr/share/man/fr.UTF-8/man1': Directory not empty dpkg: warning - unable to delete old directory `/usr/share/man/fr.UTF-8': Directory not empty dpkg: warning - unable to delete old directory `/usr/share/man/it.ISO8859-1/man1': Directory not empty dpkg: warning - unable to delete old directory `/usr/share/man/it.ISO8859-1': Directory not empty dpkg: warning - unable to delete old directory `/usr/share/man/it.UTF-8/man1': Directory not empty dpkg: warning - unable to delete old directory `/usr/share/man/it.UTF-8': Directory not empty dpkg: warning - unable to delete old directory `/usr/share/man/pl.UTF-8/man1': Directory not empty dpkg: warning - unable to delete old directory `/usr/share/man/pl.UTF-8': Directory not empty dpkg: warning - unable to delete old directory `/usr/share/man/fr.ISO8859-1/man1': Directory not empty dpkg: warning - unable to delete old directory `/usr/share/man/fr.ISO8859-1': Directory not empty dpkg: warning - unable to delete old directory `/usr/share/man/pl.ISO8859-2/man1': Directory not empty dpkg: warning - unable to delete old directory `/usr/share/man/pl.ISO8859-2': Directory not empty ctillman@121-73-239-129:/usr/share/man$ ls -l fr.UTF-8/* fr.UTF-8/man1: total 0 fr.UTF-8/man7: total 0 fr.UTF-8/man8: total 0 ctillman@121-73-239-129:/usr/share/man$ ls -l it.UTF-8/* total 0 Unpacking replacement bluez-utils ... dpkg: warning - unable to delete old directory `/etc/bluetooth': Directory not empty ... 121-73-239-129:/var/cache/apt# aptitude safe-upgrade Reading package lists... Done ... Preparing to replace libstdc++6 4.3.2-1.1 (using .../libstdc++6_4.4.5-8_i386.deb) ... Unpacking replacement libstdc++6 ... Processing triggers for man-db ... perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LC_ALL = (unset), LANG = en_US.UTF-8 perl: warning: Falling back to the standard locale (C). /usr/bin/mandb: can't set the locale; make sure $LC_* and $LANG are correct are supported and installed on your system. manconv: can't set the locale; make sure $LC_* and $LANG are correct manconv: can't set the locale; make sure $LC_* and $LANG are correct manconv: can't set the locale; make sure $LC_* and $LANG are correct manconv: can't set the locale; make sure $LC_* and $LANG are correct manconv: can't set the locale; make sure $LC_* and $LANG are correct manconv: can't set the locale; make sure $LC_* and $LANG are correct manconv: can't set the locale; make sure $LC_* and $LANG are correct Setting up libstdc++6 (4.4.5-8) ... ... Selecting previously deselected package linux-image-2.6.32-5-686. Unpacking linux-image-2.6.32-5-686 (from .../linux-image-2.6.32-5-686_2.6.32-45_i386.deb) ... locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory Preparing to replace linux-image-2.6-686 2.6.26+17+lenny1 (using .../linux-image-2.6-686_2.6.32+29_i386.deb) ... Unpacking replacement linux-image-2.6-686 ... Preparing to replace udev 0.125-7+lenny3 (using .../archives/udev_164-3_i386.deb) ... locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory unrecognized command 'log-priority=0' Unpacking replacement udev ... ... Preparing to replace xserver-xorg 1:7.3+20 (using .../xserver-xorg_1%3a7.5+8+squeeze1_i386.deb) ... locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory dpkg: warning: obsolete option '--print-installation-architecture', please use '--print-architecture' instead. Unpacking replacement xserver-xorg ... dpkg: warning: obsolete option '--print-installation-architecture', please use '--print-architecture' instead. Preparing to replace xserver-xorg-video-apm 1:1.2.0-1 (using .../xserver-xorg-video-apm_1%3a1.2.2-2_i386.deb) ... Unpacking replacement xserver-xorg-video-apm ... Preparing to replace xserver-xorg-input-wacom
Bug#472264: Merge
I agree with Rudy, this should also merge with 459024. -- Chris (Toff) Tillman
Bug#472264: Incorrect email address
I just submitted some extra information using reportbug, but it wasn't correctly configured. My email address is [EMAIL PROTECTED], not [EMAIL PROTECTED] -- Chris (Toff) Tillman
