01:51
<
DocScrutinizer >
what's labsw
01:54
<
kristianpaul >
an usb controlled swich
01:55
<
kristianpaul >
made by werner :)
01:55
<
DocScrutinizer >
mhm
01:56
<
kristianpaul >
Actually i had been thinking what else i can do with it besides powercycle a M1
01:56
<
DocScrutinizer >
powercycle M1 - what's the use of such project?
01:57
<
kristianpaul >
hunting for nor corruption in M1
01:57
<
DocScrutinizer >
err
01:57
<
DocScrutinizer >
for sure a joyful thing to do
01:59
<
DocScrutinizer >
sounds a bit like "what's square root of 2?" though
01:59
<
DocScrutinizer >
1 * 1 ? no
01:59
<
DocScrutinizer >
1.000001 * 1.000001? no
01:59
<
DocScrutinizer >
...
02:02
<
kristianpaul >
"It would be desirable to be able to also switch AC" indeed :)
02:02
<
DocScrutinizer >
well, depends on the type of relay you use, no?
02:04
<
kristianpaul >
i would prefer a triac for ac anyway
02:09
<
wpwrak >
the relays are quite decent :) just a little big
02:09
<
kristianpaul >
little noisy!!
02:09
<
kristianpaul >
i can stand that for a minute
02:09
<
DocScrutinizer >
use SolidState relays then
02:10
<
kristianpaul >
cant*
02:10
<
DocScrutinizer >
I bet there are some available with even same footprint
02:10
<
wpwrak >
the noise isn't
*that* bad :)
02:12
<
kristianpaul >
well, i was making that for 8 in/out that time
02:12
<
kristianpaul >
first vesion was rele based, next triac :-)
02:12
<
kristianpaul >
me happy ;)
02:13
<
kristianpaul >
was a very basic board i did for some EE were doign theit thesis,
02:14
<
kristianpaul >
pic16F, sms send/receive via AT commands :)
02:14
<
kristianpaul >
and zero noise :)
02:15
<
wpwrak >
(AT commands) ;-))
02:17
<
kristianpaul >
So if understand correcly that 20000+ cycles  was with no pull up mod?
02:18
<
kristianpaul >
or you still finding the  2 square root, as DocScrutinizer pointed :)
02:18
<
wpwrak >
20000+ was with WE# pull-up ... and something corrupting the lock bit of block 1
02:19
<
wpwrak >
well, 1st block, so block 0 :)
03:24
<
wolfspraul >
good morning :-)
03:53
<
roh >
wolfspraul: morning
15:58
<
Ayla >
mth: great work
16:01
<
mth >
yeah, but as usual with gmenu2x I still haven't fixed the thing I wanted to fix today ;)
16:11
<
Ayla >
mth: what was the correct command to compile the python scripts?
16:15
<
jow_laptop >
kyak: if you find a few minutes, please check whether the menuconfig situation improved now. The odd behaviour was most likely caused by recursive depends injected by the luci suite
16:55
<
kyak >
jow_laptop: sure, i can do that. What is the commit that has most likely solved the problem?
16:57
<
jow_laptop >
if you do not include the luci feed in your builds its probably another package causing the problems
16:57
<
jow_laptop >
in this case, run  make defconfig 2>/dev/null | grep recursive
16:59
<
kyak >
no, i don't have luci in there
17:00
<
kyak >
there are several packages with recursive dependencies
17:00
<
jow_laptop >
those are most likely causing it
17:02
<
kyak >
qt4 is among them
17:02
<
kyak >
lubpurple, too
17:02
<
kyak >
it's a little bit strange
17:03
<
kyak >
for example, it mentiones alex4
17:03
<
kyak >
alex4 depends on alex4-data, while alex4-data depends on alex4. Is is the kind of thing causing problems for kconfig?
17:03
<
jow_laptop >
I had  stuff like package A with DEPENDS:=+B and package B with DEPENDS:=A  ... that made menuconfig freak out
17:04
<
kyak >
strange.. it has been like this for while
17:04
<
kyak >
i'll try changing it now
17:04
<
jow_laptop >
yes, somehow menuconf got stricter, but it has always been a problem
17:07
<
kyak >
DEPENDS:=+libxml2 +libgnutls +libncursesw +glib2 $(ICONV_DEPENDS) $(INTL_DEPENDS)
17:10
<
jow_laptop >
can you paste the full recursive lines somewhere?
17:10
<
jow_laptop >
its a bit hard to understand as select-depends also inject reverse depends into the selected package
17:11
<
jow_laptop >
you can inspect the generated Kconfig source with "./scripts/metadata.pl package_config tmp/.packageinfo"
17:12
<
kyak >
jow_laptop: i'll be back in a couple of hours
17:20
<
mth >
Ayla: python -OO -E -c 'import compileall ; compileall.compile_dir("path")'
17:21
<
Ayla >
mth: ah thanks
17:22
<
Ayla >
I'm having an issue with a makefile right now, maybe one of you have the answer
17:22
<
Ayla >
I have this rule:
17:22
<
Ayla >
$(PYGAME_LIB_DIR)/%.so: $(PYGAME_SRC_DIR)/%.c
17:23
<
Ayla >
    $(TARGET_CC) $(CFLAGS) $^ $(LDFLAGS) -o $@
17:23
<
Ayla >
it does work fine, as long as the .c files are present when the makefile is executed
17:24
<
Ayla >
however, the sources are extracted from a TGZ archive;
17:24
<
Ayla >
if I launch the makefile, it will fail to build any of the .so lib
17:24
<
Ayla >
if I launch it again, it works fine
17:24
<
Ayla >
how can I bypass that?
17:27
<
jow_laptop >
what triggers the .tar.gz unpack?
17:31
<
Ayla >
I untar it manually
17:31
<
Ayla >
inside a rule
17:32
<
Ayla >
let me upload that Makefile, it'll be easier
17:35
<
jow_laptop >
can't you make the %.so target simply depend on $(PYGAME_DIR)/.downloaded as well?
17:35
<
Ayla >
the current fix is line 122: I call an external "make" process
17:36
<
jow_laptop >
$(PYGAME_LIB_DIR)/%.so: $(PYGAME_DIR)/.downloaded $(PYGAME_SRC_DIR)/%.c
17:36
<
Ayla >
probably, what would that change?
17:36
<
jow_laptop >
it would force make to complete ".downloaded" which in turn would trigger wget and tar -xzf
17:37
<
Ayla >
the sources are correctly extracted, that's not the problem
17:37
<
jow_laptop >
before diving into the %.so rule
17:42
<
mth >
it would be cleaner to depend the .so files on the .c files
17:43
<
mth >
and use $^ to refer to them inside the rule itself, to avoid duplication
17:43
<
mth >
and then make the .c files depend on .downloaded
17:45
<
Ayla >
some of the .so are constitued with two .c files
17:48
<
Ayla >
or maybe $^ extends to all the C files?
17:48
<
Ayla >
that are supplied at the right of the ':' delimiter
17:48
<
mth >
iirc $^ is all dependencies and $< is the first dependency, but maybe I mixed them up
17:49
<
mth >
doesn't pygame itself already include a Makefile? or a setup.py?
17:50
<
Ayla >
it has setup.py
17:54
<
mth >
it's possible setup.py already has the functionality to build the libs
17:54
<
mth >
I don't know if it can handle cross compilation though
17:54
<
mth >
but maybe it's easier to patch setup.py than the replicate its functionality
17:54
<
Ayla >
it's a bit of a mess
17:54
<
Ayla >
that's why I went with a Makefile
17:55
<
Ayla >
SiENcE did the same and bypassed setup.py with another python script
17:57
<
Ayla >
which does not work at all
17:58
<
Ayla >
Make says that there's no rule to build output/build/pygame-1.9.1release/lib/base.so
18:32
<
kyak >
jow_laptop: what i should be looking for in the generated Kconfig source?
18:34
<
jow_laptop >
select, dpends
18:35
<
kyak >
in case of libpurple, it doesn't lok recursive
19:10
<
jow_laptop >
sorry I got distracted
19:11
<
jow_laptop >
kyak: can you upload the full kconfig output somewhere? so that I can follow the dependency chains manually
21:56
<
mth >
well, there is indeed no rule to build the "base" module
22:08
<
Ayla >
mth: you should highlight me
22:16
<
mth >
I did highlight you, one line afterwards
22:18
<
mth >
is there a src/base.c?
22:22
<
mth >
bedtime for me, I'll check back tomorrow
22:26
<
Ayla >
irssi will highlight the message only if my nick is the very first word of the message
22:26
<
Ayla >
and there is a src/base.c as soon as the tarball is extracted
22:27
<
mth >
well, that's not what most IRC clients do afaik
22:28
<
mth >
I don't know if it makes a difference, but I usually use the 3-part target line
22:28
<
mth >
so "targets: dest_pattern: src_pattern"
22:29
<
mth >
really gone now