Re: running cronjob output
On Wed 21 Apr 2021 at 00:37:25 (+), brainf...@posteo.net wrote: > On 2021-04-20 12:14 PM, l0f...@tuta.io wrote: > > > On Tue, Apr 20, 2021 at 12:54:06PM +, brainf...@posteo.net wrote: > > > > > > > when i run a cronjob the output from the job is stored and > > > > mailed when the > > > > job finishes. where is this output stored? can i read it > > > > while the job is > > > > running? > > > > > > Is your question global or specific? > > for any cronjob Almost the entire answer is given at: https://unix.stackexchange.com/questions/40623/where-does-the-output-of-at-and-cron-jobs-go ie find the PID of your long-running cron job: it should be a child of the daemon and the parent of your program. When you: # ls -l /proc//fd/ you should see one output file descriptor pointing to a (deleted) file. So the answer to the last question is: # cp -Lip /proc/16098/fd/6 /tmp/proc16098fd6.txt for example, where 16098 is the cron job, 6 is the name of the symlink pointing to a (deleted) file, and -L makes copy follow the symlink. This method has the advantage that it can be used after the cron job has already started, but I would use the "tee" method, previously described in this thread, if you think you might want to examine the output while you're still preparing your crontab file for installation. Cheers, David.
Re: Any Debian BPMN editor (or a converter)?
Markos wrote: > Hi, > > I'm working with a group that is developing process diagrams in BPMN > format using the Bizagi tool (www.bizagi.com/en). > > Everyone is using Windows but I use Linux (Debian 9.4). > Everyone is using Windows but you are using old Debian :) > But there is no version of Bizagi for Linux. > > I tried to install and use many Open Source alternatives for Linux: > Did you see Eclipse - it has BPMN module, although IMO not as good as the pro stuff but very close to it. Eclipse is very powerful tool - but is complex and takes time to setup and learn - be patient and make backups of the installation directory before doing changes.
Re: Any Debian BPMN editor (or a converter)?
Hello, Disclaimer: I did not even now before your post what BPMN stands for... there is a comparison of BPMN sotfware on Wikipedia: https://en.wikipedia.org/wiki/Comparison_of_Business_Process_Model_and_Notation_modeling_tools Among these solutions I would take a look at Flowable (free license, relatively clear presentation for a newbie): https://blog.flowable.org/2020/10/07/flowable-6-instant-gratification/
Re: Zoom.
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. > > >
Any Debian BPMN editor (or a converter)?
Hi, I'm working with a group that is developing process diagrams in BPMN format using the Bizagi tool (www.bizagi.com/en). Everyone is using Windows but I use Linux (Debian 9.4). But there is no version of Bizagi for Linux. I tried to install and use many Open Source alternatives for Linux: Modelio jBPM Edrawmax Camunda Bonita Yaoqiang Some tools I was unable to install and others are too complex to use. I don't want to spend more time to learn how to use the tool than to do the work I need. I used Yaoqiang but the generated bpmn file gives an error to open in Bizagi. Any suggetion about an alternative of editor or a converter that converts a file in the format, for example svg (or any other), to bpmn? Thank you, Markos
Re: Strange emacs behavior after upgrade to bullseye
On Tue 20 Apr 2021 at 20:43:46 (+0200), Rainer Dorsch wrote: > Am Dienstag, 20. April 2021, 17:08:57 CEST schrieb Stefan Monnier: > > > Because the error says it cannot use LOCKS. > > > Because you can't do Unix file locking on a non-Unix file system. > > > The error does NOT say "Permission denied". > > > > FWIW, the error comes from Emacs's own locking code which doesn't seem > > to use unix file locking, so the problem comes from elsewhere. > > > > Emacs implements its locking protocol using symlinks with names > > that look like `.#` and whose content looks like > > `u...@host.pid:BOOT_TIME`. > > many thanks for that excellent diagnosis, that really helped to trace it down: > > - indeed vboxsf does not support symlinks (at least if ntfs is shared). But > instead of the symlinks there were real files. I assume a prior version of > emacs created them and used this as backup if the symlinks did not work on a > filesystem My comments are only on buster. I don't use vboxsf. On a vfat USB stick, emacs can create locks and autosave files as usual, where the lock, .#filename, is a file containing the target of what would normally be a symlink. (BTW I'd avoid using the term "backup", and say instead, perhaps, "alternative method".) > - These files had permission 555 instead of 777. Changing this back (?) to > 777 > resolved the problem. Write-protecting the contents of lockfiles seems reasonable in that their username, hostname, PID, and process start time are invariant. However, I've been testing on a single system with a vfat filesystem, mounted so as to give 777 permissions (to test sharing), and haven't observed them being set that way, or changing. I have no idea what the role of vboxsf/Windows/NTFS would be, or would have been at the time (2019, you say) these files were created. > How that happened I cannot tell. I do not even understand what these > permissions mean on vboxsf, apparently they do at least something. > > Maybe one explanation model: > > -> I noticed that the timestamp of the .# lock files were super old (2019) on > the vboxsf file system even for files which I touched many times with emacs > since then > -> I noticed that if I edit these files with emacs the .# lock files are not > created anymore on the vboxsf filesystem by bullseye's emacs, but they get > removed if I close bullseye's emacs > > So I speculate > > -> stretch emacs used .# files instead of .# symlinks, if the file system did > not support symlinks. The content of the file contains the information which > is > otherwise encoded in the symlink target I don't think this is contentious. > -> buster emacs did not care at all about .# on filesystems which do not > support symlinks. Somehow the permissions changed while the system was on > buster, possibly by virtualbox or by me myself in an accidential or intended > chmod -R a-w or something similar. I noticed the error but reverted it only > for the visible files. But since buster emacs did not care nobody noticed. I can't reproduce that. I get locks (that are files) and autosave files, both these being listed in the usual manner in each user's own respective ~/.emacs.d/.saves--~ files. However, AIUI locks only get created by the user who owns the directory (I assume), and not by others. In your case, the owner was root, and you were not running emacs as root. Also bear in mind that locks aren't created until a need arises. Opening a file in emacs is not enough: you have to modify the buffer. Upon attempting to save a file being edited by several users, I get the expected response with the user@host and PID of any valid lock. I also observe the use of ~/.emacs.d/%backup%~ when an instance won't overwrite the normal backup file, filename~, which it realises it didn't write itself, perhaps. > -> bullseye emacs not does not create the .# files on file systems, if they > don't have symlink support. But it finds them and puts the file in read-only > mode, if it is there. In addition, it tries to cleanup and delete these > files, > which failed due to the wrong permission. > > Even on a file system which supports symlinks, the problem can be easily > reproduced by > > rd@h370:~$ touch test.txt > rd@h370:~$ touch .#test.txt > rd@h370:~$ chmod a-w .#test.txt > rd@h370:~$ emacs test.txt > > What is somewhat ugly is that after toggling read-only mode and editing the > file, I cannot leave emacs anymore, it hangs. > > I am undecided if that is a bug and I should report it or a real corner case > which is not worth to invest more time. When I start (buster) emacs with a fake, empty lock(file), even one that I own like the above, it's not refreshed, but merely ignored. Nor is the fake lock removed when emacs exits. I would assume that a lock only works if the information it holds is valid, as far as can be determined. I haven't bothered to check what happens with manifestly stale locks (ie holding verifiable information). I don't know how
Re: Zoom.
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.
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.
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.
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.
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
bullseye upgrade report
New desktop: AMD Ryzen 5 3600 16GB RAM 1 TB NVMe SSD (Crucial P5) MSI B550M PRO-VDH WIFI (MS-7C95) motherboard RX460 video card Installed from USB stick with latest Buster installer image; tasksel only ssh-server above the base image. After first boot, changed source to bullseye and did a dist-upgrade. No issues. Working as expected: CM Storm keyboard Logitech M510 trackball (USB unifying receiver) Blue Yeti USB microphone Logitech C920 webcam Realtek ALC1220 analog audio output Realtek gigabit NIC -dsr-
Re: Zoom.
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.
Zoom.
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. -- VoIP: +1 604 670 0140Bcc: peter at easthope. ca
