| Wizzup | maybe dpkg --force-all -r gconf2 dbus-x11 and then re-install them | 01:39 |
|---|---|---|
| Wizzup | (to reproduce) | 01:39 |
| Wizzup | or perhaps some other pkg/deb of gconf2 | 01:40 |
| Wizzup | maybe we need to locally build a 'newer' gconf2 and install that, see if that causes it | 01:53 |
| freemangordon | Wizzup: doing 'dpkg -i gconf2-common_3.2.6-8_all.deb' allows dist-upgrade with (almost) no issues | 09:25 |
| freemangordon | so I think we shall fork gconf2 and make gconf2 binary package to pre-depend on gconf2-common | 09:26 |
| freemangordon | I can;t think of any better solution | 09:26 |
| gnarface | someone else in #devuan should have some idea why it's not that way already... | 10:27 |
| gnarface | weird to me that everyone isn't running into the same issue over there though | 10:29 |
| Wizzup | freemangordon: ok, I am happy to do that if you're sure this is it | 11:10 |
| Wizzup | freemangordon: do you know why gconf2-common? | 11:11 |
| Wizzup | gnarface: if you google for the gconf2 -> gconf2 dep problem oyu'll find some threads from years ago for ubuntu/debian based distros that have this issue | 11:11 |
| Wizzup | I suspect gconf just isn't widely used for a while anymore | 11:11 |
| gnarface | it also occurs to me now that maybe it's just that something else that depends on those packages usually pulls them in in the right order in common configurations. i believe i do recall seeing dependency errors slip through to stable for that reason before | 11:18 |
| gnarface | i also mostly run headless servers, and of the few graphical desktops i have, most of them don't use a graphical login manager, so that might also be why i haven't seen it here | 11:19 |
| Wizzup | well, gconf is replaced by gsettings for a while now | 11:20 |
| gnarface | i seem to have both installed on this system, but it has been through a lot of upgrades | 11:29 |
| freemangordon | Wizzup: I am not sure | 11:32 |
| freemangordon | like, I am not sure what I proposed will fix the issue | 11:33 |
| freemangordon | but, I think we can try it | 11:33 |
| freemangordon | do you want me to do the fork? | 11:34 |
| freemangordon | why gconf-common: because it contains files that trigger gconf2 trigger | 11:35 |
| freemangordon | hmm, wait | 11:37 |
| freemangordon | because it contains /usr/share/sgml/gconf/gconf-1.0.dtd | 11:37 |
| freemangordon | and seems this trigger sgml trigger | 11:37 |
| freemangordon | *triggers | 11:37 |
| freemangordon | anyway, I *think* pre-depends trick will do it | 11:38 |
| gnarface | the thing is, it should have been fixed already upstream long ago, so the real question is why it isn't | 11:44 |
| freemangordon | because gconf is no longer supported | 11:44 |
| freemangordon | everyone moved to gsettings | 11:45 |
| gnarface | officially no longer supported or just de-facto no longer supported? | 11:45 |
| gnarface | because the latter, it's still their job to fix | 11:45 |
| freemangordon | afaik in unstable it is officially unsupported | 11:46 |
| freemangordon | in stable it is de-facto unsupported | 11:46 |
| freemangordon | that's my understanding | 11:46 |
| freemangordon | also, if we have a quick-fix in our repos, I'd rather not deal with debian issue tracker :) | 11:46 |
| gnarface | yea but daedalus is still stable, so whatever happened in unstable after that, it's against their own rules to change retroactively in previous relases | 11:46 |
| gnarface | no, no, i get that. i really get that. but the situation isn't made any better by letting them shirk their own rules. | 11:47 |
| freemangordon | agree, but we really don;t have the manpower/spare time to fight that battle | 11:47 |
| freemangordon | to be really sure this is not our fault (not that I can see how it could be), I have to install chimaera (not leste) in a VM and then dist-upgrade | 11:48 |
| freemangordon | hmm.. even not that | 11:48 |
| gnarface | in the past, one reason this type of thing might get skimmed over is because systemd actually fixes up the installation order through its own dependencies, in which case we've seen blatant hostility when attempting to hold them to their own rules, but even just being able to collect links to all such bug reports getting refused still helps our cause in the long run... | 11:49 |
| gnarface | but i do sympathize with not wanting to bother | 11:49 |
| freemangordon | I will have to install bullseye and try-to dist-upgrade to bookworm | 11:49 |
| freemangordon | and I bet it will not fail | 11:50 |
| gnarface | there was someone in #devuan who had made a sort hobby of putting through bug reports like this that we knew ahead of time would get refused without valid cause though, maybe you could hook up with them, since it's possible this still affects devuan stable and just nobody has noticed | 11:50 |
| gnarface | (and maybe this conversation already happened over there but i just forgot because i smoke too much weed) | 11:51 |
| freemangordon | :D | 11:51 |
| freemangordon | yeah, that's a well known side-effect | 11:51 |
| freemangordon | gnarface: I'd rather first try to fix it in our repos | 11:52 |
| freemangordon | that report on #devuan, so if anyone is interested to just pull the fix | 11:52 |
| freemangordon | s/that/then | 11:53 |
| Wizzup | freemangordon: we already forked it | 11:55 |
| Wizzup | no nee to re-do the work | 11:55 |
| Wizzup | freemangordon: I don't see a rule to trigger on sgml dir | 11:55 |
| freemangordon | yeah, I saw | 11:56 |
| Wizzup | maybe we can try to create some minimal reproduce case where we build gconf locally, increase the version, remove/reinstall it and some other deps and see if it triggers the problem | 11:56 |
| freemangordon | whay not put it in daedalus repo? | 11:57 |
| freemangordon | *why | 11:57 |
| freemangordon | I don;t think we can repro | 11:57 |
| freemangordon | if not in the repos I mean | 11:57 |
| freemangordon | Wizzup: so, I will pull gconf, drop the directory change commit, add pre-depends | 11:57 |
| freemangordon | ok? | 11:58 |
| Wizzup | what directory change commit? | 11:58 |
| freemangordon | https://github.com/maemo-leste-upstream-forks/gconf/commit/d067769eaafd8ee30208adcfa6215721d9ba8625 | 11:58 |
| Wizzup | hm, what difference does this make | 11:59 |
| Wizzup | remember we also had this problem going from beowulf to chimaera | 11:59 |
| Wizzup | afaik | 11:59 |
| Wizzup | and then we also had not forked gconf | 11:59 |
| freemangordon | it is sglm trigger that's triggered by gconf-common | 12:00 |
| Wizzup | In what triggers file | 12:00 |
| freemangordon | sec | 12:00 |
| Wizzup | I don't see it in gconf2.triggers | 12:00 |
| Wizzup | or do you mean there is some other pkg that triggers on gconf-common files | 12:01 |
| freemangordon | yes | 12:01 |
| freemangordon | /var/lib/dpkg/triggers/File:/usr/share/sgml sgml-base | 12:01 |
| freemangordon | and gconf-common contains /usr/share/sgml/gconf/gconf-1.0.dtd | 12:02 |
| freemangordon | and it seems somehow sgml-base triggers gconf triggers | 12:03 |
| freemangordon | but gconf2 is not configuerd yet | 12:03 |
| freemangordon | and we have a cyclic dependency | 12:03 |
| Wizzup | does sgml depend on sgml? | 12:04 |
| Wizzup | er on gconf | 12:04 |
| freemangordon | no | 12:04 |
| freemangordon | not directly | 12:04 |
| Wizzup | hm, I thought the triggers were only 'interest' | 12:04 |
| Wizzup | if this is the case then mabye apt install --reinstall sgml gconf2 gconf-common can reproduce this | 12:04 |
| freemangordon | check /var/lib/dpkg/triggers | 12:04 |
| Wizzup | or maybe dpkg --force-all -r them first | 12:04 |
| freemangordon | I tried to apt-install gconf-common | 12:05 |
| freemangordon | this reproduces it | 12:05 |
| Wizzup | can you give me exact commands to reproduce? | 12:05 |
| freemangordon | sudo apt install gconf-common is enough | 12:05 |
| Wizzup | isn't that already installed? | 12:06 |
| freemangordon | it is | 12:06 |
| freemangordon | but on upgrade it errors out | 12:06 |
| Wizzup | ok, so you manually bumped the version | 12:06 |
| freemangordon | lemme check something | 12:06 |
| freemangordon | bumped? no, I did apt-get download gconf2-common | 12:06 |
| freemangordon | and then dpkg -i the package | 12:07 |
| Wizzup | how do you upgrade if the version isn't higher is what I mean | 12:07 |
| freemangordon | it is higher | 12:07 |
| freemangordon | it is 3.2.6-7 in chimaeara and 3.2.6-8 in daedalus | 12:07 |
| freemangordon | Wizzup: all this is with daedalus repos enabled in sources.list | 12:08 |
| freemangordon | you want top repro on chimaera? | 12:08 |
| freemangordon | *to | 12:08 |
| freemangordon | so: | 12:08 |
| freemangordon | 1. change repos from chimaera to daedalus in sources.list and sources.list.d | 12:09 |
| freemangordon | 2. sudo apt update | 12:09 |
| freemangordon | 3. apt-get download gconf2-common | 12:09 |
| Wizzup | ok, I will try that then, but sounds like just building gconf locally with -9 instead of -8 can also work no? | 12:09 |
| freemangordon | sudo dpkg -i gconf2-common_3.2.6-8_all.deb | 12:09 |
| freemangordon | no | 12:09 |
| Wizzup | brb | 12:09 |
| freemangordon | because | 12:09 |
| freemangordon | ok | 12:09 |
| freemangordon | I'll just do what I think is right, lets see | 12:12 |
| Wizzup | ok | 12:26 |
| freemangordon | Wizzup: gnarface: https://paste.debian.net/1347862/ | 12:38 |
| freemangordon | Wizzup: going to try full dist-upgrade | 12:39 |
| freemangordon | Wizzup: do we have a fix for https://paste.debian.net/1347864/ ? | 12:43 |
| Wizzup | freemangordon: that should not hgappen | 12:51 |
| Wizzup | freemangordon: do you have apt/preferences.d? | 12:52 |
| Wizzup | or shall I make a leste-config change to add those files | 12:52 |
| freemangordon | I don;t have | 12:53 |
| freemangordon | sec, to show you something | 12:54 |
| freemangordon | Wizzup: https://paste.debian.net/1347865/ | 12:54 |
| freemangordon | this is what AI thinks about that issue | 12:54 |
| freemangordon | Wizzup: so yes, make leste-config change | 12:56 |
| Wizzup | ok, let me do it | 12:57 |
| Wizzup | for chimaera | 12:57 |
| freemangordon | no, for daedalus | 12:58 |
| freemangordon | hmm... | 12:58 |
| freemangordon | not ssure | 12:58 |
| freemangordon | I guess for both | 12:58 |
| freemangordon | so we pin our packages above those from debian | 12:59 |
| Wizzup | for chimaera I think | 12:59 |
| Wizzup | ok yeah for both | 12:59 |
| freemangordon | mhm | 12:59 |
| freemangordon | I'll try to dist-upgrade without doing upgrade first | 12:59 |
| freemangordon | (once new leste-config is in the repo) | 12:59 |
| Wizzup | you should upgrade first | 13:00 |
| freemangordon | to see if it will upgrade properly | 13:00 |
| freemangordon | I knw :) | 13:00 |
| freemangordon | *know | 13:00 |
| freemangordon | but I want to test what will happen if I do not upgarde first | 13:00 |
| freemangordon | and I think it will be fine, but want to confirm | 13:01 |
| freemangordon | maybe we'll need pre-depends: leste-config-common in the meta | 13:01 |
| Wizzup | what you will get is the warning that you just got I think | 13:02 |
| Wizzup | I will put it in chimaera-devle first | 13:03 |
| freemangordon | ok | 13:03 |
| freemangordon | ah, ok, we have a warning :) | 13:04 |
| freemangordon | Wizzup: can't we hire some debian/devuan guy to manage our repos? :) | 13:34 |
| freemangordon | Wizzup: in debian/control: | 13:36 |
| freemangordon | XB-Maemo-Flags: reboot, system-update | 13:36 |
| freemangordon | I think if you put that in hildon-meta, HAM will show "system upgrade" | 13:37 |
| freemangordon | we shall fix repos first ofc | 13:37 |
| Wizzup | freemangordon: parazyd used to do that for us | 13:38 |
| freemangordon | I know | 13:39 |
| Wizzup | freemangordon: ok, hildon meta shows up now in regular ham | 14:32 |
| Wizzup | I will make the same changes for daedalus and then try a dist upgrade | 14:32 |
| Wizzup | it also reboots and says 'operating system upgraded' btw | 14:33 |
| Wizzup | freemangordon: for dist-upgrade to work we also need to add devuan repos to ham catalog | 14:38 |
| Wizzup | how else will the user get the upgrades | 14:39 |
| Wizzup | freemangordon: yeah, I made a switch to daedalus repos and cssu thinks the system upgrade wil l download 7kB :) | 14:53 |
| Wizzup | so I don't think dist-upgrade will work this way | 14:54 |
| Wizzup | as expected, it doesn't ensure every pkg is fully up to date, it just checks if some deps are satisfied | 14:54 |
| Wizzup | so we'd have to version/pin everything in hildon-meta for this to work | 14:54 |
| Wizzup | and even then it won't do the same for devuan pkgs | 14:55 |
| Wizzup | I will check with red pill mode | 14:55 |
| Wizzup | that helps, but it is still not very clever with dep handling :( | 14:59 |
| Wizzup | we probably want it to act like dist-upgrade and not like upgrade | 15:00 |
| Wizzup | freemangordon: see doc/packaging.txt section ### Installation and removal policy | 15:01 |
| Wizzup | it seems like HAM can't do dist upgrades | 15:05 |
| Wizzup | but we can use it for regular updates if we pin everything version wise | 15:06 |
| gnarface | freemangordon: strangely, what i recall those locales errors from is danctnix arch on my pinephone... fix involved the choice of either a force reinstall of some particular package or just delete the whole locale cache directory first, i think | 15:16 |
| gnarface | i forget which package | 15:16 |
| Wizzup | what locale errors? | 15:17 |
| gnarface | (in this paste: https://paste.debian.net/1347862/) | 15:18 |
| gnarface | towards the end | 15:18 |
| Wizzup | for the two char ones? | 15:18 |
| gnarface | i assume you could also just "dpkg-reconfigure locales" but not sure | 15:18 |
| Wizzup | not sure if that's not on us | 15:19 |
| gnarface | i think it's not. there was something wrong with one of those packages on arch anyway | 15:19 |
| gnarface | might have been an easy thing to cause though | 15:20 |
| gnarface | looks similar to the arch error i recall but i think there may have been more of them... | 15:20 |
| Wizzup | freemangordon: maybe we need a button that does 'DEBIAN_FRONTEND=noninteractive apt dist-uprade' :D | 15:20 |
| Wizzup | upgrade* even | 15:20 |
| Wizzup | gnarface: we had some local issues but those were related to qemu/glib bug in image builder | 15:21 |
| Wizzup | locale | 15:22 |
| Wizzup | freemangordon: should we also build fixed pre-depend gconf for chimaera | 15:55 |
| Wizzup | (we also need to re-build for excalibur, but that is for later) | 15:55 |
| freemangordon | Wizzup: don't think we should build gconf for chimaera, do we have any issue with it? | 16:14 |
| freemangordon | where is this "doc/packaging.txt"? | 16:16 |
| Wizzup | freemangordon: yes, we have the same issue if it gets reinstalled | 16:19 |
| Wizzup | freemangordon: hildon-application-manager | 16:19 |
| Wizzup | it says it's not menat for dist-upgrade type scenarios | 16:19 |
| Wizzup | literally | 16:19 |
| freemangordon | I see | 16:19 |
| Wizzup | I tried it and it was complaining that python-is-python2 was being uninstalled | 16:19 |
| Wizzup | (to be replaced with python-is-python3) | 16:19 |
| Wizzup | dist-upgrade has no such problems | 16:19 |
| freemangordon | do you know what is the difference between upgrade and dist-upgrade? | 16:20 |
| Wizzup | and also, it doesn't update packages unless they have the maemo Section: - which most of ours do not have | 16:20 |
| Wizzup | yes | 16:20 |
| Wizzup | I googled it | 16:20 |
| Wizzup | I think upgrade won't remove any pkgs | 16:21 |
| Wizzup | https://askubuntu.com/questions/194651/why-use-apt-get-upgrade-instead-of-apt-get-dist-upgrade | 16:21 |
| freemangordon | I see | 16:21 |
| Wizzup | so, we cannot use ham for dist-upgrades | 16:21 |
| Wizzup | but we can use it for upgrades to the system with specially crafted meta files | 16:22 |
| freemangordon | re maemo section: as I said, we just need to add a dependency to lets say glibc in daedalus | 16:22 |
| Wizzup | (it's too bad it can't just use the apt dist-upgrade logic tbh) | 16:22 |
| Wizzup | you can try it but I am 99% that won't work | 16:22 |
| Wizzup | 99% sure | 16:22 |
| freemangordon | why would in not? | 16:22 |
| Wizzup | why would it help to pull in new libc? | 16:22 |
| Wizzup | most pkgs don't care about the libc version | 16:23 |
| Wizzup | and it's also a hack for sw that doesn't properly resolve dependencies | 16:23 |
| freemangordon | yeah, agree | 16:23 |
| freemangordon | Wizzup: I think we can use HAM, just have to create a metapackage with the correct dependencies (and conflicts) | 16:26 |
| freemangordon | Wizzup: so, we can do apt upgrade and then check what has not been upgraded with apt dist-upgrade | 16:30 |
| freemangordon | and then include that in the metapackage | 16:30 |
| * freemangordon tries | 16:31 | |
| Wizzup | I don't think this will even work | 16:33 |
| Wizzup | it will fail immediately | 16:33 |
| Wizzup | I don't really see the point, then just make ham act like apt | 16:33 |
| freemangordon | Wizzup: did you push the new leste-config? | 16:38 |
| freemangordon | ah, seems yes | 16:38 |
| freemangordon | hmm: | 16:41 |
| freemangordon | N: Ignoring file 'pin-daedalus-extras.leste' in directory '/etc/apt/preferences.d/' as it has an invalid filename extension | 16:41 |
| freemangordon | N: Ignoring file 'pin-daedalus.leste' in directory '/etc/apt/preferences.d/' as it has an invalid filename extension | 16:41 |
| gnarface | has to end with .pref | 16:41 |
| freemangordon | yeah | 16:42 |
| Wizzup | I don't think it has to end in anything | 16:42 |
| Wizzup | this is just a result of our gen-displace | 16:43 |
| gnarface | you might want to start the names with digits too, so you can control the order they load | 16:43 |
| Wizzup | it's hardless | 16:43 |
| Wizzup | harmless | 16:43 |
| Wizzup | there is pin-daedalus and pin-daedalus-extras | 16:43 |
| Wizzup | as you can see | 16:43 |
| Wizzup | next to the .leste versions | 16:43 |
| freemangordon | I know its harmless, but will appear on every upgrade | 16:43 |
| Wizzup | yes, until we remove it again in the near future | 16:43 |
| Wizzup | no real way to solve it, I think we just live with it | 16:44 |
| freemangordon | can;t we just provide the real files? | 16:44 |
| freemangordon | why we have to divert? | 16:44 |
| freemangordon | or whatever we do? | 16:44 |
| Wizzup | feel free to try, I don't have the time to focus on this | 16:44 |
| Wizzup | we install all files this way | 16:45 |
| freemangordon | try what, sorry | 16:45 |
| Wizzup | feel free to try to install them throug the pkg | 16:45 |
| freemangordon | hmm, ok | 16:45 |
| Wizzup | I think it's a waste of time | 16:45 |
| Wizzup | we just remove the divert in a couple of weeks/months | 16:45 |
| Wizzup | we don't even need the divert in daedalus anyway, only in chimaera | 16:45 |
| freemangordon | ok | 16:46 |
| freemangordon | hmm, I think it is better to keep the priorities | 16:46 |
| freemangordon | I don;t want newer mesa to come from backports, for example | 16:46 |
| freemangordon | but ok | 16:46 |
| freemangordon | Wizzup: so, do we have any other issue? | 16:59 |
| freemangordon | or I shall dist-upgrade my d4? | 16:59 |
| freemangordon | I guess we'll have issues with upower | 17:06 |
| freemangordon | sicelo: did you try to contact upower maintainers? | 17:10 |
| sicelo | no, haven't. tbh i'm not even sure what we would ask for | 17:16 |
| freemangordon | well, you said some patches were rejected | 17:17 |
| sicelo | a part of me does just think we should hack our kernel and call it a day. it's only a problem with N900 and mapphones (at least D4), so maybe not rock the whole boat just for these | 17:18 |
| sicelo | yes, my patches were rejected, and i don't know what would change now. of course, seems the new maintainer is more open, so there might be a chance | 17:19 |
| freemangordon | ok, what is that problem we have on d4 and n900? | 17:21 |
| freemangordon | I really didn't follow back then | 17:21 |
| sicelo | at some point, both do not report a percentage/capacity | 17:22 |
| sicelo | that's the only problem | 17:22 |
| freemangordon | do they report charge level? | 17:22 |
| freemangordon | like low, high, etc? | 17:22 |
| freemangordon | at least d4 do I think | 17:23 |
| sicelo | yes. cpcap driver has hardcoded them to certain voltage levels (it's really a hack). n900 also has them (they're based on status flags in the hardware) | 17:23 |
| sicelo | but, upower doesn't care one bit about that | 17:24 |
| freemangordon | ok, so, we can as would they accept a patch that makes upower use that data when there is no capacity/percentage reported | 17:24 |
| freemangordon | *can ask | 17:24 |
| sicelo | it's exactly what i asked ... with disastrous ending :-) | 17:25 |
| sicelo | but, maybe current maintainer would | 17:25 |
| freemangordon | right, but you said minatiner changed | 17:25 |
| freemangordon | at least they may give us ideas what to do | 17:25 |
| freemangordon | ok, let me dist-upgrade my d4 to see how would it behave with that new upower | 17:27 |
| sicelo | for the question you just asked, please do read https://gitlab.freedesktop.org/upower/upower/-/merge_requests/188 ... only the comments if you have limited time :-) | 17:27 |
| sicelo | maybe you can see where things went south in the communication, and perhaps how to express it better in future | 17:27 |
| freemangordon | ok, will have a look later on | 17:33 |
| sicelo | < freemangordon> ok, so, we can as would they accept a patch that makes upower use that data when there is no capacity/percentage reported ... in reality, our drivers report 0 at that point | 17:36 |
| sicelo | to which the previous maintainers said "Right now, it's garbage in, garbage out. If we start assigning specific meaning to capacity = 0 or returning errors from reading some files, this needs to be documented so that the next driver writer that needs the same functionality isn't making their own stuff up that we'll need to work-around in upower" | 17:37 |
| fmg_d4 | daedalus d4 | 17:40 |
| sicelo | awesome | 17:42 |
| arno11 | cool | 17:52 |
| Wizzup | freemangordon: really great to have the gconf issue solved | 20:08 |
| freemangordon | yeah, my d4 dist-upgraded without any issue whatsoever | 20:18 |
| Wizzup | do calls still work? :D | 20:19 |
| freemangordon | yes | 20:19 |
| Wizzup | cool | 20:19 |
| freemangordon | mhm | 20:19 |
| Wizzup | I'll dist upgrade as well then | 20:19 |
| freemangordon | I mad an image of the SD card, just in case | 20:20 |
| freemangordon | *made | 20:20 |
| Wizzup | btw, I did make some progress with ham and doing sys upgrades | 20:20 |
| freemangordon | like? | 20:20 |
| Wizzup | well, I got it to show, disable the ui, reboot, say the operating system was upgraded successfully | 20:21 |
| Wizzup | like, things work | 20:21 |
| Wizzup | just not for dist-upgrade | 20:21 |
| freemangordon | ah | 20:21 |
| Wizzup | so we can either start adding the right section for all our sw, or we have to make a meta that pulls in these various pkgs and pins the required version to tell ham (which is a little dumb) that is has to upgrade them | 20:21 |
| freemangordon | yeah, for dist-upgrade we'll have to come-up with something else | 20:21 |
| Wizzup | I bet aptitude could do it, or some other ui | 20:21 |
| Wizzup | I think for now we can just ask the power users to use dist upgrade | 20:21 |
| freemangordon | but I guess we can do that fro the futore | 20:22 |
| freemangordon | mhm | 20:22 |
| freemangordon | I guess all of our current user base can do | 20:22 |
| freemangordon | anyway, bbl, the kid from Amsterdam is here, want to spend some time with | 20:23 |
| Wizzup | :) | 20:29 |
| freemangordon | Wizzup: hmm power usage seems very high | 20:33 |
| Wizzup | could be tracker re-indexing | 20:38 |
| arno11 | pretty sure | 20:47 |
| arno11 | so to resume: issues are solved, right ? then dist-upgrade from chimaera is supposed to work only from chimaera-devel or could it work from 'stable' ? | 20:52 |
| freemangordon | Wizzup: does not seem to be tracker | 21:00 |
| freemangordon | oh, scratch that | 21:02 |
| freemangordon | Wizzup: do not upgrade yet | 21:03 |
| freemangordon | this is still chimaera I see that big power usage | 21:03 |
| Wizzup | freemangordon: ok, I am confused :) | 21:03 |
| freemangordon | well... | 21:04 |
| freemangordon | I am fighting some cold and not very focused :) | 21:04 |
| freemangordon | so I was about to dist-upgarde | 21:04 |
| Wizzup | i dist upgraded my n900 to daedalus and didn't see any problems but I did not look super hard | 21:04 |
| freemangordon | but only upgraded | 21:04 |
| Wizzup | 2 days ago I think | 21:04 |
| Wizzup | says 1 day of battery at 99% | 21:05 |
| Wizzup | which is normal for my n900 | 21:05 |
| freemangordon | however, ahve to find the reasopn for that high power usage first | 21:05 |
| freemangordon | yeah, it is somehitng here on that device | 21:05 |
| Wizzup | maybe it is just you who sees it | 21:05 |
| freemangordon | mhm | 21:05 |
| freemangordon | most-probably | 21:05 |
| arno11 | Wizzup: calls still work btw ? | 21:07 |
| freemangordon | so, I am running dist-upgrade now | 21:09 |
| Wizzup | arno11: will check tomorrow | 21:10 |
| sicelo | arno11: fmg said Yes. anyway, there's been no change for N900, so should work fine still | 21:10 |
| arno11 | ok cool | 21:10 |
| freemangordon | sicelo: yes, but I made a mistake | 21:10 |
| freemangordon | so I *do not* confirm that calls work | 21:11 |
| freemangordon | yet | 21:11 |
| arno11 | sicelo: no change but PA is new (v15) iirc with new modules like module-match | 21:13 |
| arno11 | so remixing on n900 should probably be modified again (to improve/avoid remixing during calls) | 21:15 |
| sicelo | arno11: haha, yes, that one needs YOU :p | 21:17 |
| arno11 | :P | 21:18 |
| freemangordon | Wizzup: dpkg: warning: downgrading osso-icons-default from 2.5.3+3m7 to 2.5.2+4m7 | 21:50 |
| freemangordon | dpkg: warning: downgrading libconnui from 2.89.2+3m7 to 2.89.1+4m7.1 | 22:02 |
| freemangordon | not sure about that one though, may come from experimental | 22:03 |
| Wizzup | freemangordon: can check | 22:24 |
| Wizzup | the last is 2.5.2 | 22:24 |
| Wizzup | ah, no | 22:25 |
| Wizzup | I missed one | 22:25 |
| Wizzup | btw, I think I still need to build gpsd with dbus support | 23:53 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!