| sicelo | tmlind: when booting N900 over NFS, you use usbnet? | 09:43 |
|---|---|---|
| tmlind | sicelo: no i still have a dusty proto in my rack with smc91x ethernet from way back then | 10:37 |
| sicelo | oh, fancy :-) | 10:38 |
| tmlind | it's slow but usable for occasional boot testing :) | 10:41 |
| Wizzup | photo could be fun for a blog post one day :) | 10:49 |
| Wizzup | freemangordon: ok going to look at the image problems today | 10:50 |
| 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 | 10:56 |
| Wizzup | can't we just kick ofono on any message, or error if there is no handler for it at least | 11:07 |
| 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 | 11:07 |
| Wizzup | tmlind: ok, yeah not asking for you to do it, just trying to understand how we can improve this stuff | 11:17 |
| 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 | 11:19 |
| tmlind | mot_qmi_trigger_events() is the call that gets the usb modem to read state and do things | 11:23 |
| Wizzup | check, thanks | 11:25 |
| Wizzup | what I meant is what perhaps it gets routed to the wrong handler somehow, but maybe that's not possible | 11:25 |
| tmlind | likely some unhandled events happening on the uart mux ports somewhere | 11:26 |
| tmlind | most of the handlers just call mot_qmi_trigger_events() and let kernel qmi driver take care of things | 11:27 |
| Wizzup | ok, I'll try to get some more dumps | 11:28 |
| 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 | 11:28 |
| tmlind | i ended up doing most of the development against bionic firmware as that allowed a cheap t-mo sim | 11:29 |
| Wizzup | understood, do we have a write up of what line/data goes to what tty? is that just in kernel? | 11:30 |
| tmlind | there are some defines in ofono if you grep for dlci | 11:31 |
| Wizzup | ok | 11:31 |
| 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 | 11:32 |
| tmlind | that's only for the serial port mux communcation, no need to use ell for anything else | 11:32 |
| Wizzup | freemangordon: looks like qt packages are a problem somehow now wrt libgles2 | 12:45 |
| Wizzup | will try to fix, but definitely annoying :) | 12:46 |
| Wizzup | ah, it looks like the versions are a problem... | 13:05 |
| Wizzup | freemangordon: when I have this in control dependencies: | 13:18 |
| Wizzup | libegl1 (>= 1.3.4), | 13:18 |
| Wizzup | + libgles1 (>= 1.3.4), | 13:18 |
| Wizzup | + libgles2 (>= 1.3.4), | 13:18 |
| Wizzup | I guess that refers to version of an actual package, not version of the source package? | 13:18 |
| Wizzup | trying to understand this: | 13:19 |
| Wizzup | Investigating (0) hildon-meta-droid4:armhf < 1.24+2m7 -> 1.33+2m7.1 @ii umU Ib > | 13:19 |
| 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 | 13:19 |
| Wizzup | hm libllvm8 is not in stable it seems | 13:29 |
| Wizzup | ok, almost done I think | 13:34 |
| Wizzup | and salutem was missing :) | 14:46 |
| Wizzup | ok, I think the images will build now | 14:46 |
| freemangordon | :) | 14:58 |
| Wizzup | freemangordon: images build now, but the vm is once again out of space | 18:45 |
| Wizzup | *sigh* | 18:45 |
| Wizzup | clearing it out now | 18:46 |
| Wizzup | we need to just host it the images ourselves somewhere | 18:46 |
| 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 | 18:53 |
| freemangordon | as NFS storage that is | 18:53 |
| freemangordon | my inet is pretty much ok | 18:54 |
| freemangordon | or, I can see if I can put something on our corporate server | 18:54 |
| freemangordon | unfortunately inet connection is not good there | 18:54 |
| Wizzup | I have a lot of space on another server with 1Gbit/s | 19:07 |
| Wizzup | I just don't have the time | 19:07 |
| freemangordon | ah | 19:18 |
| freemangordon | well... | 19:18 |
| freemangordon | we may ask maemo admins to help | 19:19 |
| freemangordon | I doubt xes or warfare would refuse to help | 19:19 |
| freemangordon | xes is on the channel even | 19:20 |
| Wizzup | it's not about refusing, it's just that their host is really slow | 19:34 |
| Wizzup | and the disk space is very limited | 19:34 |
| Wizzup | I have ~80T at home and ~2TB on a server in finland or so, so we can just use that | 19:35 |
| Wizzup | I just need to migrate a part of maedevu and such | 19:35 |
| Wizzup | I'll wait for a bit, see if parazyd comes back | 19:35 |
| Wizzup | we have pp images now at least (untested) https://maedevu.maemo.org/images/pinephone/20220201/ | 19:37 |
| freemangordon | Wizzup: my point was - we can ask for help for the migration/configuration :) | 19:46 |
| Wizzup | right | 19:47 |
| Wizzup | https://maedevu.maemo.org/images/droid4/20220201/ | 20:39 |
| uvos | great | 20:40 |
| uvos | will we have a newspost for this? | 20:40 |
| uvos | (i know your busy) | 20:40 |
| Wizzup | yes, we will :) | 20:41 |
| Wizzup | I also test dist-upgrade from previous stable image and it works | 20:41 |
| Wizzup | I'm dding the new image now | 20:41 |
| Wizzup | probably 1-2 days for the news update | 20:42 |
| uvos | ok | 20:42 |
| Wizzup | should I also build sphone for stable, or keep that in -devel? | 20:42 |
| Wizzup | actually I guess you can do that | 20:42 |
| uvos | i dont think its sane to promote to devel while it dosent work on any device | 20:42 |
| Wizzup | ok | 20:42 |
| uvos | i gues it works on pp maybe | 20:42 |
| uvos | but i cant test | 20:43 |
| uvos | and audio is broken atm? | 20:43 |
| uvos | right? | 20:43 |
| Wizzup | I believe so on the PP | 20:43 |
| 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 | 20:43 |
| uvos | that would force devel to be stable at that time tho no partial upgrades of stable | 20:44 |
| Wizzup | right, or we just make our 'stable' repo something that is never updated automatically from jenkins, and requires rsync trigger | 20:45 |
| Wizzup | and then for testing we could use a different url to the stable repo and rsync it when it is ok | 20:45 |
| Wizzup | (of course for extras we would not do this) | 20:45 |
| uvos | that still a problem | 20:45 |
| uvos | if you have to rush a bugfix into stable | 20:46 |
| uvos | like the n900 ts breaking etc | 20:46 |
| Wizzup | right, that relies on a specific workflow | 20:46 |
| Wizzup | well the d4 image boots for me :) | 21:01 |
| Wizzup | to salutem | 21:01 |
| 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? | 21:30 |
| Wizzup | humpelstilzchen[: do you know what we should change in the config? | 21:34 |
| Wizzup | humpelstilzchen[: maybe a PR to maemo/beowulf-devel makes sense: https://github.com/maemo-leste/pine64-kernel/commits/maemo/beowulf-devel | 21:34 |
| humpelstilzchen[ | Wizzup: still in testing phase, but looks really good. | 21:38 |
| Wizzup | humpelstilzchen[: ok, great | 21:38 |
| humpelstilzchen[ | Wizzup: ok, PR, edit an existing patch or create a new one? | 21:38 |
| 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 | 21:43 |
| uvos | i gues you should also report the problem to the maintainer of the kernel module(s) in question | 21:47 |
| humpelstilzchen[ | right | 21:50 |
| Wizzup | humpelstilzchen[: new patch is easier | 22:32 |
| humpelstilzchen[ | ok | 22:32 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!