| 00:24.56 | *** join/#maemo infobot (ibot@rikers.org) |
| 00:24.56 | *** topic/#maemo is Welcome to #maemo http://maemo.org/intro/ | N9/harmattan related questions please in #harmattan ! | "firmware" see ~lf ~tabletsdev ~combined ~emmc ~flasher sdk: ~sb | http://wiki.maemo.org/Community_Council | Source: http://wiki.maemo.org/Sources | Chanlog: http://mg.pov.lt/maemo-irclog | #maemo-ssu is where the (few) devels and maintainers of the maemo-future meet |
| 00:35.16 | *** join/#maemo LouisA (~user@cable-10-151-99.b2b2c.ca) |
| 00:35.24 | LouisA | hey guys |
| 01:30.01 | *** join/#maemo cyphase (~cyphase@unaffiliated/cyphase) |
| 01:58.25 | *** join/#maemo hurrian (~textual@unaffiliated/rikanee) |
| 03:27.14 | *** join/#maemo luke-jr (~luke-jr@unaffiliated/luke-jr) |
| 03:38.37 | *** join/#maemo vahe (~vahe@130.193.124.163) |
| 03:45.53 | *** join/#maemo pagurus` (~user@p4FDC3067.dip0.t-ipconnect.de) |
| 03:47.47 | *** join/#maemo pagurus (~user@p4FDC3067.dip0.t-ipconnect.de) |
| 04:31.48 | *** join/#maemo DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 07:51.34 | *** join/#maemo ginggs (~quassel@quassel.tumbleweed.org.za) |
| 07:54.58 | *** join/#maemo HRH_H_Crab (~crab@kowloontong.dim-sum.org) |
| 07:57.04 | *** join/#maemo xorly (~xorly@ip-86-49-24-93.net.upcbroadband.cz) |
| 08:31.49 | *** join/#maemo xorly (~xorly@ip-86-49-24-93.net.upcbroadband.cz) |
| 08:52.03 | *** join/#maemo xorly (~xorly@ip-86-49-24-93.net.upcbroadband.cz) |
| 09:22.53 | *** join/#maemo crazyguy` (~user@2a02:a450:2b18:1:4ca4:37ec:833d:ebf0) |
| 09:28.03 | *** join/#maemo florian (~fuchs@x4d094197.dyn.telefonica.de) |
| 10:12.46 | *** join/#maemo LouisA (~user@cable-10-151-99.b2b2c.ca) |
| 10:44.38 | *** join/#maemo shentey (~shentey@x4e34c74d.dyn.telefonica.de) |
| 10:44.47 | *** join/#maemo Pali (~pali@Maemo/community/contributor/Pali) |
| 10:51.23 | *** join/#maemo shentey (~shentey@x4e34c74d.dyn.telefonica.de) |
| 11:42.04 | *** join/#maemo xy2_ (~xy2_@mlv95-h01-176-134-46-233.dsl.sta.abo.bbox.fr) |
| 11:57.08 | *** join/#maemo L29Ah (~L29Ah@2002:c35b:ef08::1) |
| 12:13.05 | *** part/#maemo L29Ah (~L29Ah@2002:c35b:ef08::1) |
| 12:21.14 | *** join/#maemo hurrian (~textual@unaffiliated/rikanee) |
| 12:35.39 | *** join/#maemo herekun (~herekun@ppp109-252-26-94.pppoe.spdop.ru) |
| 12:49.38 | *** join/#maemo shentey_ (~shentey@x4e34f296.dyn.telefonica.de) |
| 12:57.27 | *** join/#maemo xy2_ (~xy2_@mlv95-h01-176-134-46-233.dsl.sta.abo.bbox.fr) |
| 13:12.41 | *** join/#maemo xy2_ (~xy2_@mlv95-h01-176-134-46-233.dsl.sta.abo.bbox.fr) |
| 13:18.18 | *** join/#maemo dafox (~dafox@2a02:a448:c25a:1:7061:3b2a:37df:ded3) |
| 14:19.49 | *** join/#maemo mavhc (~mavhc@cpc77319-basf12-2-0-cust433.12-3.cable.virginm.net) |
| 14:24.12 | *** join/#maemo Cor-Ai (~cor-ai@c-57d071d5.06-922-7570702.cust.bredbandsbolaget.se) |
| 15:05.00 | *** join/#maemo SmilyOrg (~SmilzOrg@ip5f5bd58b.dynamic.kabel-deutschland.de) |
| 15:16.50 | *** join/#maemo auenfx4 (David@CPE-60-229-46-143.lns9.ken.bigpond.net.au) |
| 15:18.29 | *** join/#maemo L29Ah (~L29Ah@2002:c35b:ef08::1) |
| 15:40.21 | *** part/#maemo L29Ah (~L29Ah@2002:c35b:ef08::1) |
| 15:55.08 | *** join/#maemo L29Ah (~L29Ah@2002:c35b:ef08::1) |
| 16:14.24 | *** join/#maemo auenf (David@CPE-60-229-46-143.lns9.ken.bigpond.net.au) |
| 16:21.34 | *** join/#maemo xy2_ (~xy2_@mlv95-h01-176-134-46-233.dsl.sta.abo.bbox.fr) |
| 16:25.19 | *** part/#maemo L29Ah (~L29Ah@2002:c35b:ef08::1) |
| 16:25.42 | *** join/#maemo L29Ah (~L29Ah@2002:c35b:ef08::1) |
| 16:47.04 | *** join/#maemo msava (~mircea@gateway/vpn/privateinternetaccess/msava) |
| 16:48.29 | *** join/#maemo msava (~mircea@gateway/vpn/privateinternetaccess/msava) |
| 16:51.05 | *** join/#maemo msava (~mircea@gateway/vpn/privateinternetaccess/msava) |
| 17:03.02 | *** join/#maemo msava (~mircea@gateway/vpn/privateinternetaccess/msava) |
| 17:03.09 | *** join/#maemo Pali (~pali@Maemo/community/contributor/Pali) |
| 17:04.09 | *** join/#maemo msava (~mircea@gateway/vpn/privateinternetaccess/msava) |
| 17:24.39 | *** join/#maemo mp107 (~mp107___@PC-109-125-232-42.wegrow.domtel.com.pl) |
| 17:59.34 | freemangordon | Pali: ping |
| 17:59.39 | *** join/#maemo platicus (~matrixirc@fanzine.igalia.com) |
| 17:59.43 | *** join/#maemo tanty (~agomeziga@fanzine.igalia.com) |
| 18:00.11 | freemangordon | anyway, it is not a question only for Pali, so... |
| 18:01.32 | freemangordon | Wizzup: parazyd: while implementing maemo gtk on top of upstream, I am facing a hard to be solved problem how to access various widgets private structure members |
| 18:01.54 | freemangordon | I can think of 2 options, both of them i don;t really like: |
| 18:03.26 | freemangordon | 1. redefine private structure in my code, call g_type_instance_get_private and call it a day. |
| 18:03.43 | freemangordon | 2. reimplement the whole class instead of just subclassing |
| 18:04.25 | freemangordon | 1. is really, really ugly, but needs less coding |
| 18:06.43 | freemangordon | 2, is not *that* ugly, but I'll have to LD_PRELOAD hildon-gtk and hack in the gtk_whatever_widget functions, which may conflict with GTK3 programs. also, I am not sure how will that work in case of "inter-gtk" calls |
| 18:07.19 | freemangordon | so, do you have any other idea on how to achieve that? |
| 18:07.42 | freemangordon | bencoh: KotCzarny: the same question to you, and all other that can help |
| 18:07.48 | freemangordon | *all others |
| 18:07.52 | KotCzarny | arent private members meant to be private? |
| 18:08.14 | freemangordon | yes, but I am trying to act like a part of gtk itself |
| 18:08.15 | KotCzarny | ie. either find interface/func to access them or it might fall apart/be incompatible |
| 18:08.25 | freemangordon | yes, I know |
| 18:08.38 | freemangordon | thus "really, really ugly" |
| 18:08.41 | KotCzarny | gtk has a concept of custom widgets? |
| 18:09.05 | freemangordon | I am trying to implement hildon gtk, without patching gtk code :) |
| 18:09.28 | *** join/#maemo platicus (~matrixirc@fanzine.igalia.com) |
| 18:09.31 | *** join/#maemo tanty (~agomeziga@fanzine.igalia.com) |
| 18:09.51 | KotCzarny | and you want to overload them in existing apps or just add hildon functionality? |
| 18:10.25 | freemangordon | both |
| 18:10.35 | KotCzarny | hrm |
| 18:10.48 | freemangordon | as adding hildon functionality requires accessing gtk internals |
| 18:11.04 | freemangordon | KotCzarny: see https://github.com/community-ssu/gtk/blob/master/gtk/gtkiconview.c#L1565 |
| 18:11.08 | freemangordon | for example |
| 18:11.16 | KotCzarny | how about writing gtk-hildon port and provide it as an alternative (while being a requirement for hildon enabled apps/) |
| 18:11.19 | bencoh | freemangordon: how does it work thus far then? |
| 18:11.37 | freemangordon | bencoh: where? |
| 18:11.39 | bencoh | and by "upstream" do you mean gtk2 or gtk3 (or doesn't matter)? |
| 18:11.43 | freemangordon | gtk2 |
| 18:11.45 | KotCzarny | in a way jpegturbo 'overloads' libjpeg |
| 18:11.47 | bencoh | freemangordon: on current maemo/gtk2 |
| 18:12.00 | freemangordon | bencoh: code is heavily patched |
| 18:12.01 | KotCzarny | bencoh: on maemo nokia just forked gtk |
| 18:12.24 | freemangordon | KotCzarny: I don't want to fork gtk |
| 18:12.52 | bencoh | freemangordon: gtk on maemo is heavily patched? |
| 18:12.59 | KotCzarny | bencoh: yup |
| 18:13.01 | freemangordon | KotCzarny: re "in a way jpegturbo 'overloads' libjpeg" |
| 18:13.02 | bencoh | I see :/ |
| 18:13.23 | freemangordon | bencoh: just look at GtkIconView code ^^^ |
| 18:13.27 | KotCzarny | fmg, why not? gtk2 wouldnt receive updates afair |
| 18:14.03 | bencoh | freemangordon: aww.... that's not pretty :/ |
| 18:14.18 | KotCzarny | and it would allow you to do things more elegant |
| 18:14.31 | freemangordon | KotCzarny: because, this is lots of work, I'd rather avoid if possible |
| 18:14.44 | KotCzarny | fmg, but you are doing it anyway, no? |
| 18:14.47 | freemangordon | KotCzarny: no |
| 18:15.18 | KotCzarny | i dont understand why do you need private members then and the 'implement hildon functionality' |
| 18:15.30 | freemangordon | or rather - I am doing maemo part only, and if I make it that way, it won;t depend on gtk2 version |
| 18:15.40 | freemangordon | KotCzarny: look at the code ^^^ |
| 18:15.49 | KotCzarny | cant at the moment, console only |
| 18:15.55 | KotCzarny | without mouse |
| 18:16.06 | bencoh | ah :] |
| 18:16.16 | bencoh | copypaste in screen! :D |
| 18:16.24 | KotCzarny | :) |
| 18:16.49 | freemangordon | will explain - for example GtkIconView has a list of "items" which are in priv struc only, without accessor functions |
| 18:17.17 | freemangordon | hildon gtk draws a tick mark on every selected item |
| 18:17.29 | KotCzarny | hmm, afair you can get access to items in tree/list store |
| 18:17.37 | freemangordon | KotCzarny: how? |
| 18:17.56 | freemangordon | you get some cryptic GtkTreePath or somesuch |
| 18:17.56 | KotCzarny | by accessing it's tree/list store? |
| 18:18.14 | KotCzarny | yeah, its hell to understand, but you can |
| 18:18.17 | freemangordon | there is no way to access it, at least I was unable to find one for the last 3 days |
| 18:18.27 | KotCzarny | check oscp-remote-gtk |
| 18:18.33 | KotCzarny | i have some helper funcs there |
| 18:18.46 | KotCzarny | not the best code in the world but.. |
| 18:18.58 | KotCzarny | let me check the link for you |
| 18:19.00 | freemangordon | where is the code, on github? |
| 18:19.30 | Enrico_Menotti | Hello. I have Devuan booting on the n900. The system image is one I just debootstrapped on Devuan rc which I installed yesterday on my old laptop. But I have problems with the kernel. Someone here (I don't remember who exactly was, if freemangordon or parazyd ) had given me another kernel image. If I use that one, Devuan boots. However, with a kernel I built a few days ago, and also with one built right now, Devuan |
| 18:19.31 | Enrico_Menotti | <PROTECTED> |
| 18:19.46 | KotCzarny | 31.135.195.151:20280/arch/oscp/ |
| 18:19.57 | KotCzarny | sorry, typed that manually |
| 18:20.10 | KotCzarny | it's a source package prepared for arch |
| 18:20.41 | freemangordon | KotCzarny: thanks, going to dig in it |
| 18:20.41 | KotCzarny | oscp-remote-gtk is in libs/_tools/ |
| 18:20.54 | KotCzarny | it's hackish, but works for me |
| 18:20.54 | freemangordon | Enrico_Menotti: sorry, don;t have time now |
| 18:21.10 | bencoh | is wdog enabled at boot? |
| 18:21.10 | Enrico_Menotti | freemangordon No problem. |
| 18:21.13 | KotCzarny | accessing items in both, via iterators and via element reference |
| 18:21.16 | bencoh | (that'd be strange, but ... who knows) |
| 18:22.20 | Enrico_Menotti | bencoh Is there a parameter to enable the watchdog manually? |
| 18:22.29 | freemangordon | KotCzarny: any hint where to look at? as it is lots of code there |
| 18:22.49 | KotCzarny | you probably want to look at oscp-remote-gtk.c func tv_show() |
| 18:23.17 | KotCzarny | and tv_click() |
| 18:25.08 | freemangordon | KotCzarny: there is no access to the underlying items, just to the path |
| 18:25.53 | freemangordon | and I didn;t find a way to get dimensions and position of cells in GtkIconView |
| 18:26.28 | freemangordon | and I need those to be able to draw a tick GdkPixbuf |
| 18:28.14 | KotCzarny | why not defining your own widget then? |
| 18:28.42 | freemangordon | KotCzarny: because all maemo applications will have to be ported to use it :) |
| 18:28.59 | KotCzarny | see? fork it |
| 18:29.01 | KotCzarny | :) |
| 18:29.05 | freemangordon | hehe |
| 18:29.39 | freemangordon | I'd rather avoid that if possible |
| 18:30.44 | *** join/#maemo eMHa_ (~mh@p200300738E323F00267703FFFE6CC360.dip0.t-ipconnect.de) |
| 18:30.45 | *** join/#maemo florian (~fuchs@87.140.193.251) |
| 18:31.43 | KotCzarny | maybe just replace the icon with tick drawn over it? |
| 18:32.27 | freemangordon | KotCzarny: I cannot get the coordinates of the bounding box of the cell to draw into |
| 18:32.41 | freemangordon | otherwise there is no problem to draw one more icon |
| 18:32.55 | KotCzarny | not one more icon, replace the image |
| 18:33.44 | freemangordon | I cannot do that, see http://talk.maemo.org/showpost.php?p=1527039&postcount=168 |
| 18:33.57 | KotCzarny | will check links tomorrow |
| 18:34.00 | freemangordon | "Activate views" is GtkIconView |
| 18:36.01 | bencoh | Enrico_Menotti: no idea actually, that was just an idea |
| 18:36.27 | Enrico_Menotti | bencoh Actually I think that be the problem. But I don't know why. |
| 18:39.29 | parazyd | Enrico_Menotti: you have to load the watchdog modules on boot, or include them in the kernel |
| 18:39.43 | bencoh | ah :) |
| 18:39.49 | parazyd | i don't remember the names, but grep the kernel config for WATCHDOG |
| 18:40.22 | Enrico_Menotti | parazyd So your kernel has the modules included? |
| 18:40.56 | Enrico_Menotti | Also, why with Debian no problem? |
| 18:41.55 | parazyd | yes, the config is here: https://github.com/dyne/arm-sdk/raw/next/boards/kernel-configs/n900.config |
| 18:42.03 | parazyd | i don't know, i never tried debian |
| 18:42.15 | DocScrutinizer05 | wonders if ANYBODY _ever_ will tackle the relatively (in relation to the above) simple task of just building a maemo5 armel image based on debian/devuan from scratch |
| 18:42.45 | DocScrutinizer05 | without massive porting to new kernels, new libs, new arch |
| 18:44.51 | parazyd | freemangordon: you cannot get the coordinates of the tick box or the parent? |
| 18:47.23 | freemangordon | parazyd: of the tick box |
| 18:48.09 | freemangordon | parazyd: or to make it more clear - I have to draw tick mark in every selected cell |
| 18:48.32 | parazyd | ah, so you don't know the cell sizes |
| 18:48.37 | freemangordon | mhm |
| 18:48.49 | freemangordon | and positions |
| 18:49.03 | parazyd | no, i thought just spawning the tick box on the opposite of 0,0 |
| 18:49.03 | parazyd | nevermind then :D |
| 18:49.23 | freemangordon | maybe I can calculate those, but ... |
| 18:49.50 | freemangordon | hmm, maybe this is the correct way to do it |
| 18:52.32 | DocScrutinizer05 | I'm afraid this whole porting thing leads nowhere near anything that would be capable of running apps from maemo-extras (unless somebody would recompile them, which obviously is a mad idea to do) |
| 18:53.58 | freemangordon | DocScrutinizer05: actually those should run without recompiling, at least on x86 |
| 18:54.45 | freemangordon | and on armel as well |
| 18:54.55 | KotCzarny | fork the lib, told'ya |
| 18:55.08 | parazyd | aren't the libs they are linked to much older than current? |
| 18:55.13 | KotCzarny | for gtk2 you are quite safe |
| 18:55.20 | freemangordon | parazyd: so? |
| 18:55.31 | freemangordon | KotCzarny: and what about gtk3? |
| 18:55.35 | parazyd | freemangordon: maybe stuff is gone |
| 18:55.41 | KotCzarny | for gtk3 you have to rewrite apps anyway |
| 18:55.49 | KotCzarny | not even recompile would help |
| 18:56.19 | freemangordon | if we talk hildon stuff, what is there is decided by us |
| 18:56.36 | freemangordon | but yeah, there might be removeed function |
| 18:56.42 | freemangordon | *removed functions |
| 18:57.12 | parazyd | yeah i think DocScrutinizer05 is talking about _all_ the software from the repos... anyway. /end bikeshedding |
| 18:57.13 | freemangordon | parazyd: what about having forked gtk2 in devuan-maemo repo? what is the policy? |
| 18:57.34 | parazyd | freemangordon: you're free to do so as long as you keep backwards compat |
| 18:57.41 | parazyd | (because of everything else using gtk2) |
| 18:57.46 | freemangordon | define backwards please |
| 18:57.55 | KotCzarny | plain gtk2 apps |
| 18:57.58 | freemangordon | as it will change the way gtk apps look |
| 18:58.40 | freemangordon | do we talk ABI only here? |
| 18:58.46 | parazyd | abi |
| 18:58.48 | parazyd | yes |
| 18:58.55 | freemangordon | hmm |
| 18:59.33 | parazyd | the look isn't the problem, i mean everything will be running inside hildon anyway |
| 18:59.33 | parazyd | it's just the calls |
| 18:59.34 | KotCzarny | as a bonus, those old gtk2 apps might get few new features, fe. pannable areas? ;) |
| 18:59.54 | bencoh | waitamin, there is an independent devuan-maemo repo? |
| 19:00.01 | KotCzarny | pretty handy with touch screens |
| 19:00.09 | freemangordon | bencoh: WIP |
| 19:00.15 | parazyd | bencoh: there will be |
| 19:00.22 | DocScrutinizer05 | that's the idea |
| 19:01.11 | parazyd | freemangordon: we'll be free to experiment in any case. that's the point of the thing. the repo is separate from devuan, and we just include the pacakges we want |
| 19:01.25 | parazyd | then they take precedence over devuan's |
| 19:01.44 | DocScrutinizer05 | just like CSSU |
| 19:02.00 | DocScrutinizer05 | well, technically different, but same effect |
| 19:02.04 | Wizzup | freemangordon: I'd be fine with (1) for now |
| 19:02.35 | freemangordon | parazyd: well, forward-porting all hildon gtk stuff for the sake of experiment... a bit of an overkill :) |
| 19:03.02 | Wizzup | I'd go with relatively little effort for now, unless it means -a lot more work- in the future |
| 19:03.11 | Wizzup | this just sounds like an ugly hack, but not something that will bite us anytime soon |
| 19:03.21 | freemangordon | parazyd: ah, BTW which of those 2 options you dislike less? |
| 19:03.42 | DocScrutinizer05 | Wizzup: that's a good approach |
| 19:03.43 | freemangordon | Wizzup: yes, gtk2 private structures won;t change |
| 19:03.44 | parazyd | always less code |
| 19:04.40 | freemangordon | though I am not sure it will be less code, as I'll have to override almost all of the class functions |
| 19:05.15 | DocScrutinizer05 | ((<parazyd> yeah i think DocScrutinizer05 is talking about _all_ the software from the repos...)) of course. And I don't see freemangordon not doing so |
| 19:05.27 | DocScrutinizer05 | maybe I missed the point |
| 19:05.49 | *** join/#maemo LouisA (~user@cable-10-151-99.b2b2c.ca) |
| 19:05.52 | DocScrutinizer05 | that's why I insist in armel instead armhf images |
| 19:06.41 | bencoh | ... |
| 19:07.25 | DocScrutinizer05 | which are admittely a tad less effective, but according to studies quoted on debian wiki, "up to 40% faster for **heavily numbercrunching** apps" OWTTE |
| 19:07.25 | freemangordon | Wizzup: parazyd: the correct way is to fork gtk2, this is for sure. Maybe I'll just bite the bullet and do it. |
| 19:09.16 | freemangordon | parazyd: If I choose that route, do you know which git repo shall I use as a base? debian? or there is devuan repo for all the stuff? |
| 19:09.46 | parazyd | we haven't forked gtk2 |
| 19:10.01 | parazyd | but you should do an apt-get source from devuan to be sure you have the right thing |
| 19:10.03 | DocScrutinizer05 | while possibly it's irrelevant for the particular app if itself is softfp or hf build, and different apps may coexist, I see problems in libs and in task scheduler when both are used in parallel |
| 19:12.18 | *** join/#maemo xes_ (~xes@unaffiliated/xes) |
| 19:12.58 | DocScrutinizer05 | if we could maje sure all lib ABIs are agnostic of softfp vs hf and the task switcher in scheduler will take care of *all* registers (incl FP), it *might* even work to run armel apps in a hf environment, as long as the softfp libs are available |
| 19:13.08 | DocScrutinizer05 | disclaimer: AIUI |
| 19:14.28 | DocScrutinizer05 | (if softfp are even shared object libs and not embedded code by gcc during build time) |
| 19:14.39 | freemangordon | Wizzup: parazyd: seems I am not the only one https://git.javispedro.com/cgit/topmenu-gtk.git/tree/module/menuitem-proxy.c#n138 :) |
| 19:14.51 | freemangordon | and this is in debian repos |
| 19:15.40 | freemangordon | ok, going the hacky way for now |
| 19:16.52 | DocScrutinizer05 | freemangordon: would you know if the armel scheduler saves (and restores) the FP registers on task switching? |
| 19:17.51 | DocScrutinizer05 | also I hope all kernel tasks preserve FP as well |
| 19:18.05 | freemangordon | don't know, sorry, but in theory all regs should be saved |
| 19:18.16 | DocScrutinizer05 | ack, thought as much |
| 19:18.18 | freemangordon | along with all the state |
| 19:19.11 | DocScrutinizer05 | trying to wrap my head around that damn soft(fp) vs hf thing |
| 19:19.22 | DocScrutinizer05 | and armel vs armhf |
| 19:19.33 | KotCzarny | fmg: why not maemo's gtk? |
| 19:19.49 | DocScrutinizer05 | I recall back with meego it was like 2 weeks of arguing |
| 19:20.52 | freemangordon | KotCzarny: in what regard? |
| 19:21.05 | freemangordon | what to do with maemo's gtk? |
| 19:22.48 | *** join/#maemo florian (~fuchs@Maemo/community/contributor/florian) |
| 19:25.23 | KotCzarny | to take it as a fork base |
| 19:25.42 | freemangordon | it is old |
| 19:26.03 | KotCzarny | it is, unfortunatelly |
| 19:26.34 | DocScrutinizer05 | it worked, so far |
| 19:26.58 | KotCzarny | quite a lot of packages would require newer one |
| 19:27.35 | DocScrutinizer05 | there's always "quite a lot of packages that require newer than X version of Y" out there |
| 19:27.58 | KotCzarny | as in: most of them (from devuan binary repos) |
| 19:50.39 | *** join/#maemo mp107 (~mp107___@PC-109-125-232-42.wegrow.domtel.com.pl) |
| 20:26.57 | *** join/#maemo sunshavi (~user@190.234.106.143) |
| 20:43.28 | *** join/#maemo shentey (~shentey@x4e35051a.dyn.telefonica.de) |
| 21:11.46 | *** join/#maemo ssvb (~ssvb@dsl-espbrasgw1-54fa71-124.dhcp.inet.fi) |
| 21:42.07 | Enrico_Menotti | Maybe I have some clues about my kernel problem in booting Devuan on the N900. The one by parazyd has the watchdogs incorporated, as he said. Mine has them in the modules, and for some reason they are not loaded. In any case, with both kernels, at boot I get the following error: |
| 21:42.09 | Enrico_Menotti | mount failed for selinuxfs on /sys/fs/selinux: no such file or directory |
| 21:42.28 | Enrico_Menotti | I may be wrong, but maybe this delays too much the module loading. |
| 21:42.49 | Enrico_Menotti | In any case, does anyone have an idea on how to have /sys/fs/selinux created? |
| 21:43.00 | Wizzup | I ... don't think you need selinux. |
| 21:43.15 | Enrico_Menotti | Yes I don't need it but is seems to be enabled. |
| 21:43.42 | Enrico_Menotti | And causes that error, which may be source for further trouble. |
| 21:43.56 | Wizzup | I doubt it. |
| 21:44.28 | Enrico_Menotti | Well, it's unlikely, yes. |
| 21:45.11 | parazyd | the error, it's not affecting you |
| 21:45.33 | parazyd | you can disregard it |
| 21:45.34 | Maxdamantus | Did you do anything special for the watchdog modules? They should normally be built and distributed at the same time as all other modules. |
| 21:45.55 | Enrico_Menotti | I am able to boot Debian with my kernel. |
| 21:46.03 | parazyd | they aren't being loaded because he didn't add them to /etc/modules |
| 21:46.11 | Enrico_Menotti | I did the same thing for the modules in Devuan. |
| 21:46.40 | Enrico_Menotti | parazyd Isn't enough a make modules_install? |
| 21:46.42 | parazyd | Enrico_Menotti: either compile them into the kernel or add them in /etc/modules for them to autoload |
| 21:46.49 | Wizzup | just put them in the kernel. |
| 21:46.54 | parazyd | no, there is no userspace calling for the modules |
| 21:46.56 | Wizzup | there's no reason not to have the watchdog not in the kernel. |
| 21:47.02 | parazyd | the system won't load them on its own |
| 21:47.13 | parazyd | Wizzup: ++, i don't see why it's not like that in rx51_defconfig |
| 21:48.17 | Maxdamantus | on my system I just load them before contiuing with the debian init. |
| 21:48.26 | Wizzup | and you do it within 25 seconds |
| 21:48.33 | Wizzup | and if fsck runs before you do that... etc |
| 21:48.44 | Wizzup | but yeah, if you do it in initramfs, it's probably fine |
| 21:51.22 | Maxdamantus | intentionally does it before fsck even when booting normal maemo |
| 21:51.35 | Enrico_Menotti | Sorry, my computer crashed. This stupid Mac crashes very often in the last days. |
| 21:51.53 | Enrico_Menotti | So maybe I lost some message - I will read the log. |
| 21:52.41 | Maxdamantus | since fsck often takes more than 30 seconds (ext4), and the watchdogs don't seem to get triggered when the ext4 driver itself is doing the cleanup that fsck often does. |
| 21:53.43 | Enrico_Menotti | Ok, I didn't lose anything. |
| 21:54.01 | Enrico_Menotti | I will try to add the modules to /etc/modules. |
| 21:54.13 | Enrico_Menotti | If that fails, I will rebuild the kernel with the modules in it. |
| 21:54.33 | Enrico_Menotti | Just one detail: how exactly to add the modules in /etc/modules? |
| 21:58.57 | Enrico_Menotti | And in Debian I see that file is empty. So how are the modules loaded there? |
| 22:00.02 | parazyd | it's explained in the file |
| 22:02.12 | Enrico_Menotti | So just the names? |
| 22:03.02 | Enrico_Menotti | And I found this: https://wiki.debian.org/Modules. This states that "Nowadays, most modules related to hardware support should be automatically loaded, thanks to udev and modules alias that are hardcoded in kernel modules (see the alias fields in modinfo snd-hda-intel output)." This would explain why in Debian the modules are loaded and in Devuan not. |
| 22:13.48 | DocScrutinizer05 | you want particularly watchdogs to be in kernel or at very least get force-loaded very early by a simple process, not via udev |
| 22:15.01 | DocScrutinizer05 | mind you watchdogs are timing critical |
| 22:15.27 | DocScrutinizer05 | unlike pretty much *all* ither possible modules |
| 22:15.36 | DocScrutinizer05 | other* |
| 22:15.58 | DocScrutinizer05 | was a probelm with uBoot iirc |
| 22:16.16 | DocScrutinizer05 | uBoot bailing out and rebooting after 30s |
| 22:17.17 | DocScrutinizer05 | and uBoot loading a kernel after 25s then the jernel had only an additional 5s until watchdog throws sticks at kernel's legs |
| 22:18.50 | DocScrutinizer05 | though I'm a tad surprised about that, thought watcghdogs wake up from power-down in inactive state |
| 22:38.24 | Enrico_Menotti | Ok, I got a list of modules loaded in my Debian image. But how may I understand which ones are needed at boot time, in order to tell Devuan to load them? |
| 22:40.33 | *** join/#maemo Wizzup (~Wizzup@a82-161-36-93.adsl.xs4all.nl) |
| 22:42.48 | *** join/#maemo Wizzup (~Wizzup@a82-161-36-93.adsl.xs4all.nl) |
| 22:47.04 | *** join/#maemo sledges (~sleleiva@unaffiliated/sledgeas) |
| 22:59.30 | DocScrutinizer05 | no way |
| 23:00.08 | DocScrutinizer05 | except learning about, and understanding, the complete boot process |
| 23:06.26 | *** join/#maemo Kabouik_ (~kabouik@92.93.76.65) |
| 23:14.28 | Enrico_Menotti | Ok, I will do that (slowly). But, however probably not related with this issue, I'd also like to completely disable selinux, so to avoid that fastidious error. If I got it, it is not enabled in kernel (/sys/fs/selinux does not exist). But somehow it is enabled in the system image. But I may be completely wrong. In any case, what is the right place for discussing this, maybe #selinux? |
| 23:15.02 | Wizzup | I doubt it... |
| 23:15.35 | Wizzup | Are you sure you're not just chasing a lot of ghost bugs? Why are you trying to build all thing by yourself when you run into these issues ? I'm generally curious |
| 23:15.40 | Wizzup | Although I do need to sleep soon... |
| 23:18.40 | Enrico_Menotti | Well, I'm trying to learn, first. In any case, the selinux issue is present also in the Devuan image I got from parazyd (hope not confusing the person who gave it to me). |
| 23:35.45 | *** join/#maemo mavhc (~mavhc@cpc77319-basf12-2-0-cust433.12-3.cable.virginm.net) |
| 23:42.18 | Wizzup | Enrico_Menotti: ok, if it's to learn then go for it |
| 23:42.20 | Wizzup | :) |
| 23:42.31 | Wizzup | yeah parazyd builds those images |