Re: [Emc-developers] LinuxCNC is in Debian!

[Steffen Möller]

On 01.03.22 10:59, Les Newell wrote:



So once you've bought the controller, there is no other restriction.


As far as I can tell from their docs, that is the case. It's a pretty
sound business model.


I assume that royalty is 2x per axis, once for each end of the cable.


From what I can tell, it would be one royalty per axis. Daisy chaining
is part of the hardware spec.



The industry pays such patent taxes to microsoft/google/... about
everywhere. I am relaxed about that since all we want to have is an open
source access to use these devices. Here an idea for the three lines,
now asking for membership as the operational action to allow us to
redistribute whatever Open Source drivers there are through whatever
channel. I am starting with an introduction since my two contacts did
not know who we are and it is somewhat polite :)

I started some text on
https://docs.google.com/document/d/1LFtgxDwE2tQRFjFGu_AAlBCuqBEoW6CaXoSWiaJrFkM/edit?usp=sharing
. Send me an email address that Google is allowed to see for direct
editing (only comments via the link). Here what I came up with so far:

*

Sehr geehrte Damen und Herren, [their office is in Germany, I prefer
this over Dear Madam/SIr or To whom this may concern, but direct me]

We contact you in the name of the LinuxCNC community to investigate how
we could integrate public EtherCAT drivers with our software
infrastructure. We are a 20+ years Open Source project to control CNC
machines that has found frequent adoptions also to control a diverse set
of robots up to 9 axes. LinuxCNC interprets G-code and some like to
program their hardware directly with it. Please find use cases and our
documentation on https://linuxcnc.org or YouTube.

Since Open Source, and with a nice hardware abstraction layer, LinuxCNC
is commonly used by enthusiasts with access to machines from the late
1900s to retrofit these with modern technology. And others take modern
parts home to explain their dayjob to their kids or to edutain
themselves as a hobby. That spirit prevails to bring LinuxCNC to
whatever is existing, and extend LinuxCNC when it encounters something new.

A few days ago, LinuxCNC became a regular package of Debian Linux and
will soon also be on Ubuntu. Works on Fedora (the free companion to
RedHat) are on their way. No hardware projects are performed within
LinuxCNC, but we would like to be complete when it comes to software
compatibility, just like you expect Linux to run everywhere. Upstream we
look at CAD/CAM, and downstream, it is the communication from the Linux
machine to the servos and steppers, that is you.

We understand that EtherCAT has a “GPL-2 if you OKed it and make us an
ETG-member”-license, which we do not understand and did not find more
information about. As a community, we decided not to preoccupy ourselves
with the legal details, we are all techies after all, if you could give
us such a membership-carte-blanche to create, modify and redistribute
EtherCAT drivers directly via our website and/or via Linux Distributions
(Fedora, Debian, OpenSuSE and its derivative distributions). All our
developments/modifications will be Open Source and once available via
regular Linux distributions this will lower the setup costs for your
existing and new members.

We have a technical coordinator of this effort with access to a series
of EtherCAT devices

and these developers who feel associated with the project

, … , 

who agreed that you may contact them. If there are other members in the
ETG with an interest in combining LinuxCNC with EtherCAT then we would
very much like to get in touch with them.

*

*Looking forward to a fruitful collaboration*

*Rod in the name of the LinuxCNC community
*

*
*

*My personal anchors to the community are Seb, Jeff and Andy. I suggest
that Rod sends whatever we come up with (if we come up with anything)
directly, but I would like to first have a positive vote by one of them
and "don't care"s or better from them and everyone else here on the list.*

*Best,
Steffen
*

*
*


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

Re: [Emc-developers] LinuxCNC is in Debian!

[Steffen Möller]

On 28.02.22 19:44, gene heskett wrote:

On Monday, February 28, 2022 12:53:21 PM EST Steffen Möller wrote:

On 28.02.22 18:40, gene heskett wrote:

On Monday, February 28, 2022 8:28:36 AM EST andy pugh wrote:

On Mon, 28 Feb 2022 at 13:22, Steffen Möller

wrote:

ie, "rtapi" is relevant to uspace and rt builds.

Can you guide me (or someone else surfacing) towards what would be
required to have LinuxCNC readily compatible with that external
EtherCAT package on Debian?

Personally I know nothing about EtherCAT. I have always been a
little
afraid of the licensing complexities mentioned here:

https://etherlab.org/en/ethercat/

Etherlab itself is GPLv2, but _using_ it seems to bring a different
licensing restriction into play. And I don't know enough about
licensing to know if that's a problem.

I followed this link, and couldn't find an obvious link to the
licensing docs. Am I going blind? Or are they acting like a
submarine, ala the compuserve debacle from about 25 years back?

It is in the "Notice" section below that copyright thingy:
The license above concerns the source code only. Using the EtherCAT
technology and brand is only permitted in compliance with the
industrial property and similar rights ofBeckhoff Automation GmbH
<http://beckhoff.com/>.

Best,
Steffen


Yes, I read that too, Steffen, but failed to find a statement describing
those rights.

They did not put anything there, I agree.

Thats precisely why I mentioned the GIF debacle. I'm a
genuine old fart, my history starts in late 1934, with a good memory
about such dishonest goings on. It took maybe 20 hours for gifs to
disappear from the net, totally and completely then, and maybe a week to
fine tune png and get the first version out the door. Where is compuserve
today? A footnote in history at best, but not remembered with loving
thoughts.  We invented the distastefull term "submarine patent" to
describe what happened.

I don't really want to be involved with an entity that references
additional rights, but doesn't make those readily available.

Maybe I didn't look hard enough but I did look with the idea of learning
what those additional rights might cost.


Nothing, so I was assured.

I propose we describe what we want to do and then they either agree and
make LinuxCNC.org a member or they don't.

Best,
Steffen



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


Cheers, Gene Heskett.



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

Re: [Emc-developers] LinuxCNC is in Debian!

[Steffen Möller]

On 28.02.22 18:40, gene heskett wrote:

On Monday, February 28, 2022 8:28:36 AM EST andy pugh wrote:

On Mon, 28 Feb 2022 at 13:22, Steffen Möller

wrote:

ie, "rtapi" is relevant to uspace and rt builds.

Can you guide me (or someone else surfacing) towards what would be
required to have LinuxCNC readily compatible with that external
EtherCAT package on Debian?

Personally I know nothing about EtherCAT. I have always been a little
afraid of the licensing complexities mentioned here:

https://etherlab.org/en/ethercat/

Etherlab itself is GPLv2, but _using_ it seems to bring a different
licensing restriction into play. And I don't know enough about
licensing to know if that's a problem.

I followed this link, and couldn't find an obvious link to the licensing
docs. Am I going blind? Or are they acting like a submarine, ala the
compuserve debacle from about 25 years back?

It is in the "Notice" section below that copyright thingy:
The license above concerns the source code only. Using the EtherCAT
technology and brand is only permitted in compliance with the industrial
property and similar rights ofBeckhoff Automation GmbH
<http://beckhoff.com/>.

Best,
Steffen


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

[Emc-developers] EtherCAT - would not be a prob with free membership in EtherCAT Technology Group Re: LinuxCNC is in Debian!

[Steffen Möller]

Hello again,

On 28.02.22 14:28, andy pugh wrote:

On Mon, 28 Feb 2022 at 13:22, Steffen Möller  wrote:

Personally I know nothing about EtherCAT. I have always been a little
afraid of the licensing complexities mentioned here:

https://etherlab.org/en/ethercat/

Etherlab itself is GPLv2, but _using_ it seems to bring a different
licensing restriction into play. And I don't know enough about
licensing to know if that's a problem.


I called them up - first the Beckhoff group (they have nice stuff on 
https://www.beckhoff.com/en-gb/) and from there I was pointed to the EtherCAT Technology 
Group (https://www.ethercat.org/de/contact.html), so I called them, too. Without that 
membership we would be in said uncharacterized unmitigated license trouble  that Andy 
referenced but with that membership they would be very sweet to us. From what I 
understand, they try to be good people and just in case someone messes something up they 
do not want to guess how to reach out. So we are asked to become a member of the EtherCAT 
Technology Group (ETG) - for which we would identify someone who would serve as a 
communicator between them and our community and write a "3-line email" with our 
request to integrate an EtherCAT driver that is available at some URL with LinuxCNC as 
described on https://linuxcnc.org.

I do not see that Debian would become a member of their Technology Group. And 
it would not make too much sense to me to have any extra outreach from Debian 
to that ETG, but we can ask for an OK to have that distribution channel and 
also ask for Fedora at the same time.

Now - big question: Is there an agreement that it would be beneficial for 
LinuxCNC to become a member of the ETG? It is free. And there likely a series 
of perks for training material that may not be of our immediate concern. They 
invited me to help with that initial contact but that LinuxCNC-representative 
to them could then be anyone we pick. Andy? Rod? You both? Jeff? All three of 
yours?

Best,
Steffen



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

Re: [Emc-developers] LinuxCNC is in Debian!

[Steffen Möller]

On 28.02.22 14:28, andy pugh wrote:

On Mon, 28 Feb 2022 at 13:22, Steffen Möller  wrote:


ie, "rtapi" is relevant to uspace and rt builds.

Can you guide me (or someone else surfacing) towards what would be
required to have LinuxCNC readily compatible with that external EtherCAT
package on Debian?

Personally I know nothing about EtherCAT. I have always been a little
afraid of the licensing complexities mentioned here:

https://etherlab.org/en/ethercat/

Etherlab itself is GPLv2, but _using_ it seems to bring a different
licensing restriction into play. And I don't know enough about
licensing to know if that's a problem.


Let me see if I can get some sort of contact to them. This sounds all a
bit weird. Wrt Debian all it asks is if it can build, modify and
redistribute the package, I am not worried about that part. But about
all the other parts, indeed.

Steffen



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

Re: [Emc-developers] LinuxCNC is in Debian!

[Steffen Möller]

On 28.02.22 13:44, andy pugh wrote:

On Mon, 28 Feb 2022 at 12:20, Steffen Möller  wrote:


+rtapi_timespec_advance(task->nextstart, task->nextstart,
task->period + task->pll_correction);

which patches LinuxCNC's src/rtapi/rtapi.h and I have no idea if we can
just ignore this for our uspace setup on Debian

It sounds like there may be some confusion, but it might be me
misunderstanding the question.

"rtapi" is a wrapper that abstracts the differences between rtai,
preempt-rt and xenomai.

ie, "rtapi" is relevant to uspace and rt builds.


Can you guide me (or someone else surfacing) towards what would be
required to have LinuxCNC readily compatible with that external EtherCAT
package on Debian?

Best,
Steffen



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

Re: [Emc-developers] LinuxCNC is in Debian!

[Steffen Möller]

Rod,

Thank you tons for these pointers. This is a nice examples for a) and b)
of my motivation coming togther.

I'd love to see EtherCAT properly hooked up with LinuxCNC (I actually
thought this was the case already) and I happily help to get there. The
problem: I am not competent to make any decisions and have no hardware
to test (which would be the easiest to fix). I would hence need someone
to direct me or preferably we find someone who wants to grow into
maintaining it and then that individual gets help from all sides.

To describe my difficulty, I looked at
https://github.com/sittner/linuxcnc-ethercat/blob/3a25fc9cd5a52cd51fefcd152c92b860a90b3a11/patches/add-task-pll-functions-2.8.patch#L125
:

+    rtapi_timespec_advance(task->nextstart, task->nextstart,
task->period + task->pll_correction);

which patches LinuxCNC's src/rtapi/rtapi.h and I have no idea if we can
just ignore this for our uspace setup on Debian or if this needs some
further discussion.

So, Petter or me as Debian-Developers (and we likely find more DDs
teaming up over time) happily help to get this all into Debian, but the
nitty-gritty is too difficult for either of us, I presume. So, maybe we
can come up with sort of "development plan" and match that against the
skills we have at our disposal?

Best,
Steffen


On 28.02.22 02:56, Rod Webster wrote:

Stefan,
One area that could reduce dependency on Mesa hardware would be to bring
Ethercat into the Debian repos. We mention it is being supported in our
shiny new repository entry but it's not and it's difficult to install on
newer distros.
There is an ethercat driver for linuxcnc here:
See:https://github.com/sittner/linuxcnc-ethercat

Previously, it was determined that this was not possible due to incorporate
this to possible licensing restrictions with Beckhoff but from what I can
see that license is for hardware devices only and the driver links to the
Etherlabmaster open source software library
See:https://etherlab.org/en/ethercat/
Perhaps with our greater understanding of licensing and the many licences
we have uncovered in Linuxcnc, perhaps this decision could be reviewed.

And you would also probably want to capture this component for managing
CIA402 servo devices
https://github.com/dbraun1981/hal-cia402

Recently one of the etherlab developers created an unofficial buildbot for
Debian debs here so the project may be fully complete if they came on board
https://build.opensuse.org/project/show/home:bone1:branches:science:EtherLab

Currently supporting Ethercat devices is far more difficult than it should
be.

This would be an awesome and worthy addition to the project if it were
possible.

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


On Mon, 28 Feb 2022 at 10:38, Steffen Möller  wrote:


I have asked this myself. Why did I want this to happen - and I think
the answer is two-fold:

a) community-forming - not necessarily I am after contributors to
LinuxCNC but I see the extra stimulus to package other CNC-related
software for Debian from which then LinuxCNC benefits

b) less stress to "keep everything together". There are several LiveCDs
that likely would just go and add LinuxCNC, such that there may not be
an ultimate need for LinuxCNC to maintain its own. LinuxCNC in my
understanding is a bit of a distribution in itself: It has amalgamated
several projects (ladder comes to mind) that have been developed
independently before. If this all works out nicely then LinuxCNC could
consider to present some of its internals as independent packages.

Something else I see is that LinuxCNC has the Mesa cards as closely tied
hardware. There could be more. I could imagine that have LinuxCNC
integrated with Debian (now) and Ubuntu (soon) will ease the internal
decision making for hardware companies that today only address Mach3 et
al..

We'll see :)

Best,
Steffen

On 28.02.22 01:01, Sam Sokolik wrote:

This is amazing...   This will make Linuxcnc even easier to access..

  Game

changer?  Maybe!

sam

On Sun, Feb 27, 2022 at 1:32 PM Nicklas SB Karlsson  wrote:


Metoo use debian. Great!

On Sun, 27 Feb 2022 11:36:37 -0700
Sebastian Kuzminsky  wrote:


On 2/27/22 04:00, Debian FTP Masters wrote:
   > Accepted:
   >

Format: 1.8
Date: Fri, 25 Feb 2022 18:40:12 +0100
Source: linuxcnc
Binary: linuxcnc-doc-en linuxcnc-doc-es linuxcnc-doc-fr

linuxcnc-doc-zh-cn linuxcnc-uspace linuxcnc-uspace-dbgsym
linuxcnc-uspace-dev

Architecture: source all amd64
Version: 2.9.0~pre0+git20220224.3ba0951743-1
Distribution: unstable

Yayyy!  Thank you Steffen, and Petter and everyone who's been working

on

getting LinuxCNC into Debian!

If you're running sid/unstable you can now just `apt-get install
linuxcnc-uspace`, right from the debian.org package archive:

   <https://packages.debian.org/linuxcnc-uspace>


It'll hopefully make it into bookworm/testing in a couple of days.
We'll work on bullse

Re: [Emc-developers] LinuxCNC is in Debian!

[Steffen Möller]

I have asked this myself. Why did I want this to happen - and I think
the answer is two-fold:

a) community-forming - not necessarily I am after contributors to
LinuxCNC but I see the extra stimulus to package other CNC-related
software for Debian from which then LinuxCNC benefits

b) less stress to "keep everything together". There are several LiveCDs
that likely would just go and add LinuxCNC, such that there may not be
an ultimate need for LinuxCNC to maintain its own. LinuxCNC in my
understanding is a bit of a distribution in itself: It has amalgamated
several projects (ladder comes to mind) that have been developed
independently before. If this all works out nicely then LinuxCNC could
consider to present some of its internals as independent packages.

Something else I see is that LinuxCNC has the Mesa cards as closely tied
hardware. There could be more. I could imagine that have LinuxCNC
integrated with Debian (now) and Ubuntu (soon) will ease the internal
decision making for hardware companies that today only address Mach3 et al..

We'll see :)

Best,
Steffen

On 28.02.22 01:01, Sam Sokolik wrote:

This is amazing...   This will make Linuxcnc even easier to access..   Game
changer?  Maybe!

sam

On Sun, Feb 27, 2022 at 1:32 PM Nicklas SB Karlsson  wrote:


Metoo use debian. Great!

On Sun, 27 Feb 2022 11:36:37 -0700
Sebastian Kuzminsky  wrote:


On 2/27/22 04:00, Debian FTP Masters wrote:
  > Accepted:
  >

Format: 1.8
Date: Fri, 25 Feb 2022 18:40:12 +0100
Source: linuxcnc
Binary: linuxcnc-doc-en linuxcnc-doc-es linuxcnc-doc-fr

linuxcnc-doc-zh-cn linuxcnc-uspace linuxcnc-uspace-dbgsym
linuxcnc-uspace-dev

Architecture: source all amd64
Version: 2.9.0~pre0+git20220224.3ba0951743-1
Distribution: unstable

Yayyy!  Thank you Steffen, and Petter and everyone who's been working on
getting LinuxCNC into Debian!

If you're running sid/unstable you can now just `apt-get install
linuxcnc-uspace`, right from the debian.org package archive:

  


It'll hopefully make it into bookworm/testing in a couple of days.
We'll work on bullseye after that.  :-)


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



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

Re: Question about building a deb package

[Steffen Möller]

On 25.02.22 07:32, Andrey Rahmatullin wrote:

On Fri, Feb 25, 2022 at 11:44:46AM +0800, Yunmei Li wrote:

I am new to building deb packages, and I would like some help with a
question.
I am trying to build a deb package for Milvus(https://milvus.io/) on
Ubuntu18.04 or Ubuntu 20.04. Building Milvus requires Cmake 3.18 or higher,
but the latest version of cmake is 3.16 on Ubuntu 20.04 (golang has the
same situation). Could I directly use the cmake binary when building my
package? Or is there any other solution?


As others have already replied, for your local packages you are
completely free to do just anything, really. However, if you want
others, the automated builders of the release in particular, to rebuild
your package then this is not helpful.

If you are stuck with these older versions of Ubuntu then you could
backport cmake 3.18 to these releases. How exactly this works in Ubuntu
I cannot tell. You may want to start here
https://help.ubuntu.com/community/UbuntuBackports

Best,
Steffen

Re: Google Summer of Code, Debian Science

[Steffen Möller]

You are aware of https://wiki.debian.org/DebianScience/ROOT ?

On 22.02.22 17:19, Stephan Lachnit wrote:

On Mon, Feb 21, 2022 at 5:43 PM Anton Gladky  wrote:

If somebody wants to be a co-mentor or if you have better ideas
for the project, please let me know.

I would love to have a student to bring up packaging of common HEP
packages (High Energy Physics), most notably ROOT [1] and Geant4 [2].
I've already done a bit ([3] resp. [4]), but I'm currently not working
actively on it anymore.

If anyone would be interested to co-mentor this, I would consider
mentoring this. However it's unlikely that I will do it alone as I'm
hopefully a Summer Student myself (not at GSoC).

Regards,
Stephan

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981113
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965964
[3] https://salsa.debian.org/science-team/root
[4] https://salsa.debian.org/science-team/geant4

Re: q2-emperor - flagged as "RFS"ed

[Steffen Möller]

On 17.02.22 22:01, Nilesh Patra wrote:

On 2022-02-18 01:34, Steffen Möller wrote:

Hello,

q2-emperor is flagged as "RFS" in
https://docs.google.com/spreadsheets/d/1tApLhVqxRZ2VOuMH_aPUgFENQJfbLlB_PFH_Ah_q7hM/edit#gid=1986383821
and late January, its dependency EMPEROR made it into the distribution.
I have not seen any rejection email in my inbox (and it should be
flagged as "new" then). May I ask for a peer review and upload?

Uploaded after some scrutiny. Thanks!

Great! Thank you!
Steffen

q2-emperor - flagged as "RFS"ed

[Steffen Möller]

Hello,

q2-emperor is flagged as "RFS" in
https://docs.google.com/spreadsheets/d/1tApLhVqxRZ2VOuMH_aPUgFENQJfbLlB_PFH_Ah_q7hM/edit#gid=1986383821
and late January, its dependency EMPEROR made it into the distribution.
I have not seen any rejection email in my inbox (and it should be
flagged as "new" then). May I ask for a peer review and upload?

Best,
Steffen

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

[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](https://hosted.weblate.org/projects/linuxcnc/linuxcnc/) /
[English](https://hosted.weblate.org/projects/linuxcnc/linuxcnc/en/)

## Source string

Stepconf

## Comment

<https://github.com/LinuxCNC/linuxcnc/pull/1601> This refers to the name of
the tool and should not be translated.

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

## Source string location

[src/emc/usr_intf/stepconf/stepconf.py:141](https://github.com/linuxcnc/linuxcnc/blob/master/src/emc/usr_intf/stepconf/stepconf.py#L141)

##  Translation Info

All strings 
   |  [ 3,757 
](https://hosted.weblate.org/translate/linuxcnc/linuxcnc/en/)   
   |  
---|--|
Translated strings  
   |  [ 3,757 
](https://hosted.weblate.org/translate/linuxcnc/linuxcnc/en/?q=state:>=translated)
 

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


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

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

Generated on Feb. 13, 2022, 1:43 a.m..

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

Re: RFS faber - build dependency for boost-python

[Steffen Möller]

Fantastic - thank you tons!
Steffen

On 11.02.22 11:44, Étienne Mollier wrote:

Hi Steffen,

Steffen Möller, on 2022-02-08:

https://salsa.debian.org/python-team/packages/faber

I had asked the Debian boost folks already to comment on that package
but have not heard back. Faber is a build tool that the upstream boost
community has elevated as the next thing for their Python interface. But
it can also be used as a substitute for make.

Anyway. Could someone please have a look that I have not borked to
smoothen the transition through NEW? Please feel free to upload.

Please kindly check the buildability of the package using a
clean chroot (automating this with pbuilder or sbuild, or
anything doing similar job at your preference.  :)  I had to
append python3-yaml  to the build dependencies to go
through the build and test process.

There were some Lintian issues afterwards, which you might want
to address:

W: faber: useless-whatis-entry usr/share/man/man1/faber.1.gz
I: faber source: debian-watch-contains-dh_make-template  [debian/watch]
I: faber: spelling-error-in-description platoform platform
I: python3-faber: spelling-error-in-description platoform platform

(With help2man, you can set the whatis entry with --name flag.)

You will have to document as well the following files in
d/copyright, as otherwise the package would probably get
rejected from NEW:
   - doc/_static/boost.css
   - src/faber/termcolor.py
   - src/faber_bench/images/stop.svg (looks CC0/public domain,
 but I am unsure)
Maybe I missed other files, so don't hesitate to do one more
review on your end.

I don't have access to the Debian Python team repository, so I
haven't pushed nor uploaded anything.

In hope this helps,

Re: [Emc-developers] How to contribute?

[Steffen Möller]

Hi Andy,

On 10.02.22 22:49, Andy Howell wrote:


On 2/10/22 06:10, Steffen Möller wrote:


On 10.02.22 07:28, Phill Carter wrote:



On 10 Feb 2022, at 4:14 pm, Andy Howell  wrote:


On 2/9/22 14:46, andy pugh wrote:

On Wed, 9 Feb 2022 at 20:21, Andy Howell  wrote:


My background is in c/c++ development under UNIX/Linux. I know
bit of
python. I don't have the experience to work on the low level
internals.

How about this one?
https://github.com/LinuxCNC/linuxcnc/issues/1438

A text search on the pin name would find the right part of the code,
and would let you find where the associated internal variable is
updated.

(This is internals, but with code to copy from)

Thanks. That sounds like a good problem to start with. I will have
a look at the code and comment under the issue.

I do have a PR ready to submit but I am happy to hold off.

That sounds so nice and so wrong at the same time. I suggest to submit
the PR and you have already found a reviewer.

@Andy, I am currently on a mission to render the C/C++ sources
cppcheck-clean. You see a few PRs on this already - and one issue that I
could not solve with a quick patch that I think is a bug. I personally
use this to get acquainted with the code base a bit more - have started
with src/hal/* and src/emc/* and have just about completed that, I
think. But there is more.

Many thanks and greetings
Steffen


Steffen,

I could certainly work on that. I just compiled LinuxCNC for the first
time in a very long time. There were lots of compiler warnings,
particularly around strncpy and snprintf. I think those would be worth
looking into. It would be nice to fix the code to remove the warnings,
or turn warnings off where needed when they are clearly a false
positive. For example,

hal/user_comps/mb2hal/mb2hal_init.c:187:55: warning: ‘%02d’ directive
output may be truncated writing between 2 and 10 bytes into a region
of size 7 [-Wformat-truncation=]
  187 | snprintf(section, sizeof(section)-1, "TRANSACTION_%02d",
mb_tx_num);
  |   ^~~~
hal/user_comps/mb2hal/mb2hal_init.c:187:42: note: directive argument
in the range [0, 2147483647]
  187 | snprintf(section, sizeof(section)-1, "TRANSACTION_%02d",
mb_tx_num);
  | ^~

The local 'section' buffer there is 20 bytes. Although it might never
be an issue in practice, increasing the buffer size will make sure it
never is and remove the warning. Maybe we can get to a point where we
can treat warnings as errors.

Does that sound worth pursuing?


Very much so, in my humble opinion. Many thanks!

Steffen





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

Re: [Emc-developers] linuxcnc_2.9.0~pre0-1+git20211120.a2b87d299-1_amd64.changes REJECTED

[Steffen Möller]

On 10.02.22 22:12, Sebastian Kuzminsky wrote:

On 2/10/22 09:06, Steffen Möller wrote:


On 10.02.22 17:00, Thorsten Alteholz wrote:

This version does not appear in latest changelog anymore ...


Thorsten just rejected the first of two submissions, the second was a
smallish correction that indeed is agnostic about the version from the
day before.


Is the only objection that the version doesn't appear in the
changelog?  Or did I miss some email explaining further?


On https://ftp-master.debian.org/new.html we have the second upload
still queued.

The only explanation I have is that Thorsten started to look at it and
just fell back to some easy cleaning up after seeing that enormous
debian/copyright page.

Best,
Steffen






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

Re: [Emc-developers] linuxcnc_2.9.0~pre0-1+git20211120.a2b87d299-1_amd64.changes REJECTED

[Steffen Möller]

On 10.02.22 17:00, Thorsten Alteholz wrote:

This version does not appear in latest changelog anymore ...


Thorsten just rejected the first of two submissions, the second was a
smallish correction that indeed is agnostic about the version from the
day before.

Best,
Steffen



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

Re: [Emc-developers] How to contribute?

[Steffen Möller]

There should be a section on man pages, I tend to agree. My concern is
that while we are typing there is Petter active on getting weblate
(https://hosted.weblate.org/projects/linuxcnc/linuxcnc/) to also
function with the documentation. I lost touch a bit,
https://github.com/LinuxCNC/linuxcnc/pull/1356 is where I understand we
are. Please talk back to Petter on anything man/doc-associated to
minimize the confusion.

Best,
Steffen

On 10.02.22 14:27, Hans Unzner wrote:

Hi Andy,

if you want to work on the docs I have a suggestion. You could
integrate the PDf-version of the manual pages
(http://linuxcnc.org/docs/devel/pdf/LinuxCNC_Manual_Pages.pdf) into
the main documentation PDF.
Sub-tasks would be adapting the links to the man pages (like in the
current HTML docs) and creating table of content entries for the HAL
components.

But I don't know if I am the only one who think this is useful.
@others: please comment ;-)

/Hans

Am 09.02.22 um 21:18 schrieb Andy Howell:

Hello,

I've been using LinuxCNC more lately, working with our high school
robotics program's CNC routers.

Are there small tasks I could take on regarding development?

My background is in c/c++ development under UNIX/Linux. I know bit of
python. I don't have the experience to work on the low level
internals. I'll looking for things on the edges. I don't mind a bit
of grunt work. Happy to work on documentation, minor GUI tweaks,
testing etc. Maybe proof reading the docs? That would have the bonus
of learning LinuxCNC better.

Can someone point me in the right direction?

Thanks,

Andy





___
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] How to contribute?

[Steffen Möller]

On 10.02.22 07:28, Phill Carter wrote:



On 10 Feb 2022, at 4:14 pm, Andy Howell  wrote:


On 2/9/22 14:46, andy pugh wrote:

On Wed, 9 Feb 2022 at 20:21, Andy Howell  wrote:


My background is in c/c++ development under UNIX/Linux. I know bit of
python. I don't have the experience to work on the low level internals.

How about this one?
https://github.com/LinuxCNC/linuxcnc/issues/1438

A text search on the pin name would find the right part of the code,
and would let you find where the associated internal variable is
updated.

(This is internals, but with code to copy from)

Thanks. That sounds like a good problem to start with. I will have a look at 
the code and comment under the issue.

I do have a PR ready to submit but I am happy to hold off.

That sounds so nice and so wrong at the same time. I suggest to submit
the PR and you have already found a reviewer.

@Andy, I am currently on a mission to render the C/C++ sources
cppcheck-clean. You see a few PRs on this already - and one issue that I
could not solve with a quick patch that I think is a bug. I personally
use this to get acquainted with the code base a bit more - have started
with src/hal/* and src/emc/* and have just about completed that, I
think. But there is more.

Many thanks and greetings
Steffen




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

RFS faber - build dependency for boost-python

[Steffen Möller]

Hello,

This is about

https://salsa.debian.org/python-team/packages/faber

I had asked the Debian boost folks already to comment on that package
but have not heard back. Faber is a build tool that the upstream boost
community has elevated as the next thing for their Python interface. But
it can also be used as a substitute for make.

Anyway. Could someone please have a look that I have not borked to
smoothen the transition through NEW? Please feel free to upload.

Many thanks!

Best,
Steffen

Re: [Emc-developers] Need help with sourcecode-highlighting in .adoc and xsltproc parse error

[Steffen Möller]

I somehow first needed to craft this call for help and then found it:
The file needs a section header and a blank line prior to the :ini:
setting, the following file is fine:

$ cat ../testme.adoc
= sectionname

:ini: {basebackend@docbook:'':ini}

[source,{ini}]
Bla

$ asciidoc -f docs/src/attribute-colon.conf -a "scriptdir=docs/src/" -d
book -o- -b docbook ../testme.adoc

http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd;>





   sectionname



Bla


moeller@


On 07.02.22 17:31, Steffen Möller wrote:

Dear all,

I am lost. And since git-bisect is not an eye-opener for me, maybe
someone on the list can help.

I created this minimalistic file - removing any single line makes the
problem go away.

```
:ini: {basebackend@docbook:'':ini}
[source,{ini}]
the source code goes here - likely as a --- --- block

```

The build process takes this as

asciidoc -f docs/src/attribute-colon.conf -a "scriptdir=docs/src/" -d
book -o- -b docbook ../testme.adoc | xsltproc docs/src/links.x
slt - > /tmp/testme.tmp

and gives this error

-:10: parser error : Opening and ending tag mismatch: book line 6 and
programlisting
Bla
   ^
-:11: parser error : Extra content at the end of the document

^

which is darn correct, the file generated by asciidoc is


http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd;>





   2022-02-07

Bla


And - what can I tell - I cannot find why  is omitted. I
presume it is a file that is generated somewhere somehow that is not
regenerated when I bisect.

My setup is on the branch
https://github.com/smoe/linuxcnc/tree/changes_on_English_for_weblate
that is behind pull request
https://github.com/LinuxCNC/linuxcnc/pull/1516 . The Debian package
builds and tests successfully, I can reproduce the error locally with
"make -C src docs".

Many thanks for your pointers.

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] Need help with sourcecode-highlighting in .adoc and xsltproc parse error

[Steffen Möller]

Dear all,

I am lost. And since git-bisect is not an eye-opener for me, maybe
someone on the list can help.

I created this minimalistic file - removing any single line makes the
problem go away.

```
:ini: {basebackend@docbook:'':ini}
[source,{ini}]
the source code goes here - likely as a --- --- block

```

The build process takes this as

asciidoc -f docs/src/attribute-colon.conf -a "scriptdir=docs/src/" -d
book -o- -b docbook ../testme.adoc | xsltproc docs/src/links.x
slt - > /tmp/testme.tmp

and gives this error

-:10: parser error : Opening and ending tag mismatch: book line 6 and
programlisting
Bla
   ^
-:11: parser error : Extra content at the end of the document

^

which is darn correct, the file generated by asciidoc is


http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd;>





   2022-02-07

Bla


And - what can I tell - I cannot find why  is omitted. I
presume it is a file that is generated somewhere somehow that is not
regenerated when I bisect.

My setup is on the branch
https://github.com/smoe/linuxcnc/tree/changes_on_English_for_weblate
that is behind pull request
https://github.com/LinuxCNC/linuxcnc/pull/1516 . The Debian package
builds and tests successfully, I can reproduce the error locally with
"make -C src docs".

Many thanks for your pointers.

Steffen


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

does anyone know of its whereabouts? Fwd: r-bioc-progeny_1.14.0+ds-1_amd64.changes REJECTED

[Steffen Möller]

Hello,

I just checked

but could not find any info on r-bioc-progeny. Andreas has fixed the
missing license info for

https://afeld.github.io/bootstrap-toc/

(which looks good btw) . @Andreas do you happen to recall if you have
uploaded this again? Or was this rejected with a request to provide a
package for bootstrap-toc? The package would also work without it, so I
may presume, and I would then vote for a simplification.

Many thanks and regards
Steffen



 Forwarded Message 
Subject:r-bioc-progeny_1.14.0+ds-1_amd64.changes REJECTED
Date:   Tue, 23 Nov 2021 19:00:08 +
From:   Thorsten Alteholz 
To: Debian R Packages Maintainers ,
Steffen Moeller 




Hi Steffen,

please mention the license of bootstrap in your debian/copyright.

Thanks!
Thorsten



===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.

Re: [Emc-developers] thinking about the next LinuxCNC release

[Steffen Möller]

I can help backporting to buster if that is helping with development.

On 06.02.22 15:43, Nicklas SB Karlsson wrote:

gtk3 is in the master-gtk3 branch and seems well on it's way. Need to
upgrade to latest debian bullseye to get it to work if running Debian.

Den 2022-02-06 kl. 13:55, skrev Steffen Möller:

Heya,

On 06.02.22 11:43, Jérémie Tarot wrote:

Le mer. 2 févr. 2022 à 19:18, Sebastian Kuzminsky  a
écrit :


What are the big projects that need to get finished for the next
release?  Some things I know vaguely about, but don't know the
status of:
...

* Transition docs translations to po4a (optional but highly desired)

What is the status of those projects?


French docs migration has finally been done

But have all the changes to the English files been merged, yet? Is there
a PR of yours against master out? I have mine on
https://github.com/LinuxCNC/linuxcnc/pull/1516 but somehow managed to
wreck it, did not find the problem, yet. I would hence be very happy for
your changes to go in first.

so @pere should now be able to
carry on with docs build to produce the first version of the
auto-generated
translations...


I also want to see this, admittedly. Where I see part of the problem is
with all the updates we have done to the English texts in the mean time,
not knowing how good po4a/weblate is to get this synced up. Without that
sync, I guess the corresponding .po element is lost - if not with the
first weblate pull request then with the second. But then again, if this
is problematic now, then this is problematic with every future change
when someone changes

*something
like this

to

* something
  like that

We can just hope for the best, I tend to think and should go ahead. What
then happens - happens and I presume we can either live with it and
improve po4a over time or fall back to how everything is now. Most
important are French's (in the sense of
https://www.youtube.com/watch?v=38Wmi6-u7Mk) backports to English so all
content is preserved.


Meanwhile @smoe and I are looking at docs writing guidelines and style
guide, as well as designing upgraded docs pages templates/skeletons.
Once
perfected, and auto-generation working, we'll review and upgrade all
english docs pages, as well as translate and add the good chunks pulled
from the french version.
Hopefully, 2.9 could be released with an upgraded docs system (po4a,
weblate and adoc templates), and auto generated spanish and french
translations.


That would be darn cool, in my mind 2.9 would be more like a technical
experiment, still. For instance we have yet no clue about how many
contributors would find their way to LinuxCNC if the 2.9 release
promotes this weblate initiative. I would want to stress in the release
notes that free localized documentation may be as important as the
software itself because of the many concepts and problem-awareness it
transports.

I should PM @pere about it all who is not subscribed to this list.


This would pave the road to 3.0 for updated and extended support
contents...


I think it would be very nice to have a list of features that we aim to
achieve for the 3.0 version. Personally, I kind of expect a 2.10,
still :)

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] thinking about the next LinuxCNC release

[Steffen Möller]

Heya,

On 06.02.22 11:43, Jérémie Tarot wrote:

Le mer. 2 févr. 2022 à 19:18, Sebastian Kuzminsky  a
écrit :


What are the big projects that need to get finished for the next
release?  Some things I know vaguely about, but don't know the status of:
...

* Transition docs translations to po4a (optional but highly desired)

What is the status of those projects?


French docs migration has finally been done

But have all the changes to the English files been merged, yet? Is there
a PR of yours against master out? I have mine on
https://github.com/LinuxCNC/linuxcnc/pull/1516 but somehow managed to
wreck it, did not find the problem, yet. I would hence be very happy for
your changes to go in first.

so @pere should now be able to
carry on with docs build to produce the first version of the auto-generated
translations...


I also want to see this, admittedly. Where I see part of the problem is
with all the updates we have done to the English texts in the mean time,
not knowing how good po4a/weblate is to get this synced up. Without that
sync, I guess the corresponding .po element is lost - if not with the
first weblate pull request then with the second. But then again, if this
is problematic now, then this is problematic with every future change
when someone changes

*something
like this

to

* something
  like that

We can just hope for the best, I tend to think and should go ahead. What
then happens - happens and I presume we can either live with it and
improve po4a over time or fall back to how everything is now. Most
important are French's (in the sense of
https://www.youtube.com/watch?v=38Wmi6-u7Mk) backports to English so all
content is preserved.


Meanwhile @smoe and I are looking at docs writing guidelines and style
guide, as well as designing upgraded docs pages templates/skeletons. Once
perfected, and auto-generation working, we'll review and upgrade all
english docs pages, as well as translate and add the good chunks pulled
from the french version.
Hopefully, 2.9 could be released with an upgraded docs system (po4a,
weblate and adoc templates), and auto generated spanish and french
translations.


That would be darn cool, in my mind 2.9 would be more like a technical
experiment, still. For instance we have yet no clue about how many
contributors would find their way to LinuxCNC if the 2.9 release
promotes this weblate initiative. I would want to stress in the release
notes that free localized documentation may be as important as the
software itself because of the many concepts and problem-awareness it
transports.

I should PM @pere about it all who is not subscribed to this list.


This would pave the road to 3.0 for updated and extended support contents...


I think it would be very nice to have a list of features that we aim to
achieve for the 3.0 version. Personally, I kind of expect a 2.10, still :)

Steffen



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

[Emc-developers] LinuxCNC Participation in Google Summer of Code 2022?

[Steffen Möller]

Hello,

There may be are a couple of developments in the LinuxCNC source tree
that would benefit from having a trainee work on full-time for a couple
of weeks. A quick web search found that LinuxCNC was adopted by BRL-CAD
for previous GSoCs but have not heard about 2021 - is anything happening
this year? BRL-CAD and/or LinuxCNC would need to apply until the 21st
this month.

I have no idea if LinuxCNC has a sufficient number of projects to run
independently. To mind come:

 * introducing crowd-translations of our documentation (we are doing
this now, but it is how I got this idea)
 * Connect LinuxCNC with CAN-FD interface of Duet3 extension board that
already has 32V/6A stepper drivers (this is what I planned to address
over the summer but it does not need to be me)
 * bringing po4a (weblate) to HAL (just a thought, no idea if that is
desirable)
 * bringing po4a (weblate) to graphics
 * help transitioning Gtk2 to Gtk3/4 (that is too late for the next
release, but maybe this triggers an idea with someone)
 * clarify interface with Robot Operating System
 * show what LinuxCNC can do to one of those low-cost mills from China
 * improve integration with CAM within FreeCAD (I am just making this
up, cannot mentor this)
 * backport something from Machine-Kit
 * ...?

I have mentored myself in 2010 last time, so I am a bit rusty. Also, too
new with everything here, I should not have any official position in the
GSoC administration if LinuxCNC decides to apply, but I happily help
where I can.

Best,
Steffen



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

[Emc-developers] I also see a LinuxCNC Python problem on bullseye Re: latency-test period - (return) problem

[Steffen Möller]

Hi Gene,

I just ran into the problem below which I expect to be at the root of
what then kills it further down. I'll investigate this a bit more and
then create a github issue or a pull request ... or both :)

Steffen

"~/Github/linuxcnc$ linuxcnc
LINUXCNC - 2.9.0~pre0
Machine configuration directory is
'/home/moeller/linuxcnc/configs/sim.axis'
Machine configuration file is 'axis_mm.ini'
Starting LinuxCNC...
Found file(lib): /usr/share/linuxcnc/hallib/core_sim.hal
Note: Using POSIX non-realtime
Found file(lib): /usr/share/linuxcnc/hallib/sim_spindle_encoder.hal
Found file(lib): /usr/share/linuxcnc/hallib/axis_manualtoolchange.hal
Found file(lib): /usr/share/linuxcnc/hallib/simulated_home.hal
PYTHON: exception during 'this' export:
TypeError: 'Boost.Python.class' object is not iterable


The above exception was the direct cause of the following exception:


Traceback (most recent call last):

 File "", line 1007, in _find_and_load

 File "", line 986, in
_find_and_load_unlocked

 File "", line 666, in _load_unlocked

 File "", line 565, in module_from_spec

 File "", line 763, in create_module

SystemError: _PyEval_EvalFrameDefault returned a result with an error set
"

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

Re: [Emc-developers] latency-test period - (return) problem

[Steffen Möller]

On 01.02.22 01:57, gene heskett wrote:

On Monday, January 31, 2022 12:45:27 PM EST Steffen Möller wrote:

On 31.01.22 18:28, gene heskett wrote:

On Monday, January 31, 2022 6:14:42 AM EST Steffen Möller wrote:

latency-test 100 500

And it works!

This is great to hear! Thank you! This is 32bits now, right?

On the pi, yes, I think the wintel machines are too. The kernels they are
running are VERY long in the tooth, from 3.something I think.


Where are
you at?


[the latency I had meant]


Now that I have the proper syntax, the rpi4b latency's for this kernel
are amazing:
Linux rpi4.coyote.den 4.19.71-rt24-v7l+ #1 SMP PREEMPT RT Thu Feb 6
07:09:18 EST 2020 armv7l GNU/Linux, I built just shy of 2 years ago, its
reporting under 5 u-secs max jitter for both threads, and its pretty
stable.  And my lathe is moving very smoothly with the new 3 phase
stepper servo's. I have not rebooted it back to bullseye to see if the
v5.16.2-rt19 I built last week is any better.


Save the effort. Let someone else try to beat your 5µs. This looks good,
indeed.

What would be important is that you keep these 5µs when saving something
to the disk etc. or when there is a touch on the touch screen etc. But I
am already sold, will get a Pi again.

Best,
Steffen



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

Re: [Emc-developers] latency-test period - (return) problem

[Steffen Möller]

On 31.01.22 18:28, gene heskett wrote:

On Monday, January 31, 2022 6:14:42 AM EST Steffen Möller wrote:

latency-test 100 500

And it works!

This is great to hear! Thank you! This is 32bits now, right? Where are
you at? Maybe Rod can compare with his 64bit findings.

The man page sorta needs help.


Both the man page and the tool have problems. Found the man page here
https://github.com/LinuxCNC/linuxcnc/blob/master/docs/man/man1/latency-test.1
and yes, it is a bit minimalistic :)  I think the way to go is to fix
the argument parsing when units are added, improve the --help and then
auto-generate the man page from that output.

Sidenote - if you (or anyone else reading this) happen(s) to have the
leisure to contribute bits and pieces to the documentation then by all
means - please just make your pick in
https://github.com/LinuxCNC/linuxcnc/tree/master/docs/src. There is an
effort under way to crowdsource the translation to other human languages
on wetblate (https://hosted.weblate.org/projects/linuxcnc - so far only
the tools are covered, but documentation should arrive soon, too) which
ist motivated mostly from the idea to have all languages synced as good
as possible to the English original and give the English all the
best-possible freedom to evolve without the burden to keep other
languages updated. I happily help with technical bits on gitlab.

Best,
Steffen




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

Re: [Emc-developers] latency-test period - (return) problem

[Steffen Möller]

Dear Gene,

I just tried this locally and it seems like the number conversion is
broken in latency-test. Also there should not be a prefix like
base-period in the command line. First thought it was just the capital
"S" but it wasn't.  Good news: you don't need them, please try again with

latency-test 100 500

which are your times in nanoseconds.

latency-test will open an X window to show these values. No idea why,
really, wish it would not.

Best,
Steffen

$ latency-test --help

Usage:
  latency-test [base-period [servo-period]]
  or:
  latency-test period -  # for single thread
  or:
  latency-test -h | --help   # (this text)

Defaults: base-period=25000nS servo-period=100nS
Equivalently: base-period=25µs servo-period=1ms

Times may be specified with suffix "s", "ms", "us" "µs", or "ns"
Times without a suffix and less than 1000 are taken to be in us;
other times without a suffix are taken to be in ns


On 31.01.22 11:35, gene heskett wrote:

Greetings all;

both my build (on buster armhf) and the buildbot version of 2.9-pre are
failing: terminal output from my build:
===
pi@rpi4:/media/pi/workspace $ latency-test period -
/usr/bin/latency-test: line 26: [: period: integer expression expected
Note: Using POSIX realtime
HAL: ERROR: thread 'slow' not found
lat.hal:3: addf failed
Note: Using POSIX realtime
===
terminal output of buildbot version:
===
pi@rpi4:/media/pi/workspace $ latency-test period -
/usr/bin/latency-test: line 26: [: period: integer expression expected
Note: Using POSIX realtime
HAL: ERROR: thread 'slow' not found
lat.hal:3: addf failed
Note: Using POSIX realtime
===

It has been this way for a bit.

Because on my pi, I have two threads, a 1ms thread for the linuxcnc
control stuff, and a 200 hz, 5 millisecond for the hand controls, it
would be informative if the period syntax also included the ability to
trace/measure this slower thread too but that implied syntax also fails
=
pi@rpi4:/media/pi/workspace $ latency-test base-period=1mS servo-
period=5mS
/usr/bin/latency-test: line 26: [: base-period=1mS: integer expression
expected
awk: cmd. line:1: BEGIN { printf "%.0f\n", (base-period=1mS); }
awk: cmd. line:1:  ^ syntax error
awk: cmd. line:1: BEGIN { printf "%.0f\n", (base-period=1mS); }
awk: cmd. line:1:   ^ syntax
error
/usr/bin/latency-test: line 26: [: servo-period=5mS: integer expression
expected
awk: cmd. line:1: BEGIN { printf "%.0f\n", (servo-period=5mS); }
awk: cmd. line:1:   ^ syntax error
awk: cmd. line:1: BEGIN { printf "%.0f\n", (servo-period=5mS); }
awk: cmd. line:1:^ syntax
error
/usr/bin/latency-test: line 72: [: : integer expression expected
/usr/bin/latency-test: line 73: [: : integer expression expected
/usr/bin/latency-test: line 31: [: : integer expression expected
/usr/bin/latency-test: line 32: [: : integer expression expected
/usr/bin/latency-test: line 33: [: : integer expression expected
/usr/bin/latency-test: line 34: [: : integer expression expected
/usr/bin/latency-test: line 31: [: : integer expression expected
/usr/bin/latency-test: line 32: [: : integer expression expected
/usr/bin/latency-test: line 33: [: : integer expression expected
/usr/bin/latency-test: line 34: [: : integer expression expected
/usr/bin/latency-test: line 77: [: -eq: unary operator expected
Note: Using POSIX realtime
HAL: ERROR: thread 'fast' not found
lat.hal:3: addf failed
Note: Using POSIX realtime
=

The --help shows both upper and lowercase s's being used but both work as
above.

The wintel versions also exit with exactly the same msg.

Thanks all.

Cheers, Gene Heskett.


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

Re: [Emc-developers] @Seb, can we please have an RPi bullseye buildbot? Re: signed arm64 bullseye (armbian) binaries for download Re: trying to install linuxcnc built on buster on a bullseye system

[Steffen Möller]

On 30.01.22 02:53, Rod Webster wrote:

I'll just chip in here.
Today I successfully installed Steffan's .deb on a Pi4 under Debian 11.2.
Latency-test does not appear to support running from the root user

I admit to be a bit rosty on the RPi, but there was this regular user
"pi" that I recall not to have root privileges but needed sudo.

and I
have not had time to add a user yet.

Good news, thanks!

Steps were:
1 download Debian 11.2 image
2. Burn to SD card using raspberry imager.
3. Install xfce operating system using startsel command, reboot into a
graphical environment
4. Open Synaptic, search for linux-image and install PREEMPT_RT (does
Steffans's Deb install that too?)

Only the LinuxCNC tools+libraries are part of that package and there are
no such dependencies set for it. From what I
understoo^H^H^H^H^H^H^H^H^Hpicked up somewhere, this "uspace" LinuxCNC
would technically also run with a regular kernel, just that the
latencies will be worse.

5. Install gdebi and installed the debs with it.

Regarding booting from USB, it appears adding
program_usb_boot_mode=1
to /boot/firmware/config.txt solves that. (note this file location may be
different than on a standard pi OS).
I might add I am powering this device using a PoE hat so it would be pretty
easy to hide a buildbot in a rack.
I don't have a USB enclosure or I'd try the USB approach.

I have a second pi here so I will try on that too. Let me know if
preempt_rt is included in the deb. Old habits die hard


You are referring to the kernel, right? This you need to install
independently and reboot, like you described in your point 4 above. I am
not sure about the features gdebi offers, but on the command line you
can inspect the contents of a .deb with "dpkg -c". I just did

dpkg -c linuxcnc-uspace_2.9.0~pre0_arm64.deb | grep -i preemp

and this showed no such file, so, I still hope nothing was omitted and
you indeed refer to the kernel.

Many thanks and greetings!

Steffen



On Sun, 30 Jan 2022 at 08:01, Steffen Möller  wrote:


On 29.01.22 22:08, Sebastian Kuzminsky wrote:

On 1/29/22 10:44 AM, Steffen Möller wrote:

32 or 64 bits, well, I think we want to see packages for both. Let's
wait for what Sebastian replies. I just saw on his page
http://buildbot.linuxcnc.org/buildslave-admin-guide.html that there are
buildbot difficulties with newer version that ship with bullseye and up.

The difficulty is that I haven't gotten around to upgrading the
buildmaster - that's the limiting factor.  I've quietly done some
tests and it seems that a new (bullseye/bookworm) buildbot master will
happily talk to ancient (precise/wheezy) buildbot workers, so i think
that particular hurtle isn't a blocker (unless there's something I
missed, which is totally possible).

The issue with ARM builds is mostly in how annoying ARM hardware is,
still.  The first ARM build "cluster" I made for the buildbot was a
couple of Odroid U2's, running Debian (with the Odroid custom kernel)
off micro SD cards.  They kept overheating and corrupting their SD
cards, not fun to maintain.

For 64bit bullseye I happily offer that "almost Debian" Armbian machine.
It has only a USB stick next to some internal MMC(?) but so far is
stable. That machine was a present from N30dG and I am confident that
would be a much appreciated use of the device.


The current ARM presence in the buildbot is a single Raspberry Pi 4
running Raspbian off a Micro SD card, doing the builds and pbuilder on
an old spinning-metal hard drive via a USB-to-SATA enclosure.  It's
been rock solid, but it's very much not a "data center" quality setup.

I've heard maybe with recent firmware the Pi4 can boot off a
USB-connected hard drive?  So maybe the SD card isn't needed for a
modern build?

So one option is to buy a stack of Pi4's, USB-to-SATA enclosures (and
maybe SD cards if that's still needed to boot from), and hard disks.
One for each platform we want to run RIP tests on.  Each one costs
maybe $100-$150.  (Once the Pi 4 becomes available again...)

Are there any good alternatives for building ARM clusters these days?
All our x86/amd64 builds are done in VMs, on big amd64 servers, and
that works really well.  Something similar for arm/adm64 would be ideal.

For 32bit, I agree that this should be solved via virtualization. If
there are no volunteers then I can also look into that. But this would
not be as immediate as the already available bullseye 64bit one.

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

Re: [Emc-developers] @Seb, can we please have an RPi bullseye buildbot? Re: signed arm64 bullseye (armbian) binaries for download Re: trying to install linuxcnc built on buster on a bullseye system

[Steffen Möller]

On 29.01.22 22:08, Sebastian Kuzminsky wrote:

On 1/29/22 10:44 AM, Steffen Möller wrote:

32 or 64 bits, well, I think we want to see packages for both. Let's
wait for what Sebastian replies. I just saw on his page
http://buildbot.linuxcnc.org/buildslave-admin-guide.html that there are
buildbot difficulties with newer version that ship with bullseye and up.


The difficulty is that I haven't gotten around to upgrading the
buildmaster - that's the limiting factor.  I've quietly done some
tests and it seems that a new (bullseye/bookworm) buildbot master will
happily talk to ancient (precise/wheezy) buildbot workers, so i think
that particular hurtle isn't a blocker (unless there's something I
missed, which is totally possible).

The issue with ARM builds is mostly in how annoying ARM hardware is,
still.  The first ARM build "cluster" I made for the buildbot was a
couple of Odroid U2's, running Debian (with the Odroid custom kernel)
off micro SD cards.  They kept overheating and corrupting their SD
cards, not fun to maintain.


For 64bit bullseye I happily offer that "almost Debian" Armbian machine.
It has only a USB stick next to some internal MMC(?) but so far is
stable. That machine was a present from N30dG and I am confident that
would be a much appreciated use of the device.


The current ARM presence in the buildbot is a single Raspberry Pi 4
running Raspbian off a Micro SD card, doing the builds and pbuilder on
an old spinning-metal hard drive via a USB-to-SATA enclosure.  It's
been rock solid, but it's very much not a "data center" quality setup.

I've heard maybe with recent firmware the Pi4 can boot off a
USB-connected hard drive?  So maybe the SD card isn't needed for a
modern build?

So one option is to buy a stack of Pi4's, USB-to-SATA enclosures (and
maybe SD cards if that's still needed to boot from), and hard disks.
One for each platform we want to run RIP tests on.  Each one costs
maybe $100-$150.  (Once the Pi 4 becomes available again...)

Are there any good alternatives for building ARM clusters these days?
All our x86/amd64 builds are done in VMs, on big amd64 servers, and
that works really well.  Something similar for arm/adm64 would be ideal.


For 32bit, I agree that this should be solved via virtualization. If
there are no volunteers then I can also look into that. But this would
not be as immediate as the already available bullseye 64bit one.

Best,
Steffen




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

[Emc-developers] @Seb, can we please have an RPi bullseye buildbot? Re: signed arm64 bullseye (armbian) binaries for download Re: trying to install linuxcnc built on buster on a bullseye system

[Steffen Möller]

On 29.01.22 05:14, gene heskett wrote:

On Friday, January 28, 2022 9:15:18 PM EST Steffen Möller wrote:

On 28.01.22 23:25, gene heskett wrote:

On Friday, January 28, 2022 2:21:50 PM EST gene heskett wrote:

On Friday, January 28, 2022 1:32:52 PM EST gene heskett wrote:

On Friday, January 28, 2022 10:18:38 AM EST Steffen Möller wrote:

...


Processing linuxcnc-uspace_2.9.0~pre0_arm64.deb...
...

Install them on a pi, and run latency-test please.

Are you running on 64bit? Then the packages should work.

Not on the pi's, always armhf. arm64 is too slow. This runs fine on
a
pi3 even, but the rpi3 is dragging its tongue on the floor, I had
to
move some of the lower response stuff to a slower thread to give
the
quick stuff enough time to work on the rpi3b and can't do much else
at
the same time, but it did get the job done before the rpi4 came
out.

Machine control, in close enough to real time demand low irq
latency.
For normal pc's AMD processors don't do that even running rtai
kernels, but intels from about 586 had managed it well enough to
work
but i5's are amazing. Even atoms ran it well enough to get the job
done here for about a decade but they've all died for various
reasons
associated with the bblb syndrome now. I've got 2 I need to recycle
but haven't made the trip to the recycle trailer yet. I bought a
stack
of off-lease Dells to replace the atoms with, works very well with
my
only complaint about Dells being the 2 sata ports max. Running from
SSD's you would swear they are brand new state of the art machines.

You may be able to build it on arm64's but linuxcnc checks to see
if
certain resources are available that are only available from a
realtime, fully preemptable kernel, making a graceful exit if they
aren't found.

Tell you what, I just found a debian armhf net-install image for
armhf
in 11.2, and since I can't get it built on a raspios bullseye, I'll
rewrite that card and start from scratch with a genuine debian 11.2
install, just to see if I can make it run, with this kernel, on your
bullseye.

When I have something to report, I will.

And I can confirm that the armhf net-install of 11.2, will not boot
on a pi.  That is assuming dd can write a valid .iso to an sd card
just as it writes the raspios .img files. So a good .iso should, and
has worked just fine several times, but two writes of the .iso have
refused to look at the card after the first green flash of the disk
activity led.

Then I found my card reader was on strike, so I drove out to the
other
side of town to walmart and bought two more readers, along with a
keyboard cuz the space bar on this one is getting funkity, and 2 more
64G micro-cards.

I rewrote the debian net-install image, then inspected it with fdisk,
to discover the debian iso I had just written to it for /dev/sdk,
partition 1 while a dos (vfat to linux) image is also an EFI image,
the first one that pi has ever seen.

So Steffen, if you want me to try your distro, respin that .iso w/o
the EFI. The pi doesn't take more than a 10 millisecond glance at
this .iso.

Thank you tons for your efforts.


I am blown away. You are indeed the right man for the job. Most of the
devs I've interfaced with would have taken that as an insult no matter
how I worded it, which I didn't really mean it to be. Thank you very
much.


I happily concentrate on getting you mill functional with your RPi, and
do not really care what you use for it. Also I am only peripheral to
LinuxCNC, have only helped with the last meters of the Debian packaging
(and this works, just not for your RPi). My local situation is that I
have the Duet3 Main+Extension boards (from Duet3d.com) arriving next
week. They have their own CNC interface as part of their firmware. That
extension board (without that firmware) can be contacted directly via
CAN, so my summer project will be to use that interface, likely also on
top of an RPi, and have LinuxCNC talk to it. Should I be successful with
that then I may decide to call myself very close to LinuxCNC and
familiar with all that HAL interiors. If I am not successful then I need
to find out why that is. The biggest danger is that I am too happy with
what Duet3 already provides via their web interface and that their
firmware is too easy to modify (Open Source it all is). Their hardware
seems excellent.

TL;DR - I also need an RPi with LinuxCNC, just a bit later.


Now I have a problem. The config commands in my scripts, worked a week
ago before I started futzing with them to do it like you wanted. Linuxcnc
has a runinplace mode, where its is built, then commanded to runinplace
w/o an install, and then perform around 240 test runs to make sure it all
returns the correct results.  I have those scripts so that the whole
build does this testing, which is a rather prolonged process taking
around 40 minutes just to do the tests, But now its not making the debs
because the runinplace is surviving the transition to making the debs,
which it cannot then do, so what I'm doing

Re: [Emc-developers] signed arm64 bullseye (armbian) binaries for download Re: trying to install linuxcnc built on buster on a bullseye system

[Steffen Möller]

On 28.01.22 23:25, gene heskett wrote:

On Friday, January 28, 2022 2:21:50 PM EST gene heskett wrote:

On Friday, January 28, 2022 1:32:52 PM EST gene heskett wrote:

On Friday, January 28, 2022 10:18:38 AM EST Steffen Möller wrote:

...


Processing linuxcnc-uspace_2.9.0~pre0_arm64.deb...
...

Install them on a pi, and run latency-test please.

Are you running on 64bit? Then the packages should work.

Not on the pi's, always armhf. arm64 is too slow. This runs fine on a
pi3 even, but the rpi3 is dragging its tongue on the floor, I had to
move some of the lower response stuff to a slower thread to give the
quick stuff enough time to work on the rpi3b and can't do much else
at
the same time, but it did get the job done before the rpi4 came out.

Machine control, in close enough to real time demand low irq latency.
For normal pc's AMD processors don't do that even running rtai
kernels, but intels from about 586 had managed it well enough to work
but i5's are amazing. Even atoms ran it well enough to get the job
done here for about a decade but they've all died for various reasons
associated with the bblb syndrome now. I've got 2 I need to recycle
but haven't made the trip to the recycle trailer yet. I bought a
stack
of off-lease Dells to replace the atoms with, works very well with my
only complaint about Dells being the 2 sata ports max. Running from
SSD's you would swear they are brand new state of the art machines.

You may be able to build it on arm64's but linuxcnc checks to see if
certain resources are available that are only available from a
realtime, fully preemptable kernel, making a graceful exit if they
aren't found.

Tell you what, I just found a debian armhf net-install image for armhf
in 11.2, and since I can't get it built on a raspios bullseye, I'll
rewrite that card and start from scratch with a genuine debian 11.2
install, just to see if I can make it run, with this kernel, on your
bullseye.

When I have something to report, I will.

And I can confirm that the armhf net-install of 11.2, will not boot on a
pi.  That is assuming dd can write a valid .iso to an sd card just as it
writes the raspios .img files. So a good .iso should, and has worked just
fine several times, but two writes of the .iso have refused to look at
the card after the first green flash of the disk activity led.

Then I found my card reader was on strike, so I drove out to the other
side of town to walmart and bought two more readers, along with a
keyboard cuz the space bar on this one is getting funkity, and 2 more 64G
micro-cards.

I rewrote the debian net-install image, then inspected it with fdisk, to
discover the debian iso I had just written to it for /dev/sdk, partition
1 while a dos (vfat to linux) image is also an EFI image, the first one
that pi has ever seen.

So Steffen, if you want me to try your distro, respin that .iso w/o the
EFI. The pi doesn't take more than a 10 millisecond glance at this .iso.


Thank you tons for your efforts.

I gave all my RPis away, so I must admit, so I cannot easily follow up.
It will take a bit for an RPi4 to arrive. And a comparison of latencies
on 32 and 64 bits will also be interesting.

All bullseye variants on whatever platform should just somehow get
LinuxCNC compiled, so I am indeed curious to learn what is going on.

Best,
Steffen



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

Re: [Emc-developers] signed arm64 bullseye (armbian) binaries for download Re: trying to install linuxcnc built on buster on a bullseye system

[Steffen Möller]

...

Processing linuxcnc-uspace_2.9.0~pre0_arm64.deb...
...

Install them on a pi, and run latency-test please.


Are you running on 64bit? Then the packages should work.




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

Re: [Emc-developers] signed arm64 bullseye (armbian) binaries for download Re: trying to install linuxcnc built on buster on a bullseye system

[Steffen Möller]

Thank you for the quick feedback, Rod!

On 28.01.22 14:02, Rod Webster wrote:

Thanks Stefan,
I was unable to download any of the files to my Chromebook. I will try
again on a real PC in the morning.
I know Drive has added some extra security around possible cyber attacks
through drive. Its possible downloads are blocked.

Hm. Ok. I have a regular website that we can also use. Tell me if these
problems persist.

It did tell me to try enabling third party cookies in chrome but it made no
difference.
Tomorrow morning I am going to be installing Deban 11.2 on a X86 device so
I may have had time to try this as well.
I had 2 goes today at the X86 installation and for some reason I had
troubles today after 2 attempts with debian 11.2 because some dependencies
including suffixes on the versions similar to this:
libmount-dev : Depends: libblkid-dev but it is not going to be installed
 Depends: libmount1 ( 2.36.1-8) but 2.36.1-8+deb11u1 is to
be installed

I suggest you install aptitude and then run "sudo aptitude install
libmount-dev" which then proposes a solution to get this installed.

Its a bit annoying because I have LCNC running on three Debian 11 PC's
already and the machine in  question was running 11.0 installed about 2
weeks before the official Bullseye release (eg when it was testing).. These
errors are pretty deep in the dependency tree so hard to find the actual
problem packages (Ghostscript is one).

-> aptitude

Anyway tomorrow I am trying a scripted approach developed by James Walker
which is intended to become part of QTPYVCP.
https://github.com/joco-nz/lcnc-bullseye-installer
but am open to ideas...


I proposed a simplification on
https://github.com/joco-nz/lcnc-bullseye-installer/pull/1

Best,
Steffen



On Fri, 28 Jan 2022 at 22:30, Steffen Möller  wrote:


Hello again,

I built the arm64 packages on an odroid that runs armbian's bullseye
variant. Placed it on


https://drive.google.com/drive/folders/1kTr7uigCQY3c-layLJKdXqN5sRsXJnWo?usp=sharing

It worked just fine, except that armbian apparently does not have that
gpl2-variant of the readline library, so I prepared a respective pull
request to ease that. No problems with the boost libraries.

For what it's worth, I gpg-signed the packages (the changes and dsc file
to be exact) with my Debian-developer-key, so you can have the same
trust in the packages as if you received them via Debian:

$ dpkg-sig -l *deb
Processing linuxcnc-doc-en_2.9.0~pre0_all.deb...
builder
Processing linuxcnc-doc-es_2.9.0~pre0_all.deb...
builder
builder0
Processing linuxcnc-doc-fr_2.9.0~pre0_all.deb...
builder
Processing linuxcnc-doc-zh-cn_2.9.0~pre0_all.deb...
builder
Processing linuxcnc-uspace_2.9.0~pre0_arm64.deb...
builder
Processing linuxcnc-uspace-dbgsym_2.9.0~pre0_arm64.deb...
builder
Processing linuxcnc-uspace-dev_2.9.0~pre0_arm64.deb...
builder

If the "builder" does not show then the package was not signed.

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] signed arm64 bullseye (armbian) binaries for download Re: trying to install linuxcnc built on buster on a bullseye system

[Steffen Möller]

Hello again,

I built the arm64 packages on an odroid that runs armbian's bullseye
variant. Placed it on

https://drive.google.com/drive/folders/1kTr7uigCQY3c-layLJKdXqN5sRsXJnWo?usp=sharing

It worked just fine, except that armbian apparently does not have that
gpl2-variant of the readline library, so I prepared a respective pull
request to ease that. No problems with the boost libraries.

For what it's worth, I gpg-signed the packages (the changes and dsc file
to be exact) with my Debian-developer-key, so you can have the same
trust in the packages as if you received them via Debian:

$ dpkg-sig -l *deb
Processing linuxcnc-doc-en_2.9.0~pre0_all.deb...
builder
Processing linuxcnc-doc-es_2.9.0~pre0_all.deb...
builder
builder0
Processing linuxcnc-doc-fr_2.9.0~pre0_all.deb...
builder
Processing linuxcnc-doc-zh-cn_2.9.0~pre0_all.deb...
builder
Processing linuxcnc-uspace_2.9.0~pre0_arm64.deb...
builder
Processing linuxcnc-uspace-dbgsym_2.9.0~pre0_arm64.deb...
builder
Processing linuxcnc-uspace-dev_2.9.0~pre0_arm64.deb...
builder

If the "builder" does not show then the package was not signed.

Best,
Steffen

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

Re: [Emc-developers] trying to install linuxcnc built on buster on a bullseye system

[Steffen Möller]

On 28.01.22 02:15, gene heskett wrote:

On Thursday, January 27, 2022 7:17:10 PM EST Steffen Möller wrote:

On 28.01.22 00:31, gene heskett wrote:

On Thursday, January 27, 2022 2:22:43 PM EST Steffen Möller wrote:

On 27.01.22 20:03, gene heskett wrote:

On Thursday, January 27, 2022 9:54:54 AM EST Steffen Möller wrote:

Fresh start!

Dear Gene,

I would like to catch the problem before you start building and
also
exclude the possibility that somehow the code base of yours is
affected by your previous checkout - just because I cannot inspect
your machine from here. Once that was successful, yes, then this
can be optimized.

First thing is that the system needs to be truly updated, nothing
half-ish.

Remember Steffen, that this sd card was A, new, and b, written with
dd
using 2021-10-30-raspios-bullseye-armhf-full.img,

sd card then put in the pi and booted, after I had fixed the no
network problem by filling in the defaults for a static network by
putting my hosts file over the default, editing /etc/hostname to be
the same as the buster install it would replace, and filling in and
uncommenting the bottom of its /etc/dhcpcd.conf file to match the
buster net config. It was then booted, I assigned the country,
keyboard and other first boot things in raspi-config. rebooted, at
which point it ran the update/ upgrade stuff bringing it up to date
by upgrading 129 pkgs then.  The apt update/apt upgrade -y has been
done several more times, and just now replaced 5 python pkgs.

sudo apt dist-upgrade just returned:
=
pi@rpi4:/media/pi/workspace $ sudo apt dist-upgrade -y
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no
longer

required:
 dctrl-tools dkms libfuse2 libxtables-dev
 raspberrypi-kernel-headers

Use 'sudo apt autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
=
So it is, ANAICT, a fully uptodate bullseye install.

In the middle of that, I mounted the drive I had built a
5.16.2-rt19
kernel on and installed that, so a uname -a now returns:
===
Linux rpi4 5.16.2-rt19-rt19-v7l+ #3 SMP PREEMPT_RT Tue Jan 25
01:14:16
EST 2022 armv7l GNU/Linux
===
Almost as bleeding edge as has been announced on the linux-rt list.
I have since ran the first of my scripts to build master, then
scanned
the output for missing dependency's, installing those I spot in the
back trace.

I have not adjusted anything in the config, or debian directories
of
this git clone which is of the raspberry/linux. I have been doing
this build since jessie days so I'm not new to this. At one point
pi
stuff was being built on an odroid C2 at the buildbot, but crashed
several times a week and has been replaced with an rpi4 I believe,
same as this one.

I faintly recall having to do something for buster but at 87 yo I
do
not recall what it was I had to do back then. And I have not noted
the build your own recipe in our wiki as having been updated since
wheezy, so it is, shall we say, a bit long in the tooth in 2022. :)

And the next missing dependency is "convert", and its a showstopper
for configure.

I was not aware of "convert". You have done everything just fine.


Please do

sudo apt update

that showed 5 pkgs could be upgraded which I did.


sudo apt -u dist-upgrade

see above


Anything surprising/weird/many packages listed? Then please tell
me
or
continue with "yes".

Wherever you have the disk space please then do a

I have the space, its a 240gig SSD


git clone https://github.com/LinuxCNC/linuxcnc.git
bullseye-linuxcnc

Will take an hour or more, my net connection is leisurely.


cd new-dir-name

python3 --version # should be more recent than 3.7

pi@rpi4:/media/pi/workspace $ python3 --version
Python 3.9.2


Please ping me again once you got to this stage.

And configure still bails out:
checking for convert... none

configure: error: no convert, documentation cannot be built

You are two steps ahead :) I presume you ran

debian/configure

but just do it again, please, so I know what was done. The "uspace"
argument is the default, so just run as shown above.

We now have the debian/control file. This debian/control file
declares
the packages that are required to run the package, but especially
also
the packages that are required to build the package.

Now run

dpkg-buildpackage

and it will check that debian/control file to see if all packages
are
indeed installed that need to be installed to build the packages.

When you invoke this now then it will fail (so I hope) because the
package "imagemagick" is missing which then also provides
/usr/bin/convert. There are likely other packages, too, that
configure
would identify as missing if it was not already halting after
checking
for "con

Re: [Emc-developers] trying to install linuxcnc built on buster on a bullseye system

[Steffen Möller]

On 28.01.22 00:31, gene heskett wrote:

On Thursday, January 27, 2022 2:22:43 PM EST Steffen Möller wrote:

On 27.01.22 20:03, gene heskett wrote:

On Thursday, January 27, 2022 9:54:54 AM EST Steffen Möller wrote:

Fresh start!

Dear Gene,

I would like to catch the problem before you start building and also
exclude the possibility that somehow the code base of yours is
affected by your previous checkout - just because I cannot inspect
your machine from here. Once that was successful, yes, then this
can be optimized.

First thing is that the system needs to be truly updated, nothing
half-ish.

Remember Steffen, that this sd card was A, new, and b, written with
dd
using 2021-10-30-raspios-bullseye-armhf-full.img,

sd card then put in the pi and booted, after I had fixed the no
network problem by filling in the defaults for a static network by
putting my hosts file over the default, editing /etc/hostname to be
the same as the buster install it would replace, and filling in and
uncommenting the bottom of its /etc/dhcpcd.conf file to match the
buster net config. It was then booted, I assigned the country,
keyboard and other first boot things in raspi-config. rebooted, at
which point it ran the update/ upgrade stuff bringing it up to date
by upgrading 129 pkgs then.  The apt update/apt upgrade -y has been
done several more times, and just now replaced 5 python pkgs.

sudo apt dist-upgrade just returned:
=
pi@rpi4:/media/pi/workspace $ sudo apt dist-upgrade -y
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer

required:
dctrl-tools dkms libfuse2 libxtables-dev
raspberrypi-kernel-headers

Use 'sudo apt autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
=
So it is, ANAICT, a fully uptodate bullseye install.

In the middle of that, I mounted the drive I had built a 5.16.2-rt19
kernel on and installed that, so a uname -a now returns:
===
Linux rpi4 5.16.2-rt19-rt19-v7l+ #3 SMP PREEMPT_RT Tue Jan 25
01:14:16
EST 2022 armv7l GNU/Linux
===
Almost as bleeding edge as has been announced on the linux-rt list.
I have since ran the first of my scripts to build master, then
scanned
the output for missing dependency's, installing those I spot in the
back trace.

I have not adjusted anything in the config, or debian directories of
this git clone which is of the raspberry/linux. I have been doing
this build since jessie days so I'm not new to this. At one point pi
stuff was being built on an odroid C2 at the buildbot, but crashed
several times a week and has been replaced with an rpi4 I believe,
same as this one.

I faintly recall having to do something for buster but at 87 yo I do
not recall what it was I had to do back then. And I have not noted
the build your own recipe in our wiki as having been updated since
wheezy, so it is, shall we say, a bit long in the tooth in 2022. :)

And the next missing dependency is "convert", and its a showstopper
for configure.

I was not aware of "convert". You have done everything just fine.


Please do

sudo apt update

that showed 5 pkgs could be upgraded which I did.


sudo apt -u dist-upgrade

see above


Anything surprising/weird/many packages listed? Then please tell me
or
continue with "yes".

Wherever you have the disk space please then do a

I have the space, its a 240gig SSD


git clone https://github.com/LinuxCNC/linuxcnc.git bullseye-linuxcnc

Will take an hour or more, my net connection is leisurely.


cd new-dir-name

python3 --version # should be more recent than 3.7

pi@rpi4:/media/pi/workspace $ python3 --version
Python 3.9.2


Please ping me again once you got to this stage.

And configure still bails out:
   checking for convert... none

configure: error: no convert, documentation cannot be built

You are two steps ahead :) I presume you ran

debian/configure

but just do it again, please, so I know what was done. The "uspace"
argument is the default, so just run as shown above.

We now have the debian/control file. This debian/control file declares
the packages that are required to run the package, but especially also
the packages that are required to build the package.

Now run

dpkg-buildpackage

and it will check that debian/control file to see if all packages are
indeed installed that need to be installed to build the packages.

When you invoke this now then it will fail (so I hope) because the
package "imagemagick" is missing which then also provides
/usr/bin/convert. There are likely other packages, too, that configure
would identify as missing if it was not already halting after checking
for "convert". So, dpkg-buildpacakge will list all the packages that
are missing. Please install those and then r

Re: [Emc-developers] trying to install linuxcnc built on buster on a bullseye system

[Steffen Möller]

Hello,

On 27.01.22 20:41, Rod Webster wrote:

I don't have a dependency for convert anywhere in my notes.

imagemagick provides it.

One thing you could do is add the nodocs flag to configure which builds
Linuxcnc without the documents. This may bypass the convert dependency and
also save a heap of time building the debs.


Which for the RPi and he SD card underneath would be good. Next time.

Best,
Steffen



On Fri, 28 Jan 2022 at 05:23, Steffen Möller  wrote:


On 27.01.22 20:03, gene heskett wrote:


On Thursday, January 27, 2022 9:54:54 AM EST Steffen Möller wrote:

Fresh start!

Dear Gene,

I would like to catch the problem before you start building and also
exclude the possibility that somehow the code base of yours is affected
by your previous checkout - just because I cannot inspect your machine
from here. Once that was successful, yes, then this can be optimized.

First thing is that the system needs to be truly updated, nothing
half-ish.

Remember Steffen, that this sd card was A, new, and b, written with dd
using 2021-10-30-raspios-bullseye-armhf-full.img,

sd card then put in the pi and booted, after I had fixed the no network
problem by filling in the defaults for a static network by putting my
hosts file over the default, editing /etc/hostname to be the same as the
buster install it would replace, and filling in and uncommenting the
bottom of its /etc/dhcpcd.conf file to match the buster net config.
It was then booted, I assigned the country, keyboard and other first boot
things in raspi-config. rebooted, at which point it ran the update/
upgrade stuff bringing it up to date by upgrading 129 pkgs then.  The apt
update/apt upgrade -y has been done several more times, and just now
replaced 5 python pkgs.

sudo apt dist-upgrade just returned:
=
pi@rpi4:/media/pi/workspace $ sudo apt dist-upgrade -y
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer
required:
dctrl-tools dkms libfuse2 libxtables-dev raspberrypi-kernel-headers
Use 'sudo apt autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
=
So it is, ANAICT, a fully uptodate bullseye install.

In the middle of that, I mounted the drive I had built a 5.16.2-rt19
kernel on and installed that, so a uname -a now returns:
===
Linux rpi4 5.16.2-rt19-rt19-v7l+ #3 SMP PREEMPT_RT Tue Jan 25 01:14:16
EST 2022 armv7l GNU/Linux
===
Almost as bleeding edge as has been announced on the linux-rt list.
I have since ran the first of my scripts to build master, then scanned
the output for missing dependency's, installing those I spot in the back
trace.

I have not adjusted anything in the config, or debian directories of this
git clone which is of the raspberry/linux. I have been doing this build
since jessie days so I'm not new to this. At one point pi stuff was being
built on an odroid C2 at the buildbot, but crashed several times a week
and has been replaced with an rpi4 I believe, same as this one.

I faintly recall having to do something for buster but at 87 yo I do not
recall what it was I had to do back then. And I have not noted the build
your own recipe in our wiki as having been updated since wheezy, so it
is, shall we say, a bit long in the tooth in 2022. :)

And the next missing dependency is "convert", and its a showstopper for
configure.

I was not aware of "convert". You have done everything just fine.

Please do

sudo apt update

that showed 5 pkgs could be upgraded which I did.

sudo apt -u dist-upgrade

see above

Anything surprising/weird/many packages listed? Then please tell me or
continue with "yes".

Wherever you have the disk space please then do a

I have the space, its a 240gig SSD


git clone https://github.com/LinuxCNC/linuxcnc.git bullseye-linuxcnc

Will take an hour or more, my net connection is leisurely.

cd new-dir-name

python3 --version # should be more recent than 3.7

pi@rpi4:/media/pi/workspace $ python3 --version
Python 3.9.2


Please ping me again once you got to this stage.

And configure still bails out:
   checking for convert... none
configure: error: no convert, documentation cannot be built

You are two steps ahead :) I presume you ran

debian/configure

but just do it again, please, so I know what was done. The "uspace"
argument is the default, so just run as shown above.

We now have the debian/control file. This debian/control file declares
the packages that are required to run the package, but especially also
the packages that are required to build the package.

Now run

dpkg-buildpackage

and it will check that debian/control file to see if all packages are
indeed installed that need to be installed to build the packages.

When you invoke this now then it will fail (so I hope) beca

Re: [Emc-developers] trying to install linuxcnc built on buster on a bullseye system

[Steffen Möller]

On 27.01.22 20:03, gene heskett wrote:


On Thursday, January 27, 2022 9:54:54 AM EST Steffen Möller wrote:

Fresh start!

Dear Gene,

I would like to catch the problem before you start building and also
exclude the possibility that somehow the code base of yours is affected
by your previous checkout - just because I cannot inspect your machine
from here. Once that was successful, yes, then this can be optimized.

First thing is that the system needs to be truly updated, nothing
half-ish.

Remember Steffen, that this sd card was A, new, and b, written with dd
using 2021-10-30-raspios-bullseye-armhf-full.img,

sd card then put in the pi and booted, after I had fixed the no network
problem by filling in the defaults for a static network by putting my
hosts file over the default, editing /etc/hostname to be the same as the
buster install it would replace, and filling in and uncommenting the
bottom of its /etc/dhcpcd.conf file to match the buster net config.
It was then booted, I assigned the country, keyboard and other first boot
things in raspi-config. rebooted, at which point it ran the update/
upgrade stuff bringing it up to date by upgrading 129 pkgs then.  The apt
update/apt upgrade -y has been done several more times, and just now
replaced 5 python pkgs.

sudo apt dist-upgrade just returned:
=
pi@rpi4:/media/pi/workspace $ sudo apt dist-upgrade -y
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer
required:
   dctrl-tools dkms libfuse2 libxtables-dev raspberrypi-kernel-headers
Use 'sudo apt autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
=
So it is, ANAICT, a fully uptodate bullseye install.

In the middle of that, I mounted the drive I had built a 5.16.2-rt19
kernel on and installed that, so a uname -a now returns:
===
Linux rpi4 5.16.2-rt19-rt19-v7l+ #3 SMP PREEMPT_RT Tue Jan 25 01:14:16
EST 2022 armv7l GNU/Linux
===
Almost as bleeding edge as has been announced on the linux-rt list.
I have since ran the first of my scripts to build master, then scanned
the output for missing dependency's, installing those I spot in the back
trace.

I have not adjusted anything in the config, or debian directories of this
git clone which is of the raspberry/linux. I have been doing this build
since jessie days so I'm not new to this. At one point pi stuff was being
built on an odroid C2 at the buildbot, but crashed several times a week
and has been replaced with an rpi4 I believe, same as this one.

I faintly recall having to do something for buster but at 87 yo I do not
recall what it was I had to do back then. And I have not noted the build
your own recipe in our wiki as having been updated since wheezy, so it
is, shall we say, a bit long in the tooth in 2022. :)

And the next missing dependency is "convert", and its a showstopper for
configure.

I was not aware of "convert". You have done everything just fine.



Please do

sudo apt update

that showed 5 pkgs could be upgraded which I did.

sudo apt -u dist-upgrade

see above

Anything surprising/weird/many packages listed? Then please tell me or
continue with "yes".

Wherever you have the disk space please then do a

I have the space, its a 240gig SSD


git clone https://github.com/LinuxCNC/linuxcnc.git bullseye-linuxcnc

Will take an hour or more, my net connection is leisurely.

cd new-dir-name

python3 --version # should be more recent than 3.7

pi@rpi4:/media/pi/workspace $ python3 --version
Python 3.9.2


Please ping me again once you got to this stage.

And configure still bails out:
  checking for convert... none
configure: error: no convert, documentation cannot be built


You are two steps ahead :) I presume you ran

debian/configure

but just do it again, please, so I know what was done. The "uspace"
argument is the default, so just run as shown above.

We now have the debian/control file. This debian/control file declares
the packages that are required to run the package, but especially also
the packages that are required to build the package.

Now run

dpkg-buildpackage

and it will check that debian/control file to see if all packages are
indeed installed that need to be installed to build the packages.

When you invoke this now then it will fail (so I hope) because the
package "imagemagick" is missing which then also provides
/usr/bin/convert. There are likely other packages, too, that configure
would identify as missing if it was not already halting after checking
for "convert". So, dpkg-buildpacakge will list all the packages that are
missing. Please install those and then run dpkg-buildpackage again.

LinuxCNC has a bit of a problem with interrupted builds. There is a
chance that dpkg-buildpacka

Re: [Emc-developers] trying to install linuxcnc built on buster on a bullseye system

[Steffen Möller]

Fresh start!

Dear Gene,

I would like to catch the problem before you start building and also
exclude the possibility that somehow the code base of yours is affected
by your previous checkout - just because I cannot inspect your machine
from here. Once that was successful, yes, then this can be optimized.

First thing is that the system needs to be truly updated, nothing half-ish.

Please do

sudo apt update
sudo apt -u dist-upgrade

Anything surprising/weird/many packages listed? Then please tell me or
continue with "yes".

Whereever you have the disk space please then do a

git clone https://github.com/LinuxCNC/linuxcnc.git new-dir-name

cd new-dir-name

python3 --version # should be more recent than 3.7

Please ping me again once you got to this stage.

Thanks and regards

Steffen



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

Re: [Emc-developers] trying to install linuxcnc built on buster on a bullseye system

[Steffen Möller]

On 27.01.22 14:31, gene heskett wrote:

On Tuesday, January 25, 2022 8:27:27 PM EST gene heskett wrote:

Greetings all;

I built a fresh pull of master earlier today, which makes installable
debs. I normally run this shell script to install them, and on buster
it Just Works.

But, now I have succeeded in getting a raspios bullseye to run on a
5.16.2-rt19-rt19-v7l+ #3 SMP PREEMPT_RT kernel, and that first boot
updated about 2gigs of stuff. There is about 130 pkgs to update.

And I've found a solution to the no net on boot problem applicable to
home networks that are hosts file based. If you while the card is still
mounted in a reader, edit the /etc/dhcpdcp.conf file, you will find a
place at the bottom that is commented out but you can uncomment it and
fill in the data to fit your setup, and when booted in the pi, just
works, you have a network from the gitgo. Thats one MAJOR headache out
of the way.

BUT, what I built on buster, will not install on bullseye as too much
has been version advanced. I have installed about a gig of stuff dpkg
complains about but have not been able to get a working install.
yet...

The remaining errors are:
dpkg: dependency problems prevent configuration of linuxcnc-uspace:
  linuxcnc-uspace depends on libboost-python1.67.0; however:
   Package libboost-python1.67.0 is not installed.
  linuxcnc-uspace depends on libpython3.7 (>= 3.7.0); however:
   Package libpython3.7 is not installed.
  linuxcnc-uspace depends on python3 (<< 3.8); however:
   Version of python3 on system is 3.9.2-3.
  linuxcnc-uspace depends on python3.7-tk; however:
   Package python3.7-tk is not installed.
  linuxcnc-uspace depends on python3.7-numpy | python-numpy; however:
   Package python3.7-numpy is not installed.
   Package python-numpy is not installed.

But newer versions of all the above are all installed.
I do not know at this stage if I have enough to rebuild them as yet.
The debhelper suite is not yet installed.

So I need to see the /e/a/sources.list.d/linuxcnc.list file for
bullseye so I can see if those .debs will install.

Thanks guys, take care and stay well everybody.

Cheers, Gene Heskett.

addendum: I've now installed quite a few more pkgs it needs to build on
bullseye, but have hit a real showstopper. "convert" is completely
missing from the bullseye repos and configure is bailing out. There are
also quite a few squawks about python stuff that isn't quite right but
the missing convert is the current showstopper. Its also fussing about
missing rtai stuff, like it may be missconfigured or an ENV thing is
wrong, uspace does not supposedly depend on rtai when running on a
preempt-rt kernel. But I'm not THAT expert so IDK.

What do I/we do about the missing convert?


In my previous response I was informing you that your cron job
substitutes the master branch that you have checked out first with
another branch that is 7 months old by subsequently checking out that
gtk3 variant.

The paragraph above does not direct me to anything that I could possibly
use to learn if you have fixed the one thing that is for sure messing
everything up and explains the error messages that you have still in
this email.

Remote debugging with incomplete information is a bit difficult, as we
just cannot see what you can see. I suggest you build everything in a
new directory with a different name that is not interfered with by
background processes.

Thumbs pressed, other fingers crossed

Steffen



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

Re: [Emc-developers] trying to install linuxcnc built on buster on a bullseye system

[Steffen Möller]

On 27.01.22 00:35, gene heskett wrote:

On Wednesday, January 26, 2022 5:22:10 PM EST Steffen Möller wrote:

Seems like you have done something to your git repository and it cannot
just go and fetch the newer version. It could be that these are just
some changes that have been made during the build (don't think so,
should not happen) but ... you can investigate this later. "git
status" would tell what is modified.

git status returns:
===
pi@rpi4:/media/pi/workspace/linuxcnc-dev $ git status
On branch master-gtk3
Your branch is up to date with 'origin/master-gtk3'.

nothing to commit, working tree clean
===

I personally like "git config
pull.rebase true" which puts local changes in the perspective of the
latest release.

And returns nothing here.

You were just configuring a default behaviour for git. It's fine. The
warning will not be triggered since there is nothing, yet.



To get the build done, I suggest to prepend to your script something
alike

if [ -d linuxcnc-dev ]; then
 d=$(date -R)
 echo "I: Removing previous repository of linuxcnc-dev to
'linuxcnc-dev-$d'"
 mv linuxcnc-dev "linuxcnc-dev-$d"
fi
mkdir linuxcnc-dev

so everything is clean - you do not run that script too often, I
presume.

As often as its run. that would fill that 240gig drive in about a year.
:)


Well, I did not think straight. Please remove the "mkdir". Instead do

git clone https://github.com/LinuxCNC/linuxcnc.git linuxcnc-dev

so you have a fully functional git repository again.



git checkout master-gtk3


Seems like we found the culprit.

Please check https://github.com/LinuxCNC/linuxcnc/tree/master-gtk3/debian

and find this lacking all the recent developments from master.

When you "checkout" a branch you get all the files in the version they
have last been edited in that branch. That you have a past in the master
branch from the line above the git system does not remember, i.e. no
updates are transferred to that other branch. It is context-free. I
suggest to remove that second checkout from your cron file and just
checkout the true master branch and stay in it.

Cheers,
Steffen




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

Re: [Emc-developers] trying to install linuxcnc built on buster on a bullseye system

[Steffen Möller]

Seems like you have done something to your git repository and it cannot
just go and fetch the newer version. It could be that these are just
some changes that have been made during the build (don't think so,
should not happen) but ... you can investigate this later. "git status"
would tell what is modified. I personally like "git config pull.rebase
true" which puts local changes in the perspective of the latest release.

To get the build done, I suggest to prepend to your script something alike

if [ -d linuxcnc-dev ]; then
   d=$(date -R)
   echo "I: Removing previous repository of linuxcnc-dev to
'linuxcnc-dev-$d'"
   mv linuxcnc-dev "linuxcnc-dev-$d"
fi
mkdir linuxcnc-dev

so everything is clean - you do not run that script too often, I presume.

Best,
Steffen

On 26.01.22 22:57, gene heskett wrote:

On Wednesday, January 26, 2022 3:49:58 PM EST Steffen Möller wrote:

Hi Gene,


My script does a git pull first thing, which advises this:
===
  pi@rpi4:/media/pi/workspace $ time ./maketoruntests.sh
Updating files: 100% (1854/1854), done.
Switched to branch 'master'
Your branch is up to date with 'origin/master'.
hint: Pulling without specifying how to reconcile divergent branches is
hint: discouraged. You can squelch this message by running one of the
following
hint: commands sometime before your next pull:
hint:
hint:   git config pull.rebase false  # merge (the default strategy)
hint:   git config pull.rebase true   # rebase
hint:   git config pull.ff only   # fast-forward only
hint:
hint: You can replace "git config" with "git config --global" to set a
default
hint: preference for all repositories. You can also pass --rebase, --no-
rebase,
hint: or --ff-only on the command line to override the configured default
per
hint: invocation.
===
Which do you suggest I edit into this script:
==
cd /media/pi/workspace/linuxcnc-dev/
git checkout master
git pull
git checkout master-gtk3
git pull
cd ./src
./autogen.sh
./configure --with-realtime=uspace --enable-build-documentation
sudo make clean
make -j4
sudo make setuid
source ../scripts/rip-environment
cd ..
cd ./src
runtests

==
I probably don't have exactly the right git stuff, not sure I understand
it all, but its been working ok for about a year now, building good
linuxcnc deb's on buster.


On 26.01.22 02:27, gene heskett wrote:

Greetings all;

I built a fresh pull of master earlier today, which makes installable
debs. I normally run this shell script to install them, and on buster
it Just Works.

And that is how things should also behave on Bullseye. Let's find out
what is going wrong.


But, now I have succeeded in getting a raspios bullseye to run on a
5.16.2-rt19-rt19-v7l+ #3 SMP PREEMPT_RT kernel, and that first boot
updated about 2gigs of stuff. There is about 130 pkgs to update.

I have not run bullseye on a Raspberry, yet. I would however indeed go
and update everything.

sudo apt-get -u dist-upgrade

should get you there.


And I've found a solution to the no net on boot problem applicable to
home networks that are hosts file based. If you while the card is
still mounted in a reader, edit the /etc/dhcpdcp.conf file, you will
find a place at the bottom that is commented out but you can
uncomment it and fill in the data to fit your setup, and when booted
in the pi, just works, you have a network from the gitgo. Thats one
MAJOR headache out of the way.

BUT, what I built on buster, will not install on bullseye as too much
has been version advanced.

That is expected.


I have installed about a gig of stuff dpkg
complains about but have not been able to get a working install.
yet...

The remaining errors are:

dpkg: dependency problems prevent configuration of linuxcnc-uspace:
   linuxcnc-uspace depends on libboost-python1.67.0; however:
Package libboost-python1.67.0 is not installed.

   linuxcnc-uspace depends on libpython3.7 (>= 3.7.0); however:
Package libpython3.7 is not installed.

   linuxcnc-uspace depends on python3 (<< 3.8); however:
Version of python3 on system is 3.9.2-3.

   linuxcnc-uspace depends on python3.7-tk; however:
Package python3.7-tk is not installed.

   linuxcnc-uspace depends on python3.7-numpy | python-numpy; however:
Package python3.7-numpy is not installed.
Package python-numpy is not installed.

This raised some eyebrows on my end. Python 3.7 is history and
dependencies are on Python3. A grep in the debian directory of what I
have checked out from master does not have any notion of "3.7" in the
debian folder. And python-numpy (without the "3") is a Python2 version,
which is no longer needed.


But newer versions of all the above are all installed.
I do not know at this stage if I have enough to rebuild them as yet.
The debhelper suite is not yet installed.

So I need to see the /e/a/sources.list.d/linuxcnc.list file f

Re: [Emc-developers] trying to install linuxcnc built on buster on a bullseye system

[Steffen Möller]

On 26.01.22 22:30, gene heskett wrote:

On Wednesday, January 26, 2022 3:49:58 PM EST Steffen Möller wrote:

On 26.01.22 02:27, gene heskett wrote:

Greetings all;

I built a fresh pull of master earlier today, which makes installable
debs. I normally run this shell script to install them, and on buster
it Just Works.

And that is how things should also behave on Bullseye. Let's find out
what is going wrong.


But, now I have succeeded in getting a raspios bullseye to run on a
5.16.2-rt19-rt19-v7l+ #3 SMP PREEMPT_RT kernel, and that first boot
updated about 2gigs of stuff. There is about 130 pkgs to update.

I have not run bullseye on a Raspberry, yet. I would however indeed go
and update everything.

sudo apt-get -u dist-upgrade

should get you there.


But I am already there. From my running rpi4 a uname -a:
Linux rpi4 5.16.2-rt19-rt19-v7l+ #3 SMP PREEMPT_RT Tue Jan 25 01:14:16
EST 2022 armv7l GNU/Linu


I have installed about a gig of stuff dpkg
complains about but have not been able to get a working install.
yet...

The remaining errors are:

dpkg: dependency problems prevent configuration of linuxcnc-uspace:
   linuxcnc-uspace depends on libboost-python1.67.0; however:
Package libboost-python1.67.0 is not installed.

   linuxcnc-uspace depends on libpython3.7 (>= 3.7.0); however:
Package libpython3.7 is not installed.

   linuxcnc-uspace depends on python3 (<< 3.8); however:
Version of python3 on system is 3.9.2-3.

   linuxcnc-uspace depends on python3.7-tk; however:
Package python3.7-tk is not installed.

   linuxcnc-uspace depends on python3.7-numpy | python-numpy; however:
Package python3.7-numpy is not installed.
Package python-numpy is not installed.

This raised some eyebrows on my end. Python 3.7 is history and
dependencies are on Python3. A grep in the debian directory of what I
have checked out from master does not have any notion of "3.7" in the
debian folder. And python-numpy (without the "3") is a Python2 version,
which is no longer needed.


But newer versions of all the above are all installed.
I do not know at this stage if I have enough to rebuild them as yet.
The debhelper suite is not yet installed.

So I need to see the /e/a/sources.list.d/linuxcnc.list file for
bullseye so I can see if those .debs will install.

Something is off with your package. Please have a second look at when
this package was built. Maybe it is an old one that was carried over
from your past with Buster?

They all were built on thst rpi4 earlier yesterday while an uptodate
buster was running.

That might explain it. My hunch is that at the time the dependencies
were determined there was an earlier version of the said library installed.

For C libraries there is a mechanism to automagically find the right
"soname"
(which basically is a name for the ABI, part of that soname is the
soversion)
and this may indeed have anchored Python3.7 in your package, which was
then updated to 3.9 or so.


I build all the makefiles say to build but only
install the english stuff, but the buster built uspace stuff won't
install on bullseye, with the above errors shown. So I guess I move them
to a buster subdir to protect them from being overwritten, and see how
far I get with a bullseye build. FWIW, they did install on buster, thats
part of my make-all.sh script.

Would you be prepared to try again? From scratch starting with a
checkout of the master branch?

Its an uptodate a/o a yesterday mornings pull & checkout, both master and
master-gtk s/b current as of then.

Please try again, even if it hurts a bit. I am confident that it will work.
I have access to an odroid on which I can otherwise prepare an ARM64
package for you.


Thank you Stephen. I'll advise if I find anything foobar as I go charging
off into new territory.

Take care and stay well.


So do you, please!

Steffen



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

Re: [Emc-developers] trying to install linuxcnc built on buster on a bullseye system

[Steffen Möller]

Hi Gene,

On 26.01.22 02:27, gene heskett wrote:

Greetings all;

I built a fresh pull of master earlier today, which makes installable
debs. I normally run this shell script to install them, and on buster it
Just Works.

And that is how things should also behave on Bullseye. Let's find out
what is going wrong.

But, now I have succeeded in getting a raspios bullseye to run on a
5.16.2-rt19-rt19-v7l+ #3 SMP PREEMPT_RT kernel, and that first boot
updated about 2gigs of stuff. There is about 130 pkgs to update.


I have not run bullseye on a Raspberry, yet. I would however indeed go
and update everything.

sudo apt-get -u dist-upgrade

should get you there.


And I've found a solution to the no net on boot problem applicable to
home networks that are hosts file based. If you while the card is still
mounted in a reader, edit the /etc/dhcpdcp.conf file, you will find a
place at the bottom that is commented out but you can uncomment it and
fill in the data to fit your setup, and when booted in the pi, just
works, you have a network from the gitgo. Thats one MAJOR headache out of
the way.

BUT, what I built on buster, will not install on bullseye as too much has
been version advanced.

That is expected.

I have installed about a gig of stuff dpkg
complains about but have not been able to get a working install. yet...

The remaining errors are:
dpkg: dependency problems prevent configuration of linuxcnc-uspace:
  linuxcnc-uspace depends on libboost-python1.67.0; however:
   Package libboost-python1.67.0 is not installed.
  linuxcnc-uspace depends on libpython3.7 (>= 3.7.0); however:
   Package libpython3.7 is not installed.
  linuxcnc-uspace depends on python3 (<< 3.8); however:
   Version of python3 on system is 3.9.2-3.
  linuxcnc-uspace depends on python3.7-tk; however:
   Package python3.7-tk is not installed.
  linuxcnc-uspace depends on python3.7-numpy | python-numpy; however:
   Package python3.7-numpy is not installed.
   Package python-numpy is not installed.

This raised some eyebrows on my end. Python 3.7 is history and
dependencies are on Python3. A grep in the debian directory of what I
have checked out from master does not have any notion of "3.7" in the
debian folder. And python-numpy (without the "3") is a Python2 version,
which is no longer needed.

But newer versions of all the above are all installed.
I do not know at this stage if I have enough to rebuild them as yet.
The debhelper suite is not yet installed.

So I need to see the /e/a/sources.list.d/linuxcnc.list file for bullseye
so I can see if those .debs will install.


Something is off with your package. Please have a second look at when
this package was built. Maybe it is an old one that was carried over
from your past with Buster?

Would you be prepared to try again? From scratch starting with a
checkout of the master branch?

Best,
Steffen





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

Re: sambamba and freebayes new releases

[Steffen Möller]

Also many thanks to you both and greetings from my side!

Best,
Steffen

On 21.01.22 12:17, Andreas Tille wrote:

Am Fri, Jan 21, 2022 at 11:45:48AM +0100 schrieb Pjotr Prins:

We release sambamba and freebayes with updated meson build systems. It
should work for Debian. If not I am happy to troubleshoot.

$ apt policy sambamba
sambamba:
   Installed: (none)
   Candidate: 0.8.2+dfsg-1
   Version table:
  0.8.2+dfsg-1 501
 501 http://deb.debian.org/debian testing/main amd64 Packages
  50 http://deb.debian.org/debian unstable/main amd64 Packages

$ $ dput freebayes_1.3.6-1_source.changes
Uploading freebayes using ftp to ftp-master (host: ftp.upload.debian.org; 
directory: /pub/UploadQueue/)
running allowed-distribution: check whether a local profile permits uploads to 
the target distribution
running protected-distribution: warn before uploading to distributions where a 
special policy applies
running checksum: verify checksums before uploading
running suite-mismatch: check the target distribution for common errors
running gpg: check GnuPG signatures before the upload
  signfile dsc freebayes_1.3.6-1.dsc ti...@debian.org

  fixup_buildinfo freebayes_1.3.6-1.dsc freebayes_1.3.6-1_amd64.buildinfo
  signfile buildinfo freebayes_1.3.6-1_amd64.buildinfo ti...@debian.org

  fixup_changes dsc freebayes_1.3.6-1.dsc freebayes_1.3.6-1_source.changes
  fixup_changes buildinfo freebayes_1.3.6-1_amd64.buildinfo 
freebayes_1.3.6-1_source.changes
  signfile changes freebayes_1.3.6-1_source.changes ti...@debian.org

Successfully signed dsc, buildinfo, changes files
Uploading freebayes_1.3.6-1.dsc
Uploading freebayes_1.3.6.orig.tar.gz
Uploading freebayes_1.3.6-1.debian.tar.xz
Uploading freebayes_1.3.6-1_amd64.buildinfo
Uploading freebayes_1.3.6-1_source.changes


So sambamba seems to be the latest version in testing and freebayes
should follow soon.

Thanks a lot for pinging here which is really welcome

Andreas.

Bug#1003968: [Pkg-electronics-devel] Bug#1003968: fpga-icestorm: icetime looking in wrong directory for chipdb files

[Steffen Möller]

Uploaded.

On 18.01.22 20:41, Daniel Gröber wrote:

Hi Scott,

Thanks, for the report.

On Tue, Jan 18, 2022 at 05:50:58PM +, Scott Ashcroft via 
Pkg-electronics-devel wrote:

icetime seems to be looking in /usr/local/share/icebox and
/usr/bin/../share/icebox for chipdb files instead of /usr/share/fpga-
icestorm/chipdb.

Looks like we dropped a patch that had a fix for this lumped in.

I've pushed a fix to salsa[1] and I'm pinging Steffen to sponsor the
upload.

[1]: 
https://salsa.debian.org/electronics-team/fpga-icestorm/-/commit/65390136afafd321515c76cb7fb725ab4f02d151

--Daniel

Re: alphafold Debian packaging ?

[Steffen Möller]

On 12.01.22 17:24, M. Zhou wrote:

Even more complicated is the underlying software dependency tree.

alphafold depends on dm-haiku, jax, tensorflow.
dm-haiku depends on jax.
jax depends on XLA from tensorflow.
tensorflow still in NEW.

Long way to go. Mhhh.


That is what I had thought, too. On

https://docs.google.com/spreadsheets/d/1tApLhVqxRZ2VOuMH_aPUgFENQJfbLlB_PFH_Ah_q7hM/edit#gid=1840067013

I once collected the immediate dependencies and can confirm that it
there is quite a bit of homework out there. If the only purpose is to
bring AlphaFold to Debian then I suggest not to do it. The benefit may
be to improve the software basis of Debian at large with it. But also, I
can do something good elsewhere and all these releases update so
quickly, to me it stopped being fun.


What's also complicated is the GPU support. Currently the only
working modern deep learning framework in our archive is pytorch,
which is only compiled with cpu support.

pytorch-cuda requires cudnn. I gave up cudnn packaging a few
times and I eventually realized that I dislike working on
nvidia stuff even if I have to use it.

pytorch-rocm is a good way to go. As you can see on debian-ai@
people are still working hard to get ROCm into debian.

Intel GPU support is too new to evaluate.


To have ROCm as a source package with Debian will be good for everyone.
IMHO this may actually dwarf the benefit of having AlphaFold with us.
So, yes, if something like AlphaFold is something that we need as a
carrot to improve our Java infrastructure, then I am all up for it.

The prospect to have a community-regenerated knowledge base for
AlphaFold is also very tempting.

Steffen


On Wed, 2022-01-12 at 16:54 +0100, Gard Spreemann wrote:

Andrius Merkys  writes:


On 2022-01-12 17:34, Gard Spreemann wrote:

And their code repository is Apache. Or did you find the actual
pretrained models somewhere under CC-BY-NC?

Interesting. Maybe I am looking at some other source. Am I right to
assume we are talking about [3]? If so, it says that the parameters
are
CC-BY-NC here: [4].

[3] https://github.com/deepmind/alphafold
[4] https://github.com/deepmind/alphafold#model-parameters

Interesting indeed! So we have:

  – Training data: A plethora of different licenses.

  – Code: Apache

  – Trained model: CC-BY-NC-4.0

  – Output of said trained model: CC-BY-4.0 [5]

Nightmarish!

[5] See under "license and attributions" on https://alphafold.com


  -- Gard

Re: alphafold Debian packaging ?

[Steffen Möller]

I am only aware of someone who got it to run on Debian :)  I agree that
it would be nice to have. Very nice.

Cheers,
Steffen

On 11.01.22 14:47, PICCA Frederic-Emmanuel wrote:

Hello guyes,

I would like to know if you are aware of an effort to package alphafold[1] on 
Debian ?

Cheers

Frederic

[1] https://alphafold.com/

Re: Contributing to yosys maintenance

[Steffen Möller]

Hi Daniel,

On 30.12.21 22:38, Daniel Gröber wrote:

Hi Anton and Steffen,

On Thu, Dec 30, 2021 at 10:11:26PM +0100, Anton Gladky wrote:

I have just added you to the group. Welcome on board!
You can commit directly in git, but please coordinate
your work with an active uploaders of this package, if
there are any.

Awesome, thanks for the quick response.

So I guess I'll at least push new upstream release into the upstream branch
and then open an MR for the rests of the changes while I wait for a
response. That shouldn't step on anyone's toes, right?


äh - no, not yet. Wait for Ruben's reply. The integrity of the upstream
orig.tar.gz is a crucial part. You could be evil and introduce something
that then Ruben signs? Nope.

Also, yosys (like most packages on salsa) comes with a pristine-tar
branch. Please look at git-buildpackage and, preferably, get a mentor
for your first upload to salsa. I am not sure about any policy document
for science, but for med there is
https://med-team.pages.debian.net/policy/ which should also apply to
salsa (just s/med/science/g) - please read that prior to uploading to salsa.




Please also look at the electronics team.

I'm also planning on packaging the ghdl yosys integration so I'll likely
have to :)


Very nice. I happen to be behind
https://github.com/ghdl/ghdl-yosys-plugin/issues/162, so your work is
most welcome, indeed. Feel free drop a note in that issue that you
surfaced to address this.

Best,
Steffen

Re: Contributing to yosys maintenance

[Steffen Möller]

Hi Daniel,

On 30.12.21 21:08, Daniel Gröber wrote:

I'm working on packaging the latest version of yosys and related packages
for Debian.


Nice. I was not aware of the many new releases - clifford.at seems down
and https://github.com/YosysHQ/yosys is the new home?


What's the procedure in debian-science for being added to the salsa org/git

It is already on salsa, albeit not in
https://salsa.debian.org/electronics-team but in
https://salsa.debian.org/science-team/yosys

repo on salsa[1] or should I just post MRs/patches to the BTS?

Please contact the current maintainer, i.e. Ruben. He will either
immediately update the package or direct you with the next steps to
take. Should he not reply then I am dead confident that he will
appreciate a team upload, feel free to PM me, then. Please also look at
the electronics team.

[1]: Just in case, my username there is dxld-guest.


Welcome.

Best,
Steffen

Re: RF peer review: r-other-ibi-disgenet2r freshly injected into salsa

[Steffen Möller]

On 22.12.21 14:32, Andreas Tille wrote:

Hi Steffen,

Am Wed, Dec 22, 2021 at 01:47:35PM +0100 schrieb Steffen Möller:

https://salsa.debian.org/r-pkg-team/r-other-ibi-disgenet2r just arrived.
It needs r-cran-sparql that Andreas kindly uploaded yesterday.

I've added a watch file, renamed to what dh-make-R would have named

Ok, I have just changed the salsa path accordingly to
https://salsa.debian.org/r-pkg-team/r-other-disgenet2r/ .

the package and uploaded.


Great!

Best,
Steffen

RF peer review: r-other-ibi-disgenet2r freshly injected into salsa

[Steffen Möller]

Hello again,

https://salsa.debian.org/r-pkg-team/r-other-ibi-disgenet2r just arrived.
It needs r-cran-sparql that Andreas kindly uploaded yesterday.

Many thanks and regards,

Steffen

RFS: r-cran-sparql - dependency for a more typical Med package

[Steffen Möller]

Dear Andreas, dear Nilesh, dear all,

I would appreciate some extra scrutiny for

https://salsa.debian.org/r-pkg-team/r-cran-sparql

Please kindly upload if you consider this "ready-enough" or pass the
token back to me, please.

This https://www.disgenet.org/disgenet2r is why I (and Debian at large,
you would have thought that we long feature a SPARQL package) am after it.

Many thanks!
Steffen

Re: Moving python-bioblend to med-team?

[Steffen Möller]

Please go ahead - thank you both. If there is any particular action for
me to perform then please ping me, preferably with a respective tag in
the subject line.

Best
Steffen

On 19.12.21 12:05, Andreas Tille wrote:

Hi Nilesh and Steffen,

Am Sun, Dec 19, 2021 at 01:36:50PM +0530 schrieb Nilesh Patra:

python-bioblend is maintained on DPT, however it seems to be made for the
purpose of interacting with galaxy project's APIs.
Hence I was wondering if it is of our interest?

I'm absolutely in favour of this.


It has also not seen uploads for a long time, and I was wondering if it makes 
sense to
move it here.

I wanted to fix a problem on this package as well.

Please go for it - usually Steffen agrees to those kind of moves
and I think he is currently very busy.

Kind regards

   Andreas.

r-bioc-txdb.hsapiens.ucsc.hg19.knowngene on salsa Re: please kindly review: r-bioc-fishpond -- Fishpond: differential transcript and gene expression with

[Steffen Möller]

Hi all,

On 10.12.21 17:46, Andreas Tille wrote:

Am Fri, Dec 10, 2021 at 11:57:49AM +0100 schrieb Steffen Möller:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001436

for r-bioc-txdb.hsapiens.ucsc.hg19.knowngene and when I wanted to inject
it found that it is already existing at

https://salsa.debian.org/r-pkg-team/r-bioc-txdb.hsapiens.ucsc.hg19.knowngene

in a "debian folder only" stage and 4 years old.

You do not mind if I somehow adopt that?

I don't mind at all.  I remember that I used debian/ dir only due to the
size of the source which might have been an issue at the time of
creation.  Technically I wonder whether it makes sense to remove the
repository first and create it from scratch via
prepare_missing_cran_package.  It could perfectly be the case that it is
the more straight approach to get a sensible package - but I'll leave
this decision to you.


I did not have the privileges to remove the previous
r-bioc-txdb.hsapiens.ucsc.hg19.knowngene repository but could rename it,
so that is what I have done and then injected the new one.

Best,
Steffen

Re: please kindly review: r-bioc-fishpond -- Fishpond: differential transcript and gene expression with

[Steffen Möller]

On 10.12.21 07:15, Andreas Tille wrote:

Am Fri, Dec 10, 2021 at 03:07:51AM +0530 schrieb Nilesh Patra:

On Thu, Dec 09, 2021 at 08:32:46PM +0100, Steffen Möller wrote:

Hello this goes out to Andreas in particular,

I hope you do not mind me taking over (have a few spare cycles)

I definitely encourage everybody to take over anything that was
addressed to me in particular! ;-)


Same here :) And I have another one . I just prepared this ITP

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001436

for r-bioc-txdb.hsapiens.ucsc.hg19.knowngene and when I wanted to inject
it found that it is already existing at

https://salsa.debian.org/r-pkg-team/r-bioc-txdb.hsapiens.ucsc.hg19.knowngene

in a "debian folder only" stage and 4 years old.

You do not mind if I somehow adopt that?

Best,
Steffen



Uploaded after a few changes.

Thanks a lot

 Andreas.

please kindly review: r-bioc-fishpond -- Fishpond: differential transcript and gene expression with

[Steffen Möller]

Hello this goes out to Andreas in particular,

I completed the packaging of r-bioc-fishpond earlier this afternoon.
This is a suggestion for r-bioc-tximport with some other interesting
reverse-dependencies - and tximport makes problems with my rabbit data
that I yet do not understand.

The package does not seem to be overly complicated, builds in
cowbuilder.  I just injected everything to

https://salsa.debian.org/r-pkg-team/r-bioc-fishpond

Many thanks
Steffen



 Forwarded Message 
Subject:ITP: r-bioc-fishpond -- Fishpond: differential transcript and
gene expression with
Date:   Thu, 09 Dec 2021 15:29:05 +0100
From:   Steffen Moeller 
To: Debian Bug Tracking System 



Package: wnpp
Severity: wishlist

Subject: ITP: r-bioc-fishpond -- Fishpond: differential transcript and
gene expression with
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name : r-bioc-fishpond
Version : 2.0.1+ds
Upstream Author : Anzi Zhu,
* URL : https://bioconductor.org/packages/fishpond/
* License : GPL-2
Programming Lang: GNU R
Description : Fishpond: differential transcript and gene expression with
inferential replicates
Fishpond contains methods for differential transcript
and gene expression analysis of RNA-seq data using inferential
replicates for uncertainty of abundance quantification,
as generated by Gibbs sampling or bootstrap sampling. Also the
package contains utilities for working with Salmon and Alevin
quantification files.

Remark: This package is maintained by Debian R Packages Maintainers at
https://salsa.debian.org/r-pkg-team/r-bioc-fishpond

Re: [Emc-developers] Status of Weblate translations

[Steffen Möller]

On 09.12.21 10:52, Petter Reinholdtsen wrote:

[Steffen Möller]

I think the format-adjustments between French and English are good to
go. We should just not both edit the English in parallel. My French is
catastrophique but I can read it, so we could have a joint shot at the
first few *_fr.adoc files and so how they go. @pere, instructions from
your side?

Not quite sure I understand what kind of instructions you are looking
for.


Wasn't sure what to ask, either :) Trying a bit harder now:

 * What branch should silopolis start with, i.e. preferably the one
that features the changes to the English texts?



The first step for the French documentation is to bring the file
names in line with the English originals, which
https://github.com/silopolis/linuxcnc/ > branch translate-po4a
started on, but I am not sure if it is complete.

Ah, nice, yes. And this is then something I would like to see committed
back early on. @silopolis?

Next, one ned to
update the structure to make sure docs/po/migrate-translation can
extract as many translations as possible to a fr.po file.

Ok. This is what I just did for the _es files and can help @silopolis to
get started.

Once
migrate-translation we can kep the PO file and drop the translated
asciidoc files, and start generating translated asciidoc files using the
English original and the PO files.

As no-one have shown up to handle the Chinese asciidoc translation, I
believe we just will have drop those and start the PO file from scratch
there.


有没有人愿意帮忙?

This is from https://www.deepl.com . Once I have some more time again,
let us talk to the DeepL folks and choose a language many of us can
passively understand that we do not feature, yet. Like - Italian. And
then we auto-fill the translations to see how good or bad this goes.
Weblate might also benefit from a flag "auto-translated".


And I already had addressed a few. Liked it. Some typos in the English
were already fixed in master when I was about to prepare a PR. I liked
that I can put comments about the original into weblate. Who reads
them?  I am asking since it somehow feels wrong to go through a
regular PR for small typos. Someone should collect them and then
jointly push these to master.

Anyone looking at translation comments on Weblate will read them.  No
idea who that is. :)


Ah, ok. Still, with all those missing (or not missing?) full stops in
the English I wish we would have someone who chases this up on a regular
basis instead of each of us preparing small time-sucking pull requests
for a triviality.

And, I think I would want to see screen shots because of the line breaks
and the question what should be abbreviated and what not.


These are the program translation updates currently waiting in Weblate
  for someone to merge them back into master (from 'git diff
  origin/master weblate/master | diffstat'):

  de.po |  185
  es.po |   17
  fr.po |   20
  gmoccapy/de.po|  164
  gmoccapy/es.po|   22
  gmoccapy/fr.po|   49
  gmoccapy/hu.po|   45
  gmoccapy/nb_NO.po | 1731 +
  gmoccapy/pl.po|   54
  gmoccapy/sr.po|   43
  gmoccapy/zh_CN.po |   11
  it.po |   35
  ja.po |   12
  nb_NO.po  |18379 
+++
  pl.po |   35
  zh_CN.po  |   19
  16 files changed, 20473 insertions(+), 348 deletions(-)


Norway did an impressive job here.

Steffen



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

Re: [Emc-developers] Status of Weblate translations

[Steffen Möller]

Hello,

On 08.12.21 20:19, Jérémie Tarot wrote:

Hello Hans,

Le mar. 7 déc. 2021 à 20:31, Hans Unzner  a écrit :

...

@smoe has made an amazing work on es translation as well as sanitizing en
source files.

Only were the the po4a script to automated the sync to Spanish bailed out.

I'm lagging way behind with fr wich puts this work somehow on
hold untill french files please the migration script.
Meanwhile...


I think the format-adjustments between French and English are good to
go. We should just not both edit the English in parallel. My French is
catastrophique but I can read it, so we could have a joint shot at the
first few *_fr.adoc files and so how they go. @pere, instructions from
your side?


I am wondering how up-to-date the translation of

https://hosted.weblate.org/projects/linuxcnc/ is and how it is
syncronized with the GitHub repo.


This is a fresh setup, straight from master, we put together a few days ago
with @pere!


And I already had addressed a few. Liked it. Some typos in the English
were already fixed in master when I was about to prepare a PR. I liked
that I can put comments about the original into weblate. Who reads them?
I am asking since it somehow feels wrong to go through a regular PR for
small typos. Someone should collect them and then jointly push these to
master.

Best,
Steffen




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

[Emc-developers] missing anyone in debian/copyright? Re: linuxcnc_2.9.0~pre0+git20211108.cf14c89a9-1_amd64.changes REJECTED

[Steffen Möller]

Hello again,

I personally think we have fixed what needed to be fixed in response to
the FTPmasters. All requests for changes referred to the
debian/copyright file. Typically, nobody truly cares about the details
of that file as long as the files are all redistributable. But I find
this a bit to be a exceptional since while there is a docs/AUTHORS there
is no such AUTHORS file for LinuxCNC at large. This debian/copyright
comes close to it and someone may think that this file is how the
project values someone's contributions. I promise that I was only taking
all the names I found in the source tree and listed them - very technical.

To avoid bad vibes, I thought to ask on this list to point me to the
more obvious omissions that I may have made. @Andy was already very
helpful, many thanks to him. Please rest assured that there is no rush.
This is nothing finite. It is just to get things going.

Best,

Steffen


On 15.11.21 14:57, Steffen Möller wrote:

Hello,

I thought I should possibly comment on the rejection email for those who
read this the first time. We can fix this and reupload. It is just this
first version of the packaging that is rejected, not the software per se.

On 15.11.21 12:00, Thorsten Alteholz wrote:

Hi Sebastian,

unfortunately I have to reject your package.

Please mention all files licensed under a BSD license (e.g.
linuxcnc/lib/python/qtvcp/widgets/nurbs_editor.py and some other
python files) in your debian/coypright.

The copyright-check is at the very core of what FTPmasters do prior to
letting any new software in. And, frankly, I could have done a much
better job in my preparation of the upload to check this and not blindly
follow that "all GPL-2". Apologies and thanks to FTPmaster Thorsten for
what now effectively is his contribution to the packaging.

Please also mention all files under GPL-3+ in your debian/copyright.

There are more files available under GPL-2 as you wrote in your
debian/copyright (e.g. linuxcnc/src/hal/components/*). Please mention
all of them in your debian/copyright.

Please also mention all files under the Boost Software License in
your debian/copyright.

Please also mention all files under a CC-3 license in your
debian/copyright.

I will do all the above.

Please remove all files licensed under CC-2.5 license from your
source tarball, as this license is not compatible with DFSG.

The CC-2.5 license is something you (Sebastian?) please have a look at.
Removal, reimplementation or relicensing by the original authors are our
options.

As the file headers contain information about the different copyright
holder, please mention them in your debian/copyright. Stating only
"the LinuxCNC developers" is not enough.

That is something I did not want to address myself to avoid negative
vibes among those contributors who are not explicitly mentioned. I
suggest to keep the current wording and add all the names underneath
that appear in the source tree.


Thanks!
  Thorsten


Thank you!

Steffen





===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.



___
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
Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: LinuxCNC
Upstream-Contact: emc-developers@lists.sourceforge.net
Source: https://github.com/linuxcnc/linuxcnc
Comment: 
 Much of LinuxCNC is derived from EMC1, a work of Fred Proctor, Tom Kramer,
 Will Shackleford, and others.  That work was originally released into
 the public domain.  It was used as the basis of LinuxCNC, but received
 extensive modifications.  LinuxCNC is NOT public domain.  Anyone wishing
 to use the public domain code in a way that is not compatible with the
 (L)GPL must locate the original EMC1 code - they may NOT use LinuxCNC.

Files: *
Copyright: 2004-2021 The LinuxCNC Developers and notably
 .
 EMC: Derived from a work by Fred Proctor & Will Shackleford
   2004-2014 Jeff Epler 
   2004-2019 Robert W. Ellenberg 
2005 proctor
2006 Alex Joni 
   2006-2009 Eric H. Johnson
   2006-2013 Chris Radek 
   2005-2007 Peter G. Vavaroutsos 
2008 Chris Radek 
   2009-2012 Pavel Shramov ,
   2009-2014 Chris Morley 
   2011-2013 Michael Haberler 
   2011-2016 Sebastian Kuzminsky 
   2012-2017 Norbert Schechner 
   2013-2021 Dewey Garrett 
2015 John Thornton 
2016 Andrew Kyrychenko with derivative work from R. Brian 
Register on the Hexapod
2016 Rudy du Preez 

Bug#999632: r-bioc-isoformswitchanalyzer FTBFS: ERROR: dependencies ‘DRIMSeq’, ‘tximeta’ are not available

[Steffen Möller]

On 14.11.21 08:47, Andreas Tille wrote:

Control: blocked -1 by 995252

Hi Steffen


ERROR: dependencies ‘DRIMSeq’, ‘tximeta’ are not available for package 
‘IsoformSwitchAnalyzeR’

r-bioc-tximeta is in Debian and just needs to be mentioned in
Build-Depends.  However, Git seems not to be up to date so please push.

Seems like we have a race condition. I dumped my local one and
routine-updated what was in salsa.


What is the status of r-bioc-drimseq?  I have not found it in new neither
did I found any mentioning it on the maintainers list.


g...@salsa.debian.org:r-pkg-team/r-bioc-drimseq.git

Seems like I had not uploaded it. Just upgraded it to a newer version
and sent it away.


PS: Please use a chroot when building your packages.


I typically do. For the ones with build dependencies in the NEW queue I
once had my own local repository but at some point stopped doing that.

Steffen

Bug#999632: r-bioc-isoformswitchanalyzer FTBFS: ERROR: dependencies ‘DRIMSeq’, ‘tximeta’ are not available

[Steffen Möller]

On 14.11.21 08:47, Andreas Tille wrote:

Control: blocked -1 by 995252

Hi Steffen


ERROR: dependencies ‘DRIMSeq’, ‘tximeta’ are not available for package 
‘IsoformSwitchAnalyzeR’

r-bioc-tximeta is in Debian and just needs to be mentioned in
Build-Depends.  However, Git seems not to be up to date so please push.

Seems like we have a race condition. I dumped my local one and
routine-updated what was in salsa.


What is the status of r-bioc-drimseq?  I have not found it in new neither
did I found any mentioning it on the maintainers list.


g...@salsa.debian.org:r-pkg-team/r-bioc-drimseq.git

Seems like I had not uploaded it. Just upgraded it to a newer version
and sent it away.


PS: Please use a chroot when building your packages.


I typically do. For the ones with build dependencies in the NEW queue I
once had my own local repository but at some point stopped doing that.

Steffen

Re: Debian Med video conference tomorrow, Wednesday 2021-11-17 18:00 UTC

[Steffen Möller]

Heya,

On 16.11.21 19:58, Nilesh Patra wrote:

For those who are interested in hot topics we want to tackle, here
are some action items to be done:

   - Coordinating work for bioconductor transition (to be started soon)


Nice!

I am traveling and cannot join you. From my side I can only report that
I keep investigating the JavaScript headaches that PiGx RNAseq is
causing in its report. Running with guix, everthing went just smoothly.
That is so annoying. The vega JS library seems to be something else to
cause problems for multiple packages of the Qiime suite, so the JS
situation is something I likely "want" to investigate a bit further.

Enjoy!

Best,
Steffen

Re: [Emc-developers] linuxcnc_2.9.0~pre0+git20211108.cf14c89a9-1_amd64.changes REJECTED

[Steffen Möller]

Hello,

I thought I should possibly comment on the rejection email for those who
read this the first time. We can fix this and reupload. It is just this
first version of the packaging that is rejected, not the software per se.

On 15.11.21 12:00, Thorsten Alteholz wrote:

Hi Sebastian,

unfortunately I have to reject your package.

Please mention all files licensed under a BSD license (e.g. 
linuxcnc/lib/python/qtvcp/widgets/nurbs_editor.py and some other python files) 
in your debian/coypright.

The copyright-check is at the very core of what FTPmasters do prior to
letting any new software in. And, frankly, I could have done a much
better job in my preparation of the upload to check this and not blindly
follow that "all GPL-2". Apologies and thanks to FTPmaster Thorsten for
what now effectively is his contribution to the packaging.

Please also mention all files under GPL-3+ in your debian/copyright.

There are more files available under GPL-2 as you wrote in your 
debian/copyright (e.g. linuxcnc/src/hal/components/*). Please mention all of 
them in your debian/copyright.

Please also mention all files under the Boost Software License in your 
debian/copyright.

Please also mention all files under a CC-3 license in your debian/copyright.

I will do all the above.

Please remove all files licensed under CC-2.5 license from your source tarball, 
as this license is not compatible with DFSG.

The CC-2.5 license is something you (Sebastian?) please have a look at.
Removal, reimplementation or relicensing by the original authors are our
options.

As the file headers contain information about the different copyright holder, please 
mention them in your debian/copyright. Stating only "the LinuxCNC developers" 
is not enough.

That is something I did not want to address myself to avoid negative
vibes among those contributors who are not explicitly mentioned. I
suggest to keep the current wording and add all the names underneath
that appear in the source tree.


Thanks!
  Thorsten


Thank you!

Steffen





===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.



___
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.9.0~pre0+git20211108.cf14c89a9-1_amd64.changes REJECTED

[Steffen Möller]

Hello,

I thought I should possibly comment on the rejection email for those who
read this the first time. We can fix this and reupload. It is just this
first version of the packaging that is rejected, not the software per se.

On 15.11.21 12:00, Thorsten Alteholz wrote:

Hi Sebastian,

unfortunately I have to reject your package.

Please mention all files licensed under a BSD license (e.g. 
linuxcnc/lib/python/qtvcp/widgets/nurbs_editor.py and some other python files) 
in your debian/coypright.

The copyright-check is at the very core of what FTPmasters do prior to
letting any new software in. And, frankly, I could have done a much
better job in my preparation of the upload to check this and not blindly
follow that "all GPL-2". Apologies and thanks to FTPmaster Thorsten for
what now effectively is his contribution to the packaging.

Please also mention all files under GPL-3+ in your debian/copyright.

There are more files available under GPL-2 as you wrote in your 
debian/copyright (e.g. linuxcnc/src/hal/components/*). Please mention all of 
them in your debian/copyright.

Please also mention all files under the Boost Software License in your 
debian/copyright.

Please also mention all files under a CC-3 license in your debian/copyright.

I will do all the above.

Please remove all files licensed under CC-2.5 license from your source tarball, 
as this license is not compatible with DFSG.

The CC-2.5 license is something you (Sebastian?) please have a look at.
Removal, reimplementation or relicensing by the original authors are our
options.

As the file headers contain information about the different copyright holder, please 
mention them in your debian/copyright. Stating only "the LinuxCNC developers" 
is not enough.

That is something I did not want to address myself to avoid negative
vibes among those contributors who are not explicitly mentioned. I
suggest to keep the current wording and add all the names underneath
that appear in the source tree.


Thanks!
  Thorsten


Thank you!

Steffen





===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.



___
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.9.0~pre0+git20211108.cf14c89a9-1_amd64.changes REJECTED

[Steffen Möller]

Hello,

I thought I should possibly comment on the rejection email for those who
read this the first time. We can fix this and reupload. It is just this
first version of the packaging that is rejected, not the software per se.

On 15.11.21 12:00, Thorsten Alteholz wrote:

Hi Sebastian,

unfortunately I have to reject your package.

Please mention all files licensed under a BSD license (e.g. 
linuxcnc/lib/python/qtvcp/widgets/nurbs_editor.py and some other python files) 
in your debian/coypright.

The copyright-check is at the very core of what FTPmasters do prior to
letting any new software in. And, frankly, I could have done a much
better job in my preparation of the upload to check this and not blindly
follow that "all GPL-2". Apologies and thanks to FTPmaster Thorsten for
what now effectively is his contribution to the packaging.

Please also mention all files under GPL-3+ in your debian/copyright.

There are more files available under GPL-2 as you wrote in your 
debian/copyright (e.g. linuxcnc/src/hal/components/*). Please mention all of 
them in your debian/copyright.

Please also mention all files under the Boost Software License in your 
debian/copyright.

Please also mention all files under a CC-3 license in your debian/copyright.

I will do all the above.

Please remove all files licensed under CC-2.5 license from your source tarball, 
as this license is not compatible with DFSG.

The CC-2.5 license is something you (Sebastian?) please have a look at.
Removal, reimplementation or relicensing by the original authors are our
options.

As the file headers contain information about the different copyright holder, please 
mention them in your debian/copyright. Stating only "the LinuxCNC developers" 
is not enough.

That is something I did not want to address myself to avoid negative
vibes among those contributors who are not explicitly mentioned. I
suggest to keep the current wording and add all the names underneath
that appear in the source tree.


Thanks!
  Thorsten


Thank you!

Steffen





===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.



___
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] RFC: doc translations

[Steffen Möller]

Good evening also to you, Jérémie!

I think I can quickly top-post and thank you for your very encouraging
reply. This reads all (surprisingly) nice and encouraging.

Steffen

On 14.11.21 21:23, Jérémie Tarot wrote:

Good evening Steffen,

Le dim. 14 nov. 2021 à 15:51, Steffen Möller  a
écrit :


You can find it at https://crowdin.com/project/linuxcnc

I had a look. Somewhat unfortunate but maybe a good test case is that
the master branch has the asciidoc .txt files renamed to .adoc files.
The motivation was the github allows for a preview of asciidoc, even
integrating the images. How does the communication happen between that
website and the LinuxCNC github? All manual, right?


Crowdin has a GH integration which pulls and push from and to selected
branch(es).




Folks there kindly offered a free enterprise account for the project.

As a Debian developer this is refreshing to read. Their legalese is
quite extensive, though. Personally I was not convinced. My main concern
is the apparent lack of synchronicity between the reference
documentation in github (which I presume is meant to remain the
reference, right?) and its translations. But these .po files from the
po4a project that Petter suggests I have not yet seen applied on larger
texts, so, I cannot judge, it is just the impressions I get from what I
think to know/read.


As a Debian advocate and professional user for 20 years, those are all
maters I put at the top of my priorities!

GH integration, standard formats support, and "openness" of the platform
made it look clean enough to my Free eyes, even if I'd have preferred a
self hostable FOSS solution.

Also had a look at weblate but it didn't seem a good enough option, feature
and UX wise, as I remember it. Restructuration and all the work done may
also make weblate more suitable than it was... Note that nothing prevents
to migrate to something else later! Ain't that the beauty of open
standards?! 殺

Crowdin also shines with great features and UI for translators which I feel
is important to bring comrades from everywhere to the table...


All that combined I am not too much of a fan to outsource the

translation to an external service if that is not pulling from github.
Frankly, github should have some appropriate translation services
included.


I believe that is just what Crowdin provides, with all the workflow and
collaborative feature you'd expect, plus glossaries, screenshots
management, etc.

Any of yall interested please create yourself an account there, join the
project and give it a short discovery round. I'd love to get your hands on
opinions. Admin privileges will of course be shared so you can test both
front and back office.


For now, the in-file translations with the ":lang:" tags and

the .po solution I find superior.


Actually, Crowdin gives all its power with gettexted project (and other
translation formats), but also provides with "raw" text files.
Plus, folks there are easy to reach, 24h a day, and willing to improve
their native support for doc formats like rst and adoc.

I'll do my best to refresh my mind and memory around all this in the next
couple of days as it's been too long since I put this aside. Meanwhile,
please give crowdin a go and throw all the questions that come to your
sharp brains.


TY
J

___
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] RFC: doc translations

[Steffen Möller]

Hi Jérémie,

On 14.11.21 11:32, Jérémie Tarot wrote:

Hi Sebastian and all,

Le lun. 8 nov. 2021 à 20:41, Sebastian Kuzminsky  a écrit :


Hello LinuxCNC people, there's a possible change brewing that I'd like
to ask for your feedback on.

The translations of our documentation into non-English languages has
been handled in an unusual and cumbersome way, and a new developer has
suggested a plan to modernize and streamline things.

...

Do you have any concerns, input, or comments on this proposal?

Would you be willing to verify and update the translations into your
languages?

What can we software people do to help make this task easier?


Feels like you read my mind!

Actually, I began setting up a continuous translation infrastructure a few
month ago but structure, format and state of documentation made me start
with QtPyVCP for a smaller endeavour... But finally got sidetracked, again


You can find it at https://crowdin.com/project/linuxcnc


I had a look. Somewhat unfortunate but maybe a good test case is that
the master branch has the asciidoc .txt files renamed to .adoc files.
The motivation was the github allows for a preview of asciidoc, even
integrating the images. How does the communication happen between that
website and the LinuxCNC github? All manual, right?


Folks there kindly offered a free enterprise account for the project.


As a Debian developer this is refreshing to read. Their legalese is
quite extensive, though. Personally I was not convinced. My main concern
is the apparent lack of synchronicity between the reference
documentation in github (which I presume is meant to remain the
reference, right?) and its translations. But these .po files from the
po4a project that Petter suggests I have not yet seen applied on larger
texts, so, I cannot judge, it is just the impressions I get from what I
think to know/read.


Hope all the hard work done lately on sanitizing documentation are seeds
planted for a new era...


:) For me personally this is definitely true. I am still in this
honeymoon phase of it all, and happily escape from the real world when
reading something about LinuxCNC, no idea about how long this will last.
I am low-dosing it, though.

It may sound a bit weird, but the documentation I am confident has
highest chances to attract larger audiences and with it more
contributors, also to other languages. Since the translators are
typically the ones who read the original documentation with quite some
scrutiny and may have some notable writing (as in
"thought-linearisation") skills in general, the translators need an
opportunity to change or at least comment on the original wording and
add references or explain abbreviations or to just point out what needs
to be improved. Also, I sense that if translators interact with github
then they will feel more like being a part of the project, too.

All that combined I am not too much of a fan to outsource the
translation to an external service if that is not pulling from github.
Frankly, github should have some appropriate translation services
included. For now, the in-file translations with the ":lang:" tags and
the .po solution I find superior.

Best,
Steffen




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

Re: [Emc-developers] RFC: doc translations

[Steffen Möller]

On 10.11.21 00:29, andy pugh wrote:

On Tue, 9 Nov 2021 at 23:19, Steffen Möller  wrote:


Maybe Andy could outline how his system
differs from what po4a would come up with.

The thing I was trying to address is that the HAL components that are
derived from .comp files are self-documenting.

You know better than me if adapting what po4a is doing the .comp files
has any advantages. I like what you have done.

So this source file:
https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/components/abs.comp

Creates this manpage:
http://linuxcnc.org/docs/2.8/html/man/man9/abs.9.html


Looks good. Since you have this dense integration of documentation and
source - with it is possible to add a link to the generated
documentation that points to the file on github from which it was
generated - but is everyone as exited about that prospect as I am? This
way a larger audience would be introduced to the source code and the
last ambiguities about what the function is doing would go away.

Sidenote - this "provenance" (have every piece of data explain how it
was generated) may be of interest to add to all parts of the documentation.

Best,
Steffen





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

Re: [Emc-developers] RFC: doc translations

[Steffen Möller]

Hello,

I have looked at https://techbase.kde.org/Localization but failed to
take too much from their site. Maybe Andy could outline how his system
differs from what po4a would come up with.

The difficulty I see is that the synchronisation between the original
and its translations is not supported. And it may be preferable to have
one translation system for everything.

Also, I am with J.M. that the roles of developers and translators should
possibly be kept apart a bit more. This way, it is easy to tell that a
translator with a quick introduction to git will not unintentionally
change something functional.


Best,
Steffen

On 09.11.21 22:37, J.M. Garcia wrote:

Hi, Andy.
In my opinion, this solution has an drawback: the developer must take the
role of translator. And for several languages. I think it is potentially
dangerous, prone to errors and overload development work.
It's just my opinion.

El mar, 9 nov 2021 a las 20:54, andy pugh () escribió:


On Tue, 9 Nov 2021 at 19:21, J.M. Garcia  wrote:


worked last year I found many problems that were difficult to solve.
Example: the documentation of modules generated with halcompile.

I did manage to come up with a partial solution to this, which might
be practical in conjunction with gettext. Or might be totally
superseded by gettext.


https://github.com/LinuxCNC/linuxcnc/blob/andypugh/multilingual_comp/src/hal/components/abs.comp

Is an example of how a .comp file with multilingual documentation could
look.

(note that the language tags are _deliberately_ inconsistently
formatted for testing.)

It might be a better plan to hack halcompile to automatically
gettext-ify the docs, 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

LinuxCNC in New Queue - upstream as an alternative to teams on salsa

[Steffen Möller]

Hello,

LinuxCNC.org has its own Debian repository since a couple of decades.
 and I have worked as DDs with upstream over the past few weeks
to eliminate a series of lintian errors and sidetracked ourselves here
and there, but yesterday LinuxCNC arrived in the New Queue. Its runtime
(suggested) dependency "mesaflash" was already uploaded a month earlier.
Two developers from upstream agreed to become Debian Maintainers.

What I am fond of is that we have so far resisted to bring the
Debianisation to salsa. Everything went through upstream's github
repository. From my side this was motivated as an expression of respect
for the long history that Debian has with LinuxCNC. It was important to
me not to split/disturb their community because of Debian. Debian
developers should just help and support.

So, I think this has worked. If you happen to be close to robotics
and/or CNC machining, or close to those who are near, please get in
touch with them or .  prepared for the introduction of
po4a to help with their localisation that certainly can use more
eyeballs and help orchestrating translators with less ITish backgrounds.

Best,
Steffen

Re: [Emc-developers] RFC: doc translations

[Steffen Möller]

Hello,

On 08.11.21 20:40, Sebastian Kuzminsky wrote:

Hello LinuxCNC people, there's a possible change brewing that I'd like
to ask for your feedback on.

The translations of our documentation into non-English languages has
been handled in an unusual and cumbersome way, and a new developer has
suggested a plan to modernize and streamline things.


I thought I should chime in, to help keeping the momentum - and the
other DD, Petter, was the one who came up with this, not me :)

I see two basic challenges:

a) localize the documentation to lower entry barriers for decision makers
b) localize the runtime GUIs to lower the barriers for users (which also
will affect a) ).

From what I see on YouTube, the individuals behind a) and b) are
typically the same person. But this hopefully changes with automation
soon found everywhere.

The .po files are known to help with the runtime localisation for ages.
Every language has a file with pairs of lines - English first, localized
underneath. These lists are extracted and mainted automatically with the
source code. This po4a I did not know about before. They now extends
that principle with documentation. So, when the English manual has
paragraphs reordered, the other languages are equally reordered. No
exact idea yet how this works with single sentences introduced or words
changed but am confident these folks found something reasonable.

There is a c). Show to the world that LinuxCNC keeps rejuvenating itself.



How things are now:

* All our documentation is maintained in Asciidoc format in the git
repo, and built into HTML and PDF by the build system.

* The "main" documentation is maintained in English.

* To create a new translation, a translator copies the asciidoc source
of the English documentation to a new language-specific asciidoc
source file.  For example: `README.adoc` -> `README_fr.adoc`.  They
edit the new file and translate the words.

That's it!  Simple, but it has a couple of problems...


Problems with the current system:

* If the English-speaking developers change the main documentation
file there is no automatic process to notify the translators, and the
translated docs slowly drift out of date with the main English docs,
without us really knowing.


Right. This will not be automagically solved, people still need to
translate, but it will manageable since you see what paragraphs have
been changed and also see the corresponding outdated chunk of
translation next to it.



* The translations of the docs are handled differently than the
translations of the software.  The translations of the strings in the
software is done using a widely used system called "gettext", which
has a suite of tools to identify translatable strings in programs and
maintain a database of what those strings should look like in
different languages.  You can learn more about gettext here:



Gettext and .po files are a long established technology. There are also
many auxiliary tools to help with the translation. That should be mostly
painless. The danger is that someone light-heartedly translates units
without thinking straight, like "inch" to "mm". I have no doubt that
this will be caught quickly, though.



The new proposal is basically to use gettext for everything, both the
software and the documentation.  This would be done using a system
called po4a: 

Moving the docs translations to po4a would let us use the standard
gettext tools, including online tools like Weblate, to maintain the
translations.  gettext keeps track of what "main" english strings have
changed, and flags the translations of those strings as "out of date",
so that translators know they need attention. Out-of-date translations
automatically fall back to using the up-to-date english strings.

I'm not very experienced with translations, so I'm asking for comments
from the folks who currently do the work of translating LinuxCNC (both
docs & software) into non-English languages...


Debian has translations of its package descriptions. And even though all
my professional life is in English, when I read through
https://blends.debian.org/med/tasks/bio (please have a look) you will
find that there is an extra edge to those descriptions that are
translated. I find that amazing and this experience helped me to keep my
arrogance in check.



Do you have any concerns, input, or comments on this proposal?

I think it is one the most important developmental steps for LinuxCNC to
take. The translations should preferably not be performed by the
developers but by the users.


Would you be willing to verify and update the translations into your
languages?


Wrong addressees. Let me try rephrase that: "Would you be willing to
help organizing translations into your languages and to help your local
user base to contribute and forward their problems?" Problems likely are
differences in the order words in sentences that would affect the C code
and 

Re: [Emc-developers] Processing of linuxcnc_2.9.0~pre0+git20211108.cf14c89a9-1_amd64.changes

[Steffen Möller]

On 09.11.21 02:46, Rod Webster wrote:

Awesome work guys. I for one am super excited.
Thanks so much. Please pass on thanks to all concerned.

So the big question is, are those packages available in Debian testing
(12)?
If not, how long do they take to ripple through?


Thank you. On https://ftp-master.debian.org/new.html you see that we are
9 hours in and have 6 packages that arrived later than LinuxCNC. There
is quite a steady influx of packages, which is amazing. 367 packages are
currently waiting in the queue. The packages at the top of the waiting
list are waiting since 8 months and my hunch is that if there is not an
FTPmaster with a lathe at home waiting to be retrofitted then we need to
crawl to that top of the list, too. This is just because it is a 41MB
tarball and the FTPmasters typically check every file for some copyright
violation or authors that have not been declared in d/copyright and and
and, which takes considerable time. FTPmastesr coming home from a
working day, it is then more likely that smaller package is
cherry-picked - which are also important since these are typically some
build-dependency for something larger.

mesaflash is now waiting for about a month and is in the upper third of
the waiting list. My gut feeling says that this should be in within the
next two weeks.

Best,
Steffen




On Tue, 9 Nov 2021 at 11:32, Sebastian Kuzminsky  wrote:


On 11/8/21 6:16 PM, Debian FTP Masters wrote:

linuxcnc_2.9.0~pre0+git20211108.cf14c89a9-1_amd64.changes uploaded

successfully to localhost

along with the files:
linuxcnc_2.9.0~pre0+git20211108.cf14c89a9-1.dsc
linuxcnc_2.9.0~pre0+git20211108.cf14c89a9.orig.tar.xz
linuxcnc_2.9.0~pre0+git20211108.cf14c89a9-1.debian.tar.xz
linuxcnc-doc-cn_2.9.0~pre0+git20211108.cf14c89a9-1_all.deb
linuxcnc-doc-en_2.9.0~pre0+git20211108.cf14c89a9-1_all.deb
linuxcnc-doc-es_2.9.0~pre0+git20211108.cf14c89a9-1_all.deb
linuxcnc-doc-fr_2.9.0~pre0+git20211108.cf14c89a9-1_all.deb
linuxcnc-uspace-dbgsym_2.9.0~pre0+git20211108.cf14c89a9-1_amd64.deb
linuxcnc-uspace-dev_2.9.0~pre0+git20211108.cf14c89a9-1_amd64.deb
linuxcnc-uspace_2.9.0~pre0+git20211108.cf14c89a9-1_amd64.deb
linuxcnc_2.9.0~pre0+git20211108.cf14c89a9-1_amd64.buildinfo

Greetings,

   Your Debian queue daemon (running on host usper.debian.org)

Wooo h!

Huge thanks to Steffen Möller and Petter Reinholdtsen of the Debian
project for all their work getting LinuxCNC into an acceptable state for
inclusion into Debian, and for uploading our packages to the NEW queue.

There's surely more work to do, but if all goes well I expected starting
with the next release of Debian 12 "Bookworm", users will be able to
install LinuxCNC (and all dependencies, including the RT-Preempt
realtime kernel) directly from the debian.org package archives.  Shortly
thereafter the derivative distributions like Ubuntu and Mint will pick
up LinuxCNC.

This will make it much easier for people to try out LinuxCNC, and will
greatly increase our visibility in the CNC software world.

This is an exciting time for LinuxCNC, and we could not have done it
without Steffen and Petter.  Thank you!  <3


--
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: no report generation, likely not only for pigx-rnaseq Re: What happened to r-cran-jquerylib ?

[Steffen Möller]

On 03.11.21 15:55, Andreas Tille wrote:

Hi Steffen,

Am Wed, Nov 03, 2021 at 12:58:53PM +0100 schrieb Steffen Möller:

Hi Andreas et al.,

We should think about what it means for us not to have a current version
of the DT cran package. For one, it kills the PIGX RNA-seq workflow.

What do you mean by "we should think"?  All we need to do is getting
r-cran-jquerylib *properly*.  Uploading a rejected package to new
without fixing the reasons for a reject is not speeding up things.

I layed out what I consider to have good chances to pass ftpmaster
inspection (see below).  Before I start working on this please confirm
that you asked for rejection of the current upload.


I presume in the meantime you have found the CC to r-pkg-team in which I
was asking for said removal. It predated the email to med by a couple of
minutes.

Concerning the symbolic links - maybe the idea is better than I had
initially thought. Would there be a way to have a warning written when
an older version is requested? Maybe we should just not have the older
versions and provoke a clear and easily(?) detectable error.

The reason I am asking is that with pigx-rnaseq I have generated reports
that do not show two interactive figures. And I did not see anything
obvious on the JavaScript console. I now installed with guix to compare.
The more we fiddle with JavaScript, though, the more likely such
difficulties are likely to develop.

Steffen




On 03.11.21 12:01, Andreas Tille wrote:

Hi again Steffen,

I'd strongly recommend to ask for rejection of your upload to NEW
to not create extra hassle for ftpmaster.

Kind regards
   Andreas.

Am Tue, Nov 02, 2021 at 09:43:07PM +0100 schrieb Andreas Tille:

Hi

Am Sun, Oct 31, 2021 at 07:16:44PM +0100 schrieb Steffen Möller:

I just found there is a new upstream version. I'll upload it and then
likely see it in new.

That will be not successfully, thought.  My idea was to remove jquery
1.x and 2.x from the package and symlink to the Debian packaged version
of jquerylib 3.x.

Unfortunately I did not managed to do this up to now.  Feel free to
beat me in it - but simply uploading a new version to new will just
annoy ftpmaster.

no report generation, likely not only for pigx-rnaseq Re: What happened to r-cran-jquerylib ?

[Steffen Möller]

Hi Andreas et al.,

We should think about what it means for us not to have a current version
of the DT cran package. For one, it kills the PIGX RNA-seq workflow.

Steffen

On 03.11.21 12:01, Andreas Tille wrote:

Hi again Steffen,

I'd strongly recommend to ask for rejection of your upload to NEW
to not create extra hassle for ftpmaster.

Kind regards
  Andreas.

Am Tue, Nov 02, 2021 at 09:43:07PM +0100 schrieb Andreas Tille:

Hi

Am Sun, Oct 31, 2021 at 07:16:44PM +0100 schrieb Steffen Möller:

On 31.10.21 19:14, Nilesh Patra wrote:

On 10/31/21 11:30 PM, Steffen Möller wrote:

Hello, I think this goes out to Andreas.

https://salsa.debian.org/r-pkg-team/r-cran-jquerylib/ states that it was
on the NEW queue and somewhere deep in me I recall to have seen it on
there but it seems gone. It is not in the archive though and I do not
recall a rejection email to the list.

Right, I just did a quick check, and it does not seem to be rejected

$ ssh -t coccia.debian.org 'ls -1
/srv/ftp-master.debian.org/queue/reject/r-cran-* | grep jquery | wc
-l' 2>/dev/null
0

Well, I usually CC the ITP bug in my response to a reject - so feel
free to see here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994867


I manually checked in the dir as well, but I don't see any reject
reason for jquerylib :/ @Andreas, did your dput job fail somehow?
Was this uploaded properly?

I just found there is a new upstream version. I'll upload it and then
likely see it in new.

That will be not successfully, thought.  My idea was to remove jquery
1.x and 2.x from the package and symlink to the Debian packaged version
of jquerylib 3.x.

Unfortunately I did not managed to do this up to now.  Feel free to
beat me in it - but simply uploading a new version to new will just
annoy ftpmaster.

Kind regards

   Andreas.

--
http://fam-tille.de

Re: Debian Math Team

[Steffen Möller]

While I agree, this may also be good thing. There will be more Sprints
(I hope) with then more people that are brought to our community at
large. And Debian so far does very well in keeping all those fragments
together.

Best,

Steffen

On 30.10.21 01:55, Anton Gladky wrote:

Hi Doug,

well, I think that it just increases a fragmentation. But it is up to you.

Best regards

Anton

Am Fr., 29. Okt. 2021 um 22:04 Uhr schrieb Torrance, Douglas
:

During the Debian Science BoF at this year's DebConf, there was some
discussion of creating a team devoted to packaging mathematical software.

This seemed like a pretty good idea, so I figured that I'd go ahead and
start working on getting it set up.  I've already created a Salsa group [1]
and a team on the Debian Package Tracker [2].  If you're interested in
joining, then you should be able to sign up at these links.

I figured next would be applying for a mailing list, putting together a team 
policy, etc.  Any thoughts?

Doug

[1] https://salsa.debian.org/math-team
[2] https://tracker.debian.org/teams/math/

Bug#984243: Help: mothur: ftbfs with GCC-11

[Steffen Möller]

On 21.10.21 20:21, Étienne Mollier wrote:

Hi Andreas,

Andreas Tille, on 2021-10-21:

In file included from addtargets2.cpp:3:
myutils.h:176:1: error: reference to 'byte' is ambiguous

Since C++ 2017, the std::byte type is defined:


   176 | byte *ReadAllStdioFile(FILE *f, off_t );
   | ^~~~
In file included from /usr/include/c++/11/bits/stl_algobase.h:61,
  from /usr/include/c++/11/bits/char_traits.h:39,
  from /usr/include/c++/11/string:40,
  from myutils.h:8,
  from addtargets2.cpp:3:
/usr/include/c++/11/bits/cpp_type_traits.h:404:30: note: candidates are: 'enum 
class std::byte'

The redefinition below thus gives indeterminations, as the code
is running in namespace "std":


In file included from addtargets2.cpp:3:
myutils.h:42:23: note: 'typedef unsigned char byte'
42 | typedef unsigned char byte;
   |   ^~~~
myutils.h:177:1: error: reference to 'byte' is ambiguous

The option which seems the most viable would be to replace all
occurrences of the "byte" type by something that does not clash
with the new standard library, maybe "byte8" to be somewhat
consistent with upstream naming conventions.


In hope this helps,

Have a nice evening,  :)


My C++ skills are a bit rosty but would removing the typedef for byte
solve the problem?

Best,
Steffen

Bug#984243: Help: mothur: ftbfs with GCC-11

[Steffen Möller]

On 21.10.21 20:21, Étienne Mollier wrote:

Hi Andreas,

Andreas Tille, on 2021-10-21:

In file included from addtargets2.cpp:3:
myutils.h:176:1: error: reference to 'byte' is ambiguous

Since C++ 2017, the std::byte type is defined:


   176 | byte *ReadAllStdioFile(FILE *f, off_t );
   | ^~~~
In file included from /usr/include/c++/11/bits/stl_algobase.h:61,
  from /usr/include/c++/11/bits/char_traits.h:39,
  from /usr/include/c++/11/string:40,
  from myutils.h:8,
  from addtargets2.cpp:3:
/usr/include/c++/11/bits/cpp_type_traits.h:404:30: note: candidates are: 'enum 
class std::byte'

The redefinition below thus gives indeterminations, as the code
is running in namespace "std":


In file included from addtargets2.cpp:3:
myutils.h:42:23: note: 'typedef unsigned char byte'
42 | typedef unsigned char byte;
   |   ^~~~
myutils.h:177:1: error: reference to 'byte' is ambiguous

The option which seems the most viable would be to replace all
occurrences of the "byte" type by something that does not clash
with the new standard library, maybe "byte8" to be somewhat
consistent with upstream naming conventions.


In hope this helps,

Have a nice evening,  :)


My C++ skills are a bit rosty but would removing the typedef for byte
solve the problem?

Best,
Steffen

Re: snakemake-dependency Fwd: Bug#996868: ITP: python-connection-pool -- thread-safe connection pool for python

[Steffen Möller]

On 20.10.21 14:08, Nilesh Patra wrote:


On 20 October 2021 6:26:29 am IST, "Steffen Möller"  
wrote:

Snakemake is working for me with python3-connection-pool installed, so I
have uploaded.

Best,

Steffen

I had uploaded with my hack, and autopkgtests work in salsa CI.
I think we simply revert the hack when we have connection pool in archive


Thank you for this.

Steffen

snakemake-dependency Fwd: Bug#996868: ITP: python-connection-pool -- thread-safe connection pool for python

[Steffen Möller]

Snakemake is working for me with python3-connection-pool installed, so I
have uploaded.

Best,

Steffen



 Forwarded Message 
Subject:Bug#996868: ITP: python-connection-pool -- thread-safe
connection pool for python
Resent-Date:Wed, 20 Oct 2021 00:33:01 +
Resent-From:Steffen Moeller 
Resent-To:  debian-bugs-d...@lists.debian.org
Resent-CC:  moel...@debian.org, w...@debian.org
Date:   Wed, 20 Oct 2021 02:31:46 +0200
From:   Steffen Moeller 
Reply-To:   Steffen Moeller , 996...@bugs.debian.org
To: Debian Bug Tracking System 



Package: wnpp
Severity: wishlist

Subject: ITP: python-connection-pool -- thread-safe connection pool for
python
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name : python-connection-pool
Version : 0.0.3
Upstream Author : ZhouYL <81438...@qq.com>
* URL : https://github.com/zhouyl/ConnectionPool
* License : Expat
Programming Lang: Python
Description : thread-safe connection pool for python
This package provides a thread-safe connection pool for Python 3.
These are sets database connections that are readily available for
anticipated repeated requests to the same database.

Remark: This package is maintained by Steffen Moeller at
https://salsa.debian.org/python-team/packages/python-connection-pool

Re: snakemake_6.9.1+dfsg1-1_source.changes ACCEPTED into unstable

[Steffen Möller]

I just ran into this. Will package this with the Python team now.

On 19.10.21 23:40, Nilesh Patra wrote:



On Wed, 20 Oct 2021 at 00:57, Steffen Möller mailto:steffen_moel...@gmx.de>> wrote:


On 19.10.21 21:12, Nilesh Patra wrote:
> On 10/20/21 12:40 AM, Steffen Möller wrote:
>> Update follows. There is an uninstallable file in the tests
folders. I
>> am now separating -tests and -doc.
>
> Thanks, but that'd go a trip to NEW. It'd be nice if you can fix
it in
> the single-source
> package only, for now. -- So as to not stall migration. What do you
> think?


I see that you did another upload, thanks. But seeing the autopkgtest
result[1]
It looks like it needs connection_pool package, which does not seem to
be present in the archive :-(

[1]: https://salsa.debian.org/med-team/snakemake/-/jobs/2098048
<https://salsa.debian.org/med-team/snakemake/-/jobs/2098048>

Re: snakemake_6.9.1+dfsg1-1_source.changes ACCEPTED into unstable

[Steffen Möller]

On 19.10.21 21:12, Nilesh Patra wrote:

On 10/20/21 12:40 AM, Steffen Möller wrote:

Update follows. There is an uninstallable file in the tests folders. I
am now separating -tests and -doc.


Thanks, but that'd go a trip to NEW. It'd be nice if you can fix it in
the single-source
package only, for now. -- So as to not stall migration. What do you
think?


Admittedly I had not thought about that. You have a point. So, yes. I'll
have another local iteration.

Steffen

Re: snakemake_6.9.1+dfsg1-1_source.changes ACCEPTED into unstable

[Steffen Möller]

Update follows. There is an uninstallable file in the tests folders. I
am now separating -tests and -doc . And these .snakemake folders come
from installdocs, which is why all these removals failed. Getting there.

Best,
Steffen

On 19.10.21 20:17, Nilesh Patra wrote:
> Many thanks, Steffen :-)
>
> On Tue, 19 Oct, 2021, 10:50 pm Debian FTP Masters,
mailto:ftpmas...@ftp-master.debian.org>> wrote:
>
>
>
> Accepted:
>

Format: 1.8
Date: Tue, 19 Oct 2021 16:32:04 +0200
Source: snakemake
Architecture: source
Version: 6.9.1+dfsg1-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Med Packaging Team
mailto:debian-med-packag...@lists.alioth.debian.org>>
Changed-By: Nilesh Patra mailto:nil...@debian.org>>
Changes:
 snakemake (6.9.1+dfsg1-1) unstable; urgency=medium
 .
   * Team upload.
 .
   [ Andreas Tille ]
   * Fix watchfile to detect new versions on github
   * New upstream version
   * Standards-Version: 4.6.0 (routine-update)
   * Respect DEB_BUILD_OPTIONS in override_dh_auto_test target (routine-
 update)
   * Remove trailing whitespace in debian/copyright (routine-update)
   * Build-Depends: python3-requests-mock
 .
   [ Nilesh Patra ]
   * d/control:
 + Add versioned Dep on pulp (>= 2.0)
 + Add B-D on python3-smart-open
 .
   [ Steffen Moeller ]
   * Unselected tests needing internet access
   * fixing one calling pytest -> pytest-3
   * d/rules: Allowing consecutive builds with better cleaning
   * Added d/TODO to remind about missing "tes" Python module
Checksums-Sha1:
 9c190e155dfdea8b83447db5dc08535cac38e17c 3202 snakemake_6.9.1+dfsg1-1.dsc
 ad1d9ef3bd5d57b7923e5282ba0049101ee2ea27 5035772
snakemake_6.9.1+dfsg1.orig.tar.xz
 ff5459559c30f53a0c064e3cd19ea9866d640a37 21776
snakemake_6.9.1+dfsg1-1.debian.tar.xz
 830981a8a5653b9cfbb8bd974f11a3946501bbeb 16999
snakemake_6.9.1+dfsg1-1_source.buildinfo
Checksums-Sha256:
 cead2fce120ea6bd3873c84e0aa83878cf86db7f7d7aefcea8d1a98637d2e7bb 3202
snakemake_6.9.1+dfsg1-1.dsc
 6fbef35cee9461e4f9ad8f2ea9608ccafe580bd3eeef2f659df3141b3802da67
5035772 snakemake_6.9.1+dfsg1.orig.tar.xz
 5239a71667fff6c9f7424da571cd279fc30fbb581f1dc49c937e2a550193fee8
21776 snakemake_6.9.1+dfsg1-1.debian.tar.xz
 a3bcfa5dc15652395d203b73c44c953942db741883a6dc62a0dc683a29b92ca7
16999 snakemake_6.9.1+dfsg1-1_source.buildinfo
Files:
 4bf2d7714f8fe2aee04d01bd5785e7c1 3202 science optional
snakemake_6.9.1+dfsg1-1.dsc
 284ae10e744cff36b87cf7b729b99b4a 5035772 science optional
snakemake_6.9.1+dfsg1.orig.tar.xz
 bea80d03859e3043379e00be47f00723 21776 science optional
snakemake_6.9.1+dfsg1-1.debian.tar.xz
 e93718609b40a4dfe3287ea19fef630b 16999 science optional
snakemake_6.9.1+dfsg1-1_source.buildinfo


>
>
> Thank you for your contribution to Debian.
>

Re: Lagging behind several versions for snakemake - lots of failed tests in latest version

[Steffen Möller]

On 18.10.21 18:41, Rebecca N. Palmer wrote:

On 18/10/2021 08:15, Nilesh Patra wrote:

On Mon, Oct 18, 2021 at 01:32:30AM +0200, Steffen Möller wrote:

Is anyone continuing the update of
snakemake now?


@Rebecca, could you look into it now that pulp is done?
Currently, there is just a very few failing tests -- I guess
most are due to some or the other B-D missing,


Yes, and probably.


Hello,

I also had a look since I need snakemake for pigx-rnaseq and there is a
memory constraint problem that this update may fix if we are lucky
(https://github.com/BIMSBbioinfo/pigx_rnaseq/issues/103).

I removed a few tests that needed external data. I may have saved two
though that just invoked the binaries "python" and "pytest" without the
3/-3 suffix.

Best,
Steffen

Re: Lagging behind several versions for snakemake - lots of failed tests in latest version

[Steffen Möller]

Hi Nilesh,

On 17.10.21 23:27, Nilesh Patra wrote:

Hi Steffen,

On Mon, 18 Oct 2021 at 01:41, Steffen Möller mailto:steffen_moel...@gmx.de>> wrote:


On 17.10.21 21:39, Nilesh Patra wrote:

Hi Steffen,

On Mon, 18 Oct 2021 at 01:06, Steffen Möller
mailto:steffen_moel...@gmx.de>> wrote:


On 17.10.21 21:19, Nilesh Patra wrote:

Yeah, snakemake has now moved to pulp 2.0. pulp had another
rev-dep on congress which is now removed from archive.
pulp is maintained in openstack, and I sent out an email to
zigo and openstack-list asking to upgrade,

cf:
https://lists.debian.org/debian-openstack/2021/10/msg1.html
<https://lists.debian.org/debian-openstack/2021/10/msg1.html>



I had been there and already got a reply from zigo (June this
year) that we can go ahead with an update since pulp is (no
longer?) used with Open Stack. I never got around to it,
though. I Just paste our exchange below (don't expect anyone
to mind).

Wonderful, thanks for pasting this!
Are you at it? -- If you could do the needful and upload  :)


Sorry for disappointing you but I am afraid I need to concentrate
on something else this week.


No worries, I have done so, and pushed my changes to:
https://salsa.debian.org/science-team/python-pulp
<https://salsa.debian.org/science-team/python-pulp>
I really, _really_ need reviews. The very odd thing here is same
content in postrm and prerm, and no update-alternatives for installing
in postinst -- I admit, I do not understand pulp very well,
hence would want reviews.

Could you/someone else please, please take a look and upload?
And oh, BTW I added you in the uploaders field since you planned to
takeover this.


Uploaded.

lintian -i preferred the removal in prerm. So, it is a bit redundant
now. I thought this was fine, though. Is anyone continuing the update of
snakemake now?

Best,
Steffen

Re: Lagging behind several versions for snakemake - lots of failed tests in latest version

[Steffen Möller]

On 17.10.21 21:39, Nilesh Patra wrote:

Hi Steffen,

On Mon, 18 Oct 2021 at 01:06, Steffen Möller mailto:steffen_moel...@gmx.de>> wrote:


On 17.10.21 21:19, Nilesh Patra wrote:

Yeah, snakemake has now moved to pulp 2.0. pulp had another
rev-dep on congress which is now removed from archive.
pulp is maintained in openstack, and I sent out an email to zigo
and openstack-list asking to upgrade,

cf:
https://lists.debian.org/debian-openstack/2021/10/msg1.html
<https://lists.debian.org/debian-openstack/2021/10/msg1.html>


I had been there and already got a reply from zigo (June this
year) that we can go ahead with an update since pulp is (no
longer?) used with Open Stack. I never got around to it, though. I
Just paste our exchange below (don't expect anyone to mind).

Wonderful, thanks for pasting this!
Are you at it? -- If you could do the needful and upload  :)


Sorry for disappointing you but I am afraid I need to concentrate on
something else this week.

Best,
Steffen

Re: Lagging behind several versions for snakemake - lots of failed tests in latest version

[Steffen Möller]

On 17.10.21 21:19, Nilesh Patra wrote:

On 10/18/21 12:13 AM, Rebecca N. Palmer wrote:

On 15/10/2021 14:46, Andreas Tille wrote:

Hi Rebecca

and whoever might care.  As usual snakemake is troublesome to upgrade.
I have injected the latest version into Git but there are lots of
failed tests.  It would be great if someone could care about this.

I hadn't tried to upgrade snakemake because python-pulp is too old
(#963041).


Yeah, snakemake has now moved to pulp 2.0. pulp had another rev-dep on
congress which is now removed from archive.
pulp is maintained in openstack, and I sent out an email to zigo and
openstack-list asking to upgrade,

cf: https://lists.debian.org/debian-openstack/2021/10/msg1.html


I had been there and already got a reply from zigo (June this year) that
we can go ahead with an update since pulp is (no longer?) used with Open
Stack. I never got around to it, though. I Just paste our exchange below
(don't expect anyone to mind).

On 6/8/21 1:40 PM, Steffen Möller wrote:


Hi Thomas,

Am 07.06.2021 um 09:05 schrieb Thomas Goirand:

On 6/5/21 7:52 PM, Steffen Möller wrote:

Hello,

pulp is outdated. Would you mind updating it or having me update it?
There is no immediate reason for me to update that version, the error I
was looking for that made me check the version but then turned out to be
elsewhere.

Since I do not run OpenStack myself, I cannot test the effect of such a
version bump and would hence prefer the OpenStack team to address this
or to guide me towards it.

Cheers,
Steffen


Hi,

I don't think anything from OpenStack uses python-pulp, so feel free to
take over the package if you care for it.

Cheers,

Thomas Goirand

Ah, nice. That makes it easy. I had a first attempt last week and found
the branch structure of your current repository to be incompatible with
git-buildpackage (under my hands) and hence with tools like
routine-update. For Debian Med (and increasingly Debian Science)
routine-update is helping a lot, the automation also eases team
maintenance. Hence, if you do not mind, I would leave everything intact
for the OpenStack repository, copy'n'paste into a new repository that
Debian Science an.

Best,
Steffen


Hi,

FYI, the only thing you got to do is have this in your ~/.gbp.conf:

[DEFAULT]
builder = sbuild --source-only-changes
cleaner = /bin/true
ignore-branch = True
pristine-tar = False
no-create-orig = True
[buildpackage]
export-dir = ../build-area/

The important bit is the ignore-branch and pristine-tar. IMO, these
options should be by default in gbp, otherwise one has to maintain it in
all of the repositories, and for a large amount of packages, that's too
much (useless) work...

Cheers,

Thomas Goirand (zigo)




The test failures look like this isn't the only problem, [...]


ACK.
Thanks a lot for your work!


Yip! Many thanks also from my side.

Steffen

Bug#969416: LinuxCNC is coming to Debian

[Steffen Möller]

Petter kindly got in touch about me supporting the LinuxCNC developers
in their packaging and an eventual upload to Debian. So, it is happening
and we happily close this RFP with the upload. The package will be
maintained by the LinuxCNC developers as DMs with me (or Petter, I
presume) sponsoring in the meantime.

Best,
Steffen

Bug#969416: LinuxCNC is coming to Debian

[Steffen Möller]

Petter kindly got in touch about me supporting the LinuxCNC developers
in their packaging and an eventual upload to Debian. So, it is happening
and we happily close this RFP with the upload. The package will be
maintained by the LinuxCNC developers as DMs with me (or Petter, I
presume) sponsoring in the meantime.

Best,
Steffen

Bug#995723: r-cran-dbscan_1.1-8+ds-1_amd64.changes REJECTED

[Steffen Möller]

Hello,

I admit not to recall if I had responded, but I had "-sa"-uploaded a
fixed version -2.

Many thanks to you all
Steffen

On 11.10.21 16:47, Andreas Tille wrote:

Hi Thorsten,

just in case Steffen had not responded and to have a record in the ITP bug:
A fixed package was uploaded to new.

Kind regards and thanks for your work as ftpmaster

 Andreas.

Am Sun, Oct 10, 2021 at 06:00:09PM + schrieb Thorsten Alteholz:

Hi Steffen,

please also mention at least University of Maryland as copyright holder in your 
debian/coypright.

Thanks!
  Thorsten

Bug#995723: r-cran-dbscan_1.1-8+ds-1_amd64.changes REJECTED

[Steffen Möller]

Hello,

I admit not to recall if I had responded, but I had "-sa"-uploaded a
fixed version -2.

Many thanks to you all
Steffen

On 11.10.21 16:47, Andreas Tille wrote:

Hi Thorsten,

just in case Steffen had not responded and to have a record in the ITP bug:
A fixed package was uploaded to new.

Kind regards and thanks for your work as ftpmaster

 Andreas.

Am Sun, Oct 10, 2021 at 06:00:09PM + schrieb Thorsten Alteholz:

Hi Steffen,

please also mention at least University of Maryland as copyright holder in your 
debian/coypright.

Thanks!
  Thorsten

salsa-ci initiation for Debian Med - suspended?

[Steffen Möller]

Hi all,

I just got

+ PROJECT_ID=64711
+ set +x
Error GETing https://salsa.debian.org/api/v4/user (HTTP 401):
Unauthorized {"error":"invalid_token","error_description":"Toke... at
/usr/share/perl5/Devscripts/Salsa/update_repo.pm line 114.
W: Could not initiate CI for long-read-assembler, please initiate
 cd /home/steffen/Med/lra/long-read-assembler && salsa update_repo
--ci-config-path debian/salsa-ci.yml med-team/long-read-assembler

which I expected for those teams for which I do not have the
permissions, but not for the med-team. Is this something to talk about
with the salsa admins?

On a sidenote - https://salsa.debian.org/med-team/long-read-assembler is
for academics only. I thought we wait with an upload to New until the
new queue got a bit shorter.

Best,
Steffen

Nature Methods article on worfklows

[Steffen Möller]

Wratten, Laura et al.:
Reproducible, scalable, and shareable analysis pipelines with
bioinformatics workflow managers
Nature Methods. 2021
https://doi.org/10.1038/s41592-021-01254-9

They kindly cited the "Reproducible workflows"-paper.

Steffen

Re: Any volunteer to verify autopkgtest of spades?

[Steffen Möller]

Hi Tony,

On 23.09.21 15:07, Tony Travis wrote:

On 23/09/2021 13:53, Andreas Tille wrote:

Hi,

some time ago I've pushed a packaging update for Spades. Unfortunately
the autopkgtest fails with
[...]


I'm willing to volunteer, but I don't know how to run "autopkgtest":
Can I just download your package and test it?


You would install both the source tree (with the Debian folder) and
install the binary. Then run

sh debian/tests/run-unit-test

from the source directory.

Many thanks!
Steffen

Re: Any reason to wait with qiime upgrades? (Was: Bug#994470: please update dependency on openblas)

[Steffen Möller]

On 20.09.21 13:34, Andreas Tille wrote:

Control: tags -1 pending



On Thu, Sep 16, 2021 at 11:54:18AM +0200, Sébastien Villemot wrote:

q2-types depends on libopenblas-base, which is a transitional dummy package.
Please replace it by libopenblas0.

I did this in Git (please leave distribution to UNRELEASED if a package
is not uploaded for whatever reason).  I'm wondering what might be the
reason to wait with upgrading the qiime / q2-* packages.

That may have happened to me, i.e. it happened to routine-update and i
had not corrected it.

I think they can all be upgraded/sent to new. And I have changed my mind
when it comes to "shall we first complete what we have in bullseye".
Let's just go for the latest version and see how it goes.

Best,
Steffen

Datasets downloaded by scikit-learn as separate packages?

[Steffen Möller]

Hello,

This goes out to the good fellas who care about scikit-learn. There is
tutorial for the qiime package that has classifier prepared that only
works with the latest stable version (0.24.2). We are at 0.23.2 in Debian.

I gave an update of Scikit-Learn a shot and while the main build was
fine, I was eventually greeted with many download errors for datasets
that it uses as examples, as in

/home/steffen/Science/scikit-learn/examples/inspection/plot_partial_dependence.py
failed leaving traceback:
Traceback (most recent call last):
  File
"/home/steffen/Science/scikit-learn/examples/inspection/plot_partial_dependence.py",
line 50, in 
    cal_housing = fetch_california_housing()
  File
"/home/steffen/Science/scikit-learn/.pybuild/cpython3_3.9/build/sklearn/utils/validation.py",
line 63, in inner_f
    return f(*args, **kwargs)
  File
"/home/steffen/Science/scikit-learn/.pybuild/cpython3_3.9/build/sklearn/datasets/_california_housing.py",
line 134, in fetch_california_housing
    archive_path = _fetch_remote(ARCHIVE, dirname=data_home)
  File
"/home/steffen/Science/scikit-learn/.pybuild/cpython3_3.9/build/sklearn/datasets/_base.py",
line 1194, in _fetch_remote
    urlretrieve(remote.url, file_path)
  File "/usr/lib/python3.9/urllib/request.py", line 239, in urlretrieve
    with contextlib.closing(urlopen(url, data)) as fp:
  File "/usr/lib/python3.9/urllib/request.py", line 214, in urlopen
    return opener.open(url, data, timeout)
  File "/usr/lib/python3.9/urllib/request.py", line 517, in open
    response = self._open(req, data)
  File "/usr/lib/python3.9/urllib/request.py", line 534, in _open
    result = self._call_chain(self.handle_open, protocol, protocol +
  File "/usr/lib/python3.9/urllib/request.py", line 494, in _call_chain
    result = func(*args)
  File "/usr/lib/python3.9/urllib/request.py", line 1389, in https_open
    return self.do_open(http.client.HTTPSConnection, req,
  File "/usr/lib/python3.9/urllib/request.py", line 1349, in do_open
    raise URLError(err)
urllib.error.URLError: 


The original data is typically available. But these are classics with
often unclear licenses, here as in

# The original data can be found at:
# https://www.dcc.fc.up.pt/~ltorgo/Regression/cal_housing.tgz
ARCHIVE = RemoteFileMetadata(
    filename='cal_housing.tgz',
    url='https://ndownloader.figshare.com/files/5976036',
    checksum=('aaa5c9a6afe2225cc2aed2723682ae40'
  '3280c4a3695a2ddda4ffb5d8215ea681'))


The build currently ends with

I: pybuild pybuild:284:   (mv
/home/steffen/Science/scikit-learn/sklearn/conftest.py
/home/steffen/Science/scikit-learn/sklearn/conftest.py.test; mv
/home/steffen/Science/scikit-learn/sklearn/datasets/tests/conftest.py
/home/steffen/Science/scikit-learn/sklearn/datasets/tests/conftest.py.test;
cd /home/steffen/Science/scikit-learn/.pybuild/cpython3_3.9/build &&
python3.9 -c 'import sklearn; sklearn.show_versions()')
mv: cannot stat
'/home/steffen/Science/scikit-learn/sklearn/conftest.py': No such file
or directory
mv: cannot stat
'/home/steffen/Science/scikit-learn/sklearn/datasets/tests/conftest.py':
No such file or directory

System:
    python: 3.9.7 (default, Sep  3 2021, 06:18:44)  [GCC 10.3.0]
executable: /usr/bin/python3.9
   machine: Linux-5.10.0-8-amd64-x86_64-with-glibc2.32

Python dependencies:
  pip: 20.3.4
   setuptools: 52.0.0
  sklearn: 0.24.2
    numpy: 1.19.5
    scipy: 1.7.1
   Cython: 0.29.21
   pandas: 1.1.5
   matplotlib: 3.3.4
   joblib: 0.17.0
threadpoolctl: 2.1.0

Built with OpenMP: True
I: pybuild base:232: cd
/home/steffen/Science/scikit-learn/.pybuild/cpython3_3.9/build;
python3.9 -m pytest -m "not network" -v -k "not test_old_pickle and not
test_ard_accuracy_on_easy_problem"
ImportError while loading conftest
'/home/steffen/Science/scikit-learn/conftest.py'.
../../../conftest.py:14: in 
    from sklearn.utils import _IS_32BIT
../../../sklearn/__init__.py:81: in 
    from . import __check_build  # noqa: F401
../../../sklearn/__check_build/__init__.py:46: in 
    raise_build_error(e)
../../../sklearn/__check_build/__init__.py:31: in raise_build_error
    raise ImportError("""%s
E   ImportError: No module named 'sklearn.__check_build._check_build'
E
___
E   Contents of /home/steffen/Science/scikit-learn/sklearn/__check_build:
E   setup.py  _check_build.c __pycache__
E   _check_build.pyx  __init__.py
E
___
E   It seems that scikit-learn has not been built correctly.
E
E   If you have installed scikit-learn from source, please do not forget
E   to build the package before using it: run `python setup.py install` or
E   `make` in the source directory.
E
E   If you have used an installer, please check that it is suited for your
E   Python version, your operating system and your platform.
E: pybuild pybuild:353: test: plugin distutils 

Re: Is pigx-rnaseq ready to be uploaded?

[Steffen Möller]

On 15.09.21 23:27, Nilesh Patra wrote:

Hi Steffen,

On 9/15/21 5:31 PM, Steffen Möller wrote:

I don't know about the software myself, if you could take a look and push what
you deem sensible, that'd be very cool.

Done. Also eliminated some lintian warnings. All dependencies have been
transitioned, so it cowbuilds now. Good to go imho.

Cool, salsa CI agrees with you as well. Thanks a lot, uploaded

Thank you!

Also, I saw that you added in me to uploaders, thanks a lot for doing this,
but I admit I've no interest in maintaining pigx-rnaseq.
I worked on this package as a part of the team-stuff that I do. Hence, I 
removed myself from Uploaders field
and uploaded.

Sorry for sounding much like a politician, but I forgot about this.
Anyway, I normally do not do this and should have asked.

That said, I'm even motivated to remove myself from uploaders in med-packages 
which I don't have any interest in,
and which has co-maintainers. Let's see.


I agree. A package shall stimulate you somehow and not be a mere
nuisance. Everything else drags your energies. I just suggest you wait
until there is an additional reason to trigger the CI build on salsa,
preferably a new upstream release :)

Best,
Steffen