RedM_ has quit [Remote host closed the connection]
RedW has joined #maemo-leste
System_Error has quit [Ping timeout: 276 seconds]
System_Error has joined #maemo-leste
cockroac1 has quit [Quit: leaving]
xmn has quit [Quit: ZZZzzz…]
xmn has joined #maemo-leste
xmn has quit [Client Quit]
joerg has quit [Ping timeout: 250 seconds]
macros_ has quit [Ping timeout: 250 seconds]
macros__ has joined #maemo-leste
joerg has joined #maemo-leste
yanu has joined #maemo-leste
mardy has joined #maemo-leste
Oksanaa has quit [Remote host closed the connection]
Oksanaa has joined #maemo-leste
macros_ has joined #maemo-leste
macros__ has quit [Ping timeout: 250 seconds]
inky has joined #maemo-leste
_inky has quit [Ping timeout: 268 seconds]
_inky has joined #maemo-leste
macros__ has joined #maemo-leste
macros_ has quit [Ping timeout: 250 seconds]
pere has quit [Ping timeout: 245 seconds]
pere has joined #maemo-leste
xes has quit [Ping timeout: 245 seconds]
<sicelo>
tmlind: when booting N900 over NFS, you use usbnet?
mardy has quit [Read error: Connection reset by peer]
mardy has joined #maemo-leste
<tmlind>
sicelo: no i still have a dusty proto in my rack with smc91x ethernet from way back then
<sicelo>
oh, fancy :-)
<tmlind>
it's slow but usable for occasional boot testing :)
<Wizzup>
photo could be fun for a blog post one day :)
<Wizzup>
freemangordon: ok going to look at the image problems today
<Wizzup>
tmlind: do you have a brief explanation of how those ofono kicks work for the droid 4? I want to see if I can fix the problem(s), for activating internet data, sim detection and sometimes not flushing messages out
<Wizzup>
can't we just kick ofono on any message, or error if there is no handler for it at least
<Wizzup>
I think it looks like for data there are messages like voice call state and maybe the voice call handler gets in the way of those
_whitelogger has joined #maemo-leste
<Wizzup>
tmlind: ok, yeah not asking for you to do it, just trying to understand how we can improve this stuff
<tmlind>
Wizzup: well you can see the uart messages in dmesg with modprobe n_gsm debug=0xff, if there are some unhandled events just kick the usb modem based on those
<tmlind>
mot_qmi_trigger_events() is the call that gets the usb modem to read state and do things
<Wizzup>
check, thanks
<Wizzup>
what I meant is what perhaps it gets routed to the wrong handler somehow, but maybe that's not possible
<tmlind>
likely some unhandled events happening on the uart mux ports somewhere
<tmlind>
most of the handlers just call mot_qmi_trigger_events() and let kernel qmi driver take care of things
<Wizzup>
ok, I'll try to get some more dumps
<tmlind>
also, the modem firmware on d4 vs bionic use different line end :( maybe some of it is not handled properly if one behaves but the other does not
<tmlind>
i ended up doing most of the development against bionic firmware as that allowed a cheap t-mo sim
<Wizzup>
understood, do we have a write up of what line/data goes to what tty? is that just in kernel?
<tmlind>
there are some defines in ofono if you grep for dlci
<Wizzup>
ok
<tmlind>
switching over to use ell api instead of the gatchat would make it easy to get rid of the firmware specific reponse line end issue
<tmlind>
that's only for the serial port mux communcation, no need to use ell for anything else
xes has joined #maemo-leste
humpelstilzchen[ has quit [Ping timeout: 250 seconds]
_inky has quit [Read error: Connection reset by peer]
humpelstilzchen[ has joined #maemo-leste
_inky has joined #maemo-leste
scops has quit [Quit: Bridge terminating on SIGTERM]
devrtz[m] has quit [Quit: Bridge terminating on SIGTERM]
M1peter10[m] has quit [Quit: Bridge terminating on SIGTERM]
MartijnBraam[m] has quit [Quit: Bridge terminating on SIGTERM]
mighty17[m] has quit [Quit: Bridge terminating on SIGTERM]
wunderwungiel[m] has quit [Quit: Bridge terminating on SIGTERM]
tvall has quit [Quit: Bridge terminating on SIGTERM]
optix has quit [Quit: Bridge terminating on SIGTERM]
mint[m] has quit [Quit: Bridge terminating on SIGTERM]
BlagovestPetrov[ has quit [Quit: Bridge terminating on SIGTERM]
calebtheythem[m] has quit [Quit: Bridge terminating on SIGTERM]
humpelstilzchen[ has quit [Quit: Bridge terminating on SIGTERM]
tvall has joined #maemo-leste
humpelstilzchen[ has joined #maemo-leste
mighty17[m] has joined #maemo-leste
M1peter10[m] has joined #maemo-leste
scops has joined #maemo-leste
MartijnBraam[m] has joined #maemo-leste
BlagovestPetrov[ has joined #maemo-leste
elastic_dog has quit [Quit: elastic_dog]
devrtz[m] has joined #maemo-leste
wunderwungiel[m] has joined #maemo-leste
mint[m] has joined #maemo-leste
calebtheythem[m] has joined #maemo-leste
optix has joined #maemo-leste
elastic_dog has joined #maemo-leste
<Wizzup>
freemangordon: looks like qt packages are a problem somehow now wrt libgles2
<Wizzup>
will try to fix, but definitely annoying :)
MartijnBraam[m] has quit [Remote host closed the connection]
devrtz[m] has quit [Remote host closed the connection]
BlagovestPetrov[ has quit [Remote host closed the connection]
tvall has quit [Remote host closed the connection]
optix has quit [Remote host closed the connection]
calebtheythem[m] has quit [Remote host closed the connection]
M1peter10[m] has quit [Remote host closed the connection]
mighty17[m] has quit [Read error: Connection reset by peer]
wunderwungiel[m] has quit [Remote host closed the connection]
scops has quit [Remote host closed the connection]
mint[m] has quit [Remote host closed the connection]
humpelstilzchen[ has quit [Remote host closed the connection]
mp107 has quit [Remote host closed the connection]
tvall has joined #maemo-leste
tvall has quit [Remote host closed the connection]
<Wizzup>
ah, it looks like the versions are a problem...
tvall has joined #maemo-leste
System_Error has quit [Ping timeout: 276 seconds]
System_Error has joined #maemo-leste
System_Error has quit [Remote host closed the connection]
mighty17[m] has joined #maemo-leste
scops has joined #maemo-leste
humpelstilzchen[ has joined #maemo-leste
M1peter10[m] has joined #maemo-leste
MartijnBraam[m] has joined #maemo-leste
BlagovestPetrov[ has joined #maemo-leste
mint[m] has joined #maemo-leste
wunderwungiel[m] has joined #maemo-leste
devrtz[m] has joined #maemo-leste
calebtheythem[m] has joined #maemo-leste
optix has joined #maemo-leste
<Wizzup>
freemangordon: when I have this in control dependencies:
<Wizzup>
libegl1 (>= 1.3.4),
<Wizzup>
+ libgles1 (>= 1.3.4),
<Wizzup>
+ libgles2 (>= 1.3.4),
<Wizzup>
I guess that refers to version of an actual package, not version of the source package?
<Wizzup>
Broken hildon-meta-droid4:armhf Depends on libgles2:armhf < none | 1.3.4-3+2m7.1 @un uH > (>= 1.3.4) Considering libgles2:armhf 7 as a solution to hildon-meta-droid4:armhf 3 Holding Back hildon-meta-droid4:armhf rather than change libgles2:armhf
tvall has quit [Quit: Client limit exceeded: 20000]
humpelstilzchen[ has quit [Quit: Client limit exceeded: 20000]
rafael2k has quit [Ping timeout: 240 seconds]
scops has quit [Quit: Client limit exceeded: 20000]
MartijnBraam[m] has quit [Quit: Client limit exceeded: 20000]
<Wizzup>
ok, almost done I think
M1peter10[m] has quit [Quit: Client limit exceeded: 20000]
tvall has joined #maemo-leste
humpelstilzchen[ has joined #maemo-leste
scops has joined #maemo-leste
MartijnBraam[m] has joined #maemo-leste
M1peter10[m] has joined #maemo-leste
System_Error has joined #maemo-leste
wunderwungiel[m] has joined #maemo-leste
mighty17[m] has quit [Quit: Client limit exceeded: 20000]
BlagovestPetrov[ has quit [Quit: Client limit exceeded: 20000]
wunderwungiel[m] has left #maemo-leste [#maemo-leste]
mint[m] has quit [Quit: Client limit exceeded: 20000]
devrtz[m] has quit [Quit: Client limit exceeded: 20000]
calebtheythem[m] has quit [Quit: Client limit exceeded: 20000]
optix has quit [Quit: Client limit exceeded: 20000]
lightbringer has quit [Ping timeout: 245 seconds]
Daanct12 has joined #maemo-leste
Danct12 has quit [Ping timeout: 256 seconds]
xmn has joined #maemo-leste
Danct12 has joined #maemo-leste
Daanct12 has quit [Ping timeout: 256 seconds]
marabej has joined #maemo-leste
marabej has quit [Client Quit]
<Wizzup>
and salutem was missing :)
<Wizzup>
ok, I think the images will build now
mighty17[m] has joined #maemo-leste
devrtz[m] has joined #maemo-leste
calebtheythem[m] has joined #maemo-leste
BlagovestPetrov[ has joined #maemo-leste
optix has joined #maemo-leste
mint[m] has joined #maemo-leste
Livio has joined #maemo-leste
Livio has quit [Quit: I'm gone away.]
<freemangordon>
:)
Livio has joined #maemo-leste
xes has quit [Quit: WeeChat 3.3]
xes has joined #maemo-leste
rafael2k has joined #maemo-leste
xes has quit [Ping timeout: 256 seconds]
Livio has quit [Ping timeout: 256 seconds]
inky has quit [Read error: Connection reset by peer]
sunshavi has joined #maemo-leste
_inky has quit [Read error: Connection reset by peer]
inky has joined #maemo-leste
xes has joined #maemo-leste
_inky has joined #maemo-leste
Livio has joined #maemo-leste
elastic_dog has quit [Ping timeout: 252 seconds]
elastic_dog has joined #maemo-leste
xmn has quit [Remote host closed the connection]
lightbringer has joined #maemo-leste
lightbringer has quit [Changing host]
lightbringer has joined #maemo-leste
macros_ has joined #maemo-leste
macros__ has quit [Ping timeout: 250 seconds]
Livio has quit [Ping timeout: 250 seconds]
Livio has joined #maemo-leste
Livio has quit [Ping timeout: 250 seconds]
Livio has joined #maemo-leste
<Wizzup>
freemangordon: images build now, but the vm is once again out of space
<Wizzup>
*sigh*
<Wizzup>
clearing it out now
<Wizzup>
we need to just host it the images ourselves somewhere
<freemangordon>
in 1-2 months I'll retire my PC and will buy a new one, I may equip it with one more 2TB HDD in RAID1 with current one and keep it running as images server
<freemangordon>
as NFS storage that is
<freemangordon>
my inet is pretty much ok
<freemangordon>
or, I can see if I can put something on our corporate server
<freemangordon>
unfortunately inet connection is not good there
mp107 has joined #maemo-leste
<Wizzup>
I have a lot of space on another server with 1Gbit/s
<Wizzup>
I also test dist-upgrade from previous stable image and it works
<Wizzup>
I'm dding the new image now
<Wizzup>
probably 1-2 days for the news update
<uvos>
ok
<Wizzup>
should I also build sphone for stable, or keep that in -devel?
<Wizzup>
actually I guess you can do that
<uvos>
i dont think its sane to promote to devel while it dosent work on any device
<Wizzup>
ok
<uvos>
i gues it works on pp maybe
<uvos>
but i cant test
<uvos>
and audio is broken atm?
<uvos>
right?
<Wizzup>
I believe so on the PP
<Wizzup>
btw, something I think I want to fix (not sure how we'll do it yet), but the way we currently sync devel to stable is a bit tricky, in that we have to rebuild everything and also it then directly hits stable, so if we have several multi-hour builds that depend on each other it is a real problem, it would be easier if we could just rsync some repo or something
<uvos>
that would force devel to be stable at that time tho no partial upgrades of stable
<Wizzup>
right, or we just make our 'stable' repo something that is never updated automatically from jenkins, and requires rsync trigger
<Wizzup>
and then for testing we could use a different url to the stable repo and rsync it when it is ok
<Wizzup>
(of course for extras we would not do this)
<uvos>
that still a problem
<uvos>
if you have to rush a bugfix into stable
<uvos>
like the n900 ts breaking etc
<Wizzup>
right, that relies on a specific workflow
<Wizzup>
well the d4 image boots for me :)
<Wizzup>
to salutem
<humpelstilzchen[>
To get the proximity & light sensor to work I would like a config change on the pinephone kernel, what would be the recommended way? Create an issue on github?
<Wizzup>
humpelstilzchen[: do you know what we should change in the config?
<humpelstilzchen[>
Wizzup: still in testing phase, but looks really good.
<Wizzup>
humpelstilzchen[: ok, great
<humpelstilzchen[>
Wizzup: ok, PR, edit an existing patch or create a new one?
<humpelstilzchen[>
Btw its basically STK3310 y -> m and AXP20X_POWER m -> y, not 100% sure why, but looks like its a timing issue between power from PMIC and first access to stk3311 register. Compared it with megi kernel which had stk3310=m and axp=y
<uvos>
i gues you should also report the problem to the maintainer of the kernel module(s) in question
<humpelstilzchen[>
right
mardy has quit [Quit: WeeChat 2.8]
<Wizzup>
humpelstilzchen[: new patch is easier
<humpelstilzchen[>
ok
TonyStone has quit [Read error: Connection reset by peer]
TonyStone has joined #maemo-leste
<sicelo>
i reported a bug for this to debian already, but if someone here uses Debian sid (or maybe qemu 6.2 on any other distro), please check if usb passthrough works for you. a good example for how to do passthrough is https://leste.maemo.org/Status/Mobile_Data