buZz | on a vanilla config? | 00:05 |
---|---|---|
buZz | oh. 10mA more than 30mA ? | 00:05 |
buZz | freemangordon: yes it does! | 00:05 |
buZz | until the next missing mime mediatype, i bet ;) | 00:06 |
tmlind | hmm no idea what could have caused increased power consumption, don't think i've seen that with my kernel tests | 07:46 |
freemangordon | I will revert to the kernel before the patches to see if I get the same here | 08:12 |
freemangordon | with latest I have POWER_SUPPLY_POWER_AVG=125612 | 08:13 |
freemangordon | for POWER_SUPPLY_CURRENT_AVG=32458 | 08:13 |
freemangordon | tmlind: I see serial kernel threads in top with the patches | 08:19 |
tmlind | freemangordon: hmm i wonder which patch could cause that | 08:26 |
freemangordon | tmlind: wait, I am still not convinced we have an issue | 08:26 |
freemangordon | for how long I shall not touch the device in order to assume it has proper average power calculated? | 08:27 |
tmlind | i'd check once a minute if comparing | 08:29 |
freemangordon | ok | 08:29 |
freemangordon | so far I'd say it is better with the patches | 08:30 |
freemangordon | hmm. lets put accounts offline and set modest to check every 30 minutes | 08:32 |
freemangordon | without patches the lowest I got is: | 08:36 |
freemangordon | POWER_SUPPLY_CURRENT_AVG=31177 | 08:36 |
freemangordon | POWER_SUPPLY_POWER_AVG=116290 | 08:36 |
freemangordon | but most of the time idle avg current stays between 40-50mA | 08:37 |
freemangordon | tmlind: I see 2 more serial interrupts in /proc/interrupts with the patches, I guess that's normal | 08:45 |
freemangordon | what I don;t think is normal is having irq/112-48020000.serial:wakeup and irq/124-4806a000.serial:wakeup visible in top all the time | 08:46 |
buZz | is this with the kernel now in -devel? | 08:49 |
freemangordon | yes | 08:49 |
buZz | i'm not seeing those in top, at least not in a fully booted hildon? | 08:50 |
freemangordon | maybe serial gpios are not configured properly so they generate fake interrupts? | 08:50 |
freemangordon | OTOH I don;t see number of interrups to increase | 08:53 |
freemangordon | without patches I have average of the average power consumption over a period of 5 minutes (removing spikes) of 142.8mW | 09:00 |
freemangordon | with patches, under same conditions, it is 139.2 | 09:01 |
freemangordon | so I'd say there is no difference | 09:01 |
freemangordon | tmlind: still, is it normal that I see serial irqs here https://pastebin.com/rpUuKUEv? | 09:03 |
freemangordon | https://pastebin.com/rpUuKUEv | 09:03 |
tmlind | yes those are the threaded interrupt handlers for the padconf wakeup events | 09:07 |
freemangordon | yes, but I don;t see them without patches | 09:09 |
freemangordon | also, I have nothing connected to the serial, why are those active? | 09:09 |
tmlind | those are always active when a device is runtime suspended | 09:12 |
freemangordon | ok | 09:16 |
freemangordon | enabling online accounts (no iphb) increases power usage with ~40 mW | 09:27 |
uvos | 40mW is really terrible on d4 | 09:35 |
uvos | i get more like 25 ususally | 09:35 |
uvos | er mA | 09:35 |
uvos | "<freemangordon> but most of the time idle avg current stays between 40-50mA" | 09:36 |
uvos | but mW mesurements are more usefull | 09:37 |
uvos | as mA changes quite a bit with battery voltage | 09:37 |
uvos | (as you would expect) | 09:37 |
freemangordon | yes, that's why I measured power | 09:38 |
uvos__ | idk what was going on yesterday | 11:36 |
uvos__ | but its ideling at 90mW here rn | 11:36 |
uvos__ | so i gues the yesterdays excessive power usage was unrelated to the kernel patches. probubly | 11:37 |
freemangordon | maybe modem related | 11:37 |
uvos__ | it dose sometimes idle at 120mW with out explanation (allways has, only the xt875 dosent have that problem) | 11:38 |
uvos__ | but 150mW from yesterday was farily excessive+ | 11:38 |
uvos__ | freemangordon: maybe, no idea | 11:38 |
freemangordon | now testing if iphb makes any difference | 11:39 |
Wizzup | ah, cool | 11:41 |
freemangordon | ught, gabble is compiled without iphb support :( | 11:43 |
Wizzup | hey that's interesting news @ pvrsgx mail | 12:47 |
Wizzup | I wonder if they are fully aware of the X ddx that we use/have | 12:48 |
buZz | Wizzup: https://leste.maemo.org/Extras/MStarDict was what you had in mind for it, right? :) | 12:49 |
buZz | i'm not sure why a application has a device, i thought they were all pretty portable? | 12:49 |
uvos__ | Wizzup: what email are you talking about? | 12:49 |
uvos__ | buZz: some applications might need some specific hw feature, think compass usage excluding n900 or something | 12:53 |
uvos__ | but yeah its probubly not nessecary to fill that in usually | 12:54 |
buZz | right, but most do not i guess? should i just remove the device tag? | 12:54 |
Wizzup | uvos__: ah I thought it went to the list but didn't, I can fwd it to you | 12:54 |
Wizzup | buZz: looks good, maybe mention mor explicitly where the dictionaries are hosted | 12:55 |
buZz | Wizzup: okidoki | 12:55 |
buZz | but there's many many many sources of dicts | 12:55 |
buZz | even inside devuan | 12:55 |
buZz | stardict-english-czech/stable,stable 20171101-1 all | 12:56 |
buZz | stardict-german-czech/stable,stable 20171101-1 all | 12:56 |
Wizzup | hmmm, ok, it isn't clear to me that those can be used from the page | 12:57 |
Wizzup | I guess it's under the "Also" ? | 12:57 |
buZz | how's this? | 12:57 |
uvos__ | Wizzup: great | 12:57 |
buZz | if traffic gets nuts for those dicts i could move them to a leste server or whatever | 12:58 |
buZz | all dictionaries on that mirror that are linked in the .htmls are free to use/pd/gpl | 12:58 |
buZz | but there's some unlinked inside that are copyrighted i think? | 12:58 |
buZz | removing the device tag works well btw, i dont think this needs any | 13:00 |
Wizzup | buZz: I made some changes | 13:00 |
Wizzup | Can you elaborate some on espeak as well? | 13:00 |
buZz | yez | 13:00 |
Wizzup | also, maybe we ought to have a 'mstardict-alldict' pkg or something | 13:01 |
Wizzup | unless it's very very large | 13:01 |
Wizzup | :D | 13:01 |
buZz | well, there's no authority issueing stardict format dictionaries | 13:01 |
buZz | that stardict-dic mirror is 5.8GB | 13:02 |
Wizzup | buZz: is it distconv or dictconv btw | 13:02 |
buZz | dictconv | 13:02 |
Wizzup | wiki says distconv | 13:02 |
buZz | dangit :P | 13:02 |
freemangordon | Wizzup: please reply to that mail | 13:09 |
freemangordon | if we can convince andrew to help with pvr EXA on our x driver (HW accell compositing) that would be great | 13:10 |
buZz | Wizzup: i also think this program is more suitable for a 'few' dictionaries and not the whole mass of human knowledge :P | 13:10 |
freemangordon | as we already have everything else FOSS | 13:11 |
freemangordon | also, you may mention this https://github.com/maemo-leste/sgx-ddk-um/tree/master/dbm | 13:11 |
freemangordon | and mesa driver we have | 13:11 |
buZz | Wizzup: i elaborated on it and added a preferences screenshot too | 13:11 |
Wizzup | freemangordon: my understanding is that he'd make builds mostly | 13:20 |
Wizzup | freemangordon: ok, I can try, but I believe you know a -lot- more about this than I do | 13:20 |
freemangordon | I will join to the party later on if questions arise | 13:21 |
Wizzup | I'm afraid I might not be able to add enough context, but ok, I can try... | 13:21 |
freemangordon | ok, if you think it will be better, I will reply | 13:21 |
Wizzup | I think so, my only thought is that it'd be great if we know what builds we could use from him, and that over-asking might not be productive atm (but who knows, I don't know what the other 'good news' is) | 13:22 |
freemangordon | ok | 13:22 |
freemangordon | will do | 13:22 |
Wizzup | buZz: these espeak voices, where would they be placed, also in MyDocs/mstardict ? | 13:24 |
buZz | Wizzup: updated :) | 13:25 |
Wizzup | buZz: btw, the 'website' is set to a git repo, and the leste repo to another, I think they're one and the same so we can probably just link to our leste repo | 13:25 |
Wizzup | if there's no website that is | 13:25 |
buZz | there's no website, alright | 13:25 |
Wizzup | right | 13:25 |
buZz | the repo linked is the upstream where norayr was doing their dev work | 13:25 |
Wizzup | maybe the wayback link can be the website | 13:26 |
Wizzup | buZz: sure but it'll be out of date assuming norayr submits to the leste repo going forward | 13:26 |
buZz | thats for stardict, maybe the maemo.org thread? | 13:26 |
Wizzup | maybe, also not ideal imho, maybe just don't have one if there's no clear point | 13:27 |
buZz | alright, removed :) | 13:28 |
buZz | i explained some about the espeak now anyway | 13:28 |
buZz | the red is so ugly on its default colors :P maybe thats ugly enough to get me to edit it | 13:29 |
buZz | :D | 13:29 |
Wizzup | heh | 13:30 |
buZz | i think its hardcoded in libwrapper.cpp ? :/ | 13:33 |
norayr | hey i am here, let me soo what you are talking about. | 13:37 |
buZz | norayr: i wrote this ; https://leste.maemo.org/Extras/MStarDict | 13:38 |
buZz | and wizzup some | 13:38 |
norayr | wow thank you! | 13:39 |
norayr | feel free to make any changes to the repo in maemo-extras. | 13:41 |
norayr | did i leave somewhere a link to norayr/mstardict? it's not important anymore, you can delete it. | 13:41 |
norayr | and i am not planning much work on it. i was just able to port/package it, bring to life with some changes, not even sure that good changes. | 13:42 |
norayr | and i use it, since i use stardict dictionaries, and i have my own dictionaries converted from pdfs or other sources, and it is convenient. | 13:42 |
norayr | so i would be happy if anyone does something to it. | 13:43 |
buZz | hehe | 13:43 |
norayr | let's say i have no idea what to do with that on click function | 13:43 |
buZz | well, i'm annoyed by the red, not sure where it's originating from | 13:43 |
norayr | which tries to execute nokia browser. | 13:43 |
buZz | yeah its a html rendering i think | 13:43 |
norayr | red? | 13:43 |
norayr | ah! | 13:43 |
norayr | yeah feel free to push to the repo! | 13:44 |
buZz | i think it should somehow know to link to itself , but it doesnt | 13:44 |
buZz | hehe , well, if i can find it ;) | 13:44 |
norayr | yes true! | 13:44 |
buZz | this red ; https://leste.maemo.org/images/0/0d/MStarDict_Itemview.png | 13:44 |
norayr | you said once! | 13:44 |
norayr | wait | 13:44 |
norayr | on this screenshot | 13:44 |
buZz | si? | 13:44 |
norayr | i see the word is red | 13:45 |
buZz | indeed | 13:45 |
norayr | but it shoud non link to anything. | 13:45 |
norayr | i don't see links. | 13:45 |
buZz | correct | 13:45 |
buZz | this was just a example of 'a item' from 'a dictionary' | 13:45 |
buZz | but, the item title is always red | 13:45 |
buZz | regardless of colors of theme, etc | 13:45 |
norayr | yeah... i think it's possible to change it. | 13:45 |
norayr | at least to not be red, but have the same color as the rest of the text. | 13:46 |
norayr | i need a flickr app. will try to bring one to life. if it doesn't work, i'll try to write one by using flickurl. | 13:47 |
norayr | i remember one app for maemo was in qt and was very slow on n900. | 13:48 |
norayr | extremely slow. | 13:48 |
norayr | i had the impression that qt is slower on n900. | 13:48 |
norayr | did anyone have such an impression? | 13:48 |
uvos | its pretty much guarnteed qt4+ / gtk3+ are slower than gtk2 | 13:50 |
uvos | just beacuse how they render themselves | 13:50 |
norayr | doesn't gtk render itself via x? | 13:50 |
Wizzup | qt5 scrolls smoother than gtk2 for sure | 13:50 |
uvos | (potential for improved hw accel asside) | 13:50 |
Wizzup | right | 13:50 |
bencoh | norayr: I'd say that qt was slower than gtk on n900 as well yeah | 14:21 |
freemangordon | something werid happened to my device, now it idles @ 400 mW | 14:53 |
Wizzup | freemangordon: some drivers loaded? | 15:12 |
freemangordon | nothing changed IIUC | 15:14 |
Wizzup | maybe run omapconf? | 15:14 |
freemangordon | it shows the same | 15:15 |
freemangordon | I installed powertop, unfortunately it does not help much | 15:15 |
freemangordon | ogh | 15:15 |
freemangordon | what the? | 15:15 |
Wizzup | I had a problem with a droid that after I had it on psu for too long, it started drawing 16mA when turned off | 15:15 |
Wizzup | lab psu* | 15:16 |
Wizzup | was a hw problem I bet | 15:16 |
freemangordon | ok, I switched status from offline to online and back and it fixed the issue | 15:16 |
freemangordon | this does not make sense :) | 15:16 |
freemangordon | hmmm | 15:17 |
freemangordon | ok, it idles @ 120 mW now | 15:17 |
freemangordon | now I can test iphb | 15:18 |
Wizzup | yeah there is a problem where the modem doesn't idle in some states I think | 15:19 |
freemangordon | I am connected through wifi | 15:20 |
freemangordon | ah, I meat account status | 15:20 |
freemangordon | *meant | 15:20 |
freemangordon | not flight mode | 15:20 |
freemangordon | ok, without iphb and with 2 jabber accounts it idles @ ~155mW | 15:23 |
freemangordon | Wizzup: BTW, can we remove obsolete linux headers from the repo? | 15:26 |
Wizzup | sure, if you want, just let me know which exact ones you want removed | 15:27 |
freemangordon | ok | 15:28 |
freemangordon | so, with iphb I am seeing values as low as 125 mW | 15:28 |
Wizzup | this is over wifi I suspect? | 15:28 |
freemangordon | with same accounts online | 15:28 |
freemangordon | yes | 15:28 |
freemangordon | ok, lets stop iphb and try again | 15:29 |
freemangordon | hmm, seems iphb breaks it | 15:36 |
freemangordon | oh, it crashes :) | 15:38 |
sicelo | mmm, PVR email ... may i get a link? i thought i was in the correct ML, but I didn't get the mail | 15:44 |
freemangordon | sicelo: it is not in a ML | 16:00 |
sicelo | ah | 16:06 |
uvos | even 120 is very high @ freemangordon | 16:32 |
uvos | wakeups generally dont hurt the droid 4 nearly as mutch as the n900 btw | 16:35 |
uvos | since it can enter and exit idle way way faster than n900 | 16:36 |
uvos | even the mm compatction that creates a couple of hz of wakeups totaly prevents the n900 from ideling at all | 16:36 |
uvos | while on d4 the effect on power consumption wasent even mesurable | 16:37 |
uvos | so yeah just things to think about when optimizing | 16:37 |
freemangordon | well,, this is what I get here | 16:43 |
freemangordon | hints how to chase that are appreciated :) | 16:43 |
Wizzup | uvos: it was measurable on the d4 fwiw | 16:44 |
Wizzup | but not a lot | 16:44 |
freemangordon | uvos: keep in mind I measure that in ssh session | 16:44 |
freemangordon | I think each ssh session adds about 40 mW or something | 16:44 |
uvos | no | 16:44 |
uvos | idle ssh session is very low cost | 16:45 |
uvos | so if omapconf dosent change | 16:45 |
Wizzup | on gprs it actively causes the batery life to die 2-3 normal speed | 16:45 |
uvos | sure | 16:45 |
uvos | on gprs it causes the modem to stay awake | 16:45 |
Wizzup | having gprs active without ssh hardly impacts battery life | 16:46 |
uvos | anyhow if ompaconf dosent change, nothing is keeping the device awake permantently | 16:46 |
uvos | so that suggests something is using too mutch cpu time | 16:46 |
freemangordon | maybe tcp activity | 16:47 |
uvos | possible | 16:47 |
freemangordon | I'll run tcpdup to see what happens | 16:47 |
uvos | also if its tcp activity on the modem | 16:47 |
freemangordon | *tcpdump | 16:47 |
uvos | like ssh it will not enter idle state | 16:47 |
uvos | the modem takes qutie some time to calm down | 16:47 |
uvos | after you last used it | 16:47 |
freemangordon | lemme offile the modem | 16:47 |
uvos | for some reason offlineling the modem dosent really do anything pm wise | 16:48 |
freemangordon | well, what to do then? | 16:48 |
uvos | dont connect gprs? | 16:48 |
freemangordon | it is not connected | 16:48 |
uvos | then your not waking the modem | 16:49 |
freemangordon | I am using wifi all the time while measuring | 16:49 |
uvos | ok | 16:49 |
freemangordon | my wifi rooter is pretty ol, that might create issues too | 16:49 |
freemangordon | also, I think I have lowered RTS, lemme check | 16:49 |
freemangordon | well, rts threshold is 500, not that bad | 16:50 |
freemangordon | shoudl not affect power savings | 16:50 |
uvos | how manny wakeups do you have? | 16:51 |
freemangordon | sec | 16:51 |
uvos | should be 15 ish hz at very the most | 16:51 |
freemangordon | 30 | 16:51 |
freemangordon | now 10 | 16:52 |
uvos | sounds resonable | 16:52 |
uvos | first mesurement is allways high | 16:52 |
freemangordon | 9 | 16:52 |
uvos | sounds fine | 16:52 |
freemangordon | I am doing 'while [ 1 ]; do sleep 30; cat uevent | grep AVG; done' | 16:53 |
freemangordon | no issue with that,right? | 16:53 |
freemangordon | POWER_SUPPLY_POWER_AVG=222636 | 16:53 |
freemangordon | the fuck? | 16:53 |
freemangordon | ok, lemme run tcpdump | 16:54 |
freemangordon | uvos: what is the time window avg is calculated on? | 16:54 |
freemangordon | do you know? | 16:54 |
uvos | should be fine at reading uevent | 16:55 |
uvos | no but short | 16:55 |
uvos | its filtered for spikes | 16:55 |
uvos | not for long periods | 16:55 |
freemangordon | ok | 16:55 |
uvos | ie its seconds not minutes or anything | 16:55 |
freemangordon | this is what I get https://pastebin.com/iQjyKRZT | 16:56 |
freemangordon | does not look good | 16:56 |
freemangordon | let me see if using iphb will change that | 16:56 |
uvos | its about 50mW high yeah | 16:56 |
freemangordon | I guess because of the jabber accounts | 16:57 |
uvos | i wonder if reading uevent makes it higher | 16:58 |
freemangordon | for sure it does | 16:58 |
uvos | because the kernel goes and fetches more values than just reading power_avg | 16:58 |
freemangordon | hmm | 16:58 |
freemangordon | hmm.... | 16:58 |
freemangordon | right | 16:58 |
freemangordon | lemme try with just the average | 16:58 |
uvos | so by the time it fetches power_avg | 16:59 |
uvos | its been awake more | 16:59 |
freemangordon | yeah | 16:59 |
freemangordon | also grep keeps it awake for longer | 17:00 |
uvos | sure but thats after the read | 17:00 |
uvos | and the window isent 30 s long | 17:00 |
freemangordon | I think it is longer than 30s | 17:00 |
freemangordon | at least a minute | 17:01 |
uvos | i dont think so | 17:01 |
uvos | but wating 1 minute like i do | 17:01 |
uvos | would make the results more comperable in this case | 17:01 |
freemangordon | ok, lemme change the delay | 17:02 |
uvos | so doing what you do gives me 158990 btw | 17:03 |
uvos | while the cron job was saying 92 before | 17:03 |
uvos | so i dont think anythings wrong | 17:03 |
freemangordon | hmm | 17:04 |
uvos | or wrogner than here :P | 17:04 |
freemangordon | 108292 | 17:04 |
uvos | android dose 30mW | 17:04 |
freemangordon | for 1 minute with iphbd | 17:04 |
uvos | or so | 17:04 |
freemangordon | but we don;t have off mode? | 17:04 |
uvos | right | 17:04 |
freemangordon | btw, why? | 17:05 |
uvos | was never implmented in the mainline kernel | 17:05 |
uvos | for omap4 | 17:05 |
freemangordon | ah | 17:05 |
Wizzup | would be nice to have ofc :p | 17:05 |
freemangordon | maybe we shall pester tmlind :) | 17:05 |
freemangordon | I'll leave it running for 10 minutes and then will do the same without iphbd | 17:10 |
uvos | speaking of off mode | 17:12 |
uvos | the other 2 things the android kernel dose that we dont pm wise | 17:12 |
uvos | is clock sgx down and change the emif operating point | 17:12 |
uvos | this is probubly the reason we use more power while not idle | 17:13 |
freemangordon | I don't think clocking sgx down will help a lot | 17:13 |
freemangordon | no idea what emif is | 17:13 |
uvos | momory bus | 17:13 |
freemangordon | ah | 17:13 |
uvos | memory bus | 17:13 |
uvos | idk how mutch these things account for and wont speculate | 17:14 |
freemangordon | I think our buggest issue is dss being on | 17:14 |
freemangordon | because sgx is idle most of the times | 17:15 |
freemangordon | basically sgx clocks are stopped as soon as there is nothing for it to render | 17:15 |
freemangordon | IIUC | 17:15 |
uvos | this broke after swiching form ddk1.9, but you said it works again | 17:16 |
uvos | so sure | 17:16 |
freemangordon | yes, you can check in /kernel/debug | 17:16 |
freemangordon | it is OFF even when display is ON | 17:16 |
uvos | ok | 17:16 |
freemangordon | ok, some results: | 17:31 |
freemangordon | iphb on: 10 samples average: 158.5mW, lowest reading 105.6, 8 samples average (highest and lowest samples removed): 155.2 | 17:31 |
freemangordon | iphb off: 10 samples average: 182.8mW, lowest reading 132.6, 8 samples average (highest and lowest samples removed): 182.2 | 17:31 |
freemangordon | uvos: ^^^ | 17:31 |
uvos | im not sure why iphb would hurt | 17:32 |
freemangordon | well, you was against it IIRC | 17:33 |
uvos | im skepitcal it would help (much) | 17:33 |
uvos | but thats different from it hurting | 17:33 |
freemangordon | ~25mW on average for 2 jabber accounts is lots IMO | 17:33 |
uvos | yes | 17:33 |
uvos | how often dose it try and refesh? | 17:34 |
freemangordon | every 30 seconds iiuc | 17:34 |
freemangordon | but with iphb this gets synced, so you have only one wake for both accounts | 17:34 |
freemangordon | the more users the more the saving will be | 17:35 |
freemangordon | like, modest supports iphb as well | 17:35 |
uvos | sure | 17:35 |
uvos | but also why dose telepathy not sync refreshes with itself | 17:35 |
uvos | why dose it need the kernel to do that | 17:35 |
uvos | also maybe there is some other way to accive the same thing, besides introducing a custom kernel module | 17:36 |
freemangordon | no, wait | 17:36 |
freemangordon | kernel module is used in a different way | 17:36 |
freemangordon | it just signals userland that there is something to be send over the wire | 17:37 |
freemangordon | so radios will be on anyways | 17:37 |
uvos | sure | 17:37 |
freemangordon | so, if there are clients whose wake time is nearby, just wake them up now | 17:37 |
uvos | i also wonder how android handels this | 17:37 |
freemangordon | no idea | 17:37 |
uvos | alot of android patches ended up in mainline | 17:37 |
uvos | (android boots on mainline now basicly) | 17:37 |
freemangordon | well, wakelocks :) | 17:38 |
freemangordon | I would bet on that | 17:38 |
uvos | possible | 17:38 |
freemangordon | so maybe it is more or less the same, besides I don;t know how it communicates when kernel tcp stack has something to send | 17:39 |
freemangordon | how feasible is to have pre-build kernel module in the repos? | 17:40 |
freemangordon | instead of doing dkms build | 17:40 |
uvos | would be quite the headache i imagine | 17:40 |
freemangordon | ok, lets stick to dkms for now | 17:41 |
uvos | we could also just add it to the kernel | 17:41 |
uvos | its not like its relevant on x86 | 17:41 |
uvos | and everywhere else we build the kernel anyhow | 17:42 |
freemangordon | I prefer dkms way | 17:42 |
freemangordon | otherwise it will not be possible to test on the VM | 17:43 |
freemangordon | uvos: Wizzup: why linux-headers-generic is not provided by omap kernel headers? | 17:54 |
freemangordon | omap kernel headers package that is | 17:54 |
freemangordon | do you mind if I add it? | 18:13 |
Wizzup | not sure why it is like that | 18:18 |
Wizzup | I mean if it provides the headers | 18:18 |
Wizzup | then yes | 18:18 |
freemangordon | it provides linux-headers, but IIUC virtual package should be linux-headers-generic | 18:19 |
freemangordon | at least this is what is provided by amd64 devuan kernel | 18:19 |
freemangordon | here https://github.com/maemo-leste/droid4-linux/blob/maemo/beowulf-devel/debian/control#L31 | 18:20 |
Wizzup | ok | 18:20 |
freemangordon | ok, going to change that | 18:20 |
freemangordon | hmm ok, actually this is the correct virtual package name | 18:30 |
freemangordon | Wizzup: please remove linux-headers-n900 and linux-headers-droid4 packages | 18:30 |
freemangordon | oh, you can;t | 18:31 |
freemangordon | I shall disable -stable repo | 18:32 |
freemangordon | Wizzup: is -omap kernel in -stable? | 18:32 |
freemangordon | yes, it is | 18:33 |
freemangordon | so, I think we shall remove all the old n900/droid4 kernels | 18:33 |
freemangordon | Pali: do you mind if I become the maintainer https://github.com/maemo-leste/iphb-dkms/blob/master/debian/control#L4 ? | 18:36 |
freemangordon | I assume no, if you onject, please LMK and I'll revert | 18:37 |
freemangordon | *object | 18:38 |
Pali | I'm fine with it! | 18:44 |
freemangordon | ok, thanks | 18:44 |
Wizzup | freemangordon: I can remove any pkg if needed | 18:51 |
freemangordon | Wizzup: please remove all old kernels (and headers) then | 18:54 |
freemangordon | they are not used anyways | 18:54 |
freemangordon | and just create trouble | 18:54 |
Wizzup | freemangordon: ok, can you be explicit? | 19:03 |
Wizzup | linux-headers-n900 and linux-headers-droid4 ? | 19:04 |
Wizzup | if we do that, and remove it from stable too, we also need a replacement for it for -stable usres | 19:05 |
freemangordon | we already have | 19:08 |
Wizzup | ok | 19:08 |
freemangordon | https://github.com/maemo-leste/droid4-linux/blob/maemo/beowulf/debian/control#L31 | 19:09 |
freemangordon | see ^ | 19:09 |
Wizzup | ok | 19:15 |
Wizzup | done | 19:16 |
freemangordon | thanks | 19:17 |
freemangordon | Wizzup: wich package to add dependency to? | 21:17 |
freemangordon | hildon-connectivity-meta? | 21:17 |
Wizzup | freemangordon: for what package? | 21:36 |
freemangordon | iphbd | 21:37 |
freemangordon | the daemon itself | 21:37 |
Wizzup | I think hildon-connectivity-meta is fine for now | 21:41 |
freemangordon | ok | 21:41 |
Wizzup | will it depend on the dkms pkg too? | 21:43 |
freemangordon | iphbd depends on it | 21:46 |
freemangordon | so meta needs only iphbd dependency | 21:46 |
Wizzup | ok | 21:53 |
Wizzup | let's make it -devel only for now? | 21:53 |
freemangordon | sure | 21:53 |
freemangordon | will you add that dependency? | 21:53 |
Wizzup | I can in a few minutes | 21:54 |
freemangordon | ok | 21:54 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!