Content-Type: text/plain
debian-user-digest Digest Volume 2022 : Issue 675
Today's Topics:
Re: Raising volume past 100% [ David Griffith <dave@661.org> ]
Re: Why are some Debian bugs ignored [ piorunz <piorunz@gmx.com> ]
Re: Raising volume past 100% [ Cindy Sue Causey <butterflybytes@gm ]
Re: Why are some Debian bugs ignored [ Chuck Zmudzinski <brchuckz@netscape ]
Re: Why are some Debian bugs ignored [ Chuck Zmudzinski <brchuckz@netscape ]
Re: Why are some Debian bugs ignored [ Andy Smith <andy@strugglers.net> ]
must i consider zfs or lvm for smr l [ Samuel Wales <samologist@gmail.com> ]
Re: Why are some Debian bugs ignored [ Chuck Zmudzinski <brchuckz@netscape ]
Date: Fri, 19 Aug 2022 20:24:13 +0000 (UTC)
From: David Griffith <dave@661.org>
To: Bret Busby <bret@busby.net>
cc: debian-user@lists.debian.org
Subject: Re: Raising volume past 100%
Message-ID: <[🔎] b6248c6c-4b86-a0e4-8b93-5a58af5a61ab@661.org" target="_blank" rel="noreferrer">[🔎] b6248c6c-4b86-a0e4-8b93-5a58af5a61ab@661.org>
Content-Type: multipart/mixed; BOUNDARY="1371591299-517002983-1660940421=:10482"
Content-ID: <3e2eb516-8f9-dcbe-1d69-2a68efca4c7a@661.org>
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--1371591299-517002983-1660940421=:10482
Content-Type: text/plain; CHARSET=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8BIT
Content-ID: <5ea6d2d-133-b823-c9d1-badfcc3203b@661.org>
On Fri, 19 Aug 2022, Bret Busby wrote:
> On 19/8/22 03:04, David Griffith wrote:
>>
>> On Fri, 19 Aug 2022, Bret Busby wrote:
>>> On 19/8/22 01:32, David Griffith wrote:
>>>>
>>>> My reply is at the bottom. Please put your reply there too.
>>>> On Thu, 18 Aug 2022, Bret Busby wrote:
>>>>> On 18/8/22 16:15, David Griffith wrote:
>>>>>>
>>>>>> There is the continuing problem of built-in speakers on laptops being
>>>>>> too quiet when running Linux. I managed to fix this with something in
>>>>>> /etc/asound.conf and an extra mate-volume-control applet added to the
>>>>>> panel. With this extra volume control, I was able to turn the audio
>>>>>> far past 100% and even past 153%. The laptop I'm working on needed to
>>>>>> be wiped and the OS reinstalled. Unfortunately I neglected to save or
>>>>>> write down what I did to implement this volume control tweak.
>>>>>>
>>>>>> Before I discovered this, I used /etc/asound.conf (or ~/.asoundrc) to
>>>>>> add a "Pre-Amp" slider to Alsa. This raises up the low end such that
>>>>>> the really quiet audio stuff is loud enough. I'm not sure if that had
>>>>>> anything to do with the volume control tweak.
>>>>>>
>>>>>> Would someone please help me with figuring out what I could have
>>>>>> possibly done to make MATE's audio control applet to go as far past
>>>>>> 100% as I cared to raise it?
>>>>>
>>>>> Do you have access to the MATE Control Center, through the applications
>>>>> menu?
>>>>>
>>>>> If so, in there, is the Hardware -> Sound settings configurator
>>>>>
>>>>> Also, in System -> Preferences -> Hardware -> Sound
>>>>>
>>>>> Whilst this is on a UbuntuMATE system, I expect that you should, if you
>>>>> are using the MATE desktop environment, have access the same way, to the
>>>>> same functionalities.
>>>>
>>>> I'm on a regular Debian system. What you pointed me to is the same thing
>>>> that I get if I right-click on the volume control applet and select
>>>> "sound preferences". I'm not clear on what I'm supposed to see there as
>>>> it has no visible options to raise the maximum volume.
>>>
>>> 1. As a person whom strictly bottom posts as a rule, and, as this was
>>> clearly shown in the message above, your comment at the top of the
>>> message, is not appreciated.
>>
>> Sorry. That tag has been part of my reply header for some time. I'll
>> reword it.
>>
>>> 2. See attachment. The slider goes past 100%, which, from your wording in
>>> your request, is what I understand that you seek.
>>
>> What I seek is 1) the ability to hover the mouse pointer over the volume
>> applet and raise the volume past 100% using the mouse wheel and 2) the
>> ability to click on the volume applet and use the slider that appears to
>> raise the volume past 100%. I already know how to bring up a dialog to do
>> this. I was able to do #1 before an untimely wipe and reinstall and am
>> having trouble figuring out just what I did.
>
> What is wrong with simply bringing up the Sound preferences window, and
> clicking on the position of the marker on the slider, and dragging it to the
> position wanted?
>
> Your original query did not specify that you wanted instead, to be using a
> mouseover and the mouse wheel, instead of the buttons on the mouse.
I don't want to go through multiple clicks and the open/close of a dialog
box. Sometimes I get files/streams that are so quiet that even the max
provided by that method of 153% is not enough. I don't want a dialog
popping over what I'm doing. I was previously able to do exactly what I
wanted, so I know that it's possible. Also, I have come across repeated
requests on how to do what I'm trying to rediscover, so I'd like to get
the answer put out there for them.
--
David Griffith
dave@661.org
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
--1371591299-517002983-1660940421=:10482--
Date: Fri, 19 Aug 2022 21:44:57 +0100
From: piorunz <piorunz@gmx.com>
To: debian-user@lists.debian.org
Subject: Re: Why are some Debian bugs ignored for a long time?
Message-ID: <[🔎] 1d7aa7b3-0791-11cf-2a12-f83a5398cb0f@gmx.com" target="_blank" rel="noreferrer">[🔎] 1d7aa7b3-0791-11cf-2a12-f83a5398cb0f@gmx.com>
Content-Language: en-GB
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
On 19/08/2022 18:57, Chuck Zmudzinski wrote:
> I have noticed that some Debian bugs are ignored for a long time, someti=
mes even when the person who submitted the bug offered a patch. The Debian=
developers/maintainers sometimes don't even reply and therefore never exp=
lain why the proposed patch cannot be applied. Why is that the case with D=
ebian developers/maintainers?
Hi Chuck,
Maybe because developers/maintainers are not paid by the hour, but mere
volunteers, don't you think?
=2D-
With kindest regards, Piotr.
=E2=A2=80=E2=A3=B4=E2=A0=BE=E2=A0=BB=E2=A2=B6=E2=A3=A6=E2=A0=80
=E2=A3=BE=E2=A0=81=E2=A2=A0=E2=A0=92=E2=A0=80=E2=A3=BF=E2=A1=81 Debian - T=
he universal operating system
=E2=A2=BF=E2=A1=84=E2=A0=98=E2=A0=B7=E2=A0=9A=E2=A0=8B=E2=A0=80 https://ww=
w.debian.org/
=E2=A0=88=E2=A0=B3=E2=A3=84=E2=A0=80=E2=A0=80=E2=A0=80=E2=A0=80
Date: Fri, 19 Aug 2022 17:00:39 -0400
From: Cindy Sue Causey <butterflybytes@gmail.com>
To: Debian Users <debian-user@lists.debian.org>
Subject: Re: Raising volume past 100%
Message-ID: <[🔎] CAO1P-kDRHsS9vm7WautvtSpL4ea97o+81uu2hSh5u1bWhJqs_w@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
On 8/19/22, David Griffith <dave@661.org> wrote:
>
> I don't want to go through multiple clicks and the open/close of a dialog
> box. Sometimes I get files/streams that are so quiet that even the max
> provided by that method of 153% is not enough. I don't want a dialog
> popping over what I'm doing. I was previously able to do exactly what I
> wanted, so I know that it's possible. Also, I have come across repeated
> requests on how to do what I'm trying to rediscover, so I'd like to get
> the answer put out there for them.
Hi.. This thread caught my eye because I'd been having trouble for a
couple weeks. Have you always had this trouble, or is this something
that just started happening in the last few weeks?
Am asking because I started having a problem. I just assumed "Not
Gonna Take It Anymore" blew out the speakers on my newest secondhand
laptop. Might still be what happened, but it's that part about how low
it is that makes me wonder.
Mine's so low, I have to lean completely against the laptop to hear
anything. Again, it's likely the hardware, but it's sure a funny
coincidence to see that very thing stated on here, too.
pavucontrol is my weapon of choice to get anything resembling sound.
Didn't used to work for me. Had been using aumix for years then it
stopped working. Now pavucontrol(-qt) works mostly dependably,
although I have to log out and back in a couple times a week when it
doesn't make its connection(s) for currently unknown reasons.
Cindy :)
--
Talking Rock, Pickens County, Georgia, USA
* runs with birdseed *
Date: Fri, 19 Aug 2022 17:06:38 -0400
From: Chuck Zmudzinski <brchuckz@netscape.net>
To: debian-user@lists.debian.org
Subject: Re: Why are some Debian bugs ignored for a long time?
Message-ID: <[🔎] cd457fbe-cfd4-4ee2-5655-9e46d6ecebf8@netscape.net" target="_blank" rel="noreferrer">[🔎] cd457fbe-cfd4-4ee2-5655-9e46d6ecebf8@netscape.net>
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
On 8/19/2022 4:44 PM, piorunz wrote:
> On 19/08/2022 18:57, Chuck Zmudzinski wrote:
>
> > I have noticed that some Debian bugs are ignored for a long time, sometimes even when the person who submitted the bug offered a patch. The Debian developers/maintainers sometimes don't even reply and therefore never explain why the proposed patch cannot be applied. Why is that the case with Debian developers/maintainers?
>
> Hi Chuck,
>
> Maybe because developers/maintainers are not paid by the hour, but mere
> volunteers, don't you think?
So that means "free" software written and maintained by volunteers will never be as
stable and secure as software that is written by people who are paid by the hour. That is,
Debian software can *never* be as stable and secure as software that is written and
maintained by people who are paid by the hour. Not only that, you are saying if a Debian
user experiences a bug in Debian software, Debian developers/maintainers do not have
to fix it. That's fine, but...
If Debian developers/maintainers actively refuse to fix some bugs that inevitably arise
by ignoring them, why would anyone depend on Debian software for anything important?
Best regards,
Chuck
Date: Fri, 19 Aug 2022 18:54:07 -0400
From: Chuck Zmudzinski <brchuckz@netscape.net>
To: debian-user@lists.debian.org
Subject: Re: Why are some Debian bugs ignored for a long time?
Message-ID: <[🔎] 516ef004-8f6f-d790-e316-c1c85595dbd4@netscape.net" target="_blank" rel="noreferrer">[🔎] 516ef004-8f6f-d790-e316-c1c85595dbd4@netscape.net>
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
On 8/19/2022 6:43 PM, Timothy M Butterworth wrote:
>
>
> On Fri, Aug 19, 2022 at 6:40 PM Chuck Zmudzinski <brchuckz@netscape.net> wrote:
>
> On 8/19/2022 6:20 PM, Timothy M Butterworth wrote:
> >
> >
> > On Fri, Aug 19, 2022 at 5:07 PM Chuck Zmudzinski <brchuckz@netscape.net> wrote:
> >
> > On 8/19/2022 4:44 PM, piorunz wrote:
> > > On 19/08/2022 18:57, Chuck Zmudzinski wrote:
> > >
> > > > I have noticed that some Debian bugs are ignored for a long time, sometimes even when the person who submitted the bug offered a patch. The Debian developers/maintainers sometimes don't even reply and therefore never explain why the proposed patch cannot be applied. Why is that the case with Debian developers/maintainers?
> > >
> > > Hi Chuck,
> > >
> > > Maybe because developers/maintainers are not paid by the hour, but mere
> > > volunteers, don't you think?
> >
> > Debian Stable usually only ships security and stability patches.
> >
> >
> > So that means "free" software written and maintained by volunteers will never be as
> > stable and secure as software that is written by people who are paid by the hour.
> >
> > Freexian has developers that are paid by the hour to work on Debian, anyone who wants with cash to spare can purchase some hours to have work done on packages of their choosing.
> >
> > * 2 hours pack: 240 EUR + VAT (120 EUR/hour)
> > * 5 hours pack: 600 EUR + VAT (120 EUR/hour)
> > * 10 hours pack: 1150 EUR + VAT (115 EUR/hour)
> > * 20 hours pack: 2300 EUR + VAT (115 EUR/hour)
> > * 50 hours pack: 5500 EUR + VAT (110 EUR/hour)
> >
>
> That's good to know. Thanks. Presumably the work they do would be contributed back
> to Debian for the benefit of all. I am curious if they would be able to help in a case when
> a bug with a known fix has been ignored for a long time. I would prefer that Debian would
> just fix the bug instead of having to pay someone to tell Debian they should fix the bug.
>
> I could also just migrate to Fedora since their distro does not have the bug and I wouldn't
> have to pay anyone for my system to work using Fedora.
>
> Distro hopping is one of the best things about Linux, I personally switch between Debian, openSUSE and Fedora. One day I want to roll my own distro. I am planning on making a stripped down debian focusing on KDE Plasma and KDE Apps. One DE one hardware platform.
Yes, the many distros is a nice thing about Linux, and now it looks like it is time for
me to start hopping from Debian to other distros when necessary.
Sorry, I forgot to reply-to the list, so I am bringing the discussion back to the list.
Thanks,
Chuck
>
>
> Best regards,
>
> Chuck
> >
> >
> >
> >
> > --
> > ⢀⣴⠾⠻⢶⣦⠀
> > ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
> > ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
> > ⠈⠳⣄⠀⠀
>
>
>
> --
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
> ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
> ⠈⠳⣄⠀⠀
Date: Fri, 19 Aug 2022 22:59:17 +0000
From: Andy Smith <andy@strugglers.net>
To: debian-user@lists.debian.org
Subject: Re: Why are some Debian bugs ignored for a long time?
Message-ID: <[🔎] 20220819225917.joip5c5uw634aos4@bitfolk.com" target="_blank" rel="noreferrer">[🔎] 20220819225917.joip5c5uw634aos4@bitfolk.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Hello,
On Fri, Aug 19, 2022 at 05:06:38PM -0400, Chuck Zmudzinski wrote:
> On 8/19/2022 4:44 PM, piorunz wrote:
> > On 19/08/2022 18:57, Chuck Zmudzinski wrote:
> > > I have noticed that some Debian bugs are ignored for a long time, sometimes even when the person who submitted the bug offered a patch. The Debian developers/maintainers sometimes don't even reply and therefore never explain why the proposed patch cannot be applied. Why is that the case with Debian developers/maintainers?
> >
> > Hi Chuck,
> >
> > Maybe because developers/maintainers are not paid by the hour, but mere
> > volunteers, don't you think?
>
> So that means "free" software written and maintained by volunteers will never be as
> stable and secure as software that is written by people who are paid by the hour.
This is an assertion of your own that does not automatically follow
from what piorunz wrote.
> That is, Debian software can *never* be as stable and secure as
> software that is written and maintained by people who are paid by
> the hour.
This is also an assertion of your own that does not automatically
follow from what piorunz wrote.
> you are saying if a Debian user experiences a bug in Debian
> software, Debian developers/maintainers do not have to fix it.
That is a direct consequence of the meaning of the term "volunteer";
you may as well have said, "water is wet". Volunteers cannot be
forced to do work, else they are not volunteers.
> If Debian developers/maintainers actively refuse to fix some bugs that inevitably arise
> by ignoring them, why would anyone depend on Debian software for anything important?
I would argue that the situation is similar (and often worse) in
every other free software project.
I would also argue that while you may pay a software vendor to care
about your use case, that can also come with different issues.
So really, life is not perfect, and we all do what we can to cope
with that. Things are not perfect in Debian nor elsewhere both
within and outside the free software world.
I think I know some of the bugs that you are referring to as I keep
on eye on those developments. A gentle ping on the relevant bugs to
ask where things are may be appropriate. That's really the strongest
thing you can do. Others may be tempted to try to drag more info out
of you to determine what the exact history is here and who is
right/wrong, but I don't think that will help anyone in these
particular cases.
Regards,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
Date: Fri, 19 Aug 2022 16:13:02 -0700
From: Samuel Wales <samologist@gmail.com>
To: debian-user@lists.debian.org
Subject: must i consider zfs or lvm for smr large drive?
Message-ID: <CAJcAo8vyS=ifbBeOyenQVo2xtUxfLh-A_1RXGErXakkt4_=PMw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
apologies for the subject header being kind of an opinion poll rather
than a question. but it is meant as a question.
until now, i have avoided lvm and zfs determinedly. i have always
been completely satisfied to copy some big partition rather than deal
with the complexity of those. i don't want to get confused about them
when i am debugging or setting up.
i use luks and ext4 and that's enough complexity for me. i get them
right, understand them, and glory in few corner cases.
i have a new 4tb portable external drive. i want it to have a huge partition.
even such things as resizing sound error-prone or complex. more
layers and commands to learn. and zfs is a whole new thing, with, oh,
yeah, you have to use contrib or non-free [can i rely on this being
secure and also available into the future?] and oh, yeah, it's
different from luks, and oh, yeah, do a balance/resilver/whatever.
yes, send/recv beckons.
but now i am thinking, with smr, the drive could pseudo-brick, despite
discard and fstrim. and i might then want to do some kind of, idk, dd
if=/dev/zero of=some-partition to "reset" it. and my 20gb root
partition might be too small for that.
i don't actually know if /dev/zero resets smr to stop shuffling. i am
just speculating.
but if it does, then i might want lvm's or zfs's resizing feature so
that i can do /dev/zero to some lo... gical ... volume? which would
then in my imagination reset smr and then the drive would work again
instead of 3.6tb filled non-writable.
idk if zfs/btrfs has smr features better than ext4 or vice-versa. i
do NOT need snapshotting, raid. my box is old and would not support
deduplication and i wonder if it would even support zfs at all at 6gb
which always gets filled up with firefox.
so, am i going to need one of these two
more-complex-than-luks-and-ext4 technologies just for safety when the
huge partition fills up? i know they are /desirable/ technologies for
those who like them.
but desirability is not the question at all. :) the question is, for
MY case, is lvm/zfs/btrfs? going to be needed for smr.
idk if i am on this mailing list.
preliminary comments below. :)
p.s.
as a preliminarty comment, i have partitioned it for booting, my idea
being for it to boot off of anything for quick perfectly-my-env
rescue, not for all the time use. i ahve accessibility issues that
make installing and rescue cd's problematic.]
as more preliminary, the thing does not boot on my old bios box no
matter what i try.
and yet more preliminary, it is toshiba canvio basics. it does
spindown or head parking at a ridiculously low delay. idk if hdparm
-y or -Y or scsi-spin or scsiadd or eject or idle3 or what is safest.
or if i should let it rack up those smartctl attrs.
and another. i am limited in computer use and have a very large
number of limitations that i cannot go into beause it would take too
much out of me to do so. i am not a normal kind of user. but i'd
still like gentle, helpful comments on my question if anybody has
some. i've seen issues with myself and others in the past [not on
this list] with "help" being used as a very transparent, quite obvious
excuse for being a rather extreme jerk, and i'd be interested in
knowing of some accepted things to say that say "thanks, but i do not
want 'help' from you personally at all but others are still very
welcome to contribute as i know already that they are sincere and
helpful" other than quitting the place entirely [at this point always
my best option]. the idea being to encourage sincere others to help
while getting others to realize i do not want help from the problem
person and that my not replying to the problem person does not mean
sincere others can't contribute, i/e/ the problem person has not
claimed accepted ownerhip over helping me and i am in no mood to be
attacked merely for asking a question or having accessibility and
other limitations or for no reason at all.
Date: Fri, 19 Aug 2022 20:20:21 -0400
From: Chuck Zmudzinski <brchuckz@netscape.net>
To: debian-user@lists.debian.org
Subject: Re: Why are some Debian bugs ignored for a long time?
Message-ID: <[🔎] cd7bcbfd-45ab-967d-804b-0b4902d00e64@netscape.net" target="_blank" rel="noreferrer">[🔎] cd7bcbfd-45ab-967d-804b-0b4902d00e64@netscape.net>
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
On 8/19/2022 6:59 PM, Andy Smith wrote:
> Hello,
>
> On Fri, Aug 19, 2022 at 05:06:38PM -0400, Chuck Zmudzinski wrote:
> > On 8/19/2022 4:44 PM, piorunz wrote:
> > > On 19/08/2022 18:57, Chuck Zmudzinski wrote:
> > > > I have noticed that some Debian bugs are ignored for a long time, sometimes even when the person who submitted the bug offered a patch. The Debian developers/maintainers sometimes don't even reply and therefore never explain why the proposed patch cannot be applied. Why is that the case with Debian developers/maintainers?
> > >
> > > Hi Chuck,
> > >
> > > Maybe because developers/maintainers are not paid by the hour, but mere
> > > volunteers, don't you think?
> >
>
> > you are saying if a Debian user experiences a bug in Debian
> > software, Debian developers/maintainers do not have to fix it.
>
> That is a direct consequence of the meaning of the term "volunteer";
> you may as well have said, "water is wet". Volunteers cannot be
> forced to do work, else they are not volunteers.
The fact that Debian is created by volunteers and therefore the chances are
high that users might run into problems and not get help from the volunteers
who alone have the power to fix the problems is a fact that Debian users, and
all users of free software, need to keep in mind.
>
> > If Debian developers/maintainers actively refuse to fix some bugs that inevitably arise
> > by ignoring them, why would anyone depend on Debian software for anything important?
>
> I would argue that the situation is similar (and often worse) in
> every other free software project.
In Linux itself, I think it is *much* better than in Debian. I am going to try some other projects
and find out by experience where the consideration for the user has a higher priority than in
Debian.
>
> I would also argue that while you may pay a software vendor to care
> about your use case, that can also come with different issues.
>
> So really, life is not perfect, and we all do what we can to cope
> with that. Things are not perfect in Debian nor elsewhere both
> within and outside the free software world.
>
> I think I know some of the bugs that you are referring to as I keep
> on eye on those developments. A gentle ping on the relevant bugs to
> ask where things are may be appropriate.That's really the strongest
> thing you can do.
I do that and I am ignored. I am not holding my breath waiting for a response
from the relevant developers and maintainers. However, it would be a pleasant
surprise if they *did* respond and I would be grateful if they did. I just don't
think volunteers trying to help Debian but who ignore users who report bugs
in Debian is over the long term a good thing for Debian.
> Others may be tempted to try to drag more info out
> of you to determine what the exact history is here and who is
> right/wrong, but I don't think that will help anyone in these
> particular cases.
We agree on that point.
Best regards,
Chuck