Aw: Re: Do we need the Python interface of ghmm

[Steffen Möller]

Hi Andreas,
it will be best to remove it, I suggest. I do not have any personal contact to 
upstream, somehwat unfortunate since this looks very nice and educational, but 
... unless someone enjoys such a transition, I suggest to just wait for a 
version 0.10.
Best,
Steffen

> Gesendet: Mittwoch, 07. Februar 2024 um 14:02 Uhr
> Von: "Andreas Tille" 
> An: "Debian Med Project List" 
> Cc: "Steffen Möller" 
> Betreff: Re: Do we need the Python interface of ghmm
>
> Hi again,
> 
> if there is no response of kind "Yes, please try to keep the Python
> interface of ghmm" it will be removed soon.
> 
> Kind regards
>Andreas.
> 
> Am Tue, Jan 30, 2024 at 07:58:34AM +0100 schrieb Andreas Tille:
> > Hi Steffen (and two whom it might concern),
> > 
> > when Israel has written the autopkgtest for ghmm it turned
> > out that there are several issues with the Python3 interface.
> > In Matrix Nilesh raised the perfectly valid question:
> > 
> >The py interface is living off a patch from py2to3 and is (very)
> >broken. It needs quite a lot of patching. Maybe it's a sensible thing to
> >evaluate if we even need it?
> > 
> > Could you please state your opinion about this?
> > 
> > We should respond in a timely manner to the atlas removal
> > effort (patch in Git) and currently it is blocked by the
> > test suite issue of the Python3 interface.
> > 
> > Kind regards
> >Andreas.
> > 
> > -- 
> > http://fam-tille.de
> > 
> > 
> 
> -- 
> http://fam-tille.de
>

Re: [Emc-developers] Also prepared a Hugging Face LinuxCNC assistant. Re: LinuxCNC-aware chat bot

[Steffen Möller via Emc-developers]

> Gesendet: Mittwoch, 07. Februar 2024 um 10:50 Uhr
> Von: "Rod Webster" 
> An: "EMC developers" 
> Betreff: Re: [Emc-developers] Also prepared a Hugging Face LinuxCNC 
> assistant. Aw: Re: LinuxCNC-aware chat bot
>
> It lied a lot when I asked
> 
> build me a hal file for a 3 axis milling machine that uses a mesa card
> 

Below I put what chatGPT came up with - if not good enough then maybe we should 
help the documentation a bit more? Hugging Face was not explicitly pointed to 
our documentation (did not know how to do that).
Best,
Steffen

ChatGPT 4 (LinuxCNC Assistant):
Creating a HAL (Hardware Abstraction Layer) file for a 3-axis milling machine 
that uses a Mesa card involves defining how LinuxCNC communicates with your 
hardware components, such as motors, encoders, and the Mesa card itself. The 
specific Mesa card model (e.g., 7i76e, 5i25, etc.) significantly influences the 
HAL file configuration due to differing capabilities and connection methods. 
Below, I'll provide a basic template for a 3-axis milling machine using a 
generic Mesa Ethernet card (e.g., 7i76e) as an example. This should serve as a 
starting point, which you can then customize based on your specific hardware 
setup and requirements.

Before proceeding, ensure you've installed and configured LinuxCNC and have the 
necessary information about your Mesa card, including its model and IP address 
(if using an Ethernet card). The Mesa card should also be configured correctly, 
following the Mesa documentation.

### Basic HAL File Template for a 3-Axis Mill with a Mesa Card

```hal
# Load the required modules for a Mesa card
loadrt hm2_eth board_ip="192.168.1.121" # Replace with your Mesa card IP address
loadrt [KINS]KINEMATICS
loadrt stepgen step_type=0,0,0

# Load the hardware driver for the Mesa card
loadrt hostmot2

# Associate the Mesa card configuration
loadrt hm2_eth config="num_stepgens=3 num_encoders=3 sserial_port_0=000xxx"

# Define step generator for each axis
net x-step <= hm2_7i76e.0.stepgen.00.step
net x-dir <= hm2_7i76e.0.stepgen.00.dir
net y-step <= hm2_7i76e.0.stepgen.01.step
net y-dir <= hm2_7i76e.0.stepgen.01.dir
net z-step <= hm2_7i76e.0.stepgen.02.step
net z-dir <= hm2_7i76e.0.stepgen.02.dir

# Connect the step generator to the LinuxCNC motion component
net x-pos-cmd joint.0.motor-pos-cmd => hm2_7i76e.0.stepgen.00.position-cmd
net y-pos-cmd joint.1.motor-pos-cmd => hm2_7i76e.0.stepgen.01.position-cmd
net z-pos-cmd joint.2.motor-pos-cmd => hm2_7i76e.0.stepgen.02.position-cmd

net x-vel-cmd joint.0.vel-cmd => hm2_7i76e.0.stepgen.00.velocity-cmd
net y-vel-cmd joint.1.vel-cmd => hm2_7i76e.0.stepgen.01.velocity-cmd
net z-vel-cmd joint.2.vel-cmd => hm2_7i76e.0.stepgen.02.velocity-cmd

net x-enable joint.0.amp-enable-out => hm2_7i76e.0.stepgen.00.enable
net y-enable joint.1.amp-enable-out => hm2_7i76e.0.stepgen.01.enable
net z-enable joint.2.amp-enable-out => hm2_7i76e.0.stepgen.02.enable

# Define feedback for each axis (if encoders are used)
# net x-encoder-pos <= hm2_7i76e.0.encoder.00.position
# net y-encoder-pos <= hm2_7i76e.0.encoder.01.position
# net z-encoder-pos <= hm2_7i76e.0.encoder.02.position

# Feedback to LinuxCNC
# net x-pos-fb hm2_7i76e.0.encoder.00.position => joint.0.pos-fb
# net y-pos-fb hm2_7i76e.0.encoder.01.position => joint.1.pos-fb
# net z-pos-fb hm2_7i76e.0.encoder.02.position => joint.2.pos-fb

# Estop and machine enable chains
net estop-in <= hm2_7i76e.0.gpio.00.in_not
net estop-out => hm2_7i76e.0.watchdog.timeout
net machine-enable <= iocontrol.0.machine-enable => hm2_7i76e.0.watchdog.enable

# Make sure to add additional configuration as needed for your specific setup,
# such as spindle control, coolant control, additional axes, or other I/O.
```

This template provides a basic structure. You'll need to adjust it to fit your 
specific Mesa card model and setup, especially the `loadrt hm2_eth config` 
line, which depends on the capabilities of your Mesa card and the exact 
hardware you're interfacing with. Also, uncomment and configure the encoder 
sections if your machine uses encoders for feedback.

For detailed customization, consult the LinuxCNC documentation, the Mesa card 
manual for your specific model, and possibly the LinuxCNC forums for community 
support.



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] Also prepared a Hugging Face LinuxCNC assistant. Aw: Re: LinuxCNC-aware chat bot

[Steffen Möller via Emc-developers]

Hello again,

The chatGPT Open Source competitor "Hugging Face" now also came up with custom 
chat bots, calling them "Assistants". You cannot upload your own data, yet, but 
you can instruct the behaviour for the bot. You find the result publicly 
accessible on

https://hf.co/chat/assistant/65c27657be7d1bc1ec217560

The instruction I gave was: You will act as a an expert in CNC machining who 
helps new users to get their mill or lathe controlled by LinuxCNC.

That is all I did. And this works just very well. Have not tested if the 
regular version is any better or worse, would expect that regular one to 
perform just as well. I is just - very good, I tend to think.

Have fun!
Steffen


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] LinuxCNC-aware chat bot

[Steffen Möller via Emc-developers]

> Gesendet: Samstag, 03. Februar 2024 um 01:29 Uhr
> Von: "Jacob Rush" 

> I wonder what would happen if you added the source code.

Hi Jacob,
I added all in src that ends with .comp or .hal. This is what now happened. I 
was a bit surprise by the emphasis on Python.
Best,
Steffen

User
Can you give an example program for HAL that I can use without hardware 
attached to my computer?
GPT
Certainly! A simple HAL (Hardware Abstraction Layer) example in LinuxCNC 
doesn't necessarily need to interact with actual hardware. Instead, it can 
simulate a scenario or handle software-only interactions. Here's a basic 
example that demonstrates creating a HAL component in Python that toggles a 
signal back and forth, simulating a simple digital input/output scenario 
without requiring any physical hardware.

This example uses a Python HAL component (toggle.py) that creates a HAL pin and 
toggles its value between true (1) and false (0) every second. This could 
simulate, for example, a sensor being activated and deactivated.

Step 1: Create the Python HAL Component (toggle.py)
First, create a Python file named toggle.py with the following content:

python
Copy code
import hal, time

# Create a new HAL component named "toggle"
h = hal.component("toggle")
# Add a pin named "signal" of type bit (boolean) that is an output
h.newpin("signal", hal.HAL_BIT, hal.HAL_OUT)

# Initialize the component
h.ready()

try:
# Main loop to toggle the signal
while True:
# Toggle the signal pin
h['signal'] = not h['signal']
# Print the current state to the console (optional)
print("Signal is now", h['signal'])
# Wait for 1 second before toggling again
time.sleep(1)
except KeyboardInterrupt:
# Handle the user pressing CTRL+C gracefully
print("Exiting toggle.py")
Step 2: Load the Component into LinuxCNC
You will need to integrate this Python component into your LinuxCNC 
configuration. Assuming you're running LinuxCNC in a simulated environment (no 
actual hardware), you can add the component to your HAL file typically 
associated with your LinuxCNC configuration.

Edit Your HAL File: Open the HAL file you're using with your LinuxCNC 
configuration, often found in your LinuxCNC configuration directory 
(your_config_name.hal).

Load the Python Component: Add the following line to load the toggle.py script 
as a HAL component:

Copy code
loadusr -W python toggle.py
This command assumes toggle.py is in the same directory as your HAL file or in 
a location that's in your system's PATH. The -W option waits for the script to 
initialize before proceeding.

Run LinuxCNC: Start your LinuxCNC configuration as you normally would. You 
should see messages printed to the terminal showing the signal pin being 
toggled between 1 and 0 every second.

Conclusion
This example demonstrates a basic use of HAL in LinuxCNC to simulate a digital 
input/output without actual hardware. It's a starting point for more complex 
interactions where you can simulate signals and behaviors before integrating 
real hardware components.

User
How would you describe that logic of toggle.py in HAL directly, i.e. without 
falling back to Python?
GPT
Describing the logic of toggle.py (a Python script that toggles a signal every 
second) directly in HAL without using Python involves creating a HAL component 
that utilizes existing functionalities within LinuxCNC to achieve the toggle 
effect. In HAL, there isn't a direct method to create timed loops as in Python; 
however, you can achieve a similar outcome by using a combination of HAL 
components that are provided by LinuxCNC, such as a signal generator and a 
bit-wise XOR gate.

Here is a conceptual approach to replicate the toggling behavior:

Step 1: Generate a Periodic Signal
First, you would need a signal that changes state periodically. LinuxCNC's hal 
library includes a siggen component that can generate a square wave, which 
alternates between high and low states at a defined frequency.

shell
Copy code
loadrt siggen # Load the signal generator component
addf siggen.0 servo-thread # Attach it to a servo thread for periodic updates
Step 2: Configure the Signal Generator
Configure the siggen to generate a square wave with a period of 2 seconds (0.5 
Hz frequency) so that the signal toggles every second. The siggen component 
outputs a float, but for a toggle, you only need a high (1) or low (0) signal. 
Therefore, the setup might need an additional step to convert this to a bit.

shell
Copy code
setp siggen.0.square 0.5 # Set the frequency for a square wave
Since siggen outputs float values, and direct conversion to a binary signal 
(bit) for toggling isn't straightforward without a custom component or Python, 
this approach illustrates the conceptual setup. In actual HAL usage, especially 
for binary toggling, a Python script or a custom C component is often more 
practical.

Step 3: Additional Steps for Binary Toggling
To convert the siggen output to a 

[Emc-developers] LinuxCNC-aware chat bot

[Steffen Möller via Emc-developers]

Hello,

I created a GPT as an extension of chatGPT 4 that users of chatGPT 4 (it still 
costs a bit) can give a try at 
https://chat.openai.com/g/g-vfeQnX43z-linuxcnc-assistant
If you know of documents that I should add - please tell me. So far I only 
added HTML-translated pages of our documentation.

I am not ultimately sure why I did this. I think I wanted to have someone 
"local" to help me get my mill running. And questions that cannot be answered 
by that GPT may be a motivation to extend our documentation for.

The extra documentation seems to make a small difference, though version 4 is 
impressive alone already. For instance, G-code is no longer listed as a means 
to configure LinuxCNC. I think this is correct.

Feel free to send me questions to that chat bot you want me to ask if you do 
not have direct access to it. Once we have something like this implemented on a 
Free Software, should we have some bot like this on IRC/our home page?

Best,
Steffen


Me:
How is the language called that is used to configure LinuxCNC?

GPT 3.5:
The language used to configure LinuxCNC is called "G-code." G-code is a 
standardized language used in the CNC (Computer Numerical Control) industry to 
control machine tools and 3D printers. It consists of a series of alphanumeric 
codes that define the toolpath, feed rates, and other parameters for the 
machine. This information is based on general knowledge about CNC and LinuxCNC 
as of my last training data update in January 2022.

GPT 4 out of the box:

The language used to configure LinuxCNC, which is an open-source system for 
controlling machine tools, is primarily INI (Initialization) file format for 
configuration settings, along with a combination of G-code for operational 
commands and Python for scripting and customization.

1. **INI Files**: LinuxCNC uses INI files to configure the software for a 
specific machine. These files contain settings for hardware, motion control 
parameters, and interface options. The format is straightforward, allowing 
users to specify parameters in a key-value format within sections.

2. **HAL (Hardware Abstraction Layer) Configuration**: LinuxCNC also uses a 
specific system for connecting the software components to the hardware called 
the Hardware Abstraction Layer (HAL). Configuration of HAL is done through HAL 
files, which are written in a custom syntax specific to LinuxCNC. These files 
define how hardware and software components are interconnected.

3. **G-code**: For operational commands, such as moving the machine or 
executing a cutting operation, LinuxCNC uses G-code. G-code is a language used 
by machine tools to control CNC operations. It consists of commands that 
instruct the machine on movements and actions to perform.

4. **Python**: For scripting, automation, and more complex customization, 
LinuxCNC supports the use of Python scripts. Python can be used to create 
custom user interfaces, automate tasks, or extend the functionality of LinuxCNC 
beyond what is possible with G-code and INI configuration alone.

These components together allow for a highly customizable and powerful system 
for CNC machine control, catering to a wide range of applications and machine 
types.

GPT 4 with training on our documentation:
The language used to configure LinuxCNC is not a single language but rather a 
combination of configuration files, HAL (Hardware Abstraction Layer) scripts, 
and sometimes Python scripts for more complex behaviors or customizations. 
Here's a breakdown of each:

INI Files: Configuration for LinuxCNC is primarily done through INI files 
(.ini). These are plain text files that set parameters for the LinuxCNC 
software, including machine geometry, kinematics, hardware settings, and file 
paths. INI files are structured with sections, keys, and values, providing a 
straightforward way to configure the various aspects of a CNC system.

HAL Files: The Hardware Abstraction Layer (HAL) configuration files (.hal) are 
used to connect the LinuxCNC software to the physical hardware. HAL files 
describe how software components are connected to each other and to the 
hardware interfaces. This allows for a flexible setup where users can define 
how signals are routed within the system, map inputs and outputs, and configure 
hardware drivers. HAL uses its own syntax to define these connections and 
configurations.

Python Scripts: For advanced customization, Python scripts can be used to 
extend the functionality of LinuxCNC. Python allows for the creation of custom 
GUI elements, complex logic operations, and integration with external systems. 
This is more advanced than INI and HAL configurations and requires programming 
knowledge.

Together, these components allow for highly customizable and flexible setups to 
suit a wide range of CNC machines and applications.

Me:
Is it possible to define loops in HAL?

GPT 3.5:

Yes, it is possible to define loops in HAL (Hardware Abstraction Layer) for 
LinuxCNC. HAL 

[Emc-developers] Impressions of amd64 LinuxCNC (not the RPi one)

[Steffen Möller via Emc-developers]

Hello,

I installed the one from the home page, and likely this is already outdated, 
but anyway this

root@debian:/home/user# cat /proc/version
Linux version 6.1.0-16-rt-amd64 (debian-ker...@lists.debian.org) (gcc-12 
(Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT_RT Debian 6.1.67-1 (2023-12-12)

is what I got and it works fine. Just that

model name  : Intel(R) Celeron(R) CPU  J1900  @ 1.99GHz

machine does not have the latencies that one would want to have (>14 ns).

HDMI sound works!

What I always do is

sudo apt-get update && sudo apt-get -u dist-upgrade

and somehow I expect this to work. But here now I ran into an error that was 
unexpected since the amd64 image referenced something from the RPi:

After this operation, 0 B of additional disk space will be used.
Setting up linux-image-6.1.0-17-rt-amd64 (6.1.69-1) ...
/etc/kernel/postinst.d/dkms:
dkms: running auto installation service for kernel 6.1.0-17-rt-amd64.
dkms: autoinstall for kernel: 6.1.0-17-rt-amd64.
/etc/kernel/postinst.d/initramfs-tools:
I: update-initramfs is disabled (live system is running on read-only media).
/etc/kernel/postinst.d/z50-raspi-firmware:
raspi-firmware: missing /boot/firmware, did you forget to mount it?
run-parts: /etc/kernel/postinst.d/z50-raspi-firmware exited with return code 1
dpkg: error processing package linux-image-6.1.0-17-rt-amd64 (--configure):
 installed linux-image-6.1.0-17-rt-amd64 package post-installation script 
subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of linux-image-rt-amd64:
 linux-image-rt-amd64 depends on linux-image-6.1.0-17-rt-amd64 (= 6.1.69-1); 
however:
  Package linux-image-6.1.0-17-rt-amd64 is not configured yet.

dpkg: error processing package linux-image-rt-amd64 (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 linux-image-6.1.0-17-rt-amd64
 linux-image-rt-amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)

The documentation is available via the menu - and only via the menu. Tried to 
open it with xpdf but that was not installed nor any other document viewer I 
knew. avril it is - kind of unexpected.

Wen through the German "getting started" documentation and find that a lot 
needs to be done to have it appeal to the eye, to not tell me at length about 
IRC as the very first thing, not to have those many English paragraphs when 
weblate tells me it that about all would be translated, so I somehow need to 
chase those up manually and get that fixed. The Spanish and French 
documentation we should not distribute since those are mostly English.

Best,
Steffen








___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] RPImager problem Re: RPi5 + Raspbian + LinuxCNC latency tests - first impressions

[Steffen Möller via Emc-developers]

@Chuck,

Not for controlling anything because of truly evil latencies, but without any 
motors attached you may want to check if the SPI errors also show when running 
the official Raspbian OS. This could be an indication of some firmware issue - 
or some timing parameters - or ... just á hunch - Rod knows more than I do.

Best,
Steffen

> Gesendet: Donnerstag, 04. Januar 2024 um 08:46 Uhr
> Von: "Rod Webster" 
> An: "EMC developers" 
> Betreff: Re: [Emc-developers] RPImager problem Re: RPi5 + Raspbian + LinuxCNC 
> latency tests - first impressions
>
> >If the R-Pi guys are being responsive, I wonder if you find any answer
> >about the SPI interface for the Mesa boards?  I found that linux-cnc
> >reported SPI errors when trying to talk to the 7C81.
> 
> Chuck, I'm sorry but I don't know enough about the topic to frame the
> question. Lets see if they can sort out the sound first.
> you can find them on Discord #arm-img-builder which is linked to from their
> repo I forked https://github.com/pyavitz/rpi-img-builder
> 
> Rod Webster
> *1300 896 832*
> +61 435 765 611
> Vehicle Modifications Network
> www.vehiclemods.net.au
> 
> 
> On Thu, 4 Jan 2024 at 07:09, Chuck Peplinski 
> wrote:
> 
> > If the R-Pi guys are being responsive, I wonder if you find any answer
> > about the SPI interface for the Mesa boards?  I found that linux-cnc
> > reported SPI errors when trying to talk to the 7C81.  I'm new to the
> > Linux-CNC community, so maybe I'm doing something else wrong.  But I got
> > the idea on the forums that there was some known issues with SPI on the
> > R-Pi5.
> > It's been on my list to follow the build instructions and see if I could
> > find out more, but that hasn't happened yet.
> >
> >  Thanks,
> >
> >  Chuck
> >
> > On 1/3/2024 1:39 PM, Rod Webster wrote:
> > >> Thank you for that pointer, I checked and found it installed but it
> > >> does not find any input or output devices.
> > > Upstream have resolved the rpi-imager compatibility issue.
> > > Their sound guy is away for  a few days but has it on his to do list.
> > > The willingness to sort this out has been amazing
> > >
> > > I have to find time to merge the changes and rebuild it. I Am flat out
> > for
> > > a while.
> > >
> > > Rod Webster
> > > *1300 896 832*
> > > +61 435 765 611
> > > Vehicle Modifications Network
> > > www.vehiclemods.net.au
> > >
> > >
> > > On Wed, 3 Jan 2024 at 22:27, Steffen Möller via Emc-developers <
> > > emc-developers@lists.sourceforge.net> wrote:
> > >
> > >>> On Tue, 2 Jan 2024 01:49:34 +0100
> > >>> Steffen Möller via Emc-developers
> > >>>  wrote:
> > >>>
> > >>>> The regular raspbian OS comes with sound via HDMI. I am toying around
> > >>>> with packages to install to see if I am getting anywhere without much
> > >>>> configuration. KDE works after installing task-kde-desktop - no
> > >>>> sound, though.
> > >>> Install the pavucontrol package.  That hass the controls you need to
> > >>> move the sound between ports.
> > >>>
> > >> Thank you for that pointer, I checked and found it installed but it
> > >> does not find any input or output devices.
> > >>
> > >> Best,
> > >> Steffen
> > >>
> > >>
> > >> ___
> > >> Emc-developers mailing list
> > >> Emc-developers@lists.sourceforge.net
> > >> https://lists.sourceforge.net/lists/listinfo/emc-developers
> > >>
> > > ___
> > > Emc-developers mailing list
> > > Emc-developers@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/emc-developers
> >
> >
> >
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
> >
> 
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] RPImager problem Re: RPi5 + Raspbian + LinuxCNC latency tests - first impressions

[Steffen Möller via Emc-developers]

 
> On Tue, 2 Jan 2024 01:49:34 +0100
> Steffen Möller via Emc-developers
>  wrote:
> 
> > The regular raspbian OS comes with sound via HDMI. I am toying around
> > with packages to install to see if I am getting anywhere without much
> > configuration. KDE works after installing task-kde-desktop - no
> > sound, though.
> 
> Install the pavucontrol package.  That hass the controls you need to
> move the sound between ports.
> 

Thank you for that pointer, I checked and found it installed but it
does not find any input or output devices.

Best,
Steffen


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] RPImager problem Re: RPi5 + Raspbian + LinuxCNC latency tests - first impressions

[Steffen Möller via Emc-developers]

The Balena Etcher did not complain, and neither then did the RPi5.
Many thanks!

The regular raspbian OS comes with sound via HDMI. I am toying around with 
packages to install to see if I am getting anywhere without much configuration. 
KDE works after installing task-kde-desktop - no sound, though.

Best,
Steffen

> Gesendet: Montag, 01. Januar 2024 um 19:17 Uhr
> Von: "Rod Webster" 
> An: "EMC developers" 
> Betreff: Re: [Emc-developers] RPImager problem Aw: Re: RPi5 + Raspbian + 
> LinuxCNC latency tests - first impressions
>
> >I downloaded the RPi5 image , ran xz -dt on it with no complaint, but then
> got a complaint by rpi-imager, the image size would not be a multiple of
> 512. That was with the same SD that had held the previous version. Did
> anybody else get that ?>message, too?  I ran this with another machine,
> with a USB SD adapter, so something could be off. Will try another download
> and another machine, but should someone else run into this, please kindly
> shout out.
> 
> Steffen, Could you please try burning the image using Balena Etcher?
> https://etcher.balena.io/
> This created and validated th image for me, I just can't test it.
> 
> 
> Rod Webster
> *1300 896 832*
> +61 435 765 611
> Vehicle Modifications Network
> www.vehiclemods.net.au
> 
> 
> On Tue, 2 Jan 2024 at 00:01, andy pugh  wrote:
> 
> > On Mon, 1 Jan 2024 at 13:57, andy pugh  wrote:
> >
> > > Try not doing that? The RPi Imager will accept a .xz file.
> > > I just wrote the Pi5  XZ straight to an SD card with no complaints.
> >
> > Oh, wait, you mean Rod's latest images? The one at www.linuxcnc.org
> > seem to work.
> >
> > --
> > atp
> > "A motorcycle is a bicycle with a pandemonium attachment and is
> > designed for the especial use of mechanical geniuses, daredevils and
> > lunatics."
> > — George Fitch, Atlanta Constitution Newspaper, 1912
> >
> >
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
> >
> 
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] RPImager problem Re: RPi5 + Raspbian + LinuxCNC latency tests - first impressions

[Steffen Möller via Emc-developers]

I just transitioned from Windows to Mac, new download, and get the same error. 
The default Raspbian OS now installed just fine on the same SD with the same 
equipment. I now dare to conclude that the problem is with your image.

Best,
Steffen

>
> Rod,
> 
> You referenced the download page and so I just went through 
> https://linuxcnc.org/downloads/ again and liked it a lot. Very clear, many 
> thanks! Whoever wrote that - many thanks! My initial reflex was like "Our 
> documentation should be as good or better" and then thought that maybe the 
> documentation should in contrary just depend on the download page to know 
> best what to download and we should possibly even minimize our LinuxCNC 
> documentation on OS install questions with a pointer to the Download page?!?
> 
> I downloaded the RPi5 image , ran xz -dt on it with no complaint, but then 
> got a complaint by rpi-imager, the image size would not be a multiple of 512. 
> That was with the same SD that had held the previous version. Did anybody 
> else get that message, too?  I ran this with another machine, with a USB SD 
> adapter, so something could be off. Will try another download and another 
> machine, but should someone else run into this, please kindly shout out.
> 
> Happy New Year to everyone,
> Steffen
> 
> 
> 
> > Gesendet: Sonntag, 31. Dezember 2023 um 20:06 Uhr
> > Von: "Rod Webster" 
> > An: "EMC developers" 
> > Betreff: Re: [Emc-developers] RPi5 + Raspbian + LinuxCNC latency tests - 
> > first impressions
> >
> > Hi guys,
> > I've sent new images for the Pi 4b and Pi 5 to Andy for testing, with a
> > view that they be deployed on the downloads page. These both use the 6.1.69
> > kernel which is the very first version where the Raspberry Kernel and the
> > PREEMPT_RT patch align perfectly. Hopefully over the last 6 weeks, the pi5
> > is better supported now.
> > 
> > *Raspberry Pi 4b/400*
> > https://drive.google.com/file/d/1Bzx_PqRqdJVTMPlNMEG7z_RjJHf7QcDX/view?usp=sharing
> > 
> > *Raspberry PI 5*
> > https://drive.google.com/file/d/1HBXliMQE-OvU0PQPYEOK3OqJz0-CTO5K/view?usp=sharing
> > 
> > For initial login credentials, and initial configuration,  please refer to
> > the download page
> > https://linuxcnc.org/downloads/
> > 
> > Rod Webster
> > *1300 896 832*
> > +61 435 765 611
> > Vehicle Modifications Network
> > www.vehiclemods.net.au
> > 
> > 
> > On Sun, 31 Dec 2023 at 01:35, Steffen Möller via Emc-developers <
> > emc-developers@lists.sourceforge.net> wrote:
> > 
> > > Rod,
> > >
> > > Thank you for your kind and swift reply.
> > > HDMI sound works perfectly with the Raspbian default. Also, I think this
> > > would find quite some user base, since anyone reusing an old TV or a
> > > feature-rich monitor with the RPi would immediately benefit. I also
> > > mentioned games before :)
> > >
> > > The RPi image we come up with does not need to be perfect. Our users
> > > should just not be surprised with anythin when using it. My wishlist would
> > > be
> > >  * A pointer to our manual at all the places where the image could be
> > > downloaded
> > >  * The manual describing
> > >- how the image is created so they can contribute
> > >- what not to do with that image
> > >
> > > On a sidenote, please have a look at http://raspi.debian.net/. Nothing on
> > > the RPi5, though maybe this resonates somehow with what we are after.
> > >
> > > Best,
> > > Steffen
> > >
> > > > Gesendet: Samstag, 30. Dezember 2023 um 14:16 Uhr
> > > > Von: "Rod Webster" 
> > > > An: "EMC developers" 
> > > > Betreff: Re: [Emc-developers] RPi5 + Raspbian + LinuxCNC latency tests -
> > > first impressions
> > > >
> > > > Steffen,
> > > >
> > > > Some good feedback thanks.
> > > > I'm really not surprised things broke on an update because we compile 
> > > > the
> > > > kernel from the Raspberry sources at a specific point in the commit 
> > > > tree.
> > > > It's not a generic  Debian build by any means. LIkewise installing a
> > > > different desktop is also asking for trouble.
> > > >
> > > > Having no sound is also not surprising because in the absence of an 
> > > > audio
> > > > jack you are dependent on HDMI and I know other SBC's have issues with
> > > HDMI
> > > > 

[Emc-developers] RPImager problem Aw: Re: RPi5 + Raspbian + LinuxCNC latency tests - first impressions

[Steffen Möller via Emc-developers]

Rod,

You referenced the download page and so I just went through 
https://linuxcnc.org/downloads/ again and liked it a lot. Very clear, many 
thanks! Whoever wrote that - many thanks! My initial reflex was like "Our 
documentation should be as good or better" and then thought that maybe the 
documentation should in contrary just depend on the download page to know best 
what to download and we should possibly even minimize our LinuxCNC 
documentation on OS install questions with a pointer to the Download page?!?

I downloaded the RPi5 image , ran xz -dt on it with no complaint, but then got 
a complaint by rpi-imager, the image size would not be a multiple of 512. That 
was with the same SD that had held the previous version. Did anybody else get 
that message, too?  I ran this with another machine, with a USB SD adapter, so 
something could be off. Will try another download and another machine, but 
should someone else run into this, please kindly shout out.

Happy New Year to everyone,
Steffen



> Gesendet: Sonntag, 31. Dezember 2023 um 20:06 Uhr
> Von: "Rod Webster" 
> An: "EMC developers" 
> Betreff: Re: [Emc-developers] RPi5 + Raspbian + LinuxCNC latency tests - 
> first impressions
>
> Hi guys,
> I've sent new images for the Pi 4b and Pi 5 to Andy for testing, with a
> view that they be deployed on the downloads page. These both use the 6.1.69
> kernel which is the very first version where the Raspberry Kernel and the
> PREEMPT_RT patch align perfectly. Hopefully over the last 6 weeks, the pi5
> is better supported now.
> 
> *Raspberry Pi 4b/400*
> https://drive.google.com/file/d/1Bzx_PqRqdJVTMPlNMEG7z_RjJHf7QcDX/view?usp=sharing
> 
> *Raspberry PI 5*
> https://drive.google.com/file/d/1HBXliMQE-OvU0PQPYEOK3OqJz0-CTO5K/view?usp=sharing
> 
> For initial login credentials, and initial configuration,  please refer to
> the download page
> https://linuxcnc.org/downloads/
> 
> Rod Webster
> *1300 896 832*
> +61 435 765 611
> Vehicle Modifications Network
> www.vehiclemods.net.au
> 
> 
> On Sun, 31 Dec 2023 at 01:35, Steffen Möller via Emc-developers <
> emc-developers@lists.sourceforge.net> wrote:
> 
> > Rod,
> >
> > Thank you for your kind and swift reply.
> > HDMI sound works perfectly with the Raspbian default. Also, I think this
> > would find quite some user base, since anyone reusing an old TV or a
> > feature-rich monitor with the RPi would immediately benefit. I also
> > mentioned games before :)
> >
> > The RPi image we come up with does not need to be perfect. Our users
> > should just not be surprised with anythin when using it. My wishlist would
> > be
> >  * A pointer to our manual at all the places where the image could be
> > downloaded
> >  * The manual describing
> >- how the image is created so they can contribute
> >- what not to do with that image
> >
> > On a sidenote, please have a look at http://raspi.debian.net/. Nothing on
> > the RPi5, though maybe this resonates somehow with what we are after.
> >
> > Best,
> > Steffen
> >
> > > Gesendet: Samstag, 30. Dezember 2023 um 14:16 Uhr
> > > Von: "Rod Webster" 
> > > An: "EMC developers" 
> > > Betreff: Re: [Emc-developers] RPi5 + Raspbian + LinuxCNC latency tests -
> > first impressions
> > >
> > > Steffen,
> > >
> > > Some good feedback thanks.
> > > I'm really not surprised things broke on an update because we compile the
> > > kernel from the Raspberry sources at a specific point in the commit tree.
> > > It's not a generic  Debian build by any means. LIkewise installing a
> > > different desktop is also asking for trouble.
> > >
> > > Having no sound is also not surprising because in the absence of an audio
> > > jack you are dependent on HDMI and I know other SBC's have issues with
> > HDMI
> > > sound. If someone has a solution please let me know
> > >
> > > Please bear in mind that this image is over 6 weeks old and there have
> > been
> > > several kernel releases and countless commits to the raspberry pi kernel
> > > since then.
> > >
> > > But for me, the main thing is that it's only in the last few days that
> > the
> > > kernel version and the PREEMPT_RT patch align perfectly so I am hoping my
> > > next version is more robust. That has never happened in the life of the
> > pi5
> > > before.
> > >
> > > To test latency on the console, you can install the debian rt-tests
> > > package. I have found that our latency-histogram yields similar result

Re: [Emc-developers] Linuxcnc 2.10pre with glade

[Steffen Möller via Emc-developers]

Hello,

Once you have integrated your changes with the latest version I expect that you 
can run this all through Glade again. If not then something was broken in that 
process, I presume. But I am no expert on what Gmoccapy is doing or on how to 
modify it - my answer was only on how to use a recursive diff and transition 
that to the master branch. 

Good luck!
Steffen

> Hi SteffenOk I see, so no way to edit the file with glade?Gmoccapy was 
> created with witch version?Thanks again for your helpCordialement,Moustapha 
> ElhimaPenser à préserver l'environnement avant d'imprimer ce message. Merci
>  Message d'origine ----De : Steffen Möller via Emc-developers 
>  Date : 30/12/2023  22:10  (GMT+01:00) 
> À : emc-developers@lists.sourceforge.net Cc : Steffen Möller 
> , emc-developers@lists.sourceforge.net Objet : Re: 
> [Emc-developers] Linuxcnc 2.10pre with glade Well, there may be another 
> option if you still have (or can still retrieve) the tarball from which you 
> started.It is three steps:1. Rename your current source tree to avoid 
> overwriting it, call it "mywork"2. Unpack the original tarball of LinuxCNC of 
> version 2.8 that you edited.3. Create a diff of the two and redirect that 
> into a file:   diff -r original mywork > whateverpathto/mywork.patch4. Clone 
> the current master branch of LinuxCNC5. patch it with what you saved in 
> mywork.patch:   patch -p1 < whateverpathto/mywork.patchNot all hunks of that 
> patch will work, but many will be just fine.Good luck!Steffen> Gesendet: 
> Samstag, 30. Dezember 2023 um 16:55 Uhr> Von: "Hans Unzner" 
> > An: emc-developers@lists.sourceforge.net> Betreff: 
> Re: [Emc-developers] Linuxcnc 2.10pre with glade>> I'm afraid but I think you 
> have to do your modifications once more for > LinuxCNC 2.9/2.10. There have 
> been so many changes during the upgrade > from Python2 to Python3 and Gtk2 to 
> Gtk3, which make it almost > impossible to merge from 2.8, especially the 
> glade file. Also a huge > number of deprecated widgets have been replaced in 
> Gmoccapy for > LinuxCNCN 2.9.> So I would recommend to just do it again for 
> the current version. Sorry.> > Hans> > Am 30.12.23 um 15:08 schrieb ELHIMA 
> Moustapha via Emc-developers:> > Hi guy's> >> > Houston I have a problem... I 
> project to use the mesa 5i25T instead off the 5i25 ( was good for me)> > For 
> the I need at list the linuxcnc2.10pre version> >> > I had customized the 
> gmoccapy interface (gmoccapy.glade) to get some other functionality and work 
> also on the bin file of it> > After few hours of work... I get the suprise to 
> had made all of this stuff on the 2.8 version of linuxcnc.> >> > I said " 
> ok lets spend again a part of your life time again...". So I decided to merge 
> to the buster version and install linuxcnc from the biuldbot.> > 
> Linuxcnc2.10pre and the mesa 5i25T working fine.> > So 2nd step was to make 
> the same modification on the gmoccapy interface and I get a terrible 
> headache.> > Python need to be version 3 instead off 2 for linuxcnc2.8 
> but ok no problem for that ( or maybe there is a script to merge python 2 to 
> 3?)> > For Glade I had installed v3.40 and no way to get the hal library and 
> gladevcp.> >> > Is it possible to get the right way to update gmoccapy on 
> linuxcnc 2.10pre???> >> > Thanks for your help> >> > Cordialement,> >> > 
> Moustapha Elhima> > ELMO - machines outils> > +33 6 09 99 21 97> >> > P 
> Penser à préserver l'environnement avant d'imprimer ce message. Merci> >> > 
> ___> > Emc-developers mailing 
> list> > Emc-developers@lists.sourceforge.net> > 
> https://lists.sourceforge.net/lists/listinfo/emc-developers> > > > 
> ___> Emc-developers mailing list> 
> Emc-developers@lists.sourceforge.net> 
> https://lists.sourceforge.net/lists/listinfo/emc-developers>___Emc-developers
>  mailing 
> listEmc-developers@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/emc-developers
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Linuxcnc 2.10pre with glade

[Steffen Möller via Emc-developers]

Well, there may be another option if you still have (or can still retrieve) the 
tarball from which you started.
It is three steps:

1. Rename your current source tree to avoid overwriting it, call it "mywork"
2. Unpack the original tarball of LinuxCNC of version 2.8 that you edited.
3. Create a diff of the two and redirect that into a file:
   diff -r original mywork > whateverpathto/mywork.patch
4. Clone the current master branch of LinuxCNC
5. patch it with what you saved in mywork.patch:
   patch -p1 < whateverpathto/mywork.patch

Not all hunks of that patch will work, but many will be just fine.

Good luck!
Steffen

> Gesendet: Samstag, 30. Dezember 2023 um 16:55 Uhr
> Von: "Hans Unzner" 
> An: emc-developers@lists.sourceforge.net
> Betreff: Re: [Emc-developers] Linuxcnc 2.10pre with glade
>
> I'm afraid but I think you have to do your modifications once more for 
> LinuxCNC 2.9/2.10. There have been so many changes during the upgrade 
> from Python2 to Python3 and Gtk2 to Gtk3, which make it almost 
> impossible to merge from 2.8, especially the glade file. Also a huge 
> number of deprecated widgets have been replaced in Gmoccapy for 
> LinuxCNCN 2.9.
> So I would recommend to just do it again for the current version. Sorry.
> 
> Hans
> 
> Am 30.12.23 um 15:08 schrieb ELHIMA Moustapha via Emc-developers:
> > Hi guy's
> >
> > Houston I have a problem... I project to use the mesa 5i25T instead off the 
> > 5i25 ( was good for me)
> > For the I need at list the linuxcnc2.10pre version
> >
> > I had customized the gmoccapy interface (gmoccapy.glade) to get some other 
> > functionality and work also on the bin file of it
> > After few hours of work... I get the suprise to had made all of this stuff 
> > on the 2.8 version of linuxcnc.
> >
> > I said " ok lets spend again a part of your life time again...". So I 
> > decided to merge to the buster version and install linuxcnc from the 
> > biuldbot.
> > Linuxcnc2.10pre and the mesa 5i25T working fine.
> > So 2nd step was to make the same modification on the gmoccapy interface and 
> > I get a terrible headache.
> > Python need to be version 3 instead off 2 for linuxcnc2.8 but ok no problem 
> > for that ( or maybe there is a script to merge python 2 to 3?)
> > For Glade I had installed v3.40 and no way to get the hal library and 
> > gladevcp.
> >
> > Is it possible to get the right way to update gmoccapy on linuxcnc 
> > 2.10pre???
> >
> > Thanks for your help
> >
> > Cordialement,
> >
> > Moustapha Elhima
> > ELMO - machines outils
> > +33 6 09 99 21 97
> >
> > P Penser à préserver l'environnement avant d'imprimer ce message. Merci
> >
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
> 
> 
> 
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] RPi5 + Raspbian + LinuxCNC latency tests - first impressions

[Steffen Möller via Emc-developers]

Rod,

Thank you for your kind and swift reply.
HDMI sound works perfectly with the Raspbian default. Also, I think this would 
find quite some user base, since anyone reusing an old TV or a feature-rich 
monitor with the RPi would immediately benefit. I also mentioned games before :)

The RPi image we come up with does not need to be perfect. Our users should 
just not be surprised with anythin when using it. My wishlist would be
 * A pointer to our manual at all the places where the image could be downloaded
 * The manual describing 
   - how the image is created so they can contribute
   - what not to do with that image

On a sidenote, please have a look at http://raspi.debian.net/. Nothing on the 
RPi5, though maybe this resonates somehow with what we are after.

Best,
Steffen

> Gesendet: Samstag, 30. Dezember 2023 um 14:16 Uhr
> Von: "Rod Webster" 
> An: "EMC developers" 
> Betreff: Re: [Emc-developers] RPi5 + Raspbian + LinuxCNC latency tests - 
> first impressions
>
> Steffen,
> 
> Some good feedback thanks.
> I'm really not surprised things broke on an update because we compile the
> kernel from the Raspberry sources at a specific point in the commit tree.
> It's not a generic  Debian build by any means. LIkewise installing a
> different desktop is also asking for trouble.
> 
> Having no sound is also not surprising because in the absence of an audio
> jack you are dependent on HDMI and I know other SBC's have issues with HDMI
> sound. If someone has a solution please let me know
> 
> Please bear in mind that this image is over 6 weeks old and there have been
> several kernel releases and countless commits to the raspberry pi kernel
> since then.
> 
> But for me, the main thing is that it's only in the last few days that the
> kernel version and the PREEMPT_RT patch align perfectly so I am hoping my
> next version is more robust. That has never happened in the life of the pi5
> before.
> 
> To test latency on the console, you can install the debian rt-tests
> package. I have found that our latency-histogram yields similar results.
> 
> I don't think a single 400 usec spike when opening a browser is of concern.
> Thats not something you do when running a gcode program.
> 
> Hopefully I will have some peace and quiet over the weekend to build a new
> version.
> 
> Rod Webster
> *1300 896 832*
> +61 435 765 611
> Vehicle Modifications Network
> www.vehiclemods.net.au
> 
> 
> On Sat, 30 Dec 2023 at 21:58, Steffen Möller via Emc-developers <
> emc-developers@lists.sourceforge.net> wrote:
> 
> > Heya,
> >
> > Not only that we have a RPi4/5 confusion, you managed to add a Rod/b one.
> >
> > So, the image Andy pointed to (which I understand has its roots with Rod)
> > works very nicely. While idle latencies did not exceed 12µs, mostly below
> > 10. That was truly impressive. Once I got wifi up and initiated some
> > downloads, it doubled to 24µs, much like the value Andy got. When I started
> > up firefox and selected youtube, I got a single value of 400µs, though.
> >
> > A complaint I have is that there was no sound in the default installation.
> > The 400µs I like to speculate may be associated with the failed attempt to
> > perform the respective initialisations.
> >
> > Another complaint is that the image is not stable when it comes to
> > updates. I was curious on the effect that the installation of KDE would
> > have on the latencies, and if the missing sound would install with it. So I
> > installed the package "task-desktop-kde" with debfoster. That ruined the
> > reboot since the expected kernel image was no longer found. I made a
> > screenshot with my phone and send it to whoever is interested, but my hunch
> > is that Rod's new image if depending more on Debian's installation will
> > likely solve such inconsistency issues.
> >
> > Do we have any latency tools that would run without X, so we get a
> > baseline of what software layer is costing us how much? I recall that we do
> > but latency-test at least does not. I am asking since the latency-sensitive
> > gaming industry should have some strong incentive to look into what we are
> > doing but I have not seen too much from them, yet. Ok - this may be
> > something for another thread.
> >
> > Best,
> > Steffen
> >
> >
> > > Gesendet: Samstag, 30. Dezember 2023 um 04:15 Uhr
> > > Von: "Rob M" 
> > > An: "EMC developers" 
> > > Betreff: Re: [Emc-developers] RPi5 + Raspbian + LinuxCNC latency tests -
> > first impressions
> > >
> > > Umm Rod Old Mate was referring to the my linked images for the

Re: [Emc-developers] RPi5 + Raspbian + LinuxCNC latency tests - first impressions

[Steffen Möller via Emc-developers]

Heya,

Not only that we have a RPi4/5 confusion, you managed to add a Rod/b one.

So, the image Andy pointed to (which I understand has its roots with Rod) works 
very nicely. While idle latencies did not exceed 12µs, mostly below 10. That 
was truly impressive. Once I got wifi up and initiated some downloads, it 
doubled to 24µs, much like the value Andy got. When I started up firefox and 
selected youtube, I got a single value of 400µs, though.

A complaint I have is that there was no sound in the default installation. The 
400µs I like to speculate may be associated with the failed attempt to perform 
the respective initialisations.

Another complaint is that the image is not stable when it comes to updates. I 
was curious on the effect that the installation of KDE would have on the 
latencies, and if the missing sound would install with it. So I installed the 
package "task-desktop-kde" with debfoster. That ruined the reboot since the 
expected kernel image was no longer found. I made a screenshot with my phone 
and send it to whoever is interested, but my hunch is that Rod's new image if 
depending more on Debian's installation will likely solve such inconsistency 
issues.

Do we have any latency tools that would run without X, so we get a baseline of 
what software layer is costing us how much? I recall that we do but 
latency-test at least does not. I am asking since the latency-sensitive gaming 
industry should have some strong incentive to look into what we are doing but I 
have not seen too much from them, yet. Ok - this may be something for another 
thread.

Best,
Steffen


> Gesendet: Samstag, 30. Dezember 2023 um 04:15 Uhr
> Von: "Rob M" 
> An: "EMC developers" 
> Betreff: Re: [Emc-developers] RPi5 + Raspbian + LinuxCNC latency tests - 
> first impressions
>
> Umm Rod Old Mate was referring to the my linked images for the RPi4, not
> your ones, the ones I built for other reasons.
> 
> On Sat, Dec 30, 2023 at 1:26 PM Rod Webster  wrote:
> 
> > >None of those images were for the Rpi-5, I thought the RPi4 in the file
> >
> > Well yes they are. Andy and Steffan are using pi5 variant of my image which
> > is used for the 2.9.1 release from here:
> >
> > https://drive.google.com/file/d/1H_q0Ra-27ZDOhquvq179beUZQNVlex1f/view?usp=sharing
> > Filename (with rpi-5 in it):
> > rpi-5-debian-bookworm-6.1.61-rt15-arm64-ext4-2023-11-17-1520.img.xz
> > It was built for the Pi 5's BCM2712 board.
> > Username: cnc Password: cnc
> > to finalise the installation (wifi, password , locale etc) type: sudo
> > menu-config
> >
> > If the  screen resolution is not right, it should be able to be fixed with
> > a parameter in one of the pi's config files.
> >
> > I have just completed and tested a 2.9.2 installer for X86 on Debian 12.4.
> > I managed to bypass the raspberry-firmware installation bug in earlier
> > versions (Inherited from Debian)
> >
> > https://drive.google.com/file/d/1nw0dGt5aZXVo8k68lLf4N_nzc0wTczAg/view?usp=sharing
> > I will also rebuild the images for the Pi4 and Pi5, but I am kernelled out
> > for today!
> >
> > Rod Webster
> > *1300 896 832*
> > +61 435 765 611
> > Vehicle Modifications Network
> > www.vehiclemods.net.au
> >
> >
> > On Sat, 30 Dec 2023 at 12:00, Rob M  wrote:
> >
> > > None of those images were for the Rpi-5, I thought the RPi4 in the file
> > > name would made the obvious, but as this a topic about the 4 I guess
> > there
> > > could be some confusion.
> > >
> > > As for the recent RPi5 image you tried does that have any issues with
> > > screen resolution? Is it stuck on a single resolution? Does it detect the
> > > display it's attached to ? These issues, as mentioned previously, a game
> > > stopper for myself.  If they aren't an issue could you say what
> > > kind-brand-model display you're using ?
> > >
> > >
> > >
> > >
> > >
> > > On Sat, 30 Dec 2023, 11:40 andy pugh,  wrote:
> > >
> > > > On Sat, 30 Dec 2023 at 00:27, Steffen Möller via Emc-developers
> > > >  wrote:
> > > >
> > > > > Andy's image was a success - I just did not know the passwords.
> > > >
> > > > I mentioned it in a previous message, but it is cnc / cnc
> > > >
> > > > --
> > > > atp
> > > > "A motorcycle is a bicycle with a pandemonium attachment and is
> > > > designed for the especial use of mechanical geniuses, daredevils and
> > > > lunatics."
> > > > — George Fitch, Atlanta Constitution Newspaper, 1912
> > > >
>

Re: [Emc-developers] RPi5 + Raspbian + LinuxCNC latency tests - first impressions

[Steffen Möller via Emc-developers]

Hello,

Andy's image was a success - I just did not know the passwords.

> General use for Linuxcnc
> https://drive.google.com/file/d/1Ve6LismgxL0OfYufkeU1Z0hzdWhbf_WJ/view?usp=sharing

does not boot on my RPi5 - gets the same USB errors and the missing device tree 
as reported for the 2.9.1 RPI version our documentation references.


> A complete development image for the Litexcnc project, includes OpenOCD,
> oss-cad-suite and some other bits and pieces as required, previously this
> link was only shared on the github page for the project
> https://drive.google.com/file/d/1l9dldTeoRwV8Ma3ljQCWFn-8pFGjuIot/view?usp=sharing

Not tried.


> > > Let me look to see what I have.
> >
> > Try this one
> > rpi-5-debian-bookworm-6.1.61-rt15-arm64-ext4-2023-11-17-1520.img.xz

Boots very fast into the Login screen. Also the change to the ascii terminal 
with CTRL-ALT-F1 and back with ALT-F7 is fine. I recall to have set Login data 
in the RPi imager but did not find them to work. Is there a default password I 
should know about? Looked into 
https://linuxcnc.org/docs/stable/html/getting-started/getting-linuxcnc.html but 
that did not help me.

Many thanks!
Steffen



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] RPi5 + Raspbian + LinuxCNC latency tests - first impressions

[Steffen Möller via Emc-developers]

Hello,

That was quite a thread I have triggered, feels a bit like the Debian mailing 
lists :)

> Von: "andy pugh" 

> Why do people keep reinventing this particular wheel? We distribute a
> Pi SD card image via www.linuxcnc.org.

I just went for it and it does not work for the RPi5 - stating that the device 
tree would not be found and that the bcm2712-rpi-5-b.dtb cannot be found. The 
noisy fan was likely a consequence. The system the loops over that message and 
does not come up. This is the 2.9.1 version.

These kind of hardware dependencies I expect to also find for other small 
boards, so I would not mind to get some confidence to compile the RT preempt 
kernel on various platforms. I'll see how far I get without cross-compiling. We 
would then add a section somewhere in our documentation how to compile the RT 
kernel whenever that is not provided by the hardware vendor.

Best,
Steffen


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Aw: Re: Community renewal and project obsolescence

[Steffen Möller]

> Gesendet: Donnerstag, 28. Dezember 2023 um 20:02 Uhr
> Von: "Mo Zhou" 
> An: debian-project@lists.debian.org
> Betreff: Re: Community renewal and project obsolescence
>
> On 12/28/23 10:34, Rafael Laboissière wrote:
> 
> > * M. Zhou  [2023-12-27 19:00]:
> >
> > Thanks for the code and the figure. Indeed, the trend is confirmed by 
> > fitting a linear model count ~ year to the new members list. The 
> > coefficient is -1.39 member/year, which is significantly different 
> > from zero (F[1,22] = 11.8, p < 0.01). Even when we take out the data 
> > from year 2001, that could be interpreted as an outlier, the trend is 
> > still siginificant, with a drop of 0.98 member/year (F[1,21] = 8.48, p 
> > < 0.01).
> 
> I thought about to use some models for population statistics, so we can 
> get the data about DD birth rate and DD retire/leave rate, as well as a 
> prediction. But since the descendants of DDs are not naturally new DDs, 
> the typical population models are not likely going to work well. The 
> birth of DD is more likely mutation, sort of.
> 
> Anyway, we do not need sophisticated math models to draw the conclusion 
> that Debian is an aging community. And yet, we don't seem to have a good 
> way to reshape the curve using Debian's funds. -- this is one of the key 
> problems behind the data.

What hypothese do we have on what influences the number of active individuals?

Positive factors
* Location of DebConf (with many or not so many devs affording to attend)
* Popular platforms like the Raspberry Pi working with Debian derivative
* Debian packaging teams on salsa
* self-education
* Impression the DD status makes on outsiders/your next employer
* Pleasant interactions on mailing lists with current or past team members
* Team building with other DDs on projects of interest

Negative factors
* Advent of homebrew+conda
* Containers
* Increasing workloads as one ages and does not give packages up
* Work-life-balance
* Migrating to upstream
* Delay between what upstream releases and what is available in our distro
* Unpleasant interactions on mailing lists with current or past team members

Do you have a better list?
I keep thinking about what the last significant change in Debian may have been 
- to mind came salsa.debian.org. Do I miss anything?
And I think the change I would like to see the most is a variant of brew/salsa 
for Debian, preferably in some mostly automated way, so we have some way to 
install the very latest with Debian all the time.

Best,
Steffen

Re: [Emc-developers] RPi5 + Raspbian + LinuxCNC latency tests - first impressions

[Steffen Möller via Emc-developers]

Thank you, Rod! Will definitely try that one.
We need to find some official instructions for the RPi4/5 installation, I 
suggest. I looked through our documentation today but did not find anything 
beyond the use of RPi GPIOs.

After Seb's comment on using the wrong kernel I had a bit of a facepalm moment 
- thank you, Seb! Then I installed a regular arm64-rt kernel but that then 
ruined the RPi setup, so after a reboot I had no more Wifi and (worse) the 
ventilator was a max, even though the same wrong stock kernel was booting after 
the reboot. Sounds like flashing a new SD card to me. And it also sounds like a 
guarantee to lose all our new LinuxCNC users on an RPi.

We can certainly do a lot via our custom images for which we could come up with 
an RPi5 variant, but preferably we'd have someone in an official position to 
prepare the RPi5-rt kernels for everyone, as part of the Raspbian or Debian 
distribution, not just us for ourselves. Is there anyone on this list who would 
know whom to ask?

Best,
Steffen

> Gesendet: Mittwoch, 27. Dezember 2023 um 22:24 Uhr
> Von: "Rod Webster" 
> An: "EMC developers" 
> Betreff: Re: [Emc-developers] RPi5 + Raspbian + LinuxCNC latency tests - 
> first impressions
>
> You could try this image that contains preempt_rt for the Pi 5  (Linuxcnc
> 2.9.1)
> https://drive.google.com/file/d/1H_q0Ra-27ZDOhquvq179beUZQNVlex1f/view?usp=drive_link
> I don't have a Pi5 to test it but others say it worked.
> 
> This is an updated image from our Raspberry Pi 4 one that is built for
> the newer Pi 5 CPU
> sudo apt upgrade should update to 2.9.2
> 
> Rod Webster
> *1300 896 832*
> +61 435 765 611
> Vehicle Modifications Network
> www.vehiclemods.net.au
> 
> 
> On Thu, 28 Dec 2023 at 06:46, Sebastian Kuzminsky  wrote:
> 
> > On 12/27/23 13:38, Steffen Möller via Emc-developers wrote:
> > >
> > >> Gesendet: Mittwoch, 27. Dezember 2023 um 17:13 Uhr
> > >> Von: "andy pugh" 
> > >> An: "EMC developers" 
> > >> Cc: "Steffen Möller" 
> > >> Betreff: Re: [Emc-developers] RPi5 + Raspbian + LinuxCNC latency tests
> > - first impressions
> > >>
> > >> On Wed, 27 Dec 2023 at 15:20, Steffen Möller via Emc-developers
> > >>  wrote:
> > >>
> > >>> My RPi5 arrived over Xmas and I just fired it up, was offered to
> > install LinuxCNC directly from what we offer in Debian, and then ran
> > latency tests.  Graphics (as in video but also the extra art from your X
> > interface when ALT-tabbing through your applications) have the most effect
> > on the latency. I/O from the SD does not seem to affect it too much.
> > >>
> > >> The numbers you show are _awful_ though?
> > >>
> > >> It doesn't look like the LinuxCNC installation has installed the
> > >> correct kernel. (I seem to recall that I had to do a fair bit of
> > >> fiddling to make it happen, it's a Pi thing)
> > >
> > > Rebooted with
> > > Linux version 6.1.0-rpi7-rpi-2712 (debian-ker...@lists.debian.org)
> > (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40)
> > #1 SMP PREEMPT Debian 1:6.1.63-1+rpt1 (2023-11-24)
> > > but do not see any relevant change.
> >
> > That's the wrong kernel: "PREEMPT" is not enough, you need "PREEMPT_RT"
> > in the uname string.
> >
> > This is usually the difficult part of getting systems with out-of-tree
> > vendor-specific kernels to work well with LinuxCNC.
> >
> >
> > --
> > Sebastian Kuzminsky
> >
> >
> >
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
> >
> 
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Aw: Re: Last call for any other location than Berlin (Was: Any suggestions for next Debian Med sprint (in person meeting)?)

[Steffen Möller]

> Gesendet: Freitag, 22. Dezember 2023 um 22:37 Uhr
> Von: "Pierre Gruet" 
> An: debian-med@lists.debian.org
> Betreff: Re: Last call for any other location than Berlin (Was: Any 
> suggestions for next Debian Med sprint (in person meeting)?)
>
> Hi all,
> 
> Le 21/12/2023 à 16:15, Sascha Steinbiss a écrit :
> > Hi,
> > 
> > [...]
> >>> How about Feb 10-11, for example? My weekends are still free for now 
> >>> so it's
> >>> your choice.
> >>
> >> I admit I'd prefer Feb. 17-18 over 10-11.  Other opinions?
> 
> I will be available on both weekends, although I prefer 10-11 over 17-18 
> for teaching and meeting reasons.
> 
> But as I just wrote, 17-18 also works.

I'd opt for the earlier date, so we have a bit of a break before some of us I 
expect to bump into each other again in Hamburg if Holger's event materialises 
a month later.

Best,
Steffen

Re: [Emc-developers] RPi5 + Raspbian + LinuxCNC latency tests - first impressions

[Steffen Möller via Emc-developers]

> Gesendet: Mittwoch, 27. Dezember 2023 um 17:13 Uhr
> Von: "andy pugh" 
> An: "EMC developers" 
> Cc: "Steffen Möller" 
> Betreff: Re: [Emc-developers] RPi5 + Raspbian + LinuxCNC latency tests - 
> first impressions
>
> On Wed, 27 Dec 2023 at 15:20, Steffen Möller via Emc-developers
>  wrote:
> 
> > My RPi5 arrived over Xmas and I just fired it up, was offered to install 
> > LinuxCNC directly from what we offer in Debian, and then ran latency tests. 
> >  Graphics (as in video but also the extra art from your X interface when 
> > ALT-tabbing through your applications) have the most effect on the latency. 
> > I/O from the SD does not seem to affect it too much.
> 
> The numbers you show are _awful_ though?
> 
> It doesn't look like the LinuxCNC installation has installed the
> correct kernel. (I seem to recall that I had to do a fair bit of
> fiddling to make it happen, it's a Pi thing)

Rebooted with 
Linux version 6.1.0-rpi7-rpi-2712 (debian-ker...@lists.debian.org) (gcc-12 
(Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT Debian 1:6.1.63-1+rpt1 (2023-11-24)
but do not see any relevant change.

After fixing the process to a processor the max observed latency is reduced by 
a third (down to 23 million nanoseconds). That is with wifi, video and loads of 
I/O. No latencies observed as a regular user - so I am still excited about this 
new Pi.

I just updated the firmware (the routine update could not do that because of a 
version conflict) and will then try again.

Best,
Steffen


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] 2.9.2

[Steffen Möller via Emc-developers]

> Gesendet: Sonntag, 10. Dezember 2023 um 01:18 Uhr
> Von: "andy pugh" 
> An: "EMC developers" 
> Betreff: [Emc-developers] 2.9.2
...
> I am hoping not to have to hand-build all the debs again, like I did
> for the 2.9.1 release.
>
> Why did I have to do that? Because between me creating the tag and
> pushing it, there was a commit made. Well. maybe my fault, I could
> have done a --dry-run, but that still leaves a window of opportunity
> for a commit to break the process.

Please allow me to fix the double-installation of that one manual page prior to 
the release. Once that is fixed i would like to add the installation of all our 
.debs as part of the CI - anything placed redundantly in separate packages 
should then show up as a conflict.

Concerning the tag and ensuring that you exactly know what you are tagging, 
does it help that you can specify the commit that you want to tag?

NAME
   git-tag - Create, list, delete or verify a tag object signed with GPG

SYNOPSIS
   git tag [-a | -s | -u ] [-f] [-m  | -F ] [-e]
[ | ]
   git tag -d ...
   git tag [-n[]] -l [--contains ] [--no-contains ]
   [--points-at ] [--column[=] | --no-column]
   [--create-reflog] [--sort=] [--format=]
   [--merged ] [--no-merged ] [...]
   git tag -v [--format=] ...

Best,
Steffen


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Bug#1056990: src:linuxcnc: fails to migrate to testing for too long: unresolved RC issue

[Steffen Möller]

> Gesendet: Dienstag, 28. November 2023 um 10:35 Uhr
> Von: "andy pugh" 
> An: "EMC developers" 
> Betreff: Re: [Emc-developers] Bug#1056990: src:linuxcnc: fails to migrate to 
> testing for too long: unresolved RC issue
>
> On Mon, 27 Nov 2023 at 16:17, Paul Gevers  wrote:
>
> > The Release Team considers packages that are out-of-sync between testing
> > and unstable for more than 30 days as having a Release Critical bug in
> > testing [1].
>
> Can anyone explain what this means?  I understand the words but not
> what they mean when arranged in this order.

We will not be part of the next Debian release if we do not fix (or otherwise 
close) the bugs reported against our package.

Steffen


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Aw: Request for instructions how to contribute with technical documentation

[Steffen Möller]

Dear Zebb,

 

Thank you for your kind offer to help. Debian technical documentation somewhere may already have an answer to your question. I admit not to have checked. But if you would please check that and find that info missing, then please then send a diff to the authors of that document or a pull request of where the document resides.


 

You likely know that the documentation of Debian includes the documentation provided by the developers of the software that Debian builds and redistributes. So, if you are proficient with some software of Debian, maybe you truly want to contribute to the documentation of that software project, not of the documentation of Debian itself. With the typical software documentation it may be fair to say that the graphical support is lacking. So, if you know how to draw or how to make icons then you can be of immediate strong help for many projects, not only for the Debian infrastructure.

 

Debian and larger software projects, like KDE or Blender, have regular user meetings. Once you have started contributing, it seems fair to expect that you are invited to personal meetings, which should then help to find the right match of your personal skills with whatever bit is about to be developed (and not yet documented).

 

Best,
Steffen

 

Gesendet: Donnerstag, 23. November 2023 um 21:59 Uhr
Von: "Zebediah Beck" 
An: debian-devel@lists.debian.org
Betreff: Kein Betreff


Good day sir/madam
 

I'm a long time debian user but would like that contribute technical documentation to the community in thanks for your tireless work on this magnificent ecosystem.

 

Thanks

Zebb

Re: [Emc-developers] pull requestproduced ' Build CI: Some jobs were not successful'

[Steffen Möller]

Hi Thomas,

> Gesendet: Samstag, 25. November 2023 um 14:22 Uhr
> Von: "Thomas J Powderly" 
> An: emc-developers@lists.sourceforge.net
> Betreff: [Emc-developers] pull requestproduced ' Build CI: Some jobs were not 
> successful'
>
> Hello new to Git

It is all a bit much. But thank you for nibbling through that jungle. I am not 
so sure if LinuxCNC should describe GitHub in too much detail, but if you see 
that the one or other reference to some of the many tutorials of GitHub would 
have helped then please send another PR to improve the documentation :)

> I made a fork

good!

> made some changes did a 'push to master'

You mean to the master branch of your fork. That is technically fine, 
preferably though you would have committed to a new branch of yours (basically 
giving your changes a name) and then pushed that new branch to your forked 
repository. This way you can have several developments at the same time.

> did a pull request ( I think that's the procedure)

good!

> then got email that I
> don't understand 1st error in message is in 'Built Rip & test' message
> is Bar widgets #9519

That is the automated builds and testing that kicks in with every PR, so issues 
are caught as early as possible.

> pull request waspull request #2756 
> 
>
> line 23ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be
> preloaded (cannot open shared object file): ignored.
>
> really? lib eat my data? not eat my shorts?

That is a library accelerating I/O by not waiting for the hard drive. The 
LD_PRELOAD is a trick to override what the C library would normally do.

> Is the error is caused by my code?

This is not the error that caused the trouble. It is a test that failed, look at

https://github.com/LinuxCNC/linuxcnc/actions/runs/6939722284/job/18877492636?pr=2756
Look at line 9385

Running test: /home/runner/work/linuxcnc/linuxcnc/tests/twopass
Running test: /home/runner/work/linuxcnc/linuxcnc/tests/uspace/spawnv-root
Runtest: 260 tests run, 259 successful, 1 failed + 0 expected, 4 skipped
Failed:
/home/runner/work/linuxcnc/linuxcnc/tests/pyvcp-bar
Error: Process completed with exit code 1.

and then scrolling up to line 9310:

Running test: /home/runner/work/linuxcnc/linuxcnc/tests/pyvcp-bar
*** /home/runner/work/linuxcnc/linuxcnc/tests/pyvcp-bar: XFAIL: test run exited 
with 1
** result:
** stderr:
Traceback (most recent call last):
  File "/home/runner/work/linuxcnc/linuxcnc/bin/pyvcp", line 101, in 

main()
  File "/home/runner/work/linuxcnc/linuxcnc/bin/pyvcp", line 83, in main
Skipping disabled test: /home/runner/work/linuxcnc/linuxcnc/tests/raster
pyvcp0 = Tk()
  File "/usr/lib/python3.8/tkinter/__init__.py", line 2270, in __init__
self.tk = _tkinter.create(screenName, baseName, className, 
interactive, wantobjects, useTk, sync, use)
_tkinter.TclError: no display name and no $DISPLAY environment variable
test.hal:4: waitpid failed pyvcp fred
test.hal:4: pyvcp exited without becoming ready
Note: Using POSIX non-realtime
**
Running test: /home/runner/work/linuxcnc/linuxcnc/tests/realtime-math


What this means is that the test routine wants to open a window but cannot do 
so since it has no window system, so it complains about the DISPLAY variable 
not being set, which typically helps with a redirection of the display across 
machines, like when you are logged in remotely. There are tricks to circumvent 
this with Xnest but I do not feel competent to suggest how this should be 
introduced - I admittedly thought this would have been integrated already.

> Is the notification to all developers? or just to me & due to my coed?

The PR is visible to the world and so is the error report.
The error though was introduced only by your work. If you think that the test 
routines are to blame then please inspect them on .github/workflows/ci.yml .

> I have made more changes since then and want to push again
>
> but caution says ask 1st

I suggest you push what you want to push and risk running into that error again.

And then at some point we need to learn how to introduce the testing of GUIs 
that open windows in the CI.

Hoping to have helped
Steffen


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Aw: Debian 12 vs MySql WOrkbench

[Steffen Möller]

Hi Allan,

The status of the package is described on
https://tracker.debian.org/pkg/mysql-workbench

and you see it is waiting for another package to transition to testing, so it 
can migrate itself.

The bug it depends on is
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040290
and it is already fixed for several months, just apparently the maintainers did 
not get around to reupload a fixed version.

No idea how to speed this up. Man power is a thing. If you are using Debian on 
your very own hardware then I suggest to just use unstable, really. This is 
where you can run the very latest versions (why typically are just as good as 
what uptream provides), find problems and confirm fixes to work. And why not 
maintain a package of your interest yourself?

Steffen

> Gesendet: Dienstag, 21. November 2023 um 08:25 Uhr
> Von: "Allan Frank" 
> An: debian-project@lists.debian.org
> Betreff: Debian 12 vs MySql WOrkbench
>
> Hi Linux Debian 12
>
> Im a student and I use Debian 12 and in general very happy for that.
> Now according my edducation I need MySql Workbench, but as I see its in
> status "unstable" to Debian 12.
> Is there any fix for that issues in the near future ??
>
> Yes, I can use a ViatuelBox and have a whole other system there, but
> its not optimal.
>
> Let me hear from you, if there is any tips/fix or something I can do,
> that make the MySql Workbench work on Debian 12.
>
>
> Kind regards
> Allan Frank
> It-Arkitechtur
> IBA - Kolding
>
>

Aw: Re: Any suggestions for next Debian Med sprint (in person meeting)?

[Steffen Möller]

> [...]
> >> No better idea from my part. The location in Berlin was actually
> >> fine and I cannot propose a better (also closer to me) place. Last
> >> time we discussed this, you evoked a place in Hamburg. Which
> >> would not change a lot of things for me compared to Berlin.
> >
> > I remember someone suggested Hamburg but it was not me.  If the
> > person who suggested this would speak up it would be nice.
> > Otherwise I would ask Sascha to make suggestions when the known venue
> > is open for our sprint.
>
> I wouldn't mind going somewhere else for a change... but i can surely
> ask if we can have another weekend in February.

Hamburg would also be fine with me. Important for the med team is increasingly 
also what the ML team gets up to and the GPU acceleration fronts. Should we 
somehow reach out?

Best,
Steffen

[Emc-developers] Related bug (?) - "-uspace" mentioned in debian/rules.in Aw: Re: RTAI Package Building Failure

[Steffen Möller]

Hello,

I presume the linuxcnc-uspace should be substitute by @MAIN_PACKAGE_NAME@. I 
presume this also happened elsewhere during the installation of the examples.

Cheers,
Steffen

mc00023497:linuxcnc u005069$ grep -r uspace debian/rules.in 
debian/rules.in:dh_installdocs --doc-main-package=linuxcnc-uspace 
--package=linuxcnc-doc-de
debian/rules.in:mv 
debian/linuxcnc-doc-de/usr/share/doc/linuxcnc-uspace/gcode.html 
debian/linuxcnc-doc-de/usr/share/doc/linuxcnc-uspace/gcode_de.html
debian/rules.in:mv debian/linuxcnc-doc-de/usr/share/doc/linuxcnc-uspace 
debian/linuxcnc-doc-de/usr/share/doc/linuxcnc


> Gesendet: Montag, 23. Oktober 2023 um 11:08 Uhr
> Von: "Alec Ari via Emc-developers" 
> An: "EMC Developers" 
> Cc: "Alec Ari" 
> Betreff: Re: [Emc-developers] RTAI Package Building Failure
>
> I thought my local changes to prevent docs from building if `no-docs` is set 
> was the reason for this breakage, but I reverted my doc changes and I still 
> get this error:
> 
> # `.../doc/linuxcnc`) because that's where the
> # `linuxcnc` launcher script looks for them, and that's
> # inconvenient to change.
> dh_installdocs --doc-main-package=linuxcnc --package=linuxcnc
>     install -m0755 -d debian/linuxcnc/usr/share/doc/linuxcnc
>     install -p -m0644 debian/copyright 
> debian/linuxcnc/usr/share/doc/linuxcnc/copyright
> mkdir -p debian/linuxcnc/usr/share/doc/linuxcnc
> mv debian/linuxcnc/usr/share/doc/linuxcnc/examples 
> debian/linuxcnc/usr/share/doc/linuxcnc
> mv: cannot stat 'debian/linuxcnc/usr/share/doc/linuxcnc/examples': No such 
> file or directory
> make[1]: *** [debian/rules:88: override_dh_installdocs-arch] Error 1
> make[1]: Leaving directory '/home/ntu/linuxcnc-rtai-gnu11'
> make: *** [debian/rules:43: binary] Error 2
> dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned 
> exit status 2
> 
> Andy, you can probably get that one!
> 
> Alec
> 
> 
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] lost file or mind?

[Steffen Möller]

Hi Phill,

> Gesendet: Samstag, 07. Oktober 2023 um 07:54 Uhr
> Von: "Phill Carter via Emc-developers" 
> An: "linuxcnc-developers" 
> Cc: "Phill Carter" 
> Betreff: Re: [Emc-developers] lost file or mind?
>
>
> > On 7 Oct 2023, at 3:32 pm, Thomas J Powderly  wrote:
> >
> > Hello,
> >
> > I cannot find a file used in my .ini /
> > But the .ini runs fine from picker
> >
> > the 'lost' file from the iniT ...
> >
> > EMBED_TAB_COMMAND = pyvcp bars.xml
>
> The file name would be bars.xml
>
>
>
> >
> >
> > After a lot of searching, and failing to find the file,
> >
> > ( searching ~/linuxcnc and all branches of #PATH )
> >
> > I used the 'find' command on the _entire_ filesystem
> >
> > tomp@ThaiTowerD10:/$ cd /
> > tomp@ThaiTowerD10:/$ find . pyvcp_bars.xml
> > ... after a long time  I see:
> > find: 'pyvcp_bars.xml': No such file or directory

You omitted the "-name" argument, so the call would be
find . -name pyvcp_bars.xml

but considering the pointer by Thomas on the file bars.xml (pyvcp is the 
command to which bars.xml is the first argument from how I read this), you 
would search

find . -name bars.xml

You can also try

locate bars.xml

HTH
Steffen



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] Uploading 2.9 to Debian Aw: Re: Bug#1053251: How to fix this bug

[Steffen Möller]

Heyho, I just found https://github.com/LinuxCNC/linuxcnc/releases/tag/v2.9.0 - 
great!
I am literally on a train to towards the LinuxCNC meeting, will wait for Seb to 
declare that he will upload again or the upload myself during the meeting.

> Gesendet: Donnerstag, 05. Oktober 2023 um 14:07 Uhr
> Von: "Rod Webster" 
> An: "EMC developers" 
> Betreff: Re: [Emc-developers] Bug#1053251: How to fix this bug
>
> > So, I tend to think that everything starts with an update of the package in 
> > Debian unstable - this could easily be another pre-releases - just anything 
> > with a tag would do :)
> Please run with this, release 2.9 now and upload to unstable. Then
> getting in the next Debian point release will be a piece of cake (
> maybe coinciding with our own Linuxcnc 2.9.1 point release).
> 
> Rod Webster
> 1300 896 832
> +61 435 765 611
> Vehicle Modifications Network
> www.vehiclemods.net.au
> 
> On Thu, 5 Oct 2023 at 21:05, Steffen Möller  wrote:
> >
> >
> >
> > > Gesendet: Donnerstag, 05. Oktober 2023 um 00:35 Uhr
> > > Von: "andy pugh" 
> > > An: "EMC developers" 
> > > Betreff: Re: [Emc-developers] Bug#1053251: How to fix this bug
> > >
> > > On Wed, 4 Oct 2023 at 23:04, Rod Webster  wrote:
> > >
> > > > Andy,
> > > >
> > > > I think this describes the process.
> > > >
> > > > https://www.debian.org/doc/manuals/developers-reference/pkgs.html
> > > >
> > >
> > > Yeah, I hadn't realised that the system sends the question to the
> > > maintainer (so I am in effect asking myself for help...)
> > > I was hoping for some input from the Debian dudes.
> >
> > I have only uploaded to the Debian backports, not to point-update of a 
> > regular release.
> > Am not exactly sure about what to do. For regular backports there is a rule 
> > that anything backported to stable needs to be available on testing, too. I 
> > see the Debian release managers frown upon us if we fix something in a 
> > point release but have that issue untreated in testing and unstable.
> >
> > So, I tend to think that everything starts with an update of the package in 
> > Debian unstable - this could easily be another pre-releases - just anything 
> > with a tag would do :)
> >
> > Steffen
> >
> >
> >
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
> 
> 
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Upcoming stable (12.2) and oldstable (11.8) point releases

[Steffen Möller]

> Gesendet: Donnerstag, 05. Oktober 2023 um 13:07 Uhr
> Von: "andy pugh" 
> An: "EMC developers" 
> Betreff: Re: [Emc-developers] Upcoming stable (12.2) and oldstable (11.8) 
> point releases
>
> On Fri, 1 Sept 2023 at 17:58, Jonathan Wiltshire  wrote:
> >
> > The next point releases for "bookworm" (12.2) and "bullseye" (11.8) will
> > take place on Saturday, October 7th 2023. Processing of new uploads into
> > the relevant queues will be frozen the preceding weekend.
>
> I just noticed the last sentence. I have been working 18 hour days to
> hit the wrong deadline. It's already too late.

Thank you for this. There will be another one,
https://wiki.debian.org/DebianReleases/PointReleases
says about every two months.

Best,
Steffen


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Bug#1053251: How to fix this bug

[Steffen Möller]

> Gesendet: Donnerstag, 05. Oktober 2023 um 00:35 Uhr
> Von: "andy pugh" 
> An: "EMC developers" 
> Betreff: Re: [Emc-developers] Bug#1053251: How to fix this bug
>
> On Wed, 4 Oct 2023 at 23:04, Rod Webster  wrote:
>
> > Andy,
> >
> > I think this describes the process.
> >
> > https://www.debian.org/doc/manuals/developers-reference/pkgs.html
> >
>
> Yeah, I hadn't realised that the system sends the question to the
> maintainer (so I am in effect asking myself for help...)
> I was hoping for some input from the Debian dudes.

I have only uploaded to the Debian backports, not to point-update of a regular 
release.
Am not exactly sure about what to do. For regular backports there is a rule 
that anything backported to stable needs to be available on testing, too. I see 
the Debian release managers frown upon us if we fix something in a point 
release but have that issue untreated in testing and unstable.

So, I tend to think that everything starts with an update of the package in 
Debian unstable - this could easily be another pre-releases - just anything 
with a tag would do :)

Steffen



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Upcoming stable (12.2) and oldstable (11.8) point releases

[Steffen Möller]

> Von: "Andy Pugh" 

> How did the current image get there? 

Packages uploaded to unstable migrate to testing after five days and every two 
years what is in testing is renamed to stable.

> Who submitted it?

We are three who could upload new versions to Debian (Sebastian, Petter, me). 

> Who understands the process?

I have never contributed to a point release before, have no exact idea. I would 
anyway suggest to go first to have an upload to stable-backports and once we 
know this to work we can then request something for the point release.

> 
> Time is getting short and the current version has a serious uncommanded 
> motion bug. 

There will be another update (12.3), and I guess the word is out that the 
version currently in Debian should not be used, so I am not ultimately worried 
(maybe I should be). The point release update I would very much like to reserve 
for the 2.9 release.

Best,
Steffen




> > On 1 Sep 2023, at 18:40, andy pugh  wrote:
> > 
> > Is this an opportunity to get some bugfixes into the version that we
> > are distributing? It is fairly broken.
> > 
> > -- Forwarded message -
> > From: Jonathan Wiltshire 
> > Date: Fri, 1 Sept 2023 at 17:58
> > Subject: Upcoming stable (12.2) and oldstable (11.8) point releases
> > To: 
> > 
> > 
> > The next point releases for "bookworm" (12.2) and "bullseye" (11.8) will
> > take place on Saturday, October 7th 2023. Processing of new uploads into
> > the relevant queues will be frozen the preceding weekend.
> > 
> > --
> > Jonathan Wiltshire  j...@debian.org
> > Debian Developer http://people.debian.org/~jmw
> > 
> > 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
> > ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
> > 
> > 
> > 
> > -- 
> > atp
> > "A motorcycle is a bicycle with a pandemonium attachment and is
> > designed for the especial use of mechanical geniuses, daredevils and
> > lunatics."
> > — George Fitch, Atlanta Constitution Newspaper, 1912
> > 
> 
> 
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] wiped out lcnc on my pi

[Steffen Möller]

I do not understand everything, yet, but came up with
https://github.com/LinuxCNC/linuxcnc/pull/2647
to reduce xvfb from the build-dependencies when DEB_BUILD_OPTIONS=nocheck
is set as an environment variable.

Best,
Steffen

> Gesendet: Dienstag, 19. September 2023 um 09:16 Uhr
> Von: "gene heskett" 
> An: emc-developers@lists.sourceforge.net
> Betreff: Re: [Emc-developers] wiped out lcnc on my pi
>
> On 9/18/23 23:32, Rod Webster wrote:
> > Gene, Use this link.
> > https://drive.google.com/drive/folders/1Bv4ceKAa0nYwDvc5eVNYFtU24PQGjKfQ
> > I rebuilt the image last night as there was an update to the PREEMPT_RT
> > patch.
>
> Got it coming in now, thanks Rod. Got it. It will be interesting to see
> what debian looks like on my rpi4b. I see the kernel is 6.1.46. My
> armbian's are up to 6.1.50 a/o a couple days ago. I'm using
> bannanapi-m5's to drive 3d printers running klipper.  Updates are quite
> rapid. Its interesting that the gui for clipper is web based, and some
> parts of it show empty screens on the pi's firefox, but work well when I
> send this machines firefox to look at bpi52:80
>
> Many thanks Rod.
>
> > Also a 2.9 ISO for AMD64 is here
> > https://drive.google.com/drive/folders/1kW9GkNFZ7eZkfQSQPkiCHNDEXyBEfdnP
> >
> > There may be some missing dependencies that have snuck into the Linuxcnc
> > source.that are not listed in the deb files on both images
> >
> > Rod Webster
> > *1300 896 832*
> > +61 435 765 611
> > Vehicle Modifications Network
> > www.vehiclemods.net.au
>
> Take care & stay well.
>
> Cheers, Gene Heskett.
> --
> "There are four boxes to be used in defense of liberty:
>   soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author, 1940)
> If we desire respect for the law, we must first make the law respectable.
>   - Louis D. Brandeis
> Genes Web page 
>
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] wiped out lcnc on my pi

[Steffen Möller]

Hi Gene,

The build script does not install two packages that are required for the build, 
according to what the self-description of the Debian package of LinuxCNC 
states. This is stated in the line
"dpkg-checkbuilddeps: error: Unmet build dependencies: libgpiod-dev xvfb"
To help out, prior to your next run of buster-make-debs.sh, run

sudo apt install libgpiod-dev xvfb

which should install those missing build-deps.

The script then apparently tries to move the resulting .deb files that are not 
existing because the build never started because of those missing build deps. 
That is a(n easily fixable) problem of the script.

Best,
Steffen

(traveling, not sending patches :-) )

. This are

> Gesendet: Sonntag, 17. September 2023 um 11:28 Uhr
> Von: "gene heskett" 
> An: "EMC Developers" 
> Betreff: [Emc-developers] wiped out lcnc on my pi
>
> Trying to update my rpi4 running buster, but --fix-broken removed the
> executables.
>
> So I try to run my buildit script which builds the debs.
> that fails, broken dependencies:
> pi@rpi4:/media/pi/workspace $ time ./buster-make-debs.sh
> uspace is accepted for compatibility, but ignored
> successfully configured for 'uspace-Raspbian-10'..
> 5 /media/pi/workspace/buster-linuxcnc
> dpkg-checkbuilddeps: error: Unmet build dependencies: libgpiod-dev xvfb
> 7 /media/pi/workspace/buster-linuxcnc
> dpkg-buildpackage: info: source package linuxcnc
> dpkg-buildpackage: info: source version 1:2.10.0~pre0
> dpkg-buildpackage: info: source distribution UNRELEASED
> dpkg-buildpackage: info: source changed by Andy Pugh 
> dpkg-buildpackage: info: host architecture armhf
>   dpkg-source --before-build .
> dpkg-checkbuilddeps: error: Unmet build dependencies: libgpiod-dev xvfb
> dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied;
> aborting
> dpkg-buildpackage: warning: (Use -d flag to override.)
> mv: cannot stat '*.deb': No such file or directory
>
> real0m4.396s
> user0m3.275s
> sys 0m0.866s
>
> What should I do next?
>
> Thank you.
>
> Cheers, Gene Heskett.
> --
> "There are four boxes to be used in defense of liberty:
>   soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author, 1940)
> If we desire respect for the law, we must first make the law respectable.
>   - Louis D. Brandeis
> Genes Web page 
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] My rpi4b running my sheldon

[Steffen Möller]

Dear all,

it would not be ultimately problematic to upload a new version to Debian and 
then have that backported to Bookworm and then Bullseye (which would then be in 
backports.debian.org, but easily installable). From what I remotely observe, 
this should fix the installation woes.

I am a bit blank about who is in charge about the Debian uploads - it is not 
me, right? :) Tell me so if you think otherwise or if I shall help out.

Best,
Steffen

> Gesendet: Freitag, 18. August 2023 um 18:33 Uhr
> Von: "Rod Webster" 
> An: "EMC developers" 
> Betreff: Re: [Emc-developers] My rpi4b running my sheldon
>
> Gene, there are no buildbots for Bookworm (or Bullseye for that matter).
> The Bookworm package is quite old (Feb 2023 I think)
> So I think you have no choice but to build from source so it may not matter
> which OS you use.
> The ARM64 support is really spotty and while there are a few unofficial
> images, you have no idea what they are or how old they are.
> I outlined a known working solution using bookworm
> http://linuxcnc.org/docs/2.9/html/getting-started/getting-linuxcnc.html
> Going this way actually shortens the dependency list a lot when you build
> from source.
>
> However the way you work, I would explore building the Raspberry pi Cross
> compiler on a X86 machine which outputs an image file you burn to the pi
> with the normal pi imager.
>
> I shared some links in an issue here
> https://github.com/LinuxCNC/linuxcnc/issues/2349 about this
> If you start with the upstream source and  work through David Smiths git
> example, you will see how he patched for prempt_RT kernel and built
> Linuxcnc and ethercat via scripts. I link to the relevant file. I have done
> this and it works. Its just a bit old but it would be pretty easy to
> refresh it.
>
> I will have a go at this one day. My current project is a  live
> build/installer for X86 machines using Bookworm and the buildbot debs. I
> got this working yesterday, it just needs a bit of rine tuning.
>
> Rod Webster
> *1300 896 832*
> +61 435 765 611
> Vehicle Modifications Network
> www.vehiclemods.net.au
>
>
> On Sat, 19 Aug 2023 at 01:48, gene heskett  wrote:
>
> > On 8/18/23 10:09, gene heskett wrote:
> > > Several problems? this morning.
> > > 1. Used synaptic to fix broken-packages by removing my locally built
> > > linuxcnc-v2.10.0 pacakages.
> > >
> > > 1a. debians arm64 netinstall, put on an sd card doesn't even try to
> > > boot. Apparently no u-boot or miss-configured for a raspberry pi or a
> > > bananapi-m5.
> > >
> > > 2. Linuxcnc en docs could then be installed from the buildbot but
> > > linuxcnc-uspace had missing dependencies and would not install from the
> > > buildbot.
> > >
> > > 3. Made new .debs from this mornings git pull and installed them with
> > > dpkg -l, but dpkg claimed missing dependency's and would not finish the
> > > configuration.
> > > missing dependency's are:
> > > ===
> > > pi@rpi4:/media/pi/workspace $ sudo ./buster-lcnc-install.sh
> > > Selecting previously unselected package linuxcnc-uspace-dbgsym.
> > > (Reading database ... 422403 files and directories currently installed.)
> > > Preparing to unpack linuxcnc-uspace-dbgsym_2.10.0~pre0_armhf.deb ...
> > > Unpacking linuxcnc-uspace-dbgsym (1:2.10.0~pre0) ...
> > > Selecting previously unselected package linuxcnc-uspace-dev.
> > > Preparing to unpack linuxcnc-uspace-dev_2.10.0~pre0_armhf.deb ...
> > > Unpacking linuxcnc-uspace-dev (1:2.10.0~pre0) ...
> > > Selecting previously unselected package linuxcnc-uspace.
> > > Preparing to unpack linuxcnc-uspace_2.10.0~pre0_armhf.deb ...
> > > Unpacking linuxcnc-uspace (1:2.10.0~pre0) ...
> > > dpkg: dependency problems prevent configuration of linuxcnc-uspace:
> > >   linuxcnc-uspace depends on python3-poppler-qt5; however:
> > >Package python3-poppler-qt5 is not installed.
> > >
> > > dpkg: error processing package linuxcnc-uspace (--install):
> > >   dependency problems - leaving unconfigured
> > > dpkg: dependency problems prevent configuration of
> > linuxcnc-uspace-dbgsym:
> > >   linuxcnc-uspace-dbgsym depends on linuxcnc-uspace (= 1:2.10.0~pre0);
> > > however:
> > >Package linuxcnc-uspace is not configured yet.
> > >
> > > dpkg: error processing package linuxcnc-uspace-dbgsym (--install):
> > >   dependency problems - leaving unconfigured
> > > dpkg: dependency problems prevent configuration of linuxcnc-uspace-dev:
> > >   linuxcnc-uspace-dev depends on linuxcnc-uspace (= 1:2.10.0~pre0);
> > > however:
> > >Package linuxcnc-uspace is not configured yet.
> > >
> > > dpkg: error processing package linuxcnc-uspace-dev (--install):
> > >   dependency problems - leaving unconfigured
> > > Processing triggers for man-db (2.8.5-2) ...
> > > Processing triggers for libc-bin (2.28-10+rpt2+rpi1+deb10u1) ...
> > > Processing triggers for gnome-menus (3.31.4-3) ...
> > > Processing triggers for desktop-file-utils (0.23-4) ...
> > > Processing triggers for mime-support (3.62) ...

[Emc-developers] HAL Web Server as tutorial - found Rockhopper

[Steffen Möller]

Hello,

I had thought that it would be an interesting extension of HAL to come up with 
a web server as a component, maybe as a tutorial project and it would very much 
reflect how I have understood how the GUIs are working. I Googled this up and 
came across
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Rockhopper_Web_Server
which I thought would be a nice extension say for some remote monitoring just 
as it is. Is anything speaking against packaging this up for Debian? I need to 
look at this in more detail to learn what the exact difference is to what I 
thought to implement.

Best,
Steffen


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Downloading of DOCS still an issue

[Steffen Möller]

Hello,

> Gesendet: Freitag, 11. August 2023 um 09:38 Uhr
> Von: "Marius" 
>
> There seem to be a problem with the DOCS on the server. Upgrading is not
> possible if the docs are included as they just will not download at all
> or take many hours if they do download.
>
> I reported this before but it seems to be still ongoing issue.

I'm a bit puzzled by the issue you've mentioned regarding the DOCS on the 
server. I thought it might be connected to the online documentation on the web 
server, but it seems that part is working fine for the sections I checked.

Could you provide more details about the problem? Is it related to a Debian 
documentation package? If you have specific steps or commands to recreate the 
error, please share them.

If someone else on this list can already reproduce this issue, please step 
forward :)

Sorry for the delay in getting back to you. We're here to help, so the more 
information you can give us, the better. With more details, I'm sure someone 
with expertise will come forward to address the issue.

Many thanks!
Steffen



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Aw: GENtle - some progress

[Steffen Möller]

Quick update - upstream was very happy to see a first bunch of patches and 
created
https://github.com/GENtle-persons/gentle-m
with membership to GENtle-persons initially offered to Andreas and myself (I 
already accepted).

So, I think my next steps are to transfer d/patches/* to an upstream dev branch 
and then sync with upstream about a new point release.

Best,
Steffen

> Gesendet: Montag, 31. Juli 2023 um 12:39 Uhr
> Von: "Steffen Möller" 
> An: "Med Team" 
> Betreff: GENtle - some progress
>
> Hello,
> 
> I just uploaded another iteration of GENtle to our servers. It has some 
> quirks, still, as in that wxWidgets' runtime checks kick in with the one or 
> other window that is opened, something about the windows parents not set 
> right, but I guess this is usable. I'll finish this up over the next weeks.
> 
> Some background, GENtle comes from a time when the cloning of DNA (as in: get 
> some large string of unknown DNA of interest connected in a much larger piece 
> of well-known DNA that can be multiplied by bacteria) was a precondition to 
> get that DNA sequenced. With technological advancements that has mostly been 
> substituted with "let us just sequence the whole organism". And there is 
> software like https://www.snapgene.com/ doing many things right that come to 
> a rescue for smaller groups and/or smaller projects, and for all the many 
> tasks like amplifying the gene product of what was cloned (as in producing 
> insulin, see https://openinsulin.org/).
> 
> IMHO times have changed again in that we already have sequenced of what we 
> want to see sequenced and now the research community shifted from "get DNA 
> out from human cells" to "get DNA into (typically cultures of) human cells". 
> To move any gene across the cell wall, you need a special kind of vehicle, 
> and technically those look just like those plasmids that GENtle already knows 
> how to design. So this is not just some old outdated technology lurking with 
> us, we should just think about how we can modernize the GUI a bit and maybe 
> add some public data.
> 
> I'll discuss data to be added with my wet-lab colleagues, also some 
> imperfections in software may be ideal as student projects to 
> describe/fix/learn, will see.
> 
> Best,
> Steffen
> 
>

GENtle - some progress

[Steffen Möller]

Hello,

I just uploaded another iteration of GENtle to our servers. It has some quirks, 
still, as in that wxWidgets' runtime checks kick in with the one or other 
window that is opened, something about the windows parents not set right, but I 
guess this is usable. I'll finish this up over the next weeks.

Some background, GENtle comes from a time when the cloning of DNA (as in: get 
some large string of unknown DNA of interest connected in a much larger piece 
of well-known DNA that can be multiplied by bacteria) was a precondition to get 
that DNA sequenced. With technological advancements that has mostly been 
substituted with "let us just sequence the whole organism". And there is 
software like https://www.snapgene.com/ doing many things right that come to a 
rescue for smaller groups and/or smaller projects, and for all the many tasks 
like amplifying the gene product of what was cloned (as in producing insulin, 
see https://openinsulin.org/).

IMHO times have changed again in that we already have sequenced of what we want 
to see sequenced and now the research community shifted from "get DNA out from 
human cells" to "get DNA into (typically cultures of) human cells". To move any 
gene across the cell wall, you need a special kind of vehicle, and technically 
those look just like those plasmids that GENtle already knows how to design. So 
this is not just some old outdated technology lurking with us, we should just 
think about how we can modernize the GUI a bit and maybe add some public data.

I'll discuss data to be added with my wet-lab colleagues, also some 
imperfections in software may be ideal as student projects to 
describe/fix/learn, will see.

Best,
Steffen

Re: [Emc-developers] configure

[Steffen Möller]

Hi Andy,

I suggest not to bother for now. Sounds like a great entry-level job for the 
next generation of devs joining to become familiar with it all. :)

Best,
Steffen

> Gesendet: Montag, 24. Juli 2023 um 23:19 Uhr
> Von: "andy pugh" 
> An: "EMC developers" 
> Betreff: [Emc-developers] configure
>
> I am looking through the configure script and I amazed how much stuff
> there is in there that probably isn't needed.
> 
> 
> # m...@cis.ufl.edu says -lnsl (and -lsocket) are needed for his 386/AT,
> # to get the SysV transport functions.
> # Chad R. Larson says the Pyramis MIS-ES running DC/OSx (SVR4)
> # needs -lnsl.
> # The nsl library prevents programs from opening the X display
> # on Irix 5.2, according to T.E. Dickey.
> # The functions gethostbyname, getservbyname, and inet_addr are
> # in -lbsd on LynxOS 3.0.1/i386, according to Lars Hecking.
> ac_fn_c_check_func "$LINENO" "gethostbyname" "ac_cv_func_gethostbyname"
> if test "x$ac_cv_func_gethostbyname" = xyes; then :
> 
> For one example
> 
> I don't suppose it is worth trying to remove it all, we will just
> break it, but, blimey, this code must be 30 years old if Irix5.2
> (released in 1993) is relevant.
> 
> -- 
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1912
> 
> 
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Aw: Should cocotb & pyuvm be under Electronics or Python team ?

[Steffen Möller]

Hello,

Thank you for your work!

I suggest to direct to electronics about everthing that is tailored for the 
electronics and only have non-electronic-specific dependencies with the Python 
repository.

Best,
Steffen

> Gesendet: Sonntag, 23. Juli 2023 um 01:51 Uhr
> Von: "أحمد المحمودي" 
> An: debian-python@lists.debian.org, 
> pkg-electronics-de...@alioth-lists.debian.net
> Betreff: Should cocotb & pyuvm be under Electronics or Python team ?
>
> Hello, 
> 
>   I am currently working on packages for cocotb & pyuvm, both are Python 
>   packages, that are used for verification (simulation) of VHDL/*Verilog 
>   models, ie. their scope is electronics. Do I am wondering whether to 
>   package them under Electeonics team or Python team.
> 
>   Also, I've set the Section source control field to 'electronics', yet 
>   lintian complained that since the binary package names are 
>   python3-{cocotb/pyuvm}, then the section should be 'python'. Should I 
>   ignore/override that ? Or should I modifybthe Section field to 
>   'python' ?
> 
> Thanks
> 
> 
> -- 
> ‎أحمد المحمودي (Ahmed El-Mahmoudy)
>  Digital design engineer
> GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
> GPG Fingerprints:
>  6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
>  8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7
>

Re: [Emc-developers] debian recommends in control needs a small change

[Steffen Möller]

> Gesendet: Sonntag, 16. Juli 2023 um 07:34 Uhr
> Von: "Chris Morley" 
> An: "EMC DEV" 
> Betreff: [Emc-developers] debian recommends in control needs a small change
>
> Recommends:
>
>
> python3-pyqt5.qtwebkit,
>
> qtwebkit has been replaced in newer system with python3-pyqt5.qtwebengine
> In some systems both are available.
>
> Is there a way to favor the new package but fallback on the old?
>
> is it:
> python3-pyqt5.qtwebengine | python3-pyqt5.qtwebkit
>
Hi Chris,
What you proposed looks perfectly fine to me. I am uncertain if this should 
have any effect on the automated testing - likely not.
Best,
Steffen


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Shall LinuxCNC ship automated translations?

[Steffen Möller]

> Gesendet: Dienstag, 11. Juli 2023 um 13:24 Uhr
> Von: "devin chen" 
> An: "EMC developers" 
> Betreff: Re: [Emc-developers] Shall LinuxCNC ship automated translations?
>
> Steffen Möller  于2023年7月2日周日 00:50写道：
> 
> >  While transitioning to Weblate, we lost the bit that we had in Chinese. I
> > would love to give it a try to just go and autogenerate the Chinese and
> > then see how it is received.
> >
> 
> I am a Chinese user.  To be honest, I'm not familiar with weblate, but if
> you try to auto generate Chinese, you can send me a copy in some way, like
> send me a link, or a preview.
> 
Hi Devin,
Thank you tons for getting in touch. I'll talk back to Petter how to best 
address this technically now.
Best,
Steffen


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Aw: Re: Removing ATLAS?

[Steffen Möller]

Hi all,

EMMAX is (was) important
https://genome.sph.umich.edu/wiki/EMMAX

but I admittedly cannot invest into maintaining this or atlas.
My suggestion would be to talk back to upstream about transitioning to an 
alternative. I have no idea about how difficult this would be to patch 
ourselves.

Best,
Steffen

> Gesendet: Montag, 10. Juli 2023 um 22:01 Uhr
> Von: "Andreas Tille" 
> An: debian-science@lists.debian.org
> Betreff: Re: Removing ATLAS?
>
> Hi Sébastian,
> 
> Am Sat, Jul 08, 2023 at 10:01:15AM +0200 schrieb Sébastien Villemot:
> > 
> > So, given all that, I’m inclined to (try to) remove atlas during the
> > trixie development cycle.
> 
> Sounds reasonable.
>  
> > Any thought on this?
> 
> I've checked my responsibility for the dependencies and stumbled about
> emmax
> 
> 
> emmax.c:10:10: fatal error: clapack.h: No such file or directory
>10 | #include 
>   |  ^~~
> compilation terminated.
> 
> 
> and noticed
> 
> $ apt-file search clapack.h
> libatlas-base-dev: /usr/include/x86_64-linux-gnu/clapack.h
> ... (other instances are not blas related)
> 
> which was probably the reason why I've picked libatlas-base-dev
> originally.  I would not say that emmax is important and its
> also a not maintained upstream any more.  However, I vaguely
> remember that this
>#include 
> in some code pieces of Debian Med was the reason to actually
> pick this blas implementation.  Any hint how to deal with such
> cases?
>  
> Kind regards
> Andreas.
>  
> > Checking reverse dependencies...
> > # Broken Depends:
> > ceres-solver: libceres-dev
> >   libceres3
> > colmap: colmap [amd64 arm64 i386 mips64el mipsel ppc64el s390x]
> > dune-common: libdune-common-dev
> > emmax: emmax
> > ergo: ergo
> > iml: libiml0
> > nipy: python3-nipy-lib [armel mipsel]
> > psfex: psfex
> > python-escript: python3-escript [armel mipsel]
> > python3-escript-mpi [armel mipsel]
> > qm-dsp: libqm-dsp0
> > scamp: scamp [amd64 arm64 mips64el ppc64el s390x]
> > scikit-misc: python3-skmisc
> > sight: libsight [amd64]
> > source-extractor: source-extractor
> > xmds2: xmds2
> > 
> > # Broken Build-Depends:
> > ceres-solver: libatlas-base-dev
> > dune-common: libatlas-base-dev
> > emmax: libatlas-base-dev
> >libatlas3-base
> > ergo: libatlas-base-dev
> > ghmm: libatlas-base-dev
> > halide: libatlas-base-dev
> > hpcc: libatlas-base-dev
> > iml: libatlas-base-dev
> > ncl: libatlas3-base
> > odin: libatlas-base-dev
> > opm-material: libatlas-base-dev
> > phast: libatlas-base-dev
> > plink1.9: libatlas-base-dev
> > plink2: libatlas-base-dev
> > psfex: libatlas-base-dev
> > qm-dsp: libatlas-base-dev
> > scamp: libatlas-base-dev
> > scikit-misc: libatlas-base-dev
> > source-extractor: libatlas-base-dev
> > theli: libatlas-base-dev
> > xmds2: libatlas-base-dev
> > 
> > Dependency problem found.
> > 
> 
> 
> 
> 
> -- 
> http://fam-tille.de
> 
>

[Emc-developers] Shall LinuxCNC ship automated translations?

[Steffen Möller]

Hello,

Weblate brings us the option to provide the docs in another language without 
manual interference - you just press a button and anything marked as "needs 
editing" or that is yet untranslated will get an automated translation. While 
transitioning to Weblate, we lost the bit that we had in Chinese. I would love 
to give it a try to just go and autogenerate the Chinese and then see how it is 
received. If it is no good then it would be darn easy to have it removed again. 
I consider it to be a friendly invitation to our community.

Best,
Steffen






___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Bug#1037221: Bug#1037221: linuxcnc: Prepared to support Bullseye version for 3-4 years?

[Steffen Möller]

> Gesendet: Mittwoch, 14. Juni 2023 um 14:35 Uhr
> Von: "andy pugh" 
> An: "Steffen Möller" 
> Cc: emc-developers@lists.sourceforge.net
> Betreff: Re: [Emc-developers] Bug#1037221: Bug#1037221: linuxcnc: Prepared to 
> support Bullseye version for 3-4 years?
>
> > I backport sounds reasonable to me. Would want to wait for the official 2.9 
> > in Debian testing, though.
> 
> Maybe someone can explain some things to me:
> 
> 1) Why does the bug title reference Bullseye? I wasn't aware that
> there was a version of LinuxCNC in Bullseye?

Bookworm, not bullseye.

> 2) Is there a mechanism to release updates to software between Debian
> versions? Or are we now stuck with the February(?) snapshot until
> Trixie is released?

Difficult - backports are no problems but those are distributed separately. 
Security concers are the best motivator to get packages in after a release.



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Bug#1037221: Aw: [Emc-developers] Bug#1037221: Bug#1037221: linuxcnc: Prepared to support Bullseye version for 3-4 years?

[Steffen Möller]

> Gesendet: Samstag, 10. Juni 2023 um 18:15 Uhr
> Von: "Andy Pugh" 
> An: "EMC developers" 
> Cc: 1037...@bugs.debian.org
> Betreff: [Emc-developers] Bug#1037221: Bug#1037221: linuxcnc: Prepared to 
> support Bullseye version for 3-4 years?
>
> 
> 
> > On 10 Jun 2023, at 16:34, Petter Reinholdtsen  wrote:
> > 
> > [Andy Pugh]
> >> I don't fully understand the question.
> > 
> > The purpose of my question is to make sure the project understand the
> > current version in Debian Testing is the one that will be around in
> > Debian for the duration of Debian 12 Bookworm
> 
> Is there really no opportunity to push an updated version at this point? 
> 
> I suppose we can always point users at our own repository if they want the 
> new stuff (like the Mesa modbus driver)

I backport sounds reasonable to me. Would want to wait for the official 2.9 in 
Debian testing, though.

Steffen

Re: [Emc-developers] Bug#1037221: Bug#1037221: linuxcnc: Prepared to support Bullseye version for 3-4 years?

[Steffen Möller]

> Gesendet: Samstag, 10. Juni 2023 um 18:15 Uhr
> Von: "Andy Pugh" 
> An: "EMC developers" 
> Cc: 1037...@bugs.debian.org
> Betreff: [Emc-developers] Bug#1037221: Bug#1037221: linuxcnc: Prepared to 
> support Bullseye version for 3-4 years?
>
> 
> 
> > On 10 Jun 2023, at 16:34, Petter Reinholdtsen  wrote:
> > 
> > [Andy Pugh]
> >> I don't fully understand the question.
> > 
> > The purpose of my question is to make sure the project understand the
> > current version in Debian Testing is the one that will be around in
> > Debian for the duration of Debian 12 Bookworm
> 
> Is there really no opportunity to push an updated version at this point? 
> 
> I suppose we can always point users at our own repository if they want the 
> new stuff (like the Mesa modbus driver)

I backport sounds reasonable to me. Would want to wait for the official 2.9 in 
Debian testing, though.

Steffen


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Where to put a file?

[Steffen Möller]

> Gesendet: Dienstag, 06. Juni 2023 um 01:21 Uhr
> Von: "andy pugh" 
> An: "EMC developers" 
> Betreff: [Emc-developers] Where to put a file?
>
> I am trying to add the mesa_modbus framework into the build, targeted
> for linuxcnc-dev
>
> I think it is fairly clear the executable Python file "modcompile"
> should be parked in linuxcnc-dev/bin and then installed to /bin
>
> However there is a C template (mesa_modbus.c) that is needed, and I
> don't know where that should live. Possibly in /share/ ?

That sounds about right to me. If I would look for that file, my first checks 
would be /usr/share/linuxcnc/{src,template,...}/

>
> Any better ideas? I suppose the only other options are /lib and /include ?
lib would rather be for binary files and include, hm, not since the file itself 
is not compiled?

> The file is copied to a temp directory before being compiled, so does
> not have to remain as a .c file, if something else would make sense. (
> mesa_modbus.templ?)
mesa_modbus.c.tmpl ?

Best,
Steffen


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Aw: Re: Please review release notes patch

[Steffen Möller]

Heya,

> Gesendet: Donnerstag, 25. Mai 2023 um 09:51 Uhr
> Von: "Andreas Tille" 
> An: debian-med@lists.debian.org
> Cc: "Steffen Möller" 
> Betreff: Re: Please review release notes patch
>
> Hi Nilesh,
> 
> Am Wed, May 24, 2023 at 10:16:22PM +0530 schrieb Nilesh Patra:
> > On Wed, May 24, 2023 at 11:28:13AM +0200, Pierre Gruet wrote:
> > > Le 24/05/2023 à 08:25, Andreas Tille a écrit :
> > > >
> > > > https://salsa.debian.org/med-team/community/communication/-/blob/master/releasenotes/bookworm/release-notes.patch
> > > > 
> > > > Please review and comment on it (or just push fixes and enhancements)!
> > > Is there any important piece of software we packaged during this release
> > > cycle and that could be worth highlighting? From my limited perspective I
> > > have none that comes to mind, but maybe it will for someone else.
> > 
> > I do remember that during the bullseye release, we were looking forward
> > to get nextflow into bookworm. AFAICS, that did not happen but I do see
> > a capsule-nextflow package.
> > Although it is mostly a deployment tool, _maybe_ it is worth a mention?
> > 
> > I've CC'ed Steffen for any inputs about the same.
> 
> Steffen?

Nextflow has not made it. Pierre summarized the state not to long ago.
The problem was the change to the build tool that Debian does not support its 
latest version. 

> IMHO I consider it less worth mentioning than shiny-server.

shiny-server is a piece of infrastructure to run services, obviously.
It is important, although many would say that it is not a core piece of 
bioinformatics.
I propose to adjust the release notes accordingly, also adopting a bit of what 
Pierre described wrt dependencies. Here my shot:


For the past 20 years, Debian has been a trusted distributor of software for 
the Life Sciences and Medicine, offering all the benefits that come with Debian 
as a distribution. This commitment has supported education, research, and 
service providers who rely on web-based software solutions. Particularly in the 
life sciences field, where data often exceeds transport capacity, Debian's 
contributions are of immense value. With the release of Debian Bookworm, we are 
excited to introduce the shiny-server package, which enables the creation of 
scientific web applications using the statistical environment R.


Much of our work goes unnoticed by users who simply see their familiar packages 
updated. However, behind the scenes, we continuously strive to improve the 
reliability and quality of our software. Through enhanced Continuous 
Integration support, the packages maintained by the Debian Med team undergo 
official auto-tests and additional tests developed by our team. By keeping 
software dependencies up to date, multiple packages can work seamlessly 
together, benefiting from the collective identification of issues and ensuring 
a smooth user experience. Any patches we create are shared back with the 
original developers, allowing Debian Med to remain closely aligned with the 
original sciences.


Bookworm ships with >1000 packages that are maintained by the Debian Med group 
that are kept compatible with the very latest versions of the software itself, 
but most work is invested into maintaining that often aging but established 
software to remain compatible with the latest versions of the shared libraries 
that often experiences incompatible changes to their API. This effort has 
become increasingly difficult over the past years as softwares have grown in 
complexity with many more dependencies, and also seeing many overlaps with 
other disciplines, such that the contributors to Debian Med also find 
themselves contributing to the Science and Electronic teams, or just help with 
basic Java or Python libraries that have not yet been packaged. But waiting for 
Debian to provide packages for all the latest softwares available today would 
slow your Science down. To the rescue may come the updated package of 
Singularity, i.e. a non-privileged means to install externally prepared 
software images, and we already know many such images to have Debian as their 
basis.


The Debian Med team values feedback from users, especially regarding requests 
for packaging previously unpackaged free software or backports to earlier 
releases that are important to you.


To install the packages maintained by the Debian Med team, simply install the 
metapackages named med-*, which are currently at version 3.8.x for Debian 
Bookworm. You can explore the full range of biological and medical software 
available in Debian by visiting the https://blends.debian.org/med/tasks;>Debian Med tasks pages.


Please extend/shorten/mod as you see fit.

Best,
Steffen

Aw: Re: Nextflow - have just used it on our HPC cluster and liked it

[Steffen Möller]

> Gesendet: Montag, 08. Mai 2023 um 08:45 Uhr
> Von: "Charles Plessy" 
> An: debian-med@lists.debian.org
> Betreff: Re: Nextflow - have just used it on our HPC cluster and liked it
>
> Hi Steffen and everybody,
> 
> I also use Nextflow at work, and indeed, it makes it very easy to run a
> pipeline many times.  Also, Nextflow is a single Java executable, which
> makes it easy to deploy anywhere Java is already installed.
> 
> You probably also saw the nf-core repository of modules and pipelines.
> I like the way they are organised and find them empowering.  The
> community is very nice too.
> 
> BUT
> 
> With my Debian background it is very hard for me to adapt to the conda /
> biocona / quay / galaxy ecosystem.  I just can not figure out who is
> responsible for what, no idea how long the whole thing will be
> supported, where is the source code used to build the the packages into
> Docker images in to Singularity images, etc.  Not to mention that the
> whole paradigm behind "one tool, one minimal image" deprives me from all
> the Unix tools that I use to enjoy on in a Debian context.  In bioconda
> you have no idea whether sed is from GNU of from busybox unless you try
> it or dig for a package recipe in GitHub...

I am struggling with conda environments, I must admit. This should be mostly 
analogous to chroot environments, I keep thinking, but still ... 

> 
> NOT TO MENTION THAT
> 
> Everybody expects that these images will stay forever and for free at
> the URL where they are, while I have not seen any evidence of an
> organisation promising that it will really happen for at least a
> decade...  Without these images and the receipes to create them
> (remember the singularity <- docker <- conda <- GitHub fragmentation),
> the hope that these pipelines provide reproducibility in the long term
> is wishful thiking.

I admit to care more about the data than the exact tools. Just rerun it with 
whatever was proven to be superior.
The longevity of https://biocontainers.pro/ will basically determine about what 
we shall expect and conversely our demands will shape what will be offered.

> SO
> 
> Against the stream of minimising image size to the bone while processing
> terabytes of sequencing data, I thing that Debian Med images with all of
> our packages installed would be a useful alternative in many cases.

Yes - for the direct execution but also within images.

> I am already doing something along the lines on our HPC cluster to turn
> our packages into environment modules (lmod).
> 
> https://github.com/oist/BioinfoUgrp/blob/master/DebianMedModules.md#creation-of-a-new-singularity-image
> 
> The size of the images is a bit less than 8 GiB, and I make a new image
> at each point release.  Would there be some interest to make such images
> in a more official way ?

We could have our own Singularity Hub (https://singularityhub.github.io/).

@Olivier, Hervé, Matúš et al. - I would happily hear from you that we just do 
not need anything like that.

Best,
Steffen

Nextflow - have just used it on our HPC cluster and liked it

[Steffen Möller]

Hello,

I must admit that I am rather impressed - a series of images were 
auto-downloaded to function together with singularity and this then worked on a 
test data collection of the workflow. So, with singularity (or docker) in 
Debian, and nextflow, we would have an immediate sync with what upstream offers.

I had a look at the table in Google docs and found that the one dependency that 
was once missing to get nextflow through its autotests, i.e. capsule-nextflow 
is in the archive now. So I thought to give the main package of nextflow 
another look. I am impressed by all work that Pierre already invested into the 
packaging. @Pierre, where does that work stand? I only saw that kryo5 is listed 
as a dependency that is not in the archive.

Best,
Steffen

A "debian/rules binary" got this far:

Starting process 'Gradle Worker Daemon 1'. Working directory: 
/Salsa/Med/nextflow/.gradle/workers Command: 
/usr/lib/jvm/java-17-openjdk-amd64/bin/java 
@/tmp/gradle-worker-classpath9650940302470954557txt -Dfile.encoding=UTF-8 
-Duser.country -Duser.language=en -Duser.variant 
worker.org.gradle.process.internal.worker.GradleWorkerMain 'Gradle Worker 
Daemon 1'
Successfully started process 'Gradle Worker Daemon 1'
Started Gradle worker daemon (3.129 secs) with fork options 
DaemonForkOptions{executable=/usr/lib/jvm/java-17-openjdk-amd64/bin/java, 
minHeapSize=null, maxHeapSize=null, jvmArgs=[], 
classpath=[/usr/share/maven-repo/org/codehaus/groovy/groovy-ant/debian/groovy-ant-debian.jar,
 
/usr/share/maven-repo/org/codehaus/groovy/groovy-groovydoc/debian/groovy-groovydoc-debian.jar,
 
/usr/share/maven-repo/org/codehaus/groovy/groovy-templates/debian/groovy-templates-debian.jar,
 
/usr/share/maven-repo/org/codehaus/groovy/groovy-xml/debian/groovy-xml-debian.jar,
 /usr/share/maven-repo/org/codehaus/groovy/groovy/debian/groovy-debian.jar, 
/usr/share/maven-repo/org/apache/ant/ant-junit/debian/ant-junit-debian.jar, 
/usr/share/maven-repo/org/apache/ant/ant/debian/ant-debian.jar, 
/usr/share/maven-repo/org/apache/ant/ant-launcher/debian/ant-launcher-debian.jar,
 /usr/share/maven-repo/org/apache/ant/ant-antlr/debian/ant-antlr-debian.jar, 
/usr/share/java/ant-1.10.13.jar, /usr/share/java/ant-launcher-1.10.13.jar], 
keepAliveMode=SESSION}.
This JVM does not support getting OS memory, so no OS memory status updates 
will be broadcast
Initialized native services in: .../Salsa/Med/nextflow/.gradle/native

Compiling with JDK Java compiler API.
warning: [options] bootstrap class path not set in conjunction with -source 8
Note: org.pf4j.processor.ExtensionAnnotationProcessor init
Note: Options {}
Note: Processing @org.pf4j.Extension
warning: Implicitly compiled files were not subject to annotation processing.
  Use -proc:none to disable annotation processing or -implicit to specify a 
policy for implicit compilation.
2 warnings
startup failed:
.../Salsa/Med/nextflow/modules/nf-commons/src/main/nextflow/plugin/CustomPluginManager.groovy:
 68: [Static type checking] - Cannot find matching method 
org.pf4j.SingletonExtensionFactory#(). Please check if the declared type 
is correct and if the method exists.
 @ line 68, column 16.
   return new SingletonExtensionFactory()

Aw: Hi there.

[Steffen Möller]

I agree that our network of trusted developers can help beyond development, and 
maybe it should in this early onset of a deglobalisation, but this one may 
affect our security. The company's URL is https://www.hataphar.com.vn/, nothing 
like hpharm in Mali.

$ host hpharm.ml
hpharm.ml mail is handled by 10 emx.mail.ru.

I know, the likelihood of anyone of us to have fallen for this is rather slim, 
but, hey, things happen.

S.

> Gesendet: Montag, 24. April 2023 um 12:13 Uhr
> Von: "Lan  N." 
> An: debian-devel@lists.debian.org
> Betreff: Hi there.
>
> Hello,
>
> A reputable pharmaceutical company from Vietnam is in need of a
> reliable individual or corporate entity in your state to act as
> their Liaison officer; this will not
> affect your current job or business operations in any way.  If
> interested, reply for more information.
>
> Regards,
>
> Ms. Lan Nguyen
> Hatay Pharmaceutical
>
>

Re: [Emc-developers] my copy of bullseye git repo needs a hardreset, but its not in git manual, howto?

[Steffen Möller]

git reset --hard

??

Steffen

> Gesendet: Samstag, 22. April 2023 um 17:36 Uhr
> Von: "Greg C" 
> An: "EMC developers" 
> Betreff: Re: [Emc-developers] my copy of bullseye git repo needs a hardreset, 
> but its not in git manual, howto?
>
> No meeting for me, just making a sign as a wedding gift in the garage.
> 
> It’s likely mad because you made changes to some file (or added a file).
> You need to stash the changes before rebasing or resetting (or even
> pulling).
> 
> git stash
> 
> Then afterward you can do:  (Of course if you didn’t intend to have any
> changes  this step isn’t necessary).
> 
> gif stash pop
> 
> And your changes would be put back.  I’m not sure what you changed.
> 
> If you may have added new files then you need “git stash -u” for the first
> stanza.
> 
> 
> 
> On Sat, Apr 22, 2023 at 11:23 AM gene heskett  wrote:
> 
> > On 4/22/23 09:35, Greg C wrote:
> > > Hey Gene,
> > >
> > > I’m not a GitHub expert, but I the last time I had this issue the
> > following
> > > fixed it:
> > >
> > > git rebase
> > >
> > Thanks Greg, but it also fails:
> >
> > pi@rpi4:/media/pi/workspace/bullseye-linuxcnc $ git rebase
> > docs/po/de.po: needs merge
> > docs/src/gui/qtvcp.adoc: needs merge
> > lib/python/gladevcp/drowidget.py: needs merge
> > src/po/es.po: needs merge
> > src/po/gmoccapy/cs.po: needs merge
> > src/po/gmoccapy/es.po: needs merge
> > src/po/gmoccapy/tr.po: needs merge
> > src/po/tr.po: needs merge
> > error: cannot rebase: You have unstaged changes.
> > error: additionally, your index contains uncommitted changes.
> > error: Please commit or stash them.
> >
> > my cron scripts only do git pulls, I haven't touched it in yonks.
> >
> > > I think the worst case is you delete the folder and re-clone and
> > recompile
> > > the project to a folder with the same name.  Your configs and such should
> > > be separate.
> >
> > I had to do that a couple years back.  Its not a showstopper as buster
> > is running it fine, but the buildbot may be hung again, I've had wintel
> > updates but not armhf's for a few days.  Have fun if you re going to the
> > meeting. This can wait.
> > >
> > > -Greg
> > >
> > > On Sat, Apr 22, 2023 at 4:45 AM gene heskett 
> > wrote:
> > >
> > >> Hi all; Subject says it all
> > >>
> > >> A git pull or merge reports:
> > >>
> > >> pi@rpi4:/media/pi/workspace/bullseye-linuxcnc $ git pull
> > >> error: Pulling is not possible because you have unmerged files.
> > >> hint: Fix them up in the work tree, and then use 'git add/rm '
> > >> hint: as appropriate to mark resolution and make a commit.
> > >> fatal: Exiting because of an unresolved conflict.
> > >> pi@rpi4:/media/pi/workspace/bullseye-linuxcnc $ git merge
> > >> error: Merging is not possible because you have unmerged files.
> > >> hint: Fix them up in the work tree, and then use 'git add/rm '
> > >> hint: as appropriate to mark resolution and make a commit.
> > >> fatal: Exiting because of an unresolved conflict.
> > >>
> > >> Fix?
> > >>
> > >> Thanks,
> > >>
> > >> Cheers, Gene Heskett.
> > >> --
> > >> "There are four boxes to be used in defense of liberty:
> > >>soap, ballot, jury, and ammo. Please use in that order."
> > >> -Ed Howdershelt (Author, 1940)
> > >> If we desire respect for the law, we must first make the law
> > respectable.
> > >>- Louis D. Brandeis
> > >> Genes Web page 
> > >>
> > >>
> > >> ___
> > >> Emc-developers mailing list
> > >> Emc-developers@lists.sourceforge.net
> > >> https://lists.sourceforge.net/lists/listinfo/emc-developers
> > >>
> > >
> > > ___
> > > Emc-developers mailing list
> > > Emc-developers@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/emc-developers
> >
> > Cheers, Gene Heskett.
> > --
> > "There are four boxes to be used in defense of liberty:
> >   soap, ballot, jury, and ammo. Please use in that order."
> > -Ed Howdershelt (Author, 1940)
> > If we desire respect for the law, we must first make the law respectable.
> >   - Louis D. Brandeis
> > Genes Web page 
> >
> >
> >
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
> >
> 
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] probe_basic -

[Steffen Möller]

Hello,
on https://www.facebook.com/groups/1887325441579936/posts/3264707197175080/ 
someone reported difficulties to get probe_basic to run because the 
auto-triggered attempt to install dependencies via pip had failed. Is there an 
alternative to probe_basic that is shipping as part of the regular LinuxCNC 
setup?

The following is what ChatGPT has answered:
"LinuxCNC does include some alternative probing scripts that are shipped as 
part of the regular LinuxCNC setup. These alternative probing scripts are 
written in the Tcl programming language and can be used as an alternative to 
probe_basic if you encounter issues with its installation or dependencies.

One such alternative probing script is called probe-tk.py, which is a graphical 
user interface (GUI) based probing script that comes with LinuxCNC. You can 
access it through the "Touch Off" button in the Axis interface of LinuxCNC. 
This script provides similar functionality to probe_basic and can be used for 
various probing operations, such as setting tool length offsets or finding 
workpiece edges.

To use probe-tk.py, you can open the Axis interface of LinuxCNC, navigate to 
the "Touch Off" button, and click on it to launch the probe-tk.py script. This 
will open a graphical window where you can interactively perform probing 
operations.

Alternatively, LinuxCNC also provides other built-in probing scripts, such as 
g38.2 and g38.3, which are G-code commands used for probing operations. These 
commands can be used directly in G-code programs to perform probing operations 
without the need for additional Python scripts.

It's worth noting that the availability and functionality of probing scripts 
may vary depending on the specific version of LinuxCNC you are using, as well 
as any modifications or configurations made to your system. It's always 
recommended to refer to the official LinuxCNC documentation and community 
resources for up-to-date information on probing operations and available 
scripts."

Is there anything to correct/improve/extend on that answer?

To mind came https://github.com/linuxcnc-probe-screen/probe-screen-ng and 
https://github.com/linuxcnc-probe-screen/probe-screen-ng but GMOCCAPY has its 
own, right?

Is there an easy way to direct our users a bit when they look into our 
documentation? I do not find any such info straight-forward to find.

Many thanks!

Steffen


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] [Emc-users] April 2023 LinuxCNC meeting at Tormach headquarters

[Steffen Möller]

> Gesendet: Mittwoch, 12. April 2023 um 17:24 Uhr
> Von: "Sebastian Kuzminsky" 
> An: "EMC developers" , "Jon Elson" 
> 
> Betreff: Re: [Emc-developers] [Emc-users] April 2023 LinuxCNC meeting at 
> Tormach headquarters
>
> On 4/7/23 09:21, Jon Elson wrote:
> > Does anyone have agenda items for the meeting?
>
> The responsible thing would probably be to talk a bit about how to get
> 2.9 released and out the door...
>
> But the fun thing would probably be to geek out over neat hardware...

By all means - you all please concentrate on the fun bits and recharge your 
batteries with it. This likely also helps 2.9.

Best,
Steffen


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Bug#1032975: Aw: Steffen, please raise your opinion about igdiscover

[Steffen Möller]

Hi Andreas,

I am afraid I cannot put the extra effort into those packages and, admittedly, 
the NCBI software suite is just a bit intimidating, too. Please remove those 
packages from testing and if nobody shows any interest in the required updates 
then eventually those packages should also be removed from unstable.

Thank you tons,
Steffen

Bug#1032975: Aw: Steffen, please raise your opinion about igdiscover

[Steffen Möller]

Hi Andreas,

I am afraid I cannot put the extra effort into those packages and, admittedly, 
the NCBI software suite is just a bit intimidating, too. Please remove those 
packages from testing and if nobody shows any interest in the required updates 
then eventually those packages should also be removed from unstable.

Thank you tons,
Steffen

Re: [Emc-developers] [Emc-users] April 2023 LinuxCNC meeting at Tormach headquarters

[Steffen Möller]

> On Fri, 7 Apr 2023 at 17:30, John Allwine  wrote:
>
> > I could bring a Pocket NC if anyone is interested in poking around on it:
> > https://www.pentamachine.com/pocket-nc

Maybe you could jointly conceptualize a video on how to get regular LinuxCNC 
running with the Pocket-NC and how to perform 5-Axis machining, which IMHO 
may/should also adress what the big non-free software packages can do for us.

And - maybe design a tool changer for it :)

> I would love to see one, I have always rather liked the design.

IMHO an automated tool changer is missing - something like 
https://shop.stepcraft-systems.com/automatic-tool-changer-kress or (preferably) 
much nicer.

But on the more serious side - I truly hope you find an arrangement to 
synchronize the development with Tormach. Or some parts of the development at 
least. What you may want to discuss is an analogy to the Linux Software 
Foundation, which I sense played out rather well for Linux. Such a LinuxCNC 
Software Foundation (LCNCSF?) should then also fix remaining concerns that the 
EtherCAT people have.

Could we have an online meeting a week or two after your physical one?

Have fun!
Steffen


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] HAL shared memory and the mis-use of hal_malloc

[Steffen Möller]

Would this be something that we could address together with 
https://github.com/features/copilot? 

> Gesendet: Montag, 27. März 2023 um 10:17 Uhr
> Von: "andy pugh" 
> An: "Sebastian Kuzminsky" 
> Cc: "EMC developers" 
> Betreff: Re: [Emc-developers] HAL shared memory and the mis-use of hal_malloc
>
> On Mon, 27 Mar 2023 at 04:53, Sebastian Kuzminsky  wrote:
> 
> >
> > I'd prefer if we used hal memory for things that need to be in hal, and
> > used non-hal memory for everything else.
> >
> > But I don't intend to clean up all the violations of this preference, so
> > my opinion doesn't count for much.
> 
> 
> I wonder if there is any way to spot if there are any particularly bad
> offenders? (ie, looking for particularly large structs being
> hal_mallocc-ed? Having been used to the care that you took in hm2 I was a
> bit surprised to find that the software stepgen doesn't differentiate.
> 
> -- 
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is designed
> for the especial use of mechanical geniuses, daredevils and lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1912
> 
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] [Emc-users] April 2023 LinuxCNC meeting at Tormach headquarters

[Steffen Möller]

Hello,

> Von: "Jon Elson" 
>
> Would anyone who plans to attend please let me know, so I
> can get a total of attendees and inform Tormach how big the
> horde is going to be?

I just checked the travel time and am a bit surprised about this being minimum 
15 hours one-way, more like a median 21 h. Costs are not too bad, though. Now, 
if we are all going then it may be a good investment, but I consider it most 
important that the right people are attending, so we can have a talk about all 
the elder patches and how to get them integrated with the current main 
development branch. And since we only have two days and since that discussion 
is likely beyond me, it may be preferable if I stay where I am?!?

Best,
Steffen


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] For 2.10: Suggesting chatGPT checks of our documentation

[Steffen Möller]

> Gesendet: Donnerstag, 16. März 2023 um 14:13 Uhr
> Von: "andy pugh" 
> An: "EMC developers" 
> Betreff: Re: [Emc-developers] For 2.10: Suggesting chatGPT checks of our 
> documentation
>
> On Thu, 16 Mar 2023 at 12:10, Steffen Möller  wrote:
> 
> > Hello,
> >
> > I am admittedly still impressed of the linguistic skills of chatGPT
> >
> 
> It's worth considering what ChatGPT does, which is to a large extent just
> choosing the most likely word to continue the sentence.
> In many ways this is just a generic critique that could be relevant to
> almost anything, with some keywords swapped.

So when our chatty friend encounters a text that is not continuous wrt the 
sentences it already knows, like the references to the jitter and the 
descriptions of limitations, then it will point out that this needs some form 
of deeper embedding the text to cater for a fluent read. This is all I want, 
really, for now that is. I also expect that ChatGPT points me to redundancies 
or that it proposes some reordering, but I have not seen this, yet.

There is a side-thought on this. I want our documentation "understood" (are 
those quotes still needed?) by a linguistically skilled robot. That robot could 
then help our new users to set their mill up and (e.g. by integrating the forum 
and I also hope for more YouTube transcripts) also help with error recovery. 

>  Interesting examples:
> https://economistwritingeveryday.com/2023/01/21/chatgpt-cites-economics-papers-that-do-not-exist/

Yes, it is a complete utter failure on provenance, i.e. the introspection on 
where a particular information was found/derived from. But that will come.

Best,
Steffen


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] For 2.10: Suggesting chatGPT checks of our documentation

[Steffen Möller]

Hello,

I am admittedly still impressed of the linguistic skills of chatGPT. Also, its 
translations seem superior to what Google Translate or DeepL is offering. What 
I have toyed around with is to have chatGPT comment on our documentation. It 
always praises what we have, that is the boring part. But when asking for 
possible improvements, then it goes for 
http://linuxcnc.org/docs/2.9/html/install/latency-test.html like:

"Overall, the documentation provides a clear and comprehensive explanation of 
latency and its importance in LinuxCNC. The instructions for running the 
latency test and interpreting the results are also detailed and easy to follow.

However, there are a few areas that could be improved:

The introduction could benefit from a brief overview of what LinuxCNC is and 
how it works, as this would help newcomers to understand the context of the 
latency test.

The section on the disadvantages of software step pulses could be expanded upon 
to give more detail on why they are limited in terms of maximum step rate and 
pulse jitter.

The instructions for running latency-plot and latency-histogram could be 
expanded upon to provide more detail on how to interpret the output.

Including some troubleshooting tips or common issues that may arise during the 
latency test would be helpful for users who encounter problems.

Overall, the documentation is of good quality and provides useful information 
for novice LinuxCNC users."

My comments on this:

* We do not want to give an overview but a reference to where to find that 
overview could be nice, especially since it is likely that the page was found 
via Google, so the reader may not have the context.
* Introduction is short as it is all explained elsewhere in the documentation, 
but references on why something is limited and what the effect of a jitter is, 
would likely boost the confidence of our readers ("thought so").
* We have a problem with decent captions throughout the documentation.

Best,
Steffen






___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] woodpecker 0755 modes for html, js and png?

[Steffen Möller]

Hello,

My immediate hunch is that this is an artifact from using another OS with git. 
Quite some more files were changed, showing only those that surprised me.

Thanks and regards,
Steffen

create mode 100755 configs/sim/woodpecker/compensate.py
 create mode 100755 configs/sim/woodpecker/help_files/about.html
 create mode 100755 configs/sim/woodpecker/help_files/facing_utility.html
 create mode 100755 configs/sim/woodpecker/help_files/help.css
 create mode 100755 configs/sim/woodpecker/help_files/hole_circle_utility.html
 create mode 100755 configs/sim/woodpecker/help_files/probing.html
 create mode 100755 configs/sim/woodpecker/help_files/runfromline.html
 create mode 100755 configs/sim/woodpecker/help_files/spindle_pause.html
 create mode 100755 configs/sim/woodpecker/help_files/template.html
 create mode 100755 configs/sim/woodpecker/help_files/using_a_mpg.html
 create mode 100755 configs/sim/woodpecker/help_files/using_a_vfd.html
 create mode 100755 configs/sim/woodpecker/help_files/z_level_comp.html
 create mode 12 configs/sim/woodpecker/python/qt_auto_probe_tool.ngc
 create mode 100755 configs/sim/woodpecker/tool_icons/ball_end_mill.png
 create mode 100755 configs/sim/woodpecker/tool_icons/ballend_straight.png
 create mode 100755 configs/sim/woodpecker/tool_icons/center_drill.png
 create mode 100755 configs/sim/woodpecker/tool_icons/drill.png
 create mode 100755 configs/sim/woodpecker/tool_icons/gauge.png
 create mode 100755 configs/sim/woodpecker/tool_icons/not_found.png
 create mode 100755 configs/sim/woodpecker/tool_icons/probe.png
 create mode 100755 configs/sim/woodpecker/tool_icons/spiral_ball_end.png
 create mode 100755 configs/sim/woodpecker/tool_icons/spiral_downcut_2F.png
 create mode 100755 configs/sim/woodpecker/tool_icons/spiral_upcut.png
 create mode 100755 configs/sim/woodpecker/tool_icons/surfacing.png
 create mode 100755 configs/sim/woodpecker/tool_icons/tapered_ball_end.png
 create mode 100755 configs/sim/woodpecker/tool_icons/upcut_spiral.png
 create mode 100755 configs/sim/woodpecker/tool_icons/vbit-60.png
 create mode 100755 configs/sim/woodpecker/tool_icons/vbit-90.png
 create mode 100755 configs/sim/woodpecker/tool_icons/vbit-90deg.png
 create mode 100755 configs/sim/woodpecker/woodpecker_/images/QTvcp 
Widgets_files/asciidoc.js



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Bioconductor 400MB packages in Debian?

[Steffen Möller]

Hello,

Some expression data crossed my way and while

conda install -c bioconda bioconductor-clariomdhumantranscriptcluster.db

is no big deal (unless when it is), we do not support it in Debian - it is big. 
Well, at least there was a time when this was considered big, I am not so sure 
any more, so here I ask.

https://bioconductor.org/packages/release/data/annotation/html/pd.clariom.d.human.html

comes in a ~400MB tarball, which is mostly a SQLite database.

I would support a decision according to which anybody interested would just go 
and run the installer, but the dependencies are non-trivial, so you effectively 
end up in installing all of BioConductor in parallel to what Debian already 
offers, which I am not a fan of.

What do you think?

Best,
Steffen

Bug#1021041: Aw: Bug#1021041: ITP: parallel-hashmap --

[Steffen Möller]

Hi Andrius,
Thank you tons, yes, by all means, please proceed.
Best,
Steffen

> Gesendet: Mittwoch, 15. Februar 2023 um 08:12 Uhr
> Von: "Andrius Merkys" 
> An: 1021...@bugs.debian.org, "Steffen Moeller" 
> Betreff: Bug#1021041: ITP: parallel-hashmap --  description>
>
> Hi Steffen,
>
> On Fri, 30 Sep 2022 23:50:47 +0200 Steffen Moeller 
> wrote:
> > Subject: ITP: parallel-hashmap -- 
> > Package: wnpp
> > Owner: Steffen Moeller 
> > Severity: wishlist
>
> I found your ITP and initial packaging for parallel-hashmap. I need this
> library to package pytorch-sparse (#1031265). Is it OK if I finalise and
> upload it, or do you prefer to do so yourself?
>
> Best wishes,
> Andrius
>

Bug#1021041: Aw: Bug#1021041: ITP: parallel-hashmap --

[Steffen Möller]

Hi Andrius,
Thank you tons, yes, by all means, please proceed.
Best,
Steffen

> Gesendet: Mittwoch, 15. Februar 2023 um 08:12 Uhr
> Von: "Andrius Merkys" 
> An: 1021...@bugs.debian.org, "Steffen Moeller" 
> Betreff: Bug#1021041: ITP: parallel-hashmap --  description>
>
> Hi Steffen,
>
> On Fri, 30 Sep 2022 23:50:47 +0200 Steffen Moeller 
> wrote:
> > Subject: ITP: parallel-hashmap -- 
> > Package: wnpp
> > Owner: Steffen Moeller 
> > Severity: wishlist
>
> I found your ITP and initial packaging for parallel-hashmap. I need this
> library to package pytorch-sparse (#1031265). Is it OK if I finalise and
> upload it, or do you prefer to do so yourself?
>
> Best wishes,
> Andrius
>

[Emc-developers] [Hosted Weblate] New comment in LinuxCNC/LinuxCNC Documentation

[Steffen Möller via Emc-developers]

#  Comment added

[ smoe](https://hosted.weblate.org/user/smoe/ "Steffen Möller"): [Hosted
Weblate](https://hosted.weblate.org) /
[LinuxCNC](https://hosted.weblate.org/projects/linuxcnc/) / [LinuxCNC
Documentation](https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/) /
[English](https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/en/)

## Source string

Tip Volts current_vel E= min_velocity requested

## Source string description

type: Plain text

## Comment

I fail to understand what this is supposed to mean. Tip is clear. Volts is
clear. current_vel likely is the speed of movement of the tip but this does
not make sense to me when interpretded together.

[Edit this string](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-
docs/en/?checksum=f9a0e18928089f40#comments)

## Source string location

[man/man9/thc.9:83](https://github.com/LinuxCNC/linuxcnc/blob/master/docs/man/man9/thc.9?plain=1#L83)

##  Translation Info

All strings|  [ 32,324 
](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-docs/en/) |   
---|---|
Translated strings |  [ 32,324 
](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-  
docs/en/?q=state:>=translated) |  [ 100%   
](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-  
docs/en/?q=state:>=translated) 
Untranslated strings   |  [ 0  
](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-  
docs/en/?q=state:empty)|  [ 0% 
](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-  
docs/en/?q=state:empty)
Unfinished strings |  [ 0  
](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-  
docs/en/?q=state:https://hosted.weblate.org/translate/linuxcnc/linuxcnc-  
docs/en/?q=state:https://hosted.weblate.org/translate/linuxcnc/linuxcnc-  
docs/en/?q=state:needs-editing)|  [ 0% 
](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-  
docs/en/?q=state:needs-editing)


[View](https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/en/)

  
[Weblate, the libre continuous localization system.](https://weblate.org/)

Generated on Feb. 10, 2023, 12:09 p.m..

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] updated pyopengl to eliminate the glutInit()-not-found problem

[Steffen Möller]

Hello,
https://tracker.debian.org/pkg/pyopengl
already features it, but the -3 version needs to find its way to the 
autobuilders, still.

I just ran "debfoster -u linuxcnc-uspace" on my laptop and this updates 137 + 
45 packages - which I find really impressive. The question remains if this 
helps eliminating our pyopengl problems or opens new ones. :)

The glBitmap-out-of-memory problem remains.

Best,
Steffen


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] Fw: Bug#1030304: Licensing & copyright issues

[Steffen Möller]

I am not sure if Toby's reply made it to the list.

> Gesendet: Freitag, 03. Februar 2023 um 15:24 Uhr
> Von: "Tobias Frost" 
> An: 1030...@bugs.debian.org
> Betreff: [Emc-developers] Bug#1030304: Licensing & copyright issues
>
> Control: severity -1 normal
> 
> On Thu, 2 Feb 2023 12:10:52 +0100 Adam Ant  wrote:
> > Source: linuxcnc
> > Severity: serious
> 
> (Standard disclaimer: IANAL.)
> 
> > Source files for libnml lack standard Debian or SPDX copyright headers.
> 
> This is nice to have, but it is not a requirement.
> 
>  Also obsolete version of LGPL used.
> 
> Where is this a problem? All LGPL variants a DFSG approved. The license is 
> upstream's *choice*,  
> 
> > 
> > Source files for both the core linuxcnc & libmnl are forked and munged from 
> > a NIST project known as the Enhanced Machine Control (EMC). The source code 
> > for this is public domain. One can NOT take PD
> code, claim copyright, and then slap an arbitrary license on it.
> > 
> > At best, renders the license unenforceable in many jurisdictions, or 
> > illegal in some.
> 
> Public Domain is an accepted as DFSG compatible. As the DFSG-FAQ §15 says:
> "Software placed in the public domain has all the freedoms required by the 
> DFSG, and is free software."
> 
> Where would be distributing PD illegal?
> 
> 
> > Kindly refer to Debian Legal
> 
> This be https://lists.debian.org/debian-legal/2022/12/msg0.html ?
> 
> You've got an answer from Andrew actually. (which you should have considered 
> as input, when filing this bug.
> In fact, you just filed this bug as if the reponse never happened. That 
> raises some concerns on your behaviour.)
> 
> Let me quote the relevant part for the bug: 
> (https://lists.debian.org/debian-legal/2022/12/msg1.html)
> 
> > By the same token, anyone rewriting/modifying that code also has copyright.
> > The author of code can apply any license they like (and can distribute the
> > code themselves with no licence or a licence that means that no-one else
> > could ever distribute it because of a conflict of licences).
> 
> And according to a comment in d/copyright, this is exactly what happened.
> 
> (As Andy pointed out, this is not legal advice. Read the whole thread)
> 
> I don't see a (RC) bug for Debian here, sorry. 
> Downgrading it, I'll leave it up to the maintainers to close it, so that they 
> can also double
> check whether I've missed something when looking at this bug)
> 
> -- 
> tobi
> 
> > 
> > 
> 
> 
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] CI environment, which libraries?

[Steffen Möller]

> Gesendet: Dienstag, 10. Januar 2023 um 10:55 Uhr
> Von: "andy pugh" 
> An: "EMC developers" 
> Betreff: [Emc-developers] CI environment, which libraries?
>
> I added a test to test the command line parameters for halcompile.
> https://github.com/LinuxCNC/linuxcnc/pull/2256
>
> This requires sample code to reference a function in an external library.
> I chose "rl_ding()" from readline.
> But it seems that this wasn't a good choice, as the test passes on my
> PC but fails in the CI environment in Github.
>
> https://github.com/LinuxCNC/linuxcnc/actions/runs/3879455596
>
> Can anyone suggest a library and a function that should always be
> present in any Linux installation, especially including the CI
> environment on github?

My first reaction was to point you to the libc and the printf function, but 
then again, every architecture may have this in a different subdirectory - hm:

$ objdump -T /lib/$(dpkg-architecture -qDEB_HOST_GNU_TYPE)/libc.so.6|grep 
text|egrep '\https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Broken master 06jan23

[Steffen Möller]

> Gesendet: Sonntag, 08. Januar 2023 um 03:34 Uhr
> Von: "Jeff Epler" 
> An: "EMC developers" 
> Betreff: Re: [Emc-developers] Broken master 06jan23
>
> Thanks for speaking up about the problem as soon as you realized it.
> I have temporarily locked the "master" branch on github until this
> problem is resolved.

+1

> I understand that the idea of force-pushing master to 1d836df^ before
> the problem was discussed and dismissed (on IRC?). I did not see this
> discussion.
>
> Seb and I have each prepared PRs that approach fixing the problem. I
> have a third, non-pull-request suggestion.
>
> https://github.com/LinuxCNC/linuxcnc/pull/2250 --
>
> Seb re-cherry-picks work from 2.9, excluding doc work that did not apply
> cleanly. This would mean the doc work is lost from master if nobody else
> steps up to cherry-pick and pull request the changes to master too:

All the changes to the documentation that is not describing new functionality 
should have gone to 2.9, so we improve the upcoming release to the best of our 
abilities.
Any loss of that work likely stops the influx of improvements to 2.9.

> https://github.com/LinuxCNC/linuxcnc/pull/2251 --
> I merge 2.9 into 1d836df^ (git notation for "the commit before 1d836df),
> doing my best to take the better side of each conflict in the
> documentation (usually it was pretty clear; a total of 4 files had
> conflicts), then merge 1d836df with the "ours" strategy (to effectively
> discard its version of the changes), and then cherry-pick commits
> subsequent to 1d836df, only one of which introduced changes.  This
> hopefully catches the majority of doc work, but I merely selected one
> side or the other of the doc changes, rather than carefully merging them
> word by word.

This sounds very reasonable. What does that do to future changes to the 2.9 
documentation? Anyway - four files sounds much like a non-issue.

> The third suggestion is to use this as the moment to adopt the github
> standard "main" branch name, instead of the deprecated branch name
> "master". I would prepare a new branch similar to #2251, but NOT merge
> 1d836df in it, and push this as "main".

I think I prefer "devel". Also since this encourages the submission to 2.9.

> Besides fixing things in one of these ways, I think we should strongly
> consider using github "branch protection", so that any change to main
> and a "branch that looks like a version number" must go through the pull
> request process.  This doesn't catch all problems, and it would require
> folks to step up as pull request reviewers, but it might have avoided
> this problem.

PRs imho are very much a means of communication that I would miss if we would 
not have them.

Thank you, Jeff!
Steffen

> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] January 2023 Online Meeting

[Steffen Möller]

I would like to discuss the translation of French and Spanish that we somehow 
need to get done, at least for the introductory bits. Can we arrange for an 
easy transition between languages on our website?
Inconsistencies in spellings - PNCconf, PnCconf (my favorite), PnCConf ..., 
Stepconf, StepConf (fav) - others?
Would like to give our GUI a bit more of a professional touch but would need 
professional help for that. Do we have a list of problems?

Would be interested to here what everyone is working on (or hoping to find the 
time to be working on).

Best,
Steffen

> Gesendet: Dienstag, 03. Januar 2023 um 17:07 Uhr
> Von: m...@mattshaver.com
> An: emc-developers@lists.sourceforge.net
> Cc: "Petter Reinholdtsen" 
> Betreff: [Emc-developers] January 2023 Online Meeting
>
> The last online meeting was Monday, November 28, 2022 at 2:00pm Eastern
> standard Time for about 2 hours. The folks that attended, including
> myself, thought that interactive discussion was useful and Petter
> Reinholdtsen asked me if I would set up the next meeting after the
> beginning of the new year. Well, here we are!
>
> I propose to hold the next online meeting on Wednesday, January 18, 2023
> at 19:00 UTC (11:00am Pacific Standard Time (California). 2:00pm Eastern
> Standard Time (New York), 7:00pm London time, 8:00pm Central Europe
> time). This time of day seems to allow for most people to attend during
> their typical waking hours.
>
> I also propose using the same multi-participant video conferencing
> service as before, but with an updated URL:
> https://meet.jit.si/LinuxCNC-meeting-january-2023
>
> I considered a Google document for agenda items, but I think it is
> better if the agenda discussion takes place in this e-mail, so please
> "reply all" with agenda ideas.
>
> If this date and time is completely unacceptable, please reply with your
> objection soon so that we can consider alternative times or dates.
> Otherwise, see you there!
>
> Thanks,
> Matt Shaver
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] failing sample configs in 2.9: remap, gmoccapy, qtvcp, and more!

[Steffen Möller]

I completely agree - bookworm is about to freeze, and while smallish updates 
can go in for a couple of months (April?), we need this iteration between 
bookworm and our users that takes time. Once bookworm is released, that is 
mostly it, and we cannot release what we have in testing atm.

The only concern from my side is that a change motivated by bookworm may 
interfere with what is perfectly working on the current stable bullseye.

Thank you, Sebastian!
Steffen

> Gesendet: Mittwoch, 04. Januar 2023 um 13:19 Uhr
> Von: "Rod Webster" 
> An: "EMC developers" 
> Betreff: Re: [Emc-developers] failing sample configs in 2.9: remap, gmoccapy, 
> qtvcp, and more!
>
> It has to be tested on Bookworm because once it becomes the Debian release
> version in a few short months, Linuxcnc is deployed with it. Bullseye does
> not have the linuxcnc-uspace package the tests use.
>
> I must say it's great to see some testing on Bullseye. So much of the GUI's
> are broken. Hats off to the QTplasmac guys. They always seem to pass my
> testing!
>
> Rod Webster
> *1300 896 832*
> +61 435 765 611
> Vehicle Modifications Network
> www.vehiclemods.net.au
>
>
> On Wed, 4 Jan 2023 at 22:09, Hans Unzner  wrote:
>
> > Really great, thank you!
> >
> > However, I have some annotations:
> > - You could mention that the tests need to be run as sudo (at least for
> > it only worked so) and need Python >= 3.8
> > - The stderr file only shows something like "+ su --pty -c 'linuxcnc
> > /usr/share/doc/linuxcnc/examples/sample-configs/sim/gmoccapy/lathe_configs/lathe_C.ini'
> >
> > testrunner"
> > - For the configs which show an error message as window (like the
> > gmoccapy config you attached) - is there another way to check if all
> > tests have passed except looking at all screenshots or stdout logs?
> >
> > And I wonder why you chose Bookworm over Bullseye. I think all the
> > Gmoccapy configs would pass on Bullseye.
> >
> >
> > Am 04.01.23 um 06:04 schrieb Sebastian Kuzminsky:
> > > I wrote a test tool that installs linuxcnc-uspace.deb on a minimal
> > > Debian Bookworm system, and launches each of our "sim" sample configs.
> > > No big surprise, many of them don't work.
> > >
> > > The list of broken configs is:
> > > * axis/iocontrolv2/owordm6-ui-ns.ini
> > > * axis/lathe-fanucy/lathe-fanucy.ini
> > > * axis/profile_axis.ini
> > > * most of axis/orphans/*
> > > * most of axis/remap/*
> > > * axis/vismach/3axis-tutorial/3axis-tutorial.ini
> > > * axis/vismach/rolfmill/rolfmill.ini
> > > * craftsman/*
> > > * most of gmoccapy/*
> > > * most of qtvcp_screens/*
> > > * most of gscreen/*
> > >
> > > If any of these are near and dear to you, please take a look.
> > >
> > > I've attached screenshots from a few that made it far enough to
> > > display a window (many configs failed before displaying anything).
> > >
> > >
> > > The test tool is here if anyone wants to check it out (at some point i
> > > may try to integrate it with the buildbot):
> > >
> > > https://github.com/SebKuzminsky/linuxcnc-config-test
> > >
> > >
> > >
> > >
> > > ___
> > > Emc-developers mailing list
> > > Emc-developers@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/emc-developers
> >
> >
> >
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
> >
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Can I help? Depends: python3 (< 3.11) but 3.11.1-1 is to be installed

[Steffen Möller]

Dear Debian Qt/KDE team,

I was about to update freecad for which there is a new upstream version but ran 
into issues with the build deps

$ LANG=C sudo debfoster -u libpyside2-dev libqt5svg5-dev libqt5xmlpatterns5-dev 
libqt5x11extras5-dev libshiboken2-dev libspnav-dev libzipios++-dev occt-draw 
pybind11-dev pyside2-tools python3-pyside2.qtcore python3-pyside2.qtgui 
python3-pyside2.qtsvg python3-pyside2.qtuitools python3-pyside2.qtwidgets 
python3-pyside2.qtxml

...

The following packages have unmet dependencies:
 libshiboken2-py3-5.15 : Depends: python3 (< 3.11) but 3.11.1-1 is to be 
installed
 python3-pyside2.qtcore : Depends: python3 (< 3.11) but 3.11.1-1 is to be 
installed
 python3-pyside2.qtgui : Depends: python3 (< 3.11) but 3.11.1-1 is to be 
installed
 python3-pyside2.qtsvg : Depends: python3 (< 3.11) but 3.11.1-1 is to be 
installed
 python3-pyside2.qtuitools : Depends: python3 (< 3.11) but 3.11.1-1 is to be 
installed
 python3-pyside2.qtwidgets : Depends: python3 (< 3.11) but 3.11.1-1 is to be 
installed
 python3-pyside2.qtxml : Depends: python3 (< 3.11) but 3.11.1-1 is to be 
installed

There is a new upstream version that is still not completely prepared for 
Python 3.11 as it seems. In part you have addressed these issues as with the 
missing mangle, but there are also new ones:

/home/moeller/Science/pyside2/sources/shiboken2/libshiboken/basewrapper.cpp: In 
function ‘SbkObjectType* SbkObject_TypeF()’:
/usr/include/python3.11/object.h:136:30: error: lvalue required as left operand 
of assignment
  136 | #  define Py_TYPE(ob) Py_TYPE(_PyObject_CAST(ob))
  |   ~~~^~~~
/home/moeller/Science/pyside2/sources/shiboken2/libshiboken/basewrapper.cpp:380:9:
 note: in expansion of macro ‘Py_TYPE’
  380 | Py_TYPE(type) = SbkObjectType_TypeF();
  | ^~~
In file included from /usr/include/python3.11/object.h:757:
/home/moeller/Science/pyside2/sources/shiboken2/libshiboken/basewrapper.cpp: In 
function ‘void SbkObjectTypeDealloc(PyObject*)’:
/usr/include/python3.11/cpython/object.h:507:38: warning: 
‘UsingDeprecatedTrashcanMacro’ is deprecated [-Wdeprecated-declarations]
  507 | UsingDeprecatedTrashcanMacro cond=1; \
  |  ^~~~
/home/moeller/Science/pyside2/sources/shiboken2/libshiboken/basewrapper.cpp:524:5:
 note: in expansion of macro ‘Py_TRASHCAN_SAFE_BEGIN’
  524 | Py_TRASHCAN_SAFE_BEGIN(pyObj);
  | ^~
/usr/include/python3.11/cpython/object.h:504:33: note: declared here
  504 | Py_DEPRECATED(3.11) typedef int UsingDeprecatedTrashcanMacro;
  | ^~~~
/home/moeller/Science/pyside2/sources/shiboken2/libshiboken/basewrapper.cpp: In 
function ‘SbkObjectType* Shiboken::ObjectType::introduceWrapperType(PyObject*, 
const char*, const char*, PyType_Spec*, ObjectDestructor, SbkObjectType*, 
PyObject*, unsigned int)’:
/usr/include/python3.11/object.h:136:30: error: lvalue required as left operand 
of assignment
  136 | #  define Py_TYPE(ob) Py_TYPE(_PyObject_CAST(ob))
  |   ~~~^~~~
/home/moeller/Science/pyside2/sources/shiboken2/libshiboken/basewrapper.cpp:1163:5:
 note: in expansion of macro ‘Py_TYPE’
 1163 | Py_TYPE(heaptype) = SbkObjectType_TypeF();
  | ^~~

The other files compile nicely.

I first thought to address this locally and then ask if you want my local 
solution for the world, but now .. well, you may have this more under your 
fingertips than I do. 

Many thanks and regards,
Steffen (not yet subscribed to the list)

[Emc-developers] Apple M1 runs LinuxCNC in QEMU

[Steffen Möller]

The subject line tells it all.
The https://mac.getutm.app is QEMU in a virtualbox-like environment - and it 
works on my M1. I run Debian arm64 with it, and the Debian "bookworm" provided 
linuxcnc-uspace package works like it does on amd64. Latencies are at ~400µs 
with the regular kernel, have not tried booting into the rt variant.

I'll likely toy around with it more. If you have particular requests for me to 
try something - tell me.

Steffen


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] [Hosted Weblate] New comment in LinuxCNC/LinuxCNC Documentation

[Steffen Möller via Emc-developers]

#  Comment added

[ smoe](https://hosted.weblate.org/user/smoe/ "Steffen Möller"): [Hosted
Weblate](https://hosted.weblate.org) /
[LinuxCNC](https://hosted.weblate.org/projects/linuxcnc/) / [LinuxCNC
Documentation](https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/) /
[English](https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/en/)

## Source string

B and I in the LinuxCNC
documentation for documentation on the Python interface to HAL components

## Source string description

type: Plain text

## Comment

Reminder to self: A proper ref to the referenced section should be added.

[Edit this string](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-
docs/en/?checksum=3166d7e142eeacb5#comments)

## Source string location

[man/man1/halcompile.1:82](https://github.com/LinuxCNC/linuxcnc/blob/master/docs/man/man1/halcompile.1?plain=1#L82)

##  Translation Info

All strings|  [ 32,219 
](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-docs/en/) |   
---|---|
Translated strings |  [ 32,219 
](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-  
docs/en/?q=state:>=translated) |  [ 100%   
](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-  
docs/en/?q=state:>=translated) 
Untranslated strings   |  [ 0  
](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-  
docs/en/?q=state:empty)|  [ 0% 
](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-  
docs/en/?q=state:empty)
Unfinished strings |  [ 0  
](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-  
docs/en/?q=state:https://hosted.weblate.org/translate/linuxcnc/linuxcnc-  
docs/en/?q=state:https://hosted.weblate.org/translate/linuxcnc/linuxcnc-  
docs/en/?q=state:needs-editing)|  [ 0% 
](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-  
docs/en/?q=state:needs-editing)


[View](https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/en/)

  
[Weblate, the libre continuous localization system.](https://weblate.org/)

Generated on Dec. 23, 2022, 3:21 p.m..

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Fwd: Bug#1025433: Copyright issue

[Steffen Möller]

If some copyright is wrong or incomplete then we can just fix it and close that 
bug report?

> Gesendet: Samstag, 10. Dezember 2022 um 00:40 Uhr
> Von: "andy pugh" 
> An: "EMC developers" 
> Betreff: [Emc-developers] Fwd:  Bug#1025433: Copyright issue
>
> For some reason this was not sent to emc-developers.
> 
> Clearly, for reasons of his own this chap does not want LinuxCNC in Debian.
> 
> Frankly, I am OK with this. We haven't been in before and all my machine
> tools work just fine.
> 
> This is not a fight I want to fight.
> 
> -- Forwarded message -
> From: Adam Ant 
> Date: Fri, 9 Dec 2022 at 23:23
> Subject: Re: [Emc-developers] Bug#1025433: Copyright issue
> To: andy pugh 
> Cc: <1025...@bugs.debian.org>
> 
> 
> 
> Source: linuxcnc
> Severity serious
> 
> 
> 
> Sent: Thursday, December 08, 2022 at 1:36 AM
> From: "andy pugh" 
> To: "EMC developers" , "Adam Ant" <
> adam...@engineer.com>
> Subject: Re: [Emc-developers] Bug#1025433: Copyright issue
> 
> 
> 
> On Thu, 8 Dec 2022 at 00:42, Adam Ant  adam...@engineer.com]> wrote:
> 
> 
> 
> The correct course of action is to ask Paolo Mantegazza rather than
> debating symantics.
> You can not just pull substantial chunks of code from one source and then
> claim that you wrote it.
>  But Paulo didn't write it _either_
> 
> If you go back in time to 2003:
> https://github.com/LinuxCNC/linuxcnc/blob/07bc1e161f834d8b192fe279819261294e5fe150/src/rtapi/procfs_macros.h[https://github.com/LinuxCNC/linuxcnc/blob/07bc1e161f834d8b192fe279819261294e5fe150/src/rtapi/procfs_macros.h]
> and compare that to a 1999 version of the RTAI file, the only line in
> common is "#include "
> 
> At some point _both_ files included a chunk of work from Erwin Rol:
> 
> // proc print macros - Contributed by: Erwin Rol (er...@muffin.org[mailto:
> er...@muffin.org])
> 
> _Most_ of both files was written by Erwin Rol. But both files existed
> previously, and separately, as far as I can tell looking back in both
> archives.
> 
> 
> Regardless of who wrote the original code, you can not take a file, hack it
> a little and then claim sole copyright yourself.
> It brings the Debian project in to disrepute if they host the package.
> 
> 
> -- 
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is designed
> for the especial use of mechanical geniuses, daredevils and lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1912
> 
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] A vision for working now to LinuxCnc version 10

[Steffen Möller]

> Gesendet: Montag, 05. Dezember 2022 um 21:12 Uhr
> Von: "Bari" 
> An: emc-developers@lists.sourceforge.net
> Betreff: Re: [Emc-developers] A vision for working now to LinuxCnc version 10
>
> On 12/5/22 10:57, Steffen Möller wrote:
> 
> >
> > I guess any such industrial decision making is equally based on the 
> > "unknown" when it comes to interoperability. The EU funds (did fund?) COST 
> > actions for this purpose - bring industrial and academic partners together 
> > and squeeze something like a joint standard out of them. Since quite a 
> > number of CNC companies are located in Europe, it seems like worthwhile to 
> > write something up with them. Any such COST action pays for travel, not for 
> > people, except some smallish side projects when someone visits cross 
> > country. Opinions?
> >
> Good idea. Do you have any more info on COST. Unfortunately they chose 
> an acronym that makes it difficult to search for.

https://www.cost.eu/

In 2010 or so I had helped writing a successful application. They have an open 
call.

> Interesting to see some DDS performance testing. Looks like we might use 
> what they call "local delivery" for latency <1mS .
> 
> https://www.rti.com/blog/latest-connext-dds-ros-2-performance-benchmarks

It would make some good sense to me not to use DDS that currently runs in the 
base thread. 

I see a distributed control system. Many units that know the units that are 
neighboured (i.e. that they cooperate with) but do not need to see the complete 
world. And if the neighbours are allowed to be dynamic, then tis would then 
even work with mobile systems, but this is where ROS kicks in, right?

Steffen


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] A vision for working now to LinuxCnc version 10

[Steffen Möller]

> Gesendet: Montag, 05. Dezember 2022 um 17:33 Uhr
> Von: "Johannes Fassotte" 
> An: "EMC developers" 
> Betreff: Re: [Emc-developers] A vision for working now to LinuxCnc version 10
>
> DDS looks very interesting and I will plan to look into it more today. Thanks 
> for the link to DDS. Future compatibility with other industrial work is very 
> important and highly desirable.
> 
> Johannes - 
> Fairbanks, AK 99712
> 
> > On Dec 5, 2022, at 6:13 AM, Bari  wrote:
> > 
> > A pdf that explains where DDS fits in to industry 
> > https://www.dds-foundation.org/sites/default/files/RTILunchAddressOMG2014v2.pdf
> > 
> > If we use DDS it might make LCNC compatible with the industry of the 
> > future. Is everyone jumping onto the DDS bandwagon? Which messaging system 
> > will gives us the best chance at fitting into factory automation, CNC 
> > machines and robotics of the near future (next 20 years)? Will this best 
> > solve the issues of separating the controls from the GUI over the network 
> > as well as connect LCNC to factory controls and robot material handlers?

I guess any such industrial decision making is equally based on the "unknown" 
when it comes to interoperability. The EU funds (did fund?) COST actions for 
this purpose - bring industrial and academic partners together and squeeze 
something like a joint standard out of them. Since quite a number of CNC 
companies are located in Europe, it seems like worthwhile to write something up 
with them. Any such COST action pays for travel, not for people, except some 
smallish side projects when someone visits cross country. Opinions?

> Is this mission creep or killing two birds with one stone?
It is "Two flies with one clap."

Best,
Steffen


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] A vision for working now to LinuxCnc version 10

[Steffen Möller]

> Gesendet: Montag, 05. Dezember 2022 um 03:16 Uhr
> Von: "Bari" 
> An: emc-developers@lists.sourceforge.net
> Betreff: Re: [Emc-developers] A vision for working now to LinuxCnc version 10
>
> On 12/4/22 19:08, Steffen Möller wrote:
> 
> >
> >> Gesendet: Sonntag, 04. Dezember 2022 um 23:39 Uhr
> >> Von: "Chris Morley" 
> >> An: "EMC developers" 
> >> Betreff: Re: [Emc-developers] A vision for working now to LinuxCnc version 
> >> 10
> >>
> >>
> >>
> >>> My work on this will  continue, initially getting the required network
> >>> code in place for both TCP and UDP connections and also the Redis base
> >>> to handle the distribution of Cmd, Status and Error data to where ever
> >>> it is needed. Once that is done change my routing commands away from the
> >>> NML remote TCP ports into the newly created TCP server ports for further
> >>> testing and evaluation and development of any additional code
> >>> requirements. The same for status and errors.
> >>
> >> Do you mean linuxcnc would NML into a redis database and then network out 
> >> of redis?
> >>
> >> A couple of things come to mind that I run into as a UI builder:
> >>
> >> How does HAL fall into this? Many things the uis currently interact with 
> >> are HAL related.
> >>
> >> Error handling is terribly difficult. The 'consumed' error messages make 
> >> it very difficult to detect errors and act accordingly, particularly if 
> >> you have multiple ui sources.
> >>
> >> The fact that linuxcnc doesn't have an internal memory of say jog rate, 
> >> means every ui has one, yet unless you use HAL you can not communicate 
> >> between uis. This is what I think you mean by 'python based addons' we 
> >> worked around this in qtvcp and gladevcp by adding jograte to python's 
> >> status module. Mostly because linuxcnc and NML are too big of a black box 
> >> with no docs/examples.
> >>
> >> Can your proposal help with the 'no docs blackbox' problem too? Redis is 
> >> certainly mainstream.
> > I think we all somewhat agree that eventually we want to have a system with 
> > which we can somehow control multiple machines (as in a larger production 
> > facility) and those machines may be in different rooms or (as for 
> > telescopes) on another hill or wherever. But mostly we are after local 
> > synchronisation to load or unload or change the position of some piece or 
> > .. whatever.
> >
> > Would you think it would be a reasonable assumption that there may be 
> > scenarios in which two different GUIs want to control the same machine? A 
> > complicated workflow to finish a machine could have different GUIs that 
> > control different parts of the production. Or two colleagues (one on each 
> > hill) with different expertises and different expert software are 
> > interested in the same machine but look at it differently - one from 
> > support and tool maintenance, the other the with an interest in the part 
> > maybe. Should that be something to aim for then those local variables in 
> > the GUI likely need to somehow move towards something that works like HAL.
> >
> > I have no idea if there is a word for that in real time computing, but I 
> > see that variables are likely used in layers. The threads with shorter 
> > periods (base thread) I see less likely to read from variables (with 
> > well-defined exceptions) that are controlled by threads with a longer 
> > periods (server thread). And all human activities that a GUI represents are 
> > so damn slow, that this is just another layer that it does not feel natural 
> > to occupy HAL with them, so those became part of the GUI. Maybe we also 
> > need a Human Abstraction Layer (which would unfortunately have the same 
> > abbreviation) and have different GUIs communicate with that? And to prepare 
> > or some AI steering our CNC, maybe a better word would be "Intent 
> > Abstraction Layer"?
> >
> > That was not too wild, was it?
> > Steffen
> >
> What I actually run into is having to synchronize multiple CNC machines 
> with each other and with robots. For example I was asked to build a 
> large machine with four 5-axis machines on each quadrant of a large work 
> volume~2x3x0.5m. Each machine could operate independently from each 
> other yet would have a small overlap of their workspace with each other 
> for 100% coverage of the work volume. Having one instance of LCNC to

Re: [Emc-developers] A vision for working now to LinuxCnc version 10

[Steffen Möller]

> Gesendet: Sonntag, 04. Dezember 2022 um 23:39 Uhr
> Von: "Chris Morley" 
> An: "EMC developers" 
> Betreff: Re: [Emc-developers] A vision for working now to LinuxCnc version 10
>
>
>
> >My work on this will  continue, initially getting the required network
> >code in place for both TCP and UDP connections and also the Redis base
> >to handle the distribution of Cmd, Status and Error data to where ever
> >it is needed. Once that is done change my routing commands away from the
> >NML remote TCP ports into the newly created TCP server ports for further
> >testing and evaluation and development of any additional code
> >requirements. The same for status and errors.
>
>
> Do you mean linuxcnc would NML into a redis database and then network out of 
> redis?
>
> A couple of things come to mind that I run into as a UI builder:
>
> How does HAL fall into this? Many things the uis currently interact with are 
> HAL related.
>
> Error handling is terribly difficult. The 'consumed' error messages make it 
> very difficult to detect errors and act accordingly, particularly if you have 
> multiple ui sources.
>
> The fact that linuxcnc doesn't have an internal memory of say jog rate, means 
> every ui has one, yet unless you use HAL you can not communicate between uis. 
> This is what I think you mean by 'python based addons' we worked around this 
> in qtvcp and gladevcp by adding jograte to python's status module. Mostly 
> because linuxcnc and NML are too big of a black box with no docs/examples.
>
> Can your proposal help with the 'no docs blackbox' problem too? Redis is 
> certainly mainstream.

I think we all somewhat agree that eventually we want to have a system with 
which we can somehow control multiple machines (as in a larger production 
facility) and those machines may be in different rooms or (as for telescopes) 
on another hill or wherever. But mostly we are after local synchronisation to 
load or unload or change the position of some piece or .. whatever.

Would you think it would be a reasonable assumption that there may be scenarios 
in which two different GUIs want to control the same machine? A complicated 
workflow to finish a machine could have different GUIs that control different 
parts of the production. Or two colleagues (one on each hill) with different 
expertises and different expert software are interested in the same machine but 
look at it differently - one from support and tool maintenance, the other the 
with an interest in the part maybe. Should that be something to aim for then 
those local variables in the GUI likely need to somehow move towards something 
that works like HAL.

I have no idea if there is a word for that in real time computing, but I see 
that variables are likely used in layers. The threads with shorter periods 
(base thread) I see less likely to read from variables (with well-defined 
exceptions) that are controlled by threads with a longer periods (server 
thread). And all human activities that a GUI represents are so damn slow, that 
this is just another layer that it does not feel natural to occupy HAL with 
them, so those became part of the GUI. Maybe we also need a Human Abstraction 
Layer (which would unfortunately have the same abbreviation) and have different 
GUIs communicate with that? And to prepare or some AI steering our CNC, maybe a 
better word would be "Intent Abstraction Layer"?

That was not too wild, was it?
Steffen



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] A vision for working now to LinuxCnc version 10

[Steffen Möller]

Hello,

> My goal for LinuxCnc is to provide a way for any user to interface any
> UI to LinuxCnc with a secure TCP network connection.

There are remote shells to HAL but I agree - would also like to see a bit more 
of remote control. My motivation is less about the distance than it is about 
controlling multiple machines from the same host - cooperating robots anyone?

I do not exactly know how ROS would come into play, but I presume, that would 
be another very close candidate as a controlling agent. I have no idea about 
how difficult this would all be to implement.

Steffen


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Eye candy is important

[Steffen Möller]

This turned into quite a thread.

@Kurt, you did everything just right.

There should not be much of a difference between LinuxCNC-related work that is 
part of the same git repository, within the LinuxCNC github organisation or 
external to it. I'll do my best to keep packaging your dependencies and while 
we will miss the upcoming Debian freeze for them, we should manage for the next.

Best,
Steffen

> Gesendet: Freitag, 02. Dezember 2022 um 02:57 Uhr
> Von: "Kurt Jacobson" 
> An: "EMC developers" 
> Betreff: Re: [Emc-developers] Eye candy is important - Titan got a new German 
> friend - want that reaction for a LinuxCNC controller
>
> Good evening!
>
> I have been busy starting a family so have been completely out of the
> LinuxCNC loop lately,
> glad to see most of the old familiar names still active, as well as the new
> ones!
>
> I have not thoroughly read this thread, but I have read enough to be
> discouraged
> by some of the things said.
>
> As far as I know, we are all here for the fun of a good mental
> challenge and to enjoy some
> time away for the usual stress of work and life. I don't think anybody is
> trying to compete in
> any but a constructive manner or "steal market share" from any other GUI
> project.
>
>
>
> > IIUC, @hazzy had a "control agnostic UI" vision in the beginning. That
> > could explain why the project was created outside LinuxCNC.
> > But others may have better knowledge of the whys and hows...
> >
>
> You are 100% correct.
> I'm not sure where the rather obvious bitterness over the QtPyVCP project
> originated,
> but I can explain why I chose to start a seperate Qt based VCP toolkit.
>
>
> Here is a quick history of the origins of QtPyVCP which may prove helpful.
>
> When I first started playing with LinuxCNC (2013), I had absolutely no
> coding or Linux experience of any kind.
> I learn by doing, so I started reading the LinuxCNC source code, trying to
> understand it and make my
> own UI based off of Gmoccapy. The result of this was the first "Hazzy"
> (haas-like) UI I made:
> https://github.com/KurtJacobson/hazzy/tree/legacy
>
> I posted screenshots of Hazzy on the forms and got some interest (TurBoss
> for one),
> so I tried to figure out how I could share it with others. I found this
> extremely difficult
> as I had no GIT experience and the files I had modified to get the
> functionality I wanted
> were spread all over through the LinuxCNC code base.
>
> There is no way I would have got a PR to the main LinuxCNC accepted,
> since my code style was non-existent and I was intimidated by the PR
> process.
> (The linuxcnc dev community can be a little intimidating at times ...)
>
> I wished there was an easy way for newbies like myself to create and
> share VCPs without them needing to be polished to the same level as the
> main code base.
> This is something that Mach3 had that made a huge range if UIs available.
>
> TurBoss and I started trying to make a Mach3 style screen designer with
> drag and drop pre-made widgets.
> We did this with GtK and it worked reasonable well, but then we started
> having Gtk compatibility issues
> https://www.youtube.com/watch?v=rh7IONE3Lsk
>
> TurBoss had been working with Qt for other projects, so I decided to play
> with Qt as an alternative to Gtk.
> I learned of the QtPy project, and thought it would be neat to have the
> same level of abstraction between the
> machine control (LinuxCNC, GRBL etc.) and the UI so you could develop UIs
> for multiple controls with the same toolkit,
>
> By this time Chris M. was starting QtVCP, so to learn Qt I started
> studying and helping him on various things,
> but I was intimidated and my creativity stifled by having to PR to the main
> QtVCP branch.
>
> This led me to start a repo for my vision of an abstract, control agnostic,
> plugin-based VCP toolkit using QtPy
> and PyDM as its inspiration, hence the name QtPyVCP (it was originally
> QtPyMD for QtPy Machine Display).
>
> While QtPyVCP has remained much closer tied to LinuxCNC-only than I
> originally hoped,
> I believe it has been successful at lowering the barrier to creating and
> sharing custom user interfaces.
>
>
> Again, use of similar technologies is a not an issue but an opportunity to
> > find commonalities and join forces on shared libs or whatever, freeing
> > resources for what is done truly differently in each project
>
>
> 100%
>
>
> > > Nothing wrong with being independent, seems to work for both projects.
> >
> >
> > Indeed, considering the success of QtPyVCP, as an outsider, it doesn't seem
> > to impede its development and progress !
> >
>
> I think the very fact that it is a seperate project is what has made it so
> successful.
> It is much less intimidating for a new user to contribute to a small
> focussed project,
> than a massive sprawling code base like LinucCNC has become, and this is
> why I
> believe QtPyVCP should remain at least in a separate repo.
>
>
> > > I'm sure neither project wants their years of 

Re: [Emc-developers] Eye candy is important - Titan got a new German friend - want that reaction for a LinuxCNC controller

[Steffen Möller]

> Gesendet: Donnerstag, 01. Dezember 2022 um 21:07 Uhr
> Von: "andy pugh" 
> An: "EMC developers" 
> Betreff: Re: [Emc-developers] Eye candy is important - Titan got a new German 
> friend - want that reaction for a LinuxCNC controller
>
> On Wed, 30 Nov 2022 at 23:31, Steffen Moeller 
> wrote:
>
> I consider all our users to be somehow part of our project and am
> > agnostic about the interface they are using. From how I see it, if
> > PyQtVCP does something better than QtVCP then QtVCP gets some
> > encouragement and ideas on how to improve and vice versa. Both GUIs
> > should be as easy to install and use as possible.
>
>
> We already see users getting confused about whether they are using PyVCP
> (hand-coded XML input files)
>  https://linuxcnc.org/docs/stable/html/gui/pyvcp.html
> Or GladeVCP (more capable, more widgets, has Python handlers. designed
> using a GUI (which is horrible, unintiutive and crashes a lot)
> https://linuxcnc.org/docs/stable/html/gui/gladevcp.html
>
> How are integrators (ie, GUI / Panel designers) meant to pick between QtVCP
> and the very similarly named QtPyVCP? They do the same thing,
> fundamentally.

One problem (that I can eventually help with) is the documentation that does 
not mention PyQtVCP even once. You just gave a very nice introduction for the 
other VCPs (better than what I recall to have read in the documentation) that 
we should extend for PyQtVCP, which would be a paragraph and a reference to the 
external documentation.

Users will start with the GUI that looks the best, convinced that someone who 
too special care to make something look nice will also have cared for the bits 
underneath, and it is the only thing they can evaluate at that point. If we 
have a couple of good GUIs that are easy to change then it does not matter 
which one a user starts with. Let the confusion begin, I mean, let the many 
GUIs (or GUI building blocks) come.

Best,
Steffen





___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Merge Strategy

[Steffen Möller]

That video conferencing seemed helpful to have some older PRs looked into. We 
did not do it last time, but maybe any such routine would help. It is a complex 
software we are talking about one quickly is beyond one's immediate wits, 
shying away from that responsibility. So having many individual and experiences 
jointly looking at the same patch may be beneficial. And for the older PRs the 
responsible individuals (submitters) may not always be available, still.

I suggest to release a nice version 2.9, and then have some talking about what 
we want for release 2.10/3.0 and how we should get there. I find that for the 
documentation this works very nice these days. Everyone knows that @hansu has a 
rigorous eye+judgement on what is submitted - and we/hansu know when to ask and 
everyone knows that we/hansu will ask when there is a need to get something 
clarified. Maybe we can have more such teams that address some distinct corner 
of LinuxCNC?

We could possibly establish a "forgotten but still pressing PR"-committee that 
submitters can call when they (I mean, their patches) feel neglected?

Best,
Steffen 

> Gesendet: Mittwoch, 30. November 2022 um 13:00 Uhr
> Von: "Chris Morley" 
> An: "EMC developers" 
> Betreff: Re: [Emc-developers] Merge Strategy
>
> Our current strategy has not been always right in the past.
> I have occasionally had to fix merges after the fact because someone merged 
> them wrong.
> (People have occasionally had to fix my merge mistakes too.)
> Which is not surprising considering the type of files I usually work on (XML).
> I have had to wait for up merges to get needed work to master.
> The conflicts you are talking of are probably because I put separate commits 
> in each branch because I was tired of waiting.
> 
> Of course 2.9 to master will be easy for a while but the same problem will 
> come back.
> Even more so if the Debian inclusion gives us many more pull requests from 
> non devs.
> 
> I just think that having only about 4 devs that actually do merges is not a 
> good games plan.
> I presented my idea to see if anyone could show a fatal flaw of it so I 
> appreciate the discussion/feedback.
> So far no fatal flaw, other then it's different.
> 
> But I also recognise I'm not convincing anyone so I guess I will try to let 
> it go :)
> But again thanks for the discussion, that was the most important part!
> 
> Chris
> 
> From: andy pugh 
> Sent: November 30, 2022 10:24 AM
> To: EMC developers 
> Subject: Re: [Emc-developers] Merge Strategy
> 
> On Wed, 30 Nov 2022 at 07:38, Chris Morley 
> wrote:
> 
> >
> > The only solution, given our current strategy, is to wait/ask for someone
> > else to fix it.
> > This is the crux of the problem.
> 
> 
> I think that our current merge-up strategy has been right in the past and
> will be right again, but currently there are significant conflicts between
> the tip of 2.8 and 2.9. These seem to be mainly docs and the fallout of me
> merging 7i96S support "backwards".
> 
> I think we need a one-off effort to make sure that there aren't any
> important bug fixes in 2.8 needed in 2.9 but in general I think that the
> outstanding commits should be marked as merged (for housekeeping reasons)
> but with the code remaining as the 2.9 version unless there is an obviously
> necessary fix. I think that in general this is going to mean just git
> checkout --ours conflicted.file but with a look at the commit
> description to see if a fix (possibly one different from either existing
> file) is needed.
> 
> Here is the conflict list.
> 
> Auto-merging src/hal/drivers/mesa-hostmot2/pins.c
> 
> CONFLICT (content): Merge conflict in src/hal/drivers/mesa-hostmot2/pins.c
> 
> Auto-merging src/hal/drivers/mesa-hostmot2/hostmot2.h
> 
> CONFLICT (content): Merge conflict in
> src/hal/drivers/mesa-hostmot2/hostmot2.h
> 
> Auto-merging src/hal/drivers/mesa-hostmot2/hostmot2.c
> 
> CONFLICT (content): Merge conflict in
> src/hal/drivers/mesa-hostmot2/hostmot2.c
> 
> Auto-merging src/hal/drivers/mesa-hostmot2/hm2_eth.c
> 
> Auto-merging src/emc/usr_intf/pncconf/private_data.py
> 
> CONFLICT (content): Merge conflict in
> src/emc/usr_intf/pncconf/private_data.py
> 
> Auto-merging src/emc/usr_intf/pncconf/pncconf.py
> 
> CONFLICT (content): Merge conflict in src/emc/usr_intf/pncconf/pncconf.py
> 
> Auto-merging src/emc/usr_intf/pncconf/build_HAL.py
> 
> CONFLICT (content): Merge conflict in src/emc/usr_intf/pncconf/build_HAL.py
> 
> Auto-merging src/emc/usr_intf/gmoccapy/release_notes.txt
> 
> CONFLICT (content): Merge conflict in
> src/emc/usr_intf/gmoccapy/release_notes.txt
> 
> Auto-merging src/emc/usr_intf/gmoccapy/gmoccapy.py
> 
> Auto-merging src/emc/usr_intf/gmoccapy/getiniinfo.py
> 
> Auto-merging src/emc/usr_intf/emcrsh.cc
> 
> Auto-merging src/Makefile
> 
> Auto-merging share/qtvcp/panels/cam_align/cam_align_handler.py
> 
> CONFLICT (content): Merge conflict in
> share/qtvcp/panels/cam_align/cam_align_handler.py
> 
> 

Re: [Emc-developers] Eye candy is important - Titan got a new German friend - want that reaction for a LinuxCNC controller

[Steffen Möller]

> Gesendet: Dienstag, 29. November 2022 um 22:15 Uhr
> Von: "Phill Carter" 
> An: "linuxcnc-developers" 
> Betreff: Re: [Emc-developers] Eye candy is important - Titan got a new German 
> friend - want that reaction for a LinuxCNC controller
>
>
>
> > On 30 Nov 2022, at 7:54 am, Rod Webster  wrote:
> >
> > @steffen, there is a script to install qtpyvcp dependencies in:
> >
> > /usr/lib/python3/dist-packages/qtvcp/designer/install_script
> >
> > Its documented in QTplasmac, not sure if its mentioned elsewhere
> > http://linuxcnc.org/docs/devel/html/plasma/qtplasmac.html#qt-dependency
>
> The above script is for QtVCP dependencies.

Ah - many thanks!

I need to check and make sure that we have everything in Debian, such that this 
script (or other magic) is no longer needed.

Best,
Steffen


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] LinuxCNC 2.9~pre ISO tmp URL Aw: Re: Eye candy is important - Titan got a new German friend - want that reaction for a LinuxCNC controller

[Steffen Möller]

> Gesendet: Dienstag, 29. November 2022 um 23:10 Uhr
> Von: "andy pugh" 
> An: "EMC developers" 
> Betreff: Re: [Emc-developers] Eye candy is important - Titan got a new German 
> friend - want that reaction for a LinuxCNC controller
>
> On Tue, 29 Nov 2022 at 20:59, Rod Webster  wrote:
>
> > Why would we bother hosting our own ISO on slow servers and put our limited
> > resources into building and maintaining said ISO's when the new paradigm is
> > already with us right now?

> It's to lower the bar for Windows users, trying to make it as simple as
> possible.
>
> They need to install an ISO anyway, it might as well be ours for a one-step
> process.

Yes, increasing our user and developer base was what triggered my personal 
ambitions to get this out nicely. But that live systems is also helpful to 
reproduce each other's problems, I expect. You can take that same USB stick to 
different machines in the house and check, e.g., for effects on the latency or 
whatever.

Andy kindly put my shot from now two weeks ago (Debian bookworm amd64) at 
https://www.linuxcnc.org/iso/LinuxCNC_2.9.0-amd64.hybrid.iso (<3GB) for you all 
to try.

Best,
Steffen



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Eye candy is important - Titan got a new German friend - want that reaction for a LinuxCNC controller

[Steffen Möller]

> Gesendet: Dienstag, 29. November 2022 um 20:19 Uhr
> Von: "andy pugh" 
> An: "EMC developers" 
> Betreff: Re: [Emc-developers] Eye candy is important - Titan got a new German 
> friend - want that reaction for a LinuxCNC controller
>
> On Tue, 29 Nov 2022 at 16:53, Steffen Möller  wrote:
> 
> > Hello,
> >
> > No need to watch this, really. Titan has a nice Heller machine and passes
> > the Sinumeric control
> > https://youtu.be/zToKZtqQMIo?t=354
> > with some excitement. I actually find LinuxCNC even nicer, especially for
> > what I saw from https://www.qtpyvcp.com/ .
> 
> 
> If you want eye candy, the Datron UI is rather well done:
> https://youtu.be/ZgqCY3gUHcM

I had seen that video, and indeed, I liked it (and still like it). But they do 
not run LinuxCNC underneath, do they? Still, as an idea for how to develop - 
yes!!!

Thank you!
Steffen


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Eye candy is important - Titan got a new German friend - want that reaction for a LinuxCNC controller

[Steffen Möller]

I will happily watch it. Titan has (had?) some Tormach machines, so he likely 
already has (had?) LinuxCNC in house. With his zoo of machines, and his 
interest in education and "doing stuff here" (which is "there" for me), there 
should be a nice story that has not yet been told too often that you can 
implement with LinuxCNC in an easier way than with current closed-source 
controllers. That should make an interesting LinuxCNC-promoting video for him 
(and us).

Rough ideas:
 * cutting gears with a CNC at weird places that would be difficult to reach 
with traditional gear cutters
 * integrating a camera into a machine that was bought without one
 * integrating a robot/pneumatics/... into a machine that was bought without
 * a portable CNC for repairs in the field (like moon, mars or some ship on our 
own planet) that has an integrated temperature sensor/camera to compensate for 
variations in temperature
 * using the same controller for something completely different, like 
distinguishing your cat from the neighbour's cat to decide if the cat door 
should open.

Thank you!

Steffen

> Gesendet: Dienstag, 29. November 2022 um 23:23 Uhr
> Von: "Feral Engineer" 
> An: "EMC developers" 
> Betreff: Re: [Emc-developers] Eye candy is important - Titan got a new German 
> friend - want that reaction for a LinuxCNC controller
>
> There's that one interface that's a blatant rip off of a siemens control
> that would be a great addition
> 
> Maybe I'll just do a generic video and whoever wants to watch it, will
> 
> Phil T.
> The Feral Engineer
> 
> Check out my LinuxCNC tutorials, machine builds and other antics at
> www.youtube.com/c/theferalengineer
> 
> Help support my channel efforts and coffee addiction:
> www.patreon.com/theferalengineer
> 
> Order one of the coolest label makers on the market at
> http://labelworks.epson.com, use coupon code "theferalengineer" and receive
> 20% off of your order 
> 
> On Tue, Nov 29, 2022, 4:57 PM Eric Keller  wrote:
> 
> > I would watch your demonstration of the Siemens control and I'm
> > anxiously awaiting your implementation of a similar interface on
> > linuxcnc.  As long as the demonstration doesn't involve any screaming.
> > Eric Keller
> > Boalsburg, Pennsylvania
> >
> > On Tue, Nov 29, 2022 at 1:24 PM Feral Engineer
> >  wrote:
> > >
> > > That dude is a goofball and that version of Sinumerik looks like 20
> > pounds
> > > of crap in a 10 pound bag. They put away too much on the screen and it
> > > blocks most of the hmi. I thought we used up a lot of real estate on our
> > > screens (DMG Mori), these Heller machines have got us beat...
> > >
> > > Seriously... I'll give a presentation on the siemens control to anyone
> > > interested in seeing it. Why do I always feel like I'm screaming into a
> > > black hole here?
> > >
> > > Phil T.
> > > The Feral Engineer
> > >
> > > Check out my LinuxCNC tutorials, machine builds and other antics at
> > > www.youtube.com/c/theferalengineer
> > >
> > > Help support my channel efforts and coffee addiction:
> > > www.patreon.com/theferalengineer
> > >
> > > Order one of the coolest label makers on the market at
> > > http://labelworks.epson.com, use coupon code "theferalengineer" and
> > receive
> > > 20% off of your order 
> > >
> > > On Tue, Nov 29, 2022, 11:53 AM Steffen Möller 
> > > wrote:
> > >
> > > > Hello,
> > > >
> > > > No need to watch this, really. Titan has a nice Heller machine and
> > passes
> > > > the Sinumeric control
> > > > https://youtu.be/zToKZtqQMIo?t=354
> > > > with some excitement. I actually find LinuxCNC even nicer, especially
> > for
> > > > what I saw from https://www.qtpyvcp.com/ .
> > > >
> > > > When we yesterday had this OpenMike session again, we had felt like
> > there
> > > > should be four USB sticks prepared:
> > > >   a) for two distros - Bullseye (Debian stable) and Bookworm (Debian
> > > > testing, soon stable)
> > > >   b) in two flavours - minimalistic and fully-featured (including
> > FreeCAD
> > > > and Inkscape to make a good impression on those who come from the
> > other OS)
> > > >
> > > > Andy had some confidence (and I share that) that the generation of
> > those
> > > > .iso files per se is not difficult. It was not immediately clear where
> > the
> > > > generation of those .iso files sh

[Emc-developers] Eye candy is important - Titan got a new German friend - want that reaction for a LinuxCNC controller

[Steffen Möller]

Hello,

No need to watch this, really. Titan has a nice Heller machine and passes the 
Sinumeric control
https://youtu.be/zToKZtqQMIo?t=354
with some excitement. I actually find LinuxCNC even nicer, especially for what 
I saw from https://www.qtpyvcp.com/ .

When we yesterday had this OpenMike session again, we had felt like there 
should be four USB sticks prepared:
  a) for two distros - Bullseye (Debian stable) and Bookworm (Debian testing, 
soon stable)
  b) in two flavours - minimalistic and fully-featured (including FreeCAD and 
Inkscape to make a good impression on those who come from the other OS)

Andy had some confidence (and I share that) that the generation of those .iso 
files per se is not difficult. It was not immediately clear where the 
generation of those .iso files should happen, but the builders maintained by 
Sebastian are a likely target IMO.

Question: Is there anybody out there who would like to work with me on a 
description and implementation of what the fully-featured .ISO should like 
alike? This would be Intel-only as a start, leaving everything for the RPi to 
Raspbian for the time being.

There are a couple of Python libraries still missing on Debian to get QtPyVCP 
installed. This would likely be something for me to address.

Best,
Steffem



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] In ~2h: Next LinuxCNC video chat

[Steffen Möller]

Quick reminder

> [Petter Reinholdtsen 2022-11-11]
> > The next LinuxCNC video chat is scheduled for 2022-11-28 19:00 UTC
> > (19:00 London time, 20:00 Central Europe time).  Same location as last
> > time:
> >
> >   https://meet.jit.si/LinuxCNC-meeting-november-2022

Best,
Steffen


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Merge Strategy

[Steffen Möller]

> Gesendet: Montag, 28. November 2022 um 06:43 Uhr
> Von: "Chris Morley" 
> An: "EMC developers" 
> Betreff: Re: [Emc-developers] Merge Strategy
>
> Can you explain why merging up is better then cherry-picking or separate 
> commits?

@Seb explains this better, my short answer would be that it seems easier.

> Merge strategy should not change based on what should or should not be moved 
> forward.
> The strategy must be the same.

I may misunderstand the word "strategy".  The strategy I think is that every 
bug is fixed at its root. That strategy is the operationalized with the help of 
the assumption that if that root existed prior to 2.9 then the fix should also 
be performed on the branch that represents 2.9 and that if the master branch 
can pull from 2.9 then the fix gets fixed in the current version, too.

Now, I know that this is not always possible. The most trivial counter-example 
coming to my mind is a typo in the name of a pin. If a correction involves that 
changed pin name (or another part of an API change) then the mere pull is not 
sufficient to fix the bug. Extra insights are required. Also, a problem may 
refer to a function that was removed. But this does not interfere with the 
basic strategy to fix early and pull. Some un-pull-able change should likely 
then be in another branch like "2.9-release" that branches off from "2.9".

The benefit of merging up over a cherry-pick IMHO is that it looks like more 
robust. But that is more like a gut feeling than me knowing. If the 
cherry-patches go into 2.9 and the 2.9-only-fruits go into a 2.9-release branch 
then I think this looks mostly equivalent?

Best,
Steffen

> 
> From: Steffen Möller 
> Sent: November 28, 2022 1:04 AM
> To: emc-developers@lists.sourceforge.net 
> 
> Subject: Re: [Emc-developers] Merge Strategy
> 
> IMHO we should continue with the merge-up and start thinking again when there 
> is a change to 2.9 that should not be forwarded.
> Best,
> Steffen
> 
> > Gesendet: Sonntag, 27. November 2022 um 19:11 Uhr
> > Von: "Chris Morley" 
> > An: "EMC developers" 
> > Betreff: Re: [Emc-developers] Merge Strategy
> >
> > Well we will never agree on anything different if we never discuss it.
> > How about throwing out an opinion here?
> >
> > Chris
> > 
> > From: Hans Unzner 
> > Sent: November 27, 2022 10:54 AM
> > To: emc-developers@lists.sourceforge.net 
> > 
> > Subject: Re: [Emc-developers] Merge Strategy
> >
> > I agree that we should stick to "merge up" until we reach an agreement
> > to change this.
> >
> > Hans
> >
> > Am 23.11.22 um 22:42 schrieb Chris Morley:
> > > Ya it's always been hard to consistently get answers in our project.
> > > It just seems the nature of our group.
> > > Thanks for continuing to try.
> > >
> > > Currently strategy is to merge up, though you can cherry-pick up too, as 
> > > a merge later should understand this.
> > > But we rarely do anything with an older-then-current-release (I realize 
> > > that 2.8 is still sorta current)
> > >
> > > On the absence of an agreement, I am merging up 2.9 to master to keep in 
> > > sync.
> > >
> > > Chris
> > > 
> > > From: andy pugh 
> > > Sent: November 23, 2022 4:59 PM
> > > To: EMC developers 
> > > Subject: [Emc-developers] Merge Strategy
> > >
> > > On Tue, 8 Nov 2022 at 21:38, Chris Morley  
> > > wrote:
> > >> I wonder if we might discuss a different merging strategy for 2 9/master.
> > >> This would be relative to work being done in 2.9 for release.
> > >>
> > >> I suggest we don't merge up any more.
> > >> Cherry pick or a separate commit makes more sense to me.
> > >>
> > > Well, the discussion seems to have resulted in nothing happening, and
> > > some things in 2,8 that probably do belong in 2.9 and master.
> > >
> > > So what _is_ the current policy?
> > >
> > >
> > > --
> > > atp
> > > "A motorcycle is a bicycle with a pandemonium attachment and is
> > > designed for the especial use of mechanical geniuses, daredevils and
> > > lunatics."
> > > — George Fitch, Atlanta Constitution Newspaper, 1912
> > >
> > >
> > > ___
> > > Emc-developers mailing list
> > &g

Re: [Emc-developers] Merge Strategy

[Steffen Möller]

IMHO we should continue with the merge-up and start thinking again when there 
is a change to 2.9 that should not be forwarded.
Best,
Steffen

> Gesendet: Sonntag, 27. November 2022 um 19:11 Uhr
> Von: "Chris Morley" 
> An: "EMC developers" 
> Betreff: Re: [Emc-developers] Merge Strategy
>
> Well we will never agree on anything different if we never discuss it.
> How about throwing out an opinion here?
> 
> Chris
> 
> From: Hans Unzner 
> Sent: November 27, 2022 10:54 AM
> To: emc-developers@lists.sourceforge.net 
> 
> Subject: Re: [Emc-developers] Merge Strategy
> 
> I agree that we should stick to "merge up" until we reach an agreement
> to change this.
> 
> Hans
> 
> Am 23.11.22 um 22:42 schrieb Chris Morley:
> > Ya it's always been hard to consistently get answers in our project.
> > It just seems the nature of our group.
> > Thanks for continuing to try.
> >
> > Currently strategy is to merge up, though you can cherry-pick up too, as a 
> > merge later should understand this.
> > But we rarely do anything with an older-then-current-release (I realize 
> > that 2.8 is still sorta current)
> >
> > On the absence of an agreement, I am merging up 2.9 to master to keep in 
> > sync.
> >
> > Chris
> > 
> > From: andy pugh 
> > Sent: November 23, 2022 4:59 PM
> > To: EMC developers 
> > Subject: [Emc-developers] Merge Strategy
> >
> > On Tue, 8 Nov 2022 at 21:38, Chris Morley  
> > wrote:
> >> I wonder if we might discuss a different merging strategy for 2 9/master.
> >> This would be relative to work being done in 2.9 for release.
> >>
> >> I suggest we don't merge up any more.
> >> Cherry pick or a separate commit makes more sense to me.
> >>
> > Well, the discussion seems to have resulted in nothing happening, and
> > some things in 2,8 that probably do belong in 2.9 and master.
> >
> > So what _is_ the current policy?
> >
> >
> > --
> > atp
> > "A motorcycle is a bicycle with a pandemonium attachment and is
> > designed for the especial use of mechanical geniuses, daredevils and
> > lunatics."
> > — George Fitch, Atlanta Constitution Newspaper, 1912
> >
> >
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
> >
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
> 
> 
> 
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
> 
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Next LinuxCNC video chat

[Steffen Möller]

Hello,

One principle of those Video chats that shall prevent any impression of a 
power-grab is that every time someone else is hosting it who then acts as a 
moderator. The overall idea I think is that someone working on something (or 
about to work on something) gets some extra stimulus or the sensation of some 
presence from the community. I tend to think that everything is discussed on 
this list, still. Also, these calls are happening too rarely (is it every 
second month?) as that anyone would hold back on the list to raise an issue.

Petter (who is not subscribed to this list - an IRC person) will be the next 
host and then maybe we should find someone outside the GMT+-1 comfort zone as a 
host. That maybe also helps with integrating those who yet did not (or not too 
frequently) attend, I hope. The next host is typically decided at the end of 
those video sessions but let's have it here. Any takers?

Best,
Steffen

> Gesendet: Donnerstag, 24. November 2022 um 17:53 Uhr
> Von: "Chris Morley" 
> An: "EMC developers" 
> Betreff: Re: [Emc-developers] Next LinuxCNC video chat
>
> We were hardly zero tier.
> My complaint is that if you didn't go to the video meeting that there seemed 
> to be no way to find out what happened, nor a way to see the discussion after 
> the fact.
> 
> That is what I meant by two tier.
> 
> IMHO the first order of business of the video meeting would be to figure out 
> how to include people not there with reasonable effort. The nice thing about 
> maillists and chats is that they are self documenting.
> 
> There is nothing wrong with having video chats from time to time. But I think 
> you are using it to force (relatively) quick decisions rather then an 
> alternative way to comunnicate.
> 
> You want to get something done in this project faster - then become a 
> developer and do it.
> We very seldom refuse to incorporate work that was been merged.
> I found out pretty early that if I wanted to do work that I thought might be 
> a problem then I would ty to discuss on the maillist. Sometimes people 
> answered, sometimes not. If not, then I would merge my work when ready. 
> Nothing like merged work to motivate people to get involved.
> 
> Obviously, there are some things that we need to agree on - such as merge 
> strategy that we must discuss to change, but the time it takes to discuss on 
> mail list is actually an advantage.
> 
> What we are really missing is a vision to converge on and a leader to see it 
> through.
> And more developers. But that is no guarantee either - mackinekit had those 
> and has petered out it seems, unfortunately.
> 
> But now that I have a link, at least I can see the summary of what you were 
> thinking/discussing.
> 
> Chris
> 
> From: Jérémie Tarot 
> Sent: November 24, 2022 3:40 PM
> To: EMC developers 
> Subject: Re: [Emc-developers] Next LinuxCNC video chat
> 
> Le jeu. 24 nov. 2022 à 06:19, Chris Morley  a
> écrit :
> 
> > How about a summary write up?
> >
> 
> Andy has just pointed to them so won't double.
> 
> 
> > We are making a two tier project if we continue like this.
> >
> 
> At least that's some tiers !
> Seeing our inability to discuss and decide lately, at least to support
> and/or free Andy, if not to look forward and plan for the future, we almost
> look like a zero tier no-org :'(
> Hopefully some things will come out of it because written channels have
> proven inoperative these days...
> 
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
> 
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Built LinuxCNC 2.9 bookworm .iso - where shall I put it? Re: Plans for the USB sticks anyone?

[Steffen Möller]

Rod,

Thank you tons for that pointer. I'll investigate that phenotype tomorrow. I 
just invited you (+Andy+Seb) to a folder on Google Drive and,
@Andy, I'll ping you once I know if I can reproduce that OpenGL issue on that 
version - built two days ago.

Best,
Steffen

> Gesendet: Donnerstag, 24. November 2022 um 21:05 Uhr
> Von: "Rod Webster" 
> An: "EMC developers" 
> Betreff: Re: [Emc-developers] Built LinuxCNC 2.9 bookworm .iso - where shall 
> I put it? Aw: Re: Plans for the USB sticks anyone?
>
> I would like to flag while you are talking about ISOs that Bookworm is no
> longer running linuxcnc on Debian's default desktop environment after an
> apt-get upgrade last night (which brought in the latest linuxcnc_uspace
> package from November 5. This desktop has always worked since I started
> playing with Debian Bullseye before it was officially released.
> 
> I thought I had resolved this (for Axis and QTPlasmac) by reverting to the
> XFCE desktop but this morning it's been reported that Gmoccappy  and other
> GUI's are broken by the same OpenGL error.
> Refer to this forum thread
> https://forum.linuxcnc.org/ethercat/47372-any-recommendations-for-a-mini-pc-for-an-ethercat-setup?start=10#257502
> 
> 
> Rod Webster
> *1300 896 832*
> +61 435 765 611
> Vehicle Modifications Network
> www.vehiclemods.net.au
> 
> 
> On Fri, 25 Nov 2022 at 02:18, andy pugh  wrote:
> 
> > On Thu, 24 Nov 2022 at 16:08, Steffen Möller 
> > wrote:
> >
> > > I could well imagine that there are some other folks interested to play
> > with this. Can I put this somewhere underneath linuxcnc.org?
> >
> > It could go in www.linuxcnc.org/iso
> >
> > Though it would have to be put there by someone with write access (I have
> > that)
> >
> > --
> > atp
> > "A motorcycle is a bicycle with a pandemonium attachment and is
> > designed for the especial use of mechanical geniuses, daredevils and
> > lunatics."
> > — George Fitch, Atlanta Constitution Newspaper, 1912
> >
> >
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
> >
> 
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] Built LinuxCNC 2.9 bookworm .iso - where shall I put it? Aw: Re: Plans for the USB sticks anyone?

[Steffen Möller]

Dear all,

> Gesendet: Montag, 14. November 2022 um 15:49 Uhr
> Von: "Steffen Möller" > 
> 
> > Gesendet: Montag, 14. November 2022 um 10:28 Uhr
> > Von: "andy pugh" 
> >
> > On Mon, 14 Nov 2022 at 08:52, Steffen Möller  wrote:
> > 
> > > b) the Live USB stick with LinuxCNC (and other useful or eye candy bits) 
> > > on it
> > >
> > > Is there any "production team" for b) already? I would like to discuss 
> > > what is missing and/or should be updated.
> > 
> > It uses live-build and is controlled by:
> > https://github.com/LinuxCNC/linuxcnc-live-build
> 
> Found it. Thank you for the pointer. That repository features a branch 
> "bookworm" next to a branch "buster", nothing for "bullseye".
> 
> I am tempted to suggest that the LiveCD may run with bookworm. My line of 
> thought is that when we release, bookworm will already be "frozen", such that 
> the parts of Debian we are using are unlikely to see much of a change until 
> the release gets out.

I have done it. The nouveau video driver is not stable with my legacy NVidia 
card, will hence try another machine with it, otherwise it looks ok. Will start 
toying around with the non-free original Nvidia drivers. A missing packages is 
"installation-report" (so we can learn about the hardware causing problems).

I could well imagine that there are some other folks interested to play with 
this. Can I put this somewhere underneath linuxcnc.org?

Best,
Steffen




___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Next LinuxCNC video chat

[Steffen Möller]

Heya,

I was also raised with "goto = evil" and it took me some decades to overcome 
this mantra/early brainwash. Hereto, Linus' "while+goto looks more beautiful in 
assembly" was important for me 
(https://koblents.com/Ches/Links/Month-Mar-2013/20-Using-Goto-in-Linux-Kernel-Code/).

I did not exactly follow the seeds of this exchange, and likely will not get 
all the details if I tried, but

10 please allow GOTOs in.
20 goto 10

Cheers,
Steffen

> Gesendet: Donnerstag, 24. November 2022 um 16:17 Uhr
> Von: "Feral Engineer" 
> An: "EMC developers" 
> Betreff: Re: [Emc-developers] Next LinuxCNC video chat
>
> It's a familiarity thing with people engrained in the fanuc macro b
> philosophy. When all you have is a hammer, everything is a nail.
> 
> Fanuc only had basic logic functionality for decades; if, goto and while.
> They added THEN with the 30iA, i believe, and most recently, on the fanuc
> 30i B that only came out a few years ago, they enabled ELSE, but you need
> to change a parameter to even turn it on. The Mitsubishi 730 control also
> has if, then, goto, else, and while, but Sinumerik has 3 dimensional
> arrays, user definable, nonvolatile variable tables, FOR loops, char,
> string, double (known as real), int, axis and frame data types, plus 5
> different goto, as I mentioned. That's not even including custom user cycle
> calls with easyscreen gui support. Fwiw, I've peeked at theb LinuxCNC
> source code. There are goto jumps in it.
> 
> The question always stands, does LinuxCNC want to gain mainstream
> popularity or does it just want to remain a tinker toy to a select few? Is
> this just a developer's pet project or is this a machine tool control,
> meant to be used by people who understand machine tools? I started a pretty
> popular Facebook messenger chat that tells me there is definitely a growing
> interest, but even one of the other guys in my chat works for Renishaw and
> agrees that the lack of goto really hinders workflow for those who are used
> to having it.
> 
> I really would like to be a useful resource to the project. I've got 2
> decades of experience working for one of the largest CNC machine tool
> builders in the world and know a handful of top tier controls inside and
> out.
> 
> 
> Phil T.
> The Feral Engineer
> 
> Check out my LinuxCNC tutorials, machine builds and other antics at
> www.youtube.com/c/theferalengineer
> 
> Help support my channel efforts and coffee addiction:
> www.patreon.com/theferalengineer
> 
> Order one of the coolest label makers on the market at
> http://labelworks.epson.com, use coupon code "theferalengineer" and receive
> 20% off of your order 
> 
> On Thu, Nov 24, 2022, 9:52 AM andy pugh  wrote:
> 
> > On Thu, 24 Nov 2022 at 14:29, Feral Engineer 
> > wrote:
> >
> > > To comment on the section involving Siemens Sinumerik, at least one of
> > the
> > > 5 different goto options would be nice to have
> >
> > I think that will be a fight, there are too many programmers on the
> > team who have been taught that GOTO is evil.
> >
> > There isn't anything that can be done with GOTO that can't be done
> > with IF/ELSE/ENDIF or GOSUB/RETURN though.
> >
> > --
> > atp
> > "A motorcycle is a bicycle with a pandemonium attachment and is
> > designed for the especial use of mechanical geniuses, daredevils and
> > lunatics."
> > — George Fitch, Atlanta Constitution Newspaper, 1912
> >
> >
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
> >
> 
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] time delay hal component for lube pump

[Steffen Möller]

How close is http://linuxcnc.org/docs/html/man/man9/oneshot.9.html to what you 
need? Should we possibly extend it for whatever is missing? And/or should the 
description of oneshot improve?

> Von: "Feral Engineer" 

> Classicladder is awesome for this 

That is what I also thought. Conceptually, just need to develop my respective 
skills a bit more.

> Check out my LinuxCNC tutorials, machine builds and other antics at
> www.youtube.com/c/theferalengineer

I have subscribed :)

Best,
Steffen

> On Mon, Nov 21, 2022, 4:17 PM Jon Elson  wrote:
> 
> > Hello, all,
> > I need a hal component for a lube pump.  What I am looking
> > for is more like a one-shot than the existing timedelay
> > component.
> > timedelay seems to be able to delay the start or the end of
> > a signal, but output will follow the input after the delays
> > occur.  I wanted a component that would trigger for a set
> > time after a trigger (or LinuxCNC starting) and then, I
> > could or it with the spindle enables.  This would ensure the
> > lube pump starts immediately when LCNC starts, and then run
> > whenever the spindle is on.  Anybody know a better way to do
> > this?
> > Thanks,
> > Jon
> >
> >
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
> >
> 
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers