Am 01.09.24 um 19:26 schrieb andy pugh:
Does anyone have any ideas about the cause of this?
The other distros all seem to be building cleanly in CI.
example:
https://github.com/LinuxCNC/linuxcnc/actions/runs/10655514653/job/29533123088#step:8:9622
It is this one: https://github.com/LinuxC
Does anyone have any ideas about the cause of this?
The other distros all seem to be building cleanly in CI.
example:
https://github.com/LinuxCNC/linuxcnc/actions/runs/10655514653/job/29533123088#step:8:9622
--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for th
On Friday 11 September 2020 21:23:43 andy pugh wrote:
> On Fri, 11 Sep 2020 at 17:27, Gene Heskett
wrote:
> > It has been hung there for about 15 or 20 minutes now.
>
> The buildbot seems to suffer this malaise randomly too. But only
> sometimes.
>
> I suspect that if you try again it will pass.
On Fri, 11 Sep 2020 at 17:27, Gene Heskett wrote:
> It has been hung there for about 15 or 20 minutes now.
The buildbot seems to suffer this malaise randomly too. But only sometimes.
I suspect that if you try again it will pass.
It's in my "I wish I understood that" list. It's a long list.
--
Greetins guys;
It has been hung there for about 15 or 20 minutes now.
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law re
On 5/31/2013 11:02 AM, andy pugh wrote:
> On 31 May 2013 15:54, Sebastian Kuzminsky wrote:
>
>
>> If you follow the link you'll see a list of the steps the
>> builder did,
>>
> Actually, what I see in my lunch break is:
>
> "Based on your corporate access policies, this web site (
> ht
On 5/31/2013 11:29 AM, Sebastian Kuzminsky wrote:
> On 5/31/13 09:02 , andy pugh wrote:
>
>> On 31 May 2013 15:54, Sebastian Kuzminsky wrote:
>>
>>
>>>If you follow the link you'll see a list of the steps the
>>> builder did,
>>>
>> Actually, what I see in my lunch break is:
On 5/31/2013 11:29 AM, Sebastian Kuzminsky wrote:
> On 5/31/13 09:02 , andy pugh wrote:
>> On 31 May 2013 15:54, Sebastian Kuzminsky wrote:
>>
>>>If you follow the link you'll see a list of the steps the
>>> builder did,
>> Actually, what I see in my lunch break is:
>>
>> "Based on your corpor
On 31 May 2013 16:29, Sebastian Kuzminsky wrote:
> Curses! My plot to infiltrate the linuxcnc community in order to serve
> othermalware to the developers has been foiled by your ever vigilant
> corporate network administrator!
For extra fun, the company I work for is so large that no-one knows
On 5/31/13 09:02 , andy pugh wrote:
> On 31 May 2013 15:54, Sebastian Kuzminsky wrote:
>
>> If you follow the link you'll see a list of the steps the
>> builder did,
>
> Actually, what I see in my lunch break is:
>
> "Based on your corporate access policies, this web site (
> http://buildbot.lin
On 31 May 2013 15:54, Sebastian Kuzminsky wrote:
> If you follow the link you'll see a list of the steps the
> builder did,
Actually, what I see in my lunch break is:
"Based on your corporate access policies, this web site (
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds
On 05/30/2013 06:52 PM, andy pugh wrote:
> On 30 May 2013 16:04, andy pugh wrote:
>
>> Straightforward, yes, but with 16 components, 3 inputs and one output
>> per component, quite a bit of HAL to configure.
>> Ah well, time to stop moaning and start coding I guess.
>
> So I did that, and tested i
On 31 May 2013 15:00, Kent A. Reed wrote:
> I just ran the mux test again and it still fails, this time with the
> message you anticipated, namely "result" differs from "expected". I'll
> email you the result and stderr files privately.
I think I see the problem. I didn't push the input data fil
On 5/31/2013 9:29 AM, andy pugh wrote:
> On 31 May 2013 13:38, Kent A. Reed wrote:
>
>> tests/mux failed with the usual "test run exited with 1".
>>
>> Maybe I'll get a little time later to see what's happening internally.
> if you look in the tests/mux directory there should be a file left in
> t
On 31 May 2013 13:38, Kent A. Reed wrote:
> tests/mux failed with the usual "test run exited with 1".
>
> Maybe I'll get a little time later to see what's happening internally.
if you look in the tests/mux directory there should be a file left in
there called "result" which ought to match the si
On 5/31/2013 5:49 AM, andy pugh wrote:
> On 31 May 2013 01:52, andy pugh wrote:
>
>> So I disabled it.
>>
>> Is there any way to see what the problem was?
> Now that it isn't 2am:
>
> Can anyone else with a recent pull of master re-enable that test and
> see if it passes for them? I am a bit stump
On 31 May 2013 01:52, andy pugh wrote:
> So I disabled it.
>
> Is there any way to see what the problem was?
Now that it isn't 2am:
Can anyone else with a recent pull of master re-enable that test and
see if it passes for them? I am a bit stumped on how to fix this
properly when it always passe
On 30 May 2013 16:04, andy pugh wrote:
> Straightforward, yes, but with 16 components, 3 inputs and one output
> per component, quite a bit of HAL to configure.
> Ah well, time to stop moaning and start coding I guess.
So I did that, and tested it here in both sim and realtime under
Lucid, then
On 30 May 2013 16:24, Chris Radek wrote:
> Are you sure "owner" changes? I'm always seeing 6 on my sim build
> for the first thing loadrt~ed.
As far as I can see the "owner" is 6 on a sim-build and 2 on an RT build.
But it takes so long to do a back-to-back that I haven't tried a
proper A-B-A
On 30 May 2013 16:12, Chris Radek wrote:
> For this simple test, you could use "list pin" instead.
Which seem to be absent from:
http://www.linuxcnc.org/docs/html/man/man1/halrun.1.html
--
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto
-
On Thu, May 30, 2013 at 10:12:21AM -0500, Chris Radek wrote:
>
> For this simple test, you could use "list pin" instead.
Oh I misunderstood and thought you were testing pin creation. This
is stupid advice.
Are you sure "owner" changes? I'm always seeing 6 on my sim build
for the first thing lo
On Thu, May 30, 2013 at 02:36:42AM +0100, andy pugh wrote:
>
> The test just sets up one of each type of mux (16 variants), sets the
> inputs, does a "show pin", sets the selector bit, and "show pin"
> again.
For this simple test, you could use "list pin" instead.
---
On 30 May 2013 15:59, Sebastian Kuzminsky wrote:
> Take a look at the test for the multiclick component, it uses halsampler
> and halstreamer. It sets up a small HAL network with streamer connected
> to the component's input pins and sampler connected to the output pins,
> then streams in test p
On 5/29/13 19:36 , andy pugh wrote:
> In a fit of enthusiasm I set up a regression test for mux_generic.
> (which is otherwise all ready to push).
>
> The test just sets up one of each type of mux (16 variants), sets the
> inputs, does a "show pin", sets the selector bit, and "show pin"
> again.
>
In a fit of enthusiasm I set up a regression test for mux_generic.
(which is otherwise all ready to push).
The test just sets up one of each type of mux (16 variants), sets the
inputs, does a "show pin", sets the selector bit, and "show pin"
again.
All well and good, and actually did spot a mista
25 matches
Mail list logo