xes has quit [Ping timeout: 248 seconds]
uvos has quit [Remote host closed the connection]
enyc has quit [Ping timeout: 245 seconds]
enyc has joined #maemo-leste
xes has joined #maemo-leste
<tmlind> sicelo: kevin is looking at patches this merge window, see commit dfd168e74ebe ("MAINTAINERS: Add more maintainers for omaps")
System_Error has joined #maemo-leste
joerg has quit [Ping timeout: 252 seconds]
joerg has joined #maemo-leste
ceene has joined #maemo-leste
uvos__ has quit [Quit: Konversation terminated!]
<freemangordon> Wizzup: scratch that new kernel release
<freemangordon> the patch I pushed is wrong
<freemangordon> it will enable mic bias even if there is no mic
<freemangordon> I have to implement HS MIC detection for that to work properly
<freemangordon> I'll drop and force-push
<Wizzup> ok
Livio has joined #maemo-leste
arno11 has joined #maemo-leste
<arno11> (just for the record) disabling wifi powersaving mode increase battery life and idle (around 15mA) lol
<arno11> on n900 that is
<arno11> oops i mean increasing battery life and improving idle
<arno11> can't remember if powersaving is enable by default
<sicelo> it is
<arno11> ah ok
<sicelo> what's the standby current draw now?
<arno11> around 55
<arno11> 68 with power saving
<sicelo> anyway the benefits of the power saving setting are highly dependent on the AP configuration, so not too surprising if it's not helping most of the time
<arno11> ok
<sicelo> nice fine
<sicelo> *find
<Wizzup> on lab psu it def. deemed to help to enable powersaving
<Wizzup> maybe you use mosh or something?
<arno11> nope nothing particular
<sicelo> for some reason i can't find the reference that had a lot of details about power saving, especially in connection with N900. i *think* it was on the maemo wiki, but can't find it now
<arno11> ok
<sicelo> ah, wiki is down
<arno11> thx
<arno11> btw no diff between 100mW and 10mW om my device btw
<arno11> oops too much btw's
<sicelo> btw :-D
<Wizzup> our wiki?
<Wizzup> ah, no
mdz has joined #maemo-leste
<Wizzup> freemangordon: btw I solved my gprs issue, somehow apn was not being set for my new sim
<freemangordon> good
<freemangordon> so, as a continuation of our discussion - headset works just fine, HS mic needs some love
<freemangordon> I know what has to be done (cpcap is smart enough to detect headset vs heaphones), I just have to find time
<freemangordon> however, consider upgrading to 6.10 or something
<freemangordon> that will make my life way easier in terms of upstreaming the patches
<freemangordon> also, ucm needs modifications to switch to headset/headphones properly
<freemangordon> but, I don't think I am the one best fit for that job
<freemangordon> Wizzup: ^^^
<Wizzup> I can try to help with UCM, wrt 6.10 we might just spend a few more weeks chasing regressions
<Wizzup> as in, should we not get 6.6 to devel/stable first?
<freemangordon> yeah, maybe
<Wizzup> we can do that without headset for calls if you prefer
<freemangordon> but I will leave HS mic for 6.10
<freemangordon> yeah, right
<freemangordon> ok, so lets have 6.6 in -devel
<freemangordon> I don;t think there are known regressions, right?
<Wizzup> sec 5 mins
<arno11> freemangordon: mapphone ucm only need minor changes for headset
akossh has joined #maemo-leste
<arno11> it seems already quite ok, just the mic name is incorrect
<freemangordon> I am not sure
<freemangordon> why do you think MIC name is incorrect?
<arno11> because it uses mic 1
<arno11> and i suppose the headset mic name is different in alsamixer
<freemangordon> yes, but mic 1 is internal mic
uvos__ has joined #maemo-leste
<freemangordon> so we need to switch from mic 1 to "HSMIC" iff headset (not headphones) are plugged
<freemangordon> *is plugged
<arno11> exactly
<arno11> just one line to change in ucm
<freemangordon> ok, but that does not make MIC1 invalid
<freemangordon> not only one
<freemangordon> as now voice output is not redirected to headphones during call
<arno11> ah
<freemangordon> or maybe it happens only if they are plugged while in call
<freemangordon> lemme try
<arno11> yes probably because of jackcontrol
<freemangordon> no audio if HS are plugged while in call
<freemangordon> so ucm needs more changes
<arno11> yes indeed
<freemangordon> also, it has the same issue as n900 (iiuc), switching profile re-routes audio from headset
<freemangordon> Wizzup: oh, there is one issue
<freemangordon> iphb does nopt get rebuild
<freemangordon> *not
<Wizzup> I think it does if you run dpkg-reconfigure linux-image-droid4/omap or something
<Wizzup> which makes me think it's not a 'headers in the wrong place' kind of issue
<Wizzup> uvos__: I will make the sphone changes now, shall I just push them or make a pr?
<Wizzup> it'll be 1-2 lines max in vcm
<arno11> freemangordon: weird you get no audio if you plug HS during call
<arno11> or maybe jackcontrol value is wrong
<arno11> on d4, alsactl monitor should return 'Headphones Jack'
<arno11> if not, ucm is wrong
<arno11> *when you plug HS
<arno11> later (or another day) if you provide me few more details i could probably help to fix mapphone ucm
<freemangordon> arno11: but, HSMIC detection is not implemented, so HSMIC widget never gets switched on
<arno11> yes i know
<freemangordon> so, it is a bit more complicated
<freemangordon> anyway, it makes no sense to deal with that until MIC detection wirks
<freemangordon> Wizzup: yes, headers are in the right place
<freemangordon> but kernel dkms scripts are wrong
<freemangordon> I fixed them back then to make them work
<freemangordon> perhaps this was not forward-portedf
<freemangordon> lemme check
<arno11> freemangordon: (when i say audio i mean incoming audio at least)
<freemangordon> ah
<arno11> so mic or not, no matter
<freemangordon> ok, I can provide details later on
<arno11> cool
<Wizzup> freemangordon: so dpkg-reconfigure does not fix it for you?
<freemangordon> it does
<freemangordon> but that should not be needed
<Wizzup> of course
<freemangordon> and it was working
<freemangordon> but dkms uninstall works
<freemangordon> I men, during upgrade old kernel iphb module gets uninstalled
<freemangordon> *mean
<freemangordon> but new one does not get rebuild
<Wizzup> I did see that, I just don't know why not
<freemangordon> yeah, it is tricky to trace that
<freemangordon> lemme try to find the problem
<freemangordon> ok, I think I know what it is
<Wizzup> :)
<freemangordon> that results in "/usr/lib/dkms/dkms_autoinstaller start 6.6.36"
<freemangordon> I am not sure this is correct
<freemangordon> oh, it is
Wikiwide has quit [Remote host closed the connection]
Wikiwide has joined #maemo-leste
Wikiwide has quit [Remote host closed the connection]
Wikiwide has joined #maemo-leste
Wikiwide has quit [Remote host closed the connection]
<freemangordon> Wizzup: sees like an issue with dkms
<freemangordon> as dkms status lists no modules
<Wizzup> ok
<freemangordon> ok, dh_dkms does not register module with dkms :(
<freemangordon> ok, seems this is some remnant from beowulf
<Wizzup> ah
<freemangordon> i purged dkms-iphb and installed again
<freemangordon> iphb-dkms I mean
<freemangordon> ugh
<freemangordon> ok, not sure what happened
<freemangordon> but reinstalling the kernel remove iphb from dkms tree
<sicelo> Wizzup: not very important, but please help me find which libicd-network-wpasupplicant function gets called when responding to com.nokia.icd2.statistics_req
<Wizzup> src/wlan.c: network_api->link_stats = wlan_statistics;
<Wizzup> I think it's this?
<Wizzup> uvos__: made a pr for vcm rtcom
<Wizzup> tested it on my d4
<sicelo> thanks, will have a look
Wikiwide has joined #maemo-leste
<pere> so, what are people using their N900 for with Maemo Leste?
Wikiwide has quit [Remote host closed the connection]
Wikiwide has joined #maemo-leste
Wikiwide has quit [Read error: Connection reset by peer]
<Wizzup> calls, sms, chat/communication, ssh, email, calendar, music I'd suppose
Wikiwide has joined #maemo-leste
<pere> Signal?
<Wizzup> signal right now is broken until this is ready: https://gitlab.com/signald/signald/-/merge_requests/163
<Wizzup> but they're getting close to fixing it it looks like
Livio has quit [Ping timeout: 260 seconds]
Wikiwide has quit [Ping timeout: 260 seconds]
<pere> calendar is really the only overlap I got with your use case, I believe. I managed to install syncevolution, but have not investigated how to configure it yet.
<sicelo> what are your own use cases (or needs)?
<pere> I am trying to find out if it can be useful to me, and showing a copy of my ical servers calendar info and address book might be useful. and I am considering it as a ebook reader, but am not convinced I would be happy with the screen size.
<pere> sadly the dorian ebook reader is not able to download books from project gutenberg. no idea why.
<pere> I suspect using a obsolete url and failure to handle redirects, but have not investigated.
<pere> Signal on N900 connected to my signal-desktop instance on the laptop would be useful.
<Wizzup> leste.maemo.org is back (went down ~1h30mins ago)
arno11 has quit [Quit: Lost terminal]
arno11 has joined #maemo-leste
Wikiwide has joined #maemo-leste
<sixwheeledbeast> I thought you needed ios/andriod to register for signal?
<pere> btw, is it expected that the screen should turn itself off after 18 seconds?
<pere> it seem like a less optimal default.
<arno11> pere: indeed should be removed imo
<pere> I have failed to find a way to extend it
<arno11> backlight time out in setting/display ?
<arno11> sorry lockscreen
xmn has quit [Quit: ZZZzzz…]
<arno11> lockscreen + backlight time to 1 or 2 min should be fine
<arno11> btw if it takes 18 sec by default it is because of slowness (lack of optimisation)
<arno11> it takes exactly 10 sec on my device
xmn has joined #maemo-leste
<inky> pere, i tried once to revive maegutenberg or something like that. but failed and didn't try again. the od api as far as i remember was not working and for some reason i was not able to make it work with he new site. aybe if i tried for more couple of days i would o that.
<pere> inky: are you saying the gutenberg api is broken?
<sicelo> is there an official api?
Sigmanificient has quit [Ping timeout: 252 seconds]
lexik has quit [Quit: No Ping reply in 180 seconds.]
ceene has quit [Ping timeout: 252 seconds]
lexik has joined #maemo-leste
ceene has joined #maemo-leste
<sicelo> Wizzup: if i stop icd2 and start it with `icd2 -l 0`, looks like things get out of sync with gconf, e.g. saved networks start requiring psk, etc. How to restart it properly?
<sicelo> s/restart/run it in verbose mode/
<Wizzup> yes, this is a big problem and I don't know WHY things get out of sync
<Wizzup> conndlgs has this problem in particular
<Wizzup> is you restart conndlgs then the problems should go away
Sigmanificient has joined #maemo-leste
Sigmanificient has quit [Remote host closed the connection]
<sicelo> thanks
<Wizzup> as to why it gets out of sync, yeah, we need to figure this out
<Wizzup> I think icd2 does call the gconf sync thing
* sicelo is working on https://github.com/maemo-leste/bugtracker/issues/730 ... knows it's not really important, but because it's stuck on the back of his mind
ceene has quit [Remote host closed the connection]
<freemangordon> Wizzup: headers package is missing postinst file
<freemangordon> that runs maintainer scripts in /etc/kernel
<freemangordon> that's why dkms script is not invoked
Wikiwide has quit [Remote host closed the connection]
Wikiwide has joined #maemo-leste
Wikiwide has quit [Ping timeout: 265 seconds]
antranigv_ has joined #maemo-leste
<pere> I must admit, N900 is not the best build host I have around. :)
<sicelo> :-P
<bencoh> :]
antranigv has quit [Ping timeout: 252 seconds]
<freemangordon> heh
<freemangordon> Wizzup: have a fix, but building kernel takes time, will push when tested and will as you for a new release
d4dsc has left #maemo-leste [#maemo-leste]
<sicelo> mmm, this has happened twice now - i'
<sicelo> i'm compiling libicd-network-wpasupplicant on the Droid 4, when it just dies suddenly. i'm quite sure it's not power related (in fact just now it happened while connected to charger)
<freemangordon> did you increase mix charging current?
<freemangordon> *max
<freemangordon> as while compiling d4 easily goes above default 500 mA
<sicelo> i'll do that
Wikiwide has joined #maemo-leste
<freemangordon> seems to work, please make a new release
<freemangordon> or give me hints how to do it
<freemangordon> just new tag/changelog?
<Wizzup> yes, tag and changelog
<Wizzup> but I can do it if you want
<Wizzup> tag is like so: maemo-kernel-6.6.36.4
<freemangordon> please do
<Wizzup> k
<Wizzup> freemangordon: build for -devel?
<Wizzup> or experimental first
<Wizzup> I'll do the latter
<Wizzup> actually let me see if the build server is on.
<freemangordon> lets do experimental first
<freemangordon> if everything goes well, for -devel
duuude has joined #maemo-leste
<Wizzup> ok
<pere> heh, my build host crashed halfway through the build of dorian. :)
duuude has quit [Ping timeout: 244 seconds]
duuude has joined #maemo-leste
<Wizzup> pere: n900 is not a great device to build on
Livio has joined #maemo-leste
Wikiwide has quit [Remote host closed the connection]
Wikiwide has joined #maemo-leste
Wikiwide has quit [Ping timeout: 248 seconds]
antranigv_ is now known as antranigv
antranigv is now known as antranigv_
<arno11> pere: Wizzup: crashes during build are not normal on n900
<arno11> lack of optimisation
<arno11> it works pretty fine
<arno11> i mean i built lot f stuff on it with no issues
<arno11> (maybe issue wth swap, all trackers activated or other stuff like that)
<arno11> *with
<arno11> the device is even still usable during build
<arno11> perez: maybe you didn't upgrade to -devel or ?
<arno11> pere:
<arno11> all useful tweaks are in the wiki btw
<arno11> dorian should be really easy to build on n900
<arno11> ok that's not a rocket but pcsx takes around 15min to build for example
<freemangordon> still does not work, wtf?
ac_laptop has joined #maemo-leste
kreyren__ has joined #maemo-leste
<kreyren__> Hey, i installed Maemo Leste from the provided devuan fork on Nokia N900 and i can't get a sound output from it, is this like a known issue or am i doing something wrong?
<kreyren__> .. or is the very broken N900 that i spend few days fixing has a broken trace somewhere on the PCB that i need to look through
* kreyren__ is using the distribution to research the current state and how it +- works so that he can try to port the environment to NixOS as tracked in https://github.com/NixOS/nixpkgs/issues/328952
<arno11> kreyren__: sound is supposed to work OOTB
<kreyren__> arno11, any way to check? `speaker-test` maybe?
Wikiwide has joined #maemo-leste
* kreyren__ has no idea how the backend works atm assumes that it's ALSA
<arno11> there is no build-in test unfortunately
<kreyren__> actually speaker-test makes the speakers to sound well
<kreyren__> hmm weird.. i can't seem to get output from the dialer when someone's calling me
<arno11> ah maybe you didn't upgrade to devel ?
<kreyren__> arno11, eh?
<arno11> i mean, i don't know if it works well from a 'stable' img
<kreyren__> like everything seems to work well, but the dialer seems to be the sole problem
<arno11> ok but you really need to upgrade to -devel repo
<arno11> *to test calls
<kreyren__> arno11, is that like a devuan release? or how do you do that?
* kreyren__ can't find how to do that in the wiki
<arno11> ok, you have just have to add a new line in /etc/apt/sources.list
<arno11> and dist-upgrade
<arno11> the line to add is:
<arno11> deb https://maedevu.maemo.org/leste chimaera-devel main contrib non-free n900
<arno11> sorry, apt update and apt dist-upgrade
* kreyren__ is former debian dev he knows how apt works :p
<kreyren__> is that standalone repo or is that dependent on the stable release packages
<kreyren__> e.g. devuan does package additions on top of debian by default
<kreyren__> and the release doesn't work by itself without debian repos
<arno11> sorry i'm not a dev :P
<kreyren__> oke imma look through the debs then
<gnarface> devuan re-builds, patches, and re-packages a small fraction of the total debs from the debian repos, and serves the rest transparently via http redirect, so no, it doesn't work without also having access to the debian repos
<gnarface> (yet)
<gnarface> you can tell which ones devuan changed/added because they all have "devuan" in the version substring
<arno11> gnarface: thx :P
<kreyren__> gnarface, The devel repo is just a bunch of configs it seems is that all that maemo leste (distro) does?
<gnarface> np
<gnarface> kreyren__: embarrassingly enough i'm not super clear about how Maemo-Leste fits into this equation, someone around here surely knows though...
<kreyren__> gnarface, the dev mentioned in the NixOS issue tracker that they are patching gtk2, but it seems that's done on the devuan side?
<kreyren__> (if you can check as afaik u r devuan dev)
<gnarface> kreyren__: i'm not a devuan dev either, but i'm running it right here and the current stable version doesn't look like it has any custom devuan packages in the list returned by "dpkg -l |grep gtk2" on my current install
<gnarface> i think you can disambiguate this way
<gnarface> surf to deb.devuan.org
<gnarface> the /packages/devuan directory has just the devuan-forked packages, and the /packages/merged directory has both the devuan and debian packages (keep in mind the debian ones come through by http redirect at the mirror)
<gnarface> i think /merged, /devuan, and /debian used to be together at the top level but they seem to have rearranged it a bit since i last looked
<gnarface> i assume maemo-leste adds their own packages on top of that... somehow
<gnarface> maybe in the same fashion, with amprolla doing transparent http redirects at the repo, not sure
<kreyren__> There seems to be some patched libraries that seems to corelate to what the dev said in the nixos tracker so it seems that they fork devuan and change things
uvos has joined #maemo-leste
<uvos> kreyren__: you need to add "deb https://maedevu.maemo.org/leste chimaera-devel main contrib non-free droid4"
<uvos> chimaera-devel is not standalone it contains only packages that are newer than leste chimaera not all pkgs
<uvos> we fork a huge tone of packages
<uvos> voicecalls on n900 are still expiramental
<uvos> the n900 is realtively well supported but has some blemishes like very high power draw
<kreyren__> uvos, droid4?
<uvos> the only devices that you can expect to really daily use with leste are still droid4 and droid bionic
<uvos> kreyren__: sorry you need n900 ofc
<uvos> not droid4
<uvos> i just copied that line from a d4 device
<kreyren__> uvos, can you elaborate what's experimental? it's able to perform and answer calls but there is no audio atm
<uvos> you need to upgrade to devel for those to work
<uvos> in stable calls do not work atm
<kreyren__> noted
<kreyren__> thanks for info <3
<uvos> calls on n900 came online very recently
<uvos> the n900 has a very compilcated audio setup for calls
<kreyren__> i see, is that because it had to be ported from an ancient kernel or why?
<uvos> on most devices (like d4 the pinephone most modern android phones) the hw handles audio routing and processing for call audio on the n900 the cpu has to do all the work
<uvos> as the hardware is a bit impotent in this regard
<uvos> it bearly manages to do this in real time
<uvos> no not the kernel, mostly userspace work
<kreyren__> i see
<kreyren__> uvos, What's the state of maemo-leste on riscv64 btw? I got this phone for hardware development mostly to add a riscv CPU to it with the same modem pinephone's using
<uvos> kreyren__: we dont build packages for riscv and no one has tried
<gnarface> how exciting!
<gnarface> :D
<uvos> so there is nothing to say besides that in theory it should work.
<gnarface> sorry, i'm not helping
<kreyren__> uvos, i see
<uvos> the devices used by the devs here are all armv7 devices
<uvos> i dont think anyone uses the pinephone in a major way besides testing even
<gnarface> isn't pinephone armv8? oh
<uvos> thats our only arm64 target
<uvos> besides the rpi ofc
<uvos> all us devs and contirubuters use mainly n900 or droid4
<gnarface> hmm, doesn't look like debian even builds riscv packages yet...
* kreyren__ daily drives Samsung Galaxy S3 Value Edition atm, the N900 seemed like a better option as it can do games better :D
<uvos> the n900 is nice but it is very very slow
<uvos> if you can maybe also pick up a droid4, not only is it 5 times faster, its also the only linux phone with mainline kernel support that also has working power management to the point multi day battery life (new battery required ;) )
<uvos> as far as i know anyhow
<gnarface> i don't think the pinephone is very far behind that on kernel support
<gnarface> (the regular pinephone anyway, not the pro)
<uvos> the pinephone fundamentally can not do powermanagement nearly as well as the droid 4
<gnarface> that i don't doubt
<kreyren__> uvos, oh cool i will look for these, i saved these two N900 from an e-recycler
<kreyren__> uvos, pinephone has the same SoC like my OLIMEX Teres-I with the same chip for power management afaik and teres can do powermanagement without issues though
<uvos> kreyren__: no not really
<uvos> so the omap4 like any "real" smartphone chip can sleep any all of its devices for microseconds at a time this means the whole device can compleatly suspend between scheduling ticks effectively there is no difference in power consumption between the device in suspend to ram and the device being idle but running
<uvos> the allwinner in the pinephone takes mutch to long to reach sutch low power states for this to be viable
<uvos> so the cpu is suspended compleatly crust microcontroller is used to wake it back up
<uvos> this however means that it cant be running tasks and in a low power state at the same time
<gnarface> hmm, interesting
<kreyren__> hmm
<kreyren__> I guess that's because the A64 is designed for tablets
<uvos> yes
<uvos> droid 4 and n900 can to as low 8mA while being connected to the internet via the modem and checking emails and responding to incomeing ip packages for chat messages etc
<uvos> for complex reasons we cant achive this at the moment
<kreyren__> that's wild
<uvos> best we can do is something like 25mA for the droid4 and something on the order 100mW on the n900
<uvos> *on the order of 100mA
<arno11> 47mA on n900
<gnarface> well, for whatever it's worth, pine64 is already selling riscv tablets, so i think riscv debian builds will be coming soon
ac_laptop has quit [Ping timeout: 248 seconds]
<uvos> arno11: nice progress on that
<arno11> yep :P
<kreyren__> *if only StarFive gave me the hardware files docs to be able to use the chip in projects*
<arno11> uvos: btw i got 39 mA in 2g +n900pm script (OFF mode disabled) with 6.1.48
<arno11> not possible anymore
<sicelo> kreyren__: i think something else that was omitted in your GH issue is - you also need to build the kernel (which is forked to include powervr gpu support) (applies equally to d4 & n900)
<sicelo> anyway should be easy enough for Nix
<uvos> i think supporting the droid4/n900 is orthoginal to supporting hildon in nix
<uvos> so should be a different issue
<kreyren__> sicelo, PostMarketOS said that the device has full mainline no?
<uvos> kreyren__: not the gpu
<uvos> + lots of other fixes we have
<uvos> for various bits that have not landed upstream yet
<uvos> or are unsutable for now
<sicelo> postmarketOS and Leste use same kernel basically, except pmOS doesn't have the powervr stuff, so you can't run hildon on pmos
<kreyren__> Referncing tracking for adding the device to my Nix infra https://github.com/NiXium-org/NiXium/issues/119 if i missed something else, anything relevant very appreciated
<uvos> kreyren__: so you need to use our kernel if you want everything to work and the gpu requires closed source userspace bits
<uvos> for legacy reasons our kernel repo for these devices is called droid4-linux
<uvos> but its for n900/droid4/droid bionic/mz617
<freemangordon> kreyren__: re maemo repos we build on top of devuan chimaera, we have our onr repos and CI, plus some forks of packages that are in devuan/debian, but we had to do bugfixes
<freemangordon> https://github.com/maemo-leste is where we keep source of maemo specific packages
<kreyren__> freemangordon, i see, are the packages cross-compiled in deb or build natively somehow?
<kreyren__> (Nix is very sensitive on cross-compiled vs native packages)
<freemangordon> we have jenkins with native buildes (arm64 armhf and arm64)
<uvos> kreyren__: we build the packages natively
<uvos> *amd64
<kreyren__> GitHub-provided infra?
<freemangordon> ahm right, a typo
<freemangordon> no
<freemangordon> we host it
<freemangordon> well, we use github for the source code
<kreyren__> freemangordon, can you share what system you use to build these natively? I am writting RFC to NixOS foundation to support the architecture atm
<freemangordon> system like OS?
<kreyren__> Hardware
<uvos> kreyren__: we used to use a old amd operaton arm server
<uvos> kreyren__: now we use some other arm server, ask Wizzup for details
<kreyren__> uvos, thanks that's very helpful
<uvos> kreyren__: we also use qemu on amd64 for arm build occasionally
<sicelo> kreyren__: sensitive to cross-compilation? in what sense?
<kreyren__> amd operaton arm using compatibility mode for 32bit to do native i assume?
<freemangordon> not sure, Wizzup has the details
<uvos> kreyren__: yes but this machine has since died, now its some other arm server
<kreyren__> sicelo, nix is designed to provide reproducible build environments where cross-compilation introduces impurities that nix is trying to avoid as much as possible to have reproducible builds
<freemangordon> kreyren__: one more note - we build VM images for native development
<kreyren__> (reproducible results not guaranteed and much bigger issue)
<kreyren__> freemangordon, noted
<uvos> we dont have repoduceable builds atm
<gnarface> you mean AMD Opteron, i assume?
<uvos> im pretty sure some packages that will fail that
<kreyren__> uvos, nixos only has reproducible environments where the build happens but the results from these are not reproducible
<uvos> gnarface: yes the short lived arm ones
<kreyren__> bcs architecture is implemented differently and some things and CPU features interfiere with these
<gnarface> yes, news to me but apparently they came in a ARM flavor... the "Opteron A"
<gnarface> wish i'd known that when they were new...
<uvos> those where very nice machines
<kreyren__> Was the Opteron able to keep up with building the packages needed?
<uvos> yeah the operaton was great
<uvos> opteron
<uvos> jeez
<uvos> :P
<uvos> well besides failing xD
<kreyren__> hmm NixOS has altras to support aarch64 which should have the compatibility mode too, but afaik they are almost always stressed up on 100% building
<gnarface> probably the cooling fan died and quickly took the rest of the system with it...
<uvos> kreyren__: it helps that we are not a stand alone distro
<uvos> most packages are build by devuan
<uvos> idk on what they do that
<uvos> we only have 100s of pacakges not thousands
<gnarface> afaik devuan also has at least a loose "no-crossbuilds" policy
<gnarface> at least for the ARM packages
<gnarface> (stemming from an early issue with the BBB image that still doesn't work on 2/3 of the boards in the wild)
<gnarface> i don't think it's just a "no-crossbuilds" policy it's in fact a "no more builds for hardware we don't own here"
<kreyren__> wait is the opteron the CPU that fits in the Viking ASUS KCMA D8 that has coreboot?
<gnarface> (so presumably all their ARM device images are actually built on said devices)
<uvos> no
<kreyren__> oh that's amd64 mb
<kreyren__> Is this the source code for the linux that runs on the N900? Just sanity checking https://github.com/maemo-leste/droid4-linux
<uvos> kreyren__: yes maemo-6.1.y is the current stable branch
<uvos> and maemo-6.6.y is the current expiramental branch
<uvos> maemo-6.6.y should be ready to go now
<uvos> we will be promoting it soon
<uvos> so you might as well use that
<kreyren__> oke
<kreyren__> any firmware needed?
<uvos> nothing besides what is in mainline linux
<uvos> and the gpu drivers come with firmware, but that is packaged into those blobs
<kreyren__> noted
<kreyren__> did update and now i can't get internet to the device over wifi or 2G does anyone know why?
<uvos> wifi interface got renamed wlan1 maybe?
<kreyren__> wlan0 still
<uvos> try killall icd2
<kreyren__> nope
<uvos> hmm strange
<kreyren__> The whole device seems kinda broken
<kreyren__> is there a thing i can flash on the sdcard that has the devel version?
<uvos> no you can only upgrade to it
<arno11> weird
<arno11> could you pastebin your apt sources list ?
<freemangordon> ok, seems dkms autoinstall does not like 'apt install --reinstall linux-headers-bla" :(
<freemangordon> it does remove the module, but then does not rebuild it
<kreyren__> hmm i think my sim card inside slid bcs i have it there loosely bcs i didn't yet 3D print the holder for the microsim and it disconnected from the network and failed the update half way causing this to now not wanting to boot and it has wrong cmdline to not get me a serial console
<gnarface> freemangordon: i think that if you reinstall the "linux-image-bla" package after having the "linux-headers-blah" package installed (and the build tools), it should re-trigger dkms automatically
<gnarface> that said, you can re-trigger dkms manually just as easy
<uvos> you can but our users dont
<kreyren__> is the maemo-flasher still something that should be used?
<kreyren__> (would be useful to have a way to load data to the internal storage)
<freemangordon> gnarface: it does re-trigger, but dkms does nothing as dkms module is uninstalled first
<freemangordon> and then dkms autoinstall does nothing
<gnarface> hmm
<gnarface> i've only had to mess with it for nvidia drivers before
<freemangordon> thats a bug in dkms /etc/kernel script I think
<freemangordon> if you install different version, it is ok
<gnarface> maybe, there should be a log somewhere if the build failed
<freemangordon> no, the builkd is not attempted
<freemangordon> *bui;ld
<freemangordon> arg
<freemangordon> build
ac_laptop has joined #maemo-leste
<freemangordon> because there is noone in /var/lib/dkms already
<gnarface> what if you issue "dkms build" instead?
<freemangordon> as dkms /etc/kernel prerm script has uninstalled the module for the running kernel beforehand
<freemangordon> well, it is build fine if you start it by hand with either dpkg-reconfigure or dkms install
<freemangordon> it is just that it misbehaves durin re-install of the same kernel version
<freemangordon> lemme check upstream dkms
<gnarface> oh
<gnarface> i remember having to deal with it before for nvidia drivers but i don't remember what options i passed to dkms
<gnarface> i seem to remember it building for all installed kernels in series though
<freemangordon> so, this is a bug in dkms
<freemangordon> perhaps we'll have to fork it as well :(
ac_laptop has quit [Ping timeout: 248 seconds]
<freemangordon> Wizzup: so, kernel is ok, but we need dkms forked
xmn has quit [Ping timeout: 260 seconds]
<Wizzup> 21:57 < kreyren__> amd operaton arm using compatibility mode for 32bit to do native i assume?
<Wizzup> yes
<Wizzup> it's the honeycomb from solidrun with two qemu's on top, one for armhf and one for aarch64
<Wizzup> but the bare honeycomb, not the fancy one
<Wizzup> wil respond to other stuff tomorrow when I'm back home
<kreyren__> Wizzup, qemu's very resource inefficient afaik
<kreyren__> or is that different running that on arm?
<kreyren__> Wizzup, ok thanks for info! <3
<kreyren__> So i reflashed the sdcard and did the upgrade on devel and the system is again very broken
<kreyren__> you said add the line with the -devel like below the chimaera release of maemo or add the -devel line to the last line?
<kreyren__> bcs i just added the -devel line
<kreyren__> > chimaera-devel is not standalone it contains only packages that are newer than leste chimaera not all pkgs
<kreyren__> i see my bad
Livio has quit [Ping timeout: 248 seconds]
<gnarface> kreyren__: you can tell qemu to just use a particular number of host cpu cores directly without actually emulating them
<kreyren__> gnarface, oh i see
<gnarface> it's not as efficient as something like the linux-vservers kernel patch, but it does mitigate a lot of the emulation overhead, especially if you have working hardware kvm/iommu acceleration
<arno11> kreyren__: your sources.list should be:
<arno11> ignore the last line (experimental repo)
akossh has left #maemo-leste [#maemo-leste]
<gnarface> arno11: just fyi, Devuan ops prefer people would use deb.devuan.org (a dns round-robin of mirrors of pkgmaster, which also contains pkgmaster) instead of just using pkgmaster directly, to reduce their bandwidth load
<gnarface> not all the mirrors are super great on bandwidth themselves though, so i don't blame you
<gnarface> in a fair world, the only difference should be a minor periodic delay of mirror replication during updates
<gnarface> people who have problems with the dns-rr usually just pick the mirror off the list closest to them (http://deb.devuan.org/mirror_list.txt)
<gnarface> i am not officially affiliated with Devuan, i just hang out in their channel
<arno11> fair enough :P
<kreyren__> arno11, ye i just added -devel thinking that's enough, trying to reboot now with these sources thanks for clarification
<gnarface> kreyren__: did you "apt-get update && apt-get dist-upgrade" after changing the sources.list?
<kreyren__> gnarface, vservers? Hmm i am in the middle of deploying Xen infra-wide in nixium i wonder if it would help for this
<kreyren__> gnarface, yep
<kreyren__> wait no, i did full-upgrade
<kreyren__> afaik it does upgrade and dist-upgrade
<gnarface> i am not sure
<kreyren__> {"full-upgrade", &DoDistUpgrade, _("upgrade the system by removing/installing/upgrading packages")},
<kreyren__> seems that full-upgrade is the modern and the dist-upgrade is obsolete and kept there for legacy and muscle memory?
<gnarface> http://linux-vserver.org/ if you're interested, and their channel is over on OFTC, but if you're deploying it for work Xen might be a safer choice just because it's got current support. the linux-vserver project has kinda fallen on hard times and doesn't have as much current kernel support, and also isn't really for emulation, so running non-linux guests isn't an option
<kreyren__> like the problem on xen is that it's arm support is experimental as well
<gnarface> but, it's lightweight enough you could conceivably run it on your actual phone with no overhead
<kreyren__> interesting
<kreyren__> to what benefit considering the limited processing resources of N900?
<gnarface> maybe none :) i mostly use it for my quake server farm
<kreyren__> heh
<gnarface> it's good for if you're running internet-connected services you're afraid might get hacked and you want some way to keep any potential breaches from being used to breach other services
<gnarface> it's got a lot of functional overlap with something like bsd "jails"
<gnarface> in modern linux kernels, the various "namespaces" features have started to largely obsolete the old vserver features, but still don't quite reach the same level of feature-complete paranoia, especially with regards to the network layer
<kreyren__> NiXium is trying to manage that threat by using lokinet for intraweb comms and as a layer that deploys services for clearweb with PQS SSH that requires pubkeys and services in their invidual sandboxes on impermanent system
<kreyren__> rebooted the phone and it seems to work so far ^-^
<gnarface> cool!
<kreyren__> > Backend ring/tel/account0
<kreyren__> instead of ofono
<kreyren__> The phone also seems much more responsive ^^
<gnarface> nice
Wikiwide has quit [Remote host closed the connection]
Wikiwide has joined #maemo-leste
Wikiwide has quit [Remote host closed the connection]
Wikiwide has joined #maemo-leste
<arno11> kreyren__: it is bit late for me but tomorrow i can provide you few tweaks to improve perfs a LOT :P
Wikiwide has quit [Remote host closed the connection]
<kreyren__> arno11, thanks that would help a lot too, i would like to update the wiki
Wikiwide has joined #maemo-leste
Wikiwide has quit [Remote host closed the connection]
Wikiwide has joined #maemo-leste
<arno11> zzz time
arno11 has left #maemo-leste [#maemo-leste]
Wikiwide has quit [Remote host closed the connection]
Wikiwide has joined #maemo-leste
mdz has quit [Ping timeout: 260 seconds]
<kreyren__> arno11, gn~ <3
Wikiwide has quit [Remote host closed the connection]
Wikiwide has joined #maemo-leste
uvos has quit [Remote host closed the connection]
KREYREN_ has joined #maemo-leste
kreyren__ has quit [Remote host closed the connection]
antranigv_ is now known as antranigv