robot-testing-framework / Re: Introduction and joining the debian-science/robotics team

2020-09-01 Thread Daniele E. Domenichelli
Hello,

I added the robot-testing-framework package to salsa:

  https://salsa.debian.org/science-team/robot-testing-framework/

This time it is a bit more difficult, since it is a set of small libraries.

Can anyone review it, please?


Cheers,
 Daniele



Re: ycm-cmake-modules / Re: Introduction and joining the debian-science/robotics team

2020-09-01 Thread Daniele E. Domenichelli
Hello again,

is there any other comment about the ycm-cmake-modules package? Do you
think it could be uploaded? What is the proper way to proceed now?
Should upload it to mentors and ask for a sponsor?


Cheers,
 Daniele



Re: Introduction to causal dynamics

2020-09-01 Thread Anton Gladky
Hi Ralph,

thanks for the introduction. Could you please shortly formulate how the
Debian Science Team can be useful for you?

Best regards


Anton


Am So., 30. Aug. 2020 um 14:13 Uhr schrieb Ralph Alexander Bariz <
ralph.ba...@pm.me>:

> Hi all,
>
> My name is Ralph Alexander Bariz. I've written a, I think quite usable,
> proof of concept for a runtime which should introduce a new kind of
> algorithmic dedicated to the graph oriented modeling and execution of
> complex non-linear systems.
> Please see
> https://gitlab.ralph.or.at/causal-rt/wiki/-/blob/ralph/debconf/debconf.odp
> Please see the C++ POC Implementation
> https://gitlab.ralph.or.at/causal-rt/causal-cpp
> I request to move over the whole project group to salsa
> https://gitlab.ralph.or.at/causal-rt
> My salsa username is "udet".
>
> Below I've written, for people interested in the why and probably a way to
> some kind of new discrete and, error-resistant discretely, executable
> physics, the thesis. I would also like this post to be seen as an official
> pre-publication of this thesis.
>
> Thanks.
>
> *Preface*:
> I'm system analytics and architect, no mathematician. So this wont contain
> a lot of numerical math what probably also is not necessary but instead the
> results of a structural analysis of what Germans call "Wirklichkeit".
>
> While this journey begun with working out a methodology to model and
> execute symmetric interaction simulations on GPU's utilizing definite
> integrals I was not convinced it could allow to model and execute the aimed
> complex systems observed to be real.
> It continued passing by actor model systems which were more what I seek
> for but still very data oriented while lacking for a definition of "the
> how".
>
> At that time I came into contact with Werner Heisenberg's and Hans-Peter
> Dürr's "last assumption" defining a virtual entity they called "Wirks".
> This, for me, was the key to understand what we seem to have missed all the
> time. Here a discrepancy between the German and the English language got
> very obvious. While a certain understanding of "the how" seems to be deeply
> integrated into German language, the English language seems to completely
> lack it. This discrepancy gets most obvious when thinking about the classic
> definition of causality in both languages. While the English language
> defines causality as the implication cause -> effect, while cause and
> effect are both about the "what", the German definition is "Ursache"(cause)
> -> "Wirkung" while "Wirkung" is not about the "what" but about the "how".
> Also one might note, the English "reality" covers the German "Realität" but
> not the German "Wirklichkeit" while the reality is about the set of all
> being and the "Wirklichkeit" is the set of all happening.
> When trying to model this thought of a "Wirks" there came up a few
> implications which made such a model very attractive not only in context of
> Max Planck's assumption of a discrete energy and spacetime but also seems
> to connect the strings in context of thermodynamics and the simple
> question, why there is entropy but also allows to neatly and exactly define
> a model of time and why density(mass and extent) of a system influences the
> flow of time within this system in relation to another system of another
> density. Also it seems, that such a model allows to understand certain
> effects observed in quantum-mechanics and why space is not a that certain
> thing as we use to treat it as. Causal dynamics has implications to the
> concept of "calculus" and neatly defines the symmetric corner-cases where
> it is useful but clearly points out why in "real" asymmetric/complex and
> not dominated(like domination of suns mass where error can but cut as
> negligible) cases it cannot be applied.
>
> In the following lines I will not handle the concrete "proof of concept"
> implementation for classic computing I have done but use one of its
> example's to support some of previously broached claims. Still it has to be
> clear, this POC implementation is NOT complete neither correct. Also please
> mind, here I define causal dynamics as the thesis observed and deduced but
> not as the thesis making philosophical sense. There is an extended thesis
> assuming that all systems are continuous in their nature and its aspects
> are discretising on interaction but since there, for me, is no hint
> available yet, that this could be the case, but even seemingly one that
> this might not be the case(entropy) I will not touch this thought at this
> point.
>
> *Definitions*:
>
>- A "Processor" is an environment allowing the execution of a causal
>systems
>- An "Aspect" is a piece of Information in context of a system
>- A "Wirks" is the necessity of information to change
>- A "Tick" is a pattern allowing a processor to process a certain
>"Wirks" within a causal system
>- A "Wirkung" is a branch of "Wirks" implying each other
>- A "Wirklichkeit" is an integral 

Re: [COVID-19 Hackathon] Bazel build system pending NEW

2020-09-01 Thread Anton Gladky
Hi,

> eigen: sometimes TF relies on new features that debian's libeigen3-dev
>does not provide. In that case we have to use an embedded
>tarball again.

The new 3.3.8 release seems to be scheduled on 7th of september [1].
If it has features that you need, please just wait a couple of days and it
will be
uploaded into the archive.

[1]
https://listengine.tuxfamily.org/lists.tuxfamily.org/eigen/2020/08/msg1.html

Best regards

Anton



Am Di., 1. Sept. 2020 um 04:37 Uhr schrieb Mo Zhou :

> Hi Michael,
>
> I went through the list of missing dependencies.
>
>  aws-*: I'm not interested in them. In the past I just (manually)
> filtered out all the code associated with aws functionalities.
> Most of them are possibly not packaged yet.
>
>  abseil-cpp: this is a tricky one. Similar to facebook/folly. It does
>  not guarantee a stable ABI. Once the system-provided abseil
>  breaks the tensorflow, we have to embed one.
>
>  Anyway it's present in our archive: libabsl-dev but I don't
>  know whether tensorflow builds against it.
>
>  re2: already present in archive. I guess there is no reason to embed it.
>
>  boringssl: maybe a simple string replacement s/boring/open/g will just
> work?
>
>  farmhash: in archive, and I'm the uploader. Ping me if it needs to be
> updated.
>
>  eigen: sometimes TF relies on new features that debian's libeigen3-dev
> does not provide. In that case we have to use an embedded
> tarball again.
>
>  highwayhash: in archive, and I'm the uploader.
>
>  fft2d: TF uses merely 1 source file from this project for merely
> one OP/Kernel. Just keep it embedded.
> The last upstream update was ~10 yrs ago (IIRC).
>
> On Mon, Aug 31, 2020 at 05:32:56PM +0200, Michael R. Crusoe wrote:
> > Hey Mo, we have some unpackaged dependencies. Currently TensorFlow can
> be built
> > using code copies, but obviously that isn't a great plan. Here are the
> current
> > code copies:
> https://github.com/meteorcloudy/tensorflow/tree/r2.2-debian/debian
> > /dist
> >
> > If you want to help out you can use the bazel-bootstrap and
> > libcheck-framework-java binary packages from
> https://people.debian.org/~olek/
> > packages/
>
> Great! Thanks for the hint.
>
>


Calculix-ccx locked out of Testing

2020-09-01 Thread calumlikesapplepie
Hi, I was trying to install FreeCAD, and I noticed that one of its
reccomended packages was not in testing.  Calculix-ccx appears to be
failing it's autopkgtest, and thus is being locked out of testing.  I'm
not sure, as I haven't ever looked at the 'testing excuses' pages
before, but the other possibilities don't seem plausible (ie, now-
closed bugs).

Thanks for taking a look at it!


signature.asc
Description: This is a digitally signed message part