Re: Zoom in the official repo is outdated

[Stefan Monnier]

Jeffrey Walton [2024-04-24 20:13:57] wrote:

> On Wed, Apr 24, 2024 at 7:13 PM Van Snyder  wrote:
>
>> On Wed, 2024-04-24 at 16:42 -0300, Luiz Romário Santana Rios wrote:
>>
>> Hello,
>>
>>
>> (Please cc me when replying as I'm not subscribed to the list)
>>
>>
>> Earlier this month, I noticed I was no longer able to login to Zoom
>>
>> meetings using the client installed from the Debian repos. In order to
>>
>> join meetings, I had to uninstall it then install the flatpack Zoom package.
>>
>>
>> I think it should either be updated or outright removed in favor of the
>>
>> flatpack version. What do you think? Should I report a bug?
>>
>>
>> I was expected to use zoom for a meeting. The zoom app didn't work at all
>> in Debian 10, completely refusing even to open a window. I at first started
>> with the zoom support in Firefox, but it didn't have a button to select
>> high resolution for the camera, so the meeting host asked me to run in the
>> app.
>>
>> I re-opened the session on a different computer that is running Debian 12.
>> The app worked OK on that computer.
>>
>
> Related, if you control the venue, then you might consider using Jitsi.
> Jitsi is open source, and it does not have the obscene terms of service
> that companies like Google, Microsoft and Zoom push onto people using their
> service. With Jitsi, your meeting data is yours. It is not used internally
> for other products, and it is not shared with partners like the Big Tech
> companies do.

There's also BigBlueButton (more featureful than Jitsi, but apparently
harder to install/setup/maintain) and I also heard good things about
Galène https://galene.org/ (which is apparently the simplest to
install/setup/maintain and the least demanding on the server).


Stefan

Re: Zoom in the official repo is outdated

[Bret Busby]

On 25/4/24 08:13, Jeffrey Walton wrote:






Related, if you control the venue, then you might consider using Jitsi. 
Jitsi is open source, and it does not have the obscene terms of service 
that companies like Google, Microsoft and Zoom push onto people using 
their service. With Jitsi, your meeting data is yours. It is not used 
internally for other products, and it is not shared with partners like 
the Big Tech companies do.


And last but not least, Zoom is not trustworthy. The company will lie to 
users until the cows come home. It was so bad the FCC had to sue them to 
get the company to stop. That's saying something when the FCC moves 
against a company. The FCC is captured, and the regulatory body rarely 
moves against any company.


Jeff


This has been discussed (and disgusted) some months ago, on this list.

zoom, like the big g (that appears to be the ominous g in the freemasons 
symbolism), is known to be a spybot thingy, making use of content from 
communications.


As the big g does it with the goggle searches and with geemail, zoom 
does it with the audio and video from its audiovisual communications. 
Using either, for communications that are not wanted to be made public, 
or sold to people that want to cause harm, is not a good idea.


jitsi is recognised as being significantly less of a spybot, and so, is 
recommended for use, by the FSF, I believe, where use of zoom, is 
strongly discouraged, I believe.



Bret Busby
Armadale
Western Australia
(UTC+0800)
.

Note this thread Re: Zoom in the official repo is outdated

[Peter Ehlert]

On April 24, 2024 1:00:29 PM Luiz Romário Santana Rios 
 wrote:



Hello,

(Please cc me when replying as I'm not subscribed to the list)

Earlier this month, I noticed I was no longer able to login to Zoom
meetings using the client installed from the Debian repos. In order to
join meetings, I had to uninstall it then install the flatpack Zoom package.

I think it should either be updated or outright removed in favor of the
flatpack version. What do you think? Should I report a bug?

Sds,

Romário

Re: Zoom in the official repo is outdated

[Jeffrey Walton]

On Wed, Apr 24, 2024 at 7:13 PM Van Snyder  wrote:

> On Wed, 2024-04-24 at 16:42 -0300, Luiz Romário Santana Rios wrote:
>
> Hello,
>
>
> (Please cc me when replying as I'm not subscribed to the list)
>
>
> Earlier this month, I noticed I was no longer able to login to Zoom
>
> meetings using the client installed from the Debian repos. In order to
>
> join meetings, I had to uninstall it then install the flatpack Zoom package.
>
>
> I think it should either be updated or outright removed in favor of the
>
> flatpack version. What do you think? Should I report a bug?
>
>
> I was expected to use zoom for a meeting. The zoom app didn't work at all
> in Debian 10, completely refusing even to open a window. I at first started
> with the zoom support in Firefox, but it didn't have a button to select
> high resolution for the camera, so the meeting host asked me to run in the
> app.
>
> I re-opened the session on a different computer that is running Debian 12.
> The app worked OK on that computer.
>

Related, if you control the venue, then you might consider using Jitsi.
Jitsi is open source, and it does not have the obscene terms of service
that companies like Google, Microsoft and Zoom push onto people using their
service. With Jitsi, your meeting data is yours. It is not used internally
for other products, and it is not shared with partners like the Big Tech
companies do.

And last but not least, Zoom is not trustworthy. The company will lie to
users until the cows come home. It was so bad the FCC had to sue them to
get the company to stop. That's saying something when the FCC moves against
a company. The FCC is captured, and the regulatory body rarely moves
against any company.

Jeff

Re: Zoom in the official repo is outdated

[Bob McGowan]

On 4/24/24 01:28 PM, Michael Kjörling wrote:

On 24 Apr 2024 16:42 -0300, from luizroma...@tecgraf.puc-rio.br (Luiz Romário 
Santana Rios):

Earlier this month, I noticed I was no longer able to login to Zoom meetings
using the client installed from the Debian repos. In order to join meetings,
I had to uninstall it then install the flatpack Zoom package.

I think it should either be updated or outright removed in favor of the
flatpack version. What do you think? Should I report a bug?

I can't seem to find any Zoom client at all in the official Debian
repositories. It also doesn't really sound like something that the
Debian project _would_ package.

https://packages.debian.org/search?keywords=zoom (which searches
everything from buster to trixie plus sid and experimental, across all
architectures) lists packages named libnet-z3950-simple2zoom-perl,
libnet-z3950-zoom-perl, libnet-z3950-zoom-perl-dbgsym, node-d3-zoom,
ruby-zoom, ruby-zoom-dbgsym, xzoom, xzoom-dbgsym, zoom-player and
zoom-player-dbgsym; none of which appear to be in any way related to
the proprietary videoconferencing service.

That said, if it's packaged for Debian somewhere and the packaged
version does not work for its intended purpose on a version of Debian
it's advertised as being packaged for, then yes, my firm belief is
that making some sort of report of this to whoever packages it that it
doesn't work properly (ideally with steps to reproduce the incorrect
behavior) is entirely reasonable.

_If_ that is the Debian project, then filing a bug against the
specific package through the Debian bug tracker is the correct way to
do it. _If so_, then start at .

Zoom provides a .deb package from their website, so they are the ones to 
work with.


You can run your Zoom app (don't start a meeting) and in the upper 
right, just above the gear icon is an account icon.  Click it and you'll 
get a menu which includes a "Check for Updates" item.


The resulting window will either tell you you're up to date or have a 
link to their webpage to download the latest version.


You will then need to manually install the .deb package.

Bob

Re: Zoom in the official repo is outdated

[Eike Lantzsch ZP5CGE / KY4PZ]

On Mittwoch, 24. April 2024 15:42:39 -04 Luiz Romário Santana Rios wrote:
> Hello,
> 
> (Please cc me when replying as I'm not subscribed to the list)
> 
> Earlier this month, I noticed I was no longer able to login to Zoom
> meetings using the client installed from the Debian repos. In order to
> join meetings, I had to uninstall it then install the flatpack Zoom
> package.
> 
> I think it should either be updated or outright removed in favor of
> the flatpack version. What do you think? Should I report a bug?
> 
> Sds,
> 
> Romário

Hello Romário,
To me it seems that Zoom on your Debian installation will be outdated forever 
because it 
is not part of any Debian repository. Not even zoom.us hints on a repository 
lurking in the 
realms of proprietary software somewhere.
You need to install a new version from here:

https://support.zoom.com/hc/en/article?
id=zm_kb&sysparm_article=KB0063458#h_adcc0b66-b2f4-468b-bc7a-12c182f354b7[1]
You may download the package from herehttps://zoom.us/download?os=linux[2]
Enter OS Type, architecture and further download the public key.
Check the package against it and then
dpkg -i zoom-package
You might have to install some additional dependencies manually.
Then hope that it will work as designed.

Have a nice day and all the best to you
-- 
Eike Lantzsch KY4PZ / ZP5CGE

On a note about Re: Sv: and so on "feature" of MS email clients.
Re: is not a short for "Reply" as MS seems to think.
A re (the ablative of res 'thing') has been used in English
since the 18th century to mean 'in the matter of', 'referring to'.



[1] https://support.zoom.com/hc/en/article?
id=zm_kb&sysparm_article=KB0063458#h_adcc0b66-b2f4-468b-bc7a-12c182f354b7
[2] https://zoom.us/download?os=linux

Re: Zoom in the official repo is outdated

[Luiz Romário Santana Rios]

I forgot I had installed zoom from the official zoom deb package, not 
from the Debian repo. And, as it turns out, they provide just the deb 
package[1], not a repo where the push updates, so I'd have to manually 
download the new deb package in order to update Zoom.


Whoops...

Sorry for the noise. And thanks for the attention.

(Using the flatpak version is more convenient anyway, since I don't have 
to keep manually updating Zoom)


[1]: https://zoom.us/client/6.0.2.4680/zoom_amd64.deb

Em 24/04/2024 17:28, Michael Kjörling escreveu:

On 24 Apr 2024 16:42 -0300, from luizroma...@tecgraf.puc-rio.br (Luiz Romário 
Santana Rios):

Earlier this month, I noticed I was no longer able to login to Zoom meetings
using the client installed from the Debian repos. In order to join meetings,
I had to uninstall it then install the flatpack Zoom package.

I think it should either be updated or outright removed in favor of the
flatpack version. What do you think? Should I report a bug?

I can't seem to find any Zoom client at all in the official Debian
repositories. It also doesn't really sound like something that the
Debian project _would_ package.

https://packages.debian.org/search?keywords=zoom (which searches
everything from buster to trixie plus sid and experimental, across all
architectures) lists packages named libnet-z3950-simple2zoom-perl,
libnet-z3950-zoom-perl, libnet-z3950-zoom-perl-dbgsym, node-d3-zoom,
ruby-zoom, ruby-zoom-dbgsym, xzoom, xzoom-dbgsym, zoom-player and
zoom-player-dbgsym; none of which appear to be in any way related to
the proprietary videoconferencing service.

That said, if it's packaged for Debian somewhere and the packaged
version does not work for its intended purpose on a version of Debian
it's advertised as being packaged for, then yes, my firm belief is
that making some sort of report of this to whoever packages it that it
doesn't work properly (ideally with steps to reproduce the incorrect
behavior) is entirely reasonable.

_If_ that is the Debian project, then filing a bug against the
specific package through the Debian bug tracker is the correct way to
do it. _If so_, then start at .

Re: Zoom in the official repo is outdated

[Michael Kjörling]

On 24 Apr 2024 16:42 -0300, from luizroma...@tecgraf.puc-rio.br (Luiz Romário 
Santana Rios):
> Earlier this month, I noticed I was no longer able to login to Zoom meetings
> using the client installed from the Debian repos. In order to join meetings,
> I had to uninstall it then install the flatpack Zoom package.
> 
> I think it should either be updated or outright removed in favor of the
> flatpack version. What do you think? Should I report a bug?

I can't seem to find any Zoom client at all in the official Debian
repositories. It also doesn't really sound like something that the
Debian project _would_ package.

https://packages.debian.org/search?keywords=zoom (which searches
everything from buster to trixie plus sid and experimental, across all
architectures) lists packages named libnet-z3950-simple2zoom-perl,
libnet-z3950-zoom-perl, libnet-z3950-zoom-perl-dbgsym, node-d3-zoom,
ruby-zoom, ruby-zoom-dbgsym, xzoom, xzoom-dbgsym, zoom-player and
zoom-player-dbgsym; none of which appear to be in any way related to
the proprietary videoconferencing service.

That said, if it's packaged for Debian somewhere and the packaged
version does not work for its intended purpose on a version of Debian
it's advertised as being packaged for, then yes, my firm belief is
that making some sort of report of this to whoever packages it that it
doesn't work properly (ideally with steps to reproduce the incorrect
behavior) is entirely reasonable.

_If_ that is the Debian project, then filing a bug against the
specific package through the Debian bug tracker is the correct way to
do it. _If so_, then start at .

-- 
Michael Kjörling 🔗 https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Re: Zoom in the official repo is outdated

[Dan Ritter]

Luiz Romário Santana Rios wrote: 
> Hello,
> 
> (Please cc me when replying as I'm not subscribed to the list)
> 
> Earlier this month, I noticed I was no longer able to login to Zoom meetings
> using the client installed from the Debian repos. In order to join meetings,
> I had to uninstall it then install the flatpack Zoom package.
> 
> I think it should either be updated or outright removed in favor of the
> flatpack version. What do you think? Should I report a bug?

Can you point to the zoom client in the Debian repos? I can't
find it.

-dsr-

Re: Zoom in the official repo is outdated

[Van Snyder]

On Wed, 2024-04-24 at 16:42 -0300, Luiz Romário Santana Rios wrote:
> Hello,
> 
> (Please cc me when replying as I'm not subscribed to the list)
> 
> Earlier this month, I noticed I was no longer able to login to Zoom 
> meetings using the client installed from the Debian repos. In order to 
> join meetings, I had to uninstall it then install the flatpack Zoom package.
> 
> I think it should either be updated or outright removed in favor of the 
> flatpack version. What do you think? Should I report a bug?
> 
> Sds,
> 
> Romário

I was expected to use zoom for a meeting. The zoom app didn't work at
all in Debian 10, completely refusing even to open a window. I at first
started with the zoom support in Firefox, but it didn't have a button
to select high resolution for the camera, so the meeting host asked me
to run in the app.

I re-opened the session on a different computer that is running Debian
12. The app worked OK on that computer.

Re: Zoom on Bookworm?

[David]

On Tue, 2023-12-19 at 20:57 -0700, Charles Curley wrote:
> On Tue, 19 Dec 2023 18:30:55 -0500
> Jeffrey Walton  wrote:
> 
> > Use Jitsi, if possible. You can even run your own Jitsi server, if
> > desired. And it is open source. .
> 
> You might also look at Jami, which has the virtue of being in the
> Debian repos.
> 
> apt show jami-daemon

Jami is excellent!
Cheers!

Re: Zoom on Bookworm?

[Charles Curley]

On Tue, 19 Dec 2023 18:30:55 -0500
Jeffrey Walton  wrote:

> Use Jitsi, if possible. You can even run your own Jitsi server, if
> desired. And it is open source. .

You might also look at Jami, which has the virtue of being in the
Debian repos.

apt show jami-daemon

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Zoom on Bookworm?

[Jeffrey Walton]

On Tue, Dec 19, 2023 at 5:29 AM Bret Busby  wrote:
>
> On 19/12/23 17:53, John Conover wrote:
> > Does the Zoom client work on Bookworm with pipewire?
> >
> Are you aware of Zoom using video calls for spying on, and, collecting
> personal information from, users, causing
>
> "The Software Freedom Conservancy (SFC) is calling on free and open
> source software (FOSS) contributors to stop using Zoom video conferencing"
>
> "Back in March, Zoom quietly changed its fine print to include a clause
> in section 10.4 that assigned the video-chat biz perpetual, royalty-free
> rights to use "customer content" "

++

Use Jitsi, if possible. You can even run your own Jitsi server, if
desired. And it is open source. .

Jeff

Re: Zoom on Bookworm?

[Tom Dial]

On 12/19/23 02:53, John Conover wrote:

Does the Zoom client work on Bookworm with pipewire?


Zoom works fine on Bookworm using mainstream Logitech camera/microphone. It 
coexists with pipewire on the system where I use it, but does not show that as 
a dependency.

Installing it will drag in its dependencies, if they are not installed. Dpkg 
--info for the current Debian install file shows:


 new Debian package, version 2.0.
 size 181054970 bytes: control archive=34820 bytes.
1329 bytes,18 lines  control
  122532 bytes,  1403 lines  md5sums
 593 bytes,18 lines   *  postinst #!/bin/bash
 226 bytes,11 lines   *  postrm   #!/bin/bash
 Package: zoom
 Version: 5.17.0.1682
 License: see https://www.zoom.us/
 Vendor: Zoom Video Communications, Inc.
 Architecture: amd64
 Maintainer: Zoom Linux Team 
 Installed-Size: 654828
 Depends: libglib2.0-0, libxcb-keysyms1, libxcb-xinerama0, libdbus-1-3, 
libxcb-shape0, libxcb-shm0, libxcb-xfixes0, libxcb-randr0, libxcb-image0, 
libfontconfig1, libxi6, libsm6, libxrender1, libpulse0, libxcomposite1, libxslt1.1, 
libsqlite3-0, libxcb-xtest0, libxtst6, ibus, libxkbcommon-x11-0, desktop-file-utils, 
libgbm1, libdrm2, libxcb-cursor0, libxcb-icccm4, libfreetype6 (>= 2.6), libgbm1 
(>= 17.1.0~rc2)
 Recommends: libegl1-mesa, libgl1-mesa-glx
 Section: default
 Priority: optional
 Homepage: https://www.zoom.us
 Description: Zoom Cloud Meetings
  Zoom brings people together to connect and get more done in a frictionless, 
secure video environment. Our easy, reliable, and innovative video-first 
solutions provide video meetings and chat, with additional options for webinars 
and phone service.
  .
  Zoom is the leading unified communications platform and helps individuals, 
schools, healthcare professionals and enterprises stay connected. Visit 
blog.zoom.us and follow @zoom_us.
  .
  By installing this app, you agree to our Terms of Service 
(https://zoom.us/terms) and Privacy Statement (https://zoom.us/privacy).


As with any product, it always is a wise to consider the terms of use and other 
legal documentation and exercise discretion.

If you decide to use it, I use (as root)

  apt install zoom_amd64.deb

It installs under /opt except for a symbolic link /usr/bin/zoom -> 
/opt/zoom/ZoomLauncher

Regards,
Tom Dial



 Thanks,

 John
 

Re: Zoom on Bookworm?

[Kent West]

On Tue, Dec 19, 2023 at 3:30 PM Kent West  wrote:

>
>
> On 12/19/23 10:53, John Conover wrote:
>> > Does the Zoom client work on Bookworm with pipewire?
>> >
>> >  Thanks,
>> >
>> >  John
>>
>
> Yes.
>
> I have version 5.17.0 of the desktop client running on my sid/trixie box
> at this very moment.
>
> with Pipewire running.

>
> --
> Kent West<")))><
> IT Support / Client Support
> Abilene Christian University
> Westing Peacefully - http://kentwest.blogspot.com
>


-- 
Kent West<")))><
IT Support / Client Support
Abilene Christian University
Westing Peacefully - http://kentwest.blogspot.com

Re: Zoom on Bookworm?

[Kent West]

On 12/19/23 10:53, John Conover wrote:
> > Does the Zoom client work on Bookworm with pipewire?
> >
> >  Thanks,
> >
> >  John
>

Yes.

I have version 5.17.0 of the desktop client running on my sid/trixie box at
this very moment.


-- 
Kent West<")))><
IT Support / Client Support
Abilene Christian University
Westing Peacefully - http://kentwest.blogspot.com

Re: Zoom on Bookworm?

[err404]

On 12/19/23 10:53, John Conover wrote:

Does the Zoom client work on Bookworm with pipewire?

 Thanks,

 John
 

you can use zoom.us in your web browser
there is less options, but it work well.

Re: Zoom on Bookworm?

[David]

On Tue, 19 Dec 2023 at 11:04, Jerome BENOIT
 wrote:

> can we efficiently jail zoom ?

Hi, my approach is to do that on my laptop by using grub to boot into various
different Debian installations.

Multiboot is un-fashionable, but I find it useful and versatile. Hard
drives are plenty
big enough to allow multiple operating systems installations.

The 931GB spinning hard drive has 4 primary partitions, sizes are approximate:
  Z = 12GB boot
  X = 12GB standalone minimal Debian installation with /boot symlinked
to /mnt/Z/X
  Y = 12GB standalone minimal Debian installation with /boot symlinked
to /mnt/Z/Y
  LUKS2 = 895GB

So basically there is unencrypted boot, and the majority of the drive
is allocated to the
LUKS2 encrypted partition. Plus there are a couple of minimal Debian
installations,
one of which has Zoom installed.

The LUKS2 partition contains LVM volumes
  S = 12GB swap
  A, B, C, D, E = 5x 12GB Debian installations with /boot symlinked to
/mnt/Z/{ABCDE}
  T = 149G data
  U = 497G data

I have installed Zoom on partition Y, which does not contain
cryptsetup tools, so
the LUKS2 partition cannot be opened, which hides all my sensitive data from
Zoom.

When I want to do real work, I boot one of my encrypted A,B,C,D,E installations
which can all access the common encrypted data in the T and U volumes.

Re: Zoom on Bookworm?

[Dan Ritter]

Jerome BENOIT wrote: 
> can we efficiently jail zoom ?

It needs access to a microphone, camera, and the network. I
suppose you could call that a jail, but for programs, that's
pretty much everything except filesystems and root privileges.

-dsr-

Re: Zoom on Bookworm?

[Jerome BENOIT]

Hi,

can we efficiently jail zoom ?

Jerome

On 19/12/2023 11:28, Bret Busby wrote:

On 19/12/23 17:53, John Conover wrote:

Does the Zoom client work on Bookworm with pipewire?

 Thanks,

 John


Are you aware of Zoom using video calls for spying on, and, collecting personal 
information from, users, causing

"The Software Freedom Conservancy (SFC) is calling on free and open source software 
(FOSS) contributors to stop using Zoom video conferencing"

"Back in March, Zoom quietly changed its fine print to include a clause in section 10.4 that 
assigned the video-chat biz perpetual, royalty-free rights to use "customer content" 
"

?

...

Recommendation had been made, for people to switch to jitsi.


Bret Busby
Armadale
Western Australia
(UTC+0800)
.

Re: Zoom on Bookworm?

[tomas]

On Tue, Dec 19, 2023 at 06:28:48PM +0800, Bret Busby wrote:

[...]

> Are you aware of Zoom using video calls for spying on, and, collecting
> personal information from, users, causing

Thanks for pointing that out. It can't be overstated.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Zoom on Bookworm?

[Bret Busby]

On 19/12/23 18:28, Bret Busby wrote:

On 19/12/23 17:53, John Conover wrote:

Does the Zoom client work on Bookworm with pipewire?

 Thanks,

 John


Are you aware of Zoom using video calls for spying on, and, collecting 
personal information from, users, causing


"The Software Freedom Conservancy (SFC) is calling on free and open 
source software (FOSS) contributors to stop using Zoom video conferencing"


"Back in March, Zoom quietly changed its fine print to include a clause 
in section 10.4 that assigned the video-chat biz perpetual, royalty-free 
rights to use "customer content" "


?

...

Recommendation had been made, for people to switch to jitsi.

" "Throughout the pandemic and its widespread Zoom adoption, we warned 
that relying on proprietary, for-profit controlled technology as 
essential infrastructure is dangerous," the organization wrote on 
Tuesday. "Last week, Zoom demonstrated exactly why everyone must stop 
using their services without any further delay." "


- Same report...


Bret Busby
Armadale
Western Australia
(UTC+0800)
.

Re: Zoom on Bookworm?

[Bret Busby]

On 19/12/23 17:53, John Conover wrote:

Does the Zoom client work on Bookworm with pipewire?

 Thanks,

 John
 


Are you aware of Zoom using video calls for spying on, and, collecting 
personal information from, users, causing


"The Software Freedom Conservancy (SFC) is calling on free and open 
source software (FOSS) contributors to stop using Zoom video conferencing"


"Back in March, Zoom quietly changed its fine print to include a clause 
in section 10.4 that assigned the video-chat biz perpetual, royalty-free 
rights to use "customer content" "


?

...

Recommendation had been made, for people to switch to jitsi.


Bret Busby
Armadale
Western Australia
(UTC+0800)
.

Re: zoom client for bullseye

[Steven Rosenberg]

On Mon, 2021-08-30 at 08:15 +0800, Robbi Nespu wrote:
> Last time (that time bullseye still on testing release) I tried with 
> they official deb, I getting dependencies issues too.. trying with 
> "apt-get -f install" solve the installation but somehow when I using
> it, 
> it hang...and sometimes I can't close my camera properly.
> 
> Then I switched to snap version. It work fine until now so I just
> gonna 
> stick using snap version but honestly, I don't recommend you to use
> snap 
> package because of it disturbing for someone who really care about 
> bandwidth, permission to run and storage size. It will be the last 
> options for me.

I use the Flatpak for Zoom. It works fine, and since there's no .deb
repo, with the Flatpak I get updates. Since I very seldomly use Zoom,
it was always out of date when I did start it, so I'm happy to have the
Flatpak.

Re: zoom client for bullseye

[albcares]

I would suggest trying a different browser: Vivaldi.
It's a "fork" of chromium, with some interesting features.
I.e. it solved my troubles with teams in mint 17.3; maybe not a solution,
just a practical patch...

Il lun 30 ago 2021 02:33 Robbi Nespu  ha scritto:

> Last time (that time bullseye still on testing release) I tried with
> they official deb, I getting dependencies issues too.. trying with
> "apt-get -f install" solve the installation but somehow when I using it,
> it hang...and sometimes I can't close my camera properly.
>
> Then I switched to snap version. It work fine until now so I just gonna
> stick using snap version but honestly, I don't recommend you to use snap
> package because of it disturbing for someone who really care about
> bandwidth, permission to run and storage size. It will be the last
> options for me..
>
> Maybe you want to read my snap configuration adjustment[1]
>
> [1]
>
> https://robbinespu.gitlab.io/posts/control-your-snap-package/#how-to-control-and-configure-your-snap-stuff
>
> --
> Robbi Nespu 
> D311 B5FF EEE6 0BE8 9C91 FA9E 0C81 FA30 3B3A 80BA
> https://robbinespu.gitlab.io | https://mstdn.social/@robbinespu
>
>

Re: zoom client for bullseye

[Robbi Nespu]

Last time (that time bullseye still on testing release) I tried with 
they official deb, I getting dependencies issues too.. trying with 
"apt-get -f install" solve the installation but somehow when I using it, 
it hang...and sometimes I can't close my camera properly.


Then I switched to snap version. It work fine until now so I just gonna 
stick using snap version but honestly, I don't recommend you to use snap 
package because of it disturbing for someone who really care about 
bandwidth, permission to run and storage size. It will be the last 
options for me..


Maybe you want to read my snap configuration adjustment[1]

[1] 
https://robbinespu.gitlab.io/posts/control-your-snap-package/#how-to-control-and-configure-your-snap-stuff


--
Robbi Nespu 
D311 B5FF EEE6 0BE8 9C91 FA9E 0C81 FA30 3B3A 80BA
https://robbinespu.gitlab.io | https://mstdn.social/@robbinespu

Re: zoom client for bullseye

[Brian]

On Sun 22 Aug 2021 at 14:51:17 -0400, Jim Popovitch wrote:

> On Sun, 2021-08-22 at 14:47 -0400, Greg Wooledge wrote:
> > On Sun, Aug 22, 2021 at 02:37:30PM -0400, Jim Popovitch wrote:
> > > On Sun, 2021-08-22 at 14:17 -0400, Thomas George wrote:
> > > > The zoom client downloaded from the zoom web page seems to have been 
> > > > written for Debian 8
> > > > 
> > > > Installing it in bullseye fails, dependency problems
> > > > 
> > > 
> > > Works for me (Deb11 + Cinnamon).  IIRC, after running dpkg -i zoom.deb
> > > you need to run "apt-get -f install" to fix the dependencies.
> > 
> > If that's true, then you could simply use "apt install ./zoom*.deb" in
> > the first place.  It's undocumented, but it has been a thing for several
> > years now.
> 
> ntk, Thanks!

I wouldn't dream of disputing Greg Wooledge's advice. 'dpkg -i...' is
not a bad way to go but should *always* be folled by 'apt -f install'.
It leads to the same outcome.

-- 
Brian.

Re: zoom client for bullseye

[Brian]

On Sun 22 Aug 2021 at 14:27:12 -0400, Greg Wooledge wrote:

> On Sun, Aug 22, 2021 at 02:17:15PM -0400, Thomas George wrote:
> > The zoom client downloaded from the zoom web page seems to have been written
> > for Debian 8
> > 
> > Installing it in bullseye fails, dependency problems
> 
> There's not much we can do about that.  If you really want the standalone
> application, contact Zoom.

That's an avenue of support. Here isn't. We haven't any control over
the Zoom package.

> I'd suggest simply running the in-browser version whenever you
> need to attend a Zoom meeting.  It should work in either Firefox or
> Chrome/Chromium.

I've never done that. The flatpack version worked for me.

-- 
Brian.

Re: zoom client for bullseye

[Jim Popovitch]

On Sun, 2021-08-22 at 14:47 -0400, Greg Wooledge wrote:
> On Sun, Aug 22, 2021 at 02:37:30PM -0400, Jim Popovitch wrote:
> > On Sun, 2021-08-22 at 14:17 -0400, Thomas George wrote:
> > > The zoom client downloaded from the zoom web page seems to have been 
> > > written for Debian 8
> > > 
> > > Installing it in bullseye fails, dependency problems
> > > 
> > 
> > Works for me (Deb11 + Cinnamon).  IIRC, after running dpkg -i zoom.deb
> > you need to run "apt-get -f install" to fix the dependencies.
> 
> If that's true, then you could simply use "apt install ./zoom*.deb" in
> the first place.  It's undocumented, but it has been a thing for several
> years now.

ntk, Thanks!

-Jim P.

Re: zoom client for bullseye

[Greg Wooledge]

On Sun, Aug 22, 2021 at 02:37:30PM -0400, Jim Popovitch wrote:
> On Sun, 2021-08-22 at 14:17 -0400, Thomas George wrote:
> > The zoom client downloaded from the zoom web page seems to have been 
> > written for Debian 8
> > 
> > Installing it in bullseye fails, dependency problems
> > 
> 
> Works for me (Deb11 + Cinnamon).  IIRC, after running dpkg -i zoom.deb
> you need to run "apt-get -f install" to fix the dependencies.

If that's true, then you could simply use "apt install ./zoom*.deb" in
the first place.  It's undocumented, but it has been a thing for several
years now.

Re: zoom client for bullseye

[Jim Popovitch]

On Sun, 2021-08-22 at 14:17 -0400, Thomas George wrote:
> The zoom client downloaded from the zoom web page seems to have been 
> written for Debian 8
> 
> Installing it in bullseye fails, dependency problems
> 

Works for me (Deb11 + Cinnamon).  IIRC, after running dpkg -i zoom.deb
you need to run "apt-get -f install" to fix the dependencies.

hth,

-Jim P.

Re: zoom client for bullseye

[Polyna-Maude Racicot-Summerside]

On 2021-08-22 2:17 p.m., Thomas George wrote:
> The zoom client downloaded from the zoom web page seems to have been
> written for Debian 8
> 
> Installing it in bullseye fails, dependency problems
> 
What is the dependencies that fail ?
It does run on Debian Buster.
-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Re: zoom client for bullseye

[Gokan Atmaca]

> Installing it in bullseye fails, dependency problems

Can you share the log? Or run apt -f install?


On Sun, Aug 22, 2021 at 9:25 PM Thomas George  wrote:
>
> The zoom client downloaded from the zoom web page seems to have been
> written for Debian 8
>
> Installing it in bullseye fails, dependency problems
>

Re: zoom client for bullseye

[Greg Wooledge]

On Sun, Aug 22, 2021 at 02:17:15PM -0400, Thomas George wrote:
> The zoom client downloaded from the zoom web page seems to have been written
> for Debian 8
> 
> Installing it in bullseye fails, dependency problems

There's not much we can do about that.  If you really want the standalone
application, contact Zoom.

I'd suggest simply running the in-browser version whenever you
need to attend a Zoom meeting.  It should work in either Firefox or
Chrome/Chromium.

Re: Zoom.

[peter]

From: Tom Dial 
Date: Wed, 21 Apr 2021 15:04:45 -0600
> The link above hints that you may have a broken install. You might want
> to remove (most of) it by deleting the /opt/zoom directory.

Removing Zoom with aptitude also "disappeared" linphone.  After 
removing Zoom,  aptitude showed linphone was not installed.  I'm 
leaving  both off the Debian system until progress is apparent.

> The link above hints that you may have a broken install. You might want
> to remove (most of) it by deleting the /opt/zoom directory. The
> installation also includes
> 
>  /usr/bin/zoom
>  /usr/share/applications/Zoom.desktop
>  /usr/share/doc/zoom/changelog.gz
>  /usr/share/mime/packages/zoom.xml
>  /usr/share/pixmaps/Zoom.png
>  /usr/share/pixmaps/application-x-zoom.png
> 
> They can, I think, be ignored, and removal probably is unnecessary.

After removal with aptitude, all of that is gone.

From: Greg Wooledge 
Date: Wed, 21 Apr 2021 11:22:46 -0400
> Instead of installing the Zoom package, try just using Zoom inside
> a web browser. 

Yah, a user should be wary of any software not available from the 
Debian archive.

The FIrefox extension appeared to start OK.  The USB video camera was 
selectable but no video image appeared in the window.  Also no audio.  

Zoom isn't necessary on the desktop system.  It works on the iPhone 
and Android tablet.

Thx, ... P.

-- 
tel: +1 604 670 0140Bcc: peter at easthope. ca

Re: Zoom.

[Gary L. Roach]

Hi all,

OS debian10 amd -64 system

I've been using zoom for some time and have had to reinstall twice due 
to system problems. I have used the "dpkg -i  install" method followed 
by --fix-missing clean up. Everything has worked fine both times. My 
only problem is with the sound. I use bluetooth head phones and have 
trouble getting the sound ported to the proper device. This obviously 
has nothing to do with the zoom installation.


I strongly recommend downloading the .deb file from the zoom web page. 
It works fine.



Gary R.

Re: Zoom.

[Dominique Dumont]

On Wednesday, 21 April 2021 20:21:56 CEST Cindy Sue Causey wrote:
> I just had to do this AGAIN yesterday. I download the dotDEB file then
> "dpkg -i" it. It always fails due to missing dependencies.

You should use gdebi. This tool checks and installs required dependencies.

HTH

Re: Zoom.

[tomas]

On Sun, Apr 25, 2021 at 10:08:19AM +0200, deloptes wrote:

[...]

> from time to time we share same POV :)

...we humans are like that >;-)

Cheers
 - t


signature.asc
Description: Digital signature

Re: Zoom.

[deloptes]

to...@tuxteam.de wrote:

> Can confirm: it's juts the other way around -- the native app has
> trouble with me. I don't trust it. So I never installed it, leading
> to... not having had trouble with it ;-P

+1

from time to time we share same POV :)

Re: Zoom.

[tomas]

On Sun, Apr 25, 2021 at 02:53:05AM +, Russell wrote:
> Greg Wooledge  wrote:
> > On Wed, Apr 21, 2021 at 08:01:02AM -0700, pe...@easthope.ca wrote:
> >> Installed Zoom in Debian 10.
> >> [...]
> >> Ideas welcome.
> > 
> > Instead of installing the Zoom package, try just using Zoom inside
> > a web browser [...]

> For what it's worth, I've never had trouble with the native app.

Can confirm: it's juts the other way around -- the native app has
trouble with me. I don't trust it. So I never installed it, leading
to... not having had trouble with it ;-P

Cheers
 - t


signature.asc
Description: Digital signature

Re: Zoom.

[Russell]

Greg Wooledge  wrote:
> On Wed, Apr 21, 2021 at 08:01:02AM -0700, pe...@easthope.ca wrote:
>> Installed Zoom in Debian 10.
>> [...]
>> Ideas welcome.
> 
> Instead of installing the Zoom package, try just using Zoom inside
> a web browser.  I've used it inside Google Chrome without any problems.
> I can't vouch for how it will behave in Firefox or Chromium, but it's
> gotta be better than the third-party package.

For what it's worth, I've never had trouble with the native app.

-- 
rust
0x68caecc97f6a90122e51c0692c88d9cb6b58a3dc

Re: Zoom.

[peter]

From: Tom Dial 
Date: Wed, 21 Apr 2021 15:04:45 -0600
> First, as Greg Wooledge and tomas noted, You can run it using a browser,
> with some possible functional limitations.

Scheduled to give it a try April 30.

> recommend 4GB memory and an i3/i5/i7 or equivalent AMD CPU. These are 64
> bit CPUs.

Yep, underpowered; 32 bit, 3.5 GB.  

Received this comment elsewhere.
> I found my old 32 bit netbook and installed on it, it runs though 
> sluggish. Debian 8. It is a bit older version of Zoom (5.4) and the 
> constrained screen is awkward, ...

So I'd still expect this machine to display more than an empty window.

> The link above hints that you may have a broken install. ...

OK, reinstallation is on my list, after trying the browser.

Thanks, ... P.

-- 
VoIP: +1 604 670 0140Bcc: peter at easthope. ca

Re: Zoom.

[Tom Dial]

On 4/21/21 09:01, pe...@easthope.ca wrote:
> Hi,
> 
> Installed Zoom in Debian 10.
> 
> Checked dependancies listed here.
> https://support.zoom.us/hc/en-us/articles/204206269-Installing-or-updating-Zoom-on-Linux
> 
> A right click on the video camera icon and release on "Join Meeting..." gives
> the window in this screenshot.
> http://easthope.ca/ZoomJoinMeeting2021-04-21.png

I've been using various zoom client versions for over a year, and claim
some possibly useful experience.

First, as Greg Wooledge and tomas noted, You can run it using a browser,
with some possible functional limitations.

Second, contrary to some opinions, I have no major qualms about
installing the client software, although initially I examined what
installing and operating it in a confined test environment did and,
after what I considered a reasonable amount of testing and updating,
concluded that it is a well-behaved piece of software on Debian Buster
and Bullseye. It has given me no problems.

If you elect to install the client:

0. Previous history (referenced by Curt) suggests you may have a 32 bit
only machine; Michael Stone probably is on the mark in suggesting this
will not work well, if at all. Processor and memory requirements given at

https://support.zoom.us/hc/en-us/articles/201362023-System-requirements-for-Windows-macOS-and-Linux

recommend 4GB memory and an i3/i5/i7 or equivalent AMD CPU. These are 64
bit CPUs.

The link above hints that you may have a broken install. You might want
to remove (most of) it by deleting the /opt/zoom directory. The
installation also includes

 /usr/bin/zoom
 /usr/share/applications/Zoom.desktop
 /usr/share/doc/zoom/changelog.gz
 /usr/share/mime/packages/zoom.xml
 /usr/share/pixmaps/Zoom.png
 /usr/share/pixmaps/application-x-zoom.png

They can, I think, be ignored, and removal probably is unnecessary.

1. Download the Debian version (presuming you are using Debian) to /tmp
or another directory of your choice. Choose the applicable Debian
version, either 7.7 or the default 8.0+.

2. Install with apt, specifying the full path to the .deb file

 sudo apt /tmp/zoom_16775.0418_amd64.deb

This should cause installation of any necessary dependencies. Cindy
Causey's report suggests using dpkg is likely bring problems on occasion.

Regards,
Tom Dial

> 
> Ideas welcome.
> 
> Thx,  ... P.
> 
> 
> 

Re: Zoom.

[Greg Wooledge]

On Wed, Apr 21, 2021 at 02:21:56PM -0400, Cindy Sue Causey wrote:
> On 4/21/21, Richmond  wrote:
> > sudo apt install ~/Downloads/zoom_amd64.deb
> 
> I just had to do this AGAIN yesterday. I download the dotDEB file then
> "dpkg -i" it. It always fails due to missing dependencies. Somewhere
> in the failed effort, the reminder to "apt --fix-broken install"
> appears so that's what I do next.

You're doing it the old way.  If that works, well, congrats.

The modern way is to use apt or apt-get to install the .deb file,
as Richmond showed.  You need to make sure the pathname of the .deb file
that you pass to apt begins with / or ./ or ../ so apt knows it's a
pathname and not a package name.  Since ~ is expanded to an absolute
path (beginning with / ), Richmond's command works just fine.

Re: Zoom.

[Cindy Sue Causey]

On 4/21/21, Richmond  wrote:
> pe...@easthope.ca writes:
>
>> Installed Zoom in Debian 10.
>>
>> Checked dependancies listed here.
>> https://support.zoom.us/hc/en-us/articles/204206269-Installing-or-updating-Zoom-on-Linux
>>
>> A right click on the video camera icon and release on "Join Meeting..."
>> gives
>> the window in this screenshot.
>> http://easthope.ca/ZoomJoinMeeting2021-04-21.png
>>
>> Ideas welcome.
>>
>> Thx,  ... P.
>
> I downloaded zoom_amd64.deb from zoom.us and installed it using apt I
> think. It checks dependencies for you.
>
> sudo apt install ~/Downloads/zoom_amd64.deb


I just had to do this AGAIN yesterday. I download the dotDEB file then
"dpkg -i" it. It always fails due to missing dependencies. Somewhere
in the failed effort, the reminder to "apt --fix-broken install"
appears so that's what I do next.

Yesterday it worked perfectly. Everything was done in about a minute.
60 seconds.

Other times, it's a battle of going back and forth cherry picking
missing dependencies from packages.debian.org then running the "dpkg
-i" command on them, too, until every package is finally satisfied.
I'm a-suming that yesterday's success was due to Bullseye getting
ready to roll over into stable..

Maybe. Whatever the reason, yesterday was a good day for it to go that
smoothly. Thank you to all who help make that happen. :)

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with birdseed *

Re: Zoom.

[Curt]

On 2021-04-21, pe...@easthope.ca  wrote:
> Hi,
>
> Installed Zoom in Debian 10.
>
> Checked dependancies listed here.
> https://support.zoom.us/hc/en-us/articles/204206269-Installing-or-updating-Zoom-on-Linux
>
> A right click on the video camera icon and release on "Join Meeting..." gives
> the window in this screenshot.
> http://easthope.ca/ZoomJoinMeeting2021-04-21.png
>
> Ideas welcome.
>
> Thx,  ... P.

https://www.mail-archive.com/debian-user@lists.debian.org/msg761832.html

Re: Zoom.

[Richmond]

pe...@easthope.ca writes:

> Hi,
>
> Installed Zoom in Debian 10.
>
> Checked dependancies listed here.
> https://support.zoom.us/hc/en-us/articles/204206269-Installing-or-updating-Zoom-on-Linux
>
> A right click on the video camera icon and release on "Join Meeting..." gives
> the window in this screenshot.
> http://easthope.ca/ZoomJoinMeeting2021-04-21.png
>
> Ideas welcome.
>
> Thx,  ... P.

I downloaded zoom_amd64.deb from zoom.us and installed it using apt I
think. It checks dependencies for you.

sudo apt install ~/Downloads/zoom_amd64.deb

Re: Zoom.

[tomas]

On Wed, Apr 21, 2021 at 11:22:46AM -0400, Greg Wooledge wrote:
> On Wed, Apr 21, 2021 at 08:01:02AM -0700, pe...@easthope.ca wrote:
> > Installed Zoom in Debian 10.
> > [...]
> > Ideas welcome.
> 
> Instead of installing the Zoom package, try just using Zoom inside
> a web browser.  I've used it inside Google Chrome without any problems.
> I can't vouch for how it will behave in Firefox or Chromium, but it's
> gotta be better than the third-party package.

Firefox worked here, too. Note that Zoom wants to coax you into
using their "full client", thus the web client has a slightly
reduced interface. But it does its job.

Cheers
 - t


signature.asc
Description: Digital signature

Re: Zoom.

[Greg Wooledge]

On Wed, Apr 21, 2021 at 08:01:02AM -0700, pe...@easthope.ca wrote:
> Installed Zoom in Debian 10.
> [...]
> Ideas welcome.

Instead of installing the Zoom package, try just using Zoom inside
a web browser.  I've used it inside Google Chrome without any problems.
I can't vouch for how it will behave in Firefox or Chromium, but it's
gotta be better than the third-party package.

Re: Zoom.

[Michael Stone]

On Thu, Oct 22, 2020 at 06:08:23AM -0700, pe...@easthope.ca wrote:

From: Michael Stone 
Date: Mon, 19 Oct 2020 17:08:10 -0400

I'd strongly recommend switching to the amd64 distribution for a variety of 
reasons.


Reasonable advice but for all other needs, the old machine serves
well.


I'd assumed it was just a machine that could run amd64 but had i386 on 
it for legacy reasons. If it's really a machine that's too old for amd64 
I'd be amazed if zoom could possibly work on it.

Re: Zoom.

[peter]

From: Michael Stone 
Date: Mon, 19 Oct 2020 17:08:10 -0400
> I'd strongly recommend switching to the amd64 distribution for a variety of 
> reasons. 

Reasonable advice but for all other needs, the old machine serves 
well.  

A mobile data account includes an Android-Alcatel tablet.  Zoom can be 
used on that.  The contamination of the Debian system with 
proprietary software is avoided.

Thanks, ... P.


  

-- 
Tel: +1 604 670 0140Bcc: peter at easthope. ca

Re: shells (was Re: Zoom.)

[Tony van der Hoff]

On 20/10/2020 15:51, rhkra...@gmail.com wrote:

Top posting intentionally as I don't think any (or much) context is required.


so, hijacking a thread instead? :-)


--
Tony van der Hoff| mailto:t...@vanderhoff.org
Buckinghamshire, England |

Re: shells (was Re: Zoom.)

[Nicolas George]

rhkra...@gmail.com (12020-10-20):
> Top posting intentionally as I don't think any (or much) context is required.

Then you could just omit it.

> I am always impressed with Greg's knowledge of the Bash shell (maybe all 
> shells), but, wow, Bash seems like a convoluted mess to keep track of all the 
> little details / gotchas.
> 
> Is there a shell that is better in that respect?  Maybe the c-shell?  I don't 
> like c (because I have a hard time programming in it), but if the c-shell has 
> less intricacies (and is quite consistent with the c language), then maybe 
> (for me) it is worth switching to (someday ;-)

I strongly suggest zsh.

Among other advantages, it will not re-expand and re-split variables,
even without quotes, and it has a powerful globbing mechanism, with
recursive search and filters on files properties (size, ownership,
mode).

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature

Re: shells (was Re: Zoom.)

[rhkramer]

Top posting intentionally as I don't think any (or much) context is required.

I am always impressed with Greg's knowledge of the Bash shell (maybe all 
shells), but, wow, Bash seems like a convoluted mess to keep track of all the 
little details / gotchas.

Is there a shell that is better in that respect?  Maybe the c-shell?  I don't 
like c (because I have a hard time programming in it), but if the c-shell has 
less intricacies (and is quite consistent with the c language), then maybe 
(for me) it is worth switching to (someday ;-)

Nothing new below this line.

On Tuesday, October 20, 2020 07:36:39 AM Greg Wooledge wrote:
> The weird backslashing tells me you're defining PS1 with double quotes
> instead of single quotes, which is weird, and probably indicates that
> you're doing even worse things, like dynamically generating pieces of
> your PS1... I've seen things... things that no man should see
> 
> Anyway, in addition to the weird quoting and possible abominations
> unrevealed, your command substitution forks.  Every time the prompt
> is drawn, a new process is forked, just to do that simple "if" check.
> 
> The standard workaround for that is to use an array variable with the
> two possible outcomes, and a bit of arithmetic.
> 
> unicorn:~$ green=$(tput setaf 2) red=$(tput setaf 1) normal=$(tput sgr0)
> unicorn:~$ status=(+ -) statcolor=("$green" "$red")
> unicorn:~$ PS1='\[${statcolor[!!$?]}\]${status[!!$?]}\[$normal\] \h:\w\$ '
> + unicorn:~$ true
> + unicorn:~$ false
> - unicorn:~$ true
> + unicorn:~$
> 
> (You can't see the colors in the mailing list, but they're there.)
> 
> Just remember the basics:
> 
> 1) Use single quotes around your definition of PS1, because you want all
>of the parts of it to be taken literally, and quoting is already hard
>enough without making it worse.
> 
> 2) Variable expansions are "free" (do not cost a process fork).  This
>includes variables that are set by PRMOPT_COMMAND, which is the more
>efficient way to set variables dynamically if you *really* need that,
>which you probably don't.
> 
> 3) Color and other terminal escape codes can and should be stored in
>variables, which you can expand in PS1, as long as the PS1 definition
>is single-quoted.  Don't store raw terminal sequences, because they
>are not the same for all terminals.  This is what tput(1) is for.
> 
> 4) Terminal escape sequences that don't change the cursor position should
>be enclosed in \[ \] so the shell knows where the cursor is at all
>times.
> 
> 5) When expanding the index of an indexed array variable, the square
>brackets are a math context.  In a math context, !!$? means "negate
>the previous command's exit status twice".  So, 0 -> 1 -> 0, or
>nonzero -> 0 -> 1.  Thus, !!$? always expands to either 0 or 1.  And
>because it's in single quotes, it shouldn't trip history expansion,
>if you still have history expansion turned on.  (I don't.)

Re: Zoom.

[Dan Ritter]

Greg Wooledge wrote: 
> On Tue, Oct 20, 2020 at 06:36:15AM -0400, Dan Ritter wrote:
> > I have this in my PS1 definition:
> > 
> > \$(if [[ \$? == 0 ]]; then echo \"+\"; else echo \"-\"; fi)\
> > 
> > Which has the effect of telling me the rough exit status of the
> > last command in my prompt. 
> 
> The weird backslashing tells me you're defining PS1 with double quotes
> instead of single quotes, which is weird, and probably indicates that
> you're doing even worse things, like dynamically generating pieces of
> your PS1... I've seen things... things that no man should see


Regain some SAN points: none of the rest of it is weird. 

Two lines. First line is a colorized \u@\h:\w\, the second line
is the exit status and \$  


> Anyway, in addition to the weird quoting and possible abominations
> unrevealed, your command substitution forks.  Every time the prompt
> is drawn, a new process is forked, just to do that simple "if" check.
> 
> The standard workaround for that is to use an array variable with the
> two possible outcomes, and a bit of arithmetic.
> 
> unicorn:~$ green=$(tput setaf 2) red=$(tput setaf 1) normal=$(tput sgr0)
> unicorn:~$ status=(+ -) statcolor=("$green" "$red")
> unicorn:~$ PS1='\[${statcolor[!!$?]}\]${status[!!$?]}\[$normal\] \h:\w\$ '
> + unicorn:~$ true
> + unicorn:~$ false
> - unicorn:~$ true
> + unicorn:~$ 

Thanks, When I get around to redoing my PS1, I'll use that and
fix the quoting.

-dsr-

Re: Zoom.

[Greg Wooledge]

On Tue, Oct 20, 2020 at 06:36:15AM -0400, Dan Ritter wrote:
> I have this in my PS1 definition:
> 
> \$(if [[ \$? == 0 ]]; then echo \"+\"; else echo \"-\"; fi)\
> 
> Which has the effect of telling me the rough exit status of the
> last command in my prompt. 

The weird backslashing tells me you're defining PS1 with double quotes
instead of single quotes, which is weird, and probably indicates that
you're doing even worse things, like dynamically generating pieces of
your PS1... I've seen things... things that no man should see

Anyway, in addition to the weird quoting and possible abominations
unrevealed, your command substitution forks.  Every time the prompt
is drawn, a new process is forked, just to do that simple "if" check.

The standard workaround for that is to use an array variable with the
two possible outcomes, and a bit of arithmetic.

unicorn:~$ green=$(tput setaf 2) red=$(tput setaf 1) normal=$(tput sgr0)
unicorn:~$ status=(+ -) statcolor=("$green" "$red")
unicorn:~$ PS1='\[${statcolor[!!$?]}\]${status[!!$?]}\[$normal\] \h:\w\$ '
+ unicorn:~$ true
+ unicorn:~$ false
- unicorn:~$ true
+ unicorn:~$ 

(You can't see the colors in the mailing list, but they're there.)

Just remember the basics:

1) Use single quotes around your definition of PS1, because you want all
   of the parts of it to be taken literally, and quoting is already hard
   enough without making it worse.

2) Variable expansions are "free" (do not cost a process fork).  This
   includes variables that are set by PRMOPT_COMMAND, which is the more
   efficient way to set variables dynamically if you *really* need that,
   which you probably don't.

3) Color and other terminal escape codes can and should be stored in
   variables, which you can expand in PS1, as long as the PS1 definition
   is single-quoted.  Don't store raw terminal sequences, because they
   are not the same for all terminals.  This is what tput(1) is for.

4) Terminal escape sequences that don't change the cursor position should
   be enclosed in \[ \] so the shell knows where the cursor is at all
   times.

5) When expanding the index of an indexed array variable, the square
   brackets are a math context.  In a math context, !!$? means "negate
   the previous command's exit status twice".  So, 0 -> 1 -> 0, or
   nonzero -> 0 -> 1.  Thus, !!$? always expands to either 0 or 1.  And
   because it's in single quotes, it shouldn't trip history expansion,
   if you still have history expansion turned on.  (I don't.)

Re: Zoom.

[Nicolas George]

Dan Ritter (12020-10-20):
> I have this in my PS1 definition:
> 
> \$(if [[ \$? == 0 ]]; then echo \"+\"; else echo \"-\"; fi)\
> 
> Which has the effect of telling me the rough exit status of the
> last command in my prompt. 

With zsh, I suggest "setopt pritexitvalue".

Regards,

-- 
  Nicoals George


signature.asc
Description: PGP signature

Re: Zoom.

[Dan Ritter]

John Crawley wrote: 
> On 20/10/2020 04:57, pe...@easthope.ca wrote:
> > From: Bob McGowan 
> > Date: Sat, 17 Oct 2020 18:18:18 -0700
> > > As for exiting, so long as Zoom considers it a normal exit, it will
> > > give an exit status of zero and you will simply see the next prompt.
> > > That is as expected.
> > 
> > At least one earlier reply had output in the launching terminal.  Here
> > nothing in the terminal.  No exit status.  Nothing.
> Off the main topic, but the exit status of a command does not appear in the
> terminal. To see it, run:
> echo $?

I have this in my PS1 definition:

\$(if [[ \$? == 0 ]]; then echo \"+\"; else echo \"-\"; fi)\

Which has the effect of telling me the rough exit status of the
last command in my prompt. 

-dsr-

Re: Zoom.

[tomas]

On Mon, Oct 19, 2020 at 06:02:38PM -0700, pe...@easthope.ca wrote:
> From: Stefan Monnier 
> Date: Sun, 18 Oct 2020 11:16:01 -0400
> > I use and recommend Jitsi as a Free Software alternative.
> 
> 1-1 connection or multi-party conference?

Jitsi and BBB both support multi-party. You either set up a server
yourself of use one set up by someone else out there who lets you
use it.

There are good recent reviews of both over at lwn.net [1] [2]. In the
usual high lwn quality. As is usual at lwn, the comments are worth
reading, too.

Cheers

[1] "Video conferencing with Jitsi" https://lwn.net/Articles/815751/
[2] "Video conferencing with BigBlueButton" https://lwn.net/Articles/817146/

 - t


signature.asc
Description: Digital signature

Re: Zoom.

[John Crawley]

On 20/10/2020 04:57, pe...@easthope.ca wrote:

From: Bob McGowan 
Date: Sat, 17 Oct 2020 18:18:18 -0700

As for exiting, so long as Zoom considers it a normal exit, it will
give an exit status of zero and you will simply see the next prompt.
That is as expected.


At least one earlier reply had output in the launching terminal.  Here
nothing in the terminal.  No exit status.  Nothing.
Off the main topic, but the exit status of a command does not appear in  
the terminal. To see it, run:

echo $?

--
John

Re: Zoom.

[peter]

From: Stefan Monnier 
Date: Sun, 18 Oct 2020 11:16:01 -0400
> I use and recommend Jitsi as a Free Software alternative.

1-1 connection or multi-party conference?

Thanks,   ... P.
   

-- 
Tel: +1 604 670 0140Bcc: peter at easthope. ca

Re: Zoom.

[peter]

From: Stefan Monnier 
Date: Sun, 18 Oct 2020 11:16:01 -0400
> I use and recommend Jitsi as a Free Software alternative.

1-1 connection or multi-party conference?

Thanks,   ... P.
   

-- 
Tel: +1 604 670 0140Bcc: peter at easthope. ca

Re: Zoom.

[Michael Stone]

On Mon, Oct 19, 2020 at 12:57:52PM -0700, pe...@easthope.ca wrote:

Obvious factor: replies mention 64 bit machines.  32 b here.  Anyone
have Zoom running on a 32 b machine with Debian 10?


Probably not many, if any. I'd strongly recommend switching to the amd64 
distribution for a variety of reasons.

Re: Zoom.

[peter]

From: Bob McGowan 
Date: Sat, 17 Oct 2020 18:18:18 -0700
> I've seen the browser part only when I click on a link in an email 
> invite.

I shouldn't have included the browser window.  Not really pertinent.

> As for exiting, so long as Zoom considers it a normal exit, it will 
> give an exit status of zero and you will simply see the next prompt. 
> That is as expected.

At least one earlier reply had output in the launching terminal.  Here 
nothing in the terminal.  No exit status.  Nothing.

> More details on exactly what you are doing and how you are getting 
> your environment set up would be helpful. 

Obvious factor: replies mention 64 bit machines.  32 b here.  Anyone 
have Zoom running on a 32 b machine with Debian 10?

LXDE environment here.  Installed strictly according to the 
instructions at zoom.us.  Used apt or apt-get.  Checked all the 
dependancies specified in zoom.us.

I found nothing to configure zoom.  I guess a working zoom window 
might have an edit or preferences button.  No such thing here.

From: A_Man_Without_Clue  
Date: Sun, 18 Oct 2020 12:09:52 +0900 
Message-id:  
> Mine is working fine except it pops up occasionally for no reason. Quite 
> annoying though.

The automatic startup happens here; about every 30 minutes. The window 
is always empty.

Seems I should carefully work through the installation again.  
Wondering whether I am the only person try a 32 bit machine.

Thanks for all the feedback, ... P.



-- 
Tel: +1 604 670 0140Bcc: peter at easthope. ca

Re: Zoom.

[Stefan Monnier]

>>> Isn't it funny that we consider ourselves "liberal democracies", but
>>> when crossing our $COMPANY's doorstep, we leave our convictions at the
>>> wardrobe?
>> In an ideal world one could just refuse to do so and quit the job.
> There are many other things one can do,

Among them I forgot to mention an important one: you can "refuse to do
so" but without quitting your job.  Of course, there's the risk you'll
get fired, but there are many jobs where the employer may prefer some
other course of action, especially if you combine your refusal with
a reasonable counter offer.


Stefan

Re: Zoom.

[tomas]

On Mon, Oct 19, 2020 at 11:21:21AM -0400, Stefan Monnier wrote:
> >> Isn't it funny that we consider ourselves "liberal democracies", but
> >> when crossing our $COMPANY's doorstep, we leave our convictions at the
> >> wardrobe?
> > In an ideal world one could just refuse to do so and quit the job.
> 
> There are many other things one can do, starting with consistently
> and repeatedly pointing out the problems in using such services, using
> them as little as possible and using alternatives whenever possible
> (rather than following the path of least resistance and keep using the
> proprietary tool in circumstances where it's not necessary, simply
> because you have it setup already), ...

Exactly. No need to die in a hill for it :)

Cheers
-- t


signature.asc
Description: Digital signature

Re: Zoom.

[Stefan Monnier]

> But this isn't an ideal world, is it?

No, but the recent societal changes due to the pandemic have made an
enormous difference: for many (most?) people now 100% of their
communications outside of their immediate family (including the most
intimate/private ones) goes through proprietary code under the
control of companies which owe nothing to those people.

To make matters worse, this is a small handful of companies which
control (and can record, archive, analyze, ...) the whole
world's communication.

The power they can wield is hard to fathom.


Stefan

Re: Zoom.

[Stefan Monnier]

>> Isn't it funny that we consider ourselves "liberal democracies", but
>> when crossing our $COMPANY's doorstep, we leave our convictions at the
>> wardrobe?
> In an ideal world one could just refuse to do so and quit the job.

There are many other things one can do, starting with consistently
and repeatedly pointing out the problems in using such services, using
them as little as possible and using alternatives whenever possible
(rather than following the path of least resistance and keep using the
proprietary tool in circumstances where it's not necessary, simply
because you have it setup already), ...


Stefan

Re: Zoom.

[David Wright]

On Mon 19 Oct 2020 at 09:37:01 (+0200), Sven Hartge wrote:
> to...@tuxteam.de wrote:
> > On Sun, Oct 18, 2020 at 05:40:04PM +0200, Sven Hartge wrote:
> >> Stefan Monnier  wrote:
>  
>  Does anyone have Zoom working in Debian 10?
> 
> >>> Don't know, but I use and recommend Jitsi as a Free Software
> >>> alternative.
>  
> >> If The Powers That Be[tm] have decided to use Zoom, then it is
> >> irrelevant that there might be a better (Open Source) alternative.
> 
> > Isn't it funny that we consider ourselves "liberal democracies", but
> > when crossing our $COMPANY's doorstep, we leave our convictions at the
> > wardrobe?
> 
> In an ideal world one could just refuse to do so and quit the job.

Not a hill I'd choose to die on.

> But this isn't an ideal world, is it?

Cheers,
David.

Re: Zoom.

[Thomas Schmitt]

Hi,

tomas wrote:
> Isn't it funny that we consider ourselves "liberal democracies", but
> when crossing our $COMPANY's doorstep, we leave our convictions at the
> wardrobe?

Rental slavery is not in contradiction to the declaration of human rights.
There are some regulations, though:

  
https://en.wikipedia.org/wiki/Labor_rights#International_Labor_Organization_%28ILO%29

I understand that you have the right to have your union protest against
Zoom, but not the right to refuse using it for fulfilling your work duties.


Have a nice day :)

Thomas

Re: Zoom.

[Sven Hartge]

to...@tuxteam.de wrote:
> On Sun, Oct 18, 2020 at 05:40:04PM +0200, Sven Hartge wrote:
>> Stefan Monnier  wrote:
 
 Does anyone have Zoom working in Debian 10?

>>> Don't know, but I use and recommend Jitsi as a Free Software
>>> alternative.
 
>> If The Powers That Be[tm] have decided to use Zoom, then it is
>> irrelevant that there might be a better (Open Source) alternative.

> Isn't it funny that we consider ourselves "liberal democracies", but
> when crossing our $COMPANY's doorstep, we leave our convictions at the
> wardrobe?

In an ideal world one could just refuse to do so and quit the job.

But this isn't an ideal world, is it?

S!

-- 
Sigmentation fault. Core dumped.

Re: Zoom.

[tomas]

On Sun, Oct 18, 2020 at 05:40:04PM +0200, Sven Hartge wrote:
> Stefan Monnier  wrote:
> 
> >> Does anyone have Zoom working in Debian 10?
> 
> > Don't know, but I use and recommend Jitsi as a Free Software
> > alternative.
> 
> If The Powers That Be[tm] have decided to use Zoom, then it is
> irrelevant that there might be a better (Open Source) alternative.

Isn't it funny that we consider ourselves "liberal democracies", but
when crossing our $COMPANY's doorstep, we leave our convictions at
the wardrobe?

;-)

Cheers
 - t


signature.asc
Description: Digital signature

Re: Zoom.

[Sven Hartge]

Stefan Monnier  wrote:

>> Does anyone have Zoom working in Debian 10?

> Don't know, but I use and recommend Jitsi as a Free Software
> alternative.

If The Powers That Be[tm] have decided to use Zoom, then it is
irrelevant that there might be a better (Open Source) alternative.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

Re: Zoom.

[Stefan Monnier]

> Does anyone have Zoom working in Debian 10?

Don't know, but I use and recommend Jitsi as a Free Software alternative.


Stefan

Re: Zoom.

[Tom Dial]

On 10/17/20 17:47, David wrote:
> On Sun, 18 Oct 2020 at 08:03,  wrote:
> 
>> Does anyone have Zoom working in Debian 10?
> 
> Yes. I downloaded
>   zoom_amd64-5.0.413237.0524.deb
> from here
>   https://zoom.us/download?os=linux
> and installed it using apt (to provide dependencies).

Zoom has had security issues in the past and, like all large packages,
will have them in the future. It is updated often (recently, every
couple of weeks or so) and probably should be kept up to date. The
current version as of 17 Oct is 5.3.472687.1012.

I've been running Zoom successfully under Buster since the beginning of
April, through 13 versions beginning with 3.5, with only one issue,
inoperable audio between users of different versions (I think between
3.5 and 5.0). It seems to be generally  stable and well behaved, and
interoperates well between Debian and Ubuntu, Windows, and Mac,
including IPads and IPhones. It has an Android version

It installs easily in /opt/zoom, with a small number of files under
/usr. Its files are owned by root, but has no setuid or setgid files,
and as far as I can tell runs with the UID and GID of whoever starts it.
It creates a number of files under ~/zoom.

I suspect it could be set up and run with an unprivileged owner and
group, but have made no effort to do so. A less intrusive (on the
install process) approach would be to confine it with selinux, something
I ma get to shortly. Apparmor as installed and running by default on
Debian 10 has no apparent problem with it.

Regards,
Tom Dial

> 
> Because zoom is not trusted software, I did this in a separate primary
> partition where I made a clean minimal install of Debian with LXDE,
> used only for zoom.
> 
> That install has no LUKS tools installed. All my other activities on
> that machine are inside a LUKS volume and so are completely
> inaccessible to any local snooping attempts by zoom.
> 

Re: Zoom.

[A_Man_Without_Clue]

On 10/18/20 5:23 AM, pe...@easthope.ca wrote:
> Does anyone have Zoom working in Debian 10?
> 
> Here it produces empty windows.  Visible toward the right in this 
> screenshot.  http://easthope.ca/Zoom.png
> 
> This is the entire output after starting in a terminal and then 
> exiting.
> 
> peter@joule:~$ zoom 
> peter@joule:~$ 
> 
> Thx,   ... P.
> 


Mine is working fine except it pops up occasionally for no reason. Quite
annoying though.

I downloaded from the ZOOM site and just installed.

A man without clue

Re: Zoom.

[riveravaldez]

On 10/17/20, David  wrote:
> On Sun, 18 Oct 2020 at 08:03,  wrote:
>
>> Does anyone have Zoom working in Debian 10?
>
> Yes. I downloaded
>   zoom_amd64-5.0.413237.0524.deb
> from here
>   https://zoom.us/download?os=linux
> and installed it using apt (to provide dependencies).
>
> Because zoom is not trusted software, I did this in a separate primary
> partition where I made a clean minimal install of Debian with LXDE,
> used only for zoom.

I consider this important. Not trusted and not free/open-source -
which ultimately is one and the same thing...

I've been forced to install it in some machines for employers
imposition, and turned to the flatpak-flathub way in order to attain
some level of security through sandbox. It works fine.

Now I ask: is this enough?, anyone have some info about it?

Thanks a lot. Best regards.

Re: Zoom.

[Bob McGowan]

On 10/17/20 1:23 PM, pe...@easthope.ca wrote:

Does anyone have Zoom working in Debian 10?

Here it produces empty windows.  Visible toward the right in this
screenshot.  http://easthope.ca/Zoom.png

This is the entire output after starting in a terminal and then
exiting.

peter@joule:~$ zoom
peter@joule:~$

Thx,   ... P.

When I start Zoom using the command line, I get a single window with 
options to join or start a meeting, schedule a meeting or share screen.  
Plus additional choices, but the point is, I see nothing like what your 
screenshot looks like.


I've seen the browser part only when I click on a link in an email invite.

As for exiting, so long as Zoom considers it a normal exit, it will give 
an exit status of zero and you will simply see the next prompt.  That is 
as expected.


More details on exactly what you are doing and how you are getting your 
environment set up would be helpful.


Bob

Re: Zoom.

[David]

On Sun, 18 Oct 2020 at 08:03,  wrote:

> Does anyone have Zoom working in Debian 10?

Yes. I downloaded
  zoom_amd64-5.0.413237.0524.deb
from here
  https://zoom.us/download?os=linux
and installed it using apt (to provide dependencies).

Because zoom is not trusted software, I did this in a separate primary
partition where I made a clean minimal install of Debian with LXDE,
used only for zoom.

That install has no LUKS tools installed. All my other activities on
that machine are inside a LUKS volume and so are completely
inaccessible to any local snooping attempts by zoom.

Re: Zoom.

[John Conover]

Carl Fink writes:
> On 10/17/20 4:23 PM, pe...@easthope.ca wrote:
> > Does anyone have Zoom working in Debian 10?
> 
> Working fine here. Did you set up the Microsoft repo?
>

Working fine with my wife's Buster; used extensively for months,
(daily,) with no problems.

Installed from zoom_amd64.deb obtained from the Zoom site, with
standard "apt install zoom_amd64.deb".

John

-- 

John Conover, cono...@rahul.net, http://www.johncon.com/

Re: Zoom.

[Carl Fink]

On 10/17/20 4:23 PM, pe...@easthope.ca wrote:

Does anyone have Zoom working in Debian 10?


Working fine here. Did you set up the Microsoft repo?

--
Carl Fink   nitpick...@nitpicking.com

Read my blog at blog.nitpicking.com.  Reviews!  Observations!

Re: Zoom.

[Peter Ehlert]

I have zoom on a couple Debian 10 machines. Both are Mate desktop
Both work as expected.

this one opens the zoom window using $ zoom in a terminal
and by using the Mate launcher (/usr/bin/zoom %U)


On 10/17/20 1:23 PM, pe...@easthope.ca wrote:

Does anyone have Zoom working in Debian 10?

Here it produces empty windows.  Visible toward the right in this
screenshot.  http://easthope.ca/Zoom.png

This is the entire output after starting in a terminal and then
exiting.

peter@joule:~$ zoom
peter@joule:~$

Thx,   ... P.

Re: Zoom.

[Charles Curley]

On Sat, 17 Oct 2020 13:23:02 -0700
pe...@easthope.ca wrote:

> Does anyone have Zoom working in Debian 10?

Yes.

Linux Client Version is 5.0.418682.0603

(You may have to go to the notification tray and shut it down from there.)

--
charles@jhegaala:~$ zoom 
ZoomLauncher started.
Zoom not exist at current directory - /home/charles
Zoom path is: /opt/zoom
cmd line: 
CreateReportChannel bp_server_fd=4
$HOME = /home/charles 
export SSB_HOME=/home/charles/.zoom; export QSG_INFO=1; export 
LD_LIBRARY_PATH=/opt/zoom; export BREAKPAD_CLIENT_FD=3; /opt/zoom/zoom "" 
zoom started.
Client: Breakpad is using Client-Server Mode! client fd = 3
[CZPClientLogMgr::LogClientEnvironment] [MacAddr: 52:54:00:F6:E2:17][client: 
Linux][OS: Debian GNU/Linux 10 (buster)][Hardware: CPU Core:2 Frenquency:2.5 G 
Memory size:7860MB CPU Brand:   Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz 
GPU Brand:][Req ID: ]
Linux Client Version is 5.0.418682.0603
QSG_RENDER_LOOP is 
XDG_CURRENT_DESKTOP = XFCE;   GDMSESSION = lightdm-xsession
Graphics Card Info:: 00:02.0 VGA compatible controller: Intel Corporation 2nd 
Generation Core Processor Family Integrated Graphics Controller (rev 09)
Zoom package arch is 64bit, runing OS arch is x86_64
Error: Send error, 22 Invalid argument
Error: Send error, 22 Invalid argument
Error: Send error, 22 Invalid argument
AppIconMgr::systemDesktopName log Desktop Name: lightdm-xsession 
qt.scenegraph.general: QSG: basic render loop
qt.scenegraph.general: Using sg animation driver
qt.svg: link image0 hasn't been detected!
qt.svg: :/images/wechat.svg:10:6: Could not resolve property: pattern0
qt.scenegraph.general: texture atlas dimensions: 1024x512
qt.scenegraph.general: R/G/B/A Buffers:8 8 8 8
qt.scenegraph.general: Depth Buffer:   24
qt.scenegraph.general: Stencil Buffer: 8
qt.scenegraph.general: Samples:-1
qt.scenegraph.general: GL_VENDOR:  Intel Open Source Technology Center
qt.scenegraph.general: GL_RENDERER:Mesa DRI Intel(R) Sandybridge Mobile 
qt.scenegraph.general: GL_VERSION: 3.0 Mesa 18.3.6
qt.scenegraph.general: GL_EXTENSIONS:  GL_ARB_color_buffer_float 
GL_KHR_context_flush_control GL_EXT_blend_equation_separate 
GL_EXT_packed_depth_stencil GL_INTEL_performance_query GL_EXT_copy_texture 
GL_ARB_compressed_texture_pixel_storage GL_EXT_polygon_offset_clamp 
GL_SGIS_texture_lod GL_ARB_shading_language_100 GL_EXT_timer_query 
GL_ATI_texture_float GL_EXT_texture GL_EXT_texture_rectangle 
GL_APPLE_object_purgeable GL_KHR_no_error GL_EXT_packed_float 
GL_NV_texture_rectangle GL_ARB_fragment_shader GL_ARB_debug_output 
GL_SGIS_texture_edge_clamp GL_ARB_multisample GL_ARB_shader_objects 
GL_3DFX_texture_compression_FXT1 GL_ARB_texture_storage 
GL_SGIS_texture_border_clamp GL_ARB_copy_image GL_ATI_texture_env_combine3 
GL_EXT_pixel_buffer_object GL_EXT_stencil_wrap GL_ARB_texture_gather 
GL_KHR_robustness GL_ARB_pipeline_statistics_query 
GL_ARB_conditional_render_inverted GL_ARB_texture_rgb10_a2ui 
GL_IBM_rasterpos_clip GL_EXT_texture_array GL_ARB_framebuffer_sRGB 
GL_ARB_map_buffer_alig
 nment GL_EXT_texture_edge_clamp GL_EXT_blend_color 
GL_EXT_separate_specular_color GL_EXT_shadow_funcs 
GL_ARB_texture_cube_map_array GL_ARB_program_interface_query GL_KHR_debug 
GL_ARB_clear_buffer_object GL_NV_texgen_reflection GL_NV_texture_barrier 
GL_EXT_framebuffer_multisample GL_ARB_multi_bind 
GL_EXT_shader_framebuffer_fetch_non_coherent GL_S3_s3tc 
GL_NV_conditional_render GL_EXT_texture_integer GL_EXT_subtexture 
GL_EXT_transform_feedback GL_EXT_framebuffer_object GL_MESA_texture_signed_rgba 
GL_ARB_pixel_buffer_object GL_NV_fog_distance GL_EXT_texture_compression_s3tc 
GL_ARB_texture_mirror_clamp_to_edge GL_ARB_texture_filter_anisotropic 
GL_NV_texture_env_combine4 GL_EXT_secondary_color GL_ARB_transpose_matrix 
GL_ARB_texture_border_clamp GL_ARB_texture_mirrored_repeat 
GL_ARB_draw_instanced GL_ARB_explicit_uniform_location GL_ATI_draw_buffers 
GL_EXT_blend_func_separate GL_ARB_draw_elements_base_vertex 
GL_ANGLE_texture_compression_dxt5 GL_ARB_occlusion_query 
GL_ARB_shading_language_
 packing GL_ARB_internalformat_query2 GL_EXT_texture_cube_map 
GL_ARB_map_buffer_range GL_ARB_shading_language_420pack 
GL_EXT_texture_compression_rgtc GL_OES_EGL_image GL_EXT_texture_env_add 
GL_ARB_explicit_attrib_location GL_EXT_vertex_array_bgra 
GL_ARB_uniform_buffer_object GL_SGIS_generate_mipmap GL_ARB_cull_distance 
GL_ARB_seamless_cubemap_per_texture GL_ARB_occlusion_query2 
GL_EXT_point_parameters GL_ARB_clear_texture GL_EXT_abgr 
GL_ARB_framebuffer_object GL_ARB_vertex_shader GL_ARB_sync 
GL_NV_packed_depth_stencil GL_ARB_shadow GL_ARB_polygon_offset_clamp 
GL_EXT_multi_draw_arrays GL_ARB_robustness GL_EXT_texture_sRGB_decode 
GL_KHR_blend_equation_advanced GL_ARB_clip_control GL_ARB_vertex_program 
GL_AMD_seamless_cubemap_per_texture GL_ARB_texture_swizzle 
GL_ARB_texture_env_add GL_ARB_sample_shading GL_ARB_texture_env_

Resolved (at least the sound) Re: Zoom client for Linux (was: Re: Advice on encrypted filesystem)

[rhkramer]

On Thursday, June 25, 2020 10:14:50 AM rhkra...@gmail.com wrote:
> Can you give me any clues about how you told it which audio device to use
> (and which you told it to use)?

Ahh, I found the settings screen and switched the audio (to "Built In Analog 
Audio Stereo") and tested it -- it works.

(I believe there is a test meeting somewhere, I want to try connecting to that 
to make sure things are working, and then I want to change my screen name -- 
I'm guessing I'll figure those out.

Re: Zoom- best practice?

[Ryan Nowakowski]

On Fri, Jun 05, 2020 at 09:28:21AM -0700, Peter Ehlert wrote:
> Family is using Zoom, International.
> They will use Zoom, and I need to participate.
> 
> I use Debian Mate Stable, and Firefox ESR
> 
> I am concerned about security, duh!
> Looking for ideas.
> 
> my current thoughts, in order of preference:
> 
> 2. Sandbox? (but how can I do that?)

You might consider installing zoom as a snap package[1] instead of a deb.
Snaps provide some confinement that, in theory, provide some extra level
of security(harder for zoom to spread files all over your system, etc)

Alternatively, install the zoom deb package in a chroot[2].  I like to
use schroot to help with this kind of thing.

Then create a separate dedicated user just for running zoom.  That will
help limit zoom's access to your normal user's data.

[1] https://snapcraft.io/install/zoom-client/debian
[2] https://wiki.debian.org/chroot

Re: Reply semantics, yet again (was Re: Zoom- best practice?)

[Nicolas George]

[ It comes back to Jitsi and its license after a few paragraphs. And it
is appalling. ]

The Wanderer (12020-06-10):
> What's with the stray 1, here?

We are in 12020 HE = 2020 CE, HE stands for Holocene Era, or possibly
Human Era, it is just shifted by 1 from the Common Era. As a
consequence, all interesting dates are positive, since there was not
much going on earlier than 12000 years ago that would warrant an
accurate date.

https://www.youtube.com/watch?v=czgOWmtGVGs

> Not so much so; when not replying to a message received through a
> mailing list, the button is grayed out and unavailable, because there is
> no address for it to use.
> 
> So still "notice", to some degree, but not "remember", because the
> software handles that for me.

This proves my point: this is bad UI design. Instead of disabling the
button, it should revert to the non-list behavior. That would allow you
to click on it always, without having to take notice.

> Don't get me wrong; my original position on this, which I'd still prefer
> a solution that makes possible, is that the basic Reply function should
> do "smart" detection of the default reply target in all cases. I have
> rants written up about what the logic for determining the default should
> be, and I suspect that you'd agree with their results.

Probably. What I observe is with maling-lists that set the reply-to for
subscribers, I can use the G group-reply command and it does what I want
more than nine times out of ten.

> But I've seen persuasive argument that there's no way to make such
> "smart" reply direction detection smart enough that you don't need to
> override it in some cases, and that the number of different UI

Ah, the classic "we can't make it perfect, let's not make it at all"
fallacy.

> elements which would be needed to for all the different possible
> override types (reply respecting Reply-To, reply to sender, reply to
> list, reply-all, reply to list and sender, reply respecting Reply-To
> except also include list, ...) would very quickly proliferate to the
> point of unwieldiness.

This too is quite a fallacy.

> FWIW, since I wrote that I've looked at things a bit deeper. (Though not
> much.)
> 
> They do, apparently, update the JARs (lib/installer-exclude/) on a
> somewhat regular basis; there is a commit under that directory every few
> months or so, and most of them involve a commit message which looks
> related to updating from upstream.
> 
> The SOs (and DLLs, and .dylib / .jnilib files), on the other hand... the
> most recent log entry for the lib/native/ directory is from 2017, and
> the ones before that quickly go to 2016 and 2015 and on earlier. These
> appear to be mostly put in place and ignored, except when something
> breaks. (On the Linux side, only one of the .so files - libunix-java.so
> - appears to exist in current Debian testing / stable; that does not
> speak well for the possibility of being able to identify the appropriate
> upstreams.)

Oh, thanks for finding these. It is so much worse than I thought. They
are playing fast-and-loose not only with their build process, they are
playing fast-and-loose with the licenses of the dependencies and with
security.

I can even say: they are violating my copyright.

They distribute binaries of projects that are distributed under the
terms of the GPL, but nowhere have I found the corresponding source
code, nor a written offer for it, as specified in article 6 “Conveying
Non-Source Forms” of the GPL.

I will grant you that they do not do so out of nefarious intent, only
negligence. But that negligence shows that they do not understand a
significant part of what Libre Software is about.

And they are shipping a five-years old FFmpeg binary. In the last five
years, a few security-relevant bugs have been fixed in FFmpeg.

People, take notice: this is one of the reasons we insist on proper
packaging and being able to rebuild from source entirely: to allow
security upgrades for the included libraries.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature

Reply semantics, yet again (was Re: Zoom- best practice?)

[The Wanderer]

On 2020-06-10 at 09:27, Nicolas George wrote:

> The Wanderer (12020-06-09):

What's with the stray 1, here?

>> I subscribe to probably dozens of mailing lists, and I don't know
>> of any way to configure things to add that header with a proper
>> value automatically on a per-mailing-list basis. Otherwise, I'd
>> probably have done this years ago, unless other considerations
>> (e.g., UI for when I want to do this vs. when I really do want to
>> reply to the sender or to all recipients) took precedence.
> 
> With Mutt, I use this:
> 
> send-hook ~cdebian-u...@lists.debian.org my_hdr "Reply-To: 
> debian-user@lists.debian.org"
> 
> There is certainly an extension to Mozilla to do the same thing with
> a few dozen clics.

I haven't found one to date, but I'll look again.

>> For myself, I use the "Reply to List" button in (a now-old version
>> of) Thunderbird, and avoid the issue of Reply-To settings entirely
>> unless I actually do want to reply to something other than just the
>> list.
> 
> That means you need to remember and take notice, each time you reply
> to a mail, whether you are replying to a list or not.

Not so much so; when not replying to a message received through a
mailing list, the button is grayed out and unavailable, because there is
no address for it to use.

So still "notice", to some degree, but not "remember", because the
software handles that for me.

> I personally reject any solution with that requirement, since there
> are solutions without.

Don't get me wrong; my original position on this, which I'd still prefer
a solution that makes possible, is that the basic Reply function should
do "smart" detection of the default reply target in all cases. I have
rants written up about what the logic for determining the default should
be, and I suspect that you'd agree with their results.

But I've seen persuasive argument that there's no way to make such
"smart" reply direction detection smart enough that you don't need to
override it in some cases, and that the number of different UI
elements which would be needed to for all the different possible
override types (reply respecting Reply-To, reply to sender, reply to
list, reply-all, reply to list and sender, reply respecting Reply-To
except also include list, ...) would very quickly proliferate to the
point of unwieldiness.

Imperfect though it is, he use of a separate "reply to list" button is
the least problematic option that's close to a general "usable across
all scenarios" solution that I've seen actually get implemented so far.

That said, as I said above, I'll look into the type of hook you
mentioned, and see whether it produces better results for my particular
case and sensibilities.

>> While I wouldn't necessarily take the argument as far as you appear
>> to, I am inclined to agree in principle.
>> 
>> That said, while this is an important aspect of the situation,
>> it's technically a tangent from the question of whether people
>> other than the developers can build the program and have the result
>> be usable. If we assume that the developers don't routinely update
>> or replace these prebuilt objects, and don't hack these objects
>> themselves as part of working on the project, then the tree we have
>> is the tree the developers build from - and if we can build a
>> working program from it, then that narrower question is answered
>> "yes".
> 
> These thoughts caused me to consider an even scarier hypothesis:
> 
> It's entirely possible that the authors of Jitsi themselves would not
> be able to build it from sources.

FWIW, since I wrote that I've looked at things a bit deeper. (Though not
much.)

They do, apparently, update the JARs (lib/installer-exclude/) on a
somewhat regular basis; there is a commit under that directory every few
months or so, and most of them involve a commit message which looks
related to updating from upstream.

The SOs (and DLLs, and .dylib / .jnilib files), on the other hand... the
most recent log entry for the lib/native/ directory is from 2017, and
the ones before that quickly go to 2016 and 2015 and on earlier. These
appear to be mostly put in place and ignored, except when something
breaks. (On the Linux side, only one of the .so files - libunix-java.so
- appears to exist in current Debian testing / stable; that does not
speak well for the possibility of being able to identify the appropriate
upstreams.)

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Zoom- best practice?

[Paul Johnson]

On Wed, Jun 10, 2020 at 8:17 AM Nicolas George  wrote:

> Michael Stone (12020-06-10):
> > Properly configured mailing list software does no such thing, since it's
> a
> > misuse of the reply-to header.
>
> A misuse that works, compared to non-misuses that regularly bring back
> "don't cc me" subthreads. At some points, the religion of "properly"
> using headers need to cede to the pragmatism.
>
> You need to realize that a solution that requires the user to use a
> different key/command if they are replying to a list than if they are
> not is inferior to a solution that works with always the same key.
>
> >A better solution is to use a better
> program
> > to read mail.
>
> You mean I should use Mutt, like you?
>

Or literally any modern mail reader, all of which implement "reply to
list".  It's not like the mailing list isn't publishing list-id headers.

Re: Zoom- best practice?

[Nicolas George]

The Wanderer (12020-06-09):
> I subscribe to probably dozens of mailing lists, and I don't know of any
> way to configure things to add that header with a proper value
> automatically on a per-mailing-list basis. Otherwise, I'd probably have
> done this years ago, unless other considerations (e.g., UI for when I
> want to do this vs. when I really do want to reply to the sender or to
> all recipients) took precedence.

With Mutt, I use this:

send-hook ~cdebian-u...@lists.debian.org my_hdr "Reply-To: 
debian-user@lists.debian.org"

There is certainly an extension to Mozilla to do the same thing with a
few dozen clics.

> For myself, I use the "Reply to List" button in (a now-old version of)
> Thunderbird, and avoid the issue of Reply-To settings entirely unless I
> actually do want to reply to something other than just the list.

That means you need to remember and take notice, each time you reply to
a mail, whether you are replying to a list or not. I personally reject
any solution with that requirement, since there are solutions without.

> While I wouldn't necessarily take the argument as far as you appear to,
> I am inclined to agree in principle.
> 
> That said, while this is an important aspect of the situation, it's
> technically a tangent from the question of whether people other than the
> developers can build the program and have the result be usable. If we
> assume that the developers don't routinely update or replace these
> prebuilt objects, and don't hack these objects themselves as part of
> working on the project, then the tree we have is the tree the developers
> build from - and if we can build a working program from it, then that
> narrower question is answered "yes".

These thoughts caused me to consider an even scarier hypothesis:

It's entirely possible that the authors of Jitsi themselves would not be
able to build it from sources.

> I just don't care to bother with doing that myself at present. Which, to
> an extent, turns things back to Tomas' point.

Tomas's point is "give the benefit of the doubt", but at this point
there is not much doubt left.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature

Re: Zoom- best practice?

[Michael Stone]

On Wed, Jun 10, 2020 at 03:17:34PM +0200, Nicolas George wrote:

Michael Stone (12020-06-10):

Properly configured mailing list software does no such thing, since it's a
misuse of the reply-to header.


A misuse that works, 


Except for the things that it breaks, and the cases for which it doesn't 
work. So, no.

Re: Zoom- best practice?

[Nicolas George]

Michael Stone (12020-06-10):
> Properly configured mailing list software does no such thing, since it's a
> misuse of the reply-to header.

A misuse that works, compared to non-misuses that regularly bring back
"don't cc me" subthreads. At some points, the religion of "properly"
using headers need to cede to the pragmatism.

You need to realize that a solution that requires the user to use a
different key/command if they are replying to a list than if they are
not is inferior to a solution that works with always the same key.

>A better solution is to use a better program
> to read mail.

You mean I should use Mutt, like you?

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature

Re: Zoom- best practice?

[Michael Stone]

On Tue, Jun 09, 2020 at 12:51:00PM +0200, Nicolas George wrote:

Instead of writing this periodically, you could include:
Reply-To: debian-user@lists.debian.org
in your headers just like I did. Properly configured mailing-list
software does it by default for subscribed users, but Debian is an
exception. It fixes the issue of annoying ccs once and for all.


Properly configured mailing list software does no such thing, since it's 
a misuse of the reply-to header. A better solution is to use a better 
program to read mail.

Re: Zoom- best practice?

[Peter Ehlert]

Original post: family is using Zoom.
No alternative for me to participate... Zoom or nothing.
Thanks for the suggestion.
Peter Ehlert
On June 9, 2020 10:56:10 AM Alberto Sentieri <2...@tripolho.com> wrote:


This is a long thread. I did not read it all. Did anyone suggest
http://meet.google.com?

Re: Zoom- best practice?

[Alberto Sentieri]

This is a long thread. I did not read it all. Did anyone suggest 
http://meet.google.com?

Re: Zoom- best practice?

[rhkramer]

On Tuesday, June 09, 2020 05:45:24 AM Nicolas George wrote:
> to...@tuxteam.de (12020-06-09):
> > Can we stop that already? Nobody proved you can't build Jitsi or
> > BBB from source. Everyone here is just too friggin' lazy to even
> > try.
> > 
> > Can we give 'em the benefit of the doubt until someone really makes
> > his hands ditry on that?
> 
> You can be naïve and give them the benefit of the doubt. But I will not.


> Jitsi is a big project, it claims the reputation benefits of being Libre
> Software: the onus of proof is on it.

+1

If a project is new, I'm willing to give a project the benefit of the doubt on 
the assumption that it is a statement of intent, and, as they recognize 
shortcomings, they will fix them.  


> I will state and repeat: until we see actual reliable proof, claiming
> that Jitsi is Libre Software is wrong.
> 
> > That's how fake news spread, btw.
> > 
> > I think it's somewhat disgusting. Folks, put up... or shut up now.
> 
> Your attempt at irrational shaming is dishonest.
> 
> Regards,

Re: Zoom- best practice?

[tomas]

On Tue, Jun 09, 2020 at 06:41:33AM -0400, The Wanderer wrote:
> (Please stop CCing me on replies [...]

Sorry.

[...]

> FWIW, I have tried, at least in part.

Thanks for taking the time to do, and thanks for reporting back.

[...]

> Even a successful build from a repository like that would not
> demonstrate that you can actually completely rebuild the project from
> scratch [...]

Yes, this is a well-known problem with many facets.

ISTR that there was a Lisp which only could build itself: the
whole buildery (which, this being Lisp included everything,
compiler, assembler and all) was written in Lisp, and took
advantage of newer and newer features. A full bootstrap involved
unearthing "old versions" and following the historical evolution
of that thing.

Some "ecosystems", like Java, tend to build up a huge network
of dependencies on "well-known" components -- something I used
to call it the "Java Disease". Until Javascript came with npm,
or PHP with composer. It can get worse.

Building something significant, like Jitsi, lands you in this
hell, and to survive, you end up ingesting those dependencies
(that's what is called "vendoring" -- imo the Euphemism of the
Decennium).

On the other end there are heroes, like the Guix folks [1],
or the reproducible build folks [2] working relentlessly on
disentangling those things. Debian packaging belongs into that
class of heroism.

So from my POV there is a lot to critizice there, and a lot
to fix -- but "this is not free software just because I'm too
lazy to check thoroughly", as some have basically said here
is simply unfair -- and counterproductive.

Cheers

[1] https://guix.gnu.org/
[2] https://reproducible-builds.org/

-- tomás


signature.asc
Description: Digital signature

Re: Zoom- best practice?

[The Wanderer]

On 2020-06-09 at 06:51, Nicolas George wrote:

> The Wanderer (12020-06-09):
> 
>> (Please stop CCing me on replies - especially to messages which I
>> did not actually send - unless you're specifically trying to draw
>> my attention to a particular message and think I may not notice it
>> without the CC. Not only am I subscribed, I am in fact reading this
>> thread on a multiple-times-a-day basis, as my multiple replies to
>> it to date may have indicated.)
> 
> Instead of writing this periodically, you could include:
> Reply-To: debian-user@lists.debian.org
> in your headers just like I did.

Having to add that by hand to every single reply I make would be much
more of a hassle than taking the time to request this explicitly on the
relatively few occasions when people send such CCs with enough frequency
for it to be a bother to me.

> Properly configured mailing-list software does it by default for
> subscribed users, but Debian is an exception. It fixes the issue of
> annoying ccs once and for all.

I subscribe to probably dozens of mailing lists, and I don't know of any
way to configure things to add that header with a proper value
automatically on a per-mailing-list basis. Otherwise, I'd probably have
done this years ago, unless other considerations (e.g., UI for when I
want to do this vs. when I really do want to reply to the sender or to
all recipients) took precedence.

For myself, I use the "Reply to List" button in (a now-old version of)
Thunderbird, and avoid the issue of Reply-To settings entirely unless I
actually do want to reply to something other than just the list.

>> FWIW, I have tried, at least in part.
>> 
>> For the individual broken-out projects (which may or may not be
>> rolled up into the larger "master" project, I can't easily tell), I
>> succeeded with one, and failed with another, but suspect that I
>> could succeed with the latter with more effort.
>> 
>> For the apparent "master" project, I admit that I didn't bother to
>> try, because of the exact "too many prebuilt apparent-dependency
>> objects with no apparent way provided to rebuild them" issue;
>> unless we can rebuild those objects, not only can we not be sure we
>> have the source for them, we can't be sure that building with a
>> different version of that object will even work.
>> 
>> Even a successful build from a repository like that would not 
>> demonstrate that you can actually completely rebuild the project
>> from scratch; you'd have to actually track down the source for all
>> of those individual prebuilt objects, rebuild each one, and pull
>> the result in to the build in a way which will get picked up, and
>> that's more effort than I'm willing to put in for the sake of a
>> mailing-list discussion like this one.
> 
> Thank you for these clarifications.
> 
>> I don't fault the developers too much for providing a version of
>> the project tree with prebuilt dependencies like that; it's a
>> useful convenience for those who just want to get it to work and
>> for whom farting around with trying to find the right dependencies
>> and get them into place would be too much of a hassle. But for (as
>> far as I can tell) providing the tree in *only* that form, and not
>> providing (as far as I've found) *any* documentation on what these
>> prebuilt objects are and why they're needed and how to get them
>> separately and build them and so forth, there I do fault them, and
>> consider that a ding against proper Free status.
> 
> I state it that way: the knowledge of how to obtain and build these 
> objects is part of the source code of the project, just as much as a 
> makefile or configure script. Unfortunately, that bit of source code 
> only resides in the head of the developers, it is not distributed.
> 
> Consider a minified javascript program with a GPL license header
> slapped on top of it: should we consider it Libre Software? Of course
> not. The same happens here: out of negligence probably, the authors
> keep part of the source code for themselves. It is not Libre
> Software.

While I wouldn't necessarily take the argument as far as you appear to,
I am inclined to agree in principle.

That said, while this is an important aspect of the situation, it's
technically a tangent from the question of whether people other than the
developers can build the program and have the result be usable. If we
assume that the developers don't routinely update or replace these
prebuilt objects, and don't hack these objects themselves as part of
working on the project, then the tree we have is the tree the developers
build from - and if we can build a working program from it, then that
narrower question is answered "yes".

I just don't care to bother with doing that myself at present. Which, to
an extent, turns things back to Tomas' point.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable

Re: Zoom- best practice?

[Nicolas George]

The Wanderer (12020-06-09):
> (Please stop CCing me on replies - especially to messages which I did
> not actually send - unless you're specifically trying to draw my
> attention to a particular message and think I may not notice it without
> the CC. Not only am I subscribed, I am in fact reading this thread on a
> multiple-times-a-day basis, as my multiple replies to it to date may
> have indicated.)

Instead of writing this periodically, you could include:
Reply-To: debian-user@lists.debian.org
in your headers just like I did. Properly configured mailing-list
software does it by default for subscribed users, but Debian is an
exception. It fixes the issue of annoying ccs once and for all.

> FWIW, I have tried, at least in part.
> 
> For the individual broken-out projects (which may or may not be rolled
> up into the larger "master" project, I can't easily tell), I succeeded
> with one, and failed with another, but suspect that I could succeed with
> the latter with more effort.
> 
> For the apparent "master" project, I admit that I didn't bother to try,
> because of the exact "too many prebuilt apparent-dependency objects with
> no apparent way provided to rebuild them" issue; unless we can rebuild
> those objects, not only can we not be sure we have the source for them,
> we can't be sure that building with a different version of that object
> will even work.
> 
> Even a successful build from a repository like that would not
> demonstrate that you can actually completely rebuild the project from
> scratch; you'd have to actually track down the source for all of those
> individual prebuilt objects, rebuild each one, and pull the result in to
> the build in a way which will get picked up, and that's more effort than
> I'm willing to put in for the sake of a mailing-list discussion like
> this one.

Thank you for these clarifications.

> I don't fault the developers too much for providing a version of the
> project tree with prebuilt dependencies like that; it's a useful
> convenience for those who just want to get it to work and for whom
> farting around with trying to find the right dependencies and get them
> into place would be too much of a hassle. But for (as far as I can tell)
> providing the tree in *only* that form, and not providing (as far as
> I've found) *any* documentation on what these prebuilt objects are and
> why they're needed and how to get them separately and build them and so
> forth, there I do fault them, and consider that a ding against proper
> Free status.

I state it that way: the knowledge of how to obtain and build these
objects is part of the source code of the project, just as much as a
makefile or configure script. Unfortunately, that bit of source code
only resides in the head of the developers, it is not distributed.

Consider a minified javascript program with a GPL license header slapped
on top of it: should we consider it Libre Software? Of course not. The
same happens here: out of negligence probably, the authors keep part of
the source code for themselves. It is not Libre Software.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature

Re: Zoom- best practice?

[The Wanderer]

(Please stop CCing me on replies - especially to messages which I did
not actually send - unless you're specifically trying to draw my
attention to a particular message and think I may not notice it without
the CC. Not only am I subscribed, I am in fact reading this thread on a
multiple-times-a-day basis, as my multiple replies to it to date may
have indicated.)

On 2020-06-09 at 04:42, to...@tuxteam.de wrote:

> On Mon, Jun 08, 2020 at 02:59:13PM -0600, Tom Dial wrote:

>> If you cannot build an executable from source, you do not know
>> whether the binary you downloaded represents the source
>> faithfully.
> 
> Can we stop that already? Nobody proved you can't build Jitsi or BBB
> from source. Everyone here is just too friggin' lazy to even try.
> 
> Can we give 'em the benefit of the doubt until someone really makes 
> his hands ditry on that?

FWIW, I have tried, at least in part.

For the individual broken-out projects (which may or may not be rolled
up into the larger "master" project, I can't easily tell), I succeeded
with one, and failed with another, but suspect that I could succeed with
the latter with more effort.

For the apparent "master" project, I admit that I didn't bother to try,
because of the exact "too many prebuilt apparent-dependency objects with
no apparent way provided to rebuild them" issue; unless we can rebuild
those objects, not only can we not be sure we have the source for them,
we can't be sure that building with a different version of that object
will even work.

Even a successful build from a repository like that would not
demonstrate that you can actually completely rebuild the project from
scratch; you'd have to actually track down the source for all of those
individual prebuilt objects, rebuild each one, and pull the result in to
the build in a way which will get picked up, and that's more effort than
I'm willing to put in for the sake of a mailing-list discussion like
this one.

I don't fault the developers too much for providing a version of the
project tree with prebuilt dependencies like that; it's a useful
convenience for those who just want to get it to work and for whom
farting around with trying to find the right dependencies and get them
into place would be too much of a hassle. But for (as far as I can tell)
providing the tree in *only* that form, and not providing (as far as
I've found) *any* documentation on what these prebuilt objects are and
why they're needed and how to get them separately and build them and so
forth, there I do fault them, and consider that a ding against proper
Free status.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Zoom- best practice?

[Nicolas George]

to...@tuxteam.de (12020-06-09):
> Can we stop that already? Nobody proved you can't build Jitsi or
> BBB from source. Everyone here is just too friggin' lazy to even
> try.
> 
> Can we give 'em the benefit of the doubt until someone really makes
> his hands ditry on that?

You can be naïve and give them the benefit of the doubt. But I will not.
Jitsi is a big project, it claims the reputation benefits of being Libre
Software: the onus of proof is on it.

I will state and repeat: until we see actual reliable proof, claiming
that Jitsi is Libre Software is wrong.

> That's how fake news spread, btw.
> 
> I think it's somewhat disgusting. Folks, put up... or shut up now.

Your attempt at irrational shaming is dishonest.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature