Re: [OT] Sorry state of hplip (was: [SOLVED] Re: [jessie] recording line-in using ALSA?)

[Brian]

On Mon 31 Oct 2016 at 15:44:37 +, Jonathan Dowland wrote:

> On Mon, Oct 31, 2016 at 05:11:34PM +0300, Reco wrote:
> > Other convenience scripts of similar nature get their own packages and
> > put into 'contrib'.
> 
> The ones you have mentioned already (b43-fwcutter, flashplugin-nonfree and
> ttf-mscorefonts-installer) do nothing useful without additional, non-free
> bits, which is why they are in contrib. E.g. flashplugin-nonfree is useless
> without the non-free flash bits it downloads. It sounds like hp-plugin in
> isolation is similar, and would fit the bill for contrib; however, if a
> hypothetical separate hp-plugin package would depend on the hplip package
> which it is carried in now, then it's reasonably pragmatic for the hplip
> package to just carry the script, since the majority of functionality
> offered by the hplip package still does not require the non-free bits.

This is the crux of the matter. The *sole* reason for the existence of
43-fwcutter, flashplugin-nonfree and ttf-mscorefonts-installer is to
download non-free blobs/software. That is why they are in contrib.

HPLIP does not exist for the *sole* purpose of downloading non-free
items. hp-plugin is a convenience script for users. We would be doing
them and Debian a great disservice by removing it from the package.

In case you think we have not been here before there is #449497. In that
case the Release Team and the Technical Committee came down on the side
of the maintainer. Anyone who wants to chance their arm with this today
has precedent to overcome.

> On the other hand, if that script is the sole reason for the Python
> dependencies, then it would be a service to other users to split out that
> script for that reason. The place to start would be checking for, and if
> necessary filing, a wishlist bug.

The script is not the sole reason for the Python dependencies.

> There is a cost involved in having lots of small packages, that we all pay in
> terms of the size of the distribution Packages list, and the additional
> complexity of managing the source packages for developers and the bugs that
> would result.

That is another good reason. hp-plugin is free. HPLIP is free; no
non-free stuff is included in it. What a users do is up to them.

-- 
Brian.

Re: [OT] Sorry state of hplip (was: [SOLVED] Re: [jessie] recording line-in using ALSA?)

[Jonathan Dowland]

On Mon, Oct 31, 2016 at 05:11:34PM +0300, Reco wrote:
> Other convenience scripts of similar nature get their own packages and
> put into 'contrib'.

The ones you have mentioned already (b43-fwcutter, flashplugin-nonfree and
ttf-mscorefonts-installer) do nothing useful without additional, non-free
bits, which is why they are in contrib. E.g. flashplugin-nonfree is useless
without the non-free flash bits it downloads. It sounds like hp-plugin in
isolation is similar, and would fit the bill for contrib; however, if a
hypothetical separate hp-plugin package would depend on the hplip package
which it is carried in now, then it's reasonably pragmatic for the hplip
package to just carry the script, since the majority of functionality
offered by the hplip package still does not require the non-free bits.

On the other hand, if that script is the sole reason for the Python
dependencies, then it would be a service to other users to split out that
script for that reason. The place to start would be checking for, and if
necessary filing, a wishlist bug.

There is a cost involved in having lots of small packages, that we all pay in
terms of the size of the distribution Packages list, and the additional
complexity of managing the source packages for developers and the bugs that
would result.

-- 
Jonathan Dowland
Please do not CC me, I am subscribed to the list.


signature.asc
Description: Digital signature

Re: [OT] Sorry state of hplip (was: [SOLVED] Re: [jessie] recording line-in using ALSA?)

[Brian]

On Mon 31 Oct 2016 at 17:11:34 +0300, Reco wrote:

> On Sun, Oct 30, 2016 at 05:15:51PM +, 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.

Re: [OT] Sorry state of hplip (was: [SOLVED] Re: [jessie] recording line-in using ALSA?)

[Reco]

Hi.

On Sun, Oct 30, 2016 at 05:15:51PM +, Brian wrote:
> On Sun 30 Oct 2016 at 18:24:50 +0300, Reco wrote:
> 
> > Hi.
> > 
> > On Sun, 30 Oct 2016 14:20:44 +
> > Brian  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

Re: [OT] Sorry state of hplip (was: [SOLVED] Re: [jessie] recording line-in using ALSA?)

[Reco]

Hi.

On Sun, Oct 30, 2016 at 07:58:19PM +0100, deloptes wrote:
> IMO hplip also supports multifunction devices.

Yup. Happen to have one of those.


> If you want to use HP device only for printing ... non of this is required.

And if I do want to use an HP device for scanning I need libsane-hpaio,
SANE itself and a hueg pile of none-free blobs. First two are provided by
Debian, last one by openprinting.org.

What I do not need for scanning is hplip (as in - Debian package of that
name). Simply because there's nothing that does actual scanning in that
package.

I haven't try to use the thing as a fax (manual states it's possible),
so maybe I need 'hplip' for that. I have my doubts on this though.


> If you want to do a scanning etc it is understandable that a kind of gui has
> to be provided.

Stock xsane or any other sane-based application or even GIMP should fill
the role. But I agree that there may be someone that actually uses all
this stuff in 'hplip' for scanning. Yet another reason to split it in a
different package.


> It is funny to read your arguments while you are sliding into the Ric's "I
> think it should" way.

Nobody's perfect (no offence meant to Ric), certainly not me.

Reco

Re: [OT] Sorry state of hplip (was: [SOLVED] Re: [jessie] recording line-in using ALSA?)

[Brian]

On Sun 30 Oct 2016 at 19:58:19 +0100, deloptes wrote:

> IMO hplip also supports multifunction devices.

Correct.

> If you want to use HP device only for printing ... non of this is required.

Correct. It can, however, depend on which backend you want to send data
to the printer if you are fussy.

> If you want to do a scanning etc it is understandable that a kind of gui has
> to be provided.

There is no problem with scanning to an aio without HPLIP. It depends
on how you go about it. The packaging has been devised to accomodate
this (but it appears to be a source for complaint).

-- 
Brian.

Re: [OT] Sorry state of hplip (was: [SOLVED] Re: [jessie] recording line-in using ALSA?)

[deloptes]

IMO hplip also supports multifunction devices.
If you want to use HP device only for printing ... non of this is required.
If you want to do a scanning etc it is understandable that a kind of gui has
to be provided.

It is funny to read your arguments while you are sliding into the Ric's "I
think it should" way.

regards

Re: [OT] Sorry state of hplip (was: [SOLVED] Re: [jessie] recording line-in using ALSA?)

[Brian]

On Sun 30 Oct 2016 at 18:24:50 +0300, Reco wrote:

>   Hi.
> 
> On Sun, 30 Oct 2016 14:20:44 +
> Brian  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.

Re: [OT] Sorry state of hplip (was: [SOLVED] Re: [jessie] recording line-in using ALSA?)

[Reco]

Hi.

On Sun, 30 Oct 2016 14:20:44 +
Brian  wrote:

> On Sun 30 Oct 2016 at 00:20:43 +0300, Reco wrote:
> 
> > On Sat, 29 Oct 2016 20:36:27 +0100
> > Brian  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 

Re: [OT] Sorry state of hplip (was: [SOLVED] Re: [jessie] recording line-in using ALSA?)

[Brian]

On Sun 30 Oct 2016 at 00:20:43 +0300, Reco wrote:

> On Sat, 29 Oct 2016 20:36:27 +0100
> Brian  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.

Re: [OT] Sorry state of hplip (was: [SOLVED] Re: [jessie] recording line-in using ALSA?)

[deloptes]

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

Re: [OT] Sorry state of hplip (was: [SOLVED] Re: [jessie] recording line-in using ALSA?)

[Reco]

Hi.

On Sat, 29 Oct 2016 20:36:27 +0100
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  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

Re: [SOLVED] Re: [jessie] recording line-in using ALSA?

[deloptes]

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  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

Re: [SOLVED] Re: [jessie] recording line-in using ALSA?

[Brian]

On Sat 29 Oct 2016 at 21:51:48 +0300, Reco wrote:

>   Hi.
> 
> On Sat, 29 Oct 2016 19:54:27 +0200
> deloptes  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. 

Re: [SOLVED] Re: [jessie] recording line-in using ALSA?

[Reco]

Hi.

On Sat, 29 Oct 2016 19:54:27 +0200
deloptes  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

Re: [SOLVED] Re: [jessie] recording line-in using ALSA?

[deloptes]

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

Re: [SOLVED] Re: [jessie] recording line-in using ALSA?

[Reco]

Hi.

On Sat, 29 Oct 2016 12:34:44 -0400
Ric Moore  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

Re: [SOLVED] Re: [jessie] recording line-in using ALSA?

[Ric Moore]

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

Re: [SOLVED] Re: [jessie] recording line-in using ALSA?

[deloptes]

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

Re: [SOLVED] Re: [jessie] recording line-in using ALSA?

[Ric Moore]

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

[SOLVED] Re: [jessie] recording line-in using ALSA?

[D. R. Evans]

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



signature.asc
Description: OpenPGP digital signature