<freemangordon>
it seems it already return ENODATA under some conditions
mkfx has left #maemo-leste [Error from remote client]
<sicelo>
part of the upower problem is that they made the assumption that capacity_level is only valid for peripherals not supplies, e.g. bluetooth devices.
MinceR has quit [Read error: Connection reset by peer]
MinceR has joined #maemo-leste
<sicelo>
freemangordon: an idea I had recently is ... we leave kernels as they are, and upower capacity/percent as is, but just teach it to export the capacity_level property straight from kernel
<sicelo>
so no assumptions get made by either kernel or upower
<sicelo>
a upower consumer (like us) can then make its own decision to react to capacity_level if it wishes
<freemangordon>
but the real issue now is that upower does a shutdown, no?
<sicelo>
we can suppress that shutdown in latest versions of upower, so it's no longer a problem
<freemangordon>
then, what is the problem?
<sicelo>
the shutdown is there in the version found in daedalus ... but we can build newest, i guess
<sicelo>
right now there's no major problem really :-)
<sicelo>
except ... yes we don't shutdown, but, what do we report in the battery applet & mce
<freemangordon>
if the property is not reported, we can just say "battery not calibrated" in the applet and show half-empty icon
<freemangordon>
mce does not care about charge anyways, it cares about 'battery low' signal only
<freemangordon>
and voltage level
<freemangordon>
dsc_: please, fix conversations to not connect accounts if availability is offline
fmg_d4 has joined #maemo-leste
fmg_d4 has quit [Client Quit]
<sicelo>
i completely agree with that approach ... and that's why i was thinking about exposing capacity_level in upower, so at least we don't always show the 50%, but can show 75%, 25%, etc. solely from capacity_level
<freemangordon>
ahaa, now I see
<freemangordon>
yeah, makes sense
fmg_d4 has joined #maemo-leste
fmg_d4 has quit [Client Quit]
freemangordon1 has joined #maemo-leste
freemangordon has quit [Read error: Connection reset by peer]
<freemangordon>
but, I am afraid I cannot fix it for dist-upgrade
<Wizzup>
btw, looks like the ebook stuff wasn't necessary because there was also a newer version installed
<freemangordon>
lemme try jenkins
<Wizzup>
it's not just dist-upgrade, I think also when debian say upgrades sgml
<freemangordon>
yeah
<freemangordon>
sgml does something
<freemangordon>
Wizzup: jenkins is fixed, but I have no idea how to fix dist-upgrade
<freemangordon>
maybe sgml-base shall pre-depend on gconf
<Wizzup>
freemangordon: maybe we can fix some of this in our meta pkgs
_fab has joined #maemo-leste
<freemangordon>
yes, but ni idea how
<freemangordon>
*no
<freemangordon>
trying a fix now though
<Wizzup>
maybe we can have gcon2 not depend on gconf-common, hope it gets pull in some other way and fix it that way
<freemangordon>
hmm...
<freemangordon>
maybe
<Wizzup>
upon dist-upgrade now, indeed the gconf bug is back, btw
<freemangordon>
I know
<Wizzup>
yeah
<freemangordon>
one more try, if that does not work, I'll give-up
<Wizzup>
let's hope :)
<freemangordon>
I don;t really believe this will work, but...
<freemangordon>
Wizzup: hmm... *maye* it is really fixed
<freemangordon>
going to dist-upgrade my VM
<Wizzup>
great
<freemangordon>
well, lest confirm
<freemangordon>
*lets
<freemangordon>
you can build clutter etc in thye meanwhile, jenkins is fixed
<freemangordon>
Wizzup: ^^^
<freemangordon>
Wizzup: dist-upgrade is not ok, I am out of ideas
<Wizzup>
what about some hacks with hildon-meta
<Wizzup>
have gconf pkgs not depend on each other
<Wizzup>
hm I guess that is tricky for ci
<freemangordon>
maybe that will work, dunno
<freemangordon>
yeah
<Wizzup>
or maybe merge gconf2 and gconf-common and add some provides/replaces
<Wizzup>
then there might also not be a cycle
<freemangordon>
would you try? as I am sick of gconf now :)
<freemangordon>
hmm, wait
<freemangordon>
maybe we shall move triggers to another package
<freemangordon>
have to run, bbl
<Wizzup>
that works too @ triggers
arno11 has joined #maemo-leste
<Wizzup>
freemangordon: can gconf pre-depend on sgml-base?
<freemangordon>
sgml-base is not the issue
<freemangordon>
it is gconf that is the issue
<Wizzup>
I think it's both, no?
<freemangordon>
not sure
<freemangordon>
could be
<Wizzup>
ok, well, I liked the idea of moving the triggers to a separate pkg'
<freemangordon>
that package shall pre-depend on gconf or something
<freemangordon>
I am not sure how dependency chain should look like
<Wizzup>
gconf can depends on gconf-triggers and gconf-triggers can pre-depend on gconf, no?
<freemangordon>
sounds weird but we can try
<Wizzup>
this way gconf can configure without running triggers and without issue
<freemangordon>
try it
<Wizzup>
ok, will today
<arno11>
Wizzup: btw for n900, did you move all stuff from devel to daedalus ?
<arno11>
i ask because the last chimaera img is finally unusable apart for basic stuff, and not upgradeable to devel because of random network/modem crash and h-d freeze :(
<Wizzup>
I haven't observed these crashes or freezes
<arno11>
i mean from a fresh install
<Wizzup>
but we can look at n900 specific stuff when the daedalus install works on some devices
<arno11>
i mean it is not possible to use it from a fresh install with chimaera
<arno11>
so ofc from our old install, daedalus works. different story for new user
<arno11>
when you say you didn t observe these crashes or freezes, you mean from a fresh install ?
arno11 has left #maemo-leste [#maemo-leste]
<Wizzup>
no, I haven't dd an image in a bit
arno11 has joined #maemo-leste
<arno11>
Wizzup: ok. even dts fixes are missing with 125MHz freq still there btw
<Wizzup>
I am not super inclined to work backwards on chimaera and rather just make a daedalus image that works well
<Wizzup>
but if you tell me exactly what to build I can do it
<arno11>
oh, ofc no problem for daedalus as a priority. i just mean we absolutely need all devel stuff for stable img
<arno11>
for chimaera or daedalus
<Wizzup>
daedalus built from devel stuff for the most part
<arno11>
Wizzup: last d4 build failed with same submodule error (as n900)
<Wizzup>
freemangordon: do we really want to fork dpkg too? I'd prefer to try my fix
<Wizzup>
arno11: ok, ty, I'll try to see what's up
<freemangordon>
Wizzup: no dpkg fork
<freemangordon>
but change gconf trigger types
<Wizzup>
ok
<freemangordon>
Wizzup: I force-pushed, so keep you local changes for a while
<Wizzup>
yeah, I did, I also have the local changes you had
<Wizzup>
just in case
<freemangordon>
so far it seems this change helps, however, we may have to upgrade gconf in chimaera too
<Wizzup>
sounds like a good idea (let's do -devEL first)
<Wizzup>
-devel
<freemangordon>
I'll do locally forst
<freemangordon>
*first
<freemangordon>
and then -devel
<freemangordon>
in either case, there will be a need for dpkg-reconfigure a, most-probably
<Wizzup>
regardless of a fix? strange
<freemangordon>
yes, because we already have gconf with broken triggers in chimaera
<Wizzup>
if we replace gconf it doesn't seem like it would be a problem
<freemangordon>
will have to try
<freemangordon>
lemme first check if it will allow dist-upgrade to not break
<freemangordon>
starting dist-upgarde with new gconf installed, lets see
<freemangordon>
Wizzup: seems it will work
<freemangordon>
I think we shall issue a chimaera HAM metapackage that depends on that gconf
<freemangordon>
to give users chance to upgrade
<freemangordon>
dist-upgrade still goes on though, will report when its done
nohit has quit [Ping timeout: 248 seconds]
nohit has joined #maemo-leste
<Wizzup>
ok
<freemangordon>
Wizzup: done, no errors
<freemangordon>
so, the plan is:
<freemangordon>
1. put fixed gconf from daedalus to chimaera-devel and check if it installs (with apt upgrade) with no issue, then test dist-upgarde. I'll do that
<freemangordon>
2. move gconf to chimaera
<freemangordon>
3. check if image builds still work (both chimaera and daedalus)
<freemangordon>
4. add new gconf as a dependency to chimaera hildon-meta and mark hildon-meta as HAM system package
<freemangordon>
what do you think?
<Wizzup>
sounds good
<Wizzup>
hildon-meta is already a system package in ham for experimental btw
<Wizzup>
re: 5, we might also want to make some hildon-meta-pin pkg that gets update monthly with specific versions
<freemangordon>
that was my idea from yesterday, to auto-generate such package, somehow
<freemangordon>
right before I asked if we can hire repo maintainer :D
<freemangordon>
Wizzup: hmm, maybe I shall put it in experimental, if metapackage is there
<freemangordon>
hm?
<Wizzup>
either way
<freemangordon>
ok, doing for experimental first
<freemangordon>
Wizzup: hmm, HAM lists "core meta package" too
<Wizzup>
yeah I did that
<Wizzup>
we can remove it though
<freemangordon>
ok
<freemangordon>
we shall, it does not have a nice icon :)
<freemangordon>
I will do it
<freemangordon>
hmm, conflicts with libgconf2-dev (3.2.6-7)
<Wizzup>
strange, why
<freemangordon>
no idea
<Wizzup>
maybe you apt-get instlal'd something that depends on this specific version
<Wizzup>
would be strange
<Wizzup>
or ham is crazy :)
<freemangordon>
HAM
<freemangordon>
will try one more thing
<freemangordon>
hmm, why is core package "not provided by maemo leste"
<freemangordon>
oh
<freemangordon>
I guess I have to install hildon-application-manager-settings-standard first, right?
<freemangordon>
Wizzup: ^^^?
<freemangordon>
Wizzup: did you mark our packages as system?
<freemangordon>
Wizzup: somehow the upgrade is not trusted by HAM, tha's why it refuses to install it
<freemangordon>
Wizzup: what is the key of experimental?
<freemangordon>
Wizzup: oh, HAM uses its own gpg store
<freemangordon>
someone shall read the docs :)
Madda has quit [Remote host closed the connection]
Madda has joined #maemo-leste
<Wizzup>
freemangordon: ah yes, I need to do that still
<Wizzup>
freemangordon: I probably didn't have that because I had it in red pill mode
<Wizzup>
but yes there's the domains thing
mkfx has joined #maemo-leste
<freemangordon>
we have to fix domains/keys in order to use HAM
<Wizzup>
I know
MinceR has quit [Read error: Connection reset by peer]