<freemangordon>
sicelo: right, but it is not for development
<freemangordon>
like, we put there things that are highly risky, in theory at least
<freemangordon>
or things we are not sure we will use at all
<freemangordon>
in -devel here we talk about patches to be tested, IIUC
<freemangordon>
like "most-probably it is ok, but lets put it under quarantine for a while"
<sicelo>
ok. what about -testing .. what would that do?
<freemangordon>
that'd be what current -devel is used for
<freemangordon>
we shall use -devel what it is meant for - "do not care if we break something, -devel users are ready for this"
mardy has joined #maemo-leste
<Wizzup>
uvos: did we have a module.load before, created by leste-config ?
<Wizzup>
freemangordon: so you want to rename -experimental to -devel and rename -devel to -testing ?
<freemangordon>
Wizzup: not really
<freemangordon>
we shall use -experimental only in rare ocasions, like, to test package relations or huge changes (like how it was with mesa and xorg driver)
<Wizzup>
then what is the proposal exactly?
<freemangordon>
to add -testing repo, so the life-cycle would be - build for -devel, it no obvious breakages, build for -testing in a week or so (short period)
<Wizzup>
ok, but who will be on top of this? we currently haven't synced -devel to stable for a long time
<freemangordon>
I think this can be done by a script
<Wizzup>
there is a script to compare
<freemangordon>
sync devel->testing
<Wizzup>
but it still needs git branch work and jenkins ci work
<Wizzup>
and we have cellular in -devel but not in stable
<Wizzup>
so the features aren't the same either
<Wizzup>
so it's a bit more complex
<Wizzup>
I don't mind the suggestion, btw
<freemangordon>
right, and that's why7 everybody is in devel
<freemangordon>
*on devel
<Wizzup>
for chimaera cellular will be in the main
<Wizzup>
(it already is)
<Wizzup>
so why I don't add -testing and -devel to chimaera?
<freemangordon>
and when me or uvos or anybody overlook something and break things, we essencially break most of our userbase devices
<freemangordon>
but, if we have -testing repo, that guarantees that devices will not boot loop but will be almost bleeding edge, things will get better IMO
<Wizzup>
and do we call the unstable thing devel or experimental
<freemangordon>
Wizzup: devel
<freemangordon>
I don;t want to merge PRs in experimental
<freemangordon>
even we shall rarely enable/use exp[erimental
<Wizzup>
I don't think we need normal, testing, devel and experimental
<Wizzup>
that seems a bit much, perhaps?
<Wizzup>
I mean, we can, I guess
<freemangordon>
like we did for mesa/xorg/new kernel back then
<freemangordon>
experimental shall be for couple of packages only
<freemangordon>
unmaintained in general
<Wizzup>
ok
<freemangordon>
like, we need to test some fancy new feature that is highly like to break everything, we put package x in -experimental, enable the repo on several devies we can afford to break, build/test and once we are happy, move that package in -devel
<freemangordon>
*likely
<Wizzup>
ok
<freemangordon>
we don;t care if experimental is in sync, as usually, the versions there will be very old
<Wizzup>
I will to try to get the remaining chimaera things sorted
<Wizzup>
I think are a few open things
<freemangordon>
ok
<Wizzup>
- elogind (yes or no)
<freemangordon>
hmm?
<Wizzup>
- mawf-shared build has some issues (iirc)
<freemangordon>
I can look at that
<Wizzup>
and tinymail/gtkhtml3 build (iirc)
<freemangordon>
that one too
<Wizzup>
- python packages (I will do this)
<Wizzup>
regarding elogind, there's some gnome packages that mawf depends on that hard depend on elogind
<Wizzup>
or systemd-logind, but we don't want that :)
<freemangordon>
ok, I'll have a look
<Wizzup>
so uvos said we had to port our xsession things to elogind session
<uvos>
Wizzup: as per the linked commit yes, and the commit removes the file
<uvos>
this dosent apear to have removed the file on system, probubly because of how the divert machinery in leste-config works (which i dont quite understand)
<uvos>
this is bad since the modules-load trumps blacklist
<Wizzup>
ok
<Wizzup>
so we can nerf it by creating the file without the line, or we can try to figure out the undisplace stuff ;)
<uvos>
someone should probubly know how leste-config works :P
<Wizzup>
parazyd did, kinda
<Wizzup>
displace is just a general debian thing I think
<uvos>
whats wierd is that the .leste file remained
<uvos>
i get not undisplaceing leaving the link
<uvos>
but the file in the package
<uvos>
i dont understand
<Wizzup>
yeah there's some weirdness in how the displace stuff works, I don't really know but can try to figure it out
<Wizzup>
maybe the best way for now is to empty the file
<uvos>
Wizzup: so we dont have to move to an xdg session for elgoind
<Wizzup>
ok
<uvos>
these things are only tangentially related in that we can have some existing session manager take care of things for us if we do
<uvos>
but we can just roll our own script that creates a session
<uvos>
i can take care of this
<uvos>
but i need to build a chimeara vm first
<Wizzup>
uvos: you can take a devuan vm and add the chimaera pkgs
<Wizzup>
s/pkgs/repos/
<Wizzup>
uvos: so do we need tinydm or not?
<uvos>
Wizzup: not nessecarly no, but it makes sense miagrate to an xdg session at the same time, at least in the sense that we have a xdg session that just runs xsession (at first) that we can then slowly migrate
<Wizzup>
it seems like it shouldn't be too much work, no?
<Wizzup>
unless there's some senseless integration in those scripts somehow
<uvos>
no, but moving the script in every package is some work
<Wizzup>
but when you wrote: 'we can just roll our own script that creates a session', would that replace tinydm?
<uvos>
yes
<Wizzup>
uvos: sure but not too much, that's just a matter of ls and dpkg -S
<Wizzup>
I'm fine with tinydm personally, although I never used it
<Wizzup>
it has openrc already
<freemangordon>
uvos: what about our -xsession dh helper?
<uvos>
im not exatly sure what this dose (resolve the priority numbers)?
<freemangordon>
yes
<uvos>
but now if we roll our own session directory like hildon-session.d as required to be a "clean" xdg session we need something like this for that directory
<freemangordon>
mhm
<freemangordon>
maybe just port the current helper
<uvos>
i think the simplest thing is just to have our session run xsession
<uvos>
at first
<uvos>
and then worry about seperating things later
<uvos>
small steps vs grand changes
<freemangordon>
uvos: my point is - if we port our debhelper to the new infrea, no package changes will be needed
<freemangordon>
work mtg, ttyl
<uvos>
yes i get that, but what about packages that might want to also have files there
<uvos>
(xsession.d
<uvos>
)
<Wizzup>
11:59 < uvos> i think the simplest thing is just to have our session run xsession
<Wizzup>
that sounds sensible to me
<uvos>
Wizzup: ok ill package tinydm and a minimal xdg session for us to do this, we can then migrate to hildon-session.d at any point (slowly or all at once
<uvos>
)
<Wizzup>
uvos: ok, cool, let me know if you need help
<Wizzup>
I kind of want to get chimaera going before working on other things
<Wizzup>
just to not have too many things happening at once you know
<uvos>
please do fix leste-config however
<uvos>
i also noticed that now leste-config-mapphone wants to install razr on my d4 because of the depends/sections
<uvos>
the dependancy resolution urgently needs fixing
<uvos>
idealy we'd know why this convoluted path was chosen but i gues parazyd wont even awnser questions anymore
<Wizzup>
uvos: ok, gimme a moment, so I can test this on my d4?
<Wizzup>
uvos: I see upgrade for mapphone and REMOVE for mapphone
<uvos>
right because for some reason it now thinks that -razr is needed but it conflicts with -d4
<uvos>
so this happens
<uvos>
no idea why the | depends cares of razr or d4 satifies it
<uvos>
*ir
<uvos>
*if
<Wizzup>
The following packages have unmet dependencies:
<Wizzup>
leste-config-mapphone : Depends: leste-config-bionic but it is not installable or
<Wizzup>
leste-config-droid4 but it is not going to be installed or
<Wizzup>
leste-config-droid3 but it is not going to be installed
<Wizzup>
E: Unable to correct problems, you have held broken packages.
<Wizzup>
ok
<Wizzup>
I do already have leste-config-droid4 installed though
<uvos>
yeah same here
<uvos>
i have no idea how it comes to this conclusion looking at debian/control
<uvos>
anyhow this means we need to make razr its own section or we need to reverse all the dependancies
<Wizzup>
I will try to figure it out
<Wizzup>
Broken leste-config-droid4:armhf Conflicts on diverts-lib++udev++rules.d++85-input-devices.rules:armhf < none @un H >
<Wizzup>
maybe they provide the same dislace?
<uvos>
the did
<uvos>
so i moved a file from mapphone to d4 etc
<uvos>
so the old version of mapphone provides the same file as the new version of d4
<Wizzup>
try to use this btw, when debugging any apt problems
<Wizzup>
-o Debug::pkgProblemResolver=yes
<Wizzup>
The following packages have unmet dependencies: leste-config-droid4 : Conflicts: diverts-lib++udev++rules.d++85-input-devices.rules leste-config-mapphone : Conflicts: diverts-lib++udev++rules.d++85-input-devices.rules
<Wizzup>
E: Unable to correct problems, you have held broken packages.
<Wizzup>
so this really is the problem
<uvos>
Chimaera installer: "If the time zone is not listed, then please go back to the step "Choose language" and select a contry that uses the desired time zone"
<uvos>
wtf i cant want us english with eu time zone?
<uvos>
freemangordon: ok but where dose the rest of the file come from
<uvos>
freemangordon: maybe i can just patch autologin to not work like this
<uvos>
i dont like it spawing x on tty1 anyhow should be 7
<freemangordon>
yeah, maybe it comes from debootstrap
<freemangordon>
uvos: what is the difference 1 vs 7?
<uvos>
freemangordon: autologin requires there be no getty on the vt it takes over
<uvos>
pmos just dont getty tty1
<uvos>
not ideal imo it should just take over tty7
<freemangordon>
ah
<freemangordon>
well, lets patch it the
<uvos>
yeah
<freemangordon>
XDG_VTNR=1 ?
<uvos>
sadly its hardcoded
<uvos>
but yes
<freemangordon>
can't we fix it properly and send patch to upstream?
<uvos>
sure
<uvos>
but it sets XDG_VTNR itself (to 1 ofc)
<freemangordon>
like, using env var and default to 1 if missing?
<uvos>
so it needs some coordination with pmos
<uvos>
ill just change it to 7 for now and fix it proper later
<freemangordon>
ok
Twig has quit [Remote host closed the connection]
<uvos>
video-omap is going to work in rootless x or?
<freemangordon>
no idea
<freemangordon>
will see
<freemangordon>
it should
<freemangordon>
if not, I'll fix it
<freemangordon>
the only issue it might have is with omapdrm fd
mardy has quit [Ping timeout: 252 seconds]
<uvos>
nice benefit also is
<uvos>
that if x dies session is just restarted
<uvos>
instead of full reboot/ nothing
mardy has joined #maemo-leste
<uvos>
ok dmse currenly breaks the session restarting
<Wizzup>
uvos: what inittab change?
<Wizzup>
uvos: well we're not planning on session restarting
<uvos>
Wizzup: forget it inittab need not be modified anymore
<uvos>
Wizzup: well it allmost works
<uvos>
Wizzup: just dsme breaks it
<uvos>
Wizzup: and it would be nice to have
<uvos>
Wizzup: the problem is dmse is dumb, so if x dies it just blindly tries restarting h-d etc, wich dosent work ofc, then the session restarts and also restarts h-d etc
<uvos>
really we should have a small tool thats run by the h-d Xsession script like superivse-deamon to supervise just that one processes (like h-d in this example)
<uvos>
then if just h-d dies
<freemangordon>
uvos: dsme is not dumb, it is told to restart h-d if it dies
<uvos>
freemangordon: but that is dumb
<freemangordon>
look at dsmetool options
<uvos>
supervise-daemon will restart just h-d
<uvos>
then if the session dies
<uvos>
supervise-deamon will die too
<uvos>
and everything gets restarted from scratch
<uvos>
freemangordon: there is no way for dsme to work correctly
<uvos>
it simply dosent have the information
<freemangordon>
how's that?
<uvos>
dsme is running outside the session
<uvos>
so it has no concept of the session itself dieing, as far as i can tell
<freemangordon>
ok, but, does anyone knows when session gets restarted?
<uvos>
yes the display manager
<uvos>
the way its supposed to work is display manger starts the session and restarts it when it dies
<freemangordon>
so, does it stop/start the session?
<freemangordon>
or just start it?
<uvos>
and then inside of the session a tool runs that restars the deamons of the sesion
<uvos>
freemangordon: it starts the session and respawns it when it dies
<uvos>
also stops it but thats out of scope rn
<uvos>
the problem is that then dsme runs outside of the session as root
<uvos>
and thinks it knows when things shal be restarted
<uvos>
but the session might be over for all it knows
<uvos>
or is in the process of restarting
<freemangordon>
sorry, have to do some other things now, ttyl
rafael2k_ has quit [Ping timeout: 260 seconds]
<freemangordon>
I think that maybe we shall not try to restart the session and just restart the device instead
<sicelo>
freemangordon: btw there aren't any kernel hacks for N900 besides the one for modem/dma issue. other patches relate to attempts to fix OFF mode, e.g. disabling thermal.
<bencoh>
sicelo: wait, so thermal was the one preventing OFF mode?
<bencoh>
that sounds so silly :)
<sicelo>
it's one of them. there are others too. i.e. OFF mode is still broken
<bencoh>
ah
<Wizzup>
uvos: let's first just get it to work like before, then figure out what else to do
<Wizzup>
uvos: should I add the packages to jenkins?
SuperMarioSF_ has joined #maemo-leste
SuperMarioSF has quit [Ping timeout: 256 seconds]
rafael2k has joined #maemo-leste
<uvos>
Wizzup: sure still needs some exta stuff
<uvos>
Wizzup: postins is needed for tinydm
<uvos>
Wizzup: some other small fry
<uvos>
Wizzup: like fixing the metapackage
<uvos>
but you can install it and have it working with just a few commands
<Wizzup>
let me make it avail on jenkins at least
<Wizzup>
rafael2k: please, what was the ringtone problem, do we have an issue for it?
<uvos>
the current pacakge installes the files in the wrong place
<Wizzup>
wrong directory?
<uvos>
dont remember how wrong exactly but the path in file where the ringtones and metadata is hardcoded for profiled (ugh why we need to fix this) and the path in fs dont line up
<Wizzup>
right, why don't we fix the profiled path?
<uvos>
we could do that sure, im just saying what the issue is not its resolution
<uvos>
building the rintones from a repo is however better than importing the package anyways
<Wizzup>
well, it's a bit more difficult
<Wizzup>
this is one of the pkgs we can host under *.maemo.org
<Wizzup>
but not quite sure if the conents of it can be hosted elsewhere
<Wizzup>
then again maybe nobody cares but if we do put it online, I'd like it to be some separated place
<uvos>
imo we should just package some ringtones with clear and foss frendly license
<uvos>
and forget about this
<Wizzup>
also fine
<Wizzup>
so which paths are we talking about?
<freemangordon>
uvos: why does tinydm need postinst?
<uvos>
freemangordon: 1. to install it into the runlevel (it uses makefile to install the init script and i want to modify upstream source as little as possible) 2. to use tinydm-set-session to set the default session, hildon-desktop
<uvos>
or rather hildon-session
<uvos>
maybe the hildon-session should do that instead
<freemangordon>
hmm, installing init script from makefile does not seem like a good idea
<uvos>
point is it needs postins
<freemangordon>
I understand, but we have dh_installinit, no?
<Wizzup>
you can just make it an init script in debian/ yeah
<uvos>
sure
<uvos>
but id like to maintain just the debian dir in future
<uvos>
and use upstream as $src
<freemangordon>
I understand, but just install in debian/tmp/...
<freemangordon>
and then dh_installinit for the file in debian/tmp/...
<uvos>
dont know how to do that exactly via rules
<uvos>
but i can try and figure it out
<freemangordon>
I can do, where is the source?
<uvos>
upstream forks
<freemangordon>
ok
SuperMarioSF has joined #maemo-leste
<freemangordon>
gimme a couple of miinutes
SuperMarioSF_ has quit [Ping timeout: 246 seconds]
<Wizzup>
uvos: tinydm/autolaunch/hildon-session are in jenkins
<freemangordon>
ofc you can modify update-rc.d parameters
<rafael2k>
Wizzup: wrong paths in /etc/ringtone and the other file that reference the tones, missing files and so on... no, no issue
<freemangordon>
and maybe also add "--no-start" do dh_installinit if needed
<rafael2k>
just use the package I carefully did
<rafael2k>
fixing all the issues
<rafael2k>
even add more tones and so on
<rafael2k>
*added
<Wizzup>
rafael2k: please see what I said above
<uvos>
oh yeah maybe the hardcodeing file for profiled was inside the ringtone package too
<uvos>
no idea how this ever worked
mardy has quit [Quit: WeeChat 3.5]
<freemangordon>
what about if I take the package from rafael2k and create source package out of it. the source package will be in a private repo. not sure how we can build for maemo.org though
<freemangordon>
Wizzup: ^^^
<Wizzup>
freemangordon: maybe just a sep maemo leste orga
<Wizzup>
on gh
Daanct12 has joined #maemo-leste
Danct12 has quit [Ping timeout: 260 seconds]
rafael2k has quit [Ping timeout: 264 seconds]
<Wizzup>
freemangordon: we can also just build it locally
<Wizzup>
and import it ci
<Wizzup>
import in ci
<freemangordon>
right, but anyway i was talking about where to keep the source code
<norayr>
i as trying to understand what was on the board in 'modern' live wallpaper.
<norayr>
and found animations presenting live wallpapers back in 2010.