<Wizzup>
maybe dpkg --force-all -r gconf2 dbus-x11 and then re-install them
<Wizzup>
(to reproduce)
<Wizzup>
or perhaps some other pkg/deb of gconf2
<Wizzup>
maybe we need to locally build a 'newer' gconf2 and install that, see if that causes it
uvos has quit [Ping timeout: 252 seconds]
lul4 has joined #maemo-leste
lul4 has quit [Client Quit]
System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
MinceR has quit [Read error: Connection reset by peer]
MinceR has joined #maemo-leste
akossh has quit [Quit: Leaving.]
mkfx has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
joerg has quit [Ping timeout: 260 seconds]
joerg has joined #maemo-leste
xmn has quit [Quit: Leaving]
mkfx has left #maemo-leste [Disconnected: Replaced by new connection]
mkfx has joined #maemo-leste
_fab has joined #maemo-leste
Anasko has joined #maemo-leste
<freemangordon>
Wizzup: doing 'dpkg -i gconf2-common_3.2.6-8_all.deb' allows dist-upgrade with (almost) no issues
<freemangordon>
so I think we shall fork gconf2 and make gconf2 binary package to pre-depend on gconf2-common
<freemangordon>
I can;t think of any better solution
narodnik2 has quit [Quit: WeeChat 4.5.1]
<gnarface>
someone else in #devuan should have some idea why it's not that way already...
<gnarface>
weird to me that everyone isn't running into the same issue over there though
pere has quit [Ping timeout: 260 seconds]
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
narodnik has quit [Quit: WeeChat 4.5.1]
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
<Wizzup>
freemangordon: ok, I am happy to do that if you're sure this is it
<Wizzup>
freemangordon: do you know why gconf2-common?
<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
<Wizzup>
I suspect gconf just isn't widely used for a while anymore
<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
<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
<Wizzup>
well, gconf is replaced by gsettings for a while now
<gnarface>
i seem to have both installed on this system, but it has been through a lot of upgrades
<freemangordon>
Wizzup: I am not sure
<freemangordon>
like, I am not sure what I proposed will fix the issue
<freemangordon>
but, I think we can try it
<freemangordon>
do you want me to do the fork?
<freemangordon>
why gconf-common: because it contains files that trigger gconf2 trigger
<freemangordon>
hmm, wait
<freemangordon>
because it contains /usr/share/sgml/gconf/gconf-1.0.dtd
<freemangordon>
and seems this trigger sgml trigger
<freemangordon>
*triggers
<freemangordon>
anyway, I *think* pre-depends trick will do it
<gnarface>
the thing is, it should have been fixed already upstream long ago, so the real question is why it isn't
<freemangordon>
because gconf is no longer supported
<freemangordon>
everyone moved to gsettings
<gnarface>
officially no longer supported or just de-facto no longer supported?
<gnarface>
because the latter, it's still their job to fix
<freemangordon>
afaik in unstable it is officially unsupported
<freemangordon>
in stable it is de-facto unsupported
<freemangordon>
that's my understanding
<freemangordon>
also, if we have a quick-fix in our repos, I'd rather not deal with debian issue tracker :)
<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
<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.
<freemangordon>
agree, but we really don;t have the manpower/spare time to fight that battle
<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
<freemangordon>
hmm.. even not that
<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...
<gnarface>
but i do sympathize with not wanting to bother
<freemangordon>
I will have to install bullseye and try-to dist-upgrade to bookworm
<freemangordon>
and I bet it will not fail
<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
<gnarface>
(and maybe this conversation already happened over there but i just forgot because i smoke too much weed)
<freemangordon>
:D
<freemangordon>
yeah, that's a well known side-effect
<freemangordon>
gnarface: I'd rather first try to fix it in our repos
<freemangordon>
that report on #devuan, so if anyone is interested to just pull the fix
<freemangordon>
s/that/then
<Wizzup>
freemangordon: we already forked it
<Wizzup>
no nee to re-do the work
<Wizzup>
freemangordon: I don't see a rule to trigger on sgml dir
<freemangordon>
yeah, I saw
<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
<freemangordon>
whay not put it in daedalus repo?
<freemangordon>
*why
<freemangordon>
I don;t think we can repro
<freemangordon>
if not in the repos I mean
<freemangordon>
Wizzup: so, I will pull gconf, drop the directory change commit, add pre-depends
<freemangordon>
I think if you put that in hildon-meta, HAM will show "system upgrade"
<freemangordon>
we shall fix repos first ofc
<Wizzup>
freemangordon: parazyd used to do that for us
<freemangordon>
I know
mkfx has left #maemo-leste [Error from remote client]
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
mkfx has joined #maemo-leste
arno11 has joined #maemo-leste
vectis_ has quit [Read error: Connection reset by peer]
vectis_ has joined #maemo-leste
pere has joined #maemo-leste
<Wizzup>
freemangordon: ok, hildon meta shows up now in regular ham
<Wizzup>
I will make the same changes for daedalus and then try a dist upgrade
<Wizzup>
it also reboots and says 'operating system upgraded' btw
MinceR has quit [Read error: Connection reset by peer]
MinceR has joined #maemo-leste
<Wizzup>
freemangordon: for dist-upgrade to work we also need to add devuan repos to ham catalog
<Wizzup>
how else will the user get the upgrades
<Wizzup>
freemangordon: yeah, I made a switch to daedalus repos and cssu thinks the system upgrade wil l download 7kB :)
<Wizzup>
so I don't think dist-upgrade will work this way
<Wizzup>
as expected, it doesn't ensure every pkg is fully up to date, it just checks if some deps are satisfied
<Wizzup>
so we'd have to version/pin everything in hildon-meta for this to work
<Wizzup>
and even then it won't do the same for devuan pkgs
<Wizzup>
I will check with red pill mode
<Wizzup>
that helps, but it is still not very clever with dep handling :(
mkfx has left #maemo-leste [Error from remote client]
<Wizzup>
we probably want it to act like dist-upgrade and not like upgrade
<Wizzup>
freemangordon: see doc/packaging.txt section ### Installation and removal policy
pere has quit [Ping timeout: 252 seconds]
Anasko has quit [Ping timeout: 244 seconds]
<Wizzup>
it seems like HAM can't do dist upgrades
<Wizzup>
but we can use it for regular updates if we pin everything version wise
<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
<Wizzup>
but we can use it for upgrades to the system with specially crafted meta files
<freemangordon>
re maemo section: as I said, we just need to add a dependency to lets say glibc in daedalus
<Wizzup>
(it's too bad it can't just use the apt dist-upgrade logic tbh)
<Wizzup>
you can try it but I am 99% that won't work
<Wizzup>
99% sure
<freemangordon>
why would in not?
<Wizzup>
why would it help to pull in new libc?
<Wizzup>
most pkgs don't care about the libc version
<Wizzup>
and it's also a hack for sw that doesn't properly resolve dependencies
<freemangordon>
yeah, agree
<freemangordon>
Wizzup: I think we can use HAM, just have to create a metapackage with the correct dependencies (and conflicts)
lyubov has quit [Ping timeout: 246 seconds]
lyubov has joined #maemo-leste
<freemangordon>
Wizzup: so, we can do apt upgrade and then check what has not been upgraded with apt dist-upgrade
<freemangordon>
and then include that in the metapackage
* freemangordon
tries
<Wizzup>
I don't think this will even work
<Wizzup>
it will fail immediately
<Wizzup>
I don't really see the point, then just make ham act like apt
lyubov has quit [Remote host closed the connection]
lyubov has joined #maemo-leste
<freemangordon>
Wizzup: did you push the new leste-config?
<freemangordon>
ah, seems yes
<freemangordon>
hmm:
<freemangordon>
N: Ignoring file 'pin-daedalus-extras.leste' in directory '/etc/apt/preferences.d/' as it has an invalid filename extension
<freemangordon>
N: Ignoring file 'pin-daedalus.leste' in directory '/etc/apt/preferences.d/' as it has an invalid filename extension
mkfx has left #maemo-leste [Error from remote client]
<gnarface>
has to end with .pref
<freemangordon>
yeah
<Wizzup>
I don't think it has to end in anything
<Wizzup>
this is just a result of our gen-displace
<gnarface>
you might want to start the names with digits too, so you can control the order they load
<Wizzup>
it's hardless
<Wizzup>
harmless
<Wizzup>
there is pin-daedalus and pin-daedalus-extras
<Wizzup>
as you can see
<Wizzup>
next to the .leste versions
<freemangordon>
I know its harmless, but will appear on every upgrade
<Wizzup>
yes, until we remove it again in the near future
<Wizzup>
no real way to solve it, I think we just live with it
<freemangordon>
can;t we just provide the real files?
<freemangordon>
why we have to divert?
<freemangordon>
or whatever we do?
<Wizzup>
feel free to try, I don't have the time to focus on this
<Wizzup>
we install all files this way
<freemangordon>
try what, sorry
<Wizzup>
feel free to try to install them throug the pkg
<freemangordon>
hmm, ok
<Wizzup>
I think it's a waste of time
<Wizzup>
we just remove the divert in a couple of weeks/months
<Wizzup>
we don't even need the divert in daedalus anyway, only in chimaera
<freemangordon>
ok
<freemangordon>
hmm, I think it is better to keep the priorities
<freemangordon>
I don;t want newer mesa to come from backports, for example
<freemangordon>
but ok
<freemangordon>
Wizzup: so, do we have any other issue?
<freemangordon>
or I shall dist-upgrade my d4?
<freemangordon>
I guess we'll have issues with upower
System_Error has quit [Remote host closed the connection]
<freemangordon>
sicelo: did you try to contact upower maintainers?
System_Error has joined #maemo-leste
<sicelo>
no, haven't. tbh i'm not even sure what we would ask for
<freemangordon>
well, you said some patches were rejected
<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
<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
<freemangordon>
ok, what is that problem we have on d4 and n900?
<freemangordon>
I really didn't follow back then
<sicelo>
at some point, both do not report a percentage/capacity
<sicelo>
that's the only problem
<freemangordon>
do they report charge level?
<freemangordon>
like low, high, etc?
<freemangordon>
at least d4 do I think
<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)
<sicelo>
but, upower doesn't care one bit about that
<freemangordon>
ok, so, we can as would they accept a patch that makes upower use that data when there is no capacity/percentage reported
<freemangordon>
*can ask
System_Error has quit [Remote host closed the connection]
<sicelo>
it's exactly what i asked ... with disastrous ending :-)
<sicelo>
but, maybe current maintainer would
<freemangordon>
right, but you said minatiner changed
<freemangordon>
at least they may give us ideas what to do
<freemangordon>
ok, let me dist-upgrade my d4 to see how would it behave with that new upower
<sicelo>
maybe you can see where things went south in the communication, and perhaps how to express it better in future
System_Error has joined #maemo-leste
<freemangordon>
ok, will have a look later on
<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
<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"
fmg_d4 has joined #maemo-leste
fmg_d4 has left #maemo-leste [#maemo-leste]
fmg_d4 has joined #maemo-leste
fmg_d4 has quit [Client Quit]
fmg_d4 has joined #maemo-leste
<fmg_d4>
daedalus d4
fmg_d4 has quit [Client Quit]
<sicelo>
awesome
System_Error has quit [Remote host closed the connection]
<arno11>
cool
System_Error has joined #maemo-leste
bencoh has quit [Ping timeout: 248 seconds]
mkfx has joined #maemo-leste
System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
<Wizzup>
freemangordon: really great to have the gconf issue solved
<freemangordon>
yeah, my d4 dist-upgraded without any issue whatsoever
<Wizzup>
do calls still work? :D
<freemangordon>
yes
<Wizzup>
cool
<freemangordon>
mhm
<Wizzup>
I'll dist upgrade as well then
<freemangordon>
I mad an image of the SD card, just in case
<freemangordon>
*made
<Wizzup>
btw, I did make some progress with ham and doing sys upgrades
<freemangordon>
like?
<Wizzup>
well, I got it to show, disable the ui, reboot, say the operating system was upgraded successfully
<Wizzup>
like, things work
<Wizzup>
just not for dist-upgrade
<freemangordon>
ah
<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
<freemangordon>
yeah, for dist-upgrade we'll have to come-up with something else
<Wizzup>
I bet aptitude could do it, or some other ui
<Wizzup>
I think for now we can just ask the power users to use dist upgrade
<freemangordon>
but I guess we can do that fro the futore
<freemangordon>
mhm
<freemangordon>
I guess all of our current user base can do
<freemangordon>
anyway, bbl, the kid from Amsterdam is here, want to spend some time with
<Wizzup>
:)
<freemangordon>
Wizzup: hmm power usage seems very high
<Wizzup>
could be tracker re-indexing
<arno11>
pretty sure
<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' ?
<freemangordon>
Wizzup: does not seem to be tracker
<freemangordon>
oh, scratch that
<freemangordon>
Wizzup: do not upgrade yet
<freemangordon>
this is still chimaera I see that big power usage
<Wizzup>
freemangordon: ok, I am confused :)
<freemangordon>
well...
<freemangordon>
I am fighting some cold and not very focused :)
<freemangordon>
so I was about to dist-upgarde
<Wizzup>
i dist upgraded my n900 to daedalus and didn't see any problems but I did not look super hard
<freemangordon>
but only upgraded
<Wizzup>
2 days ago I think
<Wizzup>
says 1 day of battery at 99%
<Wizzup>
which is normal for my n900
<freemangordon>
however, ahve to find the reasopn for that high power usage first
<freemangordon>
yeah, it is somehitng here on that device
<Wizzup>
maybe it is just you who sees it
<freemangordon>
mhm
<freemangordon>
most-probably
<arno11>
Wizzup: calls still work btw ?
<freemangordon>
so, I am running dist-upgrade now
<Wizzup>
arno11: will check tomorrow
<sicelo>
arno11: fmg said Yes. anyway, there's been no change for N900, so should work fine still
<arno11>
ok cool
<freemangordon>
sicelo: yes, but I made a mistake
<freemangordon>
so I *do not* confirm that calls work
<freemangordon>
yet
<arno11>
sicelo: no change but PA is new (v15) iirc with new modules like module-match
<arno11>
so remixing on n900 should probably be modified again (to improve/avoid remixing during calls)
<sicelo>
arno11: haha, yes, that one needs YOU :p
<arno11>
:P
arno11 has left #maemo-leste [#maemo-leste]
<freemangordon>
Wizzup: dpkg: warning: downgrading osso-icons-default from 2.5.3+3m7 to 2.5.2+4m7
<freemangordon>
dpkg: warning: downgrading libconnui from 2.89.2+3m7 to 2.89.1+4m7.1
<freemangordon>
not sure about that one though, may come from experimental
arno11 has joined #maemo-leste
<Wizzup>
freemangordon: can check
<Wizzup>
the last is 2.5.2
<Wizzup>
ah, no
<Wizzup>
I missed one
Twig has quit [Remote host closed the connection]
<Wizzup>
btw, I think I still need to build gpsd with dbus support