Re: [arch-general] HP Laserjet plus 1020 Problem
On Wed, Aug 19, 2020 at 9:25 PM Giancarlo Razzolini wrote: > > I believe your printer works without hplip and using the driverless > option. That's something you can also try. I tried it your way too. I removed hplip. It seemed plausible too. When the printer was not working in Arch Linux I booted into Debian and without installing hplip I tried printing. And it worked. But removing hplip did not help either. -- দাস das http://ddts.randomink.org/ -- দাশ das http://ddts.randomink.org/
Re: [arch-general] No login after update
On 8/19/20 3:41 PM, Morten Linderud via arch-general wrote: > https://www.archlinux.org/pacman/pacman.8.html#_handling_config_files_a_id_hcf_a > > Can you please read this section a few times before writing more emails? > I see. I was sure pacman made no comparisons at all to previous config versions, just what is on the filesystem now and what's new. Sorry about that, I was wrong. Yaro signature.asc Description: OpenPGP digital signature
Re: [arch-general] No login after update
https://www.archlinux.org/pacman/pacman.8.html#_handling_config_files_a_id_hcf_a Can you please read this section a few times before writing more emails? -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-general] No login after update
On Wed, Aug 19, 2020 at 3:32 PM Yaro Kasear wrote: > On Wed, Aug 19, 2020 at 3:17 PM Archange wrote: > >> >> Le 20/08/2020 à 00:04, Yaro Kasear a écrit : >> > On 8/19/20 2:56 PM, Yaro Kasear wrote: >> >> On 8/19/20 2:48 PM, Giancarlo Razzolini via arch-general wrote: >> >>> Em agosto 19, 2020 16:37 Yaro Kasear escreveu: >> I've always questioned the wisdom of dropping a .pacnew just when the >> file is different from the default. There's really no reason for it >> considering any changes you made were deliberate and presumably >> thought >> out. The end result is pacman cluttering /etc with a default >> configuration file whose only reason for existing is to, if it's >> used, >> clear settings. Why? >> >> >>> The .pacnew is there to indicate that something new exists, or that >> >>> you changed >> >>> something. Most of the time you can remove .pacnew files, but not >> >>> always. Also, >> >>> it's only "cluttering" /etc (and /boot, btw), if you don't handle >> them. >> >>> >> What pacman SHOULD do is compare /etc files between package versions >> and >> see if there's a change BETWEEN DEFAULTS. *Then* there's an actual >> reason to need a new default config file for the user to examine >> because >> then there's an actual indicator some meaningful change in default >> configuration or how the package handles configs happened. >> >> >>> That's way beyond the scope of a package manager, and also, there's no >> >>> way >> >>> to tell what "DEFAULTS" (why caps?) should be. >> >> Caps for emphasis is all. >> All most pacnew files wind up doing is sitting there for thirty >> seconds >> before being deleted without anyone even opening them because they're >> literally just what the file was before the user ALREADY changed it >> before... because it's utterly useless to get a default config file >> when >> you've intentionally changed it and there's nothing in the new >> version >> of the package that calls for an examination of the defaults. >> >> >>> I don't know why you said that .pacnew sits for thirty seconds before >> >>> being >> >>> deleted. Are you using a hook that does this? Because nothing handles >> >>> them >> >>> automatically, that's the user's job. There are tools to aid in doing >> >>> that, >> >>> but in the end the user should know what to apply, and what to >> discard. >> >> I wasn't being literal about thirty seconds. Exaggerating. >> >>> Regards, >> >>> Giancarlo Razzolini >> >> Yaro >> >> >> >> >> > Oh, also: >> > >> > "That's way beyond the scope of a package manager, and also, there's no >> > way to tell what "DEFAULTS" (why caps?) should be." >> > >> > Yes there is. The defaults are literally what's in the config file in >> > the archive and not on the filesystem. How would that not be a way to >> > determine default settings? >> > >> > I'm not suggesting the package manager would have to understand the >> > settings, but it would be able to tell if the contents of that file are >> > different from another version. (Which it obviously does already, >> > otherwise it wouldn't know to make a pacnew file.) >> > >> > I can't imagine it'd be that difficult for pacman to compare checksums >> > between files in /etc or /boot between versions of a package (If a >> > previous version is available.) and what's on /etc and determine if it >> > really needs to bother putting a pacnew file on the filesystem that >> > doesn't need to be there. It's already doing some sort of check between >> > what's in the package and what's on the filesystem already. >> > >> > Yaro >> >> pacman does this: if the *packaged file* changed between the installed >> version and the new one, and the *installed file* is different from the >> *packaged file*, then drop a .pacnew. >> >> I’m not sure what you want more… >> >> Bruno/Archange >> > > But that is not what I am talking about. > > I'm discussing what is essentially three configuration files here: > > - The config in old-package. > - The config in new-package. > - The config on the filesystem. > > I already know pacman compares new-package and filesystem config. It does > NOT do any check between old-package and new-package. > > What I'm saying is a pacnew seems unnecessary if the file between > old-package and new-package are the same, because it means there's > absolutely nothing of use to the user there, as either the user's made > changes themselves and thus that file from the package is just going to be > settings they don't want, or it's never been changed, in which case > extracting the file's entirely redundant as it's literally still the same > file. Pacman wouldn't do a pacnew in that case as it's implemented so > that's beside the point. > > I'm not talking about the existing new-package to filesystem version > checks, I'm talking about a case where if a package upgrade doesn't bring a > new configuration change, the pacnew's just a waste of time and
Re: [arch-general] No login after update
On Wed, Aug 19, 2020 at 3:17 PM Archange wrote: > > Le 20/08/2020 à 00:04, Yaro Kasear a écrit : > > On 8/19/20 2:56 PM, Yaro Kasear wrote: > >> On 8/19/20 2:48 PM, Giancarlo Razzolini via arch-general wrote: > >>> Em agosto 19, 2020 16:37 Yaro Kasear escreveu: > I've always questioned the wisdom of dropping a .pacnew just when the > file is different from the default. There's really no reason for it > considering any changes you made were deliberate and presumably > thought > out. The end result is pacman cluttering /etc with a default > configuration file whose only reason for existing is to, if it's used, > clear settings. Why? > > >>> The .pacnew is there to indicate that something new exists, or that > >>> you changed > >>> something. Most of the time you can remove .pacnew files, but not > >>> always. Also, > >>> it's only "cluttering" /etc (and /boot, btw), if you don't handle them. > >>> > What pacman SHOULD do is compare /etc files between package versions > and > see if there's a change BETWEEN DEFAULTS. *Then* there's an actual > reason to need a new default config file for the user to examine > because > then there's an actual indicator some meaningful change in default > configuration or how the package handles configs happened. > > >>> That's way beyond the scope of a package manager, and also, there's no > >>> way > >>> to tell what "DEFAULTS" (why caps?) should be. > >> Caps for emphasis is all. > All most pacnew files wind up doing is sitting there for thirty > seconds > before being deleted without anyone even opening them because they're > literally just what the file was before the user ALREADY changed it > before... because it's utterly useless to get a default config file > when > you've intentionally changed it and there's nothing in the new version > of the package that calls for an examination of the defaults. > > >>> I don't know why you said that .pacnew sits for thirty seconds before > >>> being > >>> deleted. Are you using a hook that does this? Because nothing handles > >>> them > >>> automatically, that's the user's job. There are tools to aid in doing > >>> that, > >>> but in the end the user should know what to apply, and what to discard. > >> I wasn't being literal about thirty seconds. Exaggerating. > >>> Regards, > >>> Giancarlo Razzolini > >> Yaro > >> > >> > > Oh, also: > > > > "That's way beyond the scope of a package manager, and also, there's no > > way to tell what "DEFAULTS" (why caps?) should be." > > > > Yes there is. The defaults are literally what's in the config file in > > the archive and not on the filesystem. How would that not be a way to > > determine default settings? > > > > I'm not suggesting the package manager would have to understand the > > settings, but it would be able to tell if the contents of that file are > > different from another version. (Which it obviously does already, > > otherwise it wouldn't know to make a pacnew file.) > > > > I can't imagine it'd be that difficult for pacman to compare checksums > > between files in /etc or /boot between versions of a package (If a > > previous version is available.) and what's on /etc and determine if it > > really needs to bother putting a pacnew file on the filesystem that > > doesn't need to be there. It's already doing some sort of check between > > what's in the package and what's on the filesystem already. > > > > Yaro > > pacman does this: if the *packaged file* changed between the installed > version and the new one, and the *installed file* is different from the > *packaged file*, then drop a .pacnew. > > I’m not sure what you want more… > > Bruno/Archange > But that is not what I am talking about. I'm discussing what is essentially three configuration files here: - The config in old-package. - The config in new-package. - The config on the filesystem. I already know pacman compares new-package and filesystem config. It does NOT do any check between old-package and new-package. What I'm saying is a pacnew seems unnecessary if the file between old-package and new-package are the same, because it means there's absolutely nothing of use to the user there, as either the user's made changes themselves and thus that file from the package is just going to be settings they don't want, or it's never been changed, in which case extracting the file's entirely redundant as it's literally still the same file. Pacman wouldn't do a pacnew in that case as it's implemented so that's beside the point. I'm not talking about the existing new-package to filesystem version checks, I'm talking about a case where if a package upgrade doesn't bring a new configuration change, the pacnew's just a waste of time and space (Albeit tiny amounts of space.) for the user. I'm suggesting pacman check not just between installed and new-package versions of the config but, if the old-package is still in the cache,
Re: [arch-general] No login after update
Le 20/08/2020 à 00:04, Yaro Kasear a écrit : > On 8/19/20 2:56 PM, Yaro Kasear wrote: >> On 8/19/20 2:48 PM, Giancarlo Razzolini via arch-general wrote: >>> Em agosto 19, 2020 16:37 Yaro Kasear escreveu: I've always questioned the wisdom of dropping a .pacnew just when the file is different from the default. There's really no reason for it considering any changes you made were deliberate and presumably thought out. The end result is pacman cluttering /etc with a default configuration file whose only reason for existing is to, if it's used, clear settings. Why? >>> The .pacnew is there to indicate that something new exists, or that >>> you changed >>> something. Most of the time you can remove .pacnew files, but not >>> always. Also, >>> it's only "cluttering" /etc (and /boot, btw), if you don't handle them. >>> What pacman SHOULD do is compare /etc files between package versions and see if there's a change BETWEEN DEFAULTS. *Then* there's an actual reason to need a new default config file for the user to examine because then there's an actual indicator some meaningful change in default configuration or how the package handles configs happened. >>> That's way beyond the scope of a package manager, and also, there's no >>> way >>> to tell what "DEFAULTS" (why caps?) should be. >> Caps for emphasis is all. All most pacnew files wind up doing is sitting there for thirty seconds before being deleted without anyone even opening them because they're literally just what the file was before the user ALREADY changed it before... because it's utterly useless to get a default config file when you've intentionally changed it and there's nothing in the new version of the package that calls for an examination of the defaults. >>> I don't know why you said that .pacnew sits for thirty seconds before >>> being >>> deleted. Are you using a hook that does this? Because nothing handles >>> them >>> automatically, that's the user's job. There are tools to aid in doing >>> that, >>> but in the end the user should know what to apply, and what to discard. >> I wasn't being literal about thirty seconds. Exaggerating. >>> Regards, >>> Giancarlo Razzolini >> Yaro >> >> > Oh, also: > > "That's way beyond the scope of a package manager, and also, there's no > way to tell what "DEFAULTS" (why caps?) should be." > > Yes there is. The defaults are literally what's in the config file in > the archive and not on the filesystem. How would that not be a way to > determine default settings? > > I'm not suggesting the package manager would have to understand the > settings, but it would be able to tell if the contents of that file are > different from another version. (Which it obviously does already, > otherwise it wouldn't know to make a pacnew file.) > > I can't imagine it'd be that difficult for pacman to compare checksums > between files in /etc or /boot between versions of a package (If a > previous version is available.) and what's on /etc and determine if it > really needs to bother putting a pacnew file on the filesystem that > doesn't need to be there. It's already doing some sort of check between > what's in the package and what's on the filesystem already. > > Yaro pacman does this: if the *packaged file* changed between the installed version and the new one, and the *installed file* is different from the *packaged file*, then drop a .pacnew. I’m not sure what you want more… Bruno/Archange
Re: [arch-general] No login after update
Em agosto 19, 2020 17:04 Yaro Kasear escreveu: Yes there is. The defaults are literally what's in the config file in the archive and not on the filesystem. How would that not be a way to determine default settings? I'm not suggesting the package manager would have to understand the settings, but it would be able to tell if the contents of that file are different from another version. (Which it obviously does already, otherwise it wouldn't know to make a pacnew file.) I can't imagine it'd be that difficult for pacman to compare checksums between files in /etc or /boot between versions of a package (If a previous version is available.) and what's on /etc and determine if it really needs to bother putting a pacnew file on the filesystem that doesn't need to be there. It's already doing some sort of check between what's in the package and what's on the filesystem already. How is everything you just said, different than what pacman already does? How would it determine not to create a .pacnew? If you can answer both these questions, I'd encourage you to send patches to pacman. Because I couldn't understand how what you said is any different than the current pacnew logic. Regards, Giancarlo Razzolini pgp4gjuokAph0.pgp Description: PGP signature
Re: [arch-general] No login after update
On 8/19/20 2:56 PM, Yaro Kasear wrote: > On 8/19/20 2:48 PM, Giancarlo Razzolini via arch-general wrote: >> Em agosto 19, 2020 16:37 Yaro Kasear escreveu: >>> I've always questioned the wisdom of dropping a .pacnew just when the >>> file is different from the default. There's really no reason for it >>> considering any changes you made were deliberate and presumably thought >>> out. The end result is pacman cluttering /etc with a default >>> configuration file whose only reason for existing is to, if it's used, >>> clear settings. Why? >>> >> The .pacnew is there to indicate that something new exists, or that >> you changed >> something. Most of the time you can remove .pacnew files, but not >> always. Also, >> it's only "cluttering" /etc (and /boot, btw), if you don't handle them. >> >>> What pacman SHOULD do is compare /etc files between package versions and >>> see if there's a change BETWEEN DEFAULTS. *Then* there's an actual >>> reason to need a new default config file for the user to examine because >>> then there's an actual indicator some meaningful change in default >>> configuration or how the package handles configs happened. >>> >> That's way beyond the scope of a package manager, and also, there's no >> way >> to tell what "DEFAULTS" (why caps?) should be. > Caps for emphasis is all. >>> All most pacnew files wind up doing is sitting there for thirty seconds >>> before being deleted without anyone even opening them because they're >>> literally just what the file was before the user ALREADY changed it >>> before... because it's utterly useless to get a default config file when >>> you've intentionally changed it and there's nothing in the new version >>> of the package that calls for an examination of the defaults. >>> >> I don't know why you said that .pacnew sits for thirty seconds before >> being >> deleted. Are you using a hook that does this? Because nothing handles >> them >> automatically, that's the user's job. There are tools to aid in doing >> that, >> but in the end the user should know what to apply, and what to discard. > I wasn't being literal about thirty seconds. Exaggerating. >> Regards, >> Giancarlo Razzolini > Yaro > > Oh, also: "That's way beyond the scope of a package manager, and also, there's no way to tell what "DEFAULTS" (why caps?) should be." Yes there is. The defaults are literally what's in the config file in the archive and not on the filesystem. How would that not be a way to determine default settings? I'm not suggesting the package manager would have to understand the settings, but it would be able to tell if the contents of that file are different from another version. (Which it obviously does already, otherwise it wouldn't know to make a pacnew file.) I can't imagine it'd be that difficult for pacman to compare checksums between files in /etc or /boot between versions of a package (If a previous version is available.) and what's on /etc and determine if it really needs to bother putting a pacnew file on the filesystem that doesn't need to be there. It's already doing some sort of check between what's in the package and what's on the filesystem already. Yaro signature.asc Description: OpenPGP digital signature
Re: [arch-general] No login after update
On 8/19/20 2:48 PM, Giancarlo Razzolini via arch-general wrote: > Em agosto 19, 2020 16:37 Yaro Kasear escreveu: >> >> I've always questioned the wisdom of dropping a .pacnew just when the >> file is different from the default. There's really no reason for it >> considering any changes you made were deliberate and presumably thought >> out. The end result is pacman cluttering /etc with a default >> configuration file whose only reason for existing is to, if it's used, >> clear settings. Why? >> > > The .pacnew is there to indicate that something new exists, or that > you changed > something. Most of the time you can remove .pacnew files, but not > always. Also, > it's only "cluttering" /etc (and /boot, btw), if you don't handle them. > >> What pacman SHOULD do is compare /etc files between package versions and >> see if there's a change BETWEEN DEFAULTS. *Then* there's an actual >> reason to need a new default config file for the user to examine because >> then there's an actual indicator some meaningful change in default >> configuration or how the package handles configs happened. >> > > That's way beyond the scope of a package manager, and also, there's no > way > to tell what "DEFAULTS" (why caps?) should be. Caps for emphasis is all. > >> All most pacnew files wind up doing is sitting there for thirty seconds >> before being deleted without anyone even opening them because they're >> literally just what the file was before the user ALREADY changed it >> before... because it's utterly useless to get a default config file when >> you've intentionally changed it and there's nothing in the new version >> of the package that calls for an examination of the defaults. >> > > I don't know why you said that .pacnew sits for thirty seconds before > being > deleted. Are you using a hook that does this? Because nothing handles > them > automatically, that's the user's job. There are tools to aid in doing > that, > but in the end the user should know what to apply, and what to discard. I wasn't being literal about thirty seconds. Exaggerating. > > Regards, > Giancarlo Razzolini Yaro signature.asc Description: OpenPGP digital signature
Re: [arch-general] No login after update
Em agosto 19, 2020 16:37 Yaro Kasear escreveu: I've always questioned the wisdom of dropping a .pacnew just when the file is different from the default. There's really no reason for it considering any changes you made were deliberate and presumably thought out. The end result is pacman cluttering /etc with a default configuration file whose only reason for existing is to, if it's used, clear settings. Why? The .pacnew is there to indicate that something new exists, or that you changed something. Most of the time you can remove .pacnew files, but not always. Also, it's only "cluttering" /etc (and /boot, btw), if you don't handle them. What pacman SHOULD do is compare /etc files between package versions and see if there's a change BETWEEN DEFAULTS. *Then* there's an actual reason to need a new default config file for the user to examine because then there's an actual indicator some meaningful change in default configuration or how the package handles configs happened. That's way beyond the scope of a package manager, and also, there's no way to tell what "DEFAULTS" (why caps?) should be. All most pacnew files wind up doing is sitting there for thirty seconds before being deleted without anyone even opening them because they're literally just what the file was before the user ALREADY changed it before... because it's utterly useless to get a default config file when you've intentionally changed it and there's nothing in the new version of the package that calls for an examination of the defaults. I don't know why you said that .pacnew sits for thirty seconds before being deleted. Are you using a hook that does this? Because nothing handles them automatically, that's the user's job. There are tools to aid in doing that, but in the end the user should know what to apply, and what to discard. Regards, Giancarlo Razzolini pgp_77edb9oPm.pgp Description: PGP signature
Re: [arch-general] No login after update
On 8/19/20 2:13 PM, Giancarlo Razzolini via arch-general wrote: > Em agosto 19, 2020 16:02 Manuel Reimer escreveu: >> Hello, >> >> Some minutes ago I did a regular system update and after that decided >> to reboot. After reboot I was unable to log into my system. After >> fiddling a bit I rebooted to an Arch boot stick to find the following >> message in pacman.log: >> >> [2020-08-19T20:42:55+0200] [ALPM] warning: /etc/pam.d/system-login >> installed as >> /etc/pam.d/system-login.pacnew >> > > The .pacnew should've been handled *before* rebooting. > >> As this seemed to be a candidate that may cause login problems, I >> deleted "system-login" and moved the ".pacnew" into place. >> >> After reboot I'm now able to log in again... >> >> IMHO something like this should not happen... >> >> Maybe it's worth a note on the Arch homepage that it is important to >> move this pacnew into place before reboot? >> > > This only affected you and whomever else changed system-login. It's > not news > material. Also, if you're messing with PAM, you should be responsible > for applying > the new stuff, otherwise it'll break, like it did for you. > > Regards, > Giancarlo Razzolini I've always questioned the wisdom of dropping a .pacnew just when the file is different from the default. There's really no reason for it considering any changes you made were deliberate and presumably thought out. The end result is pacman cluttering /etc with a default configuration file whose only reason for existing is to, if it's used, clear settings. Why? What pacman SHOULD do is compare /etc files between package versions and see if there's a change BETWEEN DEFAULTS. *Then* there's an actual reason to need a new default config file for the user to examine because then there's an actual indicator some meaningful change in default configuration or how the package handles configs happened. All most pacnew files wind up doing is sitting there for thirty seconds before being deleted without anyone even opening them because they're literally just what the file was before the user ALREADY changed it before... because it's utterly useless to get a default config file when you've intentionally changed it and there's nothing in the new version of the package that calls for an examination of the defaults. Yaro signature.asc Description: OpenPGP digital signature
Re: [arch-general] No login after update
Em agosto 19, 2020 16:02 Manuel Reimer escreveu: Hello, Some minutes ago I did a regular system update and after that decided to reboot. After reboot I was unable to log into my system. After fiddling a bit I rebooted to an Arch boot stick to find the following message in pacman.log: [2020-08-19T20:42:55+0200] [ALPM] warning: /etc/pam.d/system-login installed as /etc/pam.d/system-login.pacnew The .pacnew should've been handled *before* rebooting. As this seemed to be a candidate that may cause login problems, I deleted "system-login" and moved the ".pacnew" into place. After reboot I'm now able to log in again... IMHO something like this should not happen... Maybe it's worth a note on the Arch homepage that it is important to move this pacnew into place before reboot? This only affected you and whomever else changed system-login. It's not news material. Also, if you're messing with PAM, you should be responsible for applying the new stuff, otherwise it'll break, like it did for you. Regards, Giancarlo Razzolini pgpmtnk7IM_k3.pgp Description: PGP signature
Re: [arch-general] No login after update
Le 19 août 2020 23:02:12 GMT+04:00, Manuel Reimer a écrit : >Hello, > >I know that Arch is not for the "average user" and some background >knowledge is expected, but this was the first time I needed a boot stick >since I think at least one year. > >Some minutes ago I did a regular system update and after that decided to >reboot. After reboot I was unable to log into my system. After fiddling >a bit I rebooted to an Arch boot stick to find the following message in >pacman.log: > >[2020-08-19T20:42:55+0200] [ALPM] warning: /etc/pam.d/system-login >installed as >/etc/pam.d/system-login.pacnew > >As this seemed to be a candidate that may cause login problems, I >deleted "system-login" and moved the ".pacnew" into place. > >After reboot I'm now able to log in again... > >IMHO something like this should not happen... > >Maybe it's worth a note on the Arch homepage that it is important to >move this pacnew into place before reboot? > >Manuel Well, if you don’t read pacman output, you’re kind of asking for such troubles. ;) Also in this case, this means that you modified system-login at some point, else it would have been silently replaced. So no, it’s not worth a news entry. Regards, Bruno/Archange
Re: [arch-general] No login after update
This can only happen if you or another program modified the original file. Josef Miegl On August 19, 2020 9:02:12 PM GMT+02:00, Manuel Reimer wrote: >Hello, > >I know that Arch is not for the "average user" and some background >knowledge is expected, but this was the first time I needed a boot >stick >since I think at least one year. > >Some minutes ago I did a regular system update and after that decided >to >reboot. After reboot I was unable to log into my system. After fiddling > >a bit I rebooted to an Arch boot stick to find the following message in > >pacman.log: > >[2020-08-19T20:42:55+0200] [ALPM] warning: /etc/pam.d/system-login >installed as >/etc/pam.d/system-login.pacnew > >As this seemed to be a candidate that may cause login problems, I >deleted "system-login" and moved the ".pacnew" into place. > >After reboot I'm now able to log in again... > >IMHO something like this should not happen... > >Maybe it's worth a note on the Arch homepage that it is important to >move this pacnew into place before reboot? > >Manuel
[arch-general] No login after update
Hello, I know that Arch is not for the "average user" and some background knowledge is expected, but this was the first time I needed a boot stick since I think at least one year. Some minutes ago I did a regular system update and after that decided to reboot. After reboot I was unable to log into my system. After fiddling a bit I rebooted to an Arch boot stick to find the following message in pacman.log: [2020-08-19T20:42:55+0200] [ALPM] warning: /etc/pam.d/system-login installed as /etc/pam.d/system-login.pacnew As this seemed to be a candidate that may cause login problems, I deleted "system-login" and moved the ".pacnew" into place. After reboot I'm now able to log in again... IMHO something like this should not happen... Maybe it's worth a note on the Arch homepage that it is important to move this pacnew into place before reboot? Manuel
Re: [arch-general] HP Laserjet plus 1020 Problem
Em agosto 19, 2020 12:17 das via arch-general escreveu: Dear Friend I installed the AUR package hplip-plugin. But still it is not working. No page can be printed. It is getting detected. And then no print. If it did not work in Debian Surge, I would have thought there is a problem in the printer. Can you suggest anything else? I believe your printer works without hplip and using the driverless option. That's something you can also try. Regards, Giancarlo Razzolini pgpAaV47cZoSk.pgp Description: PGP signature
Re: [arch-general] HP Laserjet plus 1020 Problem
On Wed, Aug 19, 2020 at 7:37 PM Andreas Bosch wrote: > > according to HP you need the binary hplip-plugin from the AUR for your > printer: > > https://developers.hp.com/hp-linux-imaging-and-printing/binary_plugin.html > > https://aur.archlinux.org/packages/hplip-plugin/ > Dear Friend I installed the AUR package hplip-plugin. But still it is not working. No page can be printed. It is getting detected. And then no print. If it did not work in Debian Surge, I would have thought there is a problem in the printer. Can you suggest anything else? -- দাশ das http://ddts.randomink.org/
[arch-general] pam-1.3.1-2 -> 1.4.0-3 breaking change
it seems the 1.4.0-3 removed the tally/tally2 modules and (for some reason) I had `auth required pam_tally2.so` in /etc/pam.d/system-login. Of course that broke the login and I had to rescue the installation from a bootable USB. I wonder if there can be some pam-lint tool that checks your /etc/pam.d/ after upgrades. -- damjan
Re: [arch-general] HP Laserjet plus 1020 Problem
19.08.2020 16:52, das via arch-general: Dear friend Karx asked me to try to print something and then give the differences in the three files in /var/log/cups. I tried to print one page from Libreoffice Writer and here is the result of running diff for the old and new versions of the three files for the three files. You seem to just learn the first basic steps of debugging and finding a problem in your linux setup. The mailinglist is not a good place for that, it is meant for more in-detail discussions of interest for many. You might be better off opening a thread at the forum [0], where somone can slowly walk you through the process. This helps both you (you learn a lot more than here with very short answers) and the subscribers of this list (less irrelevant noise). Thank you and good luck [0] bbs.archlinux.org
Re: [arch-general] HP Laserjet plus 1020 Problem
Dear friend Karx asked me to try to print something and then give the differences in the three files in /var/log/cups. I tried to print one page from Libreoffice Writer and here is the result of running diff for the old and new versions of the three files for the three files. For access_log the difference is: 186,195d185 < localhost - - [19/Aug/2020:20:10:02 +0530] "POST /printers/HP-LaserJet-1020 HTTP/1.1" 200 215 Create-Job successful-ok < localhost - - [19/Aug/2020:20:10:02 +0530] "POST /printers/HP-LaserJet-1020 HTTP/1.1" 200 29704 Send-Document successful-ok < localhost - - [19/Aug/2020:20:10:24 +0530] "POST /jobs/ HTTP/1.1" 200 151 Cancel-Job client-error-not-found < localhost - - [19/Aug/2020:20:10:24 +0530] "POST /jobs/ HTTP/1.1" 200 151 Cancel-Job client-error-not-found < localhost - - [19/Aug/2020:20:10:24 +0530] "POST /jobs/ HTTP/1.1" 200 151 Cancel-Job client-error-not-found < localhost - - [19/Aug/2020:20:10:24 +0530] "POST /jobs/ HTTP/1.1" 200 151 Cancel-Job client-error-not-found < localhost - - [19/Aug/2020:20:10:24 +0530] "POST /jobs/ HTTP/1.1" 200 151 Cancel-Job client-error-not-found < localhost - - [19/Aug/2020:20:10:24 +0530] "POST /jobs/ HTTP/1.1" 200 151 Cancel-Job client-error-not-found < localhost - - [19/Aug/2020:20:10:24 +0530] "POST /jobs/ HTTP/1.1" 200 151 Cancel-Job client-error-not-found < localhost - - [19/Aug/2020:20:10:24 +0530] "POST /jobs/ HTTP/1.1" 200 151 Cancel-Job client-error-not-found --- error_log -- no difference -- page_log -- no difference
Re: [arch-general] HP Laserjet plus 1020 Problem
Try printing something out, then look for changes in those three files. Yash
Re: [arch-general] HP Laserjet plus 1020 Problem
On Wed, Aug 19, 2020 at 7:48 PM karx via arch-general wrote: > > > > Sorry, I meant the log files in /var/log/cups/ > > > > Oh, my bad! > > > /var/log/cups/ has three files: access_log error_log page_log The error_log has 2564 lines. Shall I send it to you? -- দাস das http://ddts.randomink.org/ -- দাশ das http://ddts.randomink.org/
Re: [arch-general] HP Laserjet plus 1020 Problem
Dear Friends I am replying to you all in one message. I installed hplip-plugin. Now what to do? The printer is connected to USB 001:004. It is getting detected and system-config-printer is showing it. But, no test page is getting printed. Shall I post cupsd.conf and cups-files.conf as attachments? On Wed, Aug 19, 2020 at 7:41 PM karx via arch-general wrote: > > On Wed, Aug 19, 2020, 9:08 AM das via arch-general < > arch-general@archlinux.org> wrote: > > > > I am not > > sure what you mean by 'cups file'. Can you please ask me simple > > specific questions? > > > > Hi, > > I think by 'cups file', he means your cups configuration file. > > > Yash > > > -- দাস das http://ddts.randomink.org/ -- দাশ das http://ddts.randomink.org/
Re: [arch-general] HP Laserjet plus 1020 Problem
On Wed, Aug 19, 2020, 9:15 AM Andy Pieters wrote: > On Wed, 19 Aug 2020 at 15:11, karx via arch-general < > arch-general@archlinux.org> wrote: > > > On Wed, Aug 19, 2020, 9:08 AM das via arch-general < > > arch-general@archlinux.org> wrote: > > > > > > > I am not > > > sure what you mean by 'cups file'. Can you please ask me simple > > > specific questions? > > > > > > > Hi, > > > > I think by 'cups file', he means your cups configuration file. > > > > Sorry, I meant the log files in /var/log/cups/ > Oh, my bad! >
Re: [arch-general] HP Laserjet plus 1020 Problem
On Wed, 19 Aug 2020 at 15:11, karx via arch-general < arch-general@archlinux.org> wrote: > On Wed, Aug 19, 2020, 9:08 AM das via arch-general < > arch-general@archlinux.org> wrote: > > > > I am not > > sure what you mean by 'cups file'. Can you please ask me simple > > specific questions? > > > > Hi, > > I think by 'cups file', he means your cups configuration file. > > Sorry, I meant the log files in /var/log/cups/
Re: [arch-general] HP Laserjet plus 1020 Problem
On Wed, Aug 19, 2020, 9:08 AM das via arch-general < arch-general@archlinux.org> wrote: > I am not > sure what you mean by 'cups file'. Can you please ask me simple > specific questions? > Hi, I think by 'cups file', he means your cups configuration file. Yash >
Re: [arch-general] HP Laserjet plus 1020 Problem
Come on, do a little bit of homework and give at least some proper info to help you troubleshoot your stuff. How are you connecting to the printer, via wireless or ethernet or usb? What does it mean "not working" under Arch? Printer connected but not printing, printer not recognized, ...what? Learn to ask before asking for help. I have never encountered any problem with HP printers under Arch, so the problem must be in your lack of knowledge of your own system. Good luck, domanov
Re: [arch-general] HP Laserjet plus 1020 Problem
On Wed, Aug 19, 2020 at 7:32 PM Andy Pieters wrote: > > Hi > > On Wed, 19 Aug 2020 at 14:58, das via arch-general < > arch-general@archlinux.org> wrote: > > > > > But, still it is not working. > > > > > Can we get the obvious out of the way, and confirm that you have got cups > installed and running, please? > > Any hints in your cups file when you try to print? Yes, cups and system-config-printer both are installed. And I am not sure what you mean by 'cups file'. Can you please ask me simple specific questions? -- দাশ das http://ddts.randomink.org/
Re: [arch-general] HP Laserjet plus 1020 Problem
Am 19.08.20 um 16:00 schrieb das via arch-general: > I tried the proces given here before reinstalling hplip > > https://bbs.archlinux.org/viewtopic.php?id=218509 > > And that did not work too. > Hi, according to HP you need the binary hplip-plugin from the AUR for your printer: https://developers.hp.com/hp-linux-imaging-and-printing/binary_plugin.html https://aur.archlinux.org/packages/hplip-plugin/ This is also mentioned in the wiki: https://wiki.archlinux.org/index.php/CUPS/Printer-specific_problems#HPLIP -- AB
Re: [arch-general] HP Laserjet plus 1020 Problem
Hi On Wed, 19 Aug 2020 at 14:58, das via arch-general < arch-general@archlinux.org> wrote: > > But, still it is not working. > > Can we get the obvious out of the way, and confirm that you have got cups installed and running, please? Any hints in your cups file when you try to print? Thanks
Re: [arch-general] HP Laserjet plus 1020 Problem
I tried the proces given here before reinstalling hplip https://bbs.archlinux.org/viewtopic.php?id=218509 And that did not work too.
Re: [arch-general] HP Laserjet plus 1020 Problem
The hplip Webpage (https://developers.hp.com/hp-linux-imaging-and-printing/supported_devices/index) gives the following line for this printer: HP LaserJet 1020 Plus Printer, Minimum hplip version: 2.7.10, Driver plugin:Yes, Support Level: Full (End of support) But, still it is not working. -- দাশ das http://ddts.randomink.org/
Re: [arch-general] HP Laserjet plus 1020 Problem
On Wed, Aug 19, 2020 at 7:04 PM Rafael Fontenelle wrote: > Have you tried installing the "hplip" package, which provides PPD for > your printer? > > Installing removing reinstalling hplip -- nothing worked. Ok, as you suggest I will now explore the ArchWiki links you have provided. -- দাস das http://ddts.randomink.org/ -- দাশ das http://ddts.randomink.org/
Re: [arch-general] HP Laserjet plus 1020 Problem
On Wed, Aug 19, 2020 at 10:30 AM das via arch-general wrote: > > Dear Friends > > My new printer HP Laserjet plus 1020 is not working on Arch Linux, > while it is working fine on the second boot Debian system. I have > tried all the ways that came to my mind or all the suggestions from > the Net. It is not working. > > Can any of you suggest anything? > > With Regards > Dipankar Das > > -- > দাশ das > http://ddts.randomink.org/ Hello, Have you tried installing the "hplip" package, which provides PPD for your printer? Also have you checked the ArchWiki pages below? https://wiki.archlinux.org/index.php/CUPS/Printer-specific_problems#HP https://wiki.archlinux.org/index.php/CUPS/Troubleshooting#HP_issues https://wiki.archlinux.org/index.php/CUPS Best regards, Rafael Fontenelle
[arch-general] HP Laserjet plus 1020 Problem
Dear Friends My new printer HP Laserjet plus 1020 is not working on Arch Linux, while it is working fine on the second boot Debian system. I have tried all the ways that came to my mind or all the suggestions from the Net. It is not working. Can any of you suggest anything? With Regards Dipankar Das -- দাশ das http://ddts.randomink.org/
