Re: How can we change the keyboard layout? (was: what keyboard do you use?)
On Mon, 05 Feb 2024 21:06:30 +0100 hw wrote: > Yes, it's a misunderstanding: How can we change the keyboard layout? I recently dug into this because I am running Debian on a Chromebook, and I wanted to map the Google-key (located next to the A key, where you usually expect Caps-Lock to be) to be a Ctrl, for Emacs-Correctness. I wanted a solution that would also work when I used an external keyboard (which has an actual CapsLock next to the A), and would work both in X and in console mode. The solution I found, which should work when using Wayland as well, was to customize the lowlevel scancode-to-keycode mapping that is managed by udev. You can have different remappings for different keyboard models. This keymapping system is very powerful, but somewhat ideosyncratic, and somewhat poorly documented. And it's an edit-the-configfile system; I'm not aware of any GUI config tools for it. It took me over 2 hours to figure out and set up, after which I had a scrambled pile of notes (in a text file) but not the energy to clean them up. The next time I do it I expect it'll take me about an hour (if the same process still applies) instead of the 15 minutes it would take if I did a proper job of documenting it for myself. Some of the webpages in my notes that I remember being useful are: https://wiki.archlinux.org/title/Keyboard_input https://yulistic.gitlab.io/2017/12/linux-keymapping-with-udev-hwdb/ (including some of the comments that contain more recent info) https://medium.com/@canadaduane/key-remapping-in-linux-2021-edition-47320999d2aa Some somewhat-informative files on my computer were /lib/udev/hwdb.d/60-keyboard.hwdb (comes with udev) /usr/include/linux/input-event-codes.h (comes with linux-libc-dev package) Gotchas include: Some things *must* be in lowercase (keycodes, I think?) Some things *must* be in uppercase (certain hexadecimal stuff?) For best results, triple-check that the case you use is exactly the same as the example/sample config files. If you get this wrong, udev will just ignore the erroneous parts of your config file, (and you might think it just didn't see it) instead of giving an error message.
Re: Running 32 bit apps on 64 bit debian
On Sat, 18 Nov 2023 23:58:55 -0800 Van Snyder wrote: > I'm trying run 32 bit LinuxSusser on 64 bit Debian 12 bookworm. Have you tried running a 32-bit app that was installed via apt/dpkg ? If not, I'd recommend installing a simple 32-bit app. Two things that may happen: * it may cause the package manager to install some other packages that will fix the problem affecting 32-bit LinuxSusser. * after installing the 32-bit app, that doesn't run either, in which case investigating why the fully-debian-supported 32-bit app doesn't work, may be a useful next step. For simplicity's sake, I'd recommend a 32-bit package that you don't already have a 64-bit version installed for, that also has very few dependencies. Some candidates I would suggest are: ftp dc lsdvd I strongly suspect there's at least one of those three that you don't already have installed as a 64-bit package, and all three have relatively few dependencies.
Re: WORKAROUND (longish): was bookworm and network connections
On Sat 02 Sep 2023 at 19:37:22 +0100, Brian wrote: > On Sat 02 Sep 2023 at 08:19:56 -0600, D. R. Evans wrote: > > [...] > > > I will file a bug report. > > You have filed the report against general. This is a non-optimal > package. Someone may or may not move it to a better place. > > Doing it for yourself: > > Send a mail to > > cont...@bugs.debian.org > > Ib the mail body put > > ressign 1051086 installation-report > thanks Sorry. That's "reassign". -- Brian.
Re: WORKAROUND (longish): was bookworm and network connections
On Sat 02 Sep 2023 at 08:19:56 -0600, D. R. Evans wrote: [...] > I will file a bug report. You have filed the report against general. This is a non-optimal package. Someone may or may not move it to a better place. Doing it for yourself: Send a mail to cont...@bugs.debian.org Ib the mail body put ressign 1051086 installation-report thanks -- Brian.
Re: bookworm and network connections
On Fri 01 Sep 2023 at 22:32:00 +, Andy Smith wrote: > Hello, > > On Fri, Sep 01, 2023 at 04:16:46PM -0600, D. R. Evans wrote: > > I don't think that debian has used used /etc/network/interfaces for a while, > > at least not by default. > > All of my Debian servers (and desktops) have an > /etc/network/interfaces file and ifupdown installed. It depends upon > choices made in the installer as to whether ifupdown is installed at > all. Installation over ethernet, no DE - ifupdown provided. Installation over ethernet or wireless with a DE - network-manager provided. Installation over wireless without a DE - nothing provided, that is, no networking. -- Brian.
Re: bookworm and network connections
On Fri 01 Sep 2023 at 16:56:42 -0600, D. R. Evans wrote: > Michel Verdier wrote on 9/1/23 15:06: > > > > > If you want old names put in /etc/default/grub > > > > GRUB_CMDLINE_LINUX="net.ifnames=0" > > > > Nice to know, but I'll stay with the new names, I think. > > > network manager is good for changing networks. For a server the network > > must not change normally. So you could put configuration in > > /etc/network/interfaces.d/ with something like : > > > > auto enp11s0 > > iface enp11s0 inet static > > mtu 1500 > > metric 101 > > address 209.97.232.18/24 > > netmask 255.255.255.0 > > gateway 209.97.232.1 > > > > auto enp12s0 > > iface enp12s0 inet static > > mtu 1500 > > metric 100 > > address 192.168.0.1/24 > > netmask 255.255.0.0 > > > > When I'm feeling less tired and prone to making a mistake, I'll do this. > > The old method seems so much simpler, so I'd be happy to go back to it. It > seems that enough people are using it that it doesn't seem likely that it'll > go away anytime soon. The netmask line is unneeded. See interfaces(5). THe loopback stanza is also unneeded. See the changelog for ifupdown. -- Brian.
Debian 12 Fresh Install
Hello, I have just installed Debian 12 onto my server however it boots normally, but when its in the log in screen and i move my mouse the screen just turns off. Can you help me with this please. I use a VGA monitor for the server. Kind regards
Re: /etc/resolv.conf changes every booting time
On Mon 07 Aug 2023 at 17:53:41 -0400, gene heskett wrote: > On 8/7/23 14:57, Brian wrote: > > On Sun 06 Aug 2023 at 20:50:26 -0400, gene heskett wrote: > > > > [...] > > > > > Sorry you are so offended by a hosts file user Andy, but when the guys > > > > Did someone mention a hosts file? Is this an attempt to move discussion on > > to a different toic? I thought 'chattr -i' and the wisdom of using it was > > under discussion. > > > Its all related to networking. A pathetic response. > > My experience is that 'chattr -i' cripples the ability of my laptop to roam > > on other networks. > > > I do not own a lappy. The last one I had, an hp I paid about $1500 for, was > so poorly supported that when I went out someplace as a consulting engineer, > had to borrow a modem from the motel just to talk to their wifi about 50% of > the time. The rest of the time the wifi needed a reboot. Even windows xp > could not make the broadcom radio in it work. Its battery was as problematic > as the windows it came with, and when it died I tossed it. My expertise as a > broadcast consultant went out of date when the US went digital in mid-2008. > Now I just keep our local Ma and Pa daytimer on the air. I also don't have a > hell phone. Even more pathetic. Taking one word (laptop) and making it central is typical of your style of response. All me, me, me. -- Brian.
Re: /etc/resolv.conf changes every booting time
On Sun 06 Aug 2023 at 20:50:26 -0400, gene heskett wrote: [...] > Sorry you are so offended by a hosts file user Andy, but when the guys Did someone mention a hosts file? Is this an attempt to move discussion on to a different toic? I thought 'chattr -i' and the wisdom of using it was under discussion. My experience is that 'chattr -i' cripples the ability of my laptop to roam on other networks. -- Brian.
Re: Crossgrade instructions seem broken
There's two approaches I would consider here: If you know exactly which packages you want downloaded, I think you can use "apt-get download" to just download the packages you tell it to, and it will ignore all dependency requirements, and not download any other packages. This would be a partial improvement over using wget. If you want apt to download the packages you ask for and figure out what other packages it should download so that all the dependencies can be satisfied, then you may have to fix your "apt --download-only" invocation. I would try going from > #apt --download-only install dpkg:amd64 tar:amd64 apt:amd64 to something like apt --download-only install dpkg:amd64 tar:amd64 apt:amd64 dpkg:i386- tar:i386- apt:i386- It seems to me that apt is (ignoring the --download-only at this point of the process) assuming that you are asking to install a _second_ instance of dpkg, a _second_ instance of tar, and a second instance of apt, and deciding that that is not possible/allowed. So telling it explicitly to find a solution that involves uninstalling the i386 versions of those packages may allow it to proceed to the "actually do something" part of the process, where it will notice the "--download-only" part, and download the debs for the packages it decided you need to install, and do nothing for the packages it decided you need to uninstall. I'm not 100% sure about all of this, in part because my experience is with "apt-get" instead of "apt".
Re: logging no longer standard?
On Sat 05 Aug 2023 at 08:56:36 -0400, Carl Fink wrote: > On 8/5/23 02:54, Michel Verdier wrote: > > On 2023-08-04, Carl Fink wrote: > > > > > Today, on my Bullseye system, X crashed and restarted. Naturally, I > > > thought > > > I'd check my logs to see if I could find out why. > > > > > > Well, no ... because syslog does not exist. > > If you don't have syslog your logs will be on journald. > > But X logs could be in /var/log/Xorg.0.log or > > ~/.xsession-error or ~/.local/share/xorg/Xorg.0.log > It is highly probable that I'm being grumpy because Debian changed something > that > I was used to for decades, without my realizing it. I'm more interested in > *using* my > computer than learning whole new paradigms about, say, logging. Changing > things > will *always* be perceived as friction unless someone explains clearly why > it makes > sense, to me personally. Does this clarify? https://wiki.debian.org/Rsyslog#Deprecation_in_Bookworm
Re: reportbug - don't know what package to cite
On Sat 29 Jul 2023 at 11:35:00 -0500, Will Stites wrote:
> Hi. I tried to use reportbug to um, report a bug, but I don't know what
> package is at fault.
Maybe it's a bug; maybe it's not. I have three similar thin clients (t630)
and other ones that do not give any problem.. I would concentrate on getting
yours into shape.
> Briefly, I installed Debian 12 using debian-12.0.0-amd64-netinst.iso on a
> Hewlett-Packard T620 thin client. The installation went all right and the
> system booted into Bookworm. After doing some setup, I shut down
> (correctly). Next time I started the machine, it indicated a hardware
> failure. Machine would not respond to keys to invoke system info, BIOS
> setup, or self-tests.
>
> Tried again with a second instance of the T620. Same result, except this
> time after the apparent hardware failure, I was able to reach the BIOS setup
> and on the advice from an expert on Debian User Forums ("lewulff"),
> installed Debian 11, D-11 is working great. lewulff said that he has noticed
> a difference in how Debian 12 vs. 11 works with UEFI.
>
> I believe that the developers will want to fix this - maybe they're already
> aware of the issue, but I don't know how to tell.
D-11 works. Upgrade it to D-12 and see what happens.
--
Brian.
Re: Is it possible to downgrade openssl?
On Fri 28 Jul 2023 at 16:04:10 -0400, Patrick Wiseman wrote: > I have an AppImage from Creality which segfaults with a QT ssl error. > Googling tells me that the latest version of OpenSSL (3.x) omits some X509 > functionality, which can be found in OpenSSL-1.1. (And someone reports that > installing it solves the problem.) But I can't find that package. Is there > any way to revert to an earlier version of OpenSSL? I'm on an up-to-date > bookworm system. Install from https://snapshot.debian.org/. -- Brian.
Re: why is os-prober disabled by default
On Fri 14 Jul 2023 at 21:41:39 +0300, Teemu Likonen wrote: > * 2023-07-14 20:32:41+0200, digitalmail...@gmx.de wrote: > > > Is there a reason why GRUB_DISABLE_OS_PROBER=false in > > /etc/default/grub is commented by default after installation of > > bookworm or grub? > > Yes. Release notes document tells about it briefly: > > 5.1.11. GRUB no longer runs os-prober by default > > For a long time, grub has used the os-prober package to detect other > operating systems installed on a computer so that it can add them to > the boot menu. Unfortunately, that can be problematic in certain > cases (e.g. where guest virtual machines are running), so this has > now been disabled by default in the latest upstream release. > > https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#grub-os-prober Most Debian users experience of guest virtual machines is likely to be minimal, so the impact of having GRUB_DISABLE_OS_PROBER=false falls on the majority. The change is is an upstream one and Debian tends not to go against such changes. This is the likely reason for not altering what upstream has determined. The reason for upstream's decision appears to be: os-prober is inherently insecure as it mounts all partitions on your disk using grub-mount to check them for other OS, which is not a nice thing to do as root as you can exploit bugs in the filesystem code easily. -- Brian
Re: configuring zathura's print preview
On Mon 10 Jul 2023 at 15:07:13 -0500, David Wright wrote: > On Mon 10 Jul 2023 at 10:41:36 (-0700), Paul Scott wrote: > > On 7/10/23 5:06 AM, Brian wrote: > > > Look carefully. I think you mean > > > > > >lp -o media=letter > > > > > > This sets the page size and does not do scaling. > > > > > Of course you're correct. My mistake. > > > > This still leaves me with finding a way to scale. I'm sure there are > > several PDF tools that do it and I will use those when whichever print > > dialog Zathura uses fails me with font problems. > > I use pdfjam from texlive-extra-utils. It can scale, shift, rotate, > etc. It has rather a lot of options, so I use it through scripts. > Commandline recall (ie readline) is also useful for trial and error. > > https://github.com/rrthomas/pdfjam > > https://github.com/rrthomas/pdfjam/blob/master/pdfjam-help.txt I do not use anything for scaling, but pdfarranger offers the facility. GUI only. -- Brian.
Re: configuring zathura's print preview
On Sun 09 Jul 2023 at 10:42:52 -0700, Paul Scott wrote: > On 7/9/23 4:40 AM, Brian wrote: [...] > > The file displayed by zathura is not the file that is sent to the printing > > system. The latter can be viewed by using Print to File. > > > > The print dialog converts your PDF to a new PDF with Cairo Graphics. Scaling > > is also done by Cairo Graphics. CUPS is not involved. > > That's good to know and seems somewhat illogical! Would it be reasonable to > ask if you know why? Zathura uses the GTK print dialog, as do many other applications. GTK has to deal with a variety of file formats that the application can dispay. Let's take firefox. It can display html files. Sending an html file to the printing system is a recipe for disappointment (usually). CUPS is unable to process and render it as displayed. GTK produces a PDF of the page. CUPS is happy. The same comment also applies to PNG files. > Pdffonts does indeed tell me that there are illegal characters in the PDF > created by Print to File. > > Now that I know that the paper size is correct I see that "lp" prints my > file perfectly. The fonts are embedded in the original PDF. CUPS prints what it is given. > If the file were not the correct size I would have liked to use the scaling > and page choices in the print dialog. > > Does > > lp -o "letter" > > scale the document? This is an option unknown to CUPS. It will be ignored. -- Brian.
Re: configuring zathura's print preview
On Sat 08 Jul 2023 at 22:28:52 -0700, Paul Scott wrote: > > On 7/8/23 3:58 PM, Charles Curley wrote: > > On Sat, 8 Jul 2023 13:35:43 -0700 > > Paul Scott wrote: > > > > > Can someone please direct me to documentation for or tell me how to > > > set what program does print preview for Zathura? I would Zathura > > > would be a possibility. > > charles@jhegaala:~$ apt-cache show zathura | grep -i homepage > > Homepage: https://pwmt.org/projects/zathura > > charles@jhegaala:~$ > Thank you! > > > > > My problem is discovering whether a PDF will fit well enough on an > > > 8"x11" sheet of paper. > > Most PDF viewers will let you see the properties, which should include > > the page size. And, depending on your printer software (CUPS on > > Debian), you may be able to scale a document. > > > So far I have found the Zathura "info" command but it doesn't tell me the > page size. Install poppler-utils and use pdfinfo and pdffonts. > The print dialog does indeed give me the ability to scale. > > Another problem I am now having looks like a missing font. Zathura displays > the document (music) fine but when I print (CUPS) some of the graphical > information is missing. The file displayed by zathura is not the file that is sent to the printing system. The latter can be viewed by using Print to File. The print dialog converts your PDF to a new PDF with Cairo Graphics. Scaling is also done by Cairo Graphics. CUPS is not involved. -- Brian.
Re: bookworm upgrade report: boring
On Mon 12 Jun 2023 at 08:50:54 -0400, Celejar wrote: > On Sun, 11 Jun 2023 12:31:31 -0400 > Dan Ritter wrote: > > > > > The machine I am typing on has been upgraded from bullseye to > > bookworm. TL;DR: boring, which is good. > > ... > > > I read the release notes. > > > > Changed sources.list entries. > > > > Ran apt update. > > > > I ran apt upgrade --without-new-pkgs before apt full-upgrade. > > Then I rebooted. > > > > Everything's working. In the end, I didn't make any config > > changes (left everything as "keep current config"). > > This is the part that always stresses me out; I often have changes in > the default config files that I don't want to lose, but I'm also > worried about not getting the latest versions of the config files. I > usually try to accept the new files and manually bring in any important > changes I've made to the old ones, but this takes time and patience to > do right, and things can break if not done right :) I have taken to assuming that detected changes are due to my efforts and reject the package version offered. Less stressful and speeds up the installation. If necessary, I investigate afterwards. -- Brian.
Re: Fwd: my cv shared online
On Wed 07 Jun 2023 at 10:06:56 -0400, Dan Ritter wrote: > Klevin Kona wrote: > > Hello team > > > > A quick research in duckduckgo i found my cv shared online, please can you > > delete it? > > > > https://lists.debian.org/deity/2013/07/pdfftyX0FXMVD.pdf > > It does not appear to be there now, if it ever was. It certainly was there :). See https://lists.debian.org/debian-www/2023/06/msg6.html -- Brian.
Re: A hypervisor for a headless server?
On Fri, 2 Jun 2023 02:39:43 + Victor Sudakov wrote: > Please don't just say "kvm". I've tried installing different > combinations of "qemu-kvm", "virt-manager" etc and they all depend on > dozens of GUI tools. I think the problem that you are running into with qemu-kvm is that while the package doesn't "require" GUI tools, they do "recommend" them. If you turn off "install-recommends" in your apt config, you may find that you can install it without the GUI tools. "virt-manager", on the other hand, appears to be fundamentally a GUI tool.
Re: Bookworm CUPS Printing Revisited
On Thu 18 May 2023 at 14:26:13 -0600, Charles Curley wrote: > On Thu, 18 May 2023 15:09:00 +0100 > Brian wrote: [...] > > I haven't any idea why M234 does not work from the dialog. It might be > > an issue with the GTK version. Personally, I would prefer that Firefox > > was uused to confirm or not. > > I installed xfce and firefox, and ran firefox on the computer (rather > than over ssh to another computer). Firefox showed three queues: PDF, > and two printer queues. The PDF one worked. The other two failed > silently. The printer never woke up for either. The PDF queue is not part of the printing system. > Firefox also allows printing from the system printer dialog. When I > selected that, it showed the same three queues. The two printer queues > had error messages. > > For HP_Laserjet_MFP_m234sdw_C0FB67, "No destination host name supplied > by cups-browserd for printer "HP_Las..." cups-browserd uses mDNS to get the destination host name. OK, it can come off the rails at times, but ideapc is happy enough with it. I'll again mention that neiher cups-browserd nor a manual queue is required for printing; I gave a test of this in another post. CUPS should form a temporary queue. > For HP_Laserjet_MFP_m234sdw_C0FB67@hpbm234ethernet.local, I got an > error message, which disappeared before I could write it down. There > is now no error message. I tried printing to that, and this time the > printer came up, showed its "busy" indicator, and did nothing. This is often an indication that the dialog is unable to query the printer. It shouldn't happen on bookworm. > > An alternative URI for M234 is > > > > ipp://192.168.100.134/ipp/print > > > > and the previous lpadmin command could be run with this. It's OK as > > long as the IP does not change and it also cuts out the moving part > > of DNS-SD resolution. > > That worked: > > root@dragon:~# lpadmin -p M234ip -v "ipp://192.168.100.134/ipp/print" > -E -m everywhere root@dragon:~# lp -d M234ip > /usr/share/cups/data/form_english.pdf request id is M234ip-20 (1 > file(s)) root@dragon:~# > > It also showed up in Firefox's system printer dialog. I printed to > it. Nothing. I then printed from Firefox's internal printer > dialog. That worked. The difference between M234 and M234ip is that the latter does not need to use resolving to get the IP of the ptinter. The queue should work in Abiword too. > > The problem with the GTK dialog is that it never handled its > > relationship with CUUPS correctly before bullseye (APIs and all > > that). However, it *always* got along with manually set up queues, > > which M234 is. > > > > That isn't what I see here. Maybe not, but it is still the case that it was GTK's handling of printer discovery that was the issue. > John Doe seems to think MDNS doesn't like my network > setup. https://lists.debian.org/debian-user/2023/05/msg00767.html I queried hpm234ethernet.localdomain but you seemed happy with it, so I let it go. -- Brian.
Re: Bookworm CUPS Printing Revisited
On Wed 17 May 2023 at 13:10:21 -0600, Charles Curley wrote: > Thanks to Brian on the thread "Re: CUPS on > Bullseye and Bookworm" I now have CUPS working on dragon, my bookworm > i386 architecture laptop. > > Or I should say, CUPS printing is more or less working but something > else (GTK printing?) isn't. I can find the driverless printer on the > network, create a print queue for it, and print to it. > > root@dragon:~# driverless > ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/ > root@dragon:~# lpadmin -p M234 -v > "ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/" -E -m > everywhere > root@dragon:~# lp -d M234 /usr/share/cups/data/form_english.pdf > request id is M234-3 (1 file(s)) > root@dragon:~# lp -d M234 /etc/nsswitch.conf > request id is M234-4 (1 file(s)) > root@dragon:~# > > So far, so good. > > I have two problems: > > 1) I cannot print from abiword. abiword finds three printer queues: > print to file (which works), M234 (as previously set up), and > HP_Laserjet_MFP_M234dsw_COFB67. The two printer queues do not work. The > former see the printer light up, the "busy" indicator light up briefly, > then nothing. The latter evinces no action on the printer at all. I haven't any idea why M234 does not work from the dialog. It might be an issue with the GTK version. Personally, I would prefer that Firefox was uused to confirm or not. An alternative URI for M234 is ipp://192.168.100.134/ipp/print and the previous lpadmin command could be run with this. It's OK as long as the IP does not change and it also cuts out the moving part of DNS-SD resolution. > (I selected abiword rather than LibreOffice because LO is a bit of a > resource hog.) LibreOffice has its own dialog with its own issues. > 2) When I print from the command line, I get results printing to M234. > But when I try printing to the other queue (directly to the printer as > I understand it), I see: Strictly speaking CUPS never prints directly to a printer but via a queue, whether it be manually set up, auto set up or temporary. > charles@dragon:~$ lp -d HP_Laserjet_MFP_M234dsw_C0FB67 ~/test.document.pdf > lp: Error - The printer or class does not exist. > charles@dragon:~$ Pass on this for the moment. > I copied the printer name from abiword's list of available printers. Is > that the correct way to specify a driverless printer? I also tried > copying and pasting the ipps:// and dnssd:// printers shown by lpinfo > -v. Same error. > > According to https://wiki.debian.org/CUPSDriverlessPrinting, "the GTK > print dialog on buster and before (firefox and evince, for example), > has its own way of dealing with a network printer. Unfortunately, > applications that print through this dialog do not make use of CUPS' > temporary queue formation. To have a queue for an IPP printer visible > and usable, users should manually set up a queue with lpadmin, the CUPS > web interface or system-config-printer or rely on cups-browsed to do it > for them. The situation on bullseye and later has improved." Regression? The problem with the GTK dialog is that it never handled its relationship with CUUPS correctly before bullseye (APIs and all that). However, it *always* got along with manually set up queues, which M234 is. -- Brian.
Re: EPSON ET M 1120 new printer: If You can read this, you areusingthe wrong driver
On Tue 16 May 2023 at 11:24:05 -0400, gene heskett wrote: > On 5/16/23 10:35, Brian wrote: > > On Tue 16 May 2023 at 09:58:45 -0400, gene heskett wrote: > > > > > On 5/16/23 08:29, Andrew M.A. Cater wrote: > > > > [...] > > > > > > But yes, this is going nowhere - and there is no lsb package in Debian, > > > > I think. > > > > > > > > Andy > > > > > > > > . > > > Couple that with my recent discovery that debian seems to be shipping the > > > cups from apple, last updated by its author in 2019. > > > > Did your investigations involve reading a changelog? > > whazzat? Trolling thru /usr/share/ looking for those is a pita. And far more > often, a waste of time, not containing a useful amount of data. Mmm. That's a novel way to dispose of the usefulness of changelogs and not have to acknowledge what appears to be disinformation. > > > Given that clue, I would be surprised to find a "cups" driver in the > > > debian > > > repo's capable of driving a newer epson product. > > > > Please give yourself a treat and use 'lpinfo -m' :). > > > Thanks, I just did and it appears to show both brothers installed drivers > and the driverless, but driverless is not complete for either printer, where > the makers ppd is. for the laser, toner would last forever, very thin, > faint, had to read output, the mfcj6920dw only uses top tray, which is $8 > for 50 sheets glossy photo paper. Tray 2, the bottom one has up to 350 pages > of duplex copy paper, the obvious choice, but the driverless driver doesn't > use it. You made a comment on Epson products and Debian. I was rather hoping you would address that rather than bringing up your concern with a possibly buggy printer from another vendor. -- Brian.
Re: EPSON ET M 1120 new printer: If You can read this, you are usingthe wrong driver
On Tue 16 May 2023 at 09:58:45 -0400, gene heskett wrote: > On 5/16/23 08:29, Andrew M.A. Cater wrote: [...] > > But yes, this is going nowhere - and there is no lsb package in Debian, I > > think. > > > > Andy > > > > . > Couple that with my recent discovery that debian seems to be shipping the > cups from apple, last updated by its author in 2019. Did your investigations involve reading a changelog? > Given that clue, I would be surprised to find a "cups" driver in the debian > repo's capable of driving a newer epson product. Please give yourself a treat and use 'lpinfo -m' :). -- Brian.
Re: CUPS on Bullseye and Bookworm
On Mon 15 May 2023 at 18:29:12 +0100, Brian wrote: > On Mon 15 May 2023 at 16:33:42 +0100, Brian wrote: > > [...] > > > Good. The issue is solved, but how do you feel about being adventurous? > > > > Assuming you have deleted the three non-working queues,'lpstat -a' and > > s-c-p should show only M234. On dragon do > > > > systemctl stop cups-browsed > > > > Check that 'lpstat -l -e' still shows the printer as > > > >HP_LaserJet_MFP_M234sdw_C0FB67 > > > > * Now print: 'lp -d HP_LaserJet_MFP_M234sdw_C0FB67 /etc/nsswitch.conf'. > > * Immediately afterwards do 'lpstat -a'. What do you observe? > > * Run 'lpstat -a' a minute or so later. What do you observe? > > Thinking on: the test can be carried out withoit using papaer and ink. > For the first step: > > * Execute 'lpoptions -p HP_LaserJet_MFP_M234sdw_C0FB67 -l'. For illustrative purposes on a machine without cups-browsed: brian@test-new:~$ lpstat -a lpstat: No destinations added. brian@test-new:~$ There aren't any local print queues. brian@test-new:~$ lpstat -e ENVY4500 ENVY4500_USB RX420 brian@test-new:~$ Shows all available destinations on the local network. These are the names of prospective (on-demand) queues. brian@test-new:~$ lpoptions -p envy4500 -l PageSize/Media Size: 100x150mm 111.76x152.4mm 3.5x5 3.5x5.Borderless 3x5 4x6 4x6.Borderless 5x7 5x7.Borderless 5x8 8x10 8x10.Borderless *A4 A4.Borderless A5 A6 A6.Borderless B5 Env10 EnvA2 EnvC5 EnvC6 EnvChou3 EnvChou4 EnvDL EnvMonarch EnvPersonal Executive ISOB5 Legal Letter Letter.Borderless Postcard Postcard.Borderless Statement Custom.WIDTHxHEIGHT MediaType/Media Type: *Stationery PhotographicGlossy cupsPrintQuality/cupsPrintQuality: Draft *Normal High ColorModel/Output Mode: *RGB Gray Gray16 DeviceGray DeviceRGB AdobeRGB Duplex/Duplex: *None DuplexNoTumble DuplexTumble OutputBin/OutputBin: *FaceUp brian@test-new:~$ The destination has been contacted and querued for the device's attributes. brian@test-new:~$ lpstat -a ENVY4500 accepting requests since Tue 16 May 2023 14:50:01 BST brian@test-new:~$ A local queue for the ENVY4500 destination has been created. Unlike a queue created manually or with cups-browsed it is a *temporary* queue. Just over a minute later: brian@test-new:~$ lpstat -a lpstat: No destinations added. brian@test-new:~$ This is the future of printing and it is here now. No manual queues. No cups-browsed. -- Brian.
Re: CUPS on Bullseye and Bookworm
On Mon 15 May 2023 at 08:24:28 -0600, Charles Curley wrote: > On Mon, 15 May 2023 12:09:33 +0100 > Brian wrote: [...] > Ah, OK. So can I get rid of the three queues and print directly to the > printer? Indeed you can! 'lpstat -l -e' should show only the printer on the network and a working local queue, M234. > > Execute > > > > lpadmin -p M234 -v "URI" -E -m everywhere > > > > Test with > > > > lp -d M234 /etc/nsswitch.conf > > root@dragon:~# lp -d M234 /etc/nsswitch.conf > lp: Error - The printer or class does not exist. > root@dragon:~# lpadmin -p M234 -v "URI" -E -m everywhere > lpadmin: Bad device-uri "URI". > root@dragon:~# lpadmin -p M234 -v > "ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/" -E -m > everywhere > root@dragon:~# lp -d M234 /etc/nsswitch.conf > request id is M234-25 (1 file(s)) > root@dragon:~# > > And that printed. And I see a new queue on dragon's > system-config-printer. Good. The issue is solved, but how do you feel about being adventurous? Assuming you have deleted the three non-working queues,'lpstat -a' and s-c-p should show only M234. On dragon do systemctl stop cups-browsed Check that 'lpstat -l -e' still shows the printer as HP_LaserJet_MFP_M234sdw_C0FB67 * Now print: 'lp -d HP_LaserJet_MFP_M234sdw_C0FB67 /etc/nsswitch.conf'. * Immediately afterwards do 'lpstat -a'. What do you observe? * Run 'lpstat -a' a minute or so later. What do you observe? -- Brian.
Re: CUPS on Bullseye and Bookworm
On Mon 15 May 2023 at 08:07:12 -0600, Charles Curley wrote: > On Mon, 15 May 2023 14:22:14 +0100 > Brian wrote: > > > > Consider: the printer can be discovered via mDNS/DNS-SD by all > > machines on the network. ideapc does this and hasn't any difficulty > > printing. So why set up a server when hawk will see the printer as > > ideapc does? > > Possibly just legacy habits. I'm not accustomed to this automation. Possibly. You are not alone in this. The thinking appears to be: "I have an HP printer; therefore I must use HPLIP". Oftern it is downhill from there. Unlees there are special needs, HPLIP is redundant with a modern MFP. > > Additionally, assuming the printer provides the IPP-over-USB protocol, > > the USB queue will not work. See > > > > https://wiki.debian.org/CUPSDriverlessPrinting > > > > [...] > > > > The two URIs are equivalent. > > > > [...] > > > > > > implicitclass://HP_LaserJet_MFP_M234sdw_C0FB67_/ > > > > cups-browsed has automatically set up a queue. Unless it is having an > > off-day, it should do the same on hawk and dragon. > > I have no idea what's going on here. I now see such a queue on hawk but > not dragon. Possibly the fact that I rebooted hawk yesterday had > something to do with it? I will reboot dragon later today and see if > that makes a difference. cups-browsed works well for many users, but can be a little temperamental. > > [...] > > [...] > > [...] [...] > > hpm234ethernet.local? > > Again, the "localdomain" is correct. avahi-browse shows hpm234ethernet.local for the hostname. BTW, is hpm234ethernet you setting or HP's? -- Brian.
Re: CUPS on Bullseye and Bookworm
On Sun 14 May 2023 at 14:04:51 -0600, Charles Curley wrote:
> On Sun, 14 May 2023 19:48:07 +0200
> john doe wrote:
>
> > On 5/14/23 19:29, Charles Curley wrote:
> > [...]
> >
> > The below, is what I would try:
> >
> > - On the non-working client, Are you restricting outbound traffic at
> > all
>
> Not that I know of.
Blocking port 5353 (mdns) is not unknown.
> > or for testing purposes can you disable the FW?
>
> I shut the firewall down ("systemctl stop firewalld"), ran test pages.
> Same non-results, except that system-control-printer now reports:
>
> Idle - Print job canceled at printer.
>
>
> I tried increasing the logging, which involved stopping and restarting
> the cups service. In the process of doing that, the client and server
> both managed to forget the printer. I re-installed it. On the server, I
> have one instance of the printer, protocol:
>
> hp:/usb/HP_LaserJet_MFP_M232-M237?serial=VNB4J02590
Consider: the printer can be discovered via mDNS/DNS-SD by all machines
on the network. ideapc does this and hasn't any difficulty printing. So
why set up a server when hawk will see the printer as ideapc does?
Additionally, assuming the printer provides the IPP-over-USB protocol,
the USB queue will not work. See
https://wiki.debian.org/CUPSDriverlessPrinting
> On the non-working client, cups discovered two versions of the printer:
>
> dnssd://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipp._tcp.local/?uuid=d532fa73-f559-43ca-9f8e-1eef16972345
>
> ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/
>
> I have been testing both and getting the same results.
The two URIs are equivalent.
> > - How are the working clients connected to the printer (protocol
> > wise)?
>
> implicitclass://HP_LaserJet_MFP_M234sdw_C0FB67_/
cups-browsed has automatically set up a queue. Unless it is having an off-day,
it should do the same on hawk and dragon.
> > - Is the non-working client using that same protocol?
>
> Clearly not.
>
> So I had the working client discover the printer again. It offered the
> same two as I have on the non-working client. Both printed test pages.
>
> ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/
>
> dnssd://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipp._tcp.local/?uuid=d532fa73-f559-43ca-9f8e-1eef16972345
>
>
> > - If you do not use MDNS and point manually to the server, does it
> > work any better?
>
> I tried setting up a printer manually on the non-working client.
>
> ipp://hawk.localdomain/printers/HP_LaserJet_MFP_M232-M237
hawk.local would be the correct hostname.
> No test page, and I got:
>
> Processing - The printer may not exist or is unavailable at this time.
>
> However, I checked the CUPS on-line documentation, and did not find any
> documentation on how to set up a URI, so it's possible I did that
> incorrectly.
>
> I also enabled "port 9100" printing on the printer, and went directly to
> it:
That had to be explicitly done?
> socket://hpm234ethernet.localdomain:9100
hpm234ethernet.local?
--
Brian.
Re: CUPS on Bullseye and Bookworm
On Sun 14 May 2023 at 20:57:23 -0600, Charles Curley wrote: > On Sun, 14 May 2023 23:30:25 +0100 > Brian wrote: > > > On Sun 14 May 2023 at 14:04:51 -0600, Charles Curley wrote: > > > > > > We take it that dragon, hawk and the printer are network connected. > > > > Give what you get from dragon with > > > > avahi-browse -rt _ipp._tcp > > avahi-browse -rt _uscan._tcp > > driverless > > lpstat -l -e > > > > avahi-browse is in the avahi-utils package. > > > > root@dragon:~# avahi-browse -rt _ipp._tcp > + wlp2s2 IPv4 HP LaserJet MFP M234sdw (C0FB67) Internet Printer >local > = wlp2s2 IPv4 HP LaserJet MFP M234sdw (C0FB67) Internet Printer >local >hostname = [hpm234ethernet.local] >address = [192.168.100.134] >port = [631] >txt = ["mopria-certified=2.1" "mac=6c:02:e0:c0:fb:67" "usb_MDL=HP LaserJet > MFP M232-M237" "usb_MFG=HP" "TLS=1.2" "PaperMax=legal-A4" > "kind=document,envelope,photo" "UUID=d532fa73-f559-43ca-9f8e-1eef16972345" > "Fax=F" "Scan=T" "Duplex=T" "Color=F" "note=" > "adminurl=http://hpm234ethernet.local./hp/device/info_config_AirPrint.html?tab=Networking=AirPrintStatus; > "priority=10" "product=(HP LaserJet MFP M232-M237)" "ty=HP LaserJet MFP > M232-M237" "URF=V1.4,CP99,W8,OB10,PQ3-4,DM1,IS1-4,MT1-3-5,RS300-600" > "rp=ipp/print" > "pdl=application/PCLm,application/octet-stream,image/pwg-raster" "qtotal=1" > "txtvers=1"] Useful data but an aside first: The pdl= key lacks image/urf. HP claims AirPrint support for the device (URF=V1.4,...). It looks like you have been sold a pup. A firmware update? > root@dragon:~# driverless > ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/ This is the URI for the printer. You will need to substitute it later into an lpadmin command. > root@dragon:~# lpstat -l -e > HP-HP-LaserJet-MFP-M232-M237 permanent > ipp://localhost/printers/HP-HP-LaserJet-MFP-M232-M237 > dnssd://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipp._tcp.local/?uuid=d532fa73-f559-43ca-9f8e-1eef16972345 > HP-HP-LaserJet-MFP-M232-M237-2 permanent > ipp://localhost/printers/HP-HP-LaserJet-MFP-M232-M237-2 > ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/ > HP-LaserJet-MFP-M232-M237 permanent > ipp://localhost/printers/HP-LaserJet-MFP-M232-M237 > socket://hpm234ethernet.localdomain:9100 > HP_LaserJet_MFP_M234sdw_C0FB67 network none > ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/ > root@dragon:~# The first three entries are print queues (permanent) you have set up. The fourth is the printer. Execute lpadmin -p M234 -v "URI" -E -m everywhere Test with lp -d M234 /etc/nsswitch.conf -- Brian.
Re: CUPS on Bullseye and Bookworm
On Sun 14 May 2023 at 14:04:51 -0600, Charles Curley wrote:
> On Sun, 14 May 2023 19:48:07 +0200
> john doe wrote:
>
> > On 5/14/23 19:29, Charles Curley wrote:
> > [...]
> >
> > The below, is what I would try:
> >
> > - On the non-working client, Are you restricting outbound traffic at
> > all
>
> Not that I know of.
>
> > or for testing purposes can you disable the FW?
>
> I shut the firewall down ("systemctl stop firewalld"), ran test pages.
> Same non-results, except that system-control-printer now reports:
>
> Idle - Print job canceled at printer.
>
>
> I tried increasing the logging, which involved stopping and restarting
> the cups service. In the process of doing that, the client and server
> both managed to forget the printer. I re-installed it. On the server, I
> have one instance of the printer, protocol:
>
> hp:/usb/HP_LaserJet_MFP_M232-M237?serial=VNB4J02590
>
> On the non-working client, cups discovered two versions of the printer:
>
> dnssd://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipp._tcp.local/?uuid=d532fa73-f559-43ca-9f8e-1eef16972345
>
> ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/
>
> I have been testing both and getting the same results.
>
> >
> > - How are the working clients connected to the printer (protocol
> > wise)?
>
> implicitclass://HP_LaserJet_MFP_M234sdw_C0FB67_/
>
>
> > - Is the non-working client using that same protocol?
>
> Clearly not.
>
> So I had the working client discover the printer again. It offered the
> same two as I have on the non-working client. Both printed test pages.
>
> ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/
>
> dnssd://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipp._tcp.local/?uuid=d532fa73-f559-43ca-9f8e-1eef16972345
>
>
> > - If you do not use MDNS and point manually to the server, does it
> > work any better?
>
>
>
> I tried setting up a printer manually on the non-working client.
>
> ipp://hawk.localdomain/printers/HP_LaserJet_MFP_M232-M237
>
> No test page, and I got:
>
> Processing - The printer may not exist or is unavailable at this time.
>
> However, I checked the CUPS on-line documentation, and did not find any
> documentation on how to set up a URI, so it's possible I did that
> incorrectly.
>
> I also enabled "port 9100" printing on the printer, and went directly to
> it:
>
> socket://hpm234ethernet.localdomain:9100
>
> The printer spun its wheels, reported an error and stopped without
> printing. Nothing in the event log.
We take it that dragon, hawk and the printer are network connected.
Give what you get from dragon with
avahi-browse -rt _ipp._tcp
avahi-browse -rt _uscan._tcp
driverless
lpstat -l -e
avahi-browse is in the avahi-utils package.
--
Brian.
Re: SOLVED:Re: repeat of previous question thathasgoneunansweredseveraltimes.
On Fri 12 May 2023 at 15:27:21 -0400, gene heskett wrote: > On 5/12/23 14:45, Brian wrote: > > On Fri 12 May 2023 at 06:23:56 -0400, gene heskett wrote: > > > > [...] > > > > > I'm confused. There is not anything wrong with this machine as a Server. > > > ALL of this muttering and bitching has been because bookworm clients did > > > NOT > > > work. buster clients work great. > > > > "work(s)" is such vague term. I guess working and non-working are references > > to > > > > > All of my bullseye machines are locked out, printer screen at > > > localhost:631 is empty, and no printers can be found and added > > > > > How many times do I have to say it is/was a CLIENT problem that only > > > exists > > > for BOOKWORM clients. The elephant in the room that most have ignored. > > > > THe issue has been fully dealt with. In short: > > > >No local printers leads to an empty localhost:631 and 'lpstat -t'. > > > > THere isn't any issue whatsoever. You seem very reluctant to incorporate > > this > > basic fact into your thinking. THe room is empty. > > > > May we have 'lpstat -t' from a buster machine that is not bpi54? > > This is buster, running a milling machine in the garage [Informative info from a number of machines snupped.] All the displayed queues are local and have either been set up manually (ipp://...) or autmatically by cups-browsed (implicitclass://...). A manual setup on a bullseye machine would involve the raw or everywhere model. A client.conf is an is an alternative. -- Brian.
Re: SOLVED:Re: repeat of previous question that has gone unansweredseveraltimes.
On Thu 11 May 2023 at 12:08:01 -0400, gene heskett wrote: > On 5/11/23 07:07, Brian wrote: > > On Wed 10 May 2023 at 16:02:43 -0400, gene heskett wrote: > > > > > On 5/10/23 14:22, Brian wrote: > > > > On Wed 10 May 2023 at 13:18:07 -0400, gene heskett wrote: > > > > > > > > > On 5/10/23 11:29, Brian wrote: > > > > > > On Wed 10 May 2023 at 10:04:47 -0400, gene heskett wrote: > > > > > > > > > > > > > On 5/10/23 08:17, Brian wrote: > > > > > > > > > > > [...] > > > > > > > > > > Is /etc/cups/client,conf really, really needed? > > > > > > > > > > > That is the first thing cups docs tell you to do, see "printer > > > > > sharing" > > > > > > > > A link would be ever so useful. > > > > > > send browser to cups.org, click help, in right pane, click "printer > > > sharing", scroll down about a screenfull to Automatic using IPP > > > > Thanks to you and debian-u...@howorth.org.uk. Note that this page is for > > Apple > > CUPS. The one for Debian CUPS is at > > > >https://openprinting.github.io/cups/doc/sharing.html > > > Thank you for that link, the other Apple Cups link is first in a google > search, and probably close in DDG too since the search was for cups, not > openprinting as I was not then aware that Mike had moved. Apple should be > ashamed of themselves hanging onto the cups links when they are no longer > writing the authors paychecks. > > > Havong said that, it should also be noted that the /etc/cups/client.conf is > > used > > when a local spooler is not required and is presented as to be used only as > > absolutely necessary. Hardly "the first thing cups docs tell you to do". > > Why is > > it absolutely necessary in your situation? > > > > Additionally, a client.conf overrides the default local server. All the > > analysis > > in this thread has been carried out assuming a functional local server, so > > I do > > not know where that leaves us now if a client.conf has been in the mix all > > the time.. > > > I am wondering now if I shouldn't remove the other Listen directives from > cupsd.conf, isolating their influence when there are no locally connected > printers. > > Aha Got it, geany evince okular etc can now print from bpi54! Removing > the Listen localhost:631 directive from /etc/cups/cupsd.conf and inserting a > > Listen 192.168.xx.yy:631 > > made the localhost:631/printers on this machine show up in FF on bpi54, all > 5 choices from this machine. All that as root of course, and the acid test > was me as 1st user, calling up geany to edit that file, which complained it > was not writable but to print it on the B laser, which it just did. I did > have to leave active the "Listen /run/cups/cups.sock" line, it did not work > w/o that. > > I changed the LogLevel back to warn before it fills up a 64BG card, and it > seems its all Just Working. > > That warning in the paragraph above s/not be a show stopper when there is > only one machine as the Server on this local network. IMO, it should be > speced as applying to any machine that does NOT have any locally connected > printers. > > Your help, and some comments from Greg, have been very helpful. Thank you > both for bearing with me, most appreciated. You are, as uaual, treading your own path. Sometimes, it touches on mine or crosses it. Let's leave it there. The acknowledgement is gracious and appreciated. -- Brian.
Re: repeat of previous question that has gone unansweredseveraltimes.
On Wed 10 May 2023 at 13:18:07 -0400, gene heskett wrote: > On 5/10/23 11:29, Brian wrote: > > On Wed 10 May 2023 at 10:04:47 -0400, gene heskett wrote: > > > > > On 5/10/23 08:17, Brian wrote: > > > [...] > > Is /etc/cups/client,conf really, really needed? > > > That is the first thing cups docs tell you to do, see "printer sharing" A link would be ever so useful. > > > Also on the bpi's, running armbian, libnss-ldap is installed, which > > > conflicts with installing libnss-*, but did install libnss-my*, and now > > > the > > > printers have disappeared again. That does not hold water. What the heck > > > is > > > going on now? > > > > I haven't any idea and do not claim the know anything about armbian and how > > it should deal with NSS\ > > Since that comes from a debian arm64 repo. my first assumption is that its > identical. After appreciating that bpi51 has libnss-mdns installed, you might discard any assumption that nsswitch.conf on bpi54 has the same contents. -- Brian.
Re: repeat of previous question that has gone unansweredseveraltimes.
On Wed 10 May 2023 at 10:04:47 -0400, gene heskett wrote: > On 5/10/23 08:17, Brian wrote: [...] > > Your nsswitch.conf line implies libnss-mymacines and libnss-mymhostname are > > used. > > They have man pages to help you decide what parts they play on bpi54. > > They were not installed, and neither are 95% of the manpages. man-db is > installed, pinfo is installed, neither has any knowledge of the missing man > pages. dpkg -L libnss-mymacines man nss-myhostname > > What do you have on bpi51? > > bpi51 is busy, so bpi54 is being used, same iso installed both. The same iso does not mean nsswitch.conf is the same on both. In fact, I think they are not identical. > Man pages apparently are one of armbian's casualties. And avahi* and > cups-browsed has been reinstalled. When I went to bed last night, the > printers were being listed on the localhost:631/printers screen IF there is > an /etc/cups/client,conf containing the IP address:port of the shared > printers, but disappears if the machine name is used, And w/o manpages it > was not possible to find out that resolv.conf was using space separated > names and I had comma separated them. Fixed now. Is /etc/cups/client,conf really, really needed? > Also on the bpi's, running armbian, libnss-ldap is installed, which > conflicts with installing libnss-*, but did install libnss-my*, and now the > printers have disappeared again. That does not hold water. What the heck is > going on now? I haven't any idea and do not claim the know anything about armbian and how it should deal with NSS. > doing a status request on the cups stuff shows that systemd restarted cups > and nearly everything else I just checked, a few seconds after midnight last > night, and now cups at localhost:631/printers is using a white cane again. The scheduler restarts itself every 24 hours. -- Brian.
Re: repeat of previous question that has gone unansweredseveraltimes.
On Tue 09 May 2023 at 16:49:22 -0400, gene heskett wrote: > On 5/9/23 07:12, Greg Wooledge wrote: > > On Tue, May 09, 2023 at 04:06:14AM -0400, gene heskett wrote: > > > I think you have said resolv.conf Search directive doesn't work but > > > nsswitch.conf was mentioned and there is a diff between this machine and > > > one > > > of the arms. So what do I put in nsswitch.conf to make cups search the > > > hosts > > > file first? > > > > The bare minimum would be: > > > > hosts: files dns > > > > Mine contains this: > > > > hosts: files mdns4_minimal [NOTFOUND=return] dns > and my bpi54 is: > hosts: files mymachines dns myhostname bpi54 has two printers attached by USB. It also hosts four print queues that work from bpi54 and bpi51. You have a printing system that should continue working until trixie comes along. Then it will fall apart. So why this descent into GNU Name Service Switch (NSS) functionality when you are satisfied with the printing situation? Greg Wooledge's nsswitch.conf line is what would be expected on a machine having avahi-demon.service. You do not have avahi-daemon and libnss-mdns installed. That is fine. A descision has been made to create queues with vendor drivers on bpi54 manually. Your nsswitch.conf line implies libnss-mymacines and libnss-mymhostname are used. They have man pages to help you decide what parts they play on bpi54. What do you have on bpi51? -- Brian.
Re: repeat of previous question that has gone unansweredseveraltimes.
On Mon 08 May 2023 at 00:23:43 -0400, gene heskett wrote: > On 5/7/23 12:48, Brian wrote: [...] > > Please give 'lpstat -t' for bpi51 (bullseye) and a buster machine. > gene@bpi51:~$ lpstat -t > scheduler is running > system default destination: PDF > device for HLL2320D-RAW: ipp://192.168.71.3:631/printers/HLL2320D > device for PDF: cups-pdf:/ Thanks. 'lpstat -t' only ever shows *local* printers. That is, printers that have been set up (manually in this case) on the local machine. It will never discover and show printers on the network. This was mentioned earlier in this thread, but you do not appear to appreciate its significance. To be clear: HLL2320D-RAW and PDF are local printers. We set up HLL2320D-RAW (which is a working printer) togetger. Should you wish to see *all* devices (local and on the network) us lpstat -e lpstat -l -e The second command was explained earlier in the thread. [...] > gene@bpi54:~$ lpstat -t > scheduler is running > no system default destination > device for Brother_HL-L2320D_series: > usb://Brother/HL-L2320D%20series?serial=U63877H0N346913 > device for Brother_MFC-J6920DW_photo: > usb://Brother/MFC-J6920DW?serial=BROG5F229909 > device for HLL2320D: usb://Brother/HL-L2320D%20series?serial=U63877H0N346913 > device for MFCJ6920DW: usb://Brother/MFC-J6920DW?serial=BROG5F229909 These are the local printers on bpi54. All connected by USB. All set up by you and all working Summary: Everything is as it should be. Your first mail has: > All of my bullseye machines are locked out, printer screen at > localhost:631 is empty, and no printers can be found and added. > > But open a shell, and type "lpstat -t" and it gets the full list of > available printers on that same bullseye machine whose cups output is > empty. The facts as expressed are OK. Your interpretation of them is sub-optimal. A lack of understanding about what localhost:631 and 'lpstat -t' show is the root of problem and colours everything you have written here.. [...] > > Apple ceased any involvement with CUPS development and parted company with > > its Chief Printing Engineer a number of years ago. Debian CUPS is produced > > by a team led by the creator of CUPS. Your requested fix is in place :). > > If so, (this is the first I've heard of it, and I've only known Michael > since the late 1980's when we were both heavily involved in the os9 > development, a mini unix that ran of the trs-80 color computers) where do I > email now to be assured Michael will see it? Is there a new cups mailing > list? Please see our wiki. > Do you have any idea if that fix will be released for arm64 bullseye? I just > checked bpi54, no updates available since the Friday update. Ditto for the > intel busters here, but they're busters, so don't need the fix, they Just > Work. I haven't a clue about arm64. I am not even sure that CUPS is the issue. You have a classical local printer set up. It works. There are three other printers that could be set up with the same technique. Remenber - you are the one who does not want a New Architecture setup. -- Brian.
Re: EPSON ET M 1120 new printer: If You can read this, you are using the wrong driver
On Sun 07 May 2023 at 20:27:53 +, Andrew M.A. Cater wrote: I offer the following in the interest of correctness and just in case Schwibinger Michael gets even more confused or disheartened and considers going away :). > From looking on Epson's website: > > 1. They do not support this printer under Linux officially http://download.ebz.epson.net/dsc/search/01/search/searchModule Or, for a direct download https://download3.ebz.epson.net/dsc/f/03/00/14/48/15/1d37501ad39bd2b5753 \ > 2. The printer is listed as a printer supported only under Windows - lots > of variants. brian@test-new:~$ /usr/sbin/lpinfo -m | grep -i ET-M1120 escpr:0/cups/model/epson-inkjet-printer-escpr/Epson-ET-M1120_Series-epson-escpr-en.ppd \ EPSON ET-M1120 Series , Epson Inkjet Printer Driver (ESC/P-R) for Linux -- Briana.
Re: repeat of previous question that has gone unansweredseveraltimes.
On Sun 07 May 2023 at 11:26:05 -0400, gene heskett wrote: > On 5/6/23 19:29, Alex King wrote: > > Printing on Linux is poor. CUPS is poor. It doesn't work for some (a > > lot?) of people. > > > > I have a Brother HL-L2300D printer. It is connected to my (Debian > > bullseye) workstation by USB. I have CUPS installed. > > > > My printer prints sometime. Other times, it spins up (makes a noise > > like it is about to start printing), but nothing comes out. I can't get > > any useful diagnostics to tell me where the problem might be. > > > There is a light at the end of this dark tunnel, IF you are willing to > change the brand name on the printer. But in your case you've already done > that. So now do a search for brotherusa, go there and download their driver > installer, unpack it, run it sudo if needed. It will ask you for the model # > of your printer, enter it EXACTLY, the script will, if you've net access, > goto brothers site, download the exact driver your printer needs, install > it, integrating with cups perfectly but you will probably need to disable > cups-browsed as it will make the default driver the everywhere driver, > crippling 95% of the printers abilities. And from the machine the printer > is plugged into, and assuming browsed is stopped so you can use the brother > driver, it Just Works. > > However, if its to be shared, usable from other machines on your local home > network AND your other machines are also running bullseye, and some of my > arm stuff is, something is locking out the discovery of shares by cups, > hence my constant harping about it here. Other Buster machines Just Work > but in my case and to emphasize the point, an rpi4b running buster works but > no banana pi m2 running bullseye can find a printer for cups. But lpstat -t > on that same bpi running bullseye sees them all. Please give 'lpstat -t' for bpi51 (bullseye) and a buster machine. > I assume they can print, but thru an lp derivitive that means your Aunt > Tilly has to remember the exact name and all the options that go with it. > And Aunt Tilly will be back on windows next week. She, like I, just wants > HER printer to work. > > > My parents, who live some distance away have an HP inkjet printer. It > > works sometimes. Other times it doesn't. I get it set up so it's > > working and it might work for a while, but it will stop working for no > > reason. There might be several queues for the printer; some work and > > some just don't. A working queue will stop working for no discernible > > reason. Working queues will disappear, new queues will appear seemingly > > at random. The print system will default to an automatically provided > > queue that could never work, because it relies on some software > > component that is not installed etc... etc... > > > > Between my parents and my own system, I have spent 10s or 100s of hours > > trying to get a reliable printing system over decades, with many > > different printers. Maybe there were periods where printing worked OK. > > But I haven't managed to achieve reliable printing in the medium term. > > > > I read ESR https://www.catb.org/~esr/writings/cups-horror.html, and my > > personal experience is that nothing much has changed in the "driverless" > > era. > > To me, its been a wholesale slauterhouse since cups was sold to Apple. > The only fix I can see will require that we as a world wide group, decide to > monetarily support a cups like fork, getting away from the if it doesn't > suit Apple, it doesn't happen, influence. TANSTAAFL folks. If you think the > peanuts are free, its time to look at the price of the beer. Coders like to > eat, good ones should be able to afford a longer ladder up the side of the > hog... I can easily afford a $25/anum fee. > What say you? Applle ceased any involvement with CUPS development and parted company with its Chief Printing Engineer a number of years ago. Debian CUPS is produced by a team led by the creator of CUPS. Your requested fix is in place :). -- Brian.
Re: repeat of previous question that has gone unansweredseveraltimes.
On Fri 05 May 2023 at 11:40:21 -0400, gene heskett wrote: > On 5/5/23 10:08, Brian wrote: > > On Thu 04 May 2023 at 15:57:49 -0400, gene heskett wrote: > > > > > On 5/4/23 15:43, zithro wrote: > > > > On 01 May 2023 14:53, Brian wrote: > > > > [...] > > > > > > Second question: is that possible to use CUPS/printing without avahi ? > > > > > > > Absolutely, up to bullseye for both buster and bullseye, but not from > > > bullseye to bullseye. > > > > avahi-daemon is recommended by cups-daemong. Printing is *always* possible > > without its being on the system, especially if it's desired to make things > > difficult for all users. I'm afraid the remainder of the sentence is very > > misleading and amounts to nonsense. > > > What nonsense? I have repeatedly asked why printers shared from this > machine, that are seen and usable from any buster machine on my net, but > cannot be seen or used by any other bullseye machine on this same net by > localhost:631 on that bullseye machine. > > lpstat and friends can see and use them, but no cups related stuff installed > on a bullseye install can. A very general question was asked. You answered in terms of your own particular situation: * An unrevealed non-Debian OS on bpi51. * A well-known aversion to Avahi. * An aversion to the everywhere model. * An output from 'lpoptions -p HLL2320D_coyote -l' that indicates a broken system. Your conclusion is that the printing system is in itself is defective and that is reflected in your response. Their fault - not mine. > And no one can tell me why... none of the editors or pdf readers that have a > print this dialog, geany, evince, etc, can't see or use these printers. I > thought maybe we were on the trail of finding a solution, but you were happy > & went away when an lp command line worked. But way too many of the other > utils ignore any attempt to use lp if they can't use cups. For me, its a > serious problem. Yes, lp works, but I'm back to the amiga, ghostscript 5.05 > I had to build and an array of shell scripts I wrote to print a multipage > document. That is 1990 stuff. I just looked at a calendar and found its now > 2023. Seems to me that 33 years later, we should have made more progress > than I can see here. I gave you a classic printing solution because New Architecture printing fell apart *on your system*. I am very much disinclined to dig any further into the setup you have devised for printing. -- Brian.
Re: repeat of previous question that has gone unansweredseveraltimes.
On Mon 01 May 2023 at 17:53:08 -0400, gene heskett wrote: > On 5/1/23 13:34, Brian wrote: [...] > > A possible way forward is to execute > > > >sudo lpadmin -p HLL2320D-RAW -v ipp://192.168.71.3:631/printers/HLL2320D > > -E -m raw > which gets me this warning: > gene@bpi51:~$ sudo lpadmin -p HLL2320D-RAW -v > ipp://192.168.71.3:631/printers/HLL2320D -E -m raw > [sudo] password for gene: > lpadmin: Raw queues are deprecated and will stop working in a future version > of CUPS. A standard warning that is clear enough. > lpadmin: Use the 'everywhere' model for shared printers. > > And I wouldn't use the everywhere option ever as it cripples the printer > down to the lowest common performing option list, losing among other things, > the duplex ability. So it MUST use the Brother driver. Your demand is granted. -m raw uses the Brother driver on coyote. > > > > and try > > > then I ran this w/o the sudo: > >lp -d HLL2320D-RAW printer.cfg > And got this: > gene@bpi51:~$ lp -d HLL2320D-RAW printer.cfg > request id is HLL2320D-RAW-1 (1 file(s)) That's OK. > printing the file in portrait mode, full duplex, but the file is wider and I > would normally put it in landscape mode to reduce the auto-word-wrapping > confusion. Does -o landscape still work with the raw option? > > Yes, provided the -olandscape is after the -d argument. That file is a 3d > printer description for klipper, 5 pages in landscape mode. And is the > first and 2nd time I've been able to print it. Thank you very much. > Can we continue, making a shell script to do this again with all variations > available for the -o options of lp? See the lpadmin manual for how to set up different queues with differnent options on bpi51. Glad you are now printing, but you really need to fix the CUPS installation. -- Brian.
Re: repeat of previous question that has gone unansweredseveraltimes.
On Mon 01 May 2023 at 13:22:47 -0400, gene heskett wrote: > On 5/1/23 12:30, Brian wrote: [...] > > The -l option asks the queue for the specific options it offers. The > > response > > indicates something wrong with CUPS on bpi51. I haven't any problem when > > doing > > this and getting sensible outputs on my Debian unstable machine. > > Which isn't quite a 1:1 comparison as that will be bookworm shortly. > > Or, should I update the bullseyes to unstable? IDK and I'm not even sure > how... Forget about doing that. I was merely commenting that my Debian did not behave like yours. Is yours a fruit-flavoured varian? > > Assuming your buster machines (which are working) have similar setups to > > bpi51, > > Which is a bullseye machine. And has a totally different content to the > /etc/cups directory as shown by my last post, much more complex on the > bullseye installs that don't work. THe difference is highly likely to be relevant. You are grasping at straws. > > you couls try the two commands (and all the others in this thread) on one of > > those. > > > I'd think I could start by comparing cupsd.conf's, but miss And I can't see > the trees for all this forest in the way in both, but missing is a > client.conf. I think... But that is probably whats wrong, me thinking. A client.conf is unneeded on a well-behaved CUPS system that obtains info from avahi-daemon. -- Brian.
Re: repeat of previous question that has gone unansweredseveraltimes.
On Mon 01 May 2023 at 13:03:50 -0400, gene heskett wrote: > On 5/1/23 12:30, Brian wrote: > > > > Assuming your buster machines (which are working) have similar setups to > > bpi51, > > you couls try the two commands (and all the others in this thread) on one of > > those. > > > one of those machines reports this for the -l option: > > gene@sixty40:~$ lpoptions -p HLL2320D_coyote -l > PageSize/Media Size: Custom.WIDTHxHEIGHT *Letter Legal Executive > FanFoldGermanLegal A4 A5 A6 Env10 EnvMonarch EnvDL EnvC5 ISOB5 B5 ISOB6 B6 > 4x6 Postcard DoublePostcardRotated EnvYou4 195x270mm 184x260mm 197x273mm > CUSTOM1 CUSTOM2 CUSTOM3 > BrMediaType/MediaType: *PLAIN THIN THICK THICKERPAPER2 BOND ENV ENVTHICK > ENVTHIN RECYCLED > InputSlot/InputSlot: MANUAL *TRAY1 > Duplex/Duplex: DuplexTumble *DuplexNoTumble None > Resolution/Resolution: 300dpi *600dpi 2400x600dpi > TonerSaveMode/Toner Save: *OFF ON > Sleep/Sleep Time [Min.]: *PrinterDefault 2minutes 10minutes 30minutes Looks reasonable. A similar command on the server should give a similar output. The reason 'lp -d HLL2320D_coyote printer.cfg' failed is because CUPS is unable to query the HLL2320D_coyote printer for its attributes. Printing from anything else, such as Firefox, will also fail. CUPS on the bullseye machine appears to be broken. [...] A possible way forward is to execute sudo lpadmin -p HLL2320D-RAW -v ipp://192.168.71.3:631/printers/HLL2320D -E -m raw and try lp -d HLL2320D-RAW printer.cfg -- Brian.
Re: repeat of previous question that has gone unansweredseveraltimes.
On Mon 01 May 2023 at 11:39:29 -0400, gene heskett wrote: > On 5/1/23 11:28, Brian wrote: > > On Mon 01 May 2023 at 11:02:58 -0400, gene heskett wrote: > > > > > On 5/1/23 10:40, Brian wrote: > > > > [...] > > > > > > Your printing situation appears to be a sane one, so now for a test. Do > > > > > > > > lp -d HLL2320D_coyote ANY_FILE_YOU_WANT > > > > > > > Is not working, shell appears frozen but eventually returns: > > > gene@bpi51:~$ lp -d HLL2320D_coyote printer.cfg > > > lp: The printer or class does not exist. > > > > But HLL2320D_coyote does exist. It is seen in the outputs of 'lpstat -l -e' > > and 'sudo lpinfo -v'. Give > > > >lpoptopns -p HLL2320D_coyote > gene@bpi51:~$ lpoptions -p HLL2320D_coyote > device-uri=ipps://HLL2320D%20%40%20coyote._ipps._tcp.local/cups > printer-info='HLL2320D @ coyote' printer-make-and-model='Brother HL-L2320D > series' printer-type=25202710 The print queue specified by -p is queried for some information about itself. Its reponse is given and it seems a very reasonable one. > >lpoptions -p HLL2320D_coyote -l > gene@bpi51:~$ lpoptions -p HLL2320D_coyote -l > lpoptions: Unable to get PPD file for HLL2320D_coyote: The printer or class > does not exist. The -l option asks the queue for the specific options it offers. The response indicates something wrong with CUPS on bpi51. I haven't any problem when doing this and getting sensible outputs on my Debian unstable machine. Assuming your buster machines (which are working) have similar setups to bpi51, you couls try the two commands (and all the others in this thread) on one of those. -- Brian.
Re: repeat of previous question that has gone unansweredseveraltimes.
On Mon 01 May 2023 at 10:56:00 -0400, gene heskett wrote: > On 5/1/23 10:08, David Wright wrote: > > On Mon 01 May 2023 at 09:39:51 (-0400), gene heskett wrote: > > > > lpinfo -v > > > gene@bpi51:~$ lpinfo -v > > > -bash: lpinfo: command not found > > > gene@bpi51:~$ sudo apt install lpinfo > > > Reading package lists... Done > > > Building dependency tree... Done > > > Reading state information... Done > > > E: Unable to locate package lpinfo > > > > You need root: > > > ># lpinfo -v > >network beh > >network lpd > >file cups-brf:/ > >network socket > >network ipps > >network https > >network ipp > >network http > >file cups-pdf:/ > >network > > dnssd://Brother%20HL-L2390DW._ipp._tcp.local/?uuid=e3248000-80ce-11db-8000-90324b75e771 > >network ipp://Brother%20HL-L2390DW._ipp._tcp.local/ > >network lpd://BRW90324B75E771/BINARY_P1 > ># > > > > Cheers, > > David. > > > > . > Ah so > gene@bpi51:~$ sudo lpinfo -v > [sudo] password for gene: > Sorry, try again. > [sudo] password for gene: > network beh > network socket > network http > network ipps > network lpd > network https > network ipp > file cups-brf:/ > file cups-pdf:/ > network > dnssd://Brother%20HL-L2320D%20series%20%40%20coyote._ipp._tcp.local/cups?uuid=391b5af9-9bac-3249-65f0-795f553651fe > network > dnssd://Brother%20MFC-J6920DW%20%40%20coyote._ipp._tcp.local/cups?uuid=831942b6-acfd-3e55-7013-00336f687aa2 > network > dnssd://HLL2320D%20%40%20coyote._ipp._tcp.local/cups?uuid=36139eb5-df51-332f-4f80-ebf162ecc0ae > network > dnssd://MFCJ6920DW%20_tray_2%20%40%20coyote._ipp._tcp.local/cups?uuid=58daf55b-1dc3-31b0-7442-4a936bde800c > > Thats better, but does it show "why" THe network is probed and the dnssd backend of CUPS find the same four printers as 'lpsta -l -e' does. -- Brian.
Re: repeat of previous question that has gone unansweredseveraltimes.
On Mon 01 May 2023 at 11:02:58 -0400, gene heskett wrote: > On 5/1/23 10:40, Brian wrote: [...] > > Your printing situation appears to be a sane one, so now for a test. Do > > > >lp -d HLL2320D_coyote ANY_FILE_YOU_WANT > > > Is not working, shell appears frozen but eventually returns: > gene@bpi51:~$ lp -d HLL2320D_coyote printer.cfg > lp: The printer or class does not exist. But HLL2320D_coyote does exist. It is seen in the outputs of 'lpstat -l -e' and 'sudo lpinfo -v'. Give lpoptopns -p HLL2320D_coyote lpoptions -p HLL2320D_coyote -l -- Brian.
Re: repeat of previous question that has gone unanswered severaltimes.
On Mon 01 May 2023 at 09:07:53 -0500, David Wright wrote: > On Mon 01 May 2023 at 09:39:51 (-0400), gene heskett wrote: > > >lpinfo -v > > gene@bpi51:~$ lpinfo -v > > -bash: lpinfo: command not found > > gene@bpi51:~$ sudo apt install lpinfo > > Reading package lists... Done > > Building dependency tree... Done > > Reading state information... Done > > E: Unable to locate package lpinfo > > You need root: > > # lpinfo -v > network beh > network lpd > file cups-brf:/ > network socket > network ipps > network https > network ipp > network http > file cups-pdf:/ > network > dnssd://Brother%20HL-L2390DW._ipp._tcp.local/?uuid=e3248000-80ce-11db-8000-90324b75e771 > network ipp://Brother%20HL-L2390DW._ipp._tcp.local/ > network lpd://BRW90324B75E771/BINARY_P1 Indeed you do. I forgot that root privilege is required because the USB bus is probed. -- Brian.
Re: repeat of previous question that has gone unanswered severaltimes.
On Mon 01 May 2023 at 09:39:51 -0400, gene heskett wrote: > gene@bpi51:~$ lpstat -l -e > Brother_HL_L2320D_series_coyote network none > ipps://Brother%20HL-L2320D%20series%20%40%20coyote._ipps._tcp.local/cups > > Brother_MFC_J6920DW_coyote network none > ipps://Brother%20MFC-J6920DW%20%40%20coyote._ipps._tcp.local/cups > > HLL2320D_coyote network none > ipps://HLL2320D%20%40%20coyote._ipps._tcp.local/cups > > MFCJ6920DW_tray_2_coyote network none > ipps://MFCJ6920DW%20_tray_2%20%40%20coyote._ipps._tcp.local/cups There you are! CUPS sees all four print queues shared by coyote. At this stage we are golden. Note that all four are designated as "network". > PDF permanent ipp://localhost/printers/PDF cups-pdf:/ This is a manual queue (permanent) set up locally on bpi51. It isn't of any further interest. > gene@bpi51:~$ lpstat -a > PDF accepting requests since Fri 02 Dec 2022 11:13:10 PM -05 You may care to take note that 'lpstat -a' and 'lpstat -t' only show local printers (permanent) and not those that are on the network. That also goes for the Printers section at localhost:631. Local printers can also be auto-setup by cups-browsed. You do not have it installed/running. Thar's OK; there isn't any obligation (or for that matter, any need) to use it. Having mentioned it, we will now completely put it out of our minds. > gene@bpi51:~$ lpinfo -v > -bash: lpinfo: command not found sudo lpinfo -v Your printing situation appears to be a sane one, so now for a test. Do lp -d HLL2320D_coyote ANY_FILE_YOU_WANT -- Brian.
Re: repeat of previous question that has gone unanswered several times.
On Mon 01 May 2023 at 03:29:28 -0400, gene heskett wrote: > >avahi-browse -rt _ipp._tcp > gene@bpi51:~$ avahi-browse -rt _ipp._tcp > + eth0 IPv4 Brother HL-L2320D series @ coyote Internet Printer > local > + eth0 IPv4 Brother MFC-J6920DW @ coyote Internet Printer > local > + eth0 IPv4 HLL2320D @ coyote Internet Printer > local > + eth0 IPv4 MFCJ6920DW _tray_2 @ coyote Internet Printer > local You have exactly four (not five or six) print queues manually set up on the CUPS server coyote (192.168.71.3). It is assumed that when sat at coyote it is possible to print to any of Brother HL-L2320D series, Brother MFC-J6920DW, HLL2320D and MFCJ6920DW _tray_2. Im particular - can you print to HLL2320D from the server? [...] > = eth0 IPv4 HLL2320D @ coyote Internet Printer > local >hostname = [coyote.local] >address = [192.168.71.3] >port = [631] >txt = ["printer-type=0x809016" "printer-state=3" "Duplex=T" "TLS=1.2" > "UUID=36139eb5-df51-332f-4f80-ebf162ecc0ae" "URF=DM3" > "pdl=application/octet-stream,application/pdf,application/postscript,image/jpeg,image/png,image/pwg-raster,image/urf" > "product=(Brother HL-L2320D series)" "priority=0" > "adminurl=https://coyote.local.:631/printers/HLL2320D; "ty=Brother HL-L2320D > for CUPS" "rp=printers/HLL2320D" "qtotal=1" "txtvers=1"] As well as three other printers, the host bpi51 sees the shared HLL2320D @ coyote queue via mDNS/DNS-SD. All is well and good up to now. Let's have lpstat -l -e lpstat -a lpinfo -v from bpi51. -- Brian.
Re: repeat of previous question that has gone unanswered several times.
On Mon 01 May 2023 at 13:41:10 +0200, to...@tuxteam.de wrote: > On Mon, May 01, 2023 at 09:37:59AM +0200, john doe wrote: > > [...] > > > Please refrain from polluting the list when you do not get an answer. > > I think repeating a question after a while doesn't count as > "polluting". That's what debian-user is for, after all. Indeed. Persistaence has a place and may pay off. -- Brian.
Re: On strange threads [was: EPSON ET M 1120 new printer...]
On Sat 15 Apr 2023 at 15:32:30 +0200, to...@tuxteam.de wrote: > On Sat, Apr 15, 2023 at 12:50:16PM +0200, Thomas Schmitt wrote: > > [...] > > > Given the time pattern of posts and the lack of any learning progress > > in respect to proper asking Debian GNU/Linux questions i suspect that > > the mails from h...@hotmail.com are not sent with sincere intentions. > > This is a pretty strong assessment. Coming from you, I hesitate to > dismiss it right away, Tongue. Boots. Lick. > but I'd still prefer to apply a healthy dose > of Hanlon's razor. Designating a user as stupid is a no-no in my book. -- Brian.
Re: Apt sources.list
On Sat 15 Apr 2023 at 08:11:17 -0400, pa...@quillandmouse.com wrote: > Folks: > > Here is my sources.list file: > > --- > > deb http://debian.uchicago.edu/debian/ bookworm main contrib non-free > deb-src http://debian.uchicago.edu/debian/ bookworm main contrib non-free > > deb http://security.debian.org/debian-security bookworm-security main > contrib non-free deb-src http://security.debian.org/debian-security > bookworm-security main contrib non-free > > --- > > According to https://www.debian.org/releases/, bookworm at this time is > "testing". But when the next release comes, bookworm will still be > bookworm, but "testing" will be bookworm "plus". I'd like to follow > testing, regardless of the status of Debian official releases. > > So... in my sources.list, if I change "bookworm" to "testing", will it > do that, and (other than the instabilities of testing) is there any > liability to it? bookworm to testing is exactly what you want. -- Brian.
Re: EPSON ET M 1120 new printer: If You can read this, you are using the wrong driver
On Fri 14 Apr 2023 at 18:33:26 -0400, Stefan Monnier wrote: > >> The new printer is not working. > >> EPSON is saying > >> You cant use EPSON with Linux. > >> > >> Is this true? > > > > You could consider: > > > > * Stating the Debain OS being used. > > * Giving the printer make and model. > > "Subject:" says "EPSON ET M 1120" > AFAICT it's a monochrome printer from 2019 with some kind of ink tank. > Given the timescale, it probably supports driverless printing. The EPSON ET M1120 does not come with enough intelligence to be certified as AirPrintint-capable. Therefore, it may or may not be be a driverless device. The printer would need to be queried and its attributes examined to make a decision. -- Brian.
Re: EPSON ET M 1120 new printer: If You can read this, you are using the wrong driver
On Fri 14 Apr 2023 at 19:28:19 -0400, The Wanderer wrote: > On 2023-04-14 at 19:17, Brian wrote: [...] > > That's an issue for the OP, not me. > > Certainly. I was meaning that bullet-point item as an addendum to the > list you provided (which I understand to have been aimed at the OP), not > as something directed at you. Apologies. I should have taken more notice of the structure of your mail. -- Brian.
Re: EPSON ET M 1120 new printer: If You can read this, you are using the wrong driver
On Fri 14 Apr 2023 at 19:06:08 -0400, The Wanderer wrote: > On 2023-04-14 at 18:52, Brian wrote: > > > On Fri 14 Apr 2023 at 18:22:09 -0400, The Wanderer wrote: > > > >> On 2023-04-14 at 18:10, Brian wrote: > > >> > You could consider: > >> > > >> > * Stating the Debain OS being used. > >> > * Giving the printer make and model. > >> > >> The make *was* stated: Epson. > >> > >> The model may also have been stated, albeig only in the Subject line: ET > >> M1120. From a bit of Googling, the "ET" appears to stand for "EcoTank". > > > > The EPSON ET M 1120 doesn't exist. Do we have to guess its correct name as > > well > > as any other relevant information? > > When I searched for > > Epson ET M 1120 > > I got a suggestion that I may have meant "M1120" instead of the last two > search terms, and hits for the "Epson EcoTank ET M1120" and/or "Epson > EcoTank M1120", which look to be different names for the same model and > to be a fairly clear match. > > While, yes, specifying the exact name clearly would be preferable, this > is far from unreasonably difficult to figure out. I decided to take your signature as a template for my original response :). > >> > * Specifying the connection method. USB. Network. > >> > * Giving the exact error message and where it came from. > >> > >> Also: > >> > >> * Starting a new thread to discuss the matter, rather than replying > >> to an existing message deep in an existing thread, deleting the > >> body, and changing the Subject line before sending. > >> > >> (This question, and its replies, are appearing as responses to a > >> mail from Michael Stone in the 'update-initramfs' thread.) > > > > I haven't a clue what you are going on about here. Shift-L in mutt > > was used at this end. > > Your replies to the OP have been fine, AFAIK. The OP's message was > itself a reply, as can be seen by looking at its headers (In-Reply-To: > and References:), but was otherwise presented as if it had been the > start of a new thread; that is not fine, because it hides the "new > thread" inside of the existing one, at least for anyone using a threaded > view of the list of messages. That's an issue for the OP, not me. -- Brian.
Re: EPSON ET M 1120 new printer: If You can read this, you are using the wrong driver
On Fri 14 Apr 2023 at 18:22:09 -0400, The Wanderer wrote: > On 2023-04-14 at 18:10, Brian wrote: > > > On Fri 14 Apr 2023 at 14:40:33 +, Schwibinger Michael wrote: > > > >> Good afternoon. > >> The new printer is not working. > >> EPSON is saying > >> You cant use EPSON with Linux. > >> > >> Is this true? > > > > You could consider: > > > > * Stating the Debain OS being used. > > * Giving the printer make and model. > > The make *was* stated: Epson. > > The model may also have been stated, albeig only in the Subject line: ET > M1120. From a bit of Googling, the "ET" appears to stand for "EcoTank". The EPSON ET M 1120 doesn't exist. Do we have to guess its correct name as well as any other relevant information? > > * Specifying the connection method. USB. Network. > > * Giving the exact error message and where it came from. > > Also: > > * Starting a new thread to discuss the matter, rather than replying to > an existing message deep in an existing thread, deleting the body, and > changing the Subject line before sending. > > (This question, and its replies, are appearing as responses to a mail > from Michael Stone in the 'update-initramfs' thread.) I haven't a clue what you are going on about here. Shift-L in mutt was used at this end. -- Brian.
Re: How: Require root password instead of user password for GUI programs
On Fri 07 Apr 2023 at 21:09:59 +0200, to...@tuxteam.de wrote:
> On Fri, Apr 07, 2023 at 06:22:48PM +0200, B.M. wrote:
>
> [...]
>
> > PolicyKit got replaced by polkit (at least in current Debian Testing),
> > and the "old" solution with setting AdminIdentities doesn't work
> > anymore. Instead one has to add a file /etc/polkit-1/rules.d/50-
> > default.rules as follows:
> >
> > polkit.addAdminRule(function(action, subject) {
> > return ["unix-user:0"];
> > });
>
> Gah.
>
> > in order to require root credentials for admin tasks (if sudo is
> > installed).
> >
> > I hope someone finds this useful.
>
> You folks keeping up with desktop environments are
> real heroes:-)
It's a dirty job, but someone has to do it :).
--
Brian.
Re: Upgrade to Bookworm upon release, but now using backported kernel on Bullseye
On Mon 20 Mar 2023 at 10:37:01 -0400, Default User wrote: > Hi. > > I currently run Bullseye Stable using: > linux-image-6.0.0-0.deb11.6-amd64 6.0.12-1~bpo11+1 amd64 Linux 6.0 for > 64-bit PCs (signed) kernel. > > I plan to upgrade to Bookworm Stable shortly after release. Will I need to > do anything differently? > Any "gotcha's"? Any major gotchas should be in the Release Notes. -- Brian.
Re: Debian Installer: Specifying the preseed file device?
On Mon 13 Mar 2023 at 10:18:37 -0600, Charles Curley wrote: > On Mon, 13 Mar 2023 14:58:08 + > Brian wrote: > > > It is what d-i sees the partition as that is important and you > > do know in advance. That's problem 1. Problem 2 is that the hard > > disk partitions are probably ext4. At the opening stage of d-i > > I do not think ext4 drivers are available. > > Both partitions are FAT. That still leaves the first problem. How do you fancy running everything from a USB stick? -- Brian.
Re: Debian Installer: Specifying the preseed file device?
On Mon 13 Mar 2023 at 08:01:51 -0600, Charles Curley wrote: > On Mon, 13 Mar 2023 08:19:26 +0100 > wrote: > > > On Sun, Mar 12, 2023 at 04:08:28PM -0600, Charles Curley wrote: > > > I can specify the path to the preseed file when booting Debian > > > Installer (d-i). Is there any way to tell it that the preseed file > > > is on device X, say /dev/sdb1? > > > > You mean: the file is as raw data on the device? Or whithin a file > > system there? > > I mean within a file system. > > I specify what I want by entering the following at the boot prompt: > > expert auto file=/media/preseed.cfg > > Which tells d-i I want to use a specific file within a specific > directory. So far so good. > > That directory is the root of /dev/sdb1. Unfortunately, d-i finds a > partition at /dev/sdaX, mounts that, and (rightly) reports no preseed > file. Oops. > > I'd like either > > a) to specify which partition the preseed file is on (/dev/sdb1 in this > case), or It is what d-i sees the partition as that is important and you do know in advance. That's problem 1. Problem 2 is that the hard disk partitions are probably ext4. At the opening stage of d-i I do not think ext4 drivers are available. The awkward techniwue appears to be indicated. > b) have d-i sample partitions until it finds a file of that name in the > root directory of a partition. I do not think thta would be easy to do. -- Brian.
Re: PDF on debian
On Mon 13 Mar 2023 at 04:25:12 +0800, Jeremy Ardley wrote: > > On 13/3/23 03:38, Stefan Monnier wrote: > > > > Nowadays PDF is what matters: it's the standard format for driverless > > printing (along with a mix of JPEG, PWG raster, or PCLm depending on > > which driverless printing standard you're talking about). Admittedly, > > standards like IPP Everywhere require support only for the PWG raster > > and JPEG format, while the PDF format is relegated to "should be > > supported", but PDF is so pervasive and so easy to support on > > current hardware that it doesn't make much sense not to support it, > > except maybe for printers that focus on things like printing photos. > > [ Note: this is just a guess, I have no actual data to back it up :-) ] > > > I have written one printer driver in the cups system for a thermal printer. > > The processing chain in cups generated a raster bitmap image for me to > format and deliver to the printer. I didn't dig deep but I suspect the > previous stages involved postscript before raster conversion rather than > directly from a pdf stage. Suspicions don't quite cut it when writing a filter. -- Brian.
Re: PDF on debian
On Sun 12 Mar 2023 at 16:52:37 -, Curt wrote: > On 2023-03-12, Dan Ritter wrote: > >> > > >> > Many (most?) printers do not understand PostScript. The > >> > printing system itself is based on processing PDFs. > >> > > >> > >> Oh. > >> Times have changed! > >> I thought it was the other way around. > > > > You are correct, Yassine. > > > > PostScript is an interpreted language. PDF is a compressed > > archive data format which includes simplified PostScript commands, > > images, fonts, and other chunks of data. > > > > Apart from Windows-derived GDI printers, the majority of laser > > and inkjet printers have a PostScript interpreter built in, even > > if its primary use is in interpreting PDF files. > > > > https://en.wikipedia.org/wiki/PostScript > > However, the cost of implementation was high; computers output raw PS code > that > would be interpreted by the printer into a raster image at the printer's > natural resolution. This required high performance microprocessors and ample > memory. The LaserWriter used a 12 MHz Motorola 68000, making it faster than > any > of the Macintosh computers to which it attached. When the laser printer > engines > themselves cost over a thousand dollars the added cost of PS was marginal. > But > as printer mechanisms fell in price, the cost of implementing PS became too > great a fraction of overall printer cost; in addition, with desktop computers > becoming more powerful, it no longer made sense to offload the rasterization > work onto the resource-constrained printer. By 2001, few lower-end printer > models came with support for PostScript, largely due to growing competition > from much cheaper non-PostScript ink jet printers, and new software-based > methods to render PostScript images on the computer, making them suitable for > any printer; PDF, a descendant of PostScript, provides one such method, and > has > largely replaced PostScript as de facto standard for electronic document > distribution. > > On high-end printers, PostScript processors remain common, and their use can > dramatically reduce the CPU work involved in printing documents, transferring > the work of rendering PostScript images from the computer to the printer. Histoty is always interesting, but relating it to the modern situation is necessary. PostScript hasn't any special place in today's Debian printing system; it no longer has a *central* part to play in the printing process and hasn't for ten years. Its part in processing a file through the filtering system has been taken by PDF. Granted, a printer whose *PPD* stipulates PostScript will be given it, usaally through the auspices of Ghostscript. Apart from that, it hasn't any importance. Most modern printers are focussed on accepting Apple and PWG raster and PDF, whic will be fine when CUPS ceases to support PPDs in a couple of years. -- Brian.
Re: PDF on debian
On Sun 12 Mar 2023 at 11:50:15 -0400, Dan Ritter wrote: > Yassine Chaouche wrote: > > Le 3/12/23 à 14:18, Brian a écrit : > > > On Sun 12 Mar 2023 at 10:45:02 +0100, Yassine Chaouche wrote: > > > > > > > Le 3/9/23 à 15:33, Vincent Lefevre a écrit : > > > > > it is strange that the choice was to generate > > > > > PostScript and not PDF. > > > > > > > > Isn't postscript what printers read? > > > > > > Many (most?) printers do not understand PostScript. The > > > printing system itself is based on processing PDFs. > > > > > > > Oh. > > Times have changed! > > I thought it was the other way around. > > You are correct, Yassine. > > PostScript is an interpreted language. PDF is a compressed > archive data format which includes simplified PostScript commands, > images, fonts, and other chunks of data. > > Apart from Windows-derived GDI printers, the majority of laser > and inkjet printers have a PostScript interpreter built in, even > if its primary use is in interpreting PDF files. Just an indication from my records for recent printers: brian@desktop-new:~/printing/txt-records$ grep "pdl=" * | wc -l 719 brian@desktop-new:~/printing/txt-records$ grep "pdl=" * | grep "application/postscript" | wc -l 187 Hardly a majority. Additionally: PostScript interpreters do not handle PDF files. PDF firmware does that.. brian@desktop-new:~/printing/txt-records$ grep "pdl=" * | grep "application/pdf" | wc -l 398 -- Brian.
Re: home server for email box
On Fri 10 Mar 2023 at 10:52:20 -0500, Henning Follmann wrote: > On Fri, Mar 10, 2023 at 12:44:25PM +0100, to...@tuxteam.de wrote: > > On Fri, Mar 10, 2023 at 12:01:57PM +0100, Nicolas George wrote: > > > p...@ymail.ne.jp (12023-03-10): > > > > Can I setup a mail server (postfix, dovecot, dkim, rspamd etc) on this > > > > box to receive/send email normally? > > > > > > Probably not: ISP declare IP blocks attributed to clients as “domestic” > > > and a lot of important e-mail operators block them. > > > > It makes sense to check for that. But having a static routable IP > > is a strong hint that it could work. > > Well "could" is the best way to describe the chances of this working. Agrred. Having a static routeable IP is a good start, but what is in the DNS rules. > I think the best way too find out: > Check if the ISP will allow you to set the reverse DNS record matching > your chose A record. Mine was unsettable by me but the ISP was co-operative and set it up. > If they do, GREAT! If they don't, you most likely will not be happy in the > long run. My opinion is that unhappiness is guaranteed. -- Brian.
Re: PDF on debian
On Thu 09 Mar 2023 at 18:36:26 +0100, Vincent Lefevre wrote: > On 2023-03-09 18:07:24 +0100, didier gaumet wrote: > > Le 09/03/2023 à 16:11, Vincent Lefevre a écrit : > > > > >libreoffice --headless --convert-to pdf file.txt > > > > > > produces a PDF of better quality (fewer spacing issues). > > [...] > > > > Hello, > > > > I do not use it myself so I don't know it well but unoconv seems to be a > > headless Libreoffice converter with the ability to handle numerous options. > > Perhaps it is possible to have a more fine-grained conversion this way? > > unoconv seems to give the same output (or almost the same) as > "libreoffice --headless --convert-to pdf". > > I have not tried any specific option. For converting text to PDF unoconv works well. It is also the only software in Debian that, if desired, can produce PDF/A files. The possible disk usage of 700MB may not be of concern. -- Brian.
Re: PDF on debian
On Thu 09 Mar 2023 at 17:35:41 +0100, Vincent Lefevre wrote: > On 2023-03-09 15:13:21 +0000, Brian wrote: > > On Thu 09 Mar 2023 at 15:01:00 +0100, Vincent Lefevre wrote: > > > > > On 2023-03-09 13:42:22 +, Brian wrote: > > > > For a searchable PDF, I would use > > > > > > > > :execute '!/usr/lib/cups/filter/texttopdf 1 1 1 1 1 % > out.pdf' > > > > > > > > cups-filters needs to be on the system. > > > > > > But it generates a letter page size instead of using /etc/papersize. > > > > Pipe through > > > > pdftocairo -pdf -paper A4 - a4.pdf > > This introduces additional margins at the top and at the bottom. PPD=envy.ppd /usr/lib/cups/filter/texttopdf 1 1 1 1 1 UTF-8-demo.txt >out.pdf > Anyway, Unicode is not supported. That would be a big drawback for a printing filter. CHARSET=utf-8 /usr/lib/cups/filter/texttopdf 1 1 1 1 1 UTF-8-demo.txt >out.pdf -- Brian.
Re: PDF on debian
On Thu 09 Mar 2023 at 15:29:51 +0100, to...@tuxteam.de wrote: > On Thu, Mar 09, 2023 at 01:42:22PM +0000, Brian wrote: > > On Thu 09 Mar 2023 at 12:43:51 +0100, to...@tuxteam.de wrote: > > [...] > > > > There are other (simpler) options, look for text2pdf/text2ps. Personally, > > > I go the (La)TeX way. > > > > For a searchable PDF, I would use > > What do you mean by "searchable"? I can search in my LaTeX-generated > PDFs for some text, if you mean that. That is exactly what I mean; using / in a PDF viewer. cupsfilter does what texttopdf does but its PDF foles are not searchable, but can be made so: /usr/sbin/cupsfilter in.txt | pdftocairo -pdf - out.pdf > TeX is perfectly fine as a PDF backend. Especially if you go for the > more "modern" variants, like LuaTeX, which grok UTF-8 natively. I am sure Tex is fine. I wished to deliver a solution using something failrly simple that is probably already on most systems. -- Brian.
Re: PDF on debian
On Thu 09 Mar 2023 at 15:11:05 +0100, Nicolas George wrote: > Vincent Lefevre (12023-03-09): > > But it generates a letter page size instead of using /etc/papersize. > > And apparently that is not its only flaw, a quick test had it just skip > non-ascii characters. A possible solution: :execute '!PPD=myppd.ppd /usr/lib/cups/filter/texttopdf 1 1 1 1 1 % > out.pdf' I've not tried it. -- Brian.
Re: PDF on debian
On Thu 09 Mar 2023 at 15:01:00 +0100, Vincent Lefevre wrote: > On 2023-03-09 13:42:22 +0000, Brian wrote: > > For a searchable PDF, I would use > > > > :execute '!/usr/lib/cups/filter/texttopdf 1 1 1 1 1 % > out.pdf' > > > > cups-filters needs to be on the system. > > But it generates a letter page size instead of using /etc/papersize. Pipe through pdftocairo -pdf -paper A4 - a4.pdf -- Brian.
Re: solution to / full
On Wed 01 Mar 2023 at 19:37:10 +0100, to...@tuxteam.de wrote: > On Wed, Mar 01, 2023 at 06:12:09PM +0000, Brian wrote: > > On Wed 01 Mar 2023 at 17:43:41 +0100, to...@tuxteam.de wrote: > > > > [...] > > > > > In a pinch, you can "sudo apt-get clean", which purges the APT > > > package cache, which lives in /var. You didn't show us /var, > > > which might be interesting too (/var/log, in case some logs > > > aren't rotated properly?) > > > > There should not be any actual packages in /var/cache/apt. > > Cleaning out pkgcache.bin and srcpkgcache.bin is not really > > of permanment value as they reappear after 'apt update'. > > Doh. Forget my post anyway. I've had a better look at the mount > table now. > > Sorry for the noise No problem. I've been caught out by this regeneration on a space-constrained system in the past. -- Brian.
Re: solution to / full
On Wed 01 Mar 2023 at 13:33:32 -0500, Greg Wooledge wrote: > On Wed, Mar 01, 2023 at 06:12:09PM +0000, Brian wrote: > > On Wed 01 Mar 2023 at 17:43:41 +0100, to...@tuxteam.de wrote: > > > > [...] > > > > > In a pinch, you can "sudo apt-get clean", which purges the APT > > > package cache, which lives in /var. You didn't show us /var, > > > which might be interesting too (/var/log, in case some logs > > > aren't rotated properly?) > > > > There should not be any actual packages in /var/cache/apt. > > This depends on whether one uses "apt" or "apt-get" or some other > program to install packages. By default, "apt" removes the .deb files > from /var/cache/apt/archives/ after installing them, but "apt-get" > does not. For other programs, who knows. Of course it depends. I assumed a default usage usage of package management. It's been around long enough. -- Brian.
Re: solution to / full
On Wed 01 Mar 2023 at 19:48:59 +, Joe wrote: > On Wed, 1 Mar 2023 18:12:09 + > Brian wrote: > > > On Wed 01 Mar 2023 at 17:43:41 +0100, to...@tuxteam.de wrote: > > > > [...] > > > > > In a pinch, you can "sudo apt-get clean", which purges the APT > > > package cache, which lives in /var. You didn't show us /var, > > > which might be interesting too (/var/log, in case some logs > > > aren't rotated properly?) > > > > There should not be any actual packages in /var/cache/apt. > > What should cause/prevent that? apt deletes them after they are installed. Unless, of course, other arrangements are made. -- Brian.
Re: solution to / full
On Wed 01 Mar 2023 at 17:43:41 +0100, to...@tuxteam.de wrote: [...] > In a pinch, you can "sudo apt-get clean", which purges the APT > package cache, which lives in /var. You didn't show us /var, > which might be interesting too (/var/log, in case some logs > aren't rotated properly?) There should not be any actual packages in /var/cache/apt. Cleaning out pkgcache.bin and srcpkgcache.bin is not really of permanment value as they reappear after 'apt update'. -- Brian.
Re: Debian 11 upgrade to Debian 12
On Tue 28 Feb 2023 at 15:35:43 -0500, Jeffrey Walton wrote: > On Tue, Feb 28, 2023 at 2:53 PM Greg Wooledge wrote: > > > > On Tue, Feb 28, 2023 at 06:32:27PM +, Tixy wrote: > > > On Tue, 2023-02-28 at 13:16 -0500, Timothy M Butterworth wrote: > > > [...] > > > > All I did was modify /etc/apt/sources.list from Bullseye to Bookworm, > > > > then > > > > I ran apt update and apt upgrade. I guess I could have run apt > > > > full-upgrade > > > > and that probably would have worked better. > > > > > > It would have. If you looked at the release notes [1] it suggests > > > > > > # apt upgrade --without-new-pkgs > > > # apt full-upgrade > > > > > > Then lists some possible issues and there remedy. > > > > > > [1] > > > https://www.debian.org/releases/testing/amd64/release-notes/ch-upgrading.en.html#minimal-upgrade > > > > It's also worth mentioning that in bookworm, non-free firmware has been > > moved to a new section called "non-free-firmware". If you use any of > > that -- most people do! -- then you either need to change "non-free" to > > "non-free-firmware" or to "non-free non-free-firmware", depending on > > your specific needs. > > That's a good point. That should be stated in the wiki page at > https://wiki.debian.org/DebianUpgrade . Well! Get on with it. It's a wiki. -- Brian.
Re: CUPS - how to match autodetected printers to physical ones
On Sun 26 Feb 2023 at 17:09:51 +0300, Reco wrote: > Hi. > > On Sat, Feb 25, 2023 at 11:26:21PM +0000, Brian wrote: > > > It's interesting how you bring up DHCP, yet do not mention DHCP option 9 > > > (aka "option lpr-servers" in ISC lingo). > > > A proper implementation of DHCP options would make DNS-SD (and other > > > assorted kludges) completely redundant. > > > But that would be in an ideal world, and in the real world DNS-SD > > > serves its function (within its inherent limits of course). > > > If it works, that is. > > > > If the IP address changes, ipp://10.76.172.100/ipp/print as a > > URI becomes useless. DNS-SD ensures a reachable URI. Got it? > > There's no need to be rude. Apologies if it came through like that. Note that rfc7472 says >...literal IPv4 or IPv6 addresses SHOULD NOT be used... > Leaving aside changing printer's IP (the main question here is why would > anyone would do it), how exactly DNS-SD helped Greg to print in that > environment? >From one of Greg Wooledge's previous mails: > + eno1 IPv4 Canon LBP712Cdn (db:c0:d3) > + eno1 IPv4 HP LaserJet P3010 Series [0FCDD7] > + eno1 IPv4 hp LaserJet 4250 [621E13] He did not want to use these printers, but they would be shown in the print dialog of Evince (say), as would be the non-adverised printer if it had been set up correctly. A click or two to print. Alternatively, 'lpstat -l -e' and print with 'lp -d PRINTER FILE'. > > > > It would also be hoped that port numbers and resource > > > > paths are on the sheet of paper, otherwise a user will have a > > > > lot of guessing to do. > > > > > > Nope. RTFM would suffice, as always. > > > > I do not think you understand my argument. A port for an IPP > > printer need not be on 631 and the resource path need not be > > ipp/print. RTFM hardly helps when there is an immediate need > > to print. > > I wish you good luck in "convincing" typical dumb printer firmware in > performing such feats. Bonus points for "convincing" enterprise-grade > printer firmware to do the same. IPP printers need not be physical printers. > The main question here, of course, is why complicate things without the > need? > > > > RTFM? Which ones would you recommend? > > This one is good enough: > > https://www.pwg.org/ipp/ippguide.html > > > > Actually, CUPS performed splendidly. > > If CUPS in that configuration did not allow a user to print certain > amount of pages, then it cannot be called splendid. CUPS did not stop a user from printing. It knew of three printers (see above). The fourth was hidden from it. > > The OP was on a badly set up, unco-operative network. That was (and > > probably still is) the root of the issue. > > And here it's you who seem to misunderstand the issue. > It's a city hall, or something like it. People come there, some are in > the need of printing. > > We have a confirmed and documented case of CUPS failing to deliver the > desired result (i.e. printing something) in that environment. Without > additional user configuration, that is. > > Last time I've checked, they did not provide CUPS on any Android phone > out of the box, and probably it's the same for Apple phones. > It's likely that some visitor would bring a laptop with them, and it's > likely that said laptop would run M$ Windoze (or whatever that > shovelware is called these days). > If mobile users or M$ laptop users would encounter any trouble printing > - surely someone would make something to fix it. > > Yet is was not fixed (for a year at most), so it's likely *it works for > the users*, so there's nothing to fix. Some user configuration on their > device may be required, or not, it's not relevant here. > > Does that mean that CUPS is in need of fixing? Of course not. > Does that mean that DNS-SD is not needed? Of course not. > Does that mean that the only way of printing something via CUPS is to > use DNS-SD? You can guess it, it's also not. > > > Moreover, printing something at a city hall is a rare (although > periodic) task. If the printer's IP changes between Greg's vistits there > - so what? A few quotes from Greg Wooledge's first mail: > Whatever I managed to do last year... it's not working this > year. I can only assume that my workplace's lovely IT > department... > When I tried to print this year's tax form to my local > printer, I learned that the default print queue I had > set up last year is no longer there. > This led to a c
Re: CUPS - how to match autodetected printers to physical ones
On Sat 25 Feb 2023 at 22:22:55 +0300, Reco wrote: > On Sat, Feb 25, 2023 at 06:30:28PM +0000, Brian wrote: > > On Sat 25 Feb 2023 at 17:44:15 +0300, Reco wrote: > > > > > Hi. > > > > > > On Fri, Feb 24, 2023 at 12:58:15PM -0500, Greg Wooledge wrote: > > > > On Fri, Feb 17, 2023 at 05:35:11PM +0300, Reco wrote: > > > > > Try this next time you're on site: > > > > > > > > > > lpadmin -p D14841 -E -v ipp://10.76.172.100/ipp/print -m everywhere > > > > > > > > This worked. I printed two copies of the single-page PDF from Chrome > > > > without any further problems. > > > > > > Just as planned. CUPS autodiscovery is only good for something if you > > > don't know printer's real IP. This little episode shows us that nothing > > > beats IP-on-sheet-of-paper discovery. > > > > 99% of users with tablets, smart phones, laptops etc would find > > DNS-SD more to their liking, especially if DHCP assignment is > > in place. > > It's interesting how you bring up DHCP, yet do not mention DHCP option 9 > (aka "option lpr-servers" in ISC lingo). > A proper implementation of DHCP options would make DNS-SD (and other > assorted kludges) completely redundant. > But that would be in an ideal world, and in the real world DNS-SD > serves its function (within its inherent limits of course). > If it works, that is. If the IP address changes, ipp://10.76.172.100/ipp/print as a URI becomes useless. DNS-SD ensures a reachable URI. Got it? It's as simple as that. Why complicate it with what DHCP can do or not do? > > It would also be hoped that port numbers and resource > > paths are on the sheet of paper, otherwise a user will have a > > lot of guessing to do. > > Nope. RTFM would suffice, as always. I do not think you understand my argument. A port for an IPP printer need not be on 631 and the resource path need not be ipp/print. RTFM hardly helps when there is an immediate need to print. RTFM? Which ones would you recommend? > > In this thread we see how a very experienced user reacted to > > being denied mdns multicasting. > > Allow me to quote that original e-mail for the sake of completeness: > > > So the printer WORKS. It is ON THE NETWORK. I can print TEXT to it > > using port 9100. > > > > What I CANNOT do is find it in CUPS. Or avahi-browse, or driverless, or > > any of these other commands that are so allegedly wonderful. > > > > Is there any way I can tell CUPS "Please set up a queue for a printer > > whose IP address is 10.76.172.100 even though you can't discover it with > > your fancy tools"? > > The way I see it, Greg wrote about a CUPS configuration problem. > The solution of said problem was (and still is btw) at lpadmin(8). > Of course, to know that the solution just lies there, waiting to be > implemented, that requires one to have a knowledge of CUPS administration. > Luckily we have debian-user for last one. Your interpretation of the OP's situation is misguided. He was confused and, as such users do sometimes, lashed out at anything in sight. There was not any CUPS missconfiguration. Actually, CUPS performed splendidly. The OP was on a badly set up, unco-operative network. That was (and probably still is) the root of the issue. > > How would an ordinary user go on? "Give them a piece of paper" sounds > > awfully like "Let them eat cake". > > Easy, a user should RTFM. Failing that, a user can use a different > device or OS, or *gasp* - just use ipptool. Given the environment, a > creative use of samba suite would probably solve the problem too, but > let's not get into *that*. > And there's that last step - just ask somebody. You welcome Big Boss into your office for a $100M deal. Big Boss: Contract's on my phone. Let's print it and I'll sign. What's the printer name? You: GimmeMoney Big Boss: Can't see it. You: Just let me read the manual and do a bit of network probing. Big Boss: (10 minutes later). Any joy? You: No. I'll go ask someone. Give me half an hour. Big Boss: I'm a busy woman with other options. Goodbye. -- Brian.
Re: CUPS - how to match autodetected printers to physical ones
On Sat 25 Feb 2023 at 17:44:15 +0300, Reco wrote: > Hi. > > On Fri, Feb 24, 2023 at 12:58:15PM -0500, Greg Wooledge wrote: > > On Fri, Feb 17, 2023 at 05:35:11PM +0300, Reco wrote: > > > Try this next time you're on site: > > > > > > lpadmin -p D14841 -E -v ipp://10.76.172.100/ipp/print -m everywhere > > > > This worked. I printed two copies of the single-page PDF from Chrome > > without any further problems. > > Just as planned. CUPS autodiscovery is only good for something if you > don't know printer's real IP. This little episode shows us that nothing > beats IP-on-sheet-of-paper discovery. 99% of users with tablets, smart phones, laptops etc would find DNS-SD more to their liking, especially if DHCP assignment is in place. It would also be hoped that port numbers and resource paths are on the sheet of paper, otherwise a user will have a lot of guessing to do. In this thread we see how a very experienced user reacted to being denied mdns multicasting. How would an ordinary user go on? "Give them a piece of paper" sounds awfully like "Let them eat cake". > > I've gotta say, though, this option is a disaster: > > > > -E When specified before the -d, -p, or -x options, forces the use of > > TLS encryption on the connection to the scheduler. Otherwise, enables > > the destination and accepts jobs; this is the same as running the > > cupsaccept(8) and cupsenable(8) programs on the destination. > > > > Whoever decided to overload that option in that way... yikes. > > Back in the day Apple's slogan was "think different". The whole CUPS > suite is a living proof of that. Wrong target! -E was there in its present form well before Apple acquired CUPS. -- Brian.
Re: CUPS - how to match autodetected printers to physical ones
On Fri 24 Feb 2023 at 12:58:15 -0500, Greg Wooledge wrote: > On Fri, Feb 17, 2023 at 05:35:11PM +0300, Reco wrote: > > Try this next time you're on site: > > > > lpadmin -p D14841 -E -v ipp://10.76.172.100/ipp/print -m everywhere > > This worked. I printed two copies of the single-page PDF from Chrome > without any further problems. Good. As I have previous indicated, this works because the vendor has not used ipp/canon as the resource, which it is at liberty to do so. A previous off-target comment was > My burning hatred of printers and this printing system > remains unquenched. Your hatred is aimed at completely the wrong target. How is it expected to have CUPS discover a printer when mdns multicasting is turned off on the printer by an incompetent sysadmin? > I've gotta say, though, this option is a disaster: > > -E When specified before the -d, -p, or -x options, forces the use of > TLS encryption on the connection to the scheduler. Otherwise, enables > the destination and accepts jobs; this is the same as running the > cupsaccept(8) and cupsenable(8) programs on the destination. > > Whoever decided to overload that option in that way... yikes. I could tell you, but perthaps you might want to find out for yourself instead of griping. Reporting (or searching) an issue at https://github.com/OpenPrinting/cups/issues might be easier than tackling the staff of your Help Desk. -- Brian.
Re: hard disk installation method fails
On Sat 18 Feb 2023 at 09:06:11 -0700, Charles Curley wrote: > On Sat, 18 Feb 2023 18:55:03 +0700 > Max Nikulin wrote: > > > Due to the following message I am confused if it should work for > > Debian: > > > > Brian to debian-user. Re: problem with loading installer (hard disk > > method) Thu, 29 Dec 2022 17:42:59 +. > > https://lists.debian.org/msgid-search/?m=29122022172846.4fc3cfd29...@desktop.copernicus.org.uk > > > > > GRUB's loopback facility will not work with installer images. > > > They do not contain iso-scan. > > > > > > https://bugs.debian.org/618000 > > Date: 2011. > > > > https://bugs.debian.org/724931 > > Date 2013, last entry dated 2020. > > Neither one is marked as resolved. > > loopback.mod (not .ko) is available in grub for both Bullseye and > Bookworm. > > root@cdtest:~# find /boot/ -iname loop* > /boot/grub/i386-pc/loopback.mod > root@cdtest:~# Irrelevant when it comes to what the kernel wants to do. > I can't find iso-scan anywhere except as a part of the package > dracut-live, so I'm not sure it's relevant here. I conjecture that > telling the kernel where to find the iso image bypasses any need for > iso-scan. (See the first email in #724931.) loop.ko is a kernel module. It is needed to mount an installer ISO to access its contents. But it is not present in the installer's initrd. lsinitramfs reveals that fact. The first email at #724931 has it right: > The module 'loop.ko' is not shipped with the Debian > testing netinstall ISO. It should reside in > /lib/modules/3.10-2-amd64/kernel/drivers/block/. > Because it is missing, it is impossible to mount ISO > images during the install and thus preventing > installation from ISO, if the module is not manually > imported. As for iso-scan: https://packages.debian.org/sid/iso-scan Joey Hess is a well-respected ex-Debian developer who was very influential in installer development. He says at https://lists.debian.org/debian-boot/2013/09/msg00097.html > iso-scan is part of the Debian installer[1]. > > However, it is only included in the hd-media initrd. > There is no reason to include it on the regular CD > initrd, because isohybrid allows mounting the USB > stick directly. (Not a loop-mount of an iso file > included in some disk, which the hd-media initrd > handles.) > > [1] I wrote it. Always nice to have my Debian work > cited as another reason Ubuntu is better than Debian! -- Brian.
Re: hard disk installation method fails
On Sat 18 Feb 2023 at 18:55:03 +0700, Max Nikulin wrote:
> On 18/02/2023 12:26, Charles Curley wrote:
> > menuentry "Install Debian 12 OS (preseeded)" {
> > set root='hd0,msdos5'
> > set isofile=/firmware-testing-i386-netinst.iso
> > insmod part_msdos
> > insmod loopback
> > loopback loop (hd0,msdos5)$isofile
> > linux (loop)/install.386/vmlinuz auto=true file=/media/preseed.cfg
> > initrd (loop)/install.386/initrd.gz
> > }
>
> Due to the following message I am confused if it should work for Debian:
>
> Brian to debian-user. Re: problem with loading installer (hard disk method)
> Thu, 29 Dec 2022 17:42:59 +.
> https://lists.debian.org/msgid-search/?m=29122022172846.4fc3cfd29...@desktop.copernicus.org.uk
>
> > GRUB's loopback facility will not work with installer images.
> > They do not contain iso-scan.
> >
> > https://bugs.debian.org/618000
> > https://bugs.debian.org/724931
I am going to stick to that view and add that an initrd also
needs to contain loop.ko. 'lsinitramfs initrd.gz' is a useful
command. Bother items show in the hd-media intitrd but not in
the initrd of debian-testing-amd64-netinst.iso.
I am mystified as to Charles Curley's experience.
--
Brian.
Re: CUPS - how to match autodetected printers to physical ones
On Fri 17 Feb 2023 at 09:05:39 -0500, Greg Wooledge wrote: > On Fri, Feb 17, 2023 at 11:18:32AM +0000, Brian wrote: [...] > > avahi-browse -rt _ipp._tcp > > avahi-browse -rt _uscan._tcp > > > > (I would find that data useful for my records). > > wooledg:~$ avahi-browse -rt _ipp._tcp 2>&1 | grep -A5 db:c0:d3 > + eno1 IPv4 Canon LBP712Cdn (db:c0:d3)Internet Printer >local > + eno1 IPv4 HP LaserJet P3010 Series [0FCDD7] Internet Printer >local > + eno1 IPv4 hp LaserJet 4250 [621E13] Internet Printer >local > = eno1 IPv4 Canon LBP712Cdn (db:c0:d3)Internet Printer >local >hostname = [dhcp-10-76-173-174.local] >address = [10.76.173.174] >port = [631] >txt = ["mopria-certified=1.2" "print_wfds=T" > "kind=document,envelope,postcard" > "URF=ADOBERGB24,CP255,DM1,FN3,IS1-4,OB10,PQ4,RS300,SRGB24,V1.4,W8-16" "Fax=F" > "Scan=F" "TLS=1.2" "usb_CMD=LIPSLX" > "UUID=15904ba4-fe8c-3bee-5d53-cb5f72ea86b2" "PaperMax=legal-A4" "Punch=0" > "Staple=F" "Sort=T" "Collate=T" "Bind=F" "PaperCustom=T" "Duplex=T" > "Copies=T" "Color=T" "TBCP=F" "Binary=F" "Transparent=F" "usb_MDL=LBP712C UFR > II" "usb_MFG=Canon" "adminurl=https://dhcp-10-76-173-174.local/airprint.html; > "pdl=application/octet-stream,image/urf,image/pwg-raster,image/jpeg,application/pdf" > "product=(CNLBP712C)" "ty=Canon LBP712C" "priority=10" "qtotal=1" "note=" > "rp=ipp/print" "txtvers=1"] > = eno1 IPv4 hp LaserJet 4250 [621E13] Internet Printer >local Assuming the machine at 10.76.172.100 is identical with this one at 10.76.173.174, it too will have a TXT record with pdl=application/octet-stream,image/urf,image/pwg-raster,image/jpeg,application/pdf A PDF sent directly to it should print if an open port 9100 exists on the printer: netcat 10.76.172.100 9100 < taxform.pdf > wooledg:~$ time avahi-browse -rt _uscan._tcp > real 1.023 user 0.004 sys 0.004 > > (No other output.) No prolem here. The LBP712Cdn does not have a scanner. It looks like mdns multcasting has been disabled on the printer at 10.76.172.100. This is unfortunate and unnecessary. Perhaps someone should inform your helpful Help Desk that its Bonjour name can be changed to distinguish it from similare devices on the network. -- Brian.
Re: hard disk installation method fails
On Fri 17 Feb 2023 at 05:13:34 +0800, lsg wrote: > this is quite unbelievable, it's most widely-used platform: amd64 > > installer says "No kernel modules found", probably due to kernel mismatch > > debian-11.6.0-amd64-netinst.iso is at sdb1, vfat partition, i've checked it > with sha256sum > > vmlinuz and initrd.gz are copied from: > > http://ftp.sunet.se/debian/dists/bullseye/main/installer-amd64/current/images/hd-media/ There isn't much you can do about this. It is usually a temporary issue thats happens after Linux kernel updates. The installer is now out of step. It gets automatically fixed after some time. -- Brian.
Re: snapd vs apt
On Fri 17 Feb 2023 at 05:55:03 +0800, winnie hw wrote: > Most versions in snapd are newer than apt. such as ruby, > > snap install ruby # version 3.2.1, or > apt install ruby # version 1:3.0~exp1 I cannot better the existing very informative replies. It comes down to what you want to achieve. -- Brian.
Re: CUPS - how to match autodetected printers to physical ones
On Thu 16 Feb 2023 at 15:32:47 -0500, Greg Wooledge wrote: > wooledg:~$ cat /etc/debian_version > 11.6 > wooledg:~$ lpstat -l -e > Canon_LBP712C_UFR_II_ permanent > ipp://localhost/printers/Canon_LBP712C_UFR_II_ > ipp://Canon%20LBP712Cdn%20(db%3Ac0%3Ad3)._ipp._tcp.local/ This is a print queue, set up using Canon drivers. > Canon_LBP712Cdn_db_c0_d3_ network none > ipp://Canon%20LBP712Cdn%20(db%3Ac0%3Ad3)._ipp._tcp.local/ This is not a print queue. CUPS has discovered the printer via mdns/DNS-SD and enumetated it. It should be seen with avahi-browse -rt _ipp._tcp avahi-browse -rt _uscan._tcp (I would find that data useful for my records). It can be printed to with lp -d "Canon_LBP712Cdn_db_c0_d3_" FILE Where the job physically ends up is outside the scope of CUPS. Let's assume the printer you ar interested in is not being multicast. It exists at 10.76.172.100. Let us guess that the resource to access on the printer is ipp/print. This is a pretty good guess because most vendors use it nowadays. Its URI will be ipp://10.76.172.100/ipp/print Execute lpadmin -p mycanonprinter -v URI -E -m everywhere Test printing with lp -d mycanonprinter /etc/nsswitch.conf -- Brian.
Re: CUPS - how to match autodetected printers to physical ones
On Thu 16 Feb 2023 at 11:27:25 -0800, Bob McGowan wrote: >On 2/16/23 11:14 AM, Brian wrote: > > On Thu 16 Feb 2023 at 11:52:21 -0500, Stefan Monnier wrote: > > > [1]to...@tuxteam.de [2023-02-16 16:53:02] wrote: > > Just for kicks: have you tried sending a PS (or *gasp* PDF) file > down that alley (e.g. with socat)? > > For That One Form in the Year this might be just sufficient... > > Hint: start with a small one :) > > I don't think "a small one" can be small enough in case it misfires. > Instead, I usually make sure there's only 1 sheet of paper in the tray > when I send the test (usually a sheet that I already used :-) > > Producind a PDF with the line "This is a test" in it is > incredibly easy. Jumping through hoops is not needed. > > >However, the PDF file created (I used LibreOffice 'cause its fast and >easy) was 7,335 characters long, according to 'wc', which also reported >367 "words" and 139 "lines". > >Given that a standard US letter size sheet (8.5 by 11 inches) has 66 >lines per page, that is just over 2 pages. > >So putting only one used sheet of paper in the printer would save a >couple of sheets of paper. ;) > >Not much but why waste paper for a simple test? I have no desire or intention to investigate how LibreOffice deals with a single line text file converted to a PDF. This works to not waste paper when fileout.pdf is printed: /usr/lib/cups/filter/texttopdf 1 1 1 1 1 filein.txt > fileout.pdf -- Brian.
Re: CUPS - how to match autodetected printers to physical ones
On Thu 16 Feb 2023 at 11:52:21 -0500, Stefan Monnier wrote: > to...@tuxteam.de [2023-02-16 16:53:02] wrote: > > Just for kicks: have you tried sending a PS (or *gasp* PDF) file > > down that alley (e.g. with socat)? > > > > For That One Form in the Year this might be just sufficient... > > > > Hint: start with a small one :) > > I don't think "a small one" can be small enough in case it misfires. > Instead, I usually make sure there's only 1 sheet of paper in the tray > when I send the test (usually a sheet that I already used :-) Producind a PDF with the line "This is a test" in it is incredibly easy. Jumping through hoops is not needed. -- Brian.
Re: CUPS - how to match autodetected printers to physical ones
On Thu 16 Feb 2023 at 10:41:33 -0500, Greg Wooledge wrote: [...] > 3) Also suggested: driverless >Here's what I get this year: > >wooledg:~$ driverless >ipp://Canon%20LBP712Cdn%20(db%3Ac0%3Ad3)._ipp._tcp.local/ > >That's all. And no, that's not the right printer. That's the one >that has the right model number, but isn't *mine*. I can only imagine >it's somewhere else on this floor, and that someone is very confused >upon seeing income tax forms coming out of it. How do you know it it does not point to the right printer? > 4) Also mentioned: port 9100. >For grins, I did "telnet 10.76.172.100 9100" and after that connected >I typed "HELLO WORLD", then pressed Enter, then Ctrl-] q Enter to >close the telnet session. > >That actually printed the words HELLO WORLD on a sheet of paper. > > So the printer WORKS. It is ON THE NETWORK. I can print TEXT to it > using port 9100. The printer understands text. > What I CANNOT do is find it in CUPS. Or avahi-browse, or driverless, or > any of these other commands that are so allegedly wonderful. Your machine has bullseye, we suppose? Give what you gat for lpstat -l -e > Is there any way I can tell CUPS "Please set up a queue for a printer > whose IP address is 10.76.172.100 even though you can't discover it with > your fancy tools"? Yes, but it should not be needed and involves guessing.(Please try to avoid unhelpful, judgemental adjectives). [...] > My burning hatred of printers and this printing system remains unquenched. Calm down! Understanding a situation (like the operation of a shell script) requires being able to focus. -- Brian.
Re: ipv6 maybe has arrived.
On Tue 14 Feb 2023 at 14:02:05 +0100, Nicolas George wrote: > Greg Wooledge (12023-02-14): > > It's certainly more than "the error messages went away". > > Yes, but Reco was smarter than us, with the "> /dev/null". OK, my belief, backed up by experience, is that sudo is not needed to obtain the specific information I was after. -- Brian.
Re: ipv6 maybe has arrived.
On Tue 14 Feb 2023 at 07:21:00 -0500, Greg Wooledge wrote: > On Tue, Feb 14, 2023 at 07:07:58AM -0500, gene heskett wrote: > > On 2/14/23 06:29, Brian wrote: > > > Anyway, this USB-only printer from 2016 does not provide > > > an IPP-over-USB service. This is not unexpected. > > > > > Are you saying that this printer has been sitting on the Staples display for > > 5 years when I bought it new about when it first showed up there 2 years > > ago? > > Had to dig through the archive to find the model number (HL-L2320D) > again, since it was snipped in this part of the thread. Once I found > the model number, I did a Google search, and this was one of the results: > > > Brother HL-L2320D L2300D best budget laser printer review > https://www.youtube.com › watch > 7:51 > A quick demonstration and review of the Brother HL-L2320D laser printer.Buy > it on Amazon here: http://amzn.to/2haHDsdOr buy the similar ... > YouTube · DarkStoneCastle · Dec 21, 2016 > > > So... yeah, I guess we're saying that your printer was 5 years old at the > moment you bought it. Or at least, that it was a 5-year-old *design*, > even if that particular printer had been assembled more recently. The Brother HL-L2320D seems to have come on the market in early 2016. I haven't any idea when Staples decided to stock it. > Now, personally I don't consider a 7-year-old product to be an antique, > but maybe Brian does. I certainly can't speak for him on this topic. I do not consider a 7-year-old product to be an antique. The significance of 2016 is that it is four years after the IPP-over-USB standard was ratified. Network printers from 2016 almost certainly (always in my experience) do ship with IPP-over-USB. For some reason USB-only devices generally do not provide it; it's very hit-and-miss. I do not know why all vendors (not just Brother) have taken that decision. It's a real pain as it effectively makes the printer a legacy model and very much limits how it fits into the Debian printing ecosystem. -- Brian.
Re: ipv6 maybe has arrived.
On Tue 14 Feb 2023 at 06:23:34 +0100, to...@tuxteam.de wrote: > On Mon, Feb 13, 2023 at 04:04:29PM -0500, gene heskett wrote: > > On 2/13/23 14:10, Brian wrote: > > > lsusb -v | grep -A 3 bInterfaceClass.*7 > > FWIW, if you invoke lsusb with the -v option, you need > some superpowers. So better "sudo lsusb -v". I do not believe that to be the case. As your user run 'lsusb -v | less' and clear the screen (CTRL-L) or scroll up and down. Observations? Gene Heskett did use sudo. Note the different messages. Anyway, this USB-only printer from 2016 does not provide an IPP-over-USB service. This is not unexpected. -- Brian.
Re: ipv6 maybe has arrived.
On Mon 13 Feb 2023 at 11:21:00 -0500, gene heskett wrote: > On 2/13/23 10:30, Brian wrote: > > On Mon 13 Feb 2023 at 10:08:22 -0500, gene heskett wrote: > > > > > On 2/13/23 10:00, Brian wrote: > > > > On Mon 13 Feb 2023 at 09:30:32 -0500, gene heskett wrote: > > > > > > > > > On 2/13/23 06:01, Brian wrote: > > > > > > On Mon 13 Feb 2023 at 09:25:15 +0100, to...@tuxteam.de wrote: > > > > > > > > > > > > > On Sun, Feb 12, 2023 at 07:12:42PM +, Brian wrote: > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > > > Fortunately, the vast majority of users with a modern printer > > > > > > > > have > > > > > > > > not taken a similar view. They now enjoy an effortless and > > > > > > > > enjoyable > > > > > > > > printing experience. > > > > > > > > > > > > > > My printer is all well, thankyouverymuch. Whenever I'm after an > > > > > > > "experience", I take my bike and ride to the mountains, very > > > > > > > enjoyable :) > > > > > > > > > > > > Such a journey would give ample opportunity to ponder why mDNS > > > > > > multicasting is welcomed by so many users and whether you will > > > > > > embrace it when CUPS ceases to support legacy printers. :) > > > > > > > > > > > Precisely the unsaid point of my last post. That will be the impetus > > > > > to > > > > > fork cups. > > > > > > > > That's very doubtful. The printing system's New Architecture > > > > includes extensive and sound provision to support legacy > > > > printers. More or less, all the PPD's and drivers distributed > > > > by Debian are catered for. > > > > > > The idea is fine, Brian, but for Brother stuff, its crippling. A multitray > > > printer is restricted to the most expensive paper, where duplex does not > > > work either. In 2023, that is Unforgivable. > > > > You are basing your view on experience of a single Brother > > printer, the MFC-J6920DW. This is an IPP printer. It is > > perfectly possible for the IPP implementation to be less > > than perfect. Nothing to do with our printing system. > > > > You'll have thoroughly investigated this aspect of the > > vendor's machine, of course? > > > Wrong again Brian. I have two of their printers here as there is also a $120 > b laser that happily spits out 20+ pages a minute in full duplex. But > running on the debian supplied drivers it can't even duplex. And it will if > its anything like its predecessor, continue to do that the rest of my life, > or 50,000 pages as long as I feed it toner & decent paper. And the model of b laser? -- Brian.
Re: ipv6 maybe has arrived.
On Mon 13 Feb 2023 at 11:11:38 -0500, gene heskett wrote: [...] > "Distributed by Debian" is the key phrase here. That qualifier apparently > does not include the better Brothers. The Brother drivers are non-free. They will cease to work. It will be up to Brother to accomodate them to the New Architecture. -- Brian.
Re: ipv6 maybe has arrived.
On Mon 13 Feb 2023 at 09:30:32 -0500, gene heskett wrote: > On 2/13/23 06:01, Brian wrote: > > On Mon 13 Feb 2023 at 09:25:15 +0100, to...@tuxteam.de wrote: > > > > > On Sun, Feb 12, 2023 at 07:12:42PM +, Brian wrote: > > > > > > [...] > > > > > > > Fortunately, the vast majority of users with a modern printer have > > > > not taken a similar view. They now enjoy an effortless and enjoyable > > > > printing experience. > > > > > > My printer is all well, thankyouverymuch. Whenever I'm after an > > > "experience", I take my bike and ride to the mountains, very > > > enjoyable :) > > > > Such a journey would give ample opportunity to ponder why mDNS > > multicasting is welcomed by so many users and whether you will > > embrace it when CUPS ceases to support legacy printers. :) > > > Precisely the unsaid point of my last post. That will be the impetus to > fork cups. That's very doubtful. The printing system's New Architecture includes extensive and sound provision to support legacy printers. More or less, all the PPD's and drivers distributed by Debian are catered for. -- Brian.
Re: ipv6 maybe has arrived.
On Mon 13 Feb 2023 at 09:25:15 +0100, to...@tuxteam.de wrote: > On Sun, Feb 12, 2023 at 07:12:42PM +0000, Brian wrote: > > [...] > > > Fortunately, the vast majority of users with a modern printer have > > not taken a similar view. They now enjoy an effortless and enjoyable > > printing experience. > > My printer is all well, thankyouverymuch. Whenever I'm after an > "experience", I take my bike and ride to the mountains, very > enjoyable :) Such a journey would give ample opportunity to ponder why mDNS multicasting is welcomed by so many users and whether you will embrace it when CUPS ceases to support legacy printers. :) -- Brian.
Re: ipv6 maybe has arrived.
On Sun 12 Feb 2023 at 07:55:04 +0100, to...@tuxteam.de wrote: > On Sat, Feb 11, 2023 at 09:29:16PM -0600, David Wright wrote: [...] > > So it's difficult to figure out why some are plagued by these > > addresses, made worse when one gets used for the default route, eg > > https://lists.debian.org/debian-user/2019/07/msg00208.html > > So many of the "solutions" proferred seemed to involve "nuking" avahi. > > My reason for "nuking" Avahi wasn't the IPv4LL. ISTR that it misbehaved > once, which made me aware of its existence. Then I read up on what it > does and decided "no, I don't want this on my network". Fortunately, the vast majority of users with a modern printer have not taken a similar view. They now enjoy an effortless and enjoyable printing experience. -- Brian.
Re: CUPS printer on Debian 11.6
On Sun 05 Feb 2023 at 20:52:42 +, Russell L. Harris wrote: > Fresh installation of Debian 11.6 on Dell Vostro 200 (Intel Core 2). > > The Vostro 200 is being added to a home LAN with Debian 11.6 running > on a nondescript desktop (amd64) and a HP Laserjet P3015 Postscript > (Ethernet). The amd64 machine works perfectly with the P3015. > > The printer configuration on both machines appears identical: > >DRIVER: HP LaserJet Series PCL 6 CUPS (grayscale) >Connection: socket://192.168.1.211:9100 > > (1) The printer installs on Vostro 200 but does not print. Symptoms of not printing? Provide outputs for 'lpstat -t' and 'lpinfo -v'. > (2) Should I install the P3015 as generic Postscript printer? Unlikely to have any effect. > (3) I cannot make sense of the new CUPS "driverless" scheme. > Does it make my Postscript printers obsolete? No. -- Brian.
Re: Server Static IP and At's BGW210
On Thu 19 Jan 2023 at 15:15:28 -0600, Tom Browder wrote: > I am trying to use my new public static IP for my Debian PC which is ready > for it security-wise (thanks to advice from this ML; note I will initially > allow access only via ssh from the IP address of one of my remote hosts). > > I know how to turn on public access in their router, but it's not clear > what the results will be. I have queried the AT community but no answer > yet. > > The question is: when I set the router to allow public access, does it only > allow access to devices assigned to one of the public IPs (i.e., it does > NOT allow access to devices using DHCP)? > > It seems to me logically that should be true, but I just need some > confirmation before I open up to the public. (And I will start by limit *All* addresses used on the internet are public.
Re: problem with loading installer (hard disk method)
On Thu 29 Dec 2022 at 22:07:15 +0700, Max Nikulin wrote:
> On 29/12/2022 10:55, lou wrote:
> > i have solved my 2nd problem on my own, thanks anyway!
>
> Great
Two problems encountered. Two problems resolved in an unknown
way.
> > i have 2 suggestions:
>
> https://www.debian.org/releases/bullseye/amd64/apes02.en.html
> > E.2. Contributing to This Document
> >
> > If you have problems or suggestions regarding this document, you should
> > probably submit them as a bug report against the package
> > installation-guide. See the reportbug package or read the online
> > documentation of the Debian Bug Tracking System.
>
> Suggestions sent to this list may be lost unnoticed by the developers.
>
> I suppose, loading installer from hard drive is for advanced users. There is
> should be balance for amount of details in Debian manuals. It is grub manual
> that should cover the topic thoroughly.
I doubt GRUB would act on (hd0,partition1).
> Notice that you having an .iso file stored on a hard drive, it is possible
> to boot it directly. A couple of years ago I tried
>
> menuentry "ISO Ubuntu-20.10 amd64" {
> set isofile="/ubuntu/ubuntu-20.10-desktop-amd64.iso"
> loopback loop (hd0,5)$isofile
> linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile
> noprompt noeject toram
> initrd (loop)/casper/initrd
> }
>
> linux and initrd commands are taken from the grub configuration inside the
> iso file.
>
> The grml-rescueboot package uses the same approach.
GRUB's loopback facility will not work with installer images.
They do not contain iso-scan.
https://bugs.debian.org/618000
https://bugs.debian.org/724931
BTW: I would assiciate casper with Ubuntu, not Debian.
--
Brian.
Re: Printer not working after upgrading
On Tue 22 Nov 2022 at 09:25:40 -0600, David Wright wrote: [...] > $ driverless > ipp://Brother%20HL-L2390DW._ipp._tcp.local/ > $ > > # lpadmin -p brother -v ipp://Brother%20HL-L2390DW._ipp._tcp.local/ -E -m > driverless:ipp://Brother%20HL-L2390DW._ipp._tcp.local/ > # Splendid advice for those wishing to have complete control of setting up a print queue for a Modern printer. Unfortunately, the device in question is a Legacy one from around 2010 requiring a vendor driver. -- Brian.
Re: Printer not working after upgrading
On Tue 22 Nov 2022 at 09:42:34 +, Rodolfo Medina wrote: > I noticed the problem just after upgrading to bullseye from previous stable > Debian version; then I upgraded to Unstable in the hope of solving it but the > problem remains, with error: > > stopped "Filter failed" > > I also tried to remove and re-add the printer with no success. I'm stuck, > please help, thanks in advance. I have not read ths thread in its entirety: https://lists.debian.org/debian-user/2017/03/msg00100.html There will be a PPD for the printer in /etc/cups/ppd. As root, execute cupsfilter -p /etc/cups/ppd/YOUR_PPD -m printer/foo -e /etc/nsswitch > out.dat 2>log and post log. -- Brian.
Re: update-initramfs outside of /boot
On Sat 01 Oct 2022 at 20:07:13 +0200, Erwan David wrote: > Le 01/10/2022 à 18:25, Felix Miata a écrit : > > Erwan David composed on 2022-10-01 16:21 (UTC+0200): > > > > > My /boot is 235 MB (from deb 10 installer), however in testing I now > > > have 56MB initramfs files and update-initramfs cannot work for the 3rd > > > kernel to install (and apt autoremove keeps 2 kernels, thus at upgrade > > > there are temporarily 3 kernels). > > > I see that all the files of the initramfs are put in /boot before > > > creating the compressed image, thus the need for place. Is there a way > > > to cofigure update-initrams so that the creation of the im age is done > > > in another filesystem before instalation in /boot ? > > Alternative options: > > > > 1-Move the oldest kernel files to another filesystem, or everything, from > > /boot. > > You don't need them there until time to reboot. > > > > 2-You're not forced to keep two kernels. Remove the non-running one > > manually. > > > > 3-As Stefan already suggested, MODULES=dep. It's routine here. Big initrds > > take > > more time to load, which can be quite noticeable on old hardware. > > > > 4-Is your /boot adjacent to your swap? If yes, easily recreate both, with > > smaller > > swap, larger /boot. Don't forget to adjust fstab for UUID change of swap, > > or apply > > the one from fstab on the new. > > > My /boot is next to an encrypted lvm containing te rest of the disk. I fear > resizing /boot would require a reinstall, I'll set modules=dep It seems that a larger /boot is not an option for you. I also suspect modules=dep may not give you sufficient extra space, but it is worth a try. A lack of success with modules=dep just might propel you towards purging one or more of the installed kernels to improve the situation. -- Brian.
