<Wizzup>
I don't think we want to pkg the specific commit they check out
<Wizzup>
so a submodule seems like a great idea
<Wizzup>
(to me, here)
<Wizzup>
alternatively I can make it a 'network job' in the CI where it's allowed to run 'git clone' but that doesn't seem any better to me
ceene has quit [Ping timeout: 264 seconds]
pere has quit [Ping timeout: 252 seconds]
pere has joined #maemo-leste
<Wizzup>
freemangordon: btw, every time I sign in from slack using haze I also get an email from them, 'sign in from new device', this is probably also becaus the purple dir gets cleared
<Wizzup>
I only just realised
parazyd has quit [Ping timeout: 264 seconds]
RedW has quit [Quit: huh upgrades]
parazyd has joined #maemo-leste
<freemangordon>
Wizzup: I think we shall come-up with a sane strategy about those dirs
<freemangordon>
lets all of us think for a while
<freemangordon>
and then have a discussion what is the best way to do fix that
<Wizzup>
freemangordon: well it seems to me that some pidgin plugins just expect the dir to remain
<Wizzup>
maybe they can request that and state what data they want to persist
<Wizzup>
or alternatively, do we know *why* haze wants to always start with a clean slate?
RedW has joined #maemo-leste
parazyd has joined #maemo-leste
<freemangordon>
no
<Wizzup>
no to what?
<freemangordon>
I don't know why haze wants to start in clean state
<Wizzup>
I suspect it's because it creates all accounts from scratch and this way it won't have to account for other programs interfering wit hit
<freemangordon>
makes sense
<freemangordon>
I wouldn;t want pidgin and TP to share data
<Wizzup>
right, but they could use a tp-haze dir
<freemangordon>
right
<freemangordon>
but we shall teach haze to somehow know what plugins do
<Wizzup>
right (sorry on the phone)
parazyd has quit [Ping timeout: 268 seconds]
parazyd has joined #maemo-leste
akossh has joined #maemo-leste
mdz has quit [Ping timeout: 264 seconds]
<Wizzup>
freemangordon: conversations 0.6.3 should handle online/offline fine now
<Wizzup>
tmlind: did you test your mz609 utags on mz608 as well? same for mz617 on mz616/mz615?
uvos has joined #maemo-leste
<Wizzup>
uvos: hey
<Wizzup>
I was planning to try leste on either the mz608, mz615 or mz616 now (and hook them up a lab psu instead of battery), any suggestions on which to start with?
<Wizzup>
can also do mz617, but then it'll be tricky-er wrt no sd card
<uvos>
Wizzup: hi :)
<uvos>
mz608 has the less locked bootloader
<uvos>
i would start with that
<Wizzup>
hey
<Wizzup>
ok
<Wizzup>
do you think the kexecboot utags from mz609 will work?
<uvos>
to my knowlage the bootloader dosent care about the device string in utags and the partition layout is the same enough, but you should check the latter in android
<uvos>
since the modem partions might be missing on mz608
<Wizzup>
I'll boot it to android
<uvos>
on mz608 flashing wrong utags is also no issue since you should be able to just issue a erase via fastboot
<uvos>
(try it first ofc)
<Wizzup>
yeah, I need to check if I have the right android images for it
<uvos>
on mz61* incrorect utags is a hard brick
<Wizzup>
I'm so used to just doing it for the droid 4 that I need to remind myself of all the steps I have to do on the other ones :)
<uvos>
you dont need any android images to undo utags
<uvos>
its just erase
<uvos>
the stock utags is emtpy
<Wizzup>
ok
<Wizzup>
and I guess I should take a droid4 image and make it load the right dtb after kexecboot is set up
<uvos>
yes
<uvos>
wel no
<uvos>
you need to build a new kernel
<Wizzup>
ah, we don't have the dts in the -devel kernel yet?
<uvos>
the kernel we have in devel dosent have the hacks required for the display either