Re: [Emc-developers] cam align

2022-09-04 Thread Phill Carter
FWIW I have tried the /configs/sim/axis/qtvcp/qtvcp_tabs sample on a 64bit Pi4 
and it works.
raspberrypi:~ $ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux 11 (bullseye)
Release:11
Codename:   bullseye

raspberrypi:~ $ uname -a
Linux raspberrypi 5.15.27-rt35-v8+ #1 SMP PREEMPT_RT Fri Mar 11 16:34:20 GMT 
2022 aarch64 GNU/Linux

I got rid of the python3-gst1.0 installed? with:
sudo apt-install python3-gst-1.0

There are a lot of these errors on closing but it seems to have no ill effect.:
qt.qpa.xcb: QXcbConnection: XCB error: 9 (BadDrawable), sequence: 3320, 
resource id: 33554438, major code: 130 (Unknown), minor code: 3

I got rid of them with:
export QT_LOGGING_RULES='qt.qpa.*=false'


> On 5 Sep 2022, at 11:37 am, Chris Morley  wrote:
> 
> Hi Gene.
> I actually see no apparent show stoppers.
> The Desktop Notify error is weird but seems to not stop anything.
> It just seems not to embed.
> 
> 
> Could your try the sim sim/axis/qtvcp/qtvcp_tabs sample.
> 
> It should embed a cam window too.
> also is the new tab window completely plain or is there text?
> 
> Chris
> 
> 
> From: gene heskett 
> Sent: September 5, 2022 1:21 AM
> To: EMC developers 
> Subject: [Emc-developers] cam align
> 
> Gretibgs all;
> 
> I se some debugging has been turned on so it not a showstopper on my g0704.
> 
> The camera tab is created, but empty.
> 
> The terminal its launched from now contains some debugging info that may
> be useful:
> 
> halcmd loadusr -Wn qtvcp_embed qtvcp -d -c qtvcp_embed -x {XID} cam_align
> [False]
> Waiting for component 'qtvcp_embed' to become
> ready[QTvcp.QTVCP.LIB.SYS_NOTIFY][WARNING]
> Desktop Notify not available:: org.freedesktop.DBus.Error.NoReply: Did
> not receive a reply. Possible causes include: the remote application did
> not send a reply, the message bus security policy blocked the reply, the
> reply timeout expired, or the network connection was broken.
> (sys_notify.py:71)
> Namespace Gst not available
> [QTvcp.QTVCP.LIB.AUDIO_PLAYER][WARNING]  audio alerts - Is
> python3-gst1.0 installed? (audio_player.py:37)
> .[QTvcp][INFO]  Logging to: /home/gene/qtvcp.log (logger.py:67)
> [QTvcp][INFO]  Base log level set to: 10 (logger.py:68)
> [QTvcp.QTVCP.QT_PSTAT][DEBUG]  BASEPATH cam_align (qt_pstat.py:86)
> [QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for handler file in:
> /home/gene/linuxcnc/configs/GO704-5i25-7i76/cam_align_handler.py
> (qt_pstat.py:96)
> [QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for default handler file in:
> /usr/share/qtvcp/panels/cam_align/cam_align_handler.py (qt_pstat.py:102)
> [QTvcp.QTVCP.QT_PSTAT][INFO]  Using DEFAULT handler file path:
> /usr/share/qtvcp/panels/cam_align/cam_align_handler.py (qt_pstat.py:105)
> [QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .ui in:
> /home/gene/linuxcnc/configs/GO704-5i25-7i76/cam_align.ui (qt_pstat.py:123)
> [QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .ui in:
> /usr/share/qtvcp/panels/cam_align/cam_align.ui (qt_pstat.py:128)
> [QTvcp.QTVCP.QT_PSTAT][INFO]  Using DEFAULT ui file from:
> /usr/share/qtvcp/panels/cam_align/cam_align.ui (qt_pstat.py:130)
> [QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .qss in:
> /home/gene/linuxcnc/configs/GO704-5i25-7i76/cam_align.qss (qt_pstat.py:160)
> [QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .qss in:
> /usr/share/qtvcp/panels/cam_align/cam_align.qss (qt_pstat.py:165)
> [QTvcp.QTVCP.QT_PSTAT][INFO]  No qss file found. (qt_pstat.py:171)
> [QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .qrc in:
> /home/gene/linuxcnc/configs/GO704-5i25-7i76/cam_align.qrc (qt_pstat.py:182)
> [QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .qrc in:
> /usr/share/qtvcp/panels/cam_align/cam_align.qrc (qt_pstat.py:188)
> [QTvcp.QTVCP.QT_PSTAT][INFO]  No qrc file found. (qt_pstat.py:195)
> [QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for resources.py in:
> /home/gene/linuxcnc/configs/GO704-5i25-7i76/qtvcp/panels/resources.py
> (qt_pstat.py:205)
> [QTvcp.QTVCP.QT_PSTAT][INFO]  No resources.py file found, no QRC file to
> compile one from. (qt_pstat.py:216)
> [QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for translation file in:
> /home/gene/linuxcnc/configs/GO704-5i25-7i76/cam_align/languages/cam_align_en.qm
> (qt_pstat.py:223)
> [QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for translation file in:
> /usr/share/qtvcp/screens/cam_align/languages/cam_align_en.qm
> (qt_pstat.py:228)
> [QTvcp.QTVCP.QT_PSTAT][INFO]  Using no translations, default system
> locale is: en (qt_pstat.py:233)
> [QTvcp][INFO]  Building A VCP Panel with: Python 3 (qtvcp:215)
> [QTvcp][INFO]  No handler file specified - using:
> /usr/share/qtvcp/panels/cam_align/cam_align_handler.py (qtvcp:218)
> [QTvcp.QTVCP.QT_MAKEGUI][INFO]  Qsettings file path:
> 

Re: [Emc-developers] cam align

2022-09-04 Thread Chris Morley
Hi Gene.
I actually see no apparent show stoppers.
The Desktop Notify error is weird but seems to not stop anything.
It just seems not to embed.


Could your try the sim sim/axis/qtvcp/qtvcp_tabs sample.

It should embed a cam window too.
also is the new tab window completely plain or is there text?

Chris


From: gene heskett 
Sent: September 5, 2022 1:21 AM
To: EMC developers 
Subject: [Emc-developers] cam align

Gretibgs all;

I se some debugging has been turned on so it not a showstopper on my g0704.

The camera tab is created, but empty.

The terminal its launched from now contains some debugging info that may
be useful:

halcmd loadusr -Wn qtvcp_embed qtvcp -d -c qtvcp_embed -x {XID} cam_align
[False]
Waiting for component 'qtvcp_embed' to become
ready[QTvcp.QTVCP.LIB.SYS_NOTIFY][WARNING]
Desktop Notify not available:: org.freedesktop.DBus.Error.NoReply: Did
not receive a reply. Possible causes include: the remote application did
not send a reply, the message bus security policy blocked the reply, the
reply timeout expired, or the network connection was broken.
(sys_notify.py:71)
Namespace Gst not available
[QTvcp.QTVCP.LIB.AUDIO_PLAYER][WARNING]  audio alerts - Is
python3-gst1.0 installed? (audio_player.py:37)
.[QTvcp][INFO]  Logging to: /home/gene/qtvcp.log (logger.py:67)
[QTvcp][INFO]  Base log level set to: 10 (logger.py:68)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  BASEPATH cam_align (qt_pstat.py:86)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for handler file in:
/home/gene/linuxcnc/configs/GO704-5i25-7i76/cam_align_handler.py
(qt_pstat.py:96)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for default handler file in:
/usr/share/qtvcp/panels/cam_align/cam_align_handler.py (qt_pstat.py:102)
[QTvcp.QTVCP.QT_PSTAT][INFO]  Using DEFAULT handler file path:
/usr/share/qtvcp/panels/cam_align/cam_align_handler.py (qt_pstat.py:105)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .ui in:
/home/gene/linuxcnc/configs/GO704-5i25-7i76/cam_align.ui (qt_pstat.py:123)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .ui in:
/usr/share/qtvcp/panels/cam_align/cam_align.ui (qt_pstat.py:128)
[QTvcp.QTVCP.QT_PSTAT][INFO]  Using DEFAULT ui file from:
/usr/share/qtvcp/panels/cam_align/cam_align.ui (qt_pstat.py:130)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .qss in:
/home/gene/linuxcnc/configs/GO704-5i25-7i76/cam_align.qss (qt_pstat.py:160)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .qss in:
/usr/share/qtvcp/panels/cam_align/cam_align.qss (qt_pstat.py:165)
[QTvcp.QTVCP.QT_PSTAT][INFO]  No qss file found. (qt_pstat.py:171)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .qrc in:
/home/gene/linuxcnc/configs/GO704-5i25-7i76/cam_align.qrc (qt_pstat.py:182)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .qrc in:
/usr/share/qtvcp/panels/cam_align/cam_align.qrc (qt_pstat.py:188)
[QTvcp.QTVCP.QT_PSTAT][INFO]  No qrc file found. (qt_pstat.py:195)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for resources.py in:
/home/gene/linuxcnc/configs/GO704-5i25-7i76/qtvcp/panels/resources.py
(qt_pstat.py:205)
[QTvcp.QTVCP.QT_PSTAT][INFO]  No resources.py file found, no QRC file to
compile one from. (qt_pstat.py:216)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for translation file in:
/home/gene/linuxcnc/configs/GO704-5i25-7i76/cam_align/languages/cam_align_en.qm
(qt_pstat.py:223)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for translation file in:
/usr/share/qtvcp/screens/cam_align/languages/cam_align_en.qm
(qt_pstat.py:228)
[QTvcp.QTVCP.QT_PSTAT][INFO]  Using no translations, default system
locale is: en (qt_pstat.py:233)
[QTvcp][INFO]  Building A VCP Panel with: Python 3 (qtvcp:215)
[QTvcp][INFO]  No handler file specified - using:
/usr/share/qtvcp/panels/cam_align/cam_align_handler.py (qtvcp:218)
[QTvcp.QTVCP.QT_MAKEGUI][INFO]  Qsettings file path:
/home/gene/.config/QtVcp/cam_align.conf (qt_makegui.py:97)
[QTvcp][DEBUG]  Loading the handler file. (qtvcp:276)
[QTvcp.QTVCP.QT_MAKEGUI][DEBUG]  Adding import dir:
/usr/share/qtvcp/panels/cam_align (qt_makegui.py:290)
[QTvcp.QTVCP.QT_MAKEGUI][DEBUG]  Module 'cam_align_handler' imported OK
(qt_makegui.py:301)
[QTvcp.QTVCP.QT_MAKEGUI][DEBUG]  Module 'cam_align_handler' :
'get_handlers' function found. (qt_makegui.py:307)
[QTvcp.QTVCP.QT_MAKEGUI][DEBUG]  Registering handlers in module
cam_align_handler object  (qt_makegui.py:317)
[QTvcp.QTVCP.QT_MAKEGUI][DEBUG]  Register callback 'call_user_command_'
(qt_makegui.py:326)
[QTvcp.QTVCP.QT_MAKEGUI][DEBUG]  Register callback 'initialized__'
(qt_makegui.py:326)
[QTvcp][DEBUG]  Adding the key events filter. (qtvcp:286)
[QTvcp.QTVCP.QT_MAKEGUI][INFO]  No resource file to load: None
(qt_makegui.py:192)
.[QTvcp.QTVCP.QT_MAKEPINS][DEBUG]  QTVCP: Parsing for HAL widgets.
(qt_makepins.py:114)
[QTvcp][DEBUG]  Calling the handler file's 

[Emc-developers] cam align

2022-09-04 Thread gene heskett

Gretibgs all;

I se some debugging has been turned on so it not a showstopper on my g0704.

The camera tab is created, but empty.

The terminal its launched from now contains some debugging info that may 
be useful:


halcmd loadusr -Wn qtvcp_embed qtvcp -d -c qtvcp_embed -x {XID} cam_align
[False]
Waiting for component 'qtvcp_embed' to become 
ready[QTvcp.QTVCP.LIB.SYS_NOTIFY][WARNING] 
Desktop Notify not available:: org.freedesktop.DBus.Error.NoReply: Did 
not receive a reply. Possible causes include: the remote application did 
not send a reply, the message bus security policy blocked the reply, the 
reply timeout expired, or the network connection was broken. 
(sys_notify.py:71)

Namespace Gst not available
[QTvcp.QTVCP.LIB.AUDIO_PLAYER][WARNING]  audio alerts - Is 
python3-gst1.0 installed? (audio_player.py:37)

.[QTvcp][INFO]  Logging to: /home/gene/qtvcp.log (logger.py:67)
[QTvcp][INFO]  Base log level set to: 10 (logger.py:68)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  BASEPATH cam_align (qt_pstat.py:86)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for handler file in: 
/home/gene/linuxcnc/configs/GO704-5i25-7i76/cam_align_handler.py 
(qt_pstat.py:96)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for default handler file in: 
/usr/share/qtvcp/panels/cam_align/cam_align_handler.py (qt_pstat.py:102)
[QTvcp.QTVCP.QT_PSTAT][INFO]  Using DEFAULT handler file path: 
/usr/share/qtvcp/panels/cam_align/cam_align_handler.py (qt_pstat.py:105)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .ui in: 
/home/gene/linuxcnc/configs/GO704-5i25-7i76/cam_align.ui (qt_pstat.py:123)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .ui in: 
/usr/share/qtvcp/panels/cam_align/cam_align.ui (qt_pstat.py:128)
[QTvcp.QTVCP.QT_PSTAT][INFO]  Using DEFAULT ui file from: 
/usr/share/qtvcp/panels/cam_align/cam_align.ui (qt_pstat.py:130)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .qss in: 
/home/gene/linuxcnc/configs/GO704-5i25-7i76/cam_align.qss (qt_pstat.py:160)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .qss in: 
/usr/share/qtvcp/panels/cam_align/cam_align.qss (qt_pstat.py:165)

[QTvcp.QTVCP.QT_PSTAT][INFO]  No qss file found. (qt_pstat.py:171)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .qrc in: 
/home/gene/linuxcnc/configs/GO704-5i25-7i76/cam_align.qrc (qt_pstat.py:182)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .qrc in: 
/usr/share/qtvcp/panels/cam_align/cam_align.qrc (qt_pstat.py:188)

[QTvcp.QTVCP.QT_PSTAT][INFO]  No qrc file found. (qt_pstat.py:195)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for resources.py in: 
/home/gene/linuxcnc/configs/GO704-5i25-7i76/qtvcp/panels/resources.py 
(qt_pstat.py:205)
[QTvcp.QTVCP.QT_PSTAT][INFO]  No resources.py file found, no QRC file to 
compile one from. (qt_pstat.py:216)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for translation file in: 
/home/gene/linuxcnc/configs/GO704-5i25-7i76/cam_align/languages/cam_align_en.qm 
(qt_pstat.py:223)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for translation file in: 
/usr/share/qtvcp/screens/cam_align/languages/cam_align_en.qm 
(qt_pstat.py:228)
[QTvcp.QTVCP.QT_PSTAT][INFO]  Using no translations, default system 
locale is: en (qt_pstat.py:233)

[QTvcp][INFO]  Building A VCP Panel with: Python 3 (qtvcp:215)
[QTvcp][INFO]  No handler file specified - using: 
/usr/share/qtvcp/panels/cam_align/cam_align_handler.py (qtvcp:218)
[QTvcp.QTVCP.QT_MAKEGUI][INFO]  Qsettings file path: 
/home/gene/.config/QtVcp/cam_align.conf (qt_makegui.py:97)

[QTvcp][DEBUG]  Loading the handler file. (qtvcp:276)
[QTvcp.QTVCP.QT_MAKEGUI][DEBUG]  Adding import dir: 
/usr/share/qtvcp/panels/cam_align (qt_makegui.py:290)
[QTvcp.QTVCP.QT_MAKEGUI][DEBUG]  Module 'cam_align_handler' imported OK 
(qt_makegui.py:301)
[QTvcp.QTVCP.QT_MAKEGUI][DEBUG]  Module 'cam_align_handler' : 
'get_handlers' function found. (qt_makegui.py:307)
[QTvcp.QTVCP.QT_MAKEGUI][DEBUG]  Registering handlers in module 
cam_align_handler object 0x7f262b1fd3c8> (qt_makegui.py:317)
[QTvcp.QTVCP.QT_MAKEGUI][DEBUG]  Register callback 'call_user_command_' 
(qt_makegui.py:326)
[QTvcp.QTVCP.QT_MAKEGUI][DEBUG]  Register callback 'initialized__' 
(qt_makegui.py:326)

[QTvcp][DEBUG]  Adding the key events filter. (qtvcp:286)
[QTvcp.QTVCP.QT_MAKEGUI][INFO]  No resource file to load: None 
(qt_makegui.py:192)
.[QTvcp.QTVCP.QT_MAKEPINS][DEBUG]  QTVCP: Parsing for HAL widgets. 
(qt_makepins.py:114)
[QTvcp][DEBUG]  Calling the handler file's initialized__ function 
(qtvcp:309)
[QTvcp.QTVCP.QT_MAKEGUI][INFO]  No Handler Override file at: 
/home/gene/linuxcnc/configs/GO704-5i25-7i76/.cam_alignrc (qt_makegui.py:358)

[QTvcp][DEBUG]  Set HAL ready. (qtvcp:334)

[QTvcp][CRITICAL]  Forwarding events to AXIS is not well tested yet. 
(qtvcp:343)

[QTvcp][DEBUG]  Show window. (qtvcp:391)
[QTvcp.QTVCP.QT_MAKEPINS][INFO]  No preference file 

Re: [Emc-developers] Debian package - what is the future?

2022-09-04 Thread Rod Webster
Buildbot is not really useful in terms of testing the Debian build until
such times as it can build it on the target OS platform. If that's a
requirement, then the focus should be on buildbot upgrades.
I think back and we had a stretch distro well before stretch was the stable
debian release. It's really been disappointing not to have a Bullseye image
as it has left many users floundering.
There should not be any more work after the next version is hived off
master. The debian release should coincide with the release of the next
production version.
Look at V 2.8, it's only been upgraded 3 times since its release to 2.8.3
now. That's all that should be going to Debian.
I do think however that syncing with the Debian release cycle might require
a different mindset... But I think that would be a good thing.

I think Andy is on the right track. Draw a line, focus on bug fixes and no
new features and get in step with Debian sooner than later so the workload
is not increased.


Rod Webster
*1300 896 832*
+61 435 765 611
Vehicle Modifications Network
www.vehiclemods.net.au


On Mon, 5 Sept 2022 at 08:34, Chris Morley 
wrote:

> I'm not sure you could say it adds _no_ value - the code is compiled and
> tested by the buildbot.
> Just not on the target you wish yet. - not perfect but still lots of
> goodness.
>
> I personally don't see how we could have a good release candidate anywhere
> soon (depends what you mean soon of course - Andy implied weeks or the end
> of the year recently)
> I got basically no response on my discussion on it here on the maillist
> and I see no action towards it.
> We have run out of developers/developers time I think.
>
> But I was more wondering if anyone had thought through the logistics of
> dealing with another parallel release and potentially many(?) more users.
> I may be making a big deal out of nothing but I thought I'd ask others
> thoughts.
>
> Chris
> 
> From: Rod Webster 
> Sent: September 4, 2022 9:27 PM
> To: EMC developers 
> Subject: Re: [Emc-developers] Debian package - what is the future?
>
> What has been overlooked  so far is that there is still no buildbot version
> for 2.9 on Bullseye so its increasingly difficult to deploy Linuxcnc on
> newer hardware that requires say 5.10 kernel and higher. Buildbot is a long
> way behind current kernel versions.
>
>
> ___
> 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] Debian package - what is the future?

2022-09-04 Thread Chris Morley
I'm not sure you could say it adds _no_ value - the code is compiled and tested 
by the buildbot.
Just not on the target you wish yet. - not perfect but still lots of goodness.

I personally don't see how we could have a good release candidate anywhere soon 
(depends what you mean soon of course - Andy implied weeks or the end of the 
year recently)
I got basically no response on my discussion on it here on the maillist and I 
see no action towards it.
We have run out of developers/developers time I think.

But I was more wondering if anyone had thought through the logistics of dealing 
with another parallel release and potentially many(?) more users.
I may be making a big deal out of nothing but I thought I'd ask others thoughts.

Chris

From: Rod Webster 
Sent: September 4, 2022 9:27 PM
To: EMC developers 
Subject: Re: [Emc-developers] Debian package - what is the future?

What has been overlooked  so far is that there is still no buildbot version
for 2.9 on Bullseye so its increasingly difficult to deploy Linuxcnc on
newer hardware that requires say 5.10 kernel and higher. Buildbot is a long
way behind current kernel versions.


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


Re: [Emc-developers] Debian package - what is the future?

2022-09-04 Thread Rod Webster
What has been overlooked  so far is that there is still no buildbot version
for 2.9 on Bullseye so its increasingly difficult to deploy Linuxcnc on
newer hardware that requires say 5.10 kernel and higher. Buildbot is a long
way behind current kernel versions.

It's all very fine to support older distros so users don't have to upgrade
but what about new users on new hardware? These users currently have no
choice but to compile from source or use the Sid or Bookworm releases.

If there is a bunch of work to do to fix buildbot, wouldn't that effort be
better directed into releasing 2.9 as our official release via Debian in
time for the bookworm release? The version freeze is not really far away so
now would be a good time to get the new release rolling.

To me it seems buildbot is pretty much redundant as it's not adding value
on current versions of the OS which newer hardware enforces.

Rod Webster
*1300 896 832*
+61 435 765 611
Vehicle Modifications Network
www.vehiclemods.net.au


On Mon, 5 Sept 2022 at 05:51, Chris Morley 
wrote:

> Thank you for the explanation.
> It sounds to me we will likely/potentially have 3 or 4 versions to
> maintain.
> buildbot debs release version (for early bugfix users)
> Debian version that may or may not be up to date with the buildbot.
> Master version for development and traditionally daily use by early
> adopters.
>
> I'm just thinking aloud about how to help people and fix bugs.
> It's already a bit of a pain with installed vrs compiled of say two
> different versions.
> Add a Debian version that might be in between 
>
> I guess I hope we keep the Debian version in close lock step with the
> buildbot version.
> I am glad to hear we can update Debian package we ever we need to. I would
> guess the time to go
> from pushed fix to Debian update would be quite some time though.
>
> Chris
> 
> From: Sebastian Kuzminsky 
> Sent: September 4, 2022 6:00 PM
> To: emc-developers@lists.sourceforge.net <
> emc-developers@lists.sourceforge.net>
> Subject: Re: [Emc-developers] Debian package - what is the future?
>
> On 9/4/22 10:36, Sebastian Kuzminsky wrote:
> > There are currently four ways to get pre-built debs of linuxcnc:
> >
> > 1. debian.org
> >
> > 2. buildbot
> >
> > 3. www.linuxcnc.org
> >
> > 4. github "artifacts"
>
> I forgot to mention another important difference between the debian.org
> debs and the buildbot debs:
>
> The buildbot builds debs from every commit that passes our tests, so the
> buildbot debs are very up to date.  The debian.org debs are prepared by
> a human, so they get updated much less often.
>
>
> --
> 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


Re: [Emc-developers] Debian package - what is the future?

2022-09-04 Thread Chris Morley
Thank you for the explanation.
It sounds to me we will likely/potentially have 3 or 4 versions to maintain.
buildbot debs release version (for early bugfix users)
Debian version that may or may not be up to date with the buildbot.
Master version for development and traditionally daily use by early adopters.

I'm just thinking aloud about how to help people and fix bugs.
It's already a bit of a pain with installed vrs compiled of say two different 
versions.
Add a Debian version that might be in between 

I guess I hope we keep the Debian version in close lock step with the buildbot 
version.
I am glad to hear we can update Debian package we ever we need to. I would 
guess the time to go
from pushed fix to Debian update would be quite some time though.

Chris

From: Sebastian Kuzminsky 
Sent: September 4, 2022 6:00 PM
To: emc-developers@lists.sourceforge.net 
Subject: Re: [Emc-developers] Debian package - what is the future?

On 9/4/22 10:36, Sebastian Kuzminsky wrote:
> There are currently four ways to get pre-built debs of linuxcnc:
>
> 1. debian.org
>
> 2. buildbot
>
> 3. www.linuxcnc.org
>
> 4. github "artifacts"

I forgot to mention another important difference between the debian.org
debs and the buildbot debs:

The buildbot builds debs from every commit that passes our tests, so the
buildbot debs are very up to date.  The debian.org debs are prepared by
a human, so they get updated much less often.


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


Re: [Emc-developers] Debian package - what is the future?

2022-09-04 Thread Sebastian Kuzminsky

On 9/4/22 10:36, Sebastian Kuzminsky wrote:

There are currently four ways to get pre-built debs of linuxcnc:

1. debian.org

2. buildbot

3. www.linuxcnc.org

4. github "artifacts"


I forgot to mention another important difference between the debian.org 
debs and the buildbot debs:


The buildbot builds debs from every commit that passes our tests, so the 
buildbot debs are very up to date.  The debian.org debs are prepared by 
a human, so they get updated much less often.



--
Sebastian Kuzminsky


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


Re: [Emc-developers] Debian package - what is the future?

2022-09-04 Thread Sebastian Kuzminsky

On 9/3/22 23:53, Chris Morley wrote:

I see the action with Debian package.
I hope that gets us some more exposure and more develops/users.


Me too!



I did wonder what that means for the project as far as maintaining versions.
How are bug fixes addressed with Debian packages after (Debian) release?


Each debian package is built from a specific commit in our repo.  So far 
we've been using the tip of the master branch, but once we make the 2.9 
(or 3.0 or whatever) release branch we'll package from there, and 
ideally package our official releases.


There are two options for making a bug fix in a released debian package:

1. If there's a newer commit in our repo that fixes the reported bug 
(ideally but not necessarily a newer release in our stable release 
branch), we have the option to just make a new debian package from that 
newer release or commit.


2. We also have the option of treating the packaged buggy commit as a 
branch point for a bug-fix branch, fixing the bug in that branch, and 
releasing that as a new package.  We'd then "merge up" to get the bug 
fix commits into our appropriate "real" branches.  This technique is 
often used to fix bugs in the packaging itself (as opposed to bugs in 
the linuxcnc software), but it can also be used to patch bugs in the 
software.




Will Debian users be directed to the forum or github for issues?


Not automatically via any debian tooling; any pointers to our forum, 
irc, github, etc will have to come from our documentation, e.g.:








Will it end up we have a current buildbot released version, current Debian 
version and master version?


There are currently four ways to get pre-built debs of linuxcnc:

1. debian.org

2. buildbot

3. www.linuxcnc.org

4. github "artifacts"


# debian.org



The debian.org debs are the most user-accessible, in the sense that a 
user doesn't have to know anything about linuxcnc.org and doesn't have 
to edit their `/etc/apt/sources.list`, they can just `apt-get install 
linuxcnc-uspace`.  This has a couple of downsides, from LinuxCNC's 
perspective, as I see it:


* debian.org only packages for newer debian distros, currently 
unstable/sid/13 and testing/bookworm/12.  There is a possibility of 
using "debian backports" to get linuxcnc into stable/bullseye/11, but 
(as i understand it) nothing older than that is possible within the 
debian.org framework.  We'd have to roll our own to support e.g. 
buster/10.  (The LinuxCNC project has historically tried really hard to 
support old distros, on the theory that machine builders don't want to 
upgrade.  For example, 2.8 runs on Ubuntu 12.04, which is 10 years old. 
 This tendency of ours is both good and bad...)


* In the debian.org package archive, each distro is (pretty much) 
limited to one LinuxCNC deb: we cannot publish debs from multiple 
different LinuxCNC branches within a specific distro.  (There are ways 
around this, but they're not used much.)



# Buildbot



The buildbot debs are how we've been distributing our debs so far.  Some 
things to consider:


* We can easily publish debs for all our different branches, for 
whatever distros we choose to support.


* We have full control over the build environments, so we can support 
platforms that debian.org doesn't support, such as RTAI.


* Selfishly, it takes effort on my part to maintain the build farm, and 
i'm having a hard time finding time/energy for it.  For example, there 
is a bunch of work needed before the buildbot can support newer distros 
(bullseye and later).



# www.linuxcnc.org



This is/was the "official" way to get linuxcnc debs, for folks who 
didn't want the bleeding edge of buildbot debs.  These debs come from 
the buildbot, and share all the pros and cons of buildbot debs.



# Github artifacts



The github artifacts exist, but they're not super convenient in their 
current form...  Maybe this could be made better, but I haven't looked 
into it very much.



# Version Numbers

One important thing we need to talk about here is the version numbers 
used for debian packages.


The version numbers of the linuxcnc software are fully under our 
control, and ultimately come from release tags in our git repo such as 
"2.8.3" or "2.9.0~pre0".


However, because of an abundance of caution back in the way-back-when, 
our debian packages have historically carried an "epoch" number; that 
is, our debs have versions like "1:2.8.3", not "2.8.3".




This scheme was rejected by debian.org, and the epoch was deleted from 
the version numbers of the official debian.org packages.


I'm not sure how to deal with this.  We should 

Re: [Emc-developers] Debian package - what is the future?

2022-09-04 Thread Rod Webster
Personally, I think it makes sense that when V2.9 becomes the release
version (eg replacing V2.8), V2.9 is pushed to the Debian version and
master branch will need to be built from source. Only bug fixes to the
released version would then be sent to Debian until lcnc releases a new
version.

It would be really nice if the LCNC release schedule allowed the new
version to be included each debian release on debian release day.

Rod Webster
*1300 896 832*
+61 435 765 611
Vehicle Modifications Network
www.vehiclemods.net.au



On Sun, 4 Sept 2022 at 15:54, Chris Morley 
wrote:

> I see the action with Debian package.
> I hope that gets us some more exposure and more develops/users.
>
> I did wonder what that means for the project as far as maintaining
> versions.
> How are bug fixes addressed with Debian packages after (Debian) release?
>
> Will Debian users be directed to the forum or github for issues?
>
> Will it end up we have a current buildbot released version, current Debian
> version and master version?
>
> Will having Debian force us on a time schedule?
> What happens if we are not on time?
>
> ___
> 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