Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #173888 > unrolled thread
| Started by | "D. R. Evans" <doc.evans@gmail.com> |
|---|---|
| First post | 2016-10-27 01:50 +0200 |
| Last post | 2016-10-27 20:30 +0200 |
| Articles | 20 on this page of 26 — 6 participants |
Back to article view | Back to linux.debian.user
[jessie] recording line-in using ALSA? "D. R. Evans" <doc.evans@gmail.com> - 2016-10-27 01:50 +0200
Re: [jessie] recording line-in using ALSA? deloptes <deloptes@gmail.com> - 2016-10-27 08:40 +0200
Re: [jessie] recording line-in using ALSA? "D. R. Evans" <doc.evans@gmail.com> - 2016-10-27 20:10 +0200
Re: [jessie] recording line-in using ALSA? deloptes <deloptes@gmail.com> - 2016-10-27 20:20 +0200
[SOLVED] Re: [jessie] recording line-in using ALSA? "D. R. Evans" <doc.evans@gmail.com> - 2016-10-27 22:00 +0200
Re: [SOLVED] Re: [jessie] recording line-in using ALSA? Ric Moore <wayward4now@gmail.com> - 2016-10-28 05:50 +0200
Re: [SOLVED] Re: [jessie] recording line-in using ALSA? deloptes <deloptes@gmail.com> - 2016-10-28 23:50 +0200
Re: [SOLVED] Re: [jessie] recording line-in using ALSA? Ric Moore <wayward4now@gmail.com> - 2016-10-29 18:40 +0200
Re: [SOLVED] Re: [jessie] recording line-in using ALSA? Reco <recoverym4n@gmail.com> - 2016-10-29 19:10 +0200
Re: [SOLVED] Re: [jessie] recording line-in using ALSA? deloptes <deloptes@gmail.com> - 2016-10-29 20:00 +0200
Re: [SOLVED] Re: [jessie] recording line-in using ALSA? Reco <recoverym4n@gmail.com> - 2016-10-29 21:00 +0200
Re: [SOLVED] Re: [jessie] recording line-in using ALSA? Brian <ad44@cityscape.co.uk> - 2016-10-29 21:40 +0200
Re: [SOLVED] Re: [jessie] recording line-in using ALSA? deloptes <deloptes@gmail.com> - 2016-10-29 23:10 +0200
Re: [OT] Sorry state of hplip (was: [SOLVED] Re: [jessie] recording line-in using ALSA?) Reco <recoverym4n@gmail.com> - 2016-10-29 23:30 +0200
Re: [OT] Sorry state of hplip (was: [SOLVED] Re: [jessie] recording line-in using ALSA?) deloptes <deloptes@gmail.com> - 2016-10-29 23:40 +0200
Re: [OT] Sorry state of hplip (was: [SOLVED] Re: [jessie] recording line-in using ALSA?) Brian <ad44@cityscape.co.uk> - 2016-10-30 15:30 +0100
Re: [OT] Sorry state of hplip (was: [SOLVED] Re: [jessie] recording line-in using ALSA?) Reco <recoverym4n@gmail.com> - 2016-10-30 16:30 +0100
Re: [OT] Sorry state of hplip (was: [SOLVED] Re: [jessie] recording line-in using ALSA?) Brian <ad44@cityscape.co.uk> - 2016-10-30 18:20 +0100
Re: [OT] Sorry state of hplip (was: [SOLVED] Re: [jessie] recording line-in using ALSA?) Reco <recoverym4n@gmail.com> - 2016-10-31 15:20 +0100
Re: [OT] Sorry state of hplip (was: [SOLVED] Re: [jessie] recording line-in using ALSA?) Brian <ad44@cityscape.co.uk> - 2016-10-31 16:20 +0100
Re: [OT] Sorry state of hplip (was: [SOLVED] Re: [jessie] recording line-in using ALSA?) Jonathan Dowland <jmtd@debian.org> - 2016-10-31 16:50 +0100
Re: [OT] Sorry state of hplip (was: [SOLVED] Re: [jessie] recording line-in using ALSA?) Brian <ad44@cityscape.co.uk> - 2016-10-31 19:50 +0100
Re: [OT] Sorry state of hplip (was: [SOLVED] Re: [jessie] recording line-in using ALSA?) deloptes <deloptes@gmail.com> - 2016-10-30 20:00 +0100
Re: [OT] Sorry state of hplip (was: [SOLVED] Re: [jessie] recording line-in using ALSA?) Brian <ad44@cityscape.co.uk> - 2016-10-30 20:50 +0100
Re: [OT] Sorry state of hplip (was: [SOLVED] Re: [jessie] recording line-in using ALSA?) Reco <recoverym4n@gmail.com> - 2016-10-31 14:20 +0100
Re: [jessie] recording line-in using ALSA? deloptes <deloptes@gmail.com> - 2016-10-27 20:30 +0200
Page 1 of 2 [1] 2 Next page →
| From | "D. R. Evans" <doc.evans@gmail.com> |
|---|---|
| Date | 2016-10-27 01:50 +0200 |
| Subject | [jessie] recording line-in using ALSA? |
| Message-ID | <swG7f-2fy-5@gated-at.bofh.it> |
[Multipart message — attachments visible in raw view] — view raw
I am trying to set up the ability to record line-in, but have been unable to
make it work and would appreciate advice. (I have looked at quite a few web
pages of various kinds of help for ALSA, but all of them seem to be rather
vague on the details of recording.)
The hardware is very simple:
----
n7dr@shack:~$ cat /proc/asound/cards
0 [IXP ]: ATIIXP - ATI IXP
ATI IXP rev 2 with ALC658D at 0xfe02a000, irq 17
n7dr@shack:~$
----
The card has a mic input, a line input, and a speaker output.
If I simply run aplay with a WAV file, I hear the contents of the file. For
example:
----
n7dr@shack:~$ aplay -D hw:0,0 c*.wav
----
causes the named file to play. So *playing* seems to be fine.
However, I have been unable to find any way to record the line input.
Everything I have tried has resulted in silence in the output file.
For example:
----
n7dr@shack:~$ arecord -D hw:0,0 -fdat foo.wav
----
produces the file foo.wav, with silence.
amixer says:
----
n7dr@shack:~$ amixer
Simple mixer control 'Master',0
Capabilities: pvolume pswitch pswitch-joined
Playback channels: Front Left - Front Right
Limits: Playback 0 - 65536
Mono:
Front Left: Playback 55141 [84%] [on]
Front Right: Playback 55141 [84%] [on]
Simple mixer control 'Capture',0
Capabilities: cvolume cswitch cswitch-joined
Capture channels: Front Left - Front Right
Limits: Capture 0 - 65536
Front Left: Capture 53640 [82%] [off]
Front Right: Capture 53640 [82%] [off]
n7dr@shack:~$
----
which seems to be OK, insofar as I understand it, except that there is no
indication of whether the capture device is line-in or the mic line. I haven't
been able to find anything that explicitly tells me how to set the capture
device to be the line in.
alsamixer looks like this when viewing the Capture item:
───────────────────── AlsaMixer v1.0.28 ─────────────────────┐
│ Card: PulseAudio F1: Help │
│ Chip: PulseAudio F2: System information │
│ View: Capture F6: Select sound card │
│ Item: Capture Esc: Exit │
│ │
│ │
│ │
│ │
│ │
│ │
│ │
│ │
│ ┌──┐ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │▒▒│ │
│ │▒▒│ │
│ │▒▒│ │
│ │▒▒│ │
│ │▒▒│ │
│ │▒▒│ │
│ │▒▒│ │
│ │▒▒│ │
│ │▒▒│ │
│ │▒▒│ │
│ │▒▒│ │
│ │▒▒│ │
│ │▒▒│ │
│ │▒▒│ │
│ │▒▒│ │
│ │▒▒│ │
│ │▒▒│ │
│ │▒▒│ │
│ │▒▒│ │
│ │▒▒│ │
│ L└──┘R │
│ CAPTURE │
│ 82<>82 │
│ <Capture > │
│ │
│ │
│ │
│ │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────┘
I've also tried plugging the incoming audio into the mic socket (in case
that's what's being captured), and that just records silence as well.
So I suppose that my questions are:
1. How do I tell alsa that I want to capture from line-in?
2. How do I actually record the audio that I'm sending on the line-in line?
If more information is needed before these questions can be answered, please
let me know and I'll provide it.
Doc Evans
--
Web: http://www.sff.net/people/N7DR
[toc] | [next] | [standalone]
| From | deloptes <deloptes@gmail.com> |
|---|---|
| Date | 2016-10-27 08:40 +0200 |
| Message-ID | <swMw2-6AV-27@gated-at.bofh.it> |
| In reply to | #173888 |
D. R. Evans wrote: > I am trying to set up the ability to record line-in, but have been unable > to make it work and would appreciate advice. (I have looked at quite a few > web pages of various kinds of help for ALSA, but all of them seem to be > rather vague on the details of recording.) > > The hardware is very simple: > > ---- > > n7dr@shack:~$ cat /proc/asound/cards > 0 [IXP ]: ATIIXP - ATI IXP > ATI IXP rev 2 with ALC658D at 0xfe02a000, irq 17 > n7dr@shack:~$ > > ---- > > The card has a mic input, a line input, and a speaker output. > > If I simply run aplay with a WAV file, I hear the contents of the file. > For example: > > ---- > > n7dr@shack:~$ aplay -D hw:0,0 c*.wav > > ---- > > causes the named file to play. So *playing* seems to be fine. > > However, I have been unable to find any way to record the line input. > Everything I have tried has resulted in silence in the output file. > > For example: > > ---- > > n7dr@shack:~$ arecord -D hw:0,0 -fdat foo.wav > It is very simple 1) find out the input shell> cat /proc/asound/devices 0: [ 0] : control 1: : sequencer 6: [ 0- 2]: hardware dependent 7: [ 0- 3]: hardware dependent 16: [ 0- 0]: digital audio playback 17: [ 0- 1]: digital audio playback 19: [ 0- 3]: digital audio playback 24: [ 0- 0]: digital audio capture 32: [ 1] : control 33: : timer 56: [ 1- 0]: digital audio capture 64: [ 2] : control 88: [ 2- 0]: digital audio capture => my input is the capture on the second card 88: [ 2- 0]: digital audio capture 2) so no we can test the input shell> arecord -c2 -Dplughw:2,0 -f cd -vv /dev/null You will see if recording can be done on the screen > ---- > > produces the file foo.wav, with silence. > > amixer says: > > ---- > > n7dr@shack:~$ amixer > Simple mixer control 'Master',0 > Capabilities: pvolume pswitch pswitch-joined > Playback channels: Front Left - Front Right > Limits: Playback 0 - 65536 > Mono: > Front Left: Playback 55141 [84%] [on] > Front Right: Playback 55141 [84%] [on] > Simple mixer control 'Capture',0 > Capabilities: cvolume cswitch cswitch-joined > Capture channels: Front Left - Front Right > Limits: Capture 0 - 65536 > Front Left: Capture 53640 [82%] [off] > Front Right: Capture 53640 [82%] [off] > n7dr@shack:~$ > > ---- > > which seems to be OK, insofar as I understand it, except that there is no > indication of whether the capture device is line-in or the mic line. I > haven't been able to find anything that explicitly tells me how to set the > capture device to be the line in. > > alsamixer looks like this when viewing the Capture item: > > > ───────────────────── AlsaMixer v1.0.28 ─────────────────────┐ > │ Card: PulseAudio F1: Help │ > │ Chip: PulseAudio F2: System information │ > │ View: Capture F6: Select sound card │ > │ Item: Capture Esc: Exit │ > │ │ > │ │ > │ │ > │ │ > │ │ > │ │ > │ │ > │ │ > │ ┌──┐ │ > │ │ │ │ > │ │ │ │ > │ │ │ │ > │ │ │ │ > │ │ │ │ > │ │▒▒│ │ > │ │▒▒│ │ > │ │▒▒│ │ > │ │▒▒│ │ > │ │▒▒│ │ > │ │▒▒│ │ > │ │▒▒│ │ > │ │▒▒│ │ > │ │▒▒│ │ > │ │▒▒│ │ > │ │▒▒│ │ > │ │▒▒│ │ > │ │▒▒│ │ > │ │▒▒│ │ > │ │▒▒│ │ > │ │▒▒│ │ > │ │▒▒│ │ > │ │▒▒│ │ > │ │▒▒│ │ > │ │▒▒│ │ > │ L└──┘R │ > │ CAPTURE │ > │ 82<>82 │ > │ <Capture > │ > │ │ > │ │ > │ │ > │ │ > │ │ > │ │ > │ │ > │ │ > └─────────────────────────────────────────────────────────────┘ > > I've also tried plugging the incoming audio into the mic socket (in case > that's what's being captured), and that just records silence as well. > > So I suppose that my questions are: > > 1. How do I tell alsa that I want to capture from line-in? > > 2. How do I actually record the audio that I'm sending on the line-in > line? > > If more information is needed before these questions can be answered, > please let me know and I'll provide it. > > Doc Evans > You are looking at PulseAudio, not at ALSA mixer Try alsamixer -c0 and check the input section regards
[toc] | [prev] | [next] | [standalone]
| From | "D. R. Evans" <doc.evans@gmail.com> |
|---|---|
| Date | 2016-10-27 20:10 +0200 |
| Message-ID | <swXhM-5la-37@gated-at.bofh.it> |
| In reply to | #173897 |
[Multipart message — attachments visible in raw view] — view raw
deloptes wrote on 10/27/2016 12:32 AM: > > It is very simple I am glad to hear it. > > 1) find out the input > > shell> cat /proc/asound/devices ---- n7dr@shack:~$ cat /proc/asound/devices 2: [ 0] : control 3: [ 0- 0]: digital audio playback 4: [ 0- 0]: digital audio capture 5: [ 0- 1]: digital audio playback 33: : timer n7dr@shack:~$ ---- > > => my input is the capture on the second card > > 88: [ 2- 0]: digital audio capture So presumably the equivalent on my system is: 4: [ 0- 0]: digital audio capture > > 2) so no we can test the input > > shell> arecord -c2 -Dplughw:2,0 -f cd -vv /dev/null This is essentially how I have been trying to record, and it just creates silence. Specifically, I just tried: ---- n7dr@shack:~$ arecord -c2 -Dplughw:0,0 -f cd -vv foo.wav Recording WAVE 'foo.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo Plug PCM: Hardware PCM card 0 'ATI IXP' device 0 subdevice 0 Its setup is: stream : CAPTURE access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 44100 exact rate : 44100 (44100/1) msbits : 16 buffer_size : 16384 period_size : 4096 period_time : 92879 tstamp_mode : NONE period_step : 1 avail_min : 4096 period_event : 0 start_threshold : 1 stop_threshold : 16384 silence_threshold: 0 silence_size : 0 boundary : 1073741824 appl_ptr : 0 hw_ptr : 0 ---- That creates foo.wav. And when I play foo.wav, it just plays silence. (I did remember to make sure that audio was being played on the line-in line :-).) > > You are looking at PulseAudio, not at ALSA mixer > I don't understand that statement. Quoting my e-mail: > alsamixer looks like this when viewing the Capture item: > > > ───────────────────── AlsaMixer v1.0.28 ─────────────────────┐ That output states that it is from alsamixer. (Unfortunately, alsamixer clears the screen so that the name of the command isn't visible; but I assure you that what I typed was "alsamixer" (with no parameters).) I know that the output from "alsamixer" says "Pulseaudio"; I have no idea why it says that. But I was definitely looking at ALSA mixer. > Try alsamixer -c0 and check the input section > Hmmm. I see this: https://dl.dropboxusercontent.com/u/18494055/audio/alsamixer-1.png which doesn't mean much to me (that is, I don't know whether it looks reasonable). Doc -- Web: http://www.sff.net/people/N7DR
[toc] | [prev] | [next] | [standalone]
| From | deloptes <deloptes@gmail.com> |
|---|---|
| Date | 2016-10-27 20:20 +0200 |
| Message-ID | <swXrs-5ri-13@gated-at.bofh.it> |
| In reply to | #173907 |
D. R. Evans wrote: > That output states that it is from alsamixer. (Unfortunately, alsamixer > clears the screen so that the name of the command isn't visible; but I > assure you that what I typed was "alsamixer" (with no parameters).) > I meant not the alsa mixer but alsa. Sorry for that > I know that the output from "alsamixer" says "Pulseaudio"; I have no idea > why it says that. But I was definitely looking at ALSA mixer. > >> Try alsamixer -c0 and check the input section >> > > Hmmm. I see this: > > https://dl.dropboxusercontent.com/u/18494055/audio/alsamixer-1.png > > which doesn't mean much to me (that is, I don't know whether it looks > reasonable). > It looks reasonable. What you can do, since you have pulse installed, you could run pavucontrol and setup the input devices properly. Perhaps your problem is visible there - muted/default etc. I usually start recording and run pavucontrol, navigate to "Input Devices" and look at the indicator - it should show the level of input, play with those until it works :) regards
[toc] | [prev] | [next] | [standalone]
| From | "D. R. Evans" <doc.evans@gmail.com> |
|---|---|
| Date | 2016-10-27 22:00 +0200 |
| Subject | [SOLVED] Re: [jessie] recording line-in using ALSA? |
| Message-ID | <swZ0d-6cZ-7@gated-at.bofh.it> |
| In reply to | #173908 |
[Multipart message — attachments visible in raw view] — view raw
deloptes wrote on 10/27/2016 12:14 PM: >> > > It looks reasonable. What you can do, since you have pulse installed, you > could run pavucontrol and setup the input devices properly. Perhaps your > problem is visible there - muted/default etc. I usually start recording and > run pavucontrol, navigate to "Input Devices" and look at the indicator - it > should show the level of input, play with those until it works :) > Excellent! pavucontrol wasn't installed, but I installed it and played with the Input Devices tab. And that's when I discovered that I should have been recording from "Aux" rather than from "Line". When I configured ALSA to record from Aux on hw:0,0, it worked perfectly. Thank you so much for suggesting pavucontrol. FWIW, I had been thinking all along that this problem would be so much easier to solve if only there were a way to monitor what was happening in real time; as far as I can tell, ALSA itself doesn't provide any way to do that :-( Thank you again. Doc -- Web: http://www.sff.net/people/N7DR
[toc] | [prev] | [next] | [standalone]
| From | Ric Moore <wayward4now@gmail.com> |
|---|---|
| Date | 2016-10-28 05:50 +0200 |
| Subject | Re: [SOLVED] Re: [jessie] recording line-in using ALSA? |
| Message-ID | <sx6l3-2Ra-1@gated-at.bofh.it> |
| In reply to | #173910 |
On 10/27/2016 03:58 PM, D. R. Evans wrote: > deloptes wrote on 10/27/2016 12:14 PM: > >>> >> >> It looks reasonable. What you can do, since you have pulse installed, you >> could run pavucontrol and setup the input devices properly. Perhaps your >> problem is visible there - muted/default etc. I usually start recording and >> run pavucontrol, navigate to "Input Devices" and look at the indicator - it >> should show the level of input, play with those until it works :) >> > > Excellent! > > pavucontrol wasn't installed, but I installed it and played with the Input > Devices tab. > > And that's when I discovered that I should have been recording from "Aux" > rather than from "Line". > > When I configured ALSA to record from Aux on hw:0,0, it worked perfectly. > > Thank you so much for suggesting pavucontrol. FWIW, I had been thinking all > along that this problem would be so much easier to solve if only there were a > way to monitor what was happening in real time; as far as I can tell, ALSA > itself doesn't provide any way to do that :-( > > Thank you again. pavucontrol should have been a depend on pulseaudio since the beginning as you can't do squat without it. Try to remove firefox and you lose your entire desktop. Go figure. Ric -- My father, Victor Moore (Vic) used to say: "There are two Great Sins in the world... ..the Sin of Ignorance, and the Sin of Stupidity. Only the former may be overcome." R.I.P. Dad. http://linuxcounter.net/user/44256.html
[toc] | [prev] | [next] | [standalone]
| From | deloptes <deloptes@gmail.com> |
|---|---|
| Date | 2016-10-28 23:50 +0200 |
| Subject | Re: [SOLVED] Re: [jessie] recording line-in using ALSA? |
| Message-ID | <sxnce-5pM-13@gated-at.bofh.it> |
| In reply to | #173925 |
Ric Moore wrote: > pavucontrol should have been a depend on pulseaudio since the beginning > as you can't do squat without it. Try to remove firefox and you lose > your entire desktop. Go figure. Ric Thank you Ric. I don't think pavucontrol depends on pulseaudio apt-cache show pulseaudio Package: pulseaudio Suggests: pavumeter, pavucontrol, paman, paprefs
[toc] | [prev] | [next] | [standalone]
| From | Ric Moore <wayward4now@gmail.com> |
|---|---|
| Date | 2016-10-29 18:40 +0200 |
| Subject | Re: [SOLVED] Re: [jessie] recording line-in using ALSA? |
| Message-ID | <sxEPM-vT-53@gated-at.bofh.it> |
| In reply to | #173958 |
On 10/28/2016 05:39 PM, deloptes wrote: > Ric Moore wrote: > >> pavucontrol should have been a depend on pulseaudio since the beginning >> as you can't do squat without it. Try to remove firefox and you lose >> your entire desktop. Go figure. Ric > > Thank you Ric. > > I don't think pavucontrol depends on pulseaudio > > apt-cache show pulseaudio > Package: pulseaudio > Suggests: pavumeter, pavucontrol, paman, paprefs Right, pavucontrol is a suggest instead of a depend. I think it should be a depend. -- My father, Victor Moore (Vic) used to say: "There are two Great Sins in the world... ..the Sin of Ignorance, and the Sin of Stupidity. Only the former may be overcome." R.I.P. Dad. http://linuxcounter.net/user/44256.html
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@gmail.com> |
|---|---|
| Date | 2016-10-29 19:10 +0200 |
| Subject | Re: [SOLVED] Re: [jessie] recording line-in using ALSA? |
| Message-ID | <sxFiN-VC-13@gated-at.bofh.it> |
| In reply to | #173990 |
Hi. On Sat, 29 Oct 2016 12:34:44 -0400 Ric Moore <wayward4now@gmail.com> wrote: > On 10/28/2016 05:39 PM, deloptes wrote: > > Ric Moore wrote: > > > >> pavucontrol should have been a depend on pulseaudio since the beginning > >> as you can't do squat without it. Try to remove firefox and you lose > >> your entire desktop. Go figure. Ric > > > > Thank you Ric. > > > > I don't think pavucontrol depends on pulseaudio > > > > apt-cache show pulseaudio > > Package: pulseaudio > > Suggests: pavumeter, pavucontrol, paman, paprefs > > Right, pavucontrol is a suggest instead of a depend. I think it should > be a depend. So basically you're proposing to force the user to install GTK3 (with both C and C++ bindinds) just to install pulseaudio. There are reasons that this distribution is called Debian, not You-favorite-enterprisey-tangled-dependency-mess, and one of those reasons is a careful placement of dependencies. Reco
[toc] | [prev] | [next] | [standalone]
| From | deloptes <deloptes@gmail.com> |
|---|---|
| Date | 2016-10-29 20:00 +0200 |
| Subject | Re: [SOLVED] Re: [jessie] recording line-in using ALSA? |
| Message-ID | <sxG5c-1ew-9@gated-at.bofh.it> |
| In reply to | #173992 |
Reco wrote: > So basically you're proposing to force the user to install GTK3 (with > both C and C++ bindinds) just to install pulseaudio. > > There are reasons that this distribution is called Debian, not > You-favorite-enterprisey-tangled-dependency-mess, and one of those > reasons is a careful placement of dependencies. > > Reco Ric didn't say he proposes. He said "I think" which is personal opinion. I think nowdays it is getting a big problem understanding each other and I think it is sad, because we are misinterpreting what the other say which is equivalent to not hearing. regards
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@gmail.com> |
|---|---|
| Date | 2016-10-29 21:00 +0200 |
| Subject | Re: [SOLVED] Re: [jessie] recording line-in using ALSA? |
| Message-ID | <sxH1g-1QO-19@gated-at.bofh.it> |
| In reply to | #173993 |
Hi. On Sat, 29 Oct 2016 19:54:27 +0200 deloptes <deloptes@gmail.com> wrote: > Reco wrote: > > > So basically you're proposing to force the user to install GTK3 (with > > both C and C++ bindinds) just to install pulseaudio. > > > > There are reasons that this distribution is called Debian, not > > You-favorite-enterprisey-tangled-dependency-mess, and one of those > > reasons is a careful placement of dependencies. > > > > Reco > > Ric didn't say he proposes. He said "I think" which is personal opinion. I > think nowdays it is getting a big problem understanding each other and I > think it is sad, because we are misinterpreting what the other say which is > equivalent to not hearing. My apologies to Ric, you and any other maillist participant just in case. Still, I've seen where this road can take a perfectly good package. First example being openjdk-7-jre-headless. After a certain DSA update about a year ago it started to depend on libpulse0 (because reasons, apparently), and boom - a *headless* java install bring about one third of X with it. Kind of depends the whole purpose of package from a certain perspective - as package description explicitly refers 'non GUI Java programs'. Second example being libvirt-daemon-system, introduced in jessie, which started to depend on policykit-1, because (see #768376) from the POV of the maintainer of the package - absolutely nobody (bug report states 95% actually) uses libvirt without virt-manager, and virt-manager breaks somehow without PolicyKit. Oh, and don't get me started on the way they package hplip. So, one must be very careful when wishing for upgrading certain dependencies. PS Is it OK to CC you? My e-mail client insists on it for some reason. Reco
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2016-10-29 21:40 +0200 |
| Subject | Re: [SOLVED] Re: [jessie] recording line-in using ALSA? |
| Message-ID | <sxHDX-2jm-9@gated-at.bofh.it> |
| In reply to | #173995 |
On Sat 29 Oct 2016 at 21:51:48 +0300, Reco wrote: > Hi. > > On Sat, 29 Oct 2016 19:54:27 +0200 > deloptes <deloptes@gmail.com> wrote: > > > Reco wrote: > > > > > So basically you're proposing to force the user to install GTK3 (with > > > both C and C++ bindinds) just to install pulseaudio. > > > > > > There are reasons that this distribution is called Debian, not > > > You-favorite-enterprisey-tangled-dependency-mess, and one of those > > > reasons is a careful placement of dependencies. > > > > > > Reco > > > > Ric didn't say he proposes. He said "I think" which is personal opinion. I > > think nowdays it is getting a big problem understanding each other and I > > think it is sad, because we are misinterpreting what the other say which is > > equivalent to not hearing. > > My apologies to Ric, you and any other maillist participant just in > case. A sentence beginning "I think you should....." is practically equivalent to "I propose you should......". So Ric did propose something. Proposing or thinking is always a personal opinion. You shouldn't have backed down. > Still, I've seen where this road can take a perfectly good package. > > First example being openjdk-7-jre-headless. After a certain DSA update > about a year ago it started to depend on libpulse0 (because reasons, > apparently), and boom - a *headless* java install bring about one third > of X with it. Kind of depends the whole purpose of package from a > certain perspective - as package description explicitly refers 'non GUI > Java programs'. > > Second example being libvirt-daemon-system, introduced in jessie, which > started to depend on policykit-1, because (see #768376) from > the POV of the maintainer of the package - absolutely nobody (bug > report states 95% actually) uses libvirt without virt-manager, and > virt-manager breaks somehow without PolicyKit. > > Oh, and don't get me started on the way they package hplip. Please do. What is wrong with the packaging of hplip? -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | deloptes <deloptes@gmail.com> |
|---|---|
| Date | 2016-10-29 23:10 +0200 |
| Subject | Re: [SOLVED] Re: [jessie] recording line-in using ALSA? |
| Message-ID | <sxJ33-3sa-7@gated-at.bofh.it> |
| In reply to | #173999 |
Brian wrote: > On Sat 29 Oct 2016 at 21:51:48 +0300, Reco wrote: > >> Hi. >> >> On Sat, 29 Oct 2016 19:54:27 +0200 >> deloptes <deloptes@gmail.com> wrote: >> >> > Reco wrote: >> > >> > > So basically you're proposing to force the user to install GTK3 (with >> > > both C and C++ bindinds) just to install pulseaudio. >> > > >> > > There are reasons that this distribution is called Debian, not >> > > You-favorite-enterprisey-tangled-dependency-mess, and one of those >> > > reasons is a careful placement of dependencies. >> > > >> > > Reco >> > >> > Ric didn't say he proposes. He said "I think" which is personal >> > opinion. I think nowdays it is getting a big problem understanding each >> > other and I think it is sad, because we are misinterpreting what the >> > other say which is equivalent to not hearing. >> >> My apologies to Ric, you and any other maillist participant just in >> case. > > A sentence beginning "I think you should....." is practically equivalent > to "I propose you should......". So Ric did propose something. Proposing > or thinking is always a personal opinion. > > You shouldn't have backed down. > Come on Brian, we don't need "wars". Exactly the point is the personal opinion. Ric says "I think it should". Roco takes it as proposal. Perhaps my English is not that good, but I don't take a personal opinion "I think it should" as proposal. In his epistemic world this package is better requireing the other package, but in the real world it just suggest. So lets agree that "suggests" is the better solution for this and that reason and leave it there. >> Still, I've seen where this road can take a perfectly good package. >> >> First example being openjdk-7-jre-headless. After a certain DSA update >> about a year ago it started to depend on libpulse0 (because reasons, >> apparently), and boom - a *headless* java install bring about one third >> of X with it. Kind of depends the whole purpose of package from a >> certain perspective - as package description explicitly refers 'non GUI >> Java programs'. >> >> Second example being libvirt-daemon-system, introduced in jessie, which >> started to depend on policykit-1, because (see #768376) from >> the POV of the maintainer of the package - absolutely nobody (bug >> report states 95% actually) uses libvirt without virt-manager, and >> virt-manager breaks somehow without PolicyKit. >> I completely agree with Reco on all the arguments also from his previous mail. I'm glad that not all "suggestions" are implemented and made available to the public. I also hate it when a simple program pulls in a lot of unrealted and unwanted software, just because some developer did not define dependencies in a proper way. However Reco is better off raising this issue with the maintainers and developers. I have few custom build packages that suite my personal needs. Ah and I froze policy kit because later versions were not providing what I need. So yes I agree with Reco except for the way he put it forward. I think Ric should not propose pulse depending on the graphical frontend. We just have to know that this is available and useful if one has X and some kind of desktop installed. I wish that pavucontrol had various implementations aside gtk, but we all have gtk installed -no? At least because of firefox or some other program. >> Oh, and don't get me started on the way they package hplip. > > Please do. What is wrong with the packaging of hplip? Yes indeed ... but perhaps in another thread. regards
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@gmail.com> |
|---|---|
| Date | 2016-10-29 23:30 +0200 |
| Subject | Re: [OT] Sorry state of hplip (was: [SOLVED] Re: [jessie] recording line-in using ALSA?) |
| Message-ID | <sxJmq-3D9-31@gated-at.bofh.it> |
| In reply to | #173999 |
Hi. On Sat, 29 Oct 2016 20:36:27 +0100 Brian <ad44@cityscape.co.uk> wrote: > On Sat 29 Oct 2016 at 21:51:48 +0300, Reco wrote: > > > Hi. > > > > On Sat, 29 Oct 2016 19:54:27 +0200 > > deloptes <deloptes@gmail.com> wrote: > > > > > Reco wrote: > > > > > > > So basically you're proposing to force the user to install GTK3 (with > > > > both C and C++ bindinds) just to install pulseaudio. > > > > > > > > There are reasons that this distribution is called Debian, not > > > > You-favorite-enterprisey-tangled-dependency-mess, and one of those > > > > reasons is a careful placement of dependencies. > > > > > > > > Reco > > > > > > Ric didn't say he proposes. He said "I think" which is personal opinion. I > > > think nowdays it is getting a big problem understanding each other and I > > > think it is sad, because we are misinterpreting what the other say which is > > > equivalent to not hearing. > > > > My apologies to Ric, you and any other maillist participant just in > > case. > > A sentence beginning "I think you should....." is practically equivalent > to "I propose you should......". So Ric did propose something. Proposing > or thinking is always a personal opinion. > > You shouldn't have backed down. I don't consider an apology (including just-in-case ones) to be a variation of lost argument. I consider an apology as a sign of courtesy, no more, no less. > > Oh, and don't get me started on the way they package hplip. > > Please do. What is wrong with the packaging of hplip? I won't speak of stretch and sid, as these branches of Debian distribution don't interest me in this regard so far. The task itself is simple - one (may be two for the redundancy) centralized print-servers with arbitrary number of clients (without any CUPS or HPLIP). Several HP printers, because they bought the stuff. What's needed? A small amount of packages providing needed CUPS filters, backends and PPDs. The CUPS itself, of course. What do they give us in Debian instead? An enterprisey tangled mess. 'hplip' itself, and it's direct dependencies 'hplip-data' and 'printer-driver-hpcups'. There's also 'hplip-gui' with the bunch of worthless (for the print-server) GUI tools. Oh, and python-qt4 as a dependency and a half of KDE with it as a result, not a small achievement for the package of the size of 88k. Let's continue with 'hplip-data' as its list of dependencies is smaller. For the lazy of us, package description states 'This package contains data files and PPDs for the HP Linux Printing and Imaging System'. Apparently said 'data files' are in fact python scripts put into this package for some bizarre reason, as package brings you python installation immediately. Next, the big winner, 'hplip'. Highlight points include: 1) Python as a dependency, again. Wait, haven't we install one already with 'hplip-data'? Some python modules too, yet the package does not contain a single python script (see pt 6). 2) wget as a dependency. Included for the sole purpose of acquiring non-free blobs from openprining.org by /usr/bin/hp-firmware (see pt 6), yet the package somehow belongs in 'main'. 3) policykit-1 as a dependency. How exactly it's required for the actual printing done by CUPS invoking HPLIP filters (executables /usr/lib/cups/filter/) and backends (executables /usr/lib/cups/backend/)? Hint - it's not. But a certain python script (see pt 6) apparently does. 4) avahi-daemon as Recommends. Apparently it's considered so important that they recommend it again (CUPS has the same Recommend). Kind of surprised not to see it as Depends. 5) Aforementioned backends. Worth mentioning as another part of the puzzle actually related to the printing (filters) resides in 'printer-driver-hpcups' (which is by itself is ok). Apparently because reasons. 6) A bunch of symlinks to assorted python scripts from 'hplip-data', note again that it's 'hplip' that contains all those python script dependencies, not 'hplip-data'. Things have improved somewhat since wheezy (they didn't provide 'printer-driver-hpcups' back then), but it's only 'somewhat'. Reco
[toc] | [prev] | [next] | [standalone]
| From | deloptes <deloptes@gmail.com> |
|---|---|
| Date | 2016-10-29 23:40 +0200 |
| Subject | Re: [OT] Sorry state of hplip (was: [SOLVED] Re: [jessie] recording line-in using ALSA?) |
| Message-ID | <sxJw6-3Ir-33@gated-at.bofh.it> |
| In reply to | #174009 |
Reco wrote: > 1) Python as a dependency, again. Wait, haven't we install one already > with 'hplip-data'? Some python modules too, yet the package does not > contain a single python script (see pt 6). IMO python should be banned from real development. I dislike the new KDE most of all because they relay on python too much. Open source - no any kind of standard ... and this is the fastest way to make something bad out of pretty every idea. Also your other points are really good. Especially KDE dependencies ... you end up installing all kind of unwanted/unnecessary software. I was wondering at some point of time ... are those developers based in Peru, where c***in is legal and they take too much ... unbelievable. Also they got ressistent to any opposite opinion ... much like the so called democrats in the US. I'm just wondering what's going on with the people on this world ... and come to the conclusion that a lot of them are crazy - literally - psychopats, sociopaths and any kind of ***paths. Perhaps I'm getting old, but this can't be the only reason, as others feel/think the same as I do ... so Reco, don't worry - the only way is to patiently push your ideas or find people like you and work together. We can not stop the wave of idiocracy that takes over via face book, twitter and all of the kind unnecessary gossip channels. What I do is trying to make things work for me and perhaps help this way others, which is the basic of open source contributions. I however do not expect that this nonsense will stop. I expect the opposite looking at the 20-30y old. In 10y the mess will be complete. regards
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2016-10-30 15:30 +0100 |
| Subject | Re: [OT] Sorry state of hplip (was: [SOLVED] Re: [jessie] recording line-in using ALSA?) |
| Message-ID | <sxZhw-5Ou-11@gated-at.bofh.it> |
| In reply to | #174009 |
On Sun 30 Oct 2016 at 00:20:43 +0300, Reco wrote: > On Sat, 29 Oct 2016 20:36:27 +0100 > Brian <ad44@cityscape.co.uk> wrote: > > > On Sat 29 Oct 2016 at 21:51:48 +0300, Reco wrote: > > > > > Oh, and don't get me started on the way they package hplip. > > > > Please do. What is wrong with the packaging of hplip? > > I won't speak of stretch and sid, as these branches of Debian > distribution don't interest me in this regard so far. > > The task itself is simple - one (may be two for the redundancy) > centralized print-servers with arbitrary number of clients (without > any CUPS or HPLIP). Several HP printers, because they bought the stuff. > > What's needed? A small amount of packages providing needed CUPS > filters, backends and PPDs. The CUPS itself, of course. printer-driver-hpcups and printer-driver-hpijs would be sufficient for just printing. That is why the packages are provided. > What do they give us in Debian instead? An enterprisey tangled mess. It certainly has complexity. > 'hplip' itself, and it's direct dependencies 'hplip-data' and > 'printer-driver-hpcups'. > > There's also 'hplip-gui' with the bunch of worthless (for the > print-server) GUI tools. Oh, and python-qt4 as a dependency and a half > of KDE with it as a result, not a small achievement for the package of > the size of 88k. Upstream doesn't provide a GTK GUI; the packager doesn't have any option. The package is also optional to install; a user's choice. > Let's continue with 'hplip-data' as its list of dependencies is smaller. > For the lazy of us, package description states 'This package > contains data files and PPDs for the HP Linux Printing and Imaging > System'. Apparently said 'data files' are in fact python scripts put > into this package for some bizarre reason, as package brings you python > installation immediately. The "bizarre reason" reason is probably that the .py and .pyc files are platform independent. I cannot see any PPDs in hplip-data: https://packages.debian.org/jessie/all/hplip-data/filelist Looks like a bug in the package description. > Next, the big winner, 'hplip'. Highlight points include: > > 1) Python as a dependency, again. Wait, haven't we install one already > with 'hplip-data'? Some python modules too, yet the package does not > contain a single python script (see pt 6). See above. > 2) wget as a dependency. Included for the sole purpose of acquiring > non-free blobs from openprining.org by /usr/bin/hp-firmware (see pt 6), > yet the package somehow belongs in 'main'. main's ok. No non-free blobs are packaged. > 3) policykit-1 as a dependency. How exactly it's required for the > actual printing done by CUPS invoking HPLIP filters > (executables /usr/lib/cups/filter/) and backends > (executables /usr/lib/cups/backend/)? > Hint - it's not. But a certain python script (see pt 6) apparently > does. Possibly needed for installing a plugin. > 4) avahi-daemon as Recommends. Apparently it's considered so important > that they recommend it again (CUPS has the same Recommend). Kind of > surprised not to see it as Depends. CUPS was installed without its Recommends: because you do not want to discover Bonjour broadcasted print queues. Later, HPLIP was installed and you want to discover Bonjour broadcasted HP printers. A Depends: would be unsuitable if you were only setting up a USB printer. > 5) Aforementioned backends. Worth mentioning as another part of the > puzzle actually related to the printing (filters) resides in > 'printer-driver-hpcups' (which is by itself is ok). Apparently because > reasons. Sorry; don't follow. > 6) A bunch of symlinks to assorted python scripts from 'hplip-data', > note again that it's 'hplip' that contains all those python script > dependencies, not 'hplip-data'. Platform independence again? > Things have improved somewhat since wheezy (they didn't provide > 'printer-driver-hpcups' back then), but it's only 'somewhat'. It was provided but under a different name. -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@gmail.com> |
|---|---|
| Date | 2016-10-30 16:30 +0100 |
| Subject | Re: [OT] Sorry state of hplip (was: [SOLVED] Re: [jessie] recording line-in using ALSA?) |
| Message-ID | <sy0dz-6nx-11@gated-at.bofh.it> |
| In reply to | #174035 |
Hi. On Sun, 30 Oct 2016 14:20:44 +0000 Brian <ad44@cityscape.co.uk> wrote: > On Sun 30 Oct 2016 at 00:20:43 +0300, Reco wrote: > > > On Sat, 29 Oct 2016 20:36:27 +0100 > > Brian <ad44@cityscape.co.uk> wrote: > > > > > On Sat 29 Oct 2016 at 21:51:48 +0300, Reco wrote: > > > > > > > Oh, and don't get me started on the way they package hplip. > > > > > > Please do. What is wrong with the packaging of hplip? > > > > I won't speak of stretch and sid, as these branches of Debian > > distribution don't interest me in this regard so far. > > > > The task itself is simple - one (may be two for the redundancy) > > centralized print-servers with arbitrary number of clients (without > > any CUPS or HPLIP). Several HP printers, because they bought the stuff. > > > > What's needed? A small amount of packages providing needed CUPS > > filters, backends and PPDs. The CUPS itself, of course. > > printer-driver-hpcups and printer-driver-hpijs would be sufficient for > just printing. That is why the packages are provided. 'Should be' does not equal 'actually working' in this case. > > 'hplip' itself, and it's direct dependencies 'hplip-data' and > > 'printer-driver-hpcups'. > > > > There's also 'hplip-gui' with the bunch of worthless (for the > > print-server) GUI tools. Oh, and python-qt4 as a dependency and a half > > of KDE with it as a result, not a small achievement for the package of > > the size of 88k. > > Upstream doesn't provide a GTK GUI; the packager doesn't have any > option. The package is also optional to install; a user's choice. You're missing the point. What's the reason to provide a GUI to a bunch of CUPS filters in the first place? Why such GUI is needed for these particular filters, but not CUPS itself? > > Let's continue with 'hplip-data' as its list of dependencies is smaller. > > For the lazy of us, package description states 'This package > > contains data files and PPDs for the HP Linux Printing and Imaging > > System'. Apparently said 'data files' are in fact python scripts put > > into this package for some bizarre reason, as package brings you python > > installation immediately. > > The "bizarre reason" reason is probably that the .py and .pyc files are > platform independent. And the reason to put all those unrelated to actual printing files into the package was? > > Next, the big winner, 'hplip'. Highlight points include: > > > > 1) Python as a dependency, again. Wait, haven't we install one already > > with 'hplip-data'? Some python modules too, yet the package does not > > contain a single python script (see pt 6). > > See above. Nope, does not cut it. A package does not provide anything written in python by itself. Why does it depends on python then? > > 2) wget as a dependency. Included for the sole purpose of acquiring > > non-free blobs from openprining.org by /usr/bin/hp-firmware (see pt 6), > > yet the package somehow belongs in 'main'. > > main's ok. No non-free blobs are packaged. b43-fwcutter, flashplugin-nonfree or ttf-mscorefonts-installer (to name a few) do not package blobs either, they *only* download and/or process them. Yet all such things reside in 'contrib', not 'main'. > > 3) policykit-1 as a dependency. How exactly it's required for the > > actual printing done by CUPS invoking HPLIP filters > > (executables /usr/lib/cups/filter/) and backends > > (executables /usr/lib/cups/backend/)? > > Hint - it's not. But a certain python script (see pt 6) apparently > > does. > > Possibly needed for installing a plugin. A 'plugin' to what? Did you mean a 'non-free' blob maybe? Does this 'plugin' gets installed every time someone prints? > > 4) avahi-daemon as Recommends. Apparently it's considered so important > > that they recommend it again (CUPS has the same Recommend). Kind of > > surprised not to see it as Depends. > > CUPS was installed without its Recommends: because you do not want to > discover Bonjour broadcasted print queues. Later, HPLIP was installed > and you want to discover Bonjour broadcasted HP printers. A weak argument as no other printer driver has this ridiculous Recommends. One for the CUPS (where it serves its purpose indeed) is enough. It would be a valid argument *if* one could install HPLIP without CUPS, but currently 'hplip' depends on 'cups', so that's impossible. > A Depends: > would be unsuitable if you were only setting up a USB printer. First, that logic did not stop them from forcing one to install a PolicyKit, for instance. Second, said USB printer can be shared over the network by CUPS, so such dependency is actually justifiable. > > 5) Aforementioned backends. Worth mentioning as another part of the > > puzzle actually related to the printing (filters) resides in > > 'printer-driver-hpcups' (which is by itself is ok). Apparently because > > reasons. > > Sorry; don't follow. What's the reason that two actually useful package parts ended up in two separate packages, and one of them provides 'everything and a kitchen sink'? > > 6) A bunch of symlinks to assorted python scripts from 'hplip-data', > > note again that it's 'hplip' that contains all those python script > > dependencies, not 'hplip-data'. > > Platform independence again? There's package that provides a bunch of python scrips, yet the package depends on python only. That's 'hplip-data'. There's package, that provides symlinks, yet the package depends on python and a load of python modules. That's 'hplip'. Are you still not seeing anything wrong here? So, let me reiterate. HP provides a couple of useful files (backends, filters), lcl and ldl 'sources' (generating PPDs in runtime has never been more fun!), bundled with all kinds of python scripts, which usage is situational at best. Why? Because enterprisey. What Debian does? Instead of splitting useful parts into one package, and useless ones into another - they give us the same mess HP provides. Reco
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2016-10-30 18:20 +0100 |
| Subject | Re: [OT] Sorry state of hplip (was: [SOLVED] Re: [jessie] recording line-in using ALSA?) |
| Message-ID | <sy1W2-7xW-9@gated-at.bofh.it> |
| In reply to | #174038 |
On Sun 30 Oct 2016 at 18:24:50 +0300, Reco wrote: > Hi. > > On Sun, 30 Oct 2016 14:20:44 +0000 > Brian <ad44@cityscape.co.uk> wrote: > > > > printer-driver-hpcups and printer-driver-hpijs would be sufficient for > > just printing. That is why the packages are provided. > > 'Should be' does not equal 'actually working' in this case. If you have a problem you should seek help by starting another thread. > You're missing the point. What's the reason to provide a GUI to a bunch > of CUPS filters in the first place? Why such GUI is needed for these > particular filters, but not CUPS itself? People like GUIs; I believe system-config-printer and the CUPS web interface are popular for setting up printers. None of them are needed but they fulfill a need. > > The "bizarre reason" reason is probably that the .py and .pyc files are > > platform independent. > > And the reason to put all those unrelated to actual printing files into > the package was? HPLIP does a bit more than handle printing. > > See above. > > Nope, does not cut it. A package does not provide anything written in > python by itself. Why does it depends on python then? Pass. > > main's ok. No non-free blobs are packaged. > > b43-fwcutter, flashplugin-nonfree or ttf-mscorefonts-installer (to name > a few) do not package blobs either, they *only* download and/or > process them. Yet all such things reside in 'contrib', not 'main'. I'm not getting into a comparison with every package of this nature in contrib. hp-plugin is not central to the function of suported hardware and HPLIP will work without it. The script is a convenience one for the user and is not run from the maintainer scripts. > > Possibly needed for installing a plugin. > > A 'plugin' to what? Did you mean a 'non-free' blob maybe? I was using HPs terminology. > Does this 'plugin' gets installed every time someone prints? No. > > > 4) avahi-daemon as Recommends. Apparently it's considered so important > > > that they recommend it again (CUPS has the same Recommend). Kind of > > > surprised not to see it as Depends. > > > > CUPS was installed without its Recommends: because you do not want to > > discover Bonjour broadcasted print queues. Later, HPLIP was installed > > and you want to discover Bonjour broadcasted HP printers. > > A weak argument as no other printer driver has this ridiculous > Recommends. One for the CUPS (where it serves its purpose indeed) is > enough. It's actually a very sound argument. Not wanting any of cups recommended packages is a respectable decision. > It would be a valid argument *if* one could install HPLIP without CUPS, > but currently 'hplip' depends on 'cups', so that's impossible. True. But I think you do not understand what different purposes cups and HPLIP use avahi-daemon for. I didn't use "print queues" and "printers" as a matter of style. > > A Depends: > > would be unsuitable if you were only setting up a USB printer. > > First, that logic did not stop them from forcing one to install a > PolicyKit, for instance. > Second, said USB printer can be shared over the network by CUPS, so > such dependency is actually justifiable. Setting up a *non-shared* USB printer. Clearer? Pass on the rest because packaging is not something I know much about, so I'm most likely to rely on the expertise of the maintainers. The changelog might give you some clue as to what is going on. -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@gmail.com> |
|---|---|
| Date | 2016-10-31 15:20 +0100 |
| Subject | Re: [OT] Sorry state of hplip (was: [SOLVED] Re: [jessie] recording line-in using ALSA?) |
| Message-ID | <sylBn-3xx-15@gated-at.bofh.it> |
| In reply to | #174052 |
Hi. On Sun, Oct 30, 2016 at 05:15:51PM +0000, Brian wrote: > On Sun 30 Oct 2016 at 18:24:50 +0300, Reco wrote: > > > Hi. > > > > On Sun, 30 Oct 2016 14:20:44 +0000 > > Brian <ad44@cityscape.co.uk> wrote: > > > > > > printer-driver-hpcups and printer-driver-hpijs would be sufficient for > > > just printing. That is why the packages are provided. > > > > 'Should be' does not equal 'actually working' in this case. > > If you have a problem you should seek help by starting another thread. It works the way I've described, so why should I seek any help? > > You're missing the point. What's the reason to provide a GUI to a bunch > > of CUPS filters in the first place? Why such GUI is needed for these > > particular filters, but not CUPS itself? > > People like GUIs; I believe system-config-printer and the CUPS web > interface are popular for setting up printers. None of them are needed > but they fulfill a need. Please do not dodge the question. Why such GUI is needed for these particular filters? > > > The "bizarre reason" reason is probably that the .py and .pyc files are > > > platform independent. > > > > And the reason to put all those unrelated to actual printing files into > > the package was? > > HPLIP does a bit more than handle printing. And the reason to force this 'a bit more than printing' on all users was? > > > See above. > > > > Nope, does not cut it. A package does not provide anything written in > > python by itself. Why does it depends on python then? > > Pass. Can you agree that it's a bit unusual? > > > main's ok. No non-free blobs are packaged. > > > > b43-fwcutter, flashplugin-nonfree or ttf-mscorefonts-installer (to name > > a few) do not package blobs either, they *only* download and/or > > process them. Yet all such things reside in 'contrib', not 'main'. > > I'm not getting into a comparison with every package of this nature in > contrib. Was not my intention. > hp-plugin is not central to the function of suported hardware > and HPLIP will work without it. Yet the only function of the script is to provide user non-DFSG compliant files. > The script is a convenience one for the > user and is not run from the maintainer scripts. Other convenience scripts of similar nature get their own packages and put into 'contrib'. > > > Possibly needed for installing a plugin. > > > > A 'plugin' to what? Did you mean a 'non-free' blob maybe? > > I was using HPs terminology. > > > Does this 'plugin' gets installed every time someone prints? > > No. Yet another reason to split it into a different package, don't you agree? > > > > 4) avahi-daemon as Recommends. Apparently it's considered so important > > > > that they recommend it again (CUPS has the same Recommend). Kind of > > > > surprised not to see it as Depends. > > > > > > CUPS was installed without its Recommends: because you do not want to > > > discover Bonjour broadcasted print queues. Later, HPLIP was installed > > > and you want to discover Bonjour broadcasted HP printers. > > > > A weak argument as no other printer driver has this ridiculous > > Recommends. One for the CUPS (where it serves its purpose indeed) is > > enough. > > It's actually a very sound argument. Not wanting any of cups recommended > packages is a respectable decision. ... and suddenly, by installing hplip, the user finally comes to their senses, sees the light and installs avahi-daemon like it was intended from the beginning. You're describing an artificial scenario. > > It would be a valid argument *if* one could install HPLIP without CUPS, > > but currently 'hplip' depends on 'cups', so that's impossible. > > True. But I think you do not understand what different purposes cups and > HPLIP use avahi-daemon for. I didn't use "print queues" and "printers" > as a matter of style. Enlighten me, please. For what purpose HPLIP's backends use avahi-daemon? Or maybe all those python scripts that are provided by HPLIP? > > > A Depends: > > > would be unsuitable if you were only setting up a USB printer. > > > > First, that logic did not stop them from forcing one to install a > > PolicyKit, for instance. > > Second, said USB printer can be shared over the network by CUPS, so > > such dependency is actually justifiable. > > Setting up a *non-shared* USB printer. Clearer? Did I mention in my reply that your example was unclear somehow? Why these childish appempts to offend me? > Pass on the rest because packaging is not something I know much about, > so I'm most likely to rely on the expertise of the maintainers. The > changelog might give you some clue as to what is going on. You could save us both time by providing this magical 'rely on the expertise of the maintainers' advice from the beginning. Reco
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2016-10-31 16:20 +0100 |
| Subject | Re: [OT] Sorry state of hplip (was: [SOLVED] Re: [jessie] recording line-in using ALSA?) |
| Message-ID | <symxs-47I-13@gated-at.bofh.it> |
| In reply to | #174080 |
On Mon 31 Oct 2016 at 17:11:34 +0300, Reco wrote: > On Sun, Oct 30, 2016 at 05:15:51PM +0000, Brian wrote: > > > Pass on the rest because packaging is not something I know much about, > > so I'm most likely to rely on the expertise of the maintainers. The > > changelog might give you some clue as to what is going on. > > You could save us both time by providing this magical 'rely on the > expertise of the maintainers' advice from the beginning. It is obvious you think there are many, many things wrong with the packaging of HPLIP and we are not getting very far with a solution by bouncing ideas off one another. If I felt as strongly about a package as you do (and knew something about the subject) I would likely initiate bug reports to attempt to improve the situation for all users. I think I'm done here. -- Brian.
[toc] | [prev] | [next] | [standalone]
Page 1 of 2 [1] 2 Next page →
Back to top | Article view | linux.debian.user
csiph-web