Re: Buster/lightdm - after locking screen, unlock prompt not visible
On 5/31/19 11:16 AM, Raj Kiran Grandhi wrote: > Hi, > > In a fresh install of Buster with XFCE desktop, locking the screen > blanks the monitor and the monitor enters a power save state. After > that, neither moving the mouse nor typing on the keyboard would turn > the monitor back on. > > Typing the password without any visual feedback (while the monitor > continues to be in the power save state) unlocks the screen and my > session is displayed normally. > > Also, switching to another VT when the monitor turns off and switching > back displays the unlock prompt normally. > > The closest I could find online was this: > https://bbs.archlinux.org/viewtopic.php?id=240200 wherein installing > the nouveau video driver appeared to have fixed the issue. However, > that solution is not applicable in my case as I have an integrated > intel graphics controller. > > Is anybody else experiencing this bug? Any workaround? > > Thanks, > Raj Kiran > > Hi, Raj. Behavior on my testing systems with Xfce desktop environment is exactly as you describe. I didn't think of it as a bug. There are lots of lightweight lockers which behave similarly -- presenting a blank screen, or perhaps a colored screen and awaiting password input without any kind of feedback until the correct password is entered and the desktop returns to normal. I'm grateful for your post. I had never bothered to switch terminals to see if it would have an effect. When I do so on these systems, I'm presented with a screen with a message which says that the system is locked and that I will be redirected to a login prompt in a few seconds. I hope this is useful. Thank you for your post, as I prefer using a prompt to typing my password at a blank screen. Regards, jp
Re: solved Re: Insertion of USB devices not being recognised.
On 06/27/2018 09:38 AM, terryc wrote: On Tue, 26 Jun 2018 21:57:33 +0200 deloptes wrote: terryc wrote: Mostly it is USB sticks for stuff to play/display on the TV & "noise device" what do you see in dmesg when you plug in the device? Nothing. that was the problem. it is hard to mount it if you don't know what /dev/sd?? it is and although I "know" what it should be, unless it is listed in dmesg, i can do nothing with it, What happens if you downgrade the kernel to the previous version? Same situation, but it lead me to an unwelcome diagnose. i extracted the machine and the back plane ports were working. so I went back t 9.0.6(?) and it was the same. The current diagnose is that the front usb ports have failed for data. they work fine for power(mobile phone charging), but not for data. Not impressed as the mobo is less than two years old. Thanks for the help My suggestion is late, and possibly not much of a contribution due to my not having read the entire thread. I have two motherboards which BIOS settings which allow the front-side USB ports to be set for charging only. Is there any possibility that such a setting is in effect on your motherboard? JP
Re: solved Re: Insertion of USB devices not being recognised.
On 06/28/2018 07:39 AM, terryc wrote: On Thu, 28 Jun 2018 08:21:16 + (UTC) Curt wrote: On 2018-06-28, terryc wrote: On Wed, 27 Jun 2018 12:27:30 -0400 Jape Person wrote: My suggestion is late, and possibly not much of a contribution due to my not having read the entire thread. I have two motherboards which BIOS settings which allow the front-side USB ports to be set for charging only. Is there any possibility that such a setting is in effect on your motherboard? Idea welcome and I'll check it out. The mobo manual talks about option to enable/disable individual usb ports, but the reason(s) for this to be the cause for is ??? They're a security threat. I was thinking about why it would switch off on my machine, but OTOH I was once directed to go around a office and remove all trhe floppy drives(when floppy drives = sneaker net) for the same reason. that was an interesting period of office politics. I thought you might have looked at the BIOS setup at some time and changed some settings with end result being that data was turned off on those ports. In some setups the default behavior of these ports is different when "legacy" is enabled and when it is not. Actually, the meaning of "legacy" wrt USB port behavior seems to vary among the manufacturers. I found that out the hard way once when I did a reset to default settings on one of the machines. On top of that, the two systems I mentioned have a wonky "GUI" BIOS setup program (yes, so you can use a frikkin' mouse) which seems to have a mind of its own. I would swear that there have been times when a recheck of my BIOS setup showed that a value had changed from my last intended setup. Whether that was a failure on my part to actually save the setting or error in the setup program itself is not clear. Why they did this GUI thing is beyond me, but I understand from the SimplyNUC people that Intel has informed them that they will soon discontinue use of this "feature". That may mean that it was too buggy to bother with, or that too many curmudgeons like me whined about it. JP
Re: systemctl reboot fails (doesn't reboot)
On 3/1/19 5:53 PM, Gian Carlo wrote: > Il 01/03/19 22:40, riveravaldez ha scritto: >> Hi, I'm on debian-testing (updated), and found this issue: >> >> $ systemctl reboot >> Failed to set wall message, ignoring: The name >> org.freedesktop.PolicyKit1 was not provided by any .service files >> Failed to reboot system via logind: The name >> org.freedesktop.PolicyKit1 was not provided by any .service files >> Failed to start reboot.target: The name org.freedesktop.PolicyKit1 was >> not provided by any .service files >> See system logs and 'systemctl status reboot.target' for details. >> >> $ systemctl status reboot.target >> reboot.target - Reboot >> Loaded: loaded (/lib/systemd/system/reboot.target; disabled; vendor >> preset: enabled) >> Active: inactive (dead) >> Docs: man:systemd.special(7) >> >> $ systemctl restart reboot.target >> Failed to restart reboot.target: The name org.freedesktop.PolicyKit1 >> was not provided by any .service files >> See system logs and 'systemctl status reboot.target' for details. >> >> But 'sudo reboot' worked. >> >> Any idea? > > >> $ systemctl reboot >> $ systemctl status reboot.target >> $ systemctl restart reboot.target > You are NOT root > >> But 'sudo reboot' worked. > After "sudo..." you are root > > Bye, > > gc > > I'm curious as to why $ systemctl restart reboot.target is being used. On my systems $ systemctl start reboot.target results in a request for the root password. (And results for failure to type it correctly for a remote system via SSH often gets you punished with a non-responsive SSH session on the terminal.) Am I misunderstanding the problem?
network-manager-openvpn GUI not keeping automatic VPN connection setting
I hope that subject line doesn't obfuscate the issue. I'm using Sid/testing with Xfce4 desktop environment, fully updated. openvpn 2.4.7-1 network-manager-openvpn 1.8.10-1 network-manager-openvpn-gnome 1.8.10-1 Using the GUI I set openvpn to connect automatically to a chosen VPN. I reboot. I do connect to the vpn I selected. However, an examination of the openvpn setting in the GUI indicates a different VPN locale. Subsequent reboots still connect me to the VPN I chose, but the indicator in the GUI still indicates that I have chosen a different VPN. For instance, I just selected the Atlanta, GA VPN in the interface, rebooted, logged in, and checked which VPN I was connected to. I'm connected to the Atlanta VPN, but the settings GUI says Finland! Not a serious problem, but an odd one, to say the least. I have no idea whether or not the following message which occurs at boot time is related in some way: [FAILED] Failed to start OpenVPN connection to update-systemd-resolved. See 'systemctl status openvpn@update-systemd-resolved.service' for details. Issuing the indicated command yields: ● openvpn@update-systemd-resolved.service - OpenVPN connection to update-systemd-resolved Loaded: loaded (/lib/systemd/system/openvpn@.service; enabled-runtime; vendor preset: enabled) Active: activating (auto-restart) (Result: exit-code) since Tue 2019-11-05 15:17:58 EST; 1s ago Docs: man:openvpn(8) https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage https://community.openvpn.net/openvpn/wiki/HOWTO Process: 4314 ExecStart=/usr/sbin/openvpn --daemon ovpn-update-systemd-resolved --status /run/openvpn/update-systemd-resolved.status 10 --cd /etc/openvpn --config /etc/ope> Main PID: 4314 (code=exited, status=1/FAILURE) Please excuse short wrap length. Since recent Thunderbird upgrade the client seems unable to write longer lines. Haven't looked into it, yet. Quite annoying, but a subject for another thread. Thanks!
apparent change in hostnames on LAN without admin intervention
Hi folks. Did I miss something? I've had 3 Sid/testing systems running on the same LAN behind the same router for just shy of 3 years. Their static IP addresses have always been issued by the DHCP server on the router. Everything has been copacetic among the systems, with local and outside name resolution working with no issue. A little over a week ago the systems stopped being able to access each other by name. No changes were made in the settings or firmware of the router or of the local network settings on the systems. I discovered that all of the hostnames had changed from xx.local to xx. I've tried to determine the cause of this alteration in the hostnames on the LAN. Everything is working fine now that I've stopped trying to call the systems by the old xx.local names. Could this change be due to recent upgrades in software? (I upgrade every day.) I've reviewed the recent upgrades listed in /var/log/apt/history.log. I would have thought any deliberate change of this behavior would have been flagged by listchanges, but I can't find it. I'm just a home user / hobbyist, but this change occurring without any deliberate administrative action on my part makes the hairs stand up on my neck -- just a little bit. Advice or consolation would be welcomed. Thanks, JP
Re: apparent change in hostnames on LAN without admin intervention
On 12/13/19 8:55 PM, David Wright wrote: On Fri 13 Dec 2019 at 19:33:51 (-0500), Jape Person wrote: Hi folks. Did I miss something? Perhaps a couple of references: https://features.icann.org/addressing-new-gtld-program-applications-corp-home-and-mail which points out that any of .home, .mail and .corp are ideal for the domain name of a home LAN, and RFC 6762 on Multicast DNS which explains why .local is not a good choice. Thank you very much, David. I'll dig into the documentation. I could be quite wrong, but I thought that "local" was actually suggested as a domain name at one time by the installer. (And I could be remembering a different distro, though I've been using Debian for a long time -- at least 10 years, I think.) I suppose I just continued to use it over the years out of habit. I've had 3 Sid/testing systems running on the same LAN behind the same router for just shy of 3 years. Their static IP addresses have always been issued by the DHCP server on the router. Everything has been copacetic among the systems, with local and outside name resolution working with no issue. A little over a week ago the systems stopped being able to access each other by name. No changes were made in the settings or firmware of the router or of the local network settings on the systems. I discovered that all of the hostnames had changed from xx.local to xx. I've tried to determine the cause of this alteration in the hostnames on the LAN. Everything is working fine now that I've stopped trying to call the systems by the old xx.local names. Could this change be due to recent upgrades in software? (I upgrade every day.) I've reviewed the recent upgrades listed in /var/log/apt/history.log. I would have thought any deliberate change of this behavior would have been flagged by listchanges, but I can't find it. I'm just a home user / hobbyist, but this change occurring without any deliberate administrative action on my part makes the hairs stand up on my neck -- just a little bit. Advice or consolation would be welcomed. I tried .local quite a long while ago but it didn't work too well. I don't know where the problem lay, and I got along with no domain name for a longish period, but changed to .corp after I read the first reference above. It stopped exim4 complaining too. I have noticed that the speed of interactions (like logging on to ssh session, pinging, etc.) have improved since .local went away. But is it possible you've started using avahi/bonjour when previously you didn't? Or has the router upgraded itself and now knows not to issue names like that? I'll check to see if avahi/bonjour are being used, but I haven't done anything deliberately to start using them. I'm wondering if recent changes to CUPS may be implicated in some way. My Brother printer defaults to using bonjour, but I turned it off because I deemed it to be not particularly useful to me. It's connected by wire to the router. I live in a condo where I can see at least three dozen (no kidding) printers advertising their services. I'm getting ready to switch everything to wired connections. The router is a Luxul. Its firmware must be upgraded manually. It has been at the latest firmware version for almost a year. Perhaps others have more/better ideas. Cheers, David. Well, your ideas are certainly appreciated. I'm going to get a little education, I think, while I'm following up on your message. Best regards, JP
Re: apparent change in hostnames on LAN without admin intervention
On 12/14/19 1:24 AM, john doe wrote: Assuming that you are using the router from your ISP, it is possible that the firmware has been upgraded without your nolage. One way to prevent this could be (1), that is, use your own router/server/gateway so you control everything on your LAN. I use an EMTA modem only from my ISP which is plugged into a perimiter firewall. If you can't have an modem from your ISP, look at 'bridgemode'. If your not comfortable building your server from scratch, you can simply buy a router that is accepted by your ISP . In other words, you need to choose one or the other if you go this way: - Modem connected to router (most flexible of all) - Combo modem/router in one box (les flexible but is more compact) If you use DHCP static lease, you should look at what the DHCP server is providing as hostname and 'TLD', and also in the dhcp client (dhclient' to see what you get from the DHCP server. The file '/etc/resolv.conf' should let you know what TLD is sent from the DHCP server. Debian shouldn't modify your configuration files '/etc' without your nolage. Note that the TLD '.lan' is sometime used. 1) https://www.xfinity.com/support/articles/list-of-approved-cable-modems -- John Doe Hi, John Doe. I'm using my own router behind the modem provided by the ISP. I've never used a router provided by an ISP for controlling my network. I'm using a Luxul XWR-1750 which has been kept on the latest firmware available. Last upgrade was done early this year, long before the noted change in names. The router is set to provide static IP addresses and has the names of each of the systems associated with their MAC Addresses and IP Addresses. Thanks, JP
Re: apparent change in hostnames on LAN without admin intervention
On 12/14/19 4:40 AM, Curt wrote: On 2019-12-14, Jape Person wrote: I could be quite wrong, but I thought that "local" was actually suggested as a domain name at one time by the installer. (And I could be remembering a different distro, though I've been using Debian for a long time -- at least 10 years, I think.) I suppose I just continued to use it over the years out of habit. https://tools.ietf.org/html/rfc6762 3. Multicast DNS Names ... To remedy this problem [of home computer users generally lacking easy access to name creation in the global DNS namespace*], this document allows any computer user to elect to give their computers link-local Multicast DNS host names of the form: "single-dns-label.local". ... This document specifies that the DNS top-level domain ".local." is a special domain with special semantics, namely that any fully qualified name ending in ".local." is link-local, and names within this domain are meaningful only on the link where they originate. Has RFC 6762 been superseded? Or have I gotten this wrong? Hi, Curt. I'm doing some homework. I can see the error of my ways and am planning to change the network accordingly. Still stumped about why .local disappeared from the names, but am obviously not married to it. Thanks, JP
Re: apparent change in hostnames on LAN without admin intervention
On 12/14/19 3:56 AM, Andrei POPESCU wrote: On Vi, 13 dec 19, 19:33:51, Jape Person wrote: Hi folks. Did I miss something? I've had 3 Sid/testing systems running on the same LAN behind the same router for just shy of 3 years. Their static IP addresses have always been issued by the DHCP server on the router. Everything has been copacetic among the systems, with local and outside name resolution working with no issue. A little over a week ago the systems stopped being able to access each other by name. No changes were made in the settings or firmware of the router or of the local network settings on the systems. I discovered that all of the hostnames had changed from xx.local to xx. I've tried to determine the cause of this alteration in the hostnames on the LAN. Please provide more info on this, specifically where / how are the hostnames configured and where / how did you discover they changed. Do note that .local is typically used by mDNS and in my understanding it should not be used with a DNS server. https://en.wikipedia.org/wiki/.local Kind regards, Andrei Hi, Andrei. The hostnames and local domain name were used during installation. The static DHCP addresses are issued by a Luxul XWR-1750 router which associates the hostnames with the MAC and IP addresses. Contents of /etc/resolv.conf: search local nameserver 208.67.220.220 I discovered the change a few days ago when I was doing my daily check for updates by using SSH to connect to two of the systems. I received the following response to the connection command: ssh: Could not resolve hostname chip-nuc.local: Name or service not known I checked to make sure I could connect to everything by IP address, and I checked DNS on the outside world. Everything looked okay. On a hunch I tried omitting the .local from the connection command, and it work on each client. I figured any time the name of a client changes without deliberate action on the part of the network admin (however incompetent he may be), that could be a security issue. That's why I asked here. Thanks, JP
Re: apparent change in hostnames on LAN without admin intervention
On 12/14/19 8:02 AM, rhkra...@gmail.com wrote: On Friday, December 13, 2019 10:04:18 PM Jape Person wrote: Could this change be due to recent upgrades in software? (I upgrade every day.) I've reviewed the recent upgrades listed in /var/log/apt/history.log. I would have thought any deliberate change of this behavior would have been flagged by listchanges, but I can't find it. From the peanut gallery (I don't know why I sit here): Of course! That is the charm of sid / testing -- continuous changes, some of which might break your system. I'm just a home user / hobbyist, but this change occurring without any deliberate administrative action on my part makes the hairs stand up on my neck -- just a little bit. Well, I don't know why you're using testing (I don't), but I'm surprised your hairs on permanently up ;-) I've been using Sid/testing since long before I established this little network -- at least 12 or 13 years. I've always enjoyed seeing the changes to Debian as they come down the road. The worst problem I remember having was when the framebuffer was introduced. The nVidia graphics card I was running in my system at the time had to be appeased. Took maybe two hours to fix. But this made the old hackles raise because of the possibility that it could have security implications. It turns out that this problem has probably been caused by my own misunderstanding of proper use of naming conventions. Thanks, JP
Re: apparent change in hostnames on LAN without admin intervention
On 12/14/19 8:45 AM, Brian wrote: On Fri 13 Dec 2019 at 22:04:18 -0500, Jape Person wrote: On 12/13/19 8:55 PM, David Wright wrote: But is it possible you've started using avahi/bonjour when previously you didn't? Or has the router upgraded itself and now knows not to issue names like that? I'll check to see if avahi/bonjour are being used, but I haven't done anything deliberately to start using them. I'm wondering if recent changes to CUPS may be implicated in some way. Depends what you mean by recent. :) avahi-daemon has been a Recommends: of cups-daemon since jessie. My Brother printer defaults to using bonjour, but I turned it off because I deemed it to be not particularly useful to me. It's connected by wire to the router. I live in a condo where I can see at least three dozen (no kidding) printers advertising their services. I'm getting ready to switch everything to wired connections. Bonjour is a network protocol, not a wireless protocol. Thanks, JP
Re: apparent change in hostnames on LAN without admin intervention
On 12/15/19 1:19 AM, tv.deb...@googlemail.com wrote: ... Hi, I am running a very similar setup, also on Sid/Testing (updated daily), and didn't notice any change. My local domain is not ".local" or ".home", it is custom. My resolv.conf looks like yours (modulo the domain name), I have an additional nameserver line for my router address. My router only resolves names for the local network, public DNS is resolved though a VPN. My hosts file is just standard : one line per host on the network, the router has the same hosts file, the IP are reserved by the router DHCP and associated with (static spoofed) MAC addresses. Routers are running on Asuswrt-Merlin and openWRT (one is AP mode only). ssh here works with both hostnames short alias (no domain), full name or IP. works as expected and return the host IP. Since we probably have the same packages versions let me know if you need me to check anything that could differ from your system. Thank you very much for your kind offer! I am interested in figuring this out, but it will probably be at least after the first of the year before I'll be able to devote much time to it. I'm happy to have things apparently working as they should, for now. But this experience has made me curious. The information you provided, and your offer of help are much appreciated! Best, JP
Re: apparent change in hostnames on LAN without admin intervention
On 12/16/19 12:42 AM, David Wright wrote: On Sat 14 Dec 2019 at 13:49:25 (-0500), Jape Person wrote: On 12/14/19 1:24 AM, john doe wrote: ... The file '/etc/resolv.conf' should let you know what TLD is sent from the DHCP server. Debian shouldn't modify your configuration files '/etc' without your nolage. Depending on the packages chosen, /etc/resolv.conf is one file in /etc that is modified by Debian. The resolvconf package lists 23 other programs that it is designed to adjudicate between, for want of a better term. ... That has been my understanding, and it's why I never edit /etc/resolv.conf myself. Note that the TLD '.lan' is sometime used. That's another choice, like .local, that could always be issued as a real TLD at some point in the future. 1) https://www.xfinity.com/support/articles/list-of-approved-cable-modems I'm using my own router behind the modem provided by the ISP. I've never used a router provided by an ISP for controlling my network. I'm using a Luxul XWR-1750 which has been kept on the latest firmware available. Last upgrade was done early this year, long before the noted change in names. The router is set to provide static IP addresses and has the names of each of the systems associated with their MAC Addresses and IP Addresses. Can you just clarify this? My router provides static IP addresses on the basis of the MAC addresses, all the information being typed in¹ by me. It also lists the names of the other hosts, but only because those hosts told it their names. IOW the router (cheap, $35) doesn't issue hostnames, nor provide a DNS service itself. It also neither knows nor cares what the domain name of the network is. How much of this is the same on the router in your network? ¹ actually, of course, it deduces all but the last number in the dotted quad. Cheers, David. Yes, it's my understanding that my router does provide DNS on the local network and will provide the 208.67.222.222, 208.67.220.220 OpenDNS servers or whatever the ISP provides for DNS servers, depending upon entries made in its setup pages. I do not think that it actually issues the hostnames, but it does detect whatever hostnames the devices provide and shows them associated with the IP addresses its DHCP server issues in a table. Do you think that I'm misunderstanding the arrangement? Could well be. I have ASSumed that it worked this way from the appearance of the tables in the setup software. The software running the router is licensed under Luxul Open Source Code for Programmers (GPL). Thanks, David. JP
Re: apparent change in hostnames on LAN without admin intervention
On 12/16/19 11:39 AM, David Wright wrote: On Mon 16 Dec 2019 at 10:53:02 (-0500), Jape Person wrote: On 12/16/19 12:42 AM, David Wright wrote: On Sat 14 Dec 2019 at 13:49:25 (-0500), Jape Person wrote: On 12/14/19 1:24 AM, john doe wrote: ... The file '/etc/resolv.conf' should let you know what TLD is sent from the DHCP server. Debian shouldn't modify your configuration files '/etc' without your nolage. Depending on the packages chosen, /etc/resolv.conf is one file in /etc that is modified by Debian. The resolvconf package lists 23 other programs that it is designed to adjudicate between, for want of a better term. ... That has been my understanding, and it's why I never edit /etc/resolv.conf myself. Note that the TLD '.lan' is sometime used. That's another choice, like .local, that could always be issued as a real TLD at some point in the future. 1) https://www.xfinity.com/support/articles/list-of-approved-cable-modems I'm using my own router behind the modem provided by the ISP. I've never used a router provided by an ISP for controlling my network. I'm using a Luxul XWR-1750 which has been kept on the latest firmware available. Last upgrade was done early this year, long before the noted change in names. The router is set to provide static IP addresses and has the names of each of the systems associated with their MAC Addresses and IP Addresses. Can you just clarify this? My router provides static IP addresses on the basis of the MAC addresses, all the information being typed in¹ by me. It also lists the names of the other hosts, but only because those hosts told it their names. IOW the router (cheap, $35) doesn't issue hostnames, nor provide a DNS service itself. It also neither knows nor cares what the domain name of the network is. How much of this is the same on the router in your network? ¹ actually, of course, it deduces all but the last number in the dotted quad. Yes, it's my understanding that my router does provide DNS on the local network and will provide the 208.67.222.222, 208.67.220.220 OpenDNS servers or whatever the ISP provides for DNS servers, depending upon entries made in its setup pages. I do not think that it actually issues the hostnames, but it does detect whatever hostnames the devices provide and shows them associated with the IP addresses its DHCP server issues in a table. Do you think that I'm misunderstanding the arrangement? Could well be. I have ASSumed that it worked this way from the appearance of the tables in the setup software. The software running the router is licensed under Luxul Open Source Code for Programmers (GPL). Others will have to comment on the functionality provided by this software as I'm not familiar with it. But a table of names doesn't convince me that your router is providing a DNS service (or a domain name). My router maintains a list of names, but they're not strictly hostnames unless I edit them to be so. For example, when we bought our last Roku¹, it told the router it was called "ROKU PREMIEREPLUS - 964" which I edited to "rokupw²", the name by which I can ping it if I want to know whether it's powered up. Try typing $ nslookup chip-nuc 192.168.1.1 where 192.168.1.1 is the IP address for *your* router. ¹ a TV streamer. ² and "rokupe" for its ethernet interface. Cheers, David. Okay. I reset all of the hostnames on the network to avoid using improper names for the domain and to correct an issue where I would have had a user name and hostname being the same. I did what you suggested and got the following. $ nslookup hostname 192.168.0.1 Server: 192.168.0.1 Address:192.168.0.1#53 Name: hostname Address: 192.168.0.116 Note: I replaced the actual hostname with the word "hostname" in the example. Thanks, JP
Re: Gnucash broken after Update
On 12/16/19 12:41 PM, Markus Grunwald wrote: Hi, a few days ago, I ran an apt update of my debian/desting machine and got a new gnucash version. Apt DID tell me that there was something to do to keep gnucash working. I had no time to do that, then, but I was used to getting the instructions per e-mail. But at the time my e-mail setup was broken and I didn't notice. Bummer. Now I need to use gnucash and online banking is completely broken. I searched everywhere, found the hint in /usr/share/doc/aqbanking-tools/README.keyfile-update, but that didn't help... I /think/ the message had something to do with moved configuration files for gnucash, but am not sure. Do you have any hint for me? I urgendly need gnucash for my homebanking... TIA, I looked through my mailbox and found the following: --8<-- libaqbanking (5.99.43beta-2) unstable; urgency=medium Important notice for users upgrading from versions prior to 6.x === With AqBanking 6.x (including the preceding 5.99.x beta versions) the file location where AqBanking applications store their online banking related settings got changed again. Previously the AqBanking settings were stored in the directory ~/.aqbanking/settings/. After the upgrade settings are now stored in the directory ~/.aqbanking/settings6/. This means without manual interaction all the online banking account setup will be unavailable to the applications using it. Luckily a migration of the old settings to the new location is possible. Just copy all files from ~/.aqbanking/settings/ to ~/.aqbanking/settings6 cd ~/.aqbanking mkdir -p settings6 cp -r settings/* settings6 This should make the old online banking account settings available to the new library version. Updating the TAN methods to use for inline banking -- Due to legal changes (PSD2) most banks in Germany were forced to switch to a different TAN method for authorizing transactions. When upgrading from a libaqbanking version prior to 6.x, outdated TAN methods might still be cached in the library settings. Please follow these steps to update the TAN methods for your accounts after the upgrade: * in the online banking application open the settings dialog for AqBanking (varies, depending on the used application) * select the relevant user and click "Edit User" * in the dialog please click the "Get Bank Info" button (this will anonymously fetch the current bank and user parameter data from the bank's server) * in the dialog please click the "Get System Id" button (this will fetch a new system identifier and the list of allowed TAN modes from the bank's server) * after success, select a TAN method attributed with "Version 6" or higher * maybe close the dialog for now to open the "Edit User" dialog anew * in the dialog click the "Retrieve Account List" button (this will fetch the current account list from the bank's server, from now on TAN in version 6 will be used). In case you struggle with this update process, consider subscribing to the https://mailman.aqbanking.de/listinfo/aqbanking-user mailing list and ask for help (German and English language welcome). -- Micha Lenk Tue, 05 Nov 2019 21:15:06 +0100 --8<-- Is it helpful?
Re: apparent change in hostnames on LAN without admin intervention
On 12/16/19 3:25 PM, David Wright wrote: On Mon 16 Dec 2019 at 13:36:27 (-0500), Jape Person wrote: On 12/16/19 11:39 AM, David Wright wrote: On Mon 16 Dec 2019 at 10:53:02 (-0500), Jape Person wrote: On 12/16/19 12:42 AM, David Wright wrote: On Sat 14 Dec 2019 at 13:49:25 (-0500), Jape Person wrote: On 12/14/19 1:24 AM, john doe wrote: ... The file '/etc/resolv.conf' should let you know what TLD is sent from the DHCP server. Debian shouldn't modify your configuration files '/etc' without your nolage. Depending on the packages chosen, /etc/resolv.conf is one file in /etc that is modified by Debian. The resolvconf package lists 23 other programs that it is designed to adjudicate between, for want of a better term. ... That has been my understanding, and it's why I never edit /etc/resolv.conf myself. Note that the TLD '.lan' is sometime used. That's another choice, like .local, that could always be issued as a real TLD at some point in the future. 1) https://www.xfinity.com/support/articles/list-of-approved-cable-modems I'm using my own router behind the modem provided by the ISP. I've never used a router provided by an ISP for controlling my network. I'm using a Luxul XWR-1750 which has been kept on the latest firmware available. Last upgrade was done early this year, long before the noted change in names. The router is set to provide static IP addresses and has the names of each of the systems associated with their MAC Addresses and IP Addresses. Can you just clarify this? My router provides static IP addresses on the basis of the MAC addresses, all the information being typed in¹ by me. It also lists the names of the other hosts, but only because those hosts told it their names. IOW the router (cheap, $35) doesn't issue hostnames, nor provide a DNS service itself. It also neither knows nor cares what the domain name of the network is. How much of this is the same on the router in your network? ¹ actually, of course, it deduces all but the last number in the dotted quad. Yes, it's my understanding that my router does provide DNS on the local network and will provide the 208.67.222.222, 208.67.220.220 OpenDNS servers or whatever the ISP provides for DNS servers, depending upon entries made in its setup pages. I do not think that it actually issues the hostnames, but it does detect whatever hostnames the devices provide and shows them associated with the IP addresses its DHCP server issues in a table. Do you think that I'm misunderstanding the arrangement? Could well be. I have ASSumed that it worked this way from the appearance of the tables in the setup software. The software running the router is licensed under Luxul Open Source Code for Programmers (GPL). Others will have to comment on the functionality provided by this software as I'm not familiar with it. But a table of names doesn't convince me that your router is providing a DNS service (or a domain name). My router maintains a list of names, but they're not strictly hostnames unless I edit them to be so. For example, when we bought our last Roku¹, it told the router it was called "ROKU PREMIEREPLUS - 964" which I edited to "rokupw²", the name by which I can ping it if I want to know whether it's powered up. Try typing $ nslookup chip-nuc 192.168.1.1 where 192.168.1.1 is the IP address for *your* router. ¹ a TV streamer. ² and "rokupe" for its ethernet interface. Okay. I reset all of the hostnames on the network to avoid using improper names for the domain and to correct an issue where I would have had a user name and hostname being the same. I did what you suggested and got the following. $ nslookup hostname 192.168.0.1 Server: 192.168.0.1 Address:192.168.0.1#53 Name: hostname Address: 192.168.0.116 Note: I replaced the actual hostname with the word "hostname" in the example. My understanding is that you do have a DNS server in the router then, so you could avoid having to maintain lists of hostnames and IP addresses on any of the other hosts if the router is always on. I assume you can expand this to include the domain name, because the default dhclient.conf appears to ask for it from the dhcp server. But I certainly prefer to have each host know its own hostname and domain name before it configures the network, and IIRC the default Debian configuration is to put 127.0.1.1 hostname.domain hostname into /etc/hosts which ensures this. Understood. I have my /etc/hosts files set that way, and I add a list of domains I want blocked to these files as well. I can't really help with what changed and when, but can only point out that people who've used .local seem to report intermittent behaviour in various forums that google has turned up. Cheers, David. Understood. I have had "weirdness" on this network for quite a w
Re: Graphical indicators for Caps Lock and similar keys
On 1/17/20 7:27 PM, Tom Browder wrote: I have a laptop, running Debian 10 (Buste) with the Mate desktop. Unfortunately the laptop doesn't have light indicators on the keyboard for keys such as: CapLock, NumLock, Insert, etc. Is there any way to get a graphical indicator on a docking bar to show their status? Thanks, -Tom I don't know whether or not gkrellm-leds would work for you. Last time I tried it I found it to look at little out of place on my Xfce4 desktop, but it did perform some of the functions you're looking for. (I don't think it had an insert indicator, but my memory could be wonky.)
Re: Graphical indicators for Caps Lock and similar keys
On 1/18/20 1:19 PM, Tom Browder wrote: On Fri, Jan 17, 2020 at 8:55 PM Jape Person wrote: I don't know whether or not gkrellm-leds would work for you. Last time I tried it I found it to look at little out of place on my Xfce4 desktop, but it did perform some of the functions you're looking for. (I don't think it had an insert indicator, but my memory could be wonky.) I installed the package but didn't see any changes. And I saw no easy way to affect my panels. As a result, I removed that package and installed the 'mate-tweak' package, as suggested by Curt, and that does work, at least for the Caps and Num lock keys. I would like to try your suggestion if you can tell me how to actually implement it--I am no longer familiar with the text settings for desktop tweaks, but I am comfortable with such changes with clear instructions. -Tom To get to the configuration dialog you have to right-click on the frame of the application and choose Configure. (You can also get the dialog by placing the mouse over the gkrellm application and hitting the F1 key. Reading the man pages will give you and overview of functionality, and digging into the configuration user interface will let you set it up to suit you. If you just install gkrellm-leds it will pull in a couple of other packages (gkrellm and libgnutls-openssl27). when you start it you'll see a lot of stuff that you probably don't want. You have to go into configuration and turn off each of the displays that you don't want. If you want gkrellm to show only the LEDs, this is quite a bit of work to get just that. But it does work. It would require several pages of e-mail to explain the process, but it's obvious enough if you dig into the Configuration dialog pages and tabs for each item. JP
Re: Graphical indicators for Caps Lock and similar keys
On 1/18/20 2:32 PM, Darac Marjal wrote: On 18/01/2020 02:54, Jape Person wrote: On 1/17/20 7:27 PM, Tom Browder wrote: I have a laptop, running Debian 10 (Buste) with the Mate desktop. Unfortunately the laptop doesn't have light indicators on the keyboard for keys such as: CapLock, NumLock, Insert, etc. Is there any way to get a graphical indicator on a docking bar to show their status? Thanks, -Tom I don't know whether or not gkrellm-leds would work for you. Last time I tried it I found it to look at little out of place on my Xfce4 desktop, but it did perform some of the functions you're looking for. (I don't think it had an insert indicator, but my memory could be wonky.) If you're using XFCE, you might find https://goodies.xfce.org/projects/panel-plugins/xfce4-kbdleds-plugin more to your taste. The code is a bit old, but still works well. This give you a panel plugin with a simple "cns" where each letter gets capitalised and given a green background when the appropriate lock is on. Thanks, Darac. I looked at that page, but it appears that the download links are not working. Even if they were working, I'm not sure I'd want to try to install something that old. There have been a lot of changes to the Xfce4 panel since that plugin was last updated. In any case, I'm switching to wired keyboards with indicators this weekend, so it's a moot point for me. JP
Re: XFCE4 - gedit - was Re: Thanks
On 09/01/2013 02:22 AM, Joel Rees wrote: ... > > I've been looking at geany, and it looks interesting functionally, but > I'm not at all sold on it. Don't like lots of tool panes all over. > It's part of the reason I can't quite bring myself to use either > netbeans or eclipse regularly. > ... As an aside, thought I'd mention that geany's interface is very highly configurable. It's easy enough through the Preferences dialog to eliminate side panes, bottom panes, etc. -- or to relocate them. You can make this editor's interface as simple as mousepad's. JP -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52234747.6070...@comcast.net
You can have any color you want - as long as it's Gnome?
Heh. Just being a little tongue-in-cheek here. I needed to do a fresh installation of Debian on two systems for friends this weekend. I tried both stable (7.1) and the 10/02/2013 daily of testing -- both of them the netinst image. For both stable and testing I tried both LXDE and Xfce desktop environment installations. But when the systems rebooted, I was at the Gnome desktop. (Partying, barbecue, and our wives and children were involved -- so I wasn't watching the process as closely as I might have, otherwise.) While doing routine upgrades on my own systems I had run into a situation somewhat related and reported by someone else at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718855. Okay. So I installed Debian testing without a DE, and then tried to add xfce-desktop via aptitude. I saw that I was still going to get Gnome and canceled the operation. So, I just added xfce and lightdm packages and then added other stuff a piece at a time until I got both systems configured. This wasn't a huge deal for me, but I'm pretty sure that no newcomers to the Debian distribution are installing Xfce or LXDE from a daily image of testing or from the stable image. (I didn't try KDE. Maybe it works because, surely, it doesn't use network-manager-gnome.) >From my perspective, it looks to me as though the problem is network-manager-gnome's desire to install gnome-control-center. Xfce and LXDE both want network-manager-gnome, so they also get gnome-control-center, gnome-session, and just about everything else gnome-like. For such an annoying bug, it seems like this has been around for quite some time. It might not be serious to Xfce per se, but I'd think the Debian community would be concerned about it. People trying new installations aren't being given the choices advertised in the d-i. Or am I missing something? Anyway, friends and I had lots of time to drink because of the extra time required for installations -- so not such a bad thing for us. But for those reading this list, maybe this report may not be as lucid as one could hope for! ;-) Jape -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5251ac8f.9040...@comcast.net
Re: You can have any color you want - as long as it's Gnome?
On 10/06/2013 05:33 PM, david...@ling.ohio-state.edu wrote: On Sun, 6 Oct 2013, Jape Person wrote: For both stable and testing I tried both LXDE and Xfce desktop environment installations. But when the systems rebooted, I was at the Gnome desktop. you do not mention the display manager. at login, did the display manager's login dialog box not offer you a choice of DE? is it possible that it did offer you a choice (via, say, a drop-down menu or something), with gnome pre-selected as the default? No, I suppose I should have mentioned that. The default choice (from lightdm) was "default xsession". The only other choice in the dropdown on the login was gnome. I didn't see Xfce listed at all. I think that was on the stable installations. I didn't even check when I saw gnome pop up after logging on on the subsequent attempts to install LXDE or Xfce stable or testing installations. I just started over, because I didn't want to leave these folks with systems that had so much extraneous stuff on them. I mean, it was hundreds of megabytes, not just a few packages. It was the whole gnome DE. While doing routine upgrades on my own systems I had run into a situation somewhat related and reported by someone else at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718855. it kinda sounds like you ran into the *identical* situation. but without knowing what options the display manager offered you, i guess i shouldn't be too certain. hth, wes ps: i did a recent install for a friend, as well, and i believe we ran into bug #718855, too. it does break the principle of least surprise, but it did not prevent us from selecting an xfce session from the display manager. (at least, i don't *think* i had to do anything more fu-intensive than select xfce from a drop-down in the DM greeter. memory is a little fuzzy.) That's very interesting. On the early installations done this weekend I added some software from within aptitude in TTY1 before trying to log on. I wonder if that variable had anything to do with the difference. I did not test the dropdown on all cases, just the first. I assumed that the subsequent ones would be the same. Gnome was there, and I didn't want it to be there. Still, even if one were to be given the choice of logging on to an Xfce session, how many people would be happy with this outcome of the installation process? I mean, I guess most people go with LXDE or Xfce because they don't want something as big as gnome or kde sitting on their systems. Of course, I don't try to extrapolate from the behavior of my own testing installations wrt bugs because I fiddle mightily with them. I installed them early in the Squeeze testing cycle, and set sources.list to use testing instead of the current testing name ever since. So, they just roll right over to the new testing when it comes along. I'm used to seeing occasional breakage on them, like when framebuffer came along and nv went away. Those systems get updated at least once a day, and I add and subtract reams of packages frequently for testing purposes. But I've never seen them go through something quite as ugly as this. It wasn't hard to fix, but I'm sure it would really mess up a new user. Attempting to get a clean Xfce and / or LXDE installation from both stable and testing and getting hundreds of megabytes of gnome is just weird. I can see how it happens, but I wouldn't think that the Xfce or LXDE maintainers would be very happy about it. Yet I don't see any comments from them on the bug report. If I get time this week I may just do some testing of the installation process to confirm what I remember. (Remember, lots of wine, lots of food, lots of screaming kids...) Anyway, looks like Debian is aware of it. Thank you for your observation. It's given me something to mull over. Jape -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52520f0c.3050...@comcast.net
Re: You can have any color you want - as long as it's Gnome?
On 10/07/2013 10:02 AM, Curt wrote: On 2013-10-07, Curt wrote: With the wheezy netinstaller you simply choose 'Advanced Options' on the first page you're presented with, then 'Alternative desktop environments," then 'Xfce.' No Gnome. With this version of the netinstaller at least that's the way it's done: debian-wheezy-DI-rc1-amd64-netinst.iso The problem is that what you describe does not work as expected, according to the OP. I followed the procedure described above, installing to a usb key, and when I booted the usb key I was in the desktop environment of my choice and not in Gnome. But I can't remember whether I chose Xfce or LXDE (but he said for the both of them he ended up in Gnome). So what I described worked as expected for me (I think--I didn't check to see whether all of Gnome got installed somehow behind my back). Anyhoo, the plot sickens. Actually, rereading his post, I don't see him saying he followed the procedure I followed anywhere; rather he says he installed testing without a DE, then tried to install a lightweight desktop with aptitude, so this is something of time-waster, isn't it? apt-get --no-install-recommends No? Hi, Just to be sure you don't misunderstand me -- I did use the alternative desktop choices in the installer, and the expert installation procedure. I tried allowing installation of both the lxde and xfce desktops on different installs. In both cases, I would up with a default login to the gnome desktop. I then tried installing without a DE. Any attempt to install task-xfce-desktop was going to bring gnome onto the system. Installing only the xfce package plus lightdm plus xfce-goodies turned out to be the way to go. But trying to install network-manager-gnome, again, brings in the whole gnome DE unless you don't install recommends. The only reason I wanted these folks to have network-manager-gnome is that it's currently the only easy way for regular end users to use and configure a variety of VPN software. I also didn't want to wind up with a bunch of manual package installs that would hang around if they decided to drop network-manager for something like Wicd (which, unfortunately, does not yet support VPN connections from its GUI). These folks are sophisticated enough to want to use VPN connections when they're connecting to public wireless locations. They just don't know enough about package management to sort this sort of thing out for themselves. I wanted to leave them with systems they could reconfigure easily for themselves. What "wes" is suggesting is that I might have missed the possibility that Xfce was still being offered, just not as the default Xsession. I don't think that's what happened in this case, but I had already messed with the installations from TTY1 before logging in from the lightdm prompt. So, it's possible that I did something to cause Xfce to be missing from the dropdown selection. It's possible -- We had baskets of wine. Our wives (the responsible ones) weren't watching us carefully, and we had worked out way down to the cooking sherry in the kitchen by the time the installations had begun. (This was not a serious undertaking. It was some buddies setting up some spare Debian boxes for two of the families to experiment with, so we weren't taking notes.) The bug report clearly states that Xfce is still available after an installation, but that Gnome comes up as the default choice. That -- with the possible exception of the availability of Xfce -- is certainly what I saw. I also saw exactly the same behavior with an attempted LXDE installation. You installed the OS to a key. I can't imagine why, but maybe d-i behaves a bit differently in this respect when installing to a key??? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5252c89a.6090...@comcast.net
Re: You can have any color you want - as long as it's Gnome?
On 10/07/2013 09:37 AM, david...@ling.ohio-state.edu wrote: On Sun, 6 Oct 2013, Jape Person wrote: On 10/06/2013 05:33 PM, david...@ling.ohio-state.edu wrote: On Sun, 6 Oct 2013, Jape Person wrote: For both stable and testing I tried both LXDE and Xfce desktop environment installations. But when the systems rebooted, I was at the Gnome desktop. [snip] is it possible that [the display manager at login] did offer you a choice (via, say, a drop-down menu or something), with gnome pre-selected as the default? No, I suppose I should have mentioned that. The default choice (from lightdm) was "default xsession". The only other choice in the dropdown on the login was gnome. I didn't see Xfce listed at all. okay, i see. interesting. that is more misbehavior than is reported thus far at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718855 . the absence of Xfce from the DM selections---that is missing from the report. the report just says Xfce isn't the default selection in lightdm. I hope that is actually the case. I am sober now and not kibbitzing with my buddies, but don't have much time. If I can get some free time I'll try again with my eyes open and taking notes for a possible contribution to the bug report. I say I hope that is the case, because that would mean that a new user could install one of these lightweight environments and just deal temporarily with the dross until the package management / dependency issues are fixed, at which time the upgrade process might offer to remove gnome during an upgrade. Of course, that would probably confuse the heck out of 'em, too, wouldn't it? I think that was on the stable installations. I didn't even check when I saw gnome pop up after logging on on the subsequent attempts to install LXDE or Xfce stable or testing installations. I just started over, because I didn't want to leave these folks with systems that had so much extraneous stuff on them. I mean, it was hundreds of megabytes, not just a few packages. It was the whole gnome DE. yeah, i hear you. ps: i did a recent install for a friend, as well, and i believe we ran into bug #718855, too. it does break the principle of least surprise, but it did not prevent us from selecting an xfce session from the display manager. (at least, i don't *think* i had to do anything more fu-intensive than select xfce from a drop-down in the DM greeter. memory is a little fuzzy.) That's very interesting. On the early installations done this weekend I added some software from within aptitude in TTY1 before trying to log on. I wonder if that variable had anything to do with the difference. i'll have to pay better attention on my next install, and take some notes. whatever i did[1], i ended up with a wheezy installation with both gnome and Xfce selectable from the display manager. I'm inclined to think that -- if one of us did something unusual to the clean installation -- it was probably me. The, ah, neurological manifestations of fermented grape and the social dynamics (wise-asses and wisecracks) could not have been conducive to precise use of the CLI and aptitude following those initial installations. i aimed for variety over minimalism, i made no effort to exclude gnome, and in fact was happy to have it included. however, like you say... Still, even if one were to be given the choice of logging on to an Xfce session, how many people would be happy with this outcome of the installation process? I mean, I guess most people go with LXDE or Xfce because they don't want something as big as gnome or kde sitting on their systems. yeah, definitely. for installations valuing minimalism over variety, bringing in gnome would not be a welcome side effect at all. Yup. Attempting to get a clean Xfce and / or LXDE installation from both stable and testing and getting hundreds of megabytes of gnome is just weird. totally agree. btw, i don't see LXDE mentioned in bug 718855. speaking of which,... Yeah, and that definitely happened. The LXDE installation was done by a friend with some sysadmin experience taking directions from me. I watched him do the Expert installation of lxde properly, and we got a Gnome desktop the first time he logged in from lightdm. I can see how it happens, but I wouldn't think that the Xfce or LXDE maintainers would be very happy about it. Yet I don't see any comments from them on the bug report. well, so far it looks like http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718855 talks about how installing Xfce brings in gnome, and fails to make Xfce the default session selection. i don't see any mention there about the DM omitting Xfce as a session choice. and i see no mention of LXDE at all, though the lxde package recommends network-manager-gnome as well. Yeah, I really hope to get some time to check this out. Still, wouldn't you think the
Re: You can have any color you want - as long as it's Gnome?
On 10/07/2013 03:10 AM, Oliver Fairhall wrote: Thanks for posting on this Jape. I'm new to Debian (preparing to install soon) and will likely be caught by this. Hope it's OK to ask some newby questions. If you don't mind getting (possibly) dumb answers. ;-) I want a light weight DE, and was thinking to use XFCE (been fine on my other distros). I'm at best an intermediate level with Linux, so will likely struggle with not installing Gnome (really don't want Gnome or KDE). On 07/10/13 02:31, Jape Person wrote: > From my perspective, it looks to me as though the problem is > network-manager-gnome's desire to install gnome-control-center. Xfce and LXDE > both want network-manager-gnome, so they also get gnome-control-center, > gnome-session, and just about everything else gnome-like. Is it possible to not install network-manager-gnome when installing Debian with XFCE? I've bypassed the network manager in Ubuntu in the past, running on a desktop machine, and just configured network access by text file anyway. Not sure if that would make things awkward on a laptop connecting to different wireless sites. Are all these Gnome packages real dependencies for network-manager-gnome, or are they just selected by some other means? Is there an alternative network manager for XFCE, and can one be selected during initial installation? Thanks for any help. Cheers, Oli There are a lot of alternatives, but the decision tree for getting through the choices may not be easy for you unless you know just what you want. You don't get to pick-and-choose which network manager you want with which DE -- not during the d-i process. The easiest way to manage this is to *not* install the desktop environment. I'm not sure, but that may require that you use the Expert install procedure. I just don't know. I've never used the regular procedure. Anyway, if you uncheck the Desktop environment installation at software installation selection time, you'll wind up following the reboot at TTY1 -- simply because no GUI has been installed. You will then have to log in as root (or use sudo if you elected during installation not to allow login as root) to install the DE in a somewhat piecemeal fashion. Here's my somewhat disjointed notes on what got installed from aptitude on TTY1: * Desktop Environment and Desktop Manager * xfce4 * lightdm * xfce4 enhancements * xfce4-goodies * xfce4-power-manager * xfce4-mixer * xfce4-terminal * xfce text editor * mousepad * office applications * libreoffice-gtk * xfce inter-application / inter-system communications * dbus-x11 * support for scanners * xsane * media players * parole (standard Xfce choices applications for this are vlc and quodlibet) * pdf viewer * evince-gtk * icon theme * tango-icon-theme * network management * wicd (replacement for standard Xfce choice, network-manager-gnome, which has dependency issues right now) * package management * synaptic I'm pretty sure a lot of that (after xfce4, lightdm, and xfce-goodies) was pulled in automatically by xfce4. Exceptions would be libreoffice-gtk, parole (or vlc and quodlibet), evince-gtk, wicd, synaptice (not sure about this one). Wicd is an easy-to-use network manager that I think suits Xfce better than network-manager-gnome, but network-manager-gnome has plugins for using VPNs though its graphical interface, and that's a very valuable thing to have. I'll probably go back to those systems this weekend, rip out wicd, and put in network-manager-gnome, but with only selected recommends. We were just too tired and dumb at the end of installations to be in a pick-and-choose mode. So, you could try using apt-get or aptitude or synaptic to install network-manager-gnome without the recommends and just add the ones you need manually. The only disadvantage to this is that manually installed packages don't get cleaned up by package management when you remove whatever it was you installed them to support. *Or* if it turns out that Xfce is actually usable from the login screen after the installer finishes installing it and all of the gnome stuff, you could just use it and let gnome sit there until (we hope) aptitude / synaptic offers to remove it when task-xfce-desktop gets upgraded to a version that doesn't want all of the gnome stuff any more. As I've said elsewhere in the thread, we just started over from scratch and went with Xfce only because we really, really didn't want gnome on these systems. I hope this is helpful. I think we can probably count on the Debian xfce / lxde maintainers to figure out a fix in a reasonable amount of time, so just going with the flow may work for you. On the other hand, the only slightly harder path that I outlined isn't
Re: You can have any color you want - as long as it's Gnome?
On 10/07/2013 11:37 AM, Paul Cartwright wrote: On 10/07/2013 10:43 AM, Jape Person wrote: These folks are sophisticated enough to want to use VPN connections when they're connecting to public wireless locations. They just don't know enough about package management to sort this sort of thing out for themselves. I wanted to leave them with systems they could reconfigure easily for themselves. I never thought about that.. so if I'm away from home on an unsecure network, I could setup a VPN at home, tunnel in, and use that as securely as I do sitting at home.. I never considered that, but I might now! Or you can use something like the riseup.net VPN (if you're a member) or a commercial VPN in the same situation. Easy to set up a bunch of them, and pick and choose among them when you're out and around. I hope a lot of people start doing this sort of thing. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5252da37.50...@comcast.net
Re: You can have any color you want - as long as it's Gnome?
On 10/07/2013 09:37 AM, david...@ling.ohio-state.edu wrote: On Sun, 6 Oct 2013, Jape Person wrote: On 10/06/2013 05:33 PM, david...@ling.ohio-state.edu wrote: On Sun, 6 Oct 2013, Jape Person wrote: For both stable and testing I tried both LXDE and Xfce desktop environment installations. But when the systems rebooted, I was at the Gnome desktop. [snip] is it possible that [the display manager at login] did offer you a choice (via, say, a drop-down menu or something), with gnome pre-selected as the default? No, I suppose I should have mentioned that. The default choice (from lightdm) was "default xsession". The only other choice in the dropdown on the login was gnome. I didn't see Xfce listed at all. okay, i see. interesting. that is more misbehavior than is reported thus far at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718855 . the absence of Xfce from the DM selections---that is missing from the report. the report just says Xfce isn't the default selection in lightdm. I think that was on the stable installations. I didn't even check when I saw gnome pop up after logging on on the subsequent attempts to install LXDE or Xfce stable or testing installations. I just started over, because I didn't want to leave these folks with systems that had so much extraneous stuff on them. I mean, it was hundreds of megabytes, not just a few packages. It was the whole gnome DE. yeah, i hear you. ps: i did a recent install for a friend, as well, and i believe we ran into bug #718855, too. it does break the principle of least surprise, but it did not prevent us from selecting an xfce session from the display manager. (at least, i don't *think* i had to do anything more fu-intensive than select xfce from a drop-down in the DM greeter. memory is a little fuzzy.) That's very interesting. On the early installations done this weekend I added some software from within aptitude in TTY1 before trying to log on. I wonder if that variable had anything to do with the difference. i'll have to pay better attention on my next install, and take some notes. whatever i did[1], i ended up with a wheezy installation with both gnome and Xfce selectable from the display manager. i aimed for variety over minimalism, i made no effort to exclude gnome, and in fact was happy to have it included. however, like you say... Still, even if one were to be given the choice of logging on to an Xfce session, how many people would be happy with this outcome of the installation process? I mean, I guess most people go with LXDE or Xfce because they don't want something as big as gnome or kde sitting on their systems. yeah, definitely. for installations valuing minimalism over variety, bringing in gnome would not be a welcome side effect at all. Attempting to get a clean Xfce and / or LXDE installation from both stable and testing and getting hundreds of megabytes of gnome is just weird. totally agree. btw, i don't see LXDE mentioned in bug 718855. speaking of which,... I can see how it happens, but I wouldn't think that the Xfce or LXDE maintainers would be very happy about it. Yet I don't see any comments from them on the bug report. well, so far it looks like http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718855 talks about how installing Xfce brings in gnome, and fails to make Xfce the default session selection. i don't see any mention there about the DM omitting Xfce as a session choice. and i see no mention of LXDE at all, though the lxde package recommends network-manager-gnome as well. It wasn't hard to fix, but I'm sure it would really mess up a new user. sure would. definitely. If I get time this week I may just do some testing of the installation process to confirm what I remember. sounds good. same here. one way or another, it looks like the bug report could use some supplementary info. Thank you for your observation. It's given me something to mull over. likewise. see you at the bug report. cheers, wes [1] hmm. now, thinking it over in the light of day, i might well have apt-gotten the xfce4 package from a console, post-installation, and then cherry-picked other Xfce packages that looked useful. maybe. whatever it was, i now doubt it was whatever a new user would be likely to do. Just returning with info on this matter. I just finished an expert install (sober, and without my hilarious friends) with the Debian 7.1 netinst image we used this past weekend on a test system and was able to get Xfce *only*, so the grape certainly must have got us on that one. However, an attempt to install the daily testing netinst image with Xfce (dated 10/02) definitely got Gnome as the default desktop, albeit with Xfce available in the dropdown. I didn't have time to test any other combinations like lxde testing, but I strongly suspect that its dependence upon network-manager-gnome would en
Re: aptitude misconfigure?
On 10/26/2013 01:18 AM, Glenn English wrote: There are several Debian machines around, and some of them do an odd thing in Aptitude: lqk xReally quit Aptitude?x x [ Yes ][ No ] x mqj and others don't. Can anyone tell me what I did to make some of them do that to their ncurses boxes? Aptitude is the only place I've seen this (yet), and I've played with locales and googled and looked at man pages -- no joy. It has something to do with the VT-100 'graphics' chars, I think, but I can't figure out how to fix it... TIA Hi, Check the Preferences dialog in aptitude. This feature is controlled by the item: [] Prompt for confirmation at exit Jape -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/526bc164.8030...@comcast.net
Re: aptitude misconfigure?
On 10/26/2013 11:09 AM, Chris Bannister wrote: On Sat, Oct 26, 2013 at 09:19:32AM -0400, Jape Person wrote: On 10/26/2013 01:18 AM, Glenn English wrote: There are several Debian machines around, and some of them do an odd thing in Aptitude: lqk xReally quit Aptitude?x x [ Yes ][ No ] x mqj and others don't. Can anyone tell me what I did to make some of them do that to their ncurses boxes? Aptitude is the only place I've seen this (yet), and I've played with locales and googled and looked at man pages -- no joy. It has something to do with the VT-100 'graphics' chars, I think, but I can't figure out how to fix it... TIA Hi, Check the Preferences dialog in aptitude. This feature is controlled by the item: [] Prompt for confirmation at exit LOL, I believe he is referring to the strange characters! OIC. I guess I am the strange character in this case. The term "locales" should have been a hint. And I thought I had a chance to be useful -- as something other than comic relief, I mean. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/526be11a.1040...@comcast.net
Re: aptitude misconfigure?
On 10/26/2013 02:33 PM, Glenn English wrote: On Oct 26, 2013, at 9:34 AM, Jape Person wrote: On 10/26/2013 11:09 AM, Chris Bannister wrote: On Sat, Oct 26, 2013 at 09:19:32AM -0400, Jape Person wrote: On 10/26/2013 01:18 AM, Glenn English wrote: There are several Debian machines around, and some of them do an odd thing in Aptitude: lqk xReally quit Aptitude?x x [ Yes ][ No ] x mqj and others don't. Can anyone tell me what I did to make some of them do that to their ncurses boxes? Aptitude is the only place I've seen this (yet), and I've played with locales and googled and looked at man pages -- no joy. It has something to do with the VT-100 'graphics' chars, I think, but I can't figure out how to fix it... TIA Hi, Check the Preferences dialog in aptitude. This feature is controlled by the item: [] Prompt for confirmation at exit LOL, I believe he is referring to the strange characters! OIC. I guess I am the strange character in this case. The term "locales" should have been a hint. And I thought I had a chance to be useful -- as something other than comic relief, I mean. My apologies for being unclear, but comic relief is always welcome. I'm fairly certain that I am the only person participating in the thread who is "unclear". ;-) Yes, it's the strange characters that I'm asking for help with: What makes Aptitude build dialog boxes out of lower case letters (see above in original post, from a Wheezy box) instead of lines (see below, approximately, from a Lenny box)? And how can I get to do lines instead? ┌─┐ │Really quit Aptitude?│ │ [ Yes ][ No ] │ └─┘ I looked for the Aptitude prefs before in /etc but couldn't find them. It didn't occur to me that they were in the CTL-T menus. I didn't see anything in there that might help... Morten Bo Johansen made the only other reasonable suggestion that occurs to me. But your question is interesting to me because I'm certain that I've seen this behavior before -- but with box drawing characters being messed up in installation scripts rather than in aptitude's ncurses interface. I think we should know which DE / WM / terminal emulator you are using. I have been poking around in my testing / Xfce environment and don't seem to be able to find a way to make this happen, though I think I could manage if I changed locale settings and / or fiddled around with dependencies enough. I'm sure you were right to first suspect locale settings. It's really the most obvious culprit. Are those the same for the systems that have the problem and those that don't? I'm looking forward to seeing what you learn about this. As I said, I know I've seen the behavior before and have been mystified by it, but only briefly because it went away (IIRC) after a reboot. Jape -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/526c267d.9090...@comcast.net
Re: aptitude misconfigure?
On 10/26/2013 07:46 PM, Glenn English wrote: On Oct 26, 2013, at 2:30 PM, Jape Person wrote: I'm sure you were right to first suspect locale settings. It's really the most obvious culprit. Are those the same for the systems that have the problem and those that don't? In all, "egrep -v ^# /etc/locale.gen" says "en_US.UTF-8 UTF-8". I'm looking forward to seeing what you learn about this. As I said, I know I've seen the behavior before and have been mystified by it, but only briefly because it went away (IIRC) after a reboot. Well, I'll be damned! That grep returned the same string on all but the Lenny box -- and on that one, the only difference was that it said the same thing twice. I looked at the file on Lenny, and the locale was un-commented out at place up in the long list of commented out choices, and it was added as a last line. I edited on one of the Wheezy boxes, and the locale choice was only the last line. So I found it (commented out) up in the list, removed the '# ' and rebooted. And Aptitude got well. I have no explanation whatsoever for this, but thanks very much for your suggestion. And I thought weird stuff like this only happened to me. ... OK. I give up. I just spent the afternoon doing the same things on the other Wheezy boxes (directly from their consoles), and some of the locale.gen files were one way, and some weren't; after editing, sometimes Aptitude worked from the console, and sometimes it got worse. Then I went back to the Mac and restarted the terminal program on the Mac and re-established the ssh connections, and now they're all OK from the Mac. They weren't from their consoles. And ssh'ing around between them gave various results. Last time I looked. If somebody has a possible explanation for this, I'd sure like to hear it. But unless I do, I'm just going to assume that Aptitude makes its dialog boxes from character sets selected at random and stop whining about it. As long as it does the rest of its job reasonably well, I can live with cosmetic problems... Well, that's odd. I'm afraid the only non-GNU/Linux systems at my disposal are Windows systems that I herd (like cats) for a client. But I do manage a bunch of Debian testing systems -- some locally and some remotely by ssh connection -- and none of them has exhibited an odd display in aptitude's interactive user interface. (It's how I handle system upgrades on all of the Debian systems, so I see it daily.) Besides the lack of a Mac in the mix, the other difference in my systems from yours is the lack of Lenny or Wheezy in the mix. (Yup, my Debian systems are all the same version, testing.) But I have seen the substitution of textual characters for line-drawing characters on some TUI dialogs in the past. I'm pretty sure it always happened during software upgrades. I didn't remark when or in exactly what circumstances because it didn't persist. Still, I'm tempted to think the cause for what you are seeing might be related. I'll watch with interest. Best, Jape -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/526c69e7.50...@comcast.net
Re: Creating forlders in Gnome Shell 3.12 without Gnome Software
On 10/02/2014 10:17 AM, Wash-N-Go wrote: On Thu, 2 Oct 2014, filorin wrote: Hi there ! howdy, pardner. I spent too much time on the Internet to find how to create folders in Gnome Shell. i gather you did not intend to reply to the thread regarding security cameras. i imagine, instead, that you meant to begin a new thread. perhaps you thought replying to a message sent to the security camera thread, while changing the subject line, would be sufficient to do this. but lo, check out the other headers of your message, and behold the failure of your email client to divine your intent: | References: <54251582.30...@mousecar.com> | <1411718732.5963.0@Kingston2> | <20140926081730.GJ1289@sid.nuvreauspam> | <54268211.2020...@mousecar.com> | <20140930231128.GF3774@sid.nuvreauspam> | <542b5280.20...@attglobal.net> | <20141001074234.GH3774@sid.nuvreauspam> | <542bb206.6070...@gmail.com> <542bf160.2090...@mousecar.com> | <542bfcd9.2010...@attglobal.net> <542c164b.2070...@mousecar.com> | | | In-Reply-To: good email clients pay attention to these headers, and consequently, your desperate plea for aid in mastering the use of gnomish software is buried deep, deep within a thread regarding security cameras. down here, only callous libertarian cattlemen and suspicious laundromat proprietors can hear your cries (and, i suppose, people whose email clients don't understand threads). what this means for you: basically, only people who really, really care (as in, like, twenty-two messages' worth of devotion) about security cameras will see your message. for some reason, the thing you just did is called hijacking a thread. but it would be better to say that you let the thread hijack *you*. if i were you, i would start over. send a new message to the list, not a reply. happy trails. -wes At the beginning, there was a simple methode, This was the highlight of my day. I needed a chuckle. Thank you for being kind, considerate, and funny in your response to filorin. Now I shall return to lurking mode, where I spend most of my time wishing more of us had a kinder sense of humor. Best, Jape -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/542d6346.4090...@comcast.net
Re: XFCE4 Power Manager Brightness Panel Plugin
On 10/06/2014 10:49 AM, Lars Noodén wrote: I've got xfce4-power-manager 1.4.1-1 in xfce4 on jessie and would like to find a way to dim the LCD backlight. I'm not seeing a brightness panel anywhere like this one: http://docs.xfce.org/xfce/xfce4-power-manager/brightness nor does the backlight respond to the usual shortcut keys for dimming. What needs to be added or configured to get a brightness slider or other brightness control for the backlight? Regards, /Lars I think at this version they switched from using a notification area applet for the power manager and eliminated the old display brightness applet from the items available for the panel. Try adding xfce4-power-manager-plugins to the panel. You should see a display brightness setting in the menu you get when you left-click on this item in the panel. There should also be a checkbox on the Xfce Power Manager dialog's Display tab that might re-enable your display brightness buttons. HTH, Jape -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5432e253.8010...@comcast.net
Re: XFCE icons disappeared on Jessie
On 10/06/2014 03:02 PM, Ximo wrote: Hello, After a Jessie update icons of same themes disappeared on XFCE 4.10. On XFCE Settings > Appearance > Icons I've tried GNOME, HighContrast and Tango. The only that works is HighContrast. Maybe it's a problem with libgdk-pixbuf2.0-0, but I'm not sure. Could you help me, please? Thanks. Best regards, I've tried to reproduce this problem on four systems running Debian testing with Xfce4 and couldn't see it. What I have seen of late is that icons in /some/ gtk-based applications show up as high contrast icons, rather than whatever they've been set to in the Icons tab. But I gather that what you're seeing in this regard is rather more far spread -- all applications, even Thunar? Do you have both gtk2-engines-xfce and gtk3-engines-xfce and gtk2-engines-pixbuf installed? (I'm no expert at this, but have just seen aberrations in icon and theme behaviors with /some/ of my themes and icon sets when these aren't installed. Jape -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5432feeb.5010...@comcast.net
Re: XFCE icons disappeared on Jessie
On 10/07/2014 03:06 PM, Ximo wrote: El 06/10/14 a las #4, Jape Person escribió: On 10/06/2014 03:02 PM, Ximo wrote: Hello, After a Jessie update icons of same themes disappeared on XFCE 4.10. On XFCE Settings > Appearance > Icons I've tried GNOME, HighContrast and Tango. The only that works is HighContrast. Maybe it's a problem with libgdk-pixbuf2.0-0, but I'm not sure. Could you help me, please? Thanks. Best regards, I've tried to reproduce this problem on four systems running Debian testing with Xfce4 and couldn't see it. What I have seen of late is that icons in /some/ gtk-based applications show up as high contrast icons, rather than whatever they've been set to in the Icons tab. But I gather that what you're seeing in this regard is rather more far spread -- all applications, even Thunar? Do you have both gtk2-engines-xfce and gtk3-engines-xfce and gtk2-engines-pixbuf installed? (I'm no expert at this, but have just seen aberrations in icon and theme behaviors with /some/ of my themes and icon sets when these aren't installed. Jape Hi, It happens in all applications even in Thunar. I've checked the packages that you told me and every thing looks fine. Just in case it could be a clue, I get this in ~/.xsession-errors --- Begin --- Xsession: X session started for xnadal at mar oct 7 20:44:50 CEST 2014 localuser:xnadal being added to access control list openConnection: connect: No existe el fichero o el directorio cannot connect to brltty at :0 /usr/bin/startxfce4: X server already running on display :0 xfce4-session-Message: ssh-agent is already running; starting gpg-agent without ssh support ** (polkit-gnome-authentication-agent-1:1312): WARNING **: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. ** (nm-applet:1315): WARNING **: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. nm-applet:1315): Gtk-WARNING **: Theme parsing error: gtk.css:102:18: Not using units is deprecated. Assuming 'px'. (nm-applet:1315): Gtk-WARNING **: Theme parsing error: gtk.css:102:20: Not using units is deprecated. Assuming 'px'. (nm-applet:1315): GLib-GObject-WARNING **: The property GtkButton:use-stock is deprecated and shouldn't be used anymore. It will be removed in a future version. (nm-applet:1315): GLib-GObject-WARNING **: The property GtkSettings:gtk-button-images is deprecated and shouldn't be used anymore. It will be removed in a future version. ... --- End --- Thanks. BR, There's nothing unusual (at least on my systems) about the ssh-agent and polkit-gnome-authentication-agent errors present in ~/.xsession-errors. I don't know about the nm-applet errors because I don't use network-manager-gnome, preferring to use wicd or just do without a network manager instead. However, I do see Gtk warnings and GLib-GObject warnings of those types all the time when running applications from the terminal on remote systems, so I'm guessing that none of these messages is pertinent to your problems. It's really hard for me to see how a problem with the nm-applet could cause your icons to go bonkers. I'm sorry to say I don't have anything else to suggest -- other than possibly removing, purging, and then re-installing the icon themes. That might help if an installation or upgrade process which affected the icon themes was interrupted or failed in some other way. I assume you're not holding back any packages with your package manager and are fully updated on this system. Holding back the versions on certain libraries (or using stuff from outside repositories / sources) might break certain elements of the DE, but I'd expect that to have an effect on other things like window decorations and so on, too. I use aptitude (in interactive mode) as my package manager, with an occasional use of apt-get for special purposes. I'm one of those weirdos who upgrades every one of his personal systems every day and uses the word "testing" instead of the release code name in his /etc/apt/source.list file, so I'm used to seeing a little minor breakage now and then, but it's almost always very easy to figure out what's wrong and fix it if it's a configuration issue -- or to learn that the problem is caused by a transition that will soon be fixed by an upgrade. I have to say, though, that your problem seems a bit more like something outside of the usual "things breaking in testing" scenario. It almost
Re: XFCE4 Power Manager Brightness Panel Plugin
On 10/09/2014 07:13 AM, Lars Noodén wrote: On 10/06/2014 09:41 PM, Jape Person wrote: On 10/06/2014 10:49 AM, Lars Noodén wrote: ... What needs to be added or configured to get a brightness slider or other brightness control for the backlight? ... I think at this version they switched from using a notification area applet for the power manager and eliminated the old display brightness applet from the items available for the panel. Try adding xfce4-power-manager-plugins to the panel. You should see a display brightness setting in the menu you get when you left-click on this item in the panel. I've also got xfce4-power-manager-plugins 1.4.1-1 installed. Adding it to the panel gives me only battery status. So when you left-click on that applet's icon in the panel, the only thing displayed in the menu dropdown is the battery status? I get an indicator for the main battery, the battery on the wireless mouse, the battery on the wireless keyboard, a Display Brightness slider bar, a checkbox for Presentation Mode, and a line called "Power Manger settings..." which brings up the Xfce Power Manager dialog. There should also be a checkbox on the Xfce Power Manager dialog's Display tab that might re-enable your display brightness buttons. ... I've rummaged around there again. There are four tabs in the power manager dialog (general, system, display, devices) and though some can turn off the screen or put the machine into hibernate or suspend, none seem to offer the option of changing the display brightness. Maybe it's in another package. On the Display tab of the Xfce Power Manager dialog I have a checkbox fo "Handle display power management which has set of sliders under it for controlling the timing for blanking, sleeping, and switching off. Under that is a section called Brightness reduction which the timing and degree of brightness reduction of the panel for "on battery" and "plugged in" status. There are so many possible issues to look for. I mean there is the question of dependencies and recommends, then the involvement of acpi / acpid, upower, and polkit. If I had this problem, I'd start aptitude in interactive (ncurses) mode and examine each involved entity to see if all of its recommends were present on the system. Regards, /Lars I'm sorry I haven't been able to help. Regards, Jape -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54369376.7030...@comcast.net
Who is systemd-gpt-auto-generator, and why does s/he not like my partition table?
Hi, folks! Sorry about the title. I'm just addicted to movie titles from the 60s. (-: I am seeing this during the boot sequence on a Debian testing installation. Sometimes it is actually left showing on TTY1 after the DM (lightdm in this case) comes up, and sometimes not. From TTY1 ... systemd-gpt-auto-generator[152]: Failed to determine partition table type of /dev/sda: Input/output error ... So, I checked dmesg: From dmesg ...[4.853751] systemd-gpt-auto-generator[154]: Failed to determine partition table type of /dev/sda: Input/output error [4.854298] systemd[151]: /lib/systemd/system-generators/systemd-gpt-auto-generator failed with error code 1. ... and later on ... [12650.204616] systemd-gpt-auto-generator[7555]: Failed to determine partition table type of /dev/sda: Input/output error ... I looked in the BTS and couldn't even find a package named systemd-gpt-auto-generator, much less a bug that had been filed for it. I guess it's a routine or function name? The drive came originally from Lenovo (T520i) with and MSDOS parititon table. I just used the standard partition scheme provided by the netinst d-i (testing), so there are only /dev/sda1 and the swap partition present. I used ext4 as the file system. I'm also having the drive checked by smartmontools at boot time and have received no warnings. In addition, I run "fsck -Cfat ext4" on the drive at boot time every week with no untoward signs. This has been happening for a couple of weeks, and I haven't seen any odd behaviors from the system. Nevertheless, I thought I ought to check to see if anyone thinks this is likely to indicate that I'm about to get bit in the butt. It would also be nice to know why I'm seeing this only on this particular system and not on any of the other three systems with very similar Debian testing installations on them. Thanks! Jape -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543e813a.5040...@comcast.net
Re: Who is systemd-gpt-auto-generator, and why does s/he not like my partition table?
On 10/15/2014 11:34 AM, Sven Joachim wrote: On 2014-10-15 16:14 +0200, Jape Person wrote: I am seeing this during the boot sequence on a Debian testing installation. Sometimes it is actually left showing on TTY1 after the DM (lightdm in this case) comes up, and sometimes not. From TTY1 ... systemd-gpt-auto-generator[152]: Failed to determine partition table type of /dev/sda: Input/output error ... So, I checked dmesg: From dmesg ...[4.853751] systemd-gpt-auto-generator[154]: Failed to determine partition table type of /dev/sda: Input/output error [4.854298] systemd[151]: /lib/systemd/system-generators/systemd-gpt-auto-generator failed with error code 1. ... and later on ... [12650.204616] systemd-gpt-auto-generator[7555]: Failed to determine partition table type of /dev/sda: Input/output error ... I looked in the BTS and couldn't even find a package named systemd-gpt-auto-generator, much less a bug that had been filed for it. I guess it's a routine or function name? It's a program that is part of the systemd package. See the manpage for what it does. Ah, thanks for that! Looking in the systemd manpage hadn't occurred to me. Duh! It would also be nice to know why I'm seeing this only on this particular system and not on any of the other three systems with very similar Debian testing installations on them. Can you please show your /etc/fstab file and the output of "fdisk -l /dev/sda" ? /etc/fstab: # /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). # # # / was on /dev/sda1 during installation UUID=7ffec658-3f62-4b7c-b944-bb60bc257b83 / ext4 errors=remount-ro 0 1 # swap was on /dev/sda5 during installation UUID=e44c4b27-a764-4fcc-b4f8-a1d1d7542fd7 noneswapsw 0 0 /dev/sr0/media/cdrom0 udf,iso9660 user,noauto 0 0 Hmm. I haven't edited this file on this system. I have usually removed references to optical drives in the past. Maybe that entry (/dev/sr0) is why I've been hearing the optical drive get activated once-in-a-while on this system. output of "# fdisk -l /dev/sda": Disk /dev/sda: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xe553ae0a Device Boot Start End Blocks Id System /dev/sda1 *2048 943697919 471847936 83 Linux /dev/sda2 943699966 976771071165355535 Extended /dev/sda5 943699968 97677107116535552 82 Linux swap / Solaris Cheers, Sven Thank you for taking an interest! Jape -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543e9a91.3000...@comcast.net
Re: Who is systemd-gpt-auto-generator, and why does s/he not like my partition table?
On 10/15/2014 11:53 AM, Don Armstrong wrote: On Wed, 15 Oct 2014, Jape Person wrote: From dmesg ...[4.853751] systemd-gpt-auto-generator[154]: Failed to determine partition table type of /dev/sda: Input/output error [4.854298] systemd[151]: /lib/systemd/system-generators/systemd-gpt-auto-generator failed with error code 1. ... and later on ... [12650.204616] systemd-gpt-auto-generator[7555]: Failed to determine partition table type of /dev/sda: Input/output error ... I looked in the BTS and couldn't even find a package named systemd-gpt-auto-generator, much less a bug that had been filed for it. I guess it's a routine or function name? It's part of systemd; it generates rules to mount partitions from GPT partition tables without needing to express them in /etc/fstab. [See man systemd-gpt-auto-generator for details.] Now that's weird, or maybe it's just me. I tried to look for manpages for systemd-gpt-auto-generator, and I'd swear I was told "No manual entry for..." Sven Joachim told me to check the manpages, and I looked at man systemd, which gave me an online reference for "Generators Specifications" which wasn't helpful at all. But I'm now seeing documentation when I type "man systemd-gpt-auto-generator", so I'm guessing I made a typo earlier on and didn't even notice in the output from the man request. The drive came originally from Lenovo (T520i) with and MSDOS parititon table. I just used the standard partition scheme provided by the netinst d-i (testing), so there are only /dev/sda1 and the swap partition present. I used ext4 as the file system. I'm also having the drive checked by smartmontools at boot time and have received no warnings. You're basically not supposed to get I/O errors on drives like that. I'd try running smartctl -a /dev/sda; or similar just to see whether any errors have occured on the drive. It's possible that there's a bad sector early on which is only exposed when something tries to find a gpt partition table, or it could be a bug in systemd-gpt-auto-generator which your particular setup is triggering. You might be able to trigger it with gdisk -l /dev/sda; or similar, too. I checked with smartctl and was told the test completed without error. There were no errors in the log at all. However, the output from the gdisk command was: GPT fdisk (gdisk) version 0.8.10 Partition table scan: MBR: MBR only BSD: not present APM: not present GPT: not present *** Found invalid GPT and valid MBR; converting MBR to GPT format in memory. *** Disk /dev/sda: 976773168 sectors, 465.8 GiB Logical sector size: 512 bytes Disk identifier (GUID): 43493272-B516-4A14-95E5-BF0E895243CB Partition table holds up to 128 entries First usable sector is 34, last usable sector is 976773134 Partitions will be aligned on 2048-sector boundaries Total free space is 6125 sectors (3.0 MiB) Number Start (sector)End (sector) Size Code Name 12048 943697919 450.0 GiB 8300 Linux filesystem 5 943699968 976771071 15.8 GiB8200 Linux swap I can see the words "invalid GPT and valid MBR" in that report, but -- save for the sizes and locations pertinent to the different disks -- this is exactly the same output that command gives me on my other systems. Do you see anything significant? If not, I'll try my hand at filing a severity minor bug against systemd to see if the maintainers think anything of it. If that doesn't turn up anything useful, file a bug against systemd, and ask the maintainers what additional debugging information you can provide. [It's probably severity minor, since this particularly failure isn't going to hurt anything.] I thought I ought to check to see if anyone thinks this is likely to indicate that I'm about to get bit in the butt. I'd make sure that I had my backups in order, but that's really just out an abundance of caution. Yup. I'm meticulous about backup strategy and practice. I'm retired, so I have plenty of time to implement it. I never allow myself any excuses. Thank you for your suggestions. Jape -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543ea384.6090...@comcast.net
Re: Who is systemd-gpt-auto-generator, and why does s/he not like my partition table?
On 10/15/2014 01:38 PM, Don Armstrong wrote:
On Wed, 15 Oct 2014, Sven Joachim wrote:
I don't think there is actually an I/O error here, looking at the code
systemd-gpt-auto-generator makes this error up:
,
| errno = 0;
| r = blkid_probe_lookup_value(b, "PTTYPE", &pttype, NULL);
| if (r != 0) {
| if (errno == 0)
| errno = EIO;
| log_error("Failed to determine partition table type of %s:
%m", node);
| return -errno;
`
Somebody who is familiar with libblkid (i.e. not me) might explain why
blkid_probe_lookup_value() apparently failed but did not set errno.
Great catch. Yeah, blkid_probe_lookup_value apparently just returns -1
on all errors, regardless of what the error was.
This is probably a bug in systemd-gpt-auto-generator, but upstream (and
the maintainer) would know much more than I.
Thank you, both!
I'll see if I can file a cogent bug report.
Please let me know if you have particular suggestions about that.
Jape
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543ec0d2.8030...@comcast.net
Re: Who is systemd-gpt-auto-generator, and why does s/he not like my partition table?
On 10/15/2014 02:45 PM, Jape Person wrote:
On 10/15/2014 01:38 PM, Don Armstrong wrote:
On Wed, 15 Oct 2014, Sven Joachim wrote:
I don't think there is actually an I/O error here, looking at the code
systemd-gpt-auto-generator makes this error up:
,
| errno = 0;
| r = blkid_probe_lookup_value(b, "PTTYPE", &pttype, NULL);
| if (r != 0) {
| if (errno == 0)
| errno = EIO;
| log_error("Failed to determine partition table type of %s:
%m", node);
| return -errno;
`
Somebody who is familiar with libblkid (i.e. not me) might explain why
blkid_probe_lookup_value() apparently failed but did not set errno.
Great catch. Yeah, blkid_probe_lookup_value apparently just returns -1
on all errors, regardless of what the error was.
This is probably a bug in systemd-gpt-auto-generator, but upstream (and
the maintainer) would know much more than I.
Thank you, both!
I'll see if I can file a cogent bug report.
Please let me know if you have particular suggestions about that.
I filed a bug report -- 765...@bugs.danubian.org -- a few minutes ago.
I'm sorry if this is a duplicate notification. I accidentally sent the
original from the wrong e-mail account and wanted to be sure you knew
that Jape (nickname) and Jim were the same person.
Again, thank you Sven and Don, for your help.
Jape
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543fc52e.5010...@comcast.net
Re: Avoiding SystemD isn't hard
On 10/21/2014 09:22 PM, Miles Fidelman wrote: Don Armstrong wrote: On Tue, 21 Oct 2014, Miles Fidelman wrote: which is immediately followed by completely inaccurate information, including: -- "With jessie, it will become /easier/ to choose the init system, because *neither init system is essential now*. Instead, there is an essential meta-package "init", which requires you to install one of systemd-sysv | sysvinit-core | upstart. In other words, you have more choice than ever before." This statement is actually correct; until this change it was not possible to completely replace sysvinit with another init system without running dpkg-divert commands to divert the init away. ok. When, in fact, there IS no way to prevent systemd from being installed during installation (except for upgrades). That preseeding doesn't do this is a bug, it's filed (#668001), and the patch for it was just written on Friday the 17th. Because Debian is going to freeze in less than three weeks, the maintainers are wary of applying this patch this close to release without extensive testing. Furthermore, the effect of this patch is trivially obtained by using a late_command to remove systemd-sysv and install sysvinit-core. except for the various reported issues with all the things aptitude wants to remove when you try this (I really hate unwinding highly entangled dependencies). If you actually want to see this patch applied to the version of the Debian installer that Jessie will release with, you should coordinate with the nice people in #debian-boot to see what type of testing they would want to see before they are willing to vet the patch. Good point - will see how receptive they are. Which leaves the only option being to install, with systemd, then follow the instructions in https://randomstring.org/blog/blog/2014/10/14/removing-systemd-from-a-debian-jessie-system/ |# apt-get install sysv-rc sysvinit-core sysvinit-utils # apt-get purge systemd libpam-systemd systemd-sysv This is the wrong command to run. You want: aptitude install sysvinit-core systemd-sysv-; Removing libpam-systemd and systemd something depends on them isn't useful; they don't determine what the init system is, after all. seems like we could use some definitive instructions on how to actually do this; we now have: https://lists.debian.org/debian-user/2014/09/msg00969.html and https://randomstring.org/blog/blog/2014/10/14/removing-systemd-from-a-debian-jessie-system/ (where I copied the above instructions from) followed by: https://lists.debian.org/debian-user/2014/09/msg00998.html and now your comments above - plus the various bug reports about how to avoid mass uninstallations by aptitude (e.g., https://lists.debian.org/debian-devel/2014/10/msg00409.html) A distinct lack of clarity, given the TC resolution about expecting Jessie to support multiple init systems, but not actually having a clearly defined way to do anything except hack until one gets things to work. Miles Fidelman I haven't paid a lot of attention to threads concerning systemd because of the (unfortunate, though occasionally entertaining) hyperbole and innuendo employed by so many of the involved parties. I mostly despaired of finding anything substantive in the various threads. But I'm glad you (and Don Armstrong) have been among the more reasonable participants in the argument. I was wondering if either of you -- or anyone else -- has tried the init-select package to see if it is actually able to avoid adverse effects upon the installed software while allowing the user (presumably someone with root privs) to select among init systems. That would be nice, wouldn't it? I intend to look at it this weekend, if I can find some time for a little project. I'm guessing that it's pretty basic, and maybe not meant for use on systems with DEs, DMs, WMs, and lots of GUI user applications installed on them. It it works for those, then the author truly deserves congratulations. I hope everyone finds a way to get a system configuration s/he can live with happily! -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54478f2c.8010...@comcast.net
Re: Avoiding SystemD isn't hard
On 10/22/2014 07:41 AM, Martin Steigerwald wrote: Am Mittwoch, 22. Oktober 2014, 07:04:12 schrieb Jape Person: On 10/21/2014 09:22 PM, Miles Fidelman wrote: Don Armstrong wrote: On Tue, 21 Oct 2014, Miles Fidelman wrote: which is immediately followed by completely inaccurate information, including: -- "With jessie, it will become /easier/ to choose the init system, because *neither init system is essential now*. Instead, there is an essential meta-package "init", which requires you to install one of systemd-sysv | sysvinit-core | upstart. In other words, you have more choice than ever before." This statement is actually correct; until this change it was not possible to completely replace sysvinit with another init system without running dpkg-divert commands to divert the init away. ok. When, in fact, there IS no way to prevent systemd from being installed during installation (except for upgrades). That preseeding doesn't do this is a bug, it's filed (#668001), and the patch for it was just written on Friday the 17th. Because Debian is going to freeze in less than three weeks, the maintainers are wary of applying this patch this close to release without extensive testing. Furthermore, the effect of this patch is trivially obtained by using a late_command to remove systemd-sysv and install sysvinit-core. except for the various reported issues with all the things aptitude wants to remove when you try this (I really hate unwinding highly entangled dependencies). If you actually want to see this patch applied to the version of the Debian installer that Jessie will release with, you should coordinate with the nice people in #debian-boot to see what type of testing they would want to see before they are willing to vet the patch. Good point - will see how receptive they are. Which leaves the only option being to install, with systemd, then follow the instructions in https://randomstring.org/blog/blog/2014/10/14/removing-systemd-from-a-d ebian-jessie-system/>>> |# apt-get install sysv-rc sysvinit-core sysvinit-utils # apt-get purge systemd libpam-systemd systemd-sysv This is the wrong command to run. You want: aptitude install sysvinit-core systemd-sysv-; Removing libpam-systemd and systemd something depends on them isn't useful; they don't determine what the init system is, after all. seems like we could use some definitive instructions on how to actually do this; we now have: https://lists.debian.org/debian-user/2014/09/msg00969.html and https://randomstring.org/blog/blog/2014/10/14/removing-systemd-from-a-debi an-jessie-system/ (where I copied the above instructions from) followed by: https://lists.debian.org/debian-user/2014/09/msg00998.html and now your comments above - plus the various bug reports about how to avoid mass uninstallations by aptitude (e.g., https://lists.debian.org/debian-devel/2014/10/msg00409.html) A distinct lack of clarity, given the TC resolution about expecting Jessie to support multiple init systems, but not actually having a clearly defined way to do anything except hack until one gets things to work. Miles Fidelman I haven't paid a lot of attention to threads concerning systemd because of the (unfortunate, though occasionally entertaining) hyperbole and innuendo employed by so many of the involved parties. I mostly despaired of finding anything substantive in the various threads. But I'm glad you (and Don Armstrong) have been among the more reasonable participants in the argument. I was wondering if either of you -- or anyone else -- has tried the init-select package to see if it is actually able to avoid adverse effects upon the installed software while allowing the user (presumably someone with root privs) to select among init systems. That would be nice, wouldn't it? I intend to look at it this weekend, if I can find some time for a little project. I'm guessing that it's pretty basic, and maybe not meant for use on systems with DEs, DMs, WMs, and lots of GUI user applications installed on them. It it works for those, then the author truly deserves congratulations. I hope everyone finds a way to get a system configuration s/he can live with happily! I did, as did a co-worker of mine. It appears to be basically working, but not always does what I would expect from it. So I reported some bug reports about it: init-select init-select adds sysvinit while systemd already there https://bugs.debian.org/762558 init-select: assumes systemd is default while its not https://bugs.debian.org/762578 http://bugs.debian.org/init-select shows one other bug regarding functionality: init-select: Offers not installed inits, confusing error messages, unhelpfull description https://bugs.debian.org/759031 Thats not much so far, I wonder whether many people test this. A co-worker of mine tested with openrc, but there was a problem on boot with openrc. It hung on some service
Re: Avoiding SystemD isn't hard
On 10/22/2014 02:42 PM, Doug wrote: On 10/22/2014 07:04 AM, Jape Person wrote: /snip/ I haven't paid a lot of attention to threads concerning systemd because of the (unfortunate, though occasionally entertaining) hyperbole and innuendo employed by so many. . . . innuendo--isn't that the Italian word for enema? /snip ...or suppository... One of my favorite jokes. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54480a52.3080...@comcast.net
Re: Problem with external monitor
On 10/30/2014 01:02 PM, Curt wrote: On 2014-10-30, Bret Busby wrote: Hello. I have just realised the presence, and, extent of the presence, of the spelling/typographical errors in the last previous message that I posted about this; above, so am posting it again, hopefully with all of the errors corrected. I'm afraid your grade can't be modified at this point however grammatically laudable your continued efforts. This -- made me smile. Curt at his succinct and pithy best. As for you, Bret. I'm going to try to find an extra monitor around here this weekend to see if I can find a) your problem, and b) a solution. I'll also have to do a little spelunking in the message archive to see if I have any chance of roughly duplicating your hardware setup. I've used multiple monitors in testing before with various graphics subsystems and don't remember any drama. I quit only because I'm probably better off not seeing one monitor well than not seeing two monitors well. Dangit, old age. For all I know there was *lots* of drama, and I just don't remember it! Jape -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54527543.8050...@comcast.net
Re: Problem with external monitor
On 10/30/2014 03:13 PM, Bret Busby wrote: On 31/10/2014, Jape Person wrote: On 10/30/2014 01:02 PM, Curt wrote: On 2014-10-30, Bret Busby wrote: Hello. I have just realised the presence, and, extent of the presence, of the spelling/typographical errors in the last previous message that I posted about this; above, so am posting it again, hopefully with all of the errors corrected. I'm afraid your grade can't be modified at this point however grammatically laudable your continued efforts. This -- made me smile. Curt at his succinct and pithy best. As for you, Bret. I'm going to try to find an extra monitor around here this weekend to see if I can find a) your problem, and b) a solution. I'll also have to do a little spelunking in the message archive to see if I have any chance of roughly duplicating your hardware setup. I've used multiple monitors in testing before with various graphics subsystems and don't remember any drama. I quit only because I'm probably better off not seeing one monitor well than not seeing two monitors well. Dangit, old age. For all I know there was *lots* of drama, and I just don't remember it! Jape Hello. I hope that the information below, is helpful. The problem computer is an Acer v3 772 laptop computer, running Debian 7 .x and LXDE, now with bumblebee installed; the noveau version of bumblebee, did not work, so I installed the nvidia version of bumblebee, and that still did not work, and that system has an NVidia GEForce GT750M graphics accelerator. It does not detect the external monitor. The external monitor runs okay with Ubuntu 14.04.1 LTS, on the same hardware, regarding which, from a previous message; " However, from Ubuntu 14.04.1.LTS, which I have now installed, and got the external monitor working, and display output directed to only that monitor, I have " bret@bret-Aspire-V3-772:~$ lspci -nn | grep VGA 00:02.0 VGA compatible controller [0300]: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller [8086:0416] (rev 06) From the Ubuntu 14.04.1 LTS lshw output, I get " *-pci:0 description: PCI bridge product: Xeon E3-1200 v3/4th Gen Core Processor PCI Express x16 Controller vendor: Intel Corporation physical id: 1 bus info: pci@:00:01.0 version: 06 width: 32 bits clock: 33MHz capabilities: pci normal_decode bus_master cap_list configuration: driver=pcieport resources: irq:40 ioport:4000(size=4096) memory:d200-d2ff ioport:a000(size=536870912) *-display description: 3D controller product: GK107M [GeForce GT 750M] vendor: NVIDIA Corporation physical id: 0 bus info: pci@:01:00.0 version: a1 width: 64 bits clock: 33MHz capabilities: bus_master cap_list rom configuration: driver=nouveau latency=0 resources: irq:51 memory:d200-d2ff memory:a000-afff memory:b000-b1ff ioport:4000(size=128) memory:b200-b207 *-display description: VGA compatible controller product: 4th Gen Core Processor Integrated Graphics Controller vendor: Intel Corporation physical id: 2 bus info: pci@:00:02.0 version: 06 width: 64 bits clock: 33MHz capabilities: vga_controller bus_master cap_list rom configuration: driver=i915 latency=0 resources: irq:48 memory:d300-d33f memory:c000-cfff ioport:5000(size=64) " " Oh, rats! I had mixed up your situation and one that I saw on a forum. Yeah, there's no chance I can match that hardware setup. I'm guessing that later kernels are going to support that video hardware just fine. I will still do some noodling around this weekend to see if I can come up with a bright idea -- or even a dumb one. But I'm afraid I'm not going to be of much use to you. I'm sorry. Jape -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54529803.8060...@comcast.net
Re: terminal spreadsheet - sc fork
On 10/30/2014 06:23 PM, Andrés Martinelli wrote: Hello there!! I am working on a terminal spreadsheet based on "sc", but with some adds like undo/redo.. you can find it here: https://github.com/andmarti1424/scim Any new ideas and/or contribution is always welcome! Thanks! This is so cool! I wish you good luck. A decent spreadsheet is about the last regular application (i.e. not a Web application / browser) that I need to convince my wife to go to a simpler operating system. Undo / redo were tops on my list for improvements when I tested sc. The only "con" I can see for the application name is that it might confuse people who are looking for the "smart common input method" platform / SCIM. Heh. I wonder if you could do an ncurses-based "fork" of gnucash! Yeah, I know. Kinda ambitious. I like being ambitious when other people are doing the work. ;-) Again, good luck. This is a fantastic development. Jape -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5452bef5.60...@comcast.net
Re: Howto add a vnc URL handler to Icedove?
On 10/29/2014 01:38 AM, Scott Ferguson wrote: I want to make things easier for people accepting remote desktop invitations from Krfb. Ideal scenario:- 1. Create a reverse ssh tunnel to "middle" (an internet accessible server) from the "users" computer. e.g. port 1234 to port 1235 "middle" has port forwarding enabled e.g. port 1234 to port 1236, and the reverse ssh tunnel creation is automated (KMenu entry for Krfb modified to call a script, that starts the reverse ssh tunnel before calling Krfb). 2. The "user" then sends an (encrypted) email invitation from Krfb[*1] to the "support" - and waits for support to connect (which then requires the "user" to allow "support" access). 3. "support" then opens the email in Icedove, clicks on the link[*2], Icedove uses a script to handle the link, which then processes[*3] the link before calling krdc (or tightvnc) - which then gives "support" remote access to the "users" desktop. Ideal outcome:- Quick and easy remote desktop support even when both the "user" and "support" are behind NAT firewalls. [*1] Krfb is set to use port 1235 [*2] e.g. vnc://invitation:cpcz-...@xxx.xxx.xxx.xxx: There /appears/ to be two problems which I'd like suggestions on how to solve:- 1. while the link displays as show above, in the HTML (subset used in email) it's actually a mailto link... 2. I've tried adding to Icedove about:config:- ;a new string value of "network.protocol-handler.app.vnc" with the value "$processingScript %U" ;a new boolean value "network.protocol-handler.expose.vnc" with the value "true" But I suspect they'll never be called as Icedove treats the link as "mailto" Google yields nothing, nor does the Mozilla developer documentation, and the same question has previously been posted to Mozilla forums, carefully described, by someone else - but has never received an answer. So I ask the question here, knowing that there are some informed list readers who might have useful suggestions. Kind regards No, don't get your hopes up. I ain't gonna be helpful. I'm just expressing my disappointment that no one has responded to this message. Information on how to do this would be very helpful to me. You (Scott) help a lot of people here. I wish someone would help you! (and me) ;-) Jape -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5454e554.30...@comcast.net
Re: Camera SD card mounting problems (defined by systemd)
On 11/01/2014 06:26 AM, Andrei POPESCU wrote: On Vi, 31 oct 14, 14:10:20, Charles Kroeger wrote: I have a line in my /etc/fstab file: #/dev/sde1/ /media/lumix-photos vfat users,rw,auto,iocharset=utf8,umask=000 0 Anytime I want to add photos off the SD card in my camera, I comment out the hashmark add the SD card to the reader, and reboot the computer. Why reboot, you can just use 'mount -a'? By the way, 'auto' and 'rw' are default, no need to set them explicitly. Kind regards, Andrei I've seen a number of folks posting about manual mounting with and without use of a file manager with something like gvfs-backends, problems with entries in /etc/fstab, etc. Apropos of no particular knowledge on my part, but of a desire to ask a question that might be a useful -- would pmount be of use to at least some people with problems of this sort? I don't have any of my removable drives / storage devices in /etc/fstab (or I comment them out). I just plug them in and use pmount to mount them. $ ls -l /dev/disks/by-label to see them $ pmount /dev/sd /media/ to mount them. HTH someone. Jape -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5454e480.4040...@comcast.net
Re: Skipping fsck during boot with systemd?
On 12/10/2014 10:14 AM, Andrei POPESCU wrote: In my not so humble opinion, one should be using such a switch to re-examine one's setup, practices, etc. You might discover some "interesting" stuff. As far as I'm concerned: 1. I'll be looking into disabling periodic checks on all my ext4 partitions[1], in line with the not so new mkfs defaults. 2. As has been pointed out in this thread, interrupting or completely skipping the check after unclean umount is *dangerous* and can lead to data loss. If you get one of these while you're on battery power it's probably a good time to think if your backup strategy is good enough[2]. 3. If one can afford the additional downtime a full fsck as part of regular maintenance *might* make sense. E.g. I could imagine on kernel upgrades (which force a reboot anyway) one boots up with the new kernel, check everything is working fine and then reboots a second time with 'fsck.mode=force'. [1] the only other filesystem I'm (still) using is xfs, which doesn't do this anyway [2] and start praying if it isn't Kind regards, Andrei Hi, Andrei. I'm posing a question at this point because it relates directly to your post excerpted above. If you feel this is off-topic for this thread, I'll be glad to start a new thread. I came to the same conclusions you outlined and implemented 1 and 3 among your suggestions on my home systems -- all running testing. However, I've been helping a few remote users of Debian testing -- some of them thousands of miles from me -- by doing updates/upgrades, configuration changes as needed, and so on for them. Using fsck.mode=force on the linux command line works fine for the purpose of forcing a file system check at home, but I don't see a practical way to use it on the remote systems. Do I really have to walk each of them through editing of the linux command line or through alteration of their grub menu, etc. so they can initiate fsck manually themselves at boot time once-in-a-while? Or can you think of a way I can be in control of this without bothering them? Some of these folks would not be good candidates for performing these changes to such essential parts of their systems. At present I can still use "touch /forcefsck", but I see the warning about this in the log, and I imagine the ability to use this command to cause an fsck to run during the next reboot may cease to be implemented at some point. This issue -- while not what I'd call a bug -- is a feature difference that may eventually result in my having to stop performing this particular part of the maintenance. This is of some concern to me, most particularly in regard to the older systems which use ext3. Ideas? Thanks -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54887693.5080...@comcast.net
Re: Skipping fsck during boot with systemd?
On 12/10/2014 01:40 PM, Andrei POPESCU wrote: On Mi, 10 dec 14, 11:36:35, Jape Person wrote: Using fsck.mode=force on the linux command line works fine for the purpose of forcing a file system check at home, but I don't see a practical way to use it on the remote systems. Do I really have to walk each of them through editing of the linux command line or through alteration of their grub menu, etc. so they can initiate fsck manually themselves at boot time once-in-a-while? Or can you think of a way I can be in control of this without bothering them? Some of these folks would not be good candidates for performing these changes to such essential parts of their systems. There is a way to tell grub to boot once with a different default entry. It's a long time since I needed that, but a start would be the grub-set-default(8) command. Hope this helps, Andrei Thanks for the information. I tried 'man grub-set-default' which gave me only 40 lines. It suggested using 'info grub-set-default' for access to the entire manual -- which gave me 45 lines. Heh. But that information plus the linked items (in the info output) grub-reboot and grub-editenv may get me started toward a solution. Many thanks! Regards, JP -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5488adf7.50...@comcast.net
Re: networked multi-function colour laser printers
On 07/14/2014 10:58 AM, Richard Lyons wrote: On Mon, Jul 14, 2014 at 14:38:46 +0100, Brad Rogers wrote: On Mon, 14 Jul 2014 14:13:22 +0100 Richard Lyons wrote: Hello Richard, I see that HP and OKI both claim to offer Linux drivers, for example. With HP, by and large, you don't need to install their own drivers. Here, I install hplip and drivers (from the repos). Yes, but in fact the printing side is usually manageable -- the main problem being that CUPS mysteriously finds more and more copies of the network printer, and it is difficult to know which one to choose when setting up a new printer. The difficulty comes in persuading SANE to even see the machine on the network. Samsung have an excellent universal installer -- but when it fails on some distros, you are borked. I used to use a Business Inkjet 1200 without problems, and currently use an Officejet 6700 multifunction device (print/scan/fax). Okay, so not a laser, but even so It is beginning to sound as though HP is the only safe way to go. If you do happen to find a current multi-function laser printer (colour or b&w) that works just with the drivers and installers available in the main repository, please let us know. I purchased an HP M127fn (b&w MFP) a couple of weeks ago thinking that this would be a safe bet -- just because it was an HP. But I got it home, checked the hardware compatibility lists, found absolutely nothing that even vaguely resembled the model number, and then chickened out and took it back to the store without opening it. I don't know for certain that it wouldn't have worked, but the HP Web site was kind of dodgy about providing specifics. I got the impression that I would have had to download software directly from them -- and that's in the best-case scenario. I didn't really need the thing (already had a working inkjet MFP) and just didn't want to go through the possible hassle of using anything outside of the repos. The HP MFPs I've used have been extremely easy to install and to get all functions working -- just by using the hp-setup utility. But they've all been older models. Good luck! Good luck. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53c3f669.3040...@comcast.net
Re: Is there any documentation on how to configure the Gnome Desktop environment?
On 09/11/2014 02:35 AM, Rick Thomas wrote: In particular, I’m interested in getting Gnome under Jessie to use a terminal program that isn’t gnome-terminal. Anybody know how to do that? TLDNR: Gnome terminal, apparently, is broken if you use the “C” locale. It wants to see a UTF8 locale, and refuses to work with anything less! See Debian bug#746415 for details. Programs like lxterminal and simple xterm work fine, so I’d like to configure Gnome to use one of them instead of the broken gnome-terminal. But I haven’t discovered the right magical incantation to do that yet. Help? Anybody? Rick I'm sorry that I'm not likely to be helpful. I haven't used Gnome in a long time, and I know it has changed a lot. I'm curious, though. How do you launch the terminal window -- from the menu system / from a desktop or panel shortcut of some kind? What happens when you use a launcher and specify that it launch xterm, as in /usr/bin/xterm? Surely Gnome doesn't subsume all terminal executables and cause them to launch the Gnome terminal? I hope you find a solution. Jape -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54119140.4020...@comcast.net
How to get a log of fsck on boot partition when using systemd-sysv
Hi, I just used # apt-get install systemd-sysv on several Debian testing systems (fully up-to-date). It has been my habit to use # touch /forcefsck to force a file system check at reboot once per week on each system and to keep track of the results by copying the contents of /var/log/fsck/checkroot into a sort of diary I keep on system maintenance. In various logs on these systems I see an indication that "touch /forcefsck" doesn't work with systemd running the show, and that adding fsck.mode=force to the linux boot line in Grub is now the proper way to force fsck to run at boot time. However, though I see that fsck is running when I boot the system after altering the boot process, there is still no output from the operation written to the checkroot file. I presume this is part of the rhubarb I've noticed on various lists concerning the logging of the boot process when using systemd. This is hardly a huge problem for me, but I'd like to keep practicing this slightly OCD behavior if I can on a couple of the more critical machines. Would anyone have thoughts on how I can get a record of the file system check on the boot drive when using systemd? If there's something about this in the man pages, I'm certainly not finding it. Thanks for any pointers you can provide. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/536e9ed8.5050...@comcast.net
Re: How to get a log of fsck on boot partition when using systemd-sysv
On 05/10/2014 06:32 PM, Brandon Vincent wrote: On Sat, May 10, 2014 at 2:49 PM, Jape Person wrote: Hi, I just used # apt-get install systemd-sysv on several Debian testing systems (fully up-to-date). It has been my habit to use # touch /forcefsck to force a file system check at reboot once per week on each system and to keep track of the results by copying the contents of /var/log/fsck/checkroot into a sort of diary I keep on system maintenance. In various logs on these systems I see an indication that "touch /forcefsck" doesn't work with systemd running the show, and that adding fsck.mode=force to the linux boot line in Grub is now the proper way to force fsck to run at boot time. However, though I see that fsck is running when I boot the system after altering the boot process, there is still no output from the operation written to the checkroot file. I presume this is part of the rhubarb I've noticed on various lists concerning the logging of the boot process when using systemd. This is hardly a huge problem for me, but I'd like to keep practicing this slightly OCD behavior if I can on a couple of the more critical machines. Would anyone have thoughts on how I can get a record of the file system check on the boot drive when using systemd? If there's something about this in the man pages, I'm certainly not finding it. Thanks for any pointers you can provide. > Jape, > > It sounds like the fsck is being conducted while the initramfs is loaded > and thus no log is being saved. Ideally, there would be a way to have the > console dumped to dmesg. > > Brandon Vincent > Hi, Brandon. I hope you'll excuse me for moving your response to the bottom and then replying to it there. I think this list prefers bottom posting or, better yet, interleaved posting. Thank you for your response. Yes, I think you're right, though I wasn't bright enough to go in that direction on my own -- perhaps because the previous system startup method accomplished the file system check and then wrote the results after the disk was mounted. Or maybe I'm taking too much for granted in assuming how it accomplished that. I wonder if there's some reason why systemd-sysv couldn't do the same thing? This looks like an oversight to me, but maybe it's deliberate. I suppose I could boot these systems with a live disc of some type, and then perform a file system check on the systems' primary disks. That would be a bit of trouble to go through on the systems that sit in front of me, and not really practical at all on the remote systems. I'll mull it over and see if I can figure it out. Again, thank you for your insight. Jape -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/536ec324.7000...@comcast.net
Re: How to get a log of fsck on boot partition when using systemd-sysv
On 05/11/2014 03:35 AM, Sven Joachim wrote: On 2014-05-10 23:49 +0200, Jape Person wrote: In various logs on these systems I see an indication that "touch /forcefsck" doesn't work with systemd running the show, and that adding fsck.mode=force to the linux boot line in Grub is now the proper way to force fsck to run at boot time. It is true that fsck.mode=force is the recommended way, but the methods used by the checkfs.sh initscript are still supported despite the warning systemd-fsck prints when you use them. Thanks for this information, Sven. I was assuming that the warning message scrolling by on the screen meant that the file system check was not actually being run. (More on this later.) It's nice that it works, because that means I can still initiate the fsck on remote systems. I'm not sure what I'm going to do if this bit of backward compatibility gets eliminated before some other means besides editing the Linux boot line to force the file system check is provided. I suppose I could just update grub and have the check run every time the systems are rebooted. It's not like it takes that long for fsck to run. However, though I see that fsck is running when I boot the system after altering the boot process, there is still no output from the operation written to the checkroot file. I presume this is part of the rhubarb I've noticed on various lists concerning the logging of the boot process when using systemd. Those messages end up in the journal. The initscript captures them with logsave(8) which is a kludge to work around the problem that syslog is not yet available when it runs. Okay, well a kludge is certainly better (for me) than nothing! ;-) This is hardly a huge problem for me, but I'd like to keep practicing this slightly OCD behavior if I can on a couple of the more critical machines. Would anyone have thoughts on how I can get a record of the file system check on the boot drive when using systemd? Something like "journalctl -b | grep systemd-fsck". I haven't figured out how to get "journalctl -u" to work here. Thank you for leading me to the water, Sven. Your example shows me that I really need to get into using the standard textual tools that are so valuable to this operating system. I'm a tinkerer/hobbyist with GNU/Linux. I use it a lot, but I don't really work *on* it a lot. What's funny is that I had examined the journal after using "touch /forcefsck" by using cat to pipe it to a text file and just searching with the find function of a text editor. I then stupidly quit looking as soon as I found the warning message, assuming that the fsck hadn't actually been run. Because I wasn't using a specific tool like grep (which would have shown me only what I needed to see) to find what I was looking for, I just quit. Then when I tried to run the check by editing the Linux boot line I (rather dumbly, I admit) just checked /var/log/fsck/checkroot again for the results instead of going back to the journal. All around not one of my brighter days. If I had been a little less tired and a little more assiduous with the text editor -- or if I'd used the proper tool for searching the journal in the first place -- I'd have found what I was looking for. You are an awfully useful person to have around because you help so much with understanding the process. Many thanks. Cheers, Sven Best regards, Jape -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/536fa2a5.7080...@comcast.net
Re: How to get a log of fsck on boot partition when using systemd-sysv
On 05/11/2014 08:29 AM, Michael Biebl wrote: Am 11.05.2014 09:35, schrieb Sven Joachim: Something like "journalctl -b | grep systemd-fsck". I haven't figured out how to get "journalctl -u" to work here. That, or something like systemctl status systemd-fsck-root.service or systemctl status systemd-fsck@.service works for me as well. If you use systemctl status systemd-fsck@ autocompeltion will help you with choosing the right device name, *but* make sure to properly quote the string, if it contains \, ie. either put it in "" or use \\ instead of single \. Yes, indeed, the first of these two commands provided the information I was looking form. I'm going to have to read about systemctl. The second command didn't seem to provide information about the fsck output, but I may have been using it improperly. And I learned something about my terminal emulator that I need to correct. Apparently tab completion isn't operating on my system. I'll do a little homework on that. It's obviously a useful tool. HTH, Michael It does help, Michael. Thanks. Best regards, Jape -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/536fa43a.50...@comcast.net
[SOLVED] Re: How to get a log of fsck on boot partition when using systemd-sysv
On 05/11/2014 12:17 PM, Jape Person wrote: On 05/11/2014 03:35 AM, Sven Joachim wrote: On 2014-05-10 23:49 +0200, Jape Person wrote: In various logs on these systems I see an indication that "touch /forcefsck" doesn't work with systemd running the show, and that adding fsck.mode=force to the linux boot line in Grub is now the proper way to force fsck to run at boot time. It is true that fsck.mode=force is the recommended way, but the methods used by the checkfs.sh initscript are still supported despite the warning systemd-fsck prints when you use them. Thanks for this information, Sven. I was assuming that the warning message scrolling by on the screen meant that the file system check was not actually being run. (More on this later.) It's nice that it works, because that means I can still initiate the fsck on remote systems. I'm not sure what I'm going to do if this bit of backward compatibility gets eliminated before some other means besides editing the Linux boot line to force the file system check is provided. I suppose I could just update grub and have the check run every time the systems are rebooted. It's not like it takes that long for fsck to run. However, though I see that fsck is running when I boot the system after altering the boot process, there is still no output from the operation written to the checkroot file. I presume this is part of the rhubarb I've noticed on various lists concerning the logging of the boot process when using systemd. Those messages end up in the journal. The initscript captures them with logsave(8) which is a kludge to work around the problem that syslog is not yet available when it runs. Okay, well a kludge is certainly better (for me) than nothing! ;-) This is hardly a huge problem for me, but I'd like to keep practicing this slightly OCD behavior if I can on a couple of the more critical machines. Would anyone have thoughts on how I can get a record of the file system check on the boot drive when using systemd? Something like "journalctl -b | grep systemd-fsck". I haven't figured out how to get "journalctl -u" to work here. Thank you for leading me to the water, Sven. Your example shows me that I really need to get into using the standard textual tools that are so valuable to this operating system. I'm a tinkerer/hobbyist with GNU/Linux. I use it a lot, but I don't really work *on* it a lot. What's funny is that I had examined the journal after using "touch /forcefsck" by using cat to pipe it to a text file and just searching with the find function of a text editor. I then stupidly quit looking as soon as I found the warning message, assuming that the fsck hadn't actually been run. Because I wasn't using a specific tool like grep (which would have shown me only what I needed to see) to find what I was looking for, I just quit. Then when I tried to run the check by editing the Linux boot line I (rather dumbly, I admit) just checked /var/log/fsck/checkroot again for the results instead of going back to the journal. All around not one of my brighter days. If I had been a little less tired and a little more assiduous with the text editor -- or if I'd used the proper tool for searching the journal in the first place -- I'd have found what I was looking for. You are an awfully useful person to have around because you help so much with understanding the process. Many thanks. Cheers, Sven Best regards, Jape Not certain whether or not this is necessary, but thought I'd add "[SOLVED] " to the front of the thread title in case it might be helpful to anyone scanning the archives for solutions to this problem. Again, thank you all for your help. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/536ffcc4.70...@comcast.net
Re: systems hangs every few days
On 06/18/2013 10:31 AM, Chris Purves wrote: > On 2013-06-18 10:20, Rob Owens wrote: >> - Original Message - >>> From: "Chris Purves" >>> To: debian-user@lists.debian.org >>> Sent: Tuesday, June 18, 2013 8:59:07 AM >>> Subject: systems hangs every few days >>> >>> After upgrading to wheezy, I get a system hang every one or two days >>> where the system becomes completely unresponsive and I need do a >>> cold boot. >>> >> That sounds a lot like bad RAM. Run MEMTEST86 on it. I'm not sure if the >> debian install cds contain that, but Knoppix usually has that as a boot >> option. The full test could take more than a day. If you're lucky, it'll >> find an error in the first 10 minutes. >> > > I ran memtest86 already for about 20 minutes without error. (I forgot to > mention that in original post). I will run it overnight tonight to see if > anything else pops up. > > I am skeptical that it's bad RAM since the problem occurred after upgrading > and I would have expected some kernel panic errors in the logs or something > like that, although I suppose bad RAM can manifest itself in different ways. One thing I noted in your first message, Chris, was that it usually happens when a cron job is running. I immediately thought of two possibilities: 1. One or more of the cron jobs are running a process that is "tickling" a driver that doesn't work as well with the newer kernel as it did with the previous one. 2. A scheduled job is doing something CPU-intensive that could be making the system overheat. (I suppose load caused by a given job might be worse under wheezy than it was under squeeze.) Unfortunately, I didn't keep the earlier messages and can't refer back to them to be certain whether or not my addled brain is remembering the details properly. I hope you find the gremlin and oust him! Regards, J. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51c092da.8000...@comcast.net
Holy Gnome3 Invasion, Batman! - Testing Upgrades 06/30/2013
Hi! Forgive the facetious thread title, please. I just about got knocked out of my socks this morning when I ran my daily upgrade checks in aptitude. I run Debian testing with Xfce, and I'd like to keep it that way. About a year ago I switched out Wicd for network-manager-gnome so that I could make use of the latter package's ability to control VPN connections. I guess that's the root cause of this little adventure. (However, IIRC, Xfce has started using network-manager-gnome instead of Wicd anyway.) This morning the usual upgrades included a gnome-bluetooth updgrade that wanted to pull in what appeared to be just about everything from the Gnome DE -- roughly 117 packages. The gnome-bluetooth package was apparently on the system because the network manager wants it there. This was easy enough to prevent. I just held everything while I got rid of gnome-bluetooth and its playmates, then put a forbid on gnome-bluetooth. The ensuing upgrade attempt was a lot more reasonable. I don't suppose this really qualifies as a bug -- particularly since network-manager-gnome really is a part of the Gnome DE. But I imagine a few folks who use it in other DEs are going to be a little consternated by today's upgrades if they don't pay fairly close attention before committing to them. Thanks for reading my tale of woe (whoa?). J. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51d03b7d.9080...@comcast.net
Re: Holy Gnome3 Invasion, Batman! - Testing Upgrades 06/30/2013
On 06/30/2013 10:40 AM, Patrick Wiseman wrote: > On Sun, Jun 30, 2013 at 10:06 AM, Jape Person wrote: >> Hi! >> >> Forgive the facetious thread title, please. I just about got knocked out of >> my >> socks this morning when I ran my daily upgrade checks in aptitude. >> >> I run Debian testing with Xfce, and I'd like to keep it that way. > > Me, too. > >> About a year ago I switched out Wicd for network-manager-gnome so that I >> could >> make use of the latter package's ability to control VPN connections. I guess >> that's the root cause of this little adventure. (However, IIRC, Xfce has >> started >> using network-manager-gnome instead of Wicd anyway.) >> >> This morning the usual upgrades included a gnome-bluetooth updgrade that >> wanted >> to pull in what appeared to be just about everything from the Gnome DE -- >> roughly 117 packages. The gnome-bluetooth package was apparently on the >> system >> because the network manager wants it there. >> >> This was easy enough to prevent. I just held everything while I got rid of >> gnome-bluetooth and its playmates, then put a forbid on gnome-bluetooth. The >> ensuing upgrade attempt was a lot more reasonable. >> >> I don't suppose this really qualifies as a bug -- particularly since >> network-manager-gnome really is a part of the Gnome DE. But I imagine a few >> folks who use it in other DEs are going to be a little consternated by >> today's >> upgrades if they don't pay fairly close attention before committing to them. >> >> Thanks for reading my tale of woe (whoa?). > > I think this happened because gnome-bluetooth recommends > gnome-control-center which in its turn depends on a bunch of stuff I > don't need (and most of which is not on my system) and recommends a > bunch more unnecessary stuff. The way I avoid what you saw this > morning is to tell aptitude NOT to install by default packages > recommended by other packages. That seems to prevent a lot of > unnecessary installations. So I recommend setting that option in > aptitude! You always have the option, after scanning what's > recommended, to install what you want. > > Patrick That's a good point. Back when I decided to use Debian testing I decided to stick with the default aptitude setting, which -- as you have indicated -- may not be a great idea for those of us who prefer to keep things a little simpler. It does seem as though some of the recommends are a little excessive and certainly shouldn't be treated as though they were hard dependencies. I'm not sure which will result in me doing less fiddling around in aptitude -- not having recommends set to be installed by default and adding them manually as desired, or having aptitude set to install them by default and keeping a watchful eye. It's really pretty easy to spot 117 new installations with the aptitude TUI. But I often see smaller lists of new installations being brought in and might end up installing stuff I don't need if I'm not on my toes. I think I'll take your advice. This (no recommends) is the way I used to use aptitude. And you are exactly right about gnome-panel. The gnome-bluetooth package itself didn't require addition of all of the dross, but it's request for gnome-panel is what caused the landslide of recommended installations. J. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51d0497a.4050...@comcast.net
Re: Holy Gnome3 Invasion, Batman! - Testing Upgrades 06/30/2013
On 06/30/2013 11:06 AM, Jape Person wrote: > On 06/30/2013 10:40 AM, Patrick Wiseman wrote: >> On Sun, Jun 30, 2013 at 10:06 AM, Jape Person wrote: >>> Hi! >>> >>> Forgive the facetious thread title, please. I just about got knocked out of >>> my >>> socks this morning when I ran my daily upgrade checks in aptitude. >>> >>> I run Debian testing with Xfce, and I'd like to keep it that way. >> >> Me, too. >> >>> About a year ago I switched out Wicd for network-manager-gnome so that I >>> could >>> make use of the latter package's ability to control VPN connections. I guess >>> that's the root cause of this little adventure. (However, IIRC, Xfce has >>> started >>> using network-manager-gnome instead of Wicd anyway.) >>> >>> This morning the usual upgrades included a gnome-bluetooth updgrade that >>> wanted >>> to pull in what appeared to be just about everything from the Gnome DE -- >>> roughly 117 packages. The gnome-bluetooth package was apparently on the >>> system >>> because the network manager wants it there. >>> >>> This was easy enough to prevent. I just held everything while I got rid of >>> gnome-bluetooth and its playmates, then put a forbid on gnome-bluetooth. The >>> ensuing upgrade attempt was a lot more reasonable. >>> >>> I don't suppose this really qualifies as a bug -- particularly since >>> network-manager-gnome really is a part of the Gnome DE. But I imagine a few >>> folks who use it in other DEs are going to be a little consternated by >>> today's >>> upgrades if they don't pay fairly close attention before committing to them. >>> >>> Thanks for reading my tale of woe (whoa?). >> >> I think this happened because gnome-bluetooth recommends >> gnome-control-center which in its turn depends on a bunch of stuff I >> don't need (and most of which is not on my system) and recommends a >> bunch more unnecessary stuff. The way I avoid what you saw this >> morning is to tell aptitude NOT to install by default packages >> recommended by other packages. That seems to prevent a lot of >> unnecessary installations. So I recommend setting that option in >> aptitude! You always have the option, after scanning what's >> recommended, to install what you want. >> >> Patrick > > That's a good point. Back when I decided to use Debian testing I decided to > stick with the default aptitude setting, which -- as you have indicated -- may > not be a great idea for those of us who prefer to keep things a little > simpler. > It does seem as though some of the recommends are a little excessive and > certainly shouldn't be treated as though they were hard dependencies. > > I'm not sure which will result in me doing less fiddling around in aptitude -- > not having recommends set to be installed by default and adding them manually > as > desired, or having aptitude set to install them by default and keeping a > watchful eye. It's really pretty easy to spot 117 new installations with the > aptitude TUI. But I often see smaller lists of new installations being brought > in and might end up installing stuff I don't need if I'm not on my toes. > > I think I'll take your advice. This (no recommends) is the way I used to use > aptitude. > > And you are exactly right about gnome-panel. The gnome-bluetooth package > itself > didn't require addition of all of the dross, but it's request for gnome-panel > is > what caused the landslide of recommended installations. > > J. > > ...and by gnome-panel I, of course, meant gnome-control-center... Yeesh, I'm muddle-headed today! J. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51d05d8f.7090...@comcast.net
Re: Holy Gnome3 Invasion, Batman! - Testing Upgrades 06/30/2013
On 06/30/2013 04:01 PM, Jochen Spieker wrote:
> Patrick Wiseman:
>> On Sun, Jun 30, 2013 at 10:06 AM, Jape Person wrote:
>>>
>>> Forgive the facetious thread title, please. I just about got knocked out of
>>> my
>>> socks this morning when I ran my daily upgrade checks in aptitude.
>>>
>>> I run Debian testing with Xfce, and I'd like to keep it that way.
>>
>> Me, too.
>
> I know it is nitpicking and slightly beside the point, but still: only
> because apt wants to install (parts of) Gnome, it doesn't force you to
> run it.
>
> Sure, you should be able to install exactly what you want and nothing
> more, but even a few hundred megabytes don't really need to bother you
> on a desktop system less than ten years old. Even if you install KDE,
> Gnome, Xfce and every other desktop system you can think of, the Debian
> installation does not necessarily use more than, say, 10-12GB.
>
> I don't even use one of the big desktop environments but like to have at
> least Gnome and Xfce installed, just in case someone else wants to use
> my computer. (I usually use the „awesome“ window manager which is
> awkward to use for the uninitiated).
>
>> […] The way I avoid what you saw this
>> morning is to tell aptitude NOT to install by default packages
>> recommended by other packages. That seems to prevent a lot of
>> unnecessary installations. So I recommend setting that option in
>> aptitude! You always have the option, after scanning what's
>> recommended, to install what you want.
>
> ACK, I do that too. From my /etc/apt/apt.conf.d/local:
>
> APT {
> Install-Recommends "false";
> }
>
> Aptitude {
> Recommends-Important"false";
> Keep-Recommends "true";
> Keep-Suggests "true";
> }
>
> J.
Certainly, I think I get your point here. But 117 packages is truly a bit much
for a curmudgeon like me to buy. This appeared to be the bulk of the Gnome
desktop. And I have seen "competing" DEs installed on the same system interfere
with each other in some pretty annoying ways. It's not as though they have no
effect whatsoever on each other. The most irritating interactions I've dealt
with personally are the ways in which the DEs can (I should say "could",
perhaps, since this was some time ago.) affect each other through things like
update-alternatives. What works for one may not work so well for another.
And then there's the fact that stuff I don't need is stuff I don't need. I might
be able to put up with a little avoirdupois on my system, I suppose. But the
added weight plus even the possibility that I might encounter an unwanted
interaction is more than enough to get me to avoid wholesale introduction of new
packages onto my systems. If I don't need the function, I don't need or want the
packages.
But -- if, like you -- I had a system on which I used a window manager like
awesome and which I wanted to be able to share with users who wanted or needed a
DE, it would certainly make sense to install a couple of the more popular DEs.
It's not like they'd be likely to get in my way when I was just using the window
manager.
BTW, I told aptitude to not install recommends as Patrick suggested, then
re-installed gnome-bluetooth. It just pulled in the data package plus a couple
of orphaned packages that I removed this morning after blowing away
gnome-bluetooth. This outcome is much superior from my standpoint (and, I
assume, Patrick's) to the landslide of additional packages I was looking at this
morning.
So...my problem was that I was just using my package manager improperly.
(Self-inflicted wounds are always the most irksome, aren't they?) The aptitude
default setting of installing recommends probably works okay for Gnome and KDE,
but perhaps a little less so for Xfce or the even more minimalist DEs.
Regards,
J.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51d0a7d9.70...@comcast.net
Re: Holy Gnome3 Invasion, Batman! - Testing Upgrades 06/30/2013
On 06/30/2013 11:38 PM, Andrei POPESCU wrote: > [JFTR, I hit the same issue a while ago in unstable, and it took a while > to clean via aptitude's interactive interface] > > On Du, 30 iun 13, 17:49:13, Jape Person wrote: >> >> So...my problem was that I was just using my package manager improperly. >> (Self-inflicted wounds are always the most irksome, aren't they?) The >> aptitude >> default setting of installing recommends probably works okay for Gnome and >> KDE, >> but perhaps a little less so for Xfce or the even more minimalist DEs. > > I don't think it's a matter of DE, but what you are using the system > for, available resources and admin knowledge. > > If the point of the installation is to be, let's say, multifunctional, > then installing Recommends (except maybe specific packages) is useful. > > If your system is designed for quite specific needs or even has to run > with limited resources (e.g. a Raspberry Pi class machine), then turning > Recommends off and installing them only as needed is probably more > practical. > > Beware though that, as with every non-default setting, you may be using > your system in a way that is not as thoroughly tested or supported as > the default setting. And don't even bother to report bugs about missing > functionality before checking the Recommends. > > Kind regards, > Andrei Thank you for those observations. I haven't participated much on this list, but I've noted that your contributions are always among the most helpful and insightful. In point of fact, I used to always use aptitude to install only the harder dependencies and was used to having to search through the Audit / Recommends function to fix any missing functionality that I needed. In retrospect, that happened very infrequently, so I'm pretty happy to operate that way. Adding only as needed seems to work okay for me. I may be a little obsessive about avoiding the installation of stuff that (I think) actually doesn't do anything for me. Even Xfce seems to be getting a little "heavy" for my tastes, though I think it's a pretty good compromise between provision of a fully functional DE and simplicity. On some systems I have used only a WM -- sometimes even eschewing use of a DM. They haven't been quite as "pretty" as my Xfce systems, but I hardly miss the decoration when I'm busy actually working with the systems. I will be mindful about not reporting bugs without checking the Recommends list. But I'd rather take that tack than watch the whole of the Gnome DE come flooding onto my ostensibly Xfce system, essentially because of a bluetooth dependency. I avoid bluetooth like the plague and turn off the hardware on all my systems. ;-) Thanks again for your observations. J. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51d177f2.9090...@comcast.net
Re: Help - Gnome Died After Update/Upgrade
On 07/05/2013 05:36 PM, Klistvud wrote: > Dne, 03. 07. 2013 01:17:15 je David napisal(a): >> >> Sounds like GNOME 4 :) > > +1 > > Laughed my socks off! :-D > > Yup, I've been snickering for days! -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51d74605.7030...@comcast.net
Re: day two question on installing packages on wheezy
On 02/26/2014 12:11 PM, Kirt Odle wrote: Can I get someone to clearly explain to me ( a Debian newbie ) how to make aptitude download tshark and ALL of its dependencies, in a single operation ?? Download or install? If I assume you want to install these packages, and by "ALL of its dependencies" you mean hard dependencies, recommends, and suggests (or some subset thereof) it's probably easiest for you to use aptitude in its textual interface / interactive mode by just going to a root prompt and executing # aptitude You can find tshark from within aptitude by hitting the "/" key to invoke the search function followed by typing in "tshark" at the prompt the search function provides. Once you have tshark highlighted, hit "+" to install it. If aptitude is in its default configuration, that will offer to install tshark and its dependencies and recommends. You can install the suggests by arrowing the line cursor down to the bottom of the provided list to the "Packages which are suggested..." line, hitting Enter, and then selecting (with "+") each of the items in that part of the list that you want to install. Hitting "g" again will start the installation rolling. If you have intentions other than what I've outlined, you should probably tell us a little more precisely what it is that you want to do. thanks Kirt Odle HTH, J. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/530e2f37.7020...@comcast.net
Re: FOSS-friendly Wireless Access Point (WAP) for SOHO network?
On 06/05/2017 10:14 PM, David Christensen wrote: debian-user: I am looking for a FOSS-friendly Wireless Access Point (WAP) for my SOHO network, to support Linux, FreeBSD, Windows, OS X, Android, iOS, etc., Wi-Fi devices. I'd like something with an external power adapter (wall wart), dual-band, 802.11 b/g/n/ac, Gigabit Ethernet port, built-in antennas, wall mount, good factory firmware (I will use this as an AP only; DD-WRT bricked my last router), and that can handle warm temperatures (say, 100 F). Does anyone have any advice, warnings, recommendations, etc.? David If by "FOSS-friendly" you mean FOSS running on the Access Point or Router I'd suggest you look at Luxul. I'm using a Luxul XWR-1750 as a router for three Debian stretch boxes, one Windows 10 box, an Android tablet, an Android phone, and a Brother wireless MFP -- all connected via wireless (some on 2.4 and some on 5), except when I want to connect the Debian notebook by CAT6 for special admin functions on the router. Not a hint of slowness, even on big file transfers on the local net. And the software running on the Luxul router is Open Source and directly available from the manufacturer. The admin pages are a little clunky in some ways, but it runs like a train -- like one of those good trains in some country where they run on time. Not like the trains around here. Nosiree. Better off walkin'. ;-)
gstreamer1.0-libav - necessary for browsers to play videos?
Apropos of nothing but wishing to supply an explanation to anyone else who might run into the same issue. It is my habit to perform apt update followed by apt full-upgrade every day on my testing systems. I get the impression that this may not be a common practice, but I've been doing this (apt full-upgrade or, earlier on, apt-get dist-upgrade) on a daily basis for years with only rare resulting problems, all of which have been fixed easily. I also routinely run apt --purge autoremove and debfoster to clear out packages that are no longer needed. The recent firefox-esr upgrade resulted in the following output in /var/log/apt/history.log: Start-Date: 2017-06-16 10:15:49 Commandline: apt full-upgrade Install: libjsoncpp1:amd64 (1.7.4-3, automatic) Upgrade: firefox-esr:amd64 (45.9.0esr-1, 52.2.0esr-1~deb9u1) End-Date: 2017-06-16 10:15:54 I ran debfoster, and it asked me if I wanted to keep gstreamer1.0-libav. I ran aptitude why gstreamer1.0-libav and got this result: # aptitude why gstreamer1.0-libav i task-xfce-desktop Recommends libreoffice i A libreoffice Suggests gstreamer1.0-libav Hmmm. Looks like there's no reason to keep gstreamer1.0-libav, so I let debfoster remove it. Following this, no browser on the three testing systems I have (firefox, epiphany, or qupzilla) would play any kind of video at youtube.com or at any other location. Following re-installation of gstreamer1.0-libav all browsers were once again able to play videos. I would have thought that aptitude why might have given me a hint about the browsers requiring this package. I've looked to be sure the browsers do, indeed, have all of their depends and recommends installed, and they do. (I do not install suggests as a rule, and I don't use any kind of proprietary codecs or player software. So I am dependent upon the DFSG-compliant software available in the Debian repositories to play any video or audio I'm going to use on these systems.) This is, obviously, not a very serious problem, but it's an interesting one that might bite others as unwary as I. Maybe it's implicated somehow in some of the odd reports we see from time-to-time of someone who can't get a browser to play videos. Worthy of a bug report? Thank you for your time. JP
Re: gstreamer1.0-libav - necessary for browsers to play videos?
On 06/18/2017 07:54 AM, Brian wrote: On Sun 18 Jun 2017 at 00:27:29 -0400, Jape Person wrote: Apropos of nothing but wishing to supply an explanation to anyone else who might run into the same issue. It is my habit to perform apt update followed by apt full-upgrade every day on my testing systems. I get the impression that this may not be a common practice, but I've been doing this (apt full-upgrade or, earlier on, apt-get dist-upgrade) on a daily basis for years with only rare resulting problems, all of which have been fixed easily. I also routinely run apt --purge autoremove and debfoster to clear out packages that are no longer needed. All sensible procedures. Good to know. Some of the messages I've read on this list have made me wonder if dist-upgrade / full-upgrade is almost dreaded by some users. The recent firefox-esr upgrade resulted in the following output in /var/log/apt/history.log: Start-Date: 2017-06-16 10:15:49 Commandline: apt full-upgrade Install: libjsoncpp1:amd64 (1.7.4-3, automatic) Upgrade: firefox-esr:amd64 (45.9.0esr-1, 52.2.0esr-1~deb9u1) End-Date: 2017-06-16 10:15:54 I ran debfoster, and it asked me if I wanted to keep gstreamer1.0-libav. I ran aptitude why gstreamer1.0-libav and got this result: # aptitude why gstreamer1.0-libav i task-xfce-desktop Recommends libreoffice i A libreoffice Suggests gstreamer1.0-libav Hmmm. Looks like there's no reason to keep gstreamer1.0-libav, so I let debfoster remove it. debfoster (which I do not use) queries whether you should keep a package which firefox-esr recommends? deborphan doesn't do this. On my systems: $ deborphan -Ps --ignore-suggests main/libs gstreamer1.0-libav optional Having had to use at least some Windows systems up through the release of Vista, I abhor having anything hang around that isn't truly necessary. I may be guilty of overdoing it sometimes. Following this, no browser on the three testing systems I have (firefox, epiphany, or qupzilla) would play any kind of video at youtube.com or at any other location. My main Jessie machine does not install recommended packages; it plays youtube clips within firefox-esr. So you don't even install recommends normally? I would have supposed (from reading various descriptions of recommends) that this would result in significant functional compromise in most packages. Not usually so? I think it's odd that I always install Recommends but not Suggests, and that my browsers won't play video without this particular Suggested package. Following re-installation of gstreamer1.0-libav all browsers were once again able to play videos. I would have thought that aptitude why might have given me a hint about the browsers requiring this package. I've looked to be sure the browsers do, indeed, have all of their depends and recommends installed, and they do. (I do not install suggests as a rule, and I don't use any kind of proprietary codecs or player software. So I am dependent upon the DFSG-compliant software available in the Debian repositories to play any video or audio I'm going to use on these systems.) This is, obviously, not a very serious problem, but it's an interesting one that might bite others as unwary as I. Maybe it's implicated somehow in some of the odd reports we see from time-to-time of someone who can't get a browser to play videos. Worthy of a bug report? As an additional note, I actually run both deborphan (with the -Ps and --ignore-suggests options) and debfoster after upgrades / installations / removals. A little OCD, perhaps, but I've seen deborphan and debfoster behave slightly differently on these systems -- depending, I'm guessing, on how packages and their Depends / Recommends have been installed in the first place. Thanks for your notes, Brian. JP
Re: gstreamer1.0-libav - necessary for browsers to play videos?
On 06/19/2017 09:10 AM, Brian wrote: On Sun 18 Jun 2017 at 13:47:32 -0400, Jape Person wrote: So you don't even install recommends normally? I would have supposed (from reading various descriptions of recommends) that this would result in significant functional compromise in most packages. Not usually so? An occasional problem is not unknown but it can usually be sorted. I do not do it on all machines and certainly would not advise others to follow my example unless it is necessary (1G of flash memory, for example!) Using recommended packages should be the norm. Ah, I understand. In the initial mail Jape Person also wrote this: ... Worthy of a bug report? Not from my experiences. You are using Stretch. The situation is that firefox-esr does not recommend gstreamer1.0-libav as it does on Jessie. Nothing else uses it, so deborphan lists it for removal. I agree with you up 'til there. The other issue is no sound or video played by a browser. Youtube is still ok for me with firefox on stretch (gstreamer1.0-libav installed or not). Interesting. I'll just see what happens as things get sorted out in the new testing. I haven't seen any upgrades available yet since the freeze. I know it generally takes a few days. Once again, Brian, thank you for your help.
Re: Debian Stretch Xfce: effective screeen bigger than the monitor screen
On 06/28/2017 12:26 PM, Jerome BENOIT wrote: Hello Forum, I have recently migrated from Jessie to Stretch. I have a couple of minor issues. One of them concern Xfce: some time my fingers seem to do a combination of keys that magnifies the screen: I got a floating desktop environment that is lager than my actual screen. Does any know the magic combination that leads to this state ? And, more importantly, how can we go back to the normal state ? Thanks in advance, Jerome Hi, Jerome I'm an Xfce user. The desktop magnification / zoom feature I'm familiar with is placing the mouse cursor somewhere on the desktop (other than in a window), holding down the Alt key, and moving the scroll wheel on the mouse. Getting the desktop back to normal is a matter of holding down Alt and moving the scroll wheel in the "down" direction -- toward the back of the mouse. It might be possible to assign this function to a combination of keys on the keyboard, but I've not looked into that. HTH, JP
Re: (OT kinda) Your wish is their command
On 07/26/2017 12:01 PM, Curt wrote: https://www.wired.com/story/adobe-finally-kills-flash-dead/ I'd swear that Adobe said they were going to do this years ago. At that time I muttered under my breath that I would probably be dead by the time they actually got around to it. 2020, huh? It's going to be close.
Re: (OT kinda) Your wish is their command
On 07/28/2017 07:30 AM, Curt wrote: On 2017-07-26, Jape Person wrote: On 07/26/2017 12:01 PM, Curt wrote: https://www.wired.com/story/adobe-finally-kills-flash-dead/ I'd swear that Adobe said they were going to do this years ago. At that time I muttered under my breath that I would probably be dead by the time they actually got around to it. 2020, huh? It's going to be close. Well that's a mediocre prognosis and I'm sorry to hear it. Hi, Curt. Thank you for your kind sentiment, but I've had a terrific life, so no regrets on anyone's part. And it's still possible I'll keep surprising myself. I was expected to last six months in 1982, so I've been fortunate. I should tell you that you have provided me with a steady stream of amusement. It's so appropriate that your list name is Curt. Those pithy little zingers never fail to tickle. They've made this a fun place to visit. I had hoped to see the world get a sense of humor and go to a big party together before I kicked it. Obviously, that's not going to happen, but if I may see the end of Flash before it sees the end of me, that will be a tiny but nice consolation prize. ;-) JP
pesky and persistent "driverless" Brother MFC-9340CDW
A few weeks ago a CUPS upgrade to our Debian testing systems started showing a new driver for our Brother MFC-9340CDW in print dialogs and in the CUPS printer list and in the system-config-printer utility. You'd think that was good news, but we've been unable to find any way to make the queue for this "driverless" instance of the printer function properly. The only way we can print with this printer is to do what we were doing before the new "driverless" instance of the printer showed up. We add a printer to the system via system-config-printer or the CUPS Web browser dialog and deliberately select the Brother MFC-9320CW Foomatic or Brother Script-3 driver. (That's not a typo. I'm deliberately choosing a different model.) Both of those PPDs work. I have to provide a deliberately altered name for this instance so users can tell it from the one that doesn't work. The particularly annoying thing about this situation is that I cannot delete the "driverless" instance of the printer from CUPS / system-config-printer. The instant it is deleted, it is automatically re-detected and added back to the printer list. But anyone who chooses to print to it is going to get a distorted or garbled printout. I was able to set a policy in the instance so that only root can print to it, so a regular user isn't going to waste time and paper. Still, it would be nicer if I could turn off the advertisement that the printer and the operating system is providing for the "driverless" instance. I've found nothing in the printer's menu system or in its Web interface that would seem to pertain. Ideas, anyone? Thanks, JP
Re: pesky and persistent "driverless" Brother MFC-9340CDW
On 08/04/2017 06:37 AM, Brian wrote: On Thu 03 Aug 2017 at 21:39:43 -0400, Jape Person wrote: A few weeks ago a CUPS upgrade to our Debian testing systems started showing a new driver for our Brother MFC-9340CDW in print dialogs and in the CUPS printer list and in the system-config-printer utility. You'd think that was good news, but we've been unable to find any way to make the queue for this "driverless" instance of the printer function properly. It *is* good news. The printer was set up automatically, something people have been asking for for years. No non-free drives, either. A pity about the printout. That shouldn't happen, The cause would need to be looked at. Maybe the printer is non-conforming to IPP Everywhere. Well, it *would* be good news if it actually produced usable output. As things stand right now, it's merely a way to waste time, paper, and toner. I'll admit I was tickled when I saw that there was a driver specifically for this printer, and then not tickled when it didn't work but wouldn't go away. The only way we can print with this printer is to do what we were doing before the new "driverless" instance of the printer showed up. We add a printer to the system via system-config-printer or the CUPS Web browser dialog and deliberately select the Brother MFC-9320CW Foomatic or Brother Script-3 driver. (That's not a typo. I'm deliberately choosing a different model.) Both of those PPDs work. I have to provide a deliberately altered name for this instance so users can tell it from the one that doesn't work. Brother provides software for this printer. http://support.brother.com/g/b/downloadlist.aspx?c=gb&lang=en \ &prod=mfc9340cdw_all \ &_ga=2.149781630.955111390.1501838613-23812213.1497304959&os=128 (URL line broken for readability). When I first got the printer I updated its firmware. This isn't as easy as you might think. You have to have a Windows or Mac computer to perform the update, and I didn't own one. I purchased a little Windows 10 gizmo from SimplyNUC so that I could do this update, and so that I could perform firmware updates on a couple of GPS devices. I also tried the proprietary software, just for grins. I never intended to use anything other than what's in the official repos on my Debian systems. The helter-skelter way the driver installation directions were written and the absolutely hilarious hodge-podge of license notices and balky scripts was kind of horrifying. But I'll admit that everything worked, once I weeded out the inappropriate directions and fixed the installation. And I appreciated that all was installed in a manner that made it easy to remove. The functionality of the proprietary printer driver was no better than that of the MFC-9320CW driver from CUPS, other than it included the ability to monitor toner levels. But all of that sort of stuff is readily available via the Web interface of the printer. Since I have workaround, I can't bring myself to re-install the proprietary driver. I do have to use the Web interface to see the maintenance information, and I have to get scans via my wife's Android tablet. But I just found the proprietary drivers to be icky. The particularly annoying thing about this situation is that I cannot delete the "driverless" instance of the printer from CUPS / system-config-printer. The instant it is deleted, it is automatically re-detected and added back to the printer list. But anyone who chooses to print to it is going to get a distorted or garbled printout. I was able to set a policy in the instance so that only root can print to it, so a regular user isn't going to waste time and paper. Still, it would be nicer if I could turn off the advertisement that the printer and the operating system is providing for the "driverless" instance. "CreateIPPPrinterQueues No" in cups-browsed.conf. Or switch off Bonjour broadcasting (AirPrint) on the printer. Hmmm. I turned off AirPrint through the Web interface right from the beginning. I just checked it again, and the interface indicates that AirPrint is turned off. I'll go further down this path if other tactics don't work. Thank you so much for your time and effort. I didn't think of looking in cups-browsed.conf because I thought turning off AirPrint should have done the job.
Re: pesky and persistent "driverless" Brother MFC-9340CDW
On 08/04/2017 08:25 AM, Curt wrote: On 2017-08-04, Jape Person wrote: A few weeks ago a CUPS upgrade to our Debian testing systems started showing a new driver for our Brother MFC-9340CDW in print dialogs and in the CUPS printer list and in the system-config-printer utility. You'd think that was good news, but we've been unable to find any way to make the queue for this "driverless" instance of the printer function properly. Just very quickly found this bug that seems to be relevant to your case, Jape. As you didn't describe the "garbled" condition of your printouts with the "driverless" driver I can't be sure but it seems a fair guess. I should have been more careful in describing the output. Eyes are old, and thought the was garbling, but closer exam with magnifying glass reveals that it's all just distorted -- as in compressed vertically. Apparently a resolution dpi error (reported as 600x2dpi--firmware bug?--and set that way by cups in the PPD. Workaroundable by modifying the PPD manually as explained in the thread). BTW at the Brother site I think they're recommending updating the firmware for this printer (maybe not for the reasons explicited here). HTH. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868360 Mercy! Why didn't I look in bug reports? Sheesh! The brain is really just kind of occupying space between the ears these days! I'll check the firmware. I already updated it once on this printer, and it was a pain. (Required buying a Windows computer.) I'll also go through the thread to see what I can learn. Many thanks to you, Curt!
Re: pesky and persistent "driverless" Brother MFC-9340CDW
On 08/04/2017 08:58 AM, Brian wrote: On Fri 04 Aug 2017 at 12:25:51 +, Curt wrote: On 2017-08-04, Jape Person wrote: A few weeks ago a CUPS upgrade to our Debian testing systems started showing a new driver for our Brother MFC-9340CDW in print dialogs and in the CUPS printer list and in the system-config-printer utility. You'd think that was good news, but we've been unable to find any way to make the queue for this "driverless" instance of the printer function properly. Just very quickly found this bug that seems to be relevant to your case, Jape. As you didn't describe the "garbled" condition of your printouts with the "driverless" driver I can't be sure but it seems a fair guess. Apparently a resolution dpi error (reported as 600x2dpi--firmware bug?--and set that way by cups in the PPD. Workaroundable by modifying the PPD manually as explained in the thread). Definitely a firmware bug; the printer is non-conforming. cups-browsed puts the incorrect information in the PPD because it queries the printer and that is what it is told. Seems like this must be the case. Too bad. Updating firmware on this thing requires trundling it out of the den, down the hall and to the living room so I can attach it to a Windows box. I'll look into this and get back to you and Curt to let you know whether or not the printer is already running the latest firmware. BTW at the Brother site I think they're recommending updating the firmware for this printer (maybe not for the reasons explicited here). HTH. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868360 If the OP has his testing systems up-to-date, he should not be seeing this bug. All three testing systems are upgraded daily, so I'll check into it and get back to you. Again, many thanks to you and Curt.
Re: pesky and persistent "driverless" Brother MFC-9340CDW
On 08/04/2017 08:25 AM, Curt wrote: On 2017-08-04, Jape Person wrote: A few weeks ago a CUPS upgrade to our Debian testing systems started showing a new driver for our Brother MFC-9340CDW in print dialogs and in the CUPS printer list and in the system-config-printer utility. You'd think that was good news, but we've been unable to find any way to make the queue for this "driverless" instance of the printer function properly. Just very quickly found this bug that seems to be relevant to your case, Jape. As you didn't describe the "garbled" condition of your printouts with the "driverless" driver I can't be sure but it seems a fair guess. Apparently a resolution dpi error (reported as 600x2dpi--firmware bug?--and set that way by cups in the PPD. Workaroundable by modifying the PPD manually as explained in the thread). BTW at the Brother site I think they're recommending updating the firmware for this printer (maybe not for the reasons explicited here). HTH. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868360 Thanks, Curt. It's funny (in much the same way that hitting your thumb with a hammer is funny) that the Brother support site does indeed list a later firmware update than the one I installed when I first got the printer. If one looks at the driver update history at the site, the version number jumps from 1.07 to 1.09. I have 1.08. I purchased a Windows 10 system, trundled the printer from the den to the living room to connect to the Windows 10 system via USB cable, and updated to a firmware version that is no longer even listed on the support site. And the notes on the 1.09 firmware version update are that it "fixes some software bugs". As you implied, they're not exactly explicit about the reasons one might have for installing their latest firmware. I'm going to write them to see if they will provide any worthwhile information. If they don't, I'll stick with what I've got and use the MFC-9320CW driver -- at least until such time as I have a day when I'm only twiddling my thumbs and looking for something to do. I really appreciate the information you've provided. It really helps put the problem in perspective. I think both sides in the thread made good points. It's wonderful to have the printer detected and installed automatically, but not so wonderful if it doesn't work. The approach used by CUPS should have worked. A useful fallback would have been nice. But the ball is definitely in Brother's court. Best regards, JP
Re: pesky and persistent "driverless" Brother MFC-9340CDW
On 08/04/2017 08:58 AM, Brian wrote: On Fri 04 Aug 2017 at 12:25:51 +, Curt wrote: On 2017-08-04, Jape Person wrote: A few weeks ago a CUPS upgrade to our Debian testing systems started showing a new driver for our Brother MFC-9340CDW in print dialogs and in the CUPS printer list and in the system-config-printer utility. You'd think that was good news, but we've been unable to find any way to make the queue for this "driverless" instance of the printer function properly. Just very quickly found this bug that seems to be relevant to your case, Jape. As you didn't describe the "garbled" condition of your printouts with the "driverless" driver I can't be sure but it seems a fair guess. Apparently a resolution dpi error (reported as 600x2dpi--firmware bug?--and set that way by cups in the PPD. Workaroundable by modifying the PPD manually as explained in the thread). Definitely a firmware bug; the printer is non-conforming. cups-browsed puts the incorrect information in the PPD because it queries the printer and that is what it is told. BTW at the Brother site I think they're recommending updating the firmware for this printer (maybe not for the reasons explicited here). HTH. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868360 If the OP has his testing systems up-to-date, he should not be seeing this bug. Hi, Brian. My Debian testing systems are definitely up-to-date, but it appears that I am still seeing the bug. Eyes are too tired for me to be able to go through the suggested PPD edit and other testing. When the world is this bleary I just can't count on getting dependable results. The workable solution for me right now is to use the MFC-9320CW driver. It actually works quite well and gives me access to control of all printer functions that I need. Turning off AirPrint didn't remove the advertised driverless print option in CUPS / system-config-printer / print dialogs. Oddly enough, turning off WiFi Direct did eliminate it. I know I'm being simple-minded, but the printer's wireless adapter isn't being used. It's connected to the router via Ethernet. Why do wireless settings affect what I see of this printer on the network? At least now we don't have to select between one queue that does work and one that doesn't. Your suggestion about AirPrint / Bonjour in the other message prompted me to look through all of the wireless settings. I'm delighted not to have to look at the queue that doesn't work. ;-) I'll eventually update the firmware when my attitude improves. The physical process in our particular location is a little tough for me. Right now I'm wondering why the version 1.08 firmware on my printer is not listed in the Brother support site's update history. Their list jumps from 1.07 (which came with the printer) to 1.09. They give no useful information about the purpose of the update (or any of the previous ones). Looks like someone there is just going through the motions. Best regards, JP
Re: pesky and persistent "driverless" Brother MFC-9340CDW
On 08/04/2017 06:39 PM, Brian wrote: On Fri 04 Aug 2017 at 14:09:25 -0400, Jape Person wrote: On 08/04/2017 06:37 AM, Brian wrote: On Thu 03 Aug 2017 at 21:39:43 -0400, Jape Person wrote: A few weeks ago a CUPS upgrade to our Debian testing systems started showing a new driver for our Brother MFC-9340CDW in print dialogs and in the CUPS printer list and in the system-config-printer utility. You'd think that was good news, but we've been unable to find any way to make the queue for this "driverless" instance of the printer function properly. It *is* good news. The printer was set up automatically, something people have been asking for for years. No non-free drives, either. A pity about the printout. That shouldn't happen, The cause would need to be looked at. Maybe the printer is non-conforming to IPP Everywhere. Well, it *would* be good news if it actually produced usable output. As things stand right now, it's merely a way to waste time, paper, and toner. I thought you would say that, and it is very reasonable to express such sentiments. But where is your ire aimed at? Not at Brother, as far as I can see. What do they say? Somebody there must have some knowledge about IPP specifications. Maybe they are not aware that one of their printers sets resolution to 600x2 dpi. Have you told them? (I am assumimg you are seeing fallout from #868360 and this is the cause of your frustration). Was my tone more testy than I thought? I wasn't intending to express ire at either Debian or Brother. I was just annoyed that there was no obvious way to tell the system that I didn't want to see a queue that was non-functional. With all of the provisions for other settings it just seemed odd to me that neither CUPS nor config-system-printer had a clue in their user interfaces as to how a user might indicate that s/he didn't want to see the driverless printer. This was my first experience seeing one in GNU/Linux, after all. I'll admit I was tickled when I saw that there was a driver specifically for this printer, and then not tickled when it didn't work but wouldn't go away. cups-browsed detects printers or print queues. Its job is to keep them visible; why else should it exist? You control visibility from its conf file. If you try to delete a printer or print queue cups-browsed gets upset and reinstates it. Perfectly normal if you think about it. Hence, why I whined online -- in the hope that someone would tell me how to do this the non-gui way. After all, the man pages I read indicated that it could be done, but didn't seem to tell me how to do it. But you did! 8-) The only way we can print with this printer is to do what we were doing before the new "driverless" instance of the printer showed up. We add a printer to the system via system-config-printer or the CUPS Web browser dialog and deliberately select the Brother MFC-9320CW Foomatic or Brother Script-3 driver. (That's not a typo. I'm deliberately choosing a different model.) Both of those PPDs work. I have to provide a deliberately altered name for this instance so users can tell it from the one that doesn't work. Brother provides software for this printer. http://support.brother.com/g/b/downloadlist.aspx?c=gb&lang=en \ &prod=mfc9340cdw_all \ &_ga=2.149781630.955111390.1501838613-23812213.1497304959&os=128 (URL line broken for readability). When I first got the printer I updated its firmware. This isn't as easy as you might think. You have to have a Windows or Mac computer to perform the update, and I didn't own one. I purchased a little Windows 10 gizmo from SimplyNUC so that I could do this update, and so that I could perform firmware updates on a couple of GPS devices. I have never thought updating printer firmware was easy or even possible from Linux. No Windows or Mac here either. I'll look at SimplyNUC. Thanks. It's sad, isn't it? There must be enough Linux / Unix folks using brother printers to make it worth Brother's trouble to provide a utility for this. I guess most environments have either Windows or Mac available, but mine didn't until I got the little NUC. $300 so I can do firmware upgrades. Making lemonade, I'll probably try to play some old games on the little box. There's always a silver lining. I also tried the proprietary software, just for grins. I never intended to use anything other than what's in the official repos on my Debian systems. The helter-skelter way the driver installation directions were written and the absolutely hilarious hodge-podge of license notices and balky scripts was kind of horrifying. But I'll admit that everything worked, once I weeded out the inappropriate directions and fixed the installation. And I appreciated that all was installed in a manner that made it easy to remove. The functionality of the p
Re: pesky and persistent "driverless" Brother MFC-9340CDW
On 08/04/2017 07:02 PM, Brian wrote: On Fri 04 Aug 2017 at 16:10:13 -0400, Jape Person wrote: On 08/04/2017 08:58 AM, Brian wrote: On Fri 04 Aug 2017 at 12:25:51 +, Curt wrote: On 2017-08-04, Jape Person wrote: A few weeks ago a CUPS upgrade to our Debian testing systems started showing a new driver for our Brother MFC-9340CDW in print dialogs and in the CUPS printer list and in the system-config-printer utility. You'd think that was good news, but we've been unable to find any way to make the queue for this "driverless" instance of the printer function properly. Just very quickly found this bug that seems to be relevant to your case, Jape. As you didn't describe the "garbled" condition of your printouts with the "driverless" driver I can't be sure but it seems a fair guess. Apparently a resolution dpi error (reported as 600x2dpi--firmware bug?--and set that way by cups in the PPD. Workaroundable by modifying the PPD manually as explained in the thread). Definitely a firmware bug; the printer is non-conforming. cups-browsed puts the incorrect information in the PPD because it queries the printer and that is what it is told. BTW at the Brother site I think they're recommending updating the firmware for this printer (maybe not for the reasons explicited here). HTH. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868360 If the OP has his testing systems up-to-date, he should not be seeing this bug. Hi, Brian. My Debian testing systems are definitely up-to-date, but it appears that I am still seeing the bug. Eyes are too tired for me to be able to go through the suggested PPD edit and other testing. When the world is this bleary I just can't count on getting dependable results. Understandable. Sometimes it is better to leave it to another day and look it with fresh eyes. TBH, that is also the way I feel now when it comes to your switching off AirPrint not doing what is expected. The workable solution for me right now is to use the MFC-9320CW driver. It actually works quite well and gives me access to control of all printer functions that I need. Turning off AirPrint didn't remove the advertised driverless print option in CUPS / system-config-printer / print dialogs. Oddly enough, turning off WiFi Direct did eliminate it. I know I'm being simple-minded, but the printer's wireless adapter isn't being used. It's connected to the router via Ethernet. Why do wireless settings affect what I see of this printer on the network? Nothing immediately springs to mind. Something to think about, even though your desire not to see the printer has been sorted. No wireless capability anywhere on the network? Printer is connected to the network only via CAT6 to the router. All computers are connected via wireless. But none of them has ever been given permission to connect directly to the printer. At least now we don't have to select between one queue that does work and one that doesn't. Your suggestion about AirPrint / Bonjour in the other message prompted me to look through all of the wireless settings. I'm delighted not to have to look at the queue that doesn't work. ;-) I'll eventually update the firmware when my attitude improves. The physical process in our particular location is a little tough for me. Right now I'm wondering why the version 1.08 firmware on my printer is not listed in the Brother support site's update history. Their list jumps from 1.07 (which came with the printer) to 1.09. They give no useful information about the purpose of the update (or any of the previous ones). Looks like someone there is just going through the motions. I wouldn't want to point the finger at Brother. Other printer vendors are not all that great with changelog recording, Oh, I know. A support group is given lots of "motions" to go through, and probably precious little time for the going. But that certainly results in frustrations for end users who need information. When you're using an OS other than Windows or MacOS you're going to feel short-changed. I remember how annoyed I was once just after WinXP was released that my wife connected a new HP printer to her system and just stuck the included software CD in the optical drive. The software that got installed was bigger than the OS. No foolin'. Memory may be failing me, but I swear that at least a half-dozen services were installed without so much as a by-your-leave. Maybe I'd actually rather be short-changed, come to think of it.
Re: pesky and persistent "driverless" Brother MFC-9340CDW
On 08/04/2017 07:09 PM, Brian wrote: On Fri 04 Aug 2017 at 14:14:42 -0400, Jape Person wrote: On 08/04/2017 08:25 AM, Curt wrote: On 2017-08-04, Jape Person wrote: A few weeks ago a CUPS upgrade to our Debian testing systems started showing a new driver for our Brother MFC-9340CDW in print dialogs and in the CUPS printer list and in the system-config-printer utility. You'd think that was good news, but we've been unable to find any way to make the queue for this "driverless" instance of the printer function properly. Just very quickly found this bug that seems to be relevant to your case, Jape. As you didn't describe the "garbled" condition of your printouts with the "driverless" driver I can't be sure but it seems a fair guess. I should have been more careful in describing the output. Eyes are old, and thought the was garbling, but closer exam with magnifying glass reveals that it's all just distorted -- as in compressed vertically. I've met this before in another context with another bug. cups-browsed is doing its best to give you something better than the printer's default two lines of output. It cannot be perfect. The suggested workaround for altering the PPD in #868360 is the way to go. Does it work for you? I'm going to hold off on even trying that since I have a working solution. I know I should be more curious, but I'm an old cat, and you know what they say about that combination! When I eventually do the firmware upgrade and re-enable detection of the driverless queue, I'll edit the PPD if it's still necessary. I saved the contents of that message thread for reference. Again, thanks! JP
Re: pesky and persistent "driverless" Brother MFC-9340CDW
On 08/05/2017 08:52 AM, Brian wrote: On Fri 04 Aug 2017 at 20:19:33 -0400, Jape Person wrote: On 08/04/2017 06:39 PM, Brian wrote: It's sad, isn't it? There must be enough Linux / Unix folks using brother printers to make it worth Brother's trouble to provide a utility for this. I guess most environments have either Windows or Mac available, but mine didn't until I got the little NUC. $300 so I can do firmware upgrades. Making lemonade, I'll probably try to play some old games on the little box. There's always a silver lining. I wonder whether wine would help (with installing the firmware, I mean). I had that idea back before I purchased the little Windows system. A little alarm is flashing in the back of my mind which is telling me to not even try it. I know that a publisher I worked for after my retirement from medicine fired an IT guy for doing a BIOS upgrade on a manager's laptop via WINE. The attempt bricked the laptop. In that case, of course, the fellow could have just burned a bootable BIOS update disc and done it the right way. But he insisted that the Windows executable BIOS updater should work through WINE. Since this was the *second* time he had done this, his boss showed him the door and how to use it. So "CreateIPPPrinterQueues No" makes the ptinter invisible? As it turned out, I didn't have to edit the config file. Turning off WiFi Direct made the driverless printer invisible. Is it possible that Brother is using "WiFi Direct" as a synonym for Bonjour? I'm unschooled on this stuff, so forgive if the question is dumb! Bonjour works on cabled and wireless networks, WiFi Direct is wireless only. I also thought WiFi Direct did not use Bonjour. Mystifying. You could try activating and de-activating Bonjour on the printer and looking for the printer in the output of 'avahi-browse -art', You'll need the avahi-utils package. I'm saving this information and will hope to get a chance to experiment at some point. I'd like to know more about the features and capabilities of CUPS (and this printer), but I'm a little low on energy and time due to some health issues. I was pretty tired when I experimented with the AirPrint and WiFi Direct settings. I'm wondering now if I might have failed to restart the printer after I changed the AirPrint setting. Then, later on, turning WiFi Direct off and restarting the printer might have properly instated the change in the AirPrint setting. Thank you for the additional information.
Re: pesky and persistent "driverless" Brother MFC-9340CDW
On 08/05/2017 12:44 PM, Curt wrote: On 2017-08-05, Brian wrote: On Fri 04 Aug 2017 at 20:19:33 -0400, Jape Person wrote: On 08/04/2017 06:39 PM, Brian wrote: It's sad, isn't it? There must be enough Linux / Unix folks using brother printers to make it worth Brother's trouble to provide a utility for this. I guess most environments have either Windows or Mac available, but mine didn't until I got the little NUC. $300 so I can do firmware upgrades. Making lemonade, I'll probably try to play some old games on the little box. There's always a silver lining. I wonder whether wine would help (with installing the firmware, I mean). I was wondering whether a native utility like flashrom could be used for this. However when I looked at the Brother firmware executable to see whether the firmware part could be extracted, I found that in fact the exe file doesn't contain the firmware at all, but rather downloads the latter from a Brother internet server somewhere in the cloud and then installs into the printer. I should have mentioned that. I was aware that the firmware updater connected to a server in order to grab and install the new firmware. It's all a little patchier than I'd like. The unreliable installation instructions, the fact that a recommended firmware upgrade I got from Brother and installed is no longer even listed in the update history on their site, and the odd documented bug in the firmware that evidently provides bad information to CUPS is enough to make me want to avoid another firmware update altogether. If I do decide to update the firmware again, I'm going to be leery of workarounds. I'll just do it via Windows. Frankly I would be leery of going through the procedure without a lot of wine for fear of bricking my device. A lot of wine is almost always good. ;-)
Re: pesky and persistent "driverless" Brother MFC-9340CDW
On 08/05/2017 02:28 PM, Brian wrote: On Sat 05 Aug 2017 at 13:12:40 -0400, Jape Person wrote: On 08/05/2017 12:44 PM, Curt wrote: [A bit of snipping for poetical reasons]. Frankly I would be leery of going through the procedure without a lot of wine for fear of bricking my device. A lot of wine is almost always good. You have forgotten the other two essential ingredients: A Jug of Wine, a Loaf of Bread — and Thou It's getting a little cheesy in here. I fear that someone will be along at any moment to smack our hands with a ruler. And no spam! I hate spam!
Re: pesky and persistent "driverless" Brother MFC-9340CDW
On 08/05/2017 03:12 PM, Brian wrote: On Sat 05 Aug 2017 at 14:44:46 -0400, Jape Person wrote: On 08/05/2017 02:28 PM, Brian wrote: On Sat 05 Aug 2017 at 13:12:40 -0400, Jape Person wrote: On 08/05/2017 12:44 PM, Curt wrote: [A bit of snipping for poetical reasons]. Frankly I would be leery of going through the procedure without a lot of wine for fear of bricking my device. A lot of wine is almost always good. You have forgotten the other two essential ingredients: A Jug of Wine, a Loaf of Bread — and Thou It's getting a little cheesy in here. I fear that someone will be along at any moment to smack our hands with a ruler. You have in mind that nonentity who wrote A Jug of Wine, a Chunk of Cheddar — and Thou and who didn't understand scanning. Don't worry about it. Most people here are fans of Edward FitzGerald. I might have been thinking of my wife. She's always asking if I want some cheese to go with my whine.
Re: pesky and persistent "driverless" Brother MFC-9340CDW
On 08/05/2017 07:38 PM, Richard Hector wrote: On 05/08/17 07:52, Jape Person wrote: It's funny (in much the same way that hitting your thumb with a hammer is funny) that the Brother support site does indeed list a later firmware update than the one I installed when I first got the printer. If one looks at the driver update history at the site, the version number jumps from 1.07 to 1.09. I have 1.08. Perhaps 1.08 was so buggy they decided to withdraw it altogether? Richard Yup! That's what I was inferring from their site and implying here. But they don't have to allow downloads of a bad firmware version to keep a record of its release (and it's "features" and flaws). That sort of information can be pretty important to a customer. It could help me decide whether or not it makes sense to go ahead with an upgrade to 1.09. As it is, I don't have even a clue as to whether or not 1.09 is meant to fix the resolution misreporting issue -- or anything else that might be affecting me. I only have experience applying one update to the printer. I had to buy a Windows computer to accomplish the update, and the update didn't provide any improvement whatsoever that I can see in the functionality of the printer. It may, in fact, have caused some of the weirdness I've seen. I only got it because the Brother site recommended the update to improve paper-handling (eliminate smudging and paper wrinkling). Paper-handling on this printer has, in my experience, always been excellent. That doesn't exactly encourage me to proceed with another update. I'm spoiled by the changelogs I can see for every package in my Debian installations. Most of them are excellent. A few contain very little in the way of specific information, except for the fact that they always provide version numbers which I can use to find out what's changed from upstream. Heh. I don't want to go through this silly process (mechanically / logistically difficult in my little condo) just to go to their site a few months from now to see the firmware version number in their update history jump from 1.07 to 1.10. ;-) I'm waiting to see if there's any fallout from people going to 1.09.
Re: Laser Printer recommendation...
On 08/08/2017 02:01 PM, Doug wrote: ... It always amazes me that people who get a driver made specifically for a device, a driver that has significantly more capability than one that came with their Linux os, would refuse to use it. It hasn't cost them anything, just as the Linux os hasn't cost them anything, so it is FREE. (Don't tell me they paid for it with the printer--they couldn't have bought the printer without subsidizing the driver, so essentially it is free.) Same goes for video drivers. It's like trying to swim with one hand tied behind your back. --doug It always amazes me that people think that something that didn't cost them any additional money is necessarily free. We live in a society chock full of nefarious operators (commercial, governmental, and free-lance). There can be a lot of issues with just accepting a manufacturer's software. I've seen the support disc for a printer install a half-dozen or more services (and set them to run automatically at system start) without any notification whatsoever to the user. I'd also say that the Open Source drivers available for many devices do not differ significantly in usable functionality (as opposed to lacking special "features" from the proprietary ones. Furthermore, many users don't even need all of the regular functionality provided by the proprietary drivers. How many of us have multi-function printing devices at home which include fax capability? How many of us actually use that fax capability at home? If you don't need it, why install additional software to support it? Some of the proprietary driver packages I've seen appear to be a hodge-podge of Open Source / Freeware / Proprietary software collected by support groups that are barely holding on by their fingernails. How often is that stuff perused for security or functional issues? They're barely getting it out of the door to keep up with the plethora of new printer models! It can be a bit horrifying to watch a truly ugly installation process grinding away for minutes doing whatever it wants under the root account -- often without signifying just what it's doing to ownership and permissions or what it may be altering in config files or just what it's dumping in system folders. I'm pretty sure that the vendors don't always know just what they're providing in their driver packages. Whoever wrote the installation notes for some of the commercial printer drivers I've played with recently definitely didn't know how to install those drivers -- on any OS. I'd rather use drivers from the official repos. The people who put those packages together know the OS and its desktop environments, ostensibly are following the policies of the distro, are communicating with members of other teams pertinent to use of the driver, and are presenting their packages for an assessment process by testing and unstable users and release teams. Me likey. A proprietary driver has to at least appear to be well made, provide reasonable documentation, and offer me something very special to make my risk / benefit analysis go its way. And, no matter how great the proprietary driver is, I won't use it if the only real difference between it and the Open Source driver is that it supports something I don't use. Just some thoughts on what some of the people who amaze you may be thinking. Or you could read Brian's response, which is far more pithy and succinct. :-)
Re: Laser Printer recommendation...
On 08/09/2017 04:29 AM, to...@tuxteam.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Aug 08, 2017 at 01:01:30PM -0500, Doug wrote: [...] It always amazes me that people who get a driver made specifically for a device [...] Thanks, Brian and Jape. You've put it more eloquently than I could :) Let me add that to a fish, that yummy bait up there seems free too: the little app, the Android OS coming with your smartphone, the shiny Chrome browser... The bait is free. Then you get caught in the 'net. Those old enough among us will remember Microsoft's failed attempt at reigning in the Internet which somehow, by sheer luck, seemed to have escaped their grip: "Best viewed with IE6", wit ActiveX and all that. We are there again. Best viewed with Chrome. Cheers - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlmKx+MACgkQBcgs9XrR2kYh2ACfSUICRKQBUxkLWs0UtEwJt/5f 4/cAn1hp75JqnstWp9hpEjy3r4eDIFqR =xZ6z -END PGP SIGNATURE- Best viewed with... One of my favorite online experiences over time has been the sites that announce that they won't work without Internet Explorer or Firefox or whatever, and they don't. And then you have your browser *tell* them that it's Internet Explorer or Firefox or whatever, and suddenly everything works. And then there's Flash. Web sites that insist that you use the "latest Flash" for security reasons are a laugh riot. If they gave a goat's carcass about security they wouldn't be using Flash in the first place. I'm still doing my happy dance over Adobe's announcement that they are ending support for that abomination. Life was so much fun with BBS and FidoNet and my 110 baud modem. That thing was bigger than all of my current computing equipment combined, and it ran hot enough to supplement our heating system in the winter. Ah, ASCII art pinups put up by a "naughty" SYSOP printed out on tractor feed! Those were the days! JP
Re: Background will not change.
On 08/09/2017 02:31 PM, Default User wrote: ... Hi tomas. Cinnamon DE I think borrows it's background settings utility from Gnome 3. I had the background (wallpaper) set to show an image from the "Pictures" directory. Upon reboot, the background displayed instead was the "softwaves" wallpaper installed by default by Debian 9 Stable. To change it, I right clicked on the desktop to bring up the desktop menu. From that I left clicked "Change Desktop Background". That brings up a window showing preview images of the full images available in (in this case) the Pictures directory. From this window, I left clicked any image preview. The preview image in the window then has a blue highlight around it. But then nothing else happens. Previously, when selecting any image preview, the desktop background behind the window would change to the full version of the image selected. Now, the desktop does not change at all. This acts the same for for any other directory added to the menu on the left side of window in question. - Note: in the menu on the left side of the window mentioned, the icons next to the choices above the "Pictures" directory all show as the "broken icon" placeholder symbol. "Pictures and below show a folder icon, as expected. Also, the choices in this left hand menu of the window can not be reliably selected, sometimes clicking them does nothing. And the Adwaita choice appears to have no images associated with it. This behavior (after "Note") has existed since the original install of Debian 9 Stable. I guess I just got used to it. - Fun fact: if the screen saver activates, then the user wants to unlock it, the password entry box appears. Behind it is a translucent, faded display of the full background image the user wanted and had selected. But when the screen is unlocked, the user-chosen image has disappeared and the "softwaves" image has become the background again. No expert here, but I do use the Cinnamon DE on my testing systems. I'll tell you what I'm thinking from my end user level. Your story sounds very much like there may be some missing dependencies in the DE. Obviously, the data is there, but parts of the DE are having trouble using it. Since you're running unstable / sid and updated recently, the method of upgrade used may have something to do with the symptoms. Aptitude, apt, apt-get (subset of apt?) and synaptic can have slightly different behaviors from each other during upgrades depending upon their configurations and any options you pass when using them. If the upgrade removed some packages during the upgrade, it may have removed a dependency or two that are needed for full function of the desktop background feature. I'd check /var/log/apt/history.log to see just what was upgraded and what (if any) was removed. If nothing was removed, I guess it's possible that something was upgraded to a new version but a dependency was left at an earlier version that doesn't support the parts of the upgraded stuff. I'd think you'd have got some feedback on that during the upgrade process, but things maybe don't always go as intended during upgrades -- especially in unstable. You can use the aptitude TIA to look at the details for any package names that were removed to see if any dependencies for the DE (or more specifically the background selector) were broken. Another useful utility is debsums. Running "debsums -acs" as root on a system will show you every missing or altered file in the system locations. It also lists parenthetically which packages have those missing files as dependencies. This being unstable, you might be able to fix the issue by downgrading the DE, or portions of it, to the testing version. (I think I'd keep it all the same version.) If the missing files got removed or corrupted in some other way, it's possible you can reinstall the broken package(s) with something like # apt install [package] --reinstall I've done lots of experimentation on our testing systems -- especially with respect to changing DEs. My preferred method of doing this is to completely remove task-desktop-whatever and task-desktop. It's more time-consuming and sometimes breaks a few things. But fixing the broken stuff using apt and debsums is very easy and results in a system that's identical in file complement and configuration (barring manual configuration changes) to a fresh netinstall with that same DE on another system. That means to me that Debian's package management really works well and is able to break anything the unsuspecting user breaks through misdirection or inattention. (Of course, that method wouldn't be great for someone with low bandwidth.) Anyway, I hope some of my meandering may be helpful. Best, JP
Re: Background will not change.
On 08/09/2017 10:28 PM, Default User wrote: Thanks, Jape! That's a lot of information to digest, but I'll give it a try. I wish there was an automated tool that could go through the system, to find and report any missing or invalid or circular dependencies, etc., and fix it or at least say "here's what you need to do to fix it". Maybe someday. Well, actually, that's what debsums does. At least the finding part. And fixing with apt isn't really hard at all. Once you found the missing bits and the packages they belong to, using apt or apt-get with the appropriate parameters generally fixes problem pretty easily. Aptitude's textual user interface (Just execute aptitude in a terminal.) has the ability to find broken packages where entire dependent packages are missing, but I don't think it works as well as debsums coupled with apt or apt-get does when problems are caused by partially installed packages or missing/corrupted individual member files of a package. If you haven't used these particular tools because you use something like Synaptic (which I know almost nothing about) or an autoupdater (which I know so little about that I don't even know its name), then getting used to these command line or TUI tools might take a bit of time and study. They do allow you to see what changes a command will make to the system before you actually commit to it, so they're not quite as scary as they might look at first. The man pages can be pretty useful. At any rate, running # debsums -acs in a terminal, then copying and pasting the terminal outlet into a reply to this thread may give us enough information to start with. It may prove that I'm all wet about this, and your problems with background changing are caused by a bug in whatever got updated. Give it a shot! The debsums -acs command won't do anything to change your system, so there's no risk. And, of course, if you have questions about how these utilities are working, you can just ask for help. One step at a time. Being unable to change the background isn't a problem that has to be fixed right of way, so you can take it slowly. JP
Thunderbird almost unusable after upgrade
After this upgrade thunderbird:amd64 (1:52.2.1-4, 1:52.2.1-4+b1) Thunderbird in Cinnamon DE is almost completely useless because portions of its windows / text / toolbars don't repaint until the window is resized. Is anyone else seeing this? Using different desktop themes or logging in as a different user results in same behavior. I'm curious to know whether this is being seen in different desktop environments, too. JP
Re: Thunderbird almost unusable after upgrade
On 08/10/2017 10:40 AM, Sven Joachim wrote: On 2017-08-10 10:24 -0400, Jape Person wrote: After this upgrade thunderbird:amd64 (1:52.2.1-4, 1:52.2.1-4+b1) Thunderbird in Cinnamon DE is almost completely useless because portions of its windows / text / toolbars don't repaint until the window is resized. Is anyone else seeing this? Yes, see https://bugs.debian.org/871629. Using different desktop themes or logging in as a different user results in same behavior. I'm curious to know whether this is being seen in different desktop environments, too. This is independent of the desktop environment. Cheers, Sven Thanks, Sven. Ugh! What a nasty set of behaviors! Makes me "pine" for "mutt". ;-)
Re: Thunderbird almost unusable after upgrade
On 08/11/2017 06:27 PM, Javier Barroso wrote: Hello, On Fri, Aug 11, 2017 at 9:43 PM, Sven Hartge wrote: Sven Joachim wrote: On 2017-08-10 10:24 -0400, Jape Person wrote: After this upgrade thunderbird:amd64 (1:52.2.1-4, 1:52.2.1-4+b1) Thunderbird in Cinnamon DE is almost completely useless because portions of its windows / text / toolbars don't repaint until the window is resized. Is anyone else seeing this? Yes, see https://bugs.debian.org/871629. Confirmation: Rebuilding 1:52.2.1-4 with gcc-6/g++-6 as the compiler fixes the problem. You can also download thunderbird and its addons from http://snapshot.debian.org/package/icedove/1%3A52.2.1-4/, selecting your architecture See what packages have you installed from icedove them: aptitude search '?and(?source-package(icedove),?installed)' Download to Download/icedove and install with apt install ./Download/icedove/*.deb Regards I was just getting frustrated enough to do the recompile. Ugh. I'm old, have poor eyesight, and was not anxious to do that while recovering from pneumonia. I'll give it a shot. Thank you much for the reminder. I used to love to do things the hard way, but that's not my thing any more. Just spent today doing a system installation and configuration for a system that lost a solid state drive. JP
Re: Thunderbird almost unusable after upgrade
On 08/12/2017 07:32 AM, Javier Barroso wrote: On Sat, Aug 12, 2017 at 5:49 AM, Jape Person wrote: On 08/11/2017 06:27 PM, Javier Barroso wrote: Hello, On Fri, Aug 11, 2017 at 9:43 PM, Sven Hartge wrote: Sven Joachim wrote: On 2017-08-10 10:24 -0400, Jape Person wrote: After this upgrade thunderbird:amd64 (1:52.2.1-4, 1:52.2.1-4+b1) Thunderbird in Cinnamon DE is almost completely useless because portions of its windows / text / toolbars don't repaint until the window is resized. Is anyone else seeing this? Yes, see https://bugs.debian.org/871629. Confirmation: Rebuilding 1:52.2.1-4 with gcc-6/g++-6 as the compiler fixes the problem. You can also download thunderbird and its addons from http://snapshot.debian.org/package/icedove/1%3A52.2.1-4/, selecting your architecture See what packages have you installed from icedove them: aptitude search '?and(?source-package(icedove),?installed)' Download to Download/icedove and install with apt install ./Download/icedove/*.deb Regards I was just getting frustrated enough to do the recompile. Ugh. I'm old, have poor eyesight, and was not anxious to do that while recovering from pneumonia. I'll give it a shot. Thank you much for the reminder. I used to love to do things the hard way, but that's not my thing any more. Just spent today doing a system installation and configuration for a system that lost a solid state drive. JP It is solved in sid now (maintainer rebuild it with gcc 6) Regards Better the maintainer than me! ;-) I'm very lazy these days. Speaking of which, thank you again. JP
Re: Debian buster & gnucash
On 02/08/2018 12:25 PM, Donald F. Emery wrote: > I am new to debian and was hoping someone could tell me why > GNUCASH was not in debian testing. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790204 The bug report explains the current status of gnucash in testing. I installed gnucash from unstable by adding this line deb http://deb.debian.org/debian sid main (temporarily) to /etc/apt/sources.list, then running # apt update then # apt install gnucash* Following that I commented out the testing line in /etc/apt/sources.list and ran # apt update again to get the apt package database back to its normal contents for testing. Normally when using unstable like this I would alter the apt configuration to give preference to the version in unstable and / or pin the version of the package I want, but since there is no version of gnucash and gnucash-docs available in testing, I just got lazy and did nothing about that. Currently these instructions should get you version 1:2.6.18-1 of gnucash. It's working well for me. I hope one of the sharper-eyed and less lazy of the list members will give you better instructions if warranted. As I understand it, the version in experimental is not yet a good choice for someone who needs a properly functioning installation of the package. HTH, JP
Re: update bios from debian
On 03/07/2018 10:37 PM, emetib wrote: > has anyone tried to update their bios from debian or linux in general? > > i've looked at these pages -> > https://wiki.debian.org/FlashBIOS > https://support.lenovo.com/us/en/downloads/DS038945 > > and have downloaded the packages that they say to get, and have also > downloaded the new bios from lenovo's website. > > don't really want to turn my laptop into a brick, so i'm curious if anyone > has done this before, and if so anything that i should worry, not worry > about? > > the lenovo site say to just click on the .exe, yet i don't know if it needs > windows to do the install or not. > > any thoughts? > thanks. > em > > I looked at the Lenovo support site and saw no evidence of a bootable BIOS update CD for the G405 and G505. For the Lenovo systems I've seen before those images are available alongside the Windows executable (.exe) updater that you've downloaded. The .exe will not work from within Linux, and you don't want to try using it from within WINE. You should ask Lenovo if they can supply the bootable BIOS update CD. Here's a quote from the Lenovo site regarding the BIOS Update CDs available for Thinkpad laptops: The BIOS Update CD can boot the computer disregarding the operating systems and update the UEFI BIOS (including system program and Embedded Controller program) stored in the ThinkPad computer to fix problems, add new functions, or expand functions as noted below. I think that's the type of BIOS / UEFI updater you want. You can use such an image by burning it to CD and booting from the CD, or you can use information from one of the many locations online like https://workaround.org/article/updating-the-bios-on-lenovo-laptops-from-linux-using-a-usb-flash-stick/ to create and use a bootable usb flash drive as the basis for updating the system. I'm concerned that Lenovo doesn't seem to make the update CD image for the G405/G505. Do they only provide them for Thinkpads? If so, not cool. Hope you find a solution. JP
Debian testing linux-image update leads to slow file transfers?
On 03/28 I updated 3 Debian testing systems on our LAN at home, the update including -- linux-image-4.15.0-2-amd64 Since that time two behavioral differences have been conspicuous on all three systems. The first is that these messages appear in dmesg during every boot process: [1.799465] platform regulatory.0: firmware: failed to load regulatory.db (-2) [1.799498] firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware [1.799537] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 [1.799540] cfg80211: failed to load regulatory.db The second is that large file transfers on the LAN are almost unbelievably slow, requiring (for instance) more than three hours to copy a 5 gigabyte file from one system to another. Such operations required only a few minutes before the upgrade of 03/28. I found some information in threads at bbs.archlinux.org that indicated that this issue was supposed to be harmless, but I learned, also, that some systems have shown evidence of very slow file transfers following this kernel update. This apparently had something to do with a change in TCP congestion control to bbr. I ran the following command on all three systems: # sysctl net.ipv4.tcp_congestion_control=cubic File transfer speeds returned immediately to normal for all three systems. Naturally, this did nothing for the dmesg messages, but system backups and other file transfers no longer require ridiculous amounts of time. I saw nothing in the Debian bug tracker that seems to apply, but I may have been looking in the wrong places. I did fire up reportbug and tried to send the information to reportbug.debian.org, but got an SMMTP send failure. Would like to get the information in front of someone who might be interested and able to do something about it. Suggestions?
Re: Non-firefox browser?
On 06/10/2016 11:00 PM, terryc wrote: Are there any browsers in Debian Jessie that are not dependent on Firefox? It seems everything has been replaced or is just a cover/skin/re-paint of firefox. T.I.A. My two favorite non-firefox browsers are xombrero and qupzilla. Xombrero used to be called xxxterm. Not sure what it was called in Jessie by the time Jessie was released. I always have my sources.list set to "testing" rather than any of the nicknames, so I'm never quite sure what a nicknamed version of Debian had in its repositories when it was released. Anyway, xombrero is a different kind of browser designed to be controlled entirely from the keyboard. Depending on your preferences, it might work for you. It's very fast. Qupzilla is new to me. It got installed when I decided to drop Xfce and switch to lxqt. It is extremely fast, maybe the fastest graphical browser I've seen -- at least on my systems. Hope you find something to suit you.
