| 00:27.39 | *** join/#maemo enyc (~enyc@muddle.enyc.org.uk) |
| 00:36.31 | drathir | freemangordon: ++ < freemangordon> progress on fremantle porting to devuan |
| 00:59.54 | *** join/#maemo ced117 (~ced117@AStrasbourg-552-1-17-59.w90-13.abo.wanadoo.fr) |
| 00:59.55 | *** join/#maemo ced117 (~ced117@opensuse/member/ced117) |
| 02:53.22 | *** join/#maemo hurrian (~textual@unaffiliated/rikanee) |
| 02:56.15 | *** join/#maemo buZz (~buzz@192.161.48.59) |
| 03:48.35 | *** join/#maemo Kilroo (~Kilroo@cpe-71-71-97-50.triad.res.rr.com) |
| 04:21.55 | *** join/#maemo Cor-Ai_ (~cor-ai@c-17d571d5.06-922-7570702.cust.bredbandsbolaget.se) |
| 04:21.57 | *** join/#maemo NIN101 (~core@jabber.quitesimple.org) |
| 04:21.57 | *** join/#maemo herekun (~herekun@164.132.132.199) |
| 04:21.57 | *** join/#maemo wnd (~wnd@katei.fi) |
| 04:23.58 | *** join/#maemo trx (ns-team@cable-188-2-25-100.dynamic.sbb.rs) |
| 04:23.58 | *** join/#maemo trx (ns-team@devbin/founder/trx) |
| 04:24.16 | *** join/#maemo pagurus (~user@i59F7C747.versanet.de) |
| 04:25.09 | *** join/#maemo Natch (~Natch@h-155-122.A444.priv.bahnhof.se) |
| 04:26.33 | *** join/#maemo ced117 (~ced117@AStrasbourg-552-1-17-59.w90-13.abo.wanadoo.fr) |
| 04:26.34 | *** join/#maemo ced117 (~ced117@opensuse/member/ced117) |
| 04:33.01 | *** join/#maemo trx (ns-team@devbin/founder/trx) |
| 04:41.32 | *** join/#maemo trx (ns-team@cable-188-2-25-100.dynamic.sbb.rs) |
| 04:41.33 | *** join/#maemo trx (ns-team@devbin/founder/trx) |
| 05:25.30 | *** join/#maemo jkepler (~Thunderbi@gateway/vpn/privateinternetaccess/jkepler) |
| 05:32.36 | *** join/#maemo geaaru_ (~geaaru@host179-50-dynamic.45-213-r.retail.telecomitalia.it) |
| 05:59.52 | *** join/#maemo xy2_ (~xy2_@94.239.177.175) |
| 06:18.10 | *** join/#maemo xorly (~xorly@ip-86-49-24-93.net.upcbroadband.cz) |
| 06:35.43 | *** join/#maemo Pali (~pali@Maemo/community/contributor/Pali) |
| 07:06.42 | *** join/#maemo brolin_empey (~brolin@brolin.be) |
| 07:19.21 | *** join/#maemo jkepler (~Thunderbi@gateway/vpn/privateinternetaccess/jkepler) |
| 07:21.41 | sixwheeledbeast | Would it matter to devuan if maemo was upstart for init? I know Canonical are unlikely to put any more work into it but it is open source and well documented. Having Upstart and OpenRC working on Devuan would be a good thing? |
| 07:22.00 | *** join/#maemo florian (~fuchs@Maemo/community/contributor/florian) |
| 07:40.51 | bencoh | I doubt devuan would prevent you from using any of those init systems |
| 07:41.03 | bencoh | but I don't really see any benefit for maemo on devuan |
| 07:41.20 | bencoh | 53 |
| 07:41.58 | parazyd | bencoh: benefit over what? |
| 07:42.44 | bencoh | parazyd: of choosing any specific init systems over the default one in devuan |
| 07:42.54 | bencoh | -s |
| 09:03.01 | Wizzup | sixwheeledbeast: not sure why you'd not just migrate to a maintained and decent init system |
| 09:12.31 | sixwheeledbeast | It depends how you define "decent", upstart is quite mature and I have never had any issues with it. It's also integrated into a lot of maemos existing packages. |
| 09:13.51 | sixwheeledbeast | I fully agree regarding maintained, but unless there's a bug/vulnerability what needs changing? |
| 09:30.16 | Wizzup | it's a dead project |
| 09:30.57 | Wizzup | I have no interest in taking maintenance of dead init systems |
| 09:31.09 | Wizzup | s/taking/taking up/ |
| 09:31.45 | Wizzup | I don't see why we'd want *more* work (maintaining two init systems) when we already need more people doing the work that's really needed |
| 09:32.12 | Wizzup | from experience devuan also doesn't move fast at all, and I don't want to rely on them maintaining an init system for us, and if they are going to move from sysvinit, they will move to openrc, and not to upstart. |
| 09:36.46 | DocScrutinizer05 | if you want to re-invent the complete maemo init system (have fun¡) then sure, move away from maemo init (which basically is upstart) to whatever else you like. I just wonder why the heck you call it maemo devuan and not hildon devuan or even osso devuan then |
| 09:37.08 | Wizzup | not this again. |
| 09:38.08 | Wizzup | there is no reinventing an init system, there's only applying hygiene and porting scripts. |
| 09:39.02 | DocScrutinizer05 | yeah sure |
| 09:39.13 | Wizzup | do you believe that maemo is defined by the fact that it uses upstart? |
| 09:39.26 | DocScrutinizer05 | as I saud, have fun porting a bazillion scripts in maemo-extras |
| 09:39.56 | DocScrutinizer05 | I believe that maemo is defined by the synergy of 3 dozen details |
| 09:40.10 | DocScrutinizer05 | and yes, init system is part of that |
| 09:40.27 | Wizzup | so you essentially don't want to change anything that 'defines' it by your definition |
| 09:41.03 | Wizzup | I'm not interested in looking backwards, I want to look forward. Not sticking to ancient and dead projects is part of that (hal anyone?) |
| 09:41.23 | Wizzup | and if there are things in whatever repo that depend on hal, they will need to be fixed |
| 09:41.28 | Wizzup | that's part of maintaining an ecosystem |
| 09:41.48 | Wizzup | it's not different for an init system, although it might be more work/invasive |
| 09:41.50 | DocScrutinizer05 | then go the heck and develop devuan, why abuse the name maemo? |
| 09:42.10 | Wizzup | sure enough, let's see what a better name would be. |
| 09:42.20 | Wizzup | if that saves us from future abuse |
| 09:42.27 | KotCzarny | demeaman? |
| 09:42.40 | KotCzarny | maevuan? |
| 09:43.03 | KotCzarny | devaemo |
| 09:43.03 | Wizzup | right now there's maedevu, that might work |
| 09:43.16 | Wizzup | but we can always change it later, not too interested in naming atm |
| 09:43.46 | KotCzarny | pronounced meh-deh-voo ? |
| 09:44.12 | Wizzup | I'm kind of leaning towards daemo |
| 09:49.29 | DocScrutinizer05 | it probably would have been less invasive to maemo when it had adopted systemd and stayed with debian, than what now is planned for it while trying to steer clear of debian's systemd change. When you change init system anyway, no more need to avoid systemd, and you can nuke OHMd and HAL en passant. Sure that thing might boot, but is it maemo still, can you make phonecalls with it *reliably*? |
| 09:51.31 | Wizzup | no, clearly systemd is required to make phonecalls reliably. |
| 09:51.34 | Wizzup | sighs |
| 09:52.09 | KotCzarny | mmm, wouldnt it be beautiful to integrate all maemo daemons into systemd? |
| 09:52.24 | KotCzarny | onebinary ramdisk and voila! |
| 09:53.10 | DocScrutinizer05 | Wizzup: you're telling BS. systemd is unrelated to phonecalls |
| 09:53.34 | DocScrutinizer05 | cgroups however are very important for maemo |
| 09:53.52 | Wizzup | I was ridiculing your senseless arguments |
| 09:54.06 | DocScrutinizer05 | yeah, in an anept way |
| 09:54.31 | DocScrutinizer05 | since I never sdayd anything that faunly warants this BS statement about systemd for cals |
| 09:54.48 | KotCzarny | 'said' |
| 09:55.27 | Wizzup | you were suggesting that we should instead move to debian and systemd (which is acceptable for me too, as long as we swap out upstart), and then you said that somehow the result would not be able to make phonecalls |
| 09:55.39 | Wizzup | and if you're not going to do any work, and just flame and throw shit around, I'm going to ignore your opinion |
| 09:55.49 | *** join/#maemo err0r3o3_ (~err0r3o3@91-115-109-193.adsl.highway.telekom.at) |
| 09:56.54 | DocScrutinizer05 | no, I never suggested that. maybe you need some coffee to wake up |
| 09:57.21 | DocScrutinizer05 | you're ignoring my opinion anyway, you always did |
| 09:57.43 | DocScrutinizer05 | you're even ignoring the meaning of my statements |
| 09:57.53 | DocScrutinizer05 | and instead quote me incorrectly |
| 09:59.41 | DocScrutinizer05 | and your statements make me ignore your option since you evidently have less clue about the implicit requirements regarding phonecalls than Enrico_Menotti |
| 09:59.50 | DocScrutinizer05 | opinion* |
| 10:12.21 | sixwheeledbeast | I understand it's deemed dead but isn't the point of devuan "init freedom". If Maemo as it stands requires upstart then why is that a problem? |
| 10:13.17 | Wizzup | if you make it work with all of devuans packages and do all the work to port it, then there is no problem |
| 10:13.39 | Wizzup | and if you would, you'd realise that you're working against the flow, against the path of least effort |
| 10:14.39 | Wizzup | and you'd have to maintain it over time with ever increasing maintenance since you're likely the only person in the world that wants to stick to upstart |
| 10:14.45 | Wizzup | just because of some legacy init scripts |
| 10:15.11 | Wizzup | I don't dislike upstart, it just doesn't make sense to stick with it just because. If it's little effort to make it work on devuan, fine, I don't care, but it doesn't look that way |
| 10:15.44 | Wizzup | there is no technical reason to require a specific init system: both openrc and systemd are modern alternatives, with different philosophies, but completely comparable feature sets |
| 10:27.10 | *** join/#maemo HRH_H_Crab (~crab@kowloontong.dim-sum.org) |
| 10:28.43 | sixwheeledbeast | I would have thought getting upstart working on Devuan would be easier than making OpenRC work with Maemo, but I am no expert. |
| 10:30.42 | Wizzup | The problem is having it continue to work over months/years/releases |
| 10:31.02 | Wizzup | Thinking only about the short-term solution is short sighted and will come back to bite |
| 10:39.22 | sixwheeledbeast | I suppose I am trying to look at it from both sides, as Doc says, it's what we deem to be "Maemo" that maybe the question. Hildon-Desktop with bits missing and maemo packages that are no longer compatible, isn't the whole Maemo experience for some. I fully understand your future support point BTW. |
| 10:39.39 | *** join/#maemo eMHa (~mh@HSI-KBW-109-192-005-246.hsi6.kabel-badenwuerttemberg.de) |
| 10:41.59 | Wizzup | I have no illusions about the fact that you can't just expect every single maemo package to run without modifications, but that's just how the software world works. On the flip side, you get access to all the normal packages in debian. |
| 10:42.38 | Wizzup | Furthermore, the requirements for having all of that continue to work are also a terrible foresight: having to keep around ancient tls libraries with known vulnerabilities, etc. |
| 10:42.53 | Wizzup | Down that path lies insanity |
| 10:42.57 | Wizzup | I wish it was different, but it's not |
| 10:43.12 | sixwheeledbeast | Making something to work to a future goal should have better long term support over back patching but "Maemo" is a weird beast. |
| 10:43.15 | DocScrutinizer05 | the point of devuan *IS* init freedom, and there's no such concept in devuan like "we need to move from (e.g.) upstart to $whatever-init to allow devuan packages without maintenance effort. IF anything is standard init in devuan, then that's sysv-init so far, but allowing any other init system. OTOH maemo-extras has more than just a few packages that depend on maemo's particular init system |
| 10:43.18 | Wizzup | My expectation would be that people could port over packages with relative ease or ask others to do so |
| 10:43.37 | Wizzup | sixwheeledbeast: I don't care if it is called maemo or not, I want a nice GNU/Linux OS for my devices |
| 10:43.42 | DocScrutinizer05 | said poettering |
| 10:44.44 | KotCzarny | he probably didnt say 'nice', but 'mine' |
| 10:46.30 | Wizzup | Any comparison of this discussion and poetterings general attitude is silly & trolling |
| 10:47.47 | Wizzup | Even when you keep upstart and change devuan to work with it, the maemo-extras packages still won't work without additional changes |
| 10:48.37 | DocScrutinizer05 | any argumentation why maemo devuan should enforce a new init system, when devuan got invented to dodge exactly this forcing of systemd init system to everybody for exactly the rationale given for maemo new init now, doesn't make any sense |
| 10:48.55 | sixwheeledbeast | Maybe I don't understand the thread correctly but how would what init Maemo uses effect tls libraries? Obviously Maemo needs updating and upstream Devuan is the planned source. |
| 10:49.02 | Wizzup | *You* are free to pick a different system. *Nobody* is forcing you to do anything |
| 10:49.26 | Wizzup | Stop pissing on other people |
| 10:50.02 | KotCzarny | swb: i guess that comment was about having to keep some compatibility layer |
| 10:50.07 | Wizzup | sixwheeledbeast: it won't the tls libraries of course |
| 10:50.15 | Wizzup | it won't affect* |
| 10:50.47 | Wizzup | KotCzarny: that was about the near impossibility of such a compatibility layer within a sane os/distro |
| 10:50.53 | DocScrutinizer05 | you you don't need to change devuan to work with upstart, devuan is about init freedom. A statement like >>On the flip side, you get access to all the normal packages in debian.<< is total BS since debian is systemd now and that was the whole reason why devuan got invented, since you only get access to systemd-dependent packages on debian |
| 10:51.32 | Wizzup | DocScrutinizer05: devuan imports most packages directly from debian |
| 10:51.35 | Wizzup | in case you didn't know |
| 10:51.40 | Wizzup | so my statement is as true as it gets |
| 10:52.04 | DocScrutinizer05 | in case you didn't know, I understood how devuan works before I sugested maemo goes devuan |
| 10:52.13 | Wizzup | then why state such falsehoods? |
| 10:52.50 | Wizzup | most packages in debian have no dependency on systemd at all, and the ones that might, either devuan will have a replacement for or you're SOL |
| 10:53.05 | DocScrutinizer05 | you obviously not only lack understanding of the phonecall modifications in maemo system and how they impact more than just audio, you also lack to understand whar devuan is |
| 10:53.29 | Wizzup | rolls his eyes |
| 10:53.34 | Wizzup | I'll await your implement of all of this |
| 10:54.32 | DocScrutinizer05 | it's YOU not me who's about to invent and failing to implement a new OS falsely dubbed maemo devuan |
| 10:55.31 | Wizzup | it mostly seems like you slinging shit at everyone who doesn't do exactly as you wish |
| 10:55.39 | DocScrutinizer05 | I suggested maemo & devuan join forces back when, *because* devuan allows keeping particularly upstart and cgroups |
| 10:55.53 | Wizzup | openrc and systemd support cgroups just fine |
| 10:56.11 | DocScrutinizer05 | you're telling bullshit without end |
| 10:56.42 | DocScrutinizer05 | systemd evidently takes cgroups hostage |
| 10:56.56 | DocScrutinizer05 | and is NOT compatible with maemo |
| 10:57.30 | DocScrutinizer05 | and when you want systemd then why the heck you pester the poor devuan people with that? |
| 10:57.44 | Wizzup | >when you want systemd |
| 11:01.00 | DocScrutinizer05 | you say "we can use debian packages" (NO you CANNOT as soon as they have systemd dependencies), then you say "we need to move to a init system that's supported by devuan" (no you don't since there is no such particular init system in devuan, they run on sysv-init for now but allow any init system except systemd madness), while you claim maemo must move away from upstart because it's not supported anymore (NO, devuan supports it). I don't |
| 11:01.02 | DocScrutinizer05 | know where to stop calling you out, so I rather stop right here |
| 11:02.29 | Wizzup | 'there is no such a particular init system in devuan?' |
| 11:02.45 | DocScrutinizer05 | no, devuan is about init dreedom |
| 11:03.22 | DocScrutinizer05 | maemo upstart is perfectly fine inside devuan |
| 11:03.26 | Wizzup | OK, do it |
| 11:03.38 | DocScrutinizer05 | no, why should I? |
| 11:04.53 | DocScrutinizer05 | why are you trying to not only modify maemo towards a allegedly needed new init system that is nowhere supported, but even also trying to redefine what's devuan? |
| 11:05.13 | Wizzup | whatinit syste is nowhere supported? |
| 11:05.22 | Wizzup | and why are you saying I am trying to redefine what devuan means? |
| 11:05.41 | Wizzup | I know pretty well what it means, I've shared an office with them for a considerable amount of time, and I see many of the core people on a regular basis irl |
| 11:05.45 | DocScrutinizer05 | meh, you are trolling me, or you're dense |
| 11:06.00 | buZz | hands out liquorice |
| 11:06.15 | KotCzarny | never tried liquir rice |
| 11:06.21 | KotCzarny | *liquor |
| 11:07.55 | buZz | :P |
| 11:08.36 | buZz | liquorice is one of the most traditional of all dutch candies |
| 11:08.57 | buZz | its what you give to your kids when they are fighting on the backseat of the car |
| 11:09.00 | buZz | so they stfu |
| 11:09.24 | KotCzarny | i wonder what would happen if you gave them liquor rice |
| 11:09.39 | sixwheeledbeast | Taking this back to maemo-devuan and openrc init. Would there be a conflict with openrc's use of cgroups and maemo's use of cgroups? |
| 11:09.58 | sixwheeledbeast | KotCzarny: I imagine it does the same |
| 11:10.26 | sixwheeledbeast | You just end up with a messy car |
| 11:10.40 | DocScrutinizer05 | just read this one carefully >>I have no illusions about the fact that you can't just expect every single maemo package to run without modifications, but that's just how the software world works. On the flip side, you get access to all the normal packages in debian.<< thats TOTAL BS. maemo already had access to all debian packages, now is slowly losing it thanks to systemd dependencies in debian packages, that's why I suggested to ally |
| 11:10.41 | DocScrutinizer05 | with devuan which offers init freedom. There's zilch rationale in "maemo needs another init system to stay comüpatible with devuan" - it lacks elementary logic |
| 11:11.06 | Wizzup | DocScrutinizer05: if you find it to be total bullshit, go and do it, because your approach will take many human lives to get to a semi working system |
| 11:11.17 | Wizzup | if you're not going to do it, kindly piss off |
| 11:11.30 | *** mode/#maemo [+o DocScrutinizer05] by ChanServ |
| 11:11.33 | Wizzup | I'm not going to bend to your will, especially if you're not going to put in any effort yourself |
| 11:11.34 | *** kick/#maemo [Wizzup!~saturn@openmoko/engineers/joerg] by DocScrutinizer05 (T900: "User terminated!") |
| 11:11.39 | *** mode/#maemo [-o DocScrutinizer05] by ChanServ |
| 11:12.24 | DocScrutinizer05 | somebody doing the wrong thing doesn't earn privileges to tell others to do the right ting or piss off |
| 11:13.22 | *** join/#maemo Wizzup (~Wizzup@a82-161-36-93.adsl.xs4all.nl) |
| 11:13.28 | Wizzup | How long do you want to keep everyone in here hostage? |
| 11:13.56 | Wizzup | That was completely uncalled for |
| 11:14.07 | DocScrutinizer05 | you're not denying to bend to anybody's will, you're denying mere logic and insist in BS statements that are evidently false and lack any logic |
| 11:14.15 | Wizzup | Unless you want to force people to move discussion about this topic to a channel where you don't exist |
| 11:14.30 | DocScrutinizer05 | yes, do that |
| 11:14.31 | Wizzup | no, you don't agree with my logic and I've long given up trying to talk to you |
| 11:14.34 | KotCzarny | wizzup, /ignore works wonders |
| 11:14.42 | Wizzup | KotCzarny: I want my refund for my neo900 first |
| 11:14.46 | Wizzup | then I will just that |
| 11:14.48 | Wizzup | I will do* |
| 11:14.58 | DocScrutinizer05 | it's YOU who is insulting people and telling them to piss off, so who's holding anybody histage here? |
| 11:15.07 | buZz | Wizzup: did you order a pyra yet? :D |
| 11:15.23 | Wizzup | I don't know man, calling people's arguments 'total BS' is kind of offensive |
| 11:15.32 | Wizzup | buZz: I will use the refund to do that |
| 11:15.38 | buZz | \o w00p |
| 11:15.56 | buZz | isnt neo900 refund like 5 pyras? :P |
| 11:16.12 | DocScrutinizer05 | answering a logical "A is true, B is false" statement with "do it or piss off" earny you a kick. sorry, this won't change |
| 11:17.12 | Wizzup | DocScrutinizer05: did you see my question about the refund in the neo900 channel? |
| 11:18.00 | DocScrutinizer05 | did you see my moaning about some irc users in #freenode? |
| 11:18.59 | DocScrutinizer05 | when you're upset about somebody calling you out for evidently nonsensical incorrect statements, you should step back and rethink instead of starting a war |
| 11:19.03 | buZz | did anyone watch american dad s14e21 yet? |
| 11:19.14 | parazyd | buZz: me :) |
| 11:19.14 | Wizzup | I don't need to rethink anything. I just don't want to have to deal with you |
| 11:19.15 | KotCzarny | i'm hungry |
| 11:19.25 | buZz | parazyd: nice, right? :D |
| 11:19.26 | Wizzup | This is not the first time, and I want this to be the last time. |
| 11:19.32 | parazyd | buZz: indeed :D |
| 11:19.35 | buZz | i mean, -any- topic better than this ^_^ |
| 11:19.57 | buZz | KotCzarny: hi hungry, i am buZz |
| 11:20.14 | KotCzarny | hi buzz, what are you buzzing about? |
| 11:20.27 | KotCzarny | maybe i will finally check that n900 |
| 11:20.27 | buZz | :) |
| 11:20.33 | buZz | i am F5-ing some order pages |
| 11:20.36 | KotCzarny | or not. left it at other place, eh |
| 11:20.46 | buZz | getting a GTX1060 today , and some parts for 3D printer |
| 11:21.19 | KotCzarny | the part that keeps me from doing it i would have to replace screens to make it boot/be usable |
| 11:21.56 | KotCzarny | unless someone has a workaround to enable tvout without working lcd |
| 11:22.11 | KotCzarny | (my guess fb is uninitialized and fails to setup tvout) |
| 11:22.17 | buZz | hmm |
| 11:22.30 | buZz | maybe if you can ssh into it? |
| 11:22.45 | KotCzarny | to ssh one would have to enable usb net or wifi |
| 11:22.54 | Wizzup | add a serial line? |
| 11:23.01 | KotCzarny | serial line isnt trivial |
| 11:23.14 | Wizzup | *shrug* |
| 11:23.23 | Wizzup | if it's trivial, it's not fun |
| 11:23.32 | KotCzarny | i wonder if it's just a setting somewhere in xomap or kernel |
| 11:24.26 | KotCzarny | wouldnt it be great if you boot, it detects missing lcd but setups things anyway to make tvout work? |
| 11:25.20 | KotCzarny | (that was my original plan with that n900) |
| 11:25.55 | DocScrutinizer05 | should work, except afaik for NOLO |
| 11:26.14 | KotCzarny | nope. bad/missing lcd results in flatline on tvout |
| 11:26.15 | buZz | Nobody Only Lives Once |
| 11:26.26 | DocScrutinizer05 | seems NOLO vlows chunks when LCD controller chip init fails |
| 11:26.37 | parazyd | buZz: lol |
| 11:26.39 | KotCzarny | it boots fully, but no tvout |
| 11:27.00 | KotCzarny | i only see the 1px yellow line in the middle (probably some message pops up) |
| 11:27.16 | KotCzarny | (most likely about missing modem functions) |
| 11:27.32 | DocScrutinizer05 | ooh, that's great news, so NOLO only fails when the I2C link to flat cable is partially broken so it ruins complete I2C bus? |
| 11:27.34 | KotCzarny | swapping lcds makes tvout work as expected |
| 11:28.17 | KotCzarny | trivial to check, just disconnect ribbon and connect to tv set (set wifi to auto connect before though for checks) |
| 11:29.02 | DocScrutinizer05 | hmm, or not. Seems video init also in SoC and thus for TVout too, is failing when SoC cannot talk to LCD |
| 11:30.06 | DocScrutinizer05 | anyway I'd suggest to NOT load the kernel driver for LCD controller, that might help |
| 11:31.09 | KotCzarny | my guess is that lcd init populates height/width structures which are not hardcoded. but it's just a guess |
| 11:32.08 | KotCzarny | might be also that failing lcd init stops tv init from happening |
| 11:37.58 | DocScrutinizer05 | KotCzarny: >>lcd init populates height/width structures<< yes, exactly my guess too |
| 11:38.44 | KotCzarny | hmm, i wonder if that means it would be possible to drive higher res lcd with n900 |
| 11:38.56 | DocScrutinizer05 | judging from my involuntary experiments with broken I2C(?) connection to LCD controller a 6(?) years ago |
| 11:39.19 | DocScrutinizer05 | yes, should be possible |
| 11:39.35 | KotCzarny | were there any reports of such experiments? |
| 11:40.00 | DocScrutinizer05 | check OMAP3430 TRM section "video" or whatever |
| 11:40.37 | DocScrutinizer05 | OMAP3430 has a range of resolutions it supports |
| 11:40.52 | DocScrutinizer05 | and a generic display hardware interface |
| 11:42.30 | KotCzarny | pdf says 'any size up to 2048x2048 with 8px granularity' |
| 11:43.01 | KotCzarny | in section 15 |
| 11:44.05 | KotCzarny | but mipi dsi says 'xga @60fps with 24depth' |
| 11:45.56 | DocScrutinizer05 | yep, OMAP34xx_ES3.1.x_PUBLIC_TRM_vZM___SWPU223M.pdf section 15 "display subsystem" |
| 11:48.02 | DocScrutinizer05 | http://susepaste.org/64625507 |
| 11:48.27 | KotCzarny | yes, but see mipi section too |
| 11:49.21 | DocScrutinizer05 | basically boils down to >> Programmable pixel rate up to 75 MHz<< |
| 11:49.34 | DocScrutinizer05 | MIPI is just an industry standard |
| 11:50.02 | KotCzarny | isnt that the actual connector/standard used? |
| 11:50.45 | KotCzarny | unless all of those standards on the same connector |
| 11:50.53 | DocScrutinizer05 | the one *used* in N900 maybe, but not the only supported one |
| 11:51.05 | DocScrutinizer05 | yes, the latter |
| 11:51.47 | DocScrutinizer05 | well, there's pinmux, depends what is allowed/suppported on which of the available pins/balls |
| 11:53.07 | DocScrutinizer05 | but generally the supported protocols are not dependent on the hw interface used, unless you simply don't have access to the requird pins for a standard that uses more pins/lines than the one N900 does |
| 12:11.24 | DocScrutinizer05 | KotCzarny: mipi SDI or mipi DBI |
| 12:11.57 | DocScrutinizer05 | ugh DSI too |
| 12:24.36 | sicelo | anyone has an idea of the serial protocol uses in popular cheap smartwatch DZ09 and clones? |
| 12:27.23 | *** join/#maemo Konsieur (~kabouik@2a01:e35:2fd3:5030:e142:c406:c878:1d89) |
| 12:30.51 | DocScrutinizer05 | sicelo: doesn't https://www.ixquick.com/do/search?q=serial+protocol++DZ09 help? |
| 12:34.07 | DocScrutinizer05 | always a good goto: bunnie https://www.bunniestudios.com/blog/?p=4297 |
| 12:34.13 | buZz | bunnie <3 |
| 12:40.23 | sicelo | thanks. |
| 12:40.29 | sicelo | lookinkg |
| 12:40.39 | sicelo | in the meantime have been downloading the f/w |
| 12:46.49 | *** join/#maemo EgS (~egs@quassel/developer/egs) |
| 12:56.17 | *** join/#maemo xorly (~xorly@193.85.203.185) |
| 13:00.57 | *** join/#maemo jkepler (~Thunderbi@gateway/vpn/privateinternetaccess/jkepler) |
| 13:13.29 | *** join/#maemo jkepler (~Thunderbi@gateway/vpn/privateinternetaccess/jkepler) |
| 13:31.30 | *** join/#maemo auenf (David@120.154.78.136) |
| 14:01.04 | drathir | thats good... http://www.bunniefoo.com/fernvale/fernvale-31c3.pdf |
| 14:03.53 | *** join/#maemo jkepler (~Thunderbi@gateway/vpn/privateinternetaccess/jkepler) |
| 14:15.50 | sicelo | the resources above are all great. however they are for firmware hacking, and don't seem to cover bluetooth serial comms, which i'm after |
| 14:16.18 | sicelo | i notice i didn't mention bluetooth in my earlier question |
| 14:18.15 | drathir | not tech guy but isnt if mb source present and os source too that somehow predict/extract how os interact with bt module? |
| 14:18.43 | drathir | sicelo: or that even lower inside bt fw module? |
| 14:20.13 | sicelo | no idea. i'm no better than you are .. i bet i know way less |
| 14:22.42 | sicelo | establishing a bluetooth link using rfcomm is very easy .. my problem is in knowing what to send |
| 14:27.38 | DocScrutinizer05 | bt simplifies things a tad, since at least you have a profile that predicts which protocol being used to send/receive |
| 14:27.56 | drathir | sicelo: im not sure that im know more than You... and theoretically speaking maybe also good idea search devices based on that chipset and maybe that devices will have some kind of documentayion/usage of module ? |
| 14:36.02 | timeless | DocScrutinizer05: have you ever had `zless foo.gz` not `work`? |
| 14:36.15 | timeless | for me, i get a warning that this may be a binary file |
| 14:36.26 | timeless | and then less lets me look at the uncompressed file :-( |
| 14:36.33 | DocScrutinizer05 | hmm, never really used zless |
| 14:36.59 | timeless | oh! |
| 14:37.00 | timeless | sighs |
| 14:37.04 | timeless | SHELL=/bin/false |
| 14:37.05 | DocScrutinizer05 | weird. cehck ending, maybe needs .tgz or .tar.gz |
| 14:37.07 | timeless | that's awesome |
| 14:37.14 | DocScrutinizer05 | LOL |
| 14:37.32 | timeless | so, zless honors shell |
| 14:37.42 | DocScrutinizer05 | if in doubt, try mc ;-) |
| 14:37.46 | timeless | and since i'm running as a service account, where shell=/bin/false, doesn't work |
| 14:38.02 | timeless | wonders if this is really the right behavior |
| 14:38.51 | DocScrutinizer05 | I *guess* zless is just a tiny bash wrapper around tar/zip and less, doing uncompressing and piping to $PAGER |
| 14:39.13 | timeless | zless is a binary that does some wrappings |
| 14:39.17 | timeless | but yes, kinda |
| 14:39.29 | timeless | it mostly sets LESSOPEN / LESSPIPE and friends |
| 14:39.34 | timeless | except, apparently it honors SHELL |
| 14:39.44 | timeless | is still trying to decide why anyone would think that's the right behavior |
| 14:40.51 | DocScrutinizer05 | wonders how logging in interactively to an account with SHELL=/bin/false is the right behavior anyway |
| 14:41.09 | timeless | sudo -u tomcat /bin/bash |
| 14:41.14 | timeless | HOME=`eval echo ~$USER` |
| 14:41.21 | timeless | clearly needs to add SHELL=/bin/bash |
| 14:41.47 | timeless | i'm trying to avoid having lots of scripts that run as root |
| 14:41.49 | bencoh | less honors SHELL, not zless |
| 14:41.59 | timeless | bencoh: ah |
| 14:42.35 | timeless | can you walk me through why it should do that? is the expectation that someone would want SHELL=psh and LESSPIPE={perl} ? |
| 14:42.39 | DocScrutinizer05 | I just 2 days ago googled for shel = /bin/false resp /bin/nologin and it's a pretty weird topic |
| 14:42.50 | timeless | oh, yeah |
| 14:43.03 | DocScrutinizer05 | it *should* forbid any interactive login |
| 14:43.07 | timeless | more or less one is "use this for services" and the other is "use this for accounts that have been disabled" |
| 14:43.33 | timeless | well, the way computers work, a permission has to exist, so this account has permissions |
| 14:43.42 | timeless | and you can create a permission, and then ask it to run a program |
| 14:43.45 | timeless | e.g. tomcat (i.e. java) |
| 14:43.56 | timeless | or you can asks it to run some other program (e.g. bash) |
| 14:43.58 | DocScrutinizer05 | well, technically there's little difference between false and nologin, just the latter prints a polite message about the fact |
| 14:44.04 | timeless | yep |
| 14:44.13 | timeless | hence nologin is really "how to tell a user to go away" |
| 14:44.24 | timeless | and false is what you use for a service account -- something a user shouldn't be trying to log into |
| 14:44.30 | DocScrutinizer05 | it's for hysterical raisins |
| 14:44.40 | timeless | my favorite part of that dance is that the location of those files has changed over time |
| 14:44.45 | timeless | yep |
| 14:45.00 | timeless | false was part of the base system, so people cheated and used it for locking accounts/services |
| 14:45.06 | timeless | but eventually they wanted to be fancier |
| 14:45.29 | DocScrutinizer05 | sort of, yes |
| 14:45.49 | DocScrutinizer05 | aiui there's no best common practice |
| 14:47.18 | DocScrutinizer05 | anyway when you *log in* to any account, you inherit that account's shell settings, and obviously less is meant to run inside a shell, so... |
| 14:48.35 | DocScrutinizer05 | then there's also fun with PAM |
| 14:49.06 | drathir | timeless: env what say after login? |
| 14:55.54 | DocScrutinizer05 | actually /bin/flase is a tad weird for login. I *think* you should set the password invalid but have the primary and sole function of an account as "shell" in etc/passwd, e.g. /usr/bin/tomcat for account tomcat |
| 14:56.11 | DocScrutinizer05 | but then that's just what came to my mind right now |
| 14:57.22 | timeless | drathir: this isn't a `login` proper, it's a `sudo` |
| 14:57.54 | timeless | DocScrutinizer05: partially, `sshd` can easily ignore an empty password |
| 14:58.05 | timeless | which is why the screwy system is the way it is... |
| 14:58.28 | DocScrutinizer05 | you shouldn't have sshd in an account that's not meant to have ssh login |
| 14:58.57 | timeless | sshd doesn't really live inside an account :) |
| 14:59.08 | timeless | but if you mean ~/.ssh/authorized_keys -- well... |
| 14:59.10 | DocScrutinizer05 | well, depends on your system config |
| 14:59.26 | timeless | sshd is almost always owned by root :) |
| 14:59.39 | timeless | sure, it's /possible/ to run sshd as another user (i do it occasionally to debug things), but... |
| 14:59.46 | *** join/#maemo sunshavi (~user@190.234.106.70) |
| 14:59.53 | DocScrutinizer05 | basically sshd is a glorified login + su |
| 15:00.55 | DocScrutinizer05 | it *should* get configured in a way so it behaves pretty much identical or evem *less* permissive than normal login |
| 15:02.11 | DocScrutinizer05 | ssh ignoring password in /etc/shadow and etc/passwd and still allowing to log in to an account that hos NO .ssh/authorized_keys is... BAD[TM] |
| 15:03.45 | DocScrutinizer05 | you *can* do this, allowing ssh to log in to arbitrary accounts using arbitrary unrelated ssh keys, by setting up mess in /etc/sshd7* but... |
| 15:05.15 | DocScrutinizer05 | well, at least I guess you could, I never tried this and I think defualt is not allowing it |
| 15:06.04 | DocScrutinizer05 | glares at git |
| 15:07.33 | bencoh | or just use a different pam configuration? ... |
| 15:07.56 | DocScrutinizer05 | still sort of a miracle to me how git daemon / sshd knows which authorized_key to use and which user to authenticate to git, while you're not providing an explicit user name and neither your local account you do "git push ssh:/foo.bar" has a valid known git account name |
| 15:07.57 | timeless | yeah, pam / ldap |
| 15:08.17 | timeless | DocScrutinizer05: usually you're configured to login as the `git` user |
| 15:08.25 | timeless | (or in hg the `hg` user) |
| 15:08.47 | DocScrutinizer05 | well, nevertheless git is greeting you with your name when you simply ssh git@foo.bar |
| 15:08.50 | timeless | but the way those usually work is that there's essentially only one `user` and each authorized_key line has a `command` |
| 15:09.07 | timeless | yeah, so, that's all through the magic of `command=...` |
| 15:09.14 | DocScrutinizer05 | yep |
| 15:09.15 | timeless | has a whole bunch of `command=` things |
| 15:09.34 | timeless | basically that can set the "user" for the program |
| 15:09.45 | timeless | so it can greet you / know to do things as "you" |
| 15:10.34 | timeless | i suspect that the ssh system for larger systems is a little modified from the standard to avoid having a single "authorized_keys" file, since updating that would be scary beyond belief |
| 15:10.58 | timeless | https://serverfault.com/questions/162238/openssh-with-public-keys-from-database |
| 15:11.02 | timeless | AuthorizedKeysCommand |
| 15:11.05 | timeless | AuthorizedKeysCommandRunAs |
| 15:11.32 | timeless | those look promising :) |
| 15:11.48 | DocScrutinizer05 | *cough* |
| 15:11.56 | DocScrutinizer05 | but yeah, prolly that's it |
| 15:12.31 | timeless | https://github.com/blog/530-how-we-made-github-fast |
| 15:12.35 | timeless | apparently not :o |
| 15:18.47 | DocScrutinizer05 | github my ass |
| 15:19.47 | *** join/#maemo jkepler (~Thunderbi@gateway/vpn/privateinternetaccess/jkepler) |
| 15:25.47 | *** join/#maemo Pali (~pali@Maemo/community/contributor/Pali) |
| 15:29.41 | DocScrutinizer05 | timeless: but think about it: how does sshd know *which* key in authorized_keys is the right one to use for the inbound ssh connection request? |
| 15:30.28 | DocScrutinizer05 | theere must be sth magic going on behind the scenes, in ssh protocol |
| 15:30.55 | bencoh | it doesn't need to know |
| 15:30.59 | bencoh | and there is no magic |
| 15:31.33 | bencoh | ssh (client) uses the specified (or default) key |
| 15:31.36 | bencoh | and ... that's it |
| 15:31.42 | DocScrutinizer05 | err it doesn't need to know which of a 100 pubkeys to use to verify the authentication request? |
| 15:31.48 | bencoh | no |
| 15:32.08 | bencoh | it only needs to check that submitted pubkey is indeed present |
| 15:32.18 | DocScrutinizer05 | that sounds like a communication problem between you and me |
| 15:32.29 | bencoh | DocScrutinizer05: then I repeat, 18:31 < bencoh> ssh (client) uses the specified (or default) key |
| 15:32.44 | bencoh | the fact that you think it doesn't is the issue :) |
| 15:32.51 | DocScrutinizer05 | huh? |
| 15:33.16 | bencoh | client decides whether to use and supply a pubkey |
| 15:33.19 | DocScrutinizer05 | please explain me what I think, I fail to understand what I'm supposed to be thinking |
| 15:33.28 | bencoh | 18:29 < DocScrutinizer05> timeless: but think about it: how does sshd know *which* key in authorized_keys is the right one to use for the inbound ssh connection request? |
| 15:33.36 | bencoh | I'm only referring to this |
| 15:33.41 | bencoh | and this very question is wrong |
| 15:33.49 | DocScrutinizer05 | and what did I say I'm thinking there? |
| 15:34.04 | bencoh | that sshd should somehow know which key to use |
| 15:34.39 | bencoh | which doesn't really makes sense in my opinion |
| 15:34.58 | DocScrutinizer05 | when sshd doesn't know which of the 100 pubkeys in authorized_keys to use, I totally fail to understand how authentication would be feasible |
| 15:35.16 | bencoh | sshd doesn't get to choose |
| 15:35.28 | bencoh | client supplies a pubkey |
| 15:35.28 | DocScrutinizer05 | since sshd MUST use a particular key in azthoirzed_keys, that's why they exist |
| 15:35.35 | bencoh | sshd checks whether it matches any in the list |
| 15:35.42 | bencoh | no, it doesn't |
| 15:35.46 | DocScrutinizer05 | so there you have it |
| 15:36.01 | DocScrutinizer05 | it gets told which key to use |
| 15:36.06 | bencoh | by client, yes |
| 15:36.11 | bencoh | 18:31 < bencoh> ssh (client) uses the specified (or default) key |
| 15:36.12 | bencoh | :) |
| 15:36.31 | DocScrutinizer05 | >>ssh (client) uses the specified (or default) key<< is very fuzzy |
| 15:36.37 | bencoh | mybad then :) |
| 15:37.21 | DocScrutinizer05 | also my question wasn't about client but about server |
| 15:37.54 | DocScrutinizer05 | I know which private key the client uses |
| 15:38.31 | DocScrutinizer05 | but obviously it needs to tell server about which pubkey to use |
| 15:38.37 | bencoh | that's true, yes |
| 15:38.43 | bencoh | s/true/exact/ |
| 15:40.44 | DocScrutinizer05 | so now we're talking. How is the pubkey to use getting identified / referred to, in the communication from client to server? |
| 15:41.27 | bencoh | "identified"? |
| 15:41.34 | DocScrutinizer05 | I guess not by transferring it a second time, since the client has no access or knowledge about the pubkey |
| 15:41.35 | bencoh | it's simply sent from client to server |
| 15:41.47 | bencoh | err, it does |
| 15:41.56 | bencoh | client has both pubkey and privkey |
| 15:42.05 | bencoh | it has* |
| 15:42.22 | DocScrutinizer05 | only id privkey includes a pubkey version |
| 15:42.26 | DocScrutinizer05 | if* |
| 15:42.47 | bencoh | $ ls .ssh/id_rsa* |
| 15:42.47 | bencoh | .ssh/id_rsa .ssh/id_rsa.pub |
| 15:42.52 | DocScrutinizer05 | I'm only pointing to privjey in my ssh client command |
| 15:43.16 | DocScrutinizer05 | no? |
| 15:43.28 | bencoh | pointing to a key usually refers to a pair |
| 15:43.59 | DocScrutinizer05 | I even think you could set up a client by only providing the privkey file, the system never get to see the pubkey. |
| 15:45.14 | timeless | Public keys can be (re)generated from private keys |
| 15:45.18 | DocScrutinizer05 | I've created key pairs for users, sent the privkey to user and the pubkey to server, neither knew of the other part |
| 15:45.59 | timeless | https://askubuntu.com/questions/53553/how-do-i-retrieve-the-public-key-from-a-ssh-private-key |
| 15:46.05 | DocScrutinizer05 | timeless: then that's the solution, pretty much in line with my >>only if privkey includes a pubkey version<< |
| 15:47.05 | timeless | https://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-and-connection-process |
| 15:47.08 | DocScrutinizer05 | so the sshd would only compare if the provided pubkey is already in authorized_keys ? |
| 15:47.13 | bencoh | exactly |
| 15:47.25 | DocScrutinizer05 | :-) |
| 15:47.54 | DocScrutinizer05 | sounds suboptimal but meh |
| 15:48.06 | timeless | from above page https://www.irccloud.com/pastebin/3AYIJGSU |
| 15:48.23 | DocScrutinizer05 | I had thought the protocol would want to keep the pubkey also sort of non-public |
| 15:48.46 | timeless | Nope, the public key is actively sent from client to server |
| 15:49.06 | DocScrutinizer05 | so isn't there an attack vector for MITM? |
| 15:49.16 | timeless | If it isn't recognized, the server says "I don't know that one, try another" |
| 15:49.37 | timeless | SSH starts by clients connecting to servers |
| 15:49.41 | DocScrutinizer05 | MITM would say "hey great that's a known key" while storing it ;-) |
| 15:49.43 | timeless | Servers present their public keys |
| 15:50.05 | timeless | If the client has a public key for the server and it doesn't match, the client screams |
| 15:50.21 | timeless | The public key doesn't really do much |
| 15:50.25 | DocScrutinizer05 | we all seen that, yes :-D |
| 15:50.47 | timeless | I'm about to trigger that for one of our systems... |
| 15:50.48 | DocScrutinizer05 | ok,, learned sth for today |
| 15:51.15 | DocScrutinizer05 | thanks! |
| 15:51.28 | timeless | Anyway, the SSH model allows a client to offer key after key after key |
| 15:51.39 | timeless | Usually after a certain number, the server gets annoyed |
| 15:51.48 | DocScrutinizer05 | hehehehe |
| 15:52.41 | timeless | has triggered that... |
| 15:52.58 | DocScrutinizer05 | it's a tad weird an approach to not keep the actual pubkey out of the communication |
| 15:53.26 | DocScrutinizer05 | I had just send a hash over the pubkey |
| 15:53.40 | DocScrutinizer05 | if I were to design the protocol |
| 15:53.45 | *** join/#maemo xy2_ (~xy2_@94.239.253.5) |
| 15:54.13 | DocScrutinizer05 | if I *had* to... |
| 15:54.15 | bencoh | there's no real reason not to send the pubkey |
| 15:54.53 | DocScrutinizer05 | it significantly complicates MITM attacks |
| 15:55.07 | bencoh | well, actually there might be, but if you're referring to potential mitm, just think of the fact that client is already supposed to check server's fingerprint |
| 15:55.22 | bencoh | so you've already got that aspect covered |
| 15:55.25 | DocScrutinizer05 | yes, I know |
| 15:56.34 | DocScrutinizer05 | but honestly, how do *you* (the user) verify that the fingerprint of the server auth key is actually a valid one when you first time connect to a server? |
| 15:58.13 | DocScrutinizer05 | particularly when you're stupid like me and think the mere fact that the server has your pubkey is an indication that it's the server you sent your pubkey to via out-of-band means like encrypted email |
| 16:00.00 | DocScrutinizer05 | for me that's frequently a "plausibility check: do I conect to this server for the first time? or are there other possible reasons why my known_hists is not up to date? OK? then 'YES'..." |
| 16:00.19 | bencoh | DocScrutinizer05: you're supposed to know the fingerprint |
| 16:00.24 | bencoh | and ssh displays it |
| 16:00.52 | bencoh | I don't see any valid reason why server would have your pubkey while you wouldn't have his |
| 16:00.56 | DocScrutinizer05 | where from would I possibly know the fingerprint of the host's identify key? |
| 16:01.34 | bencoh | ssh-keyscan from a trusted computer on a trusted network, for instance |
| 16:02.05 | DocScrutinizer05 | honestly not a single of my known_hosts seen any verification, I wouldn't even know how to do that |
| 16:02.05 | bencoh | or by using sshfp and dnssec |
| 16:03.19 | DocScrutinizer05 | I never seen a howto for server identity key verification |
| 16:03.45 | DocScrutinizer05 | or I forgot if I actually did |
| 16:05.27 | DocScrutinizer05 | for all I know even my own servers could have different server id keys than I got in my known_hosts, and I'm always ever since talking to a MITM |
| 16:05.49 | bencoh | :) |
| 16:07.35 | DocScrutinizer05 | I'm not sure but I doubt e.g. Hetzner gave me a fingerprint to verify against, when they sent me my server credentials |
| 16:09.12 | DocScrutinizer05 | neither would I know of maemo fingerprints being published anywhere |
| 16:11.50 | DocScrutinizer05 | probably the canonical way to establish a connection to a server (first time) would be to add the key to known_hosts from OOB source, so ssh client never even would ask that notorious "ARE YOU SURE YOU WANT TO ADD THAT SERVER?" |
| 16:13.14 | DocScrutinizer05 | alas I don't know of any source for the key to add it to my known_hosts |
| 16:13.48 | DocScrutinizer05 | other than the just mentioned client based method |
| 16:16.03 | *** join/#maemo cyteen (~cyteen@29.31.7.51.dyn.plus.net) |
| 16:16.31 | DocScrutinizer05 | there must be a way to have servr side key fingerprint displayed to user out-of-band of mere ssh negotiation protocol, so you could compare server side fingerprint with local fingerprint |
| 16:16.55 | DocScrutinizer05 | ideally via email or other non-ssh based channel |
| 16:18.28 | DocScrutinizer05 | compare ZRTP where that "OOB" channel is voice that's hard to fake by a rogue software in a MITM |
| 16:19.20 | DocScrutinizer05 | ZRTP also doesn't share keys ever, making any MITM attack even harder |
| 16:20.54 | DocScrutinizer05 | iirc |
| 16:26.33 | DocScrutinizer05 | HMMMM http://man.openbsd.org/ssh-keyscan#SECURITY |
| 16:32.15 | bencoh | DocScrutinizer05: man ssh-keygen /fingerprint and see /etc/ssh* |
| 16:35.07 | DocScrutinizer05 | hmm, not sure what exactly you refer to |
| 16:35.34 | DocScrutinizer05 | to view fingerprints? |
| 16:36.12 | bencoh | yes |
| 16:37.06 | DocScrutinizer05 | ta |
| 16:44.00 | DocScrutinizer05 | hmm, ssh-copy-id needs severe augmentation, to cope with default no-passowrd as well as mitigating the above discussed MITM issue by specifying unique properties to look and verify for on target server to install your pubkey to |
| 16:46.43 | DocScrutinizer05 | so an admin could send a ssh-copy-id command that would guarantee to avoid MITM and also copes with allowing password auth only for installing the pubkey (based on server side measures, only from certain hostnames, IP ranges, only for a limited timespan and only for a very limited number of tries) |
| 16:47.25 | DocScrutinizer05 | s/ssh-copy-id command that /ssh-copy-id command to user per encrypted email that / |
| 16:48.44 | DocScrutinizer05 | that's basically reverse pubkey-is-secret aproach |
| 16:48.45 | *** join/#maemo jkepler (~Thunderbi@gateway/vpn/privateinternetaccess/jkepler) |
| 16:49.05 | bencoh | except that your pubkey is public |
| 16:49.11 | bencoh | not a psk |
| 16:49.38 | DocScrutinizer05 | well, I didn't say anything different |
| 16:50.35 | DocScrutinizer05 | it's just the fow of secret info is from admin to user instead of from user to admin (via providing the pubkey) |
| 16:51.27 | DocScrutinizer05 | the secret info are the parameters to ssh-copy-id-ng |
| 16:52.27 | DocScrutinizer05 | these could even include the fingerprint of server id key |
| 16:52.50 | DocScrutinizer05 | or already the key itself |
| 16:52.57 | DocScrutinizer05 | to add it to known hosts |
| 16:55.10 | DocScrutinizer05 | on server side, e.g inotify or a temporary login script could cope with disabling password authentication and restricting allowed commands to only installing the pubkey to authorized_keys |
| 16:56.03 | freemangordon | DocScrutinizer05: on a side not - maemo's upstart scripts are more or less NOT compatible with upstream upstart. Also, most, if not all of the packages in maemo have both upstart and sysvinit scripts. No idea why. |
| 16:56.11 | freemangordon | *note |
| 16:56.41 | DocScrutinizer05 | heck, you wouldn't even need password auth at all, just send user a temprary ssh privkey with the server pubkey only allowing command to install the final pubkey to server |
| 16:56.42 | freemangordon | not to say that the whole maemo boot process is a total mess |
| 16:57.15 | freemangordon | part of it is upstart, another part in /etc/Xsession.d scripts |
| 16:57.55 | freemangordon | without an easy to be seen sequence |
| 16:58.03 | freemangordon | if there is a sequence at all |
| 16:58.05 | DocScrutinizer05 | freemangordon: well, that's ok, we still don't need to nuke maemo-upstart for another init system just to stay compatible with devuan. Devuan is compatible to whatever init system you like, per foundation definition of devuan's purpose |
| 16:58.39 | freemangordon | maemo-upstart is already nuked in the project I am participating in |
| 16:59.46 | DocScrutinizer05 | yeah, maemo compatibility is nuked in many aspects in that project, armhf only being an elephant to start with |
| 17:01.01 | freemangordon | no, you got it wrong, maemo compatibility is not defined by the init system neither by the fact that ONE of the builds will be armhf |
| 17:01.20 | DocScrutinizer05 | but that's not mandated by devuan, nor ny any other compatibility considerations. It rather outright denies any backward compatibilty and claiming it had to be done to *stay compatible* is not based on any facts |
| 17:01.55 | freemangordon | it is not mandated by devuan, that's for sure. It is mandated by the fact that maemo is horribly outdated |
| 17:02.45 | DocScrutinizer05 | that's a totally different topic and up to anybody's personal belief if it's a sane thing to invent something totally new and still call it maemo |
| 17:02.45 | freemangordon | so, without having the RnD size of ex-Nokia's, the only sane way I see is to reuse as much upstream as possible |
| 17:03.28 | DocScrutinizer05 | my take on that is to reuse as much *maemo* as possible |
| 17:03.45 | freemangordon | sure |
| 17:03.52 | freemangordon | but init system is not part of it |
| 17:04.18 | DocScrutinizer05 | which directly results in "don't change the init system just because we can" considerations |
| 17:04.54 | freemangordon | the change is not because we can, but because we can;t reuse it without an effort that doesn worths it |
| 17:05.41 | freemangordon | I don;t see the point spending 2 or 3 months porting maemo-upstart to upstream libs |
| 17:06.01 | DocScrutinizer05 | you just said maemo supports maemopstart and sysvinit. Neither systemd is supported by either devuan or maemo, nor is another init system needed to make maemo work with devuan |
| 17:06.42 | freemangordon | in devuan, right now I can choose between upstart and sysvinit |
| 17:06.52 | DocScrutinizer05 | all devuan upstream supports sysvinit as well right now, and will do so for a long time still |
| 17:07.29 | freemangordon | sure, but maemo sysvinit scripts are not LSB compatible in their most |
| 17:07.46 | freemangordon | so they just don;t get started |
| 17:07.55 | freemangordon | the same goes for maemo upstart scripts |
| 17:08.37 | DocScrutinizer05 | sorry, I'm not feeling like discussing this any further, it doesn't seem tolead anywhere |
| 17:08.54 | freemangordon | and we can;t just put maemo-upstart there, because upstream services are not compatible with it |
| 17:09.10 | *** join/#maemo sparetire (~sparetire@unaffiliated/sparetire) |
| 17:09.26 | *** join/#maemo drcode (~drcode@5.29.192.15) |
| 17:09.47 | freemangordon | why not, you seem to know how it works? |
| 17:10.24 | sixwheeledbeast | Maybe a hang over from original sysv nokia tablets that there are both? |
| 17:10.28 | DocScrutinizer05 | all this leads to is bitching and flamewares very much similar to those seen from systemd people against devuan |
| 17:11.20 | DocScrutinizer05 | and I'm not interested in this sort of battle |
| 17:12.12 | freemangordon | sixwheeledbeast: can;t parse, sorry :) |
| 17:12.22 | DocScrutinizer05 | I won't convince anybody anyway, obviously. And I'm sick of taking insults when pointing at inconsistencies in other people's argumentation chains |
| 17:12.35 | sixwheeledbeast | You say there are duplicate sysv and upstart scripts? |
| 17:12.51 | freemangordon | DocScrutinizer05: hmm? I insulted you? |
| 17:12.51 | Enrico_Menotti | DocScrutinizer05 Seen a mention of my name at 12.59 CEST. What did you mean? |
| 17:12.58 | DocScrutinizer05 | freemangordon: not you |
| 17:13.03 | DocScrutinizer05 | :-) |
| 17:13.06 | freemangordon | sixwheeledbeast: yep, should be something like that |
| 17:13.24 | freemangordon | DocScrutinizer05: then please, don;t put me in a group I don;t belong, ok |
| 17:13.47 | DocScrutinizer05 | Enrico_Menotti: never mind, I just referred to yur learning about why it's so complicated to implement proper phonecalls in linux |
| 17:13.54 | freemangordon | even if we assume such a group exists |
| 17:14.04 | DocScrutinizer05 | freemangordon: sorry, wasn't my intention |
| 17:14.47 | DocScrutinizer05 | I didn't invent or refer to any groups either |
| 17:15.01 | Enrico_Menotti | DocScrutinizer05 Ok. |
| 17:15.48 | *** join/#maemo drcode (~drcode@5.29.192.15) |
| 17:16.51 | sixwheeledbeast | Is maemo-upstart hugely different from upstream, I wasn't aware, I suppose that is a valid point. |
| 17:17.07 | DocScrutinizer05 | freemangordon: I just said I have the feeling this discussion is pointless from my side and I'm sick of getting bashed for pointing at incorrect statements, not implying those were made by you |
| 17:26.34 | DocScrutinizer05 | sixwheeledbeast: depends, valid point for what. the basics we might agree on (at least i'd hope so) are: maemo been based on debian, then seen massive tweaks to make it fit for the particular usecase (NIT and phonecalls). So any differences between "upstream" and maemo need careful evaluation *why* they got introduced by Nokia, to start with. It's probably not the generally best approach to simply revert all of those differences to stay |
| 17:26.35 | DocScrutinizer05 | as close to upstream as possible since then we could use debian plain-vanilla right away. In my book maemo is more than just the hildon desktop |
| 17:28.24 | DocScrutinizer05 | after all Nokia engineers themselves for sure were interested in minimizing own workload by staying as close to upstream as possible |
| 17:29.25 | DocScrutinizer05 | you can tell from maemo being what it is, and not looking like android or whatever |
| 17:30.55 | DocScrutinizer05 | Nokia clearly had no agenda to buold walled gardens like pretty much all other smartphone OS developers like Goggle and Apple and younameit do |
| 17:31.26 | DocScrutinizer05 | at least not with maemo5, for HARM aka maemo6 things changed a bit |
| 17:31.48 | sixwheeledbeast | If there is a huge amount of work you have to consider options and how best to use your time to reach the goal. |
| 17:32.21 | DocScrutinizer05 | how is that statement related, however true it may be? |
| 17:33.46 | DocScrutinizer05 | unless it'smeant as being supportive for Nokia engineers' motivation |
| 17:34.38 | DocScrutinizer05 | then yes, exactly this, so they didn't add changes from upstream for shits'n'giggles, they had no time for that |
| 17:36.21 | DocScrutinizer05 | any change that created differneces to upstream was clearly motivated by a factual need created by the usecase |
| 17:37.27 | DocScrutinizer05 | well, at least 95% were, I give then a 5% for ignorance or just "personal" or corporate-identity goals |
| 17:41.24 | *** join/#maemo freemangordon (~ivo@46.249.74.23) |
| 17:41.47 | *** join/#maemo err0r3o3__ (~err0r3o3@212-197-140-8.adsl.highway.telekom.at) |
| 17:44.20 | DocScrutinizer05 | compare to Google what has like 98% corporate goals in android |
| 17:45.41 | DocScrutinizer05 | or RedHat that has 100% corporate goals as in masterplan, in pushing systemd avalanche |
| 17:59.11 | *** join/#maemo eMHa (~mh@p200300738E28D100267703FFFE6CC360.dip0.t-ipconnect.de) |
| 18:19.32 | *** join/#maemo xy2_ (~xy2_@94.239.177.175) |
| 18:20.18 | *** join/#maemo xy2_ (~xy2_@94.239.177.175) |
| 18:31.20 | *** join/#maemo jkepler (~Thunderbi@57.3e.32a9.ip4.static.sl-reverse.com) |
| 18:40.58 | *** join/#maemo jkepler (~Thunderbi@57.3e.32a9.ip4.static.sl-reverse.com) |
| 19:02.04 | *** join/#maemo xorly (~xorly@ip-86-49-24-93.net.upcbroadband.cz) |
| 19:04.11 | *** join/#maemo jkepler (~Thunderbi@4d.3e.32a9.ip4.static.sl-reverse.com) |
| 19:14.11 | Enrico_Menotti | Ehm... I was trying to clone the git repo of current mainline Linux kernel on my old laptop with Devuan. Went out of disk space. Git clone aborted by itself. But now the disk is 98% full. However, I don't find any 'linux' directory. Where is all the stuff which had been downloaded already? (Cloning was at least at 20% when aborted.) Are there any log files of the git clone process anywhere? I'm trying to google for |
| 19:14.12 | Enrico_Menotti | <PROTECTED> |
| 19:16.21 | DocScrutinizer05 | Enrico_Menotti: check for .git dirs (ls -a) |
| 19:16.54 | Enrico_Menotti | DocScrutinizer05 No such dirs, already done that. |
| 19:17.29 | Enrico_Menotti | Even tried, from /, ls -Ral|grep .git. I only find .git dirs related to old clones of other projects. |
| 19:17.33 | DocScrutinizer05 | what was your exactl git command? |
| 19:18.25 | Enrico_Menotti | git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git. |
| 19:19.30 | Wizzup | Enrico_Menotti: git will clean up if it fails |
| 19:20.22 | DocScrutinizer05 | Enrico_Menotti: du -h / | sort -h | less |
| 19:20.46 | Enrico_Menotti | Wizzup Yes, it should. But how is that I have 98% disk full? I didn't check before trying the clone, yes, but with such a filled disk I think it should have aborted much earlier. |
| 19:20.52 | Enrico_Menotti | DocScrutinizer05 Ok, a minute. |
| 19:20.54 | *** join/#maemo jkepler1 (~Thunderbi@2a01:e35:2f37:400:705f:38dd:3b1:d21) |
| 19:22.02 | DocScrutinizer05 | this will take longer than a minute to complete, on an old hardware |
| 19:22.15 | Enrico_Menotti | :) |
| 19:22.38 | DocScrutinizer05 | anyway should help you spot the nasty space hogs |
| 19:23.27 | DocScrutinizer05 | use > to jump to end with hugest dirs, then b to page backwards |
| 19:24.10 | DocScrutinizer05 | don't press q or you start again ;-) |
| 19:29.01 | Enrico_Menotti | Well, I don't see anything strange. There are some very big dirs in the root home directory, but they are related to other projects. Maybe I was really out of space already when started the git clone... Although seems strange. I will try again a git clone and see where it goes, just to check if the behaviour is the same. If yes, then I was already out of space before. If no, then the first git clone filled up the disk. |
| 19:29.38 | timeless | DocScrutinizer05: funny question about `find(1)` |
| 19:30.34 | timeless | consider: `find . -mtime 1`; `find . -mtime +1`; `find . -daystart -mtime +1` |
| 19:31.05 | timeless | based on reading the `man 1 find` under the section for `-mtime`, would you expect `-daystart` to matter? |
| 19:31.15 | freemangordon | any clue why "power off" button in system menu leads to "telinit 5" what is runlevel 5 on maemo? |
| 19:31.15 | DocScrutinizer05 | haha mtime, huge inbconsistency between manpages and implementations |
| 19:31.57 | DocScrutinizer05 | to start with, you wonder if mtamine +1 means one day back or to the future |
| 19:31.57 | freemangordon | I would expect runlevel 0 |
| 19:32.47 | timeless | nods |
| 19:32.53 | timeless | find's syntax is insane |
| 19:33.06 | timeless | and the various implementations of find make it even more exciting |
| 19:33.18 | timeless | for simplicity, let's limit hell to gnu-find |
| 19:33.22 | DocScrutinizer05 | freemangordon: l5:5:wait:/etc/init.d/rc 5 |
| 19:33.54 | DocScrutinizer05 | l0:0:wait:/etc/init.d/minishutdown ;; l6:6:wait:/etc/init.d/minireboot |
| 19:34.13 | timeless | DocScrutinizer05: anyway, my `man 1 find` man page for `-mtime` says ~see -atime for details~ ... but `-atime` doesn't mention `-daystart` which seems unfortunate |
| 19:34.22 | freemangordon | hmm |
| 19:34.31 | DocScrutinizer05 | but then, as you mentioned already, maemo has maemopstart |
| 19:34.33 | *** join/#maemo florian (~fuchs@port-92-198-56-102.static.qsc.de) |
| 19:34.40 | *** join/#maemo florian (~fuchs@Maemo/community/contributor/florian) |
| 19:34.52 | freemangordon | isn't that sysvint script? |
| 19:35.17 | DocScrutinizer05 | -daystart |
| 19:35.19 | DocScrutinizer05 | <PROTECTED> |
| 19:35.20 | DocScrutinizer05 | <PROTECTED> |
| 19:35.48 | timeless | DocScrutinizer05: right... but... wouldn't it make sense for `atime` to mention `-daystart`? |
| 19:35.54 | DocScrutinizer05 | freemangordon: yes, rzc/inittab |
| 19:36.01 | DocScrutinizer05 | etc |
| 19:36.54 | DocScrutinizer05 | timeless: man pages are not always 100% comprehensive |
| 19:37.02 | freemangordon | why the hell Nokia used runlevel 5 for shutdown?!? |
| 19:37.11 | DocScrutinizer05 | timeless: -daystart mentions atime |
| 19:37.12 | freemangordon | that doesn;t make any sense |
| 19:37.12 | timeless | DocScrutinizer05: just looking for support for filing a bug to improve it |
| 19:37.18 | timeless | yes |
| 19:37.37 | DocScrutinizer05 | freemangordon: do they? |
| 19:37.40 | timeless | it just seems silly that -mtime has a backreference to -atime, but -atime doesn't have a backreference to -daystart |
| 19:37.59 | DocScrutinizer05 | timeless: ack |
| 19:38.06 | freemangordon | DocScrutinizer05: telinit 5 will power off the device |
| 19:38.28 | freemangordon | iiuc |
| 19:38.30 | Enrico_Menotti | I'm already at 10% of download. Yes, seems situation didn't change with the first git clone, so yes, I think I was at 98% already. Ok, will do some cleaning. Sorry for having disturbed you. |
| 19:40.09 | DocScrutinizer05 | freemangordon: aside from it being deprecated way in maemo (use dsmetool -b or simesuch instead), I think it just depends on what's in etc/rc.d/5 |
| 19:40.09 | freemangordon | DocScrutinizer05: sorry, my fault |
| 19:40.25 | freemangordon | yeah, right, I misread what you posted |
| 19:41.03 | freemangordon | I think dsme tries to enter act_dead mode through telinit 5 |
| 19:41.15 | DocScrutinizer05 | that sounds more like it |
| 19:42.52 | freemangordon | but then this log https://pastebin.com/JqRHg5bb doesn;t make sense to me |
| 19:44.02 | freemangordon | esp those 2 "go to actdead via reboot" and "Issuing telinit 5" |
| 19:44.35 | DocScrutinizer05 | sorry, no clue, bever looked into it |
| 19:44.47 | freemangordon | Pali: any idea ^^^ ? |
| 19:45.49 | DocScrutinizer05 | might well be maemopstart mess |
| 19:46.08 | DocScrutinizer05 | I suggest having a look into sbin/preinit |
| 19:48.10 | DocScrutinizer05 | freemangordon: http://paste.ubuntu.com/25485776 |
| 19:49.26 | Pali | no idea about runlevels |
| 19:49.34 | Pali | every linux distro uses own scheme |
| 19:49.48 | DocScrutinizer05 | and maemo is doubleplusweird |
| 19:50.05 | Pali | I would not be surprised if some RHEL would use runlevel 4 for shutdown |
| 19:50.34 | DocScrutinizer05 | why not runlevel 9 ? ;-D |
| 19:50.50 | Pali | great! in that script enter_state is nice mapping |
| 19:51.06 | freemangordon | Pali: no, the question is why dsme issues telinit 5 for rebooting to act_dead |
| 19:51.26 | freemangordon | in inittab it is "l5:5:wait:/etc/init.d/rc 5" |
| 19:51.57 | Pali | maybe because of some charger problem? |
| 19:52.20 | Pali | hmmm.... right... I remember one problem with kernel-power in qemu emulator |
| 19:52.53 | freemangordon | Pali: well, this is VMWare running maemo perted over devuan, for sure thre is a problem with the charger :D |
| 19:52.57 | freemangordon | *ported |
| 19:52.59 | Pali | when I turned off Maemo via power button under normal stock kernel in qemu, then it was correctly turned off |
| 19:53.21 | Pali | and when I used same setup, just with kernel-power then it always go to actdead |
| 19:53.26 | Pali | rebooted to nolo |
| 19:53.31 | Pali | and then nolo turned it off |
| 19:53.44 | DocScrutinizer05 | yeah, seem same for some time |
| 19:53.48 | freemangordon | but telinit 5 should not reboot it |
| 19:54.02 | Pali | and it is possible that similar problem is also on real n900 device with kernel-power |
| 19:54.23 | Pali | so maybe it is mce/dsme problem that it does not detect something related to charger correctly? |
| 19:54.36 | Pali | in kernel-power there is bme replacement |
| 19:54.43 | Pali | and nokia's bme daemon is not used |
| 19:54.47 | DocScrutinizer05 | :-D see my pastebin above, getbootstate |
| 19:54.58 | Pali | so maybe because of this dsme/mce can be confused, |
| 19:54.59 | Pali | ? |
| 19:55.05 | DocScrutinizer05 | yes |
| 19:55.22 | DocScrutinizer05 | detecting charger is tricky |
| 19:55.27 | DocScrutinizer05 | very tricky |
| 19:55.31 | Pali | I know |
| 19:55.48 | Pali | in kernel there is a hack for it |
| 19:55.53 | DocScrutinizer05 | anyway sorry, I'm out. Busy |
| 19:55.53 | Pali | and glue code between 3 layers |
| 19:56.08 | freemangordon | is going to issue telnint 5 on the device to see what will happen |
| 19:57.06 | Pali | freemangordon: see dsme/modules/state.c |
| 19:57.29 | Pali | that would happen when CHARGER_STATE_UNKNOWN |
| 19:57.41 | Pali | function select_state |
| 19:58.32 | Pali | start on line 182 |
| 19:58.32 | freemangordon | hehe: DSME_RUNLEVEL_ACTDEAD = 5 |
| 19:58.44 | freemangordon | ok, so runlevel 5 is actdead :D |
| 19:58.49 | Pali | yes |
| 19:59.12 | freemangordon | I guess I should stop hildon-desktop and whatnot on that runlevel, right? |
| 20:00.08 | freemangordon | Pali: btw https://github.com/fremantle-gtk2/mce/blob/gtk2/modules/battery-upower.c |
| 20:00.08 | DocScrutinizer05 | you're trying to re-implement act_dead? prolyl not worth the effort |
| 20:00.14 | DocScrutinizer05 | prolly* |
| 20:00.32 | freemangordon | looks like it works, though it is yet to be tested on a device |
| 20:00.59 | DocScrutinizer05 | act_dead is mainly meeded for BME/charging |
| 20:01.24 | DocScrutinizer05 | so unless you plan to also implement that, you may forget about ACT_DEAD |
| 20:02.00 | freemangordon | yes, I plan to implement act_dead |
| 20:02.10 | freemangordon | remember, port whatever possible :) |
| 20:02.23 | DocScrutinizer05 | and if you actually plan to reimplement that whole mess, please accept my condolences. It's probably very frustrating |
| 20:03.08 | DocScrutinizer05 | even Nokia took literally years to finally debug it so it worked as supposed |
| 20:03.17 | Pali | looks like if you start dsme, its charger state is in CHARGER_STATE_UNKNOWN |
| 20:03.24 | DocScrutinizer05 | the result is the very mess you just discovered |
| 20:03.39 | Pali | and when you request shutdown or reboot when in CHARGER_STATE_UNKNOWN, then you enter into actdead mode |
| 20:04.09 | freemangordon | yeah |
| 20:04.25 | DocScrutinizer05 | shudders figuring the state diagram |
| 20:04.28 | Pali | so if you do not setup charger after starting dsme, you alvways get runlevel 5 |
| 20:04.34 | freemangordon | I see |
| 20:04.53 | Pali | in dsme is "batttest" program |
| 20:05.00 | Pali | which can be used to change charger state |
| 20:05.27 | Pali | run it with -c 0 |
| 20:05.32 | Pali | (charger disconnected) |
| 20:05.37 | Pali | and then it should work |
| 20:05.40 | freemangordon | ok, seems I should tweak hildon-desktop and other init scripts to stop on runlevel 5 |
| 20:06.24 | DocScrutinizer05 | sorry when I sound heretic or sarcastic, but... it'sprobably less effort to port maemopstart than to re-imvent ACT_DEAD incl all needed pieces |
| 20:06.41 | freemangordon | no, unfortunately it is not |
| 20:07.05 | freemangordon | if I do that, the whole devuan stuff in means of services will become useless |
| 20:07.36 | freemangordon | Pali: but, do you have idea who is supposed to reboot then? |
| 20:07.56 | freemangordon | checks runlevel 5 services on n900 |
| 20:07.58 | Pali | errr I do not understand question |
| 20:08.08 | freemangordon | see pastebin ^^^ |
| 20:08.33 | freemangordon | "go to actdead via reboot" |
| 20:08.48 | Pali | and what is the problem? |
| 20:08.57 | freemangordon | who is doing that reboot? |
| 20:10.47 | Pali | in log is: user pressed powerkey to shutdown device; event was received by systemui and it tell it to mce; them mce tell it to dsme; dsme checked charger status and becuase it was unknown it changed shutdown action to actdead; going into actdead means reboot |
| 20:10.55 | Pali | so DSME issued that reboot |
| 20:11.22 | DocScrutinizer05 | yes, that's what i'd think too |
| 20:11.42 | Pali | it either started reboot script (which just send signal to upstart to do REAL reboot) or tell it to upstart directly |
| 20:11.42 | freemangordon | yes, this is what happens |
| 20:11.50 | freemangordon | but at the end dsme issues telinit 5 |
| 20:12.01 | freemangordon | and expect device to reboot |
| 20:12.20 | Pali | and? |
| 20:12.33 | DocScrutinizer05 | I *think* (rather suspect) that dsme talks directly to kernel |
| 20:12.44 | freemangordon | I don't see who is rebooting on runlevel 5 |
| 20:12.52 | Pali | nope, reboot/shutdown is done by upstart for sure |
| 20:12.57 | freemangordon | mhm |
| 20:13.03 | DocScrutinizer05 | then /sbin/init |
| 20:13.12 | Pali | so upstart |
| 20:13.20 | freemangordon | yes, but how? |
| 20:13.22 | DocScrutinizer05 | but finally always it's kernel to shut down system |
| 20:13.48 | Pali | yes, but after upstart kill all services, start all "on shutdown scripts" |
| 20:13.49 | Pali | etc... |
| 20:14.02 | Pali | upstart will then issue kernel syscall for shutdown |
| 20:14.24 | Pali | upstart is pid 1 daemon which listen for signals and also for commands from socket |
| 20:14.34 | Pali | and there is upstart client, named telinit |
| 20:14.37 | DocScrutinizer05 | isn't it like kernel executes shutdown when pid1 terminates? |
| 20:14.44 | Pali | no |
| 20:14.53 | Pali | when pid1 terminates, then kernel panic! |
| 20:14.57 | freemangordon | it will just panic afaik |
| 20:14.59 | DocScrutinizer05 | ouch :-D |
| 20:15.28 | Pali | somebody must issue reboot syscall and pid1 needs to be still alive |
| 20:15.59 | Pali | killing pid 1 with SIGKILL would also lead to kernel panic :-) |
| 20:17.23 | DocScrutinizer05 | echo "off" >/err/powerwhatever ? |
| 20:17.29 | freemangordon | ok, found it |
| 20:17.40 | freemangordon | telinit on maemo is a script |
| 20:17.52 | DocScrutinizer05 | LOL |
| 20:18.00 | freemangordon | which does /etc/init.d/minireboot in runlevel 5 |
| 20:18.08 | freemangordon | *on |
| 20:18.09 | DocScrutinizer05 | sbin/init is 104kB ELF |
| 20:18.21 | freemangordon | init != telinit |
| 20:18.24 | Pali | yes, it is upstart |
| 20:18.28 | DocScrutinizer05 | yes, thus LOL |
| 20:18.46 | Pali | telinit is upstart client |
| 20:18.57 | Pali | init is upstart daemon (pid1) |
| 20:18.58 | DocScrutinizer05 | in former good ole' times telinit was a symlink to init |
| 20:19.04 | DocScrutinizer05 | or even a hardlink |
| 20:19.48 | Pali | maybe it can be implemented based on argv[0] also today... |
| 20:19.55 | freemangordon | ok, mystery revealed, now, how to fix that |
| 20:19.57 | Pali | or based on getpid() |
| 20:20.17 | DocScrutinizer05 | that's how telinit/init does it |
| 20:20.30 | freemangordon | maybe put some act_dead upstart service that does what telinit 5 in maemo does |
| 20:20.43 | DocScrutinizer05 | getpid()!=0 -> I'm telinit |
| 20:20.51 | Pali | and what do you want to achieve? |
| 20:21.04 | freemangordon | going to actdead on telinit 5 |
| 20:21.16 | Pali | and what does actdead mean for you? |
| 20:21.18 | DocScrutinizer05 | define ACT_DEAD ;-) |
| 20:21.55 | freemangordon | see in /etx/X11/Xsession.actdead |
| 20:22.09 | Pali | because in maemo it is runlevel in which nothing is running, just bme daemon + some led pattern |
| 20:22.16 | freemangordon | Pali: not sure I understand your question |
| 20:22.17 | DocScrutinizer05 | yep |
| 20:22.20 | freemangordon | yes |
| 20:22.39 | Pali | so you want to have also own actdead-like runlevel in devuan? |
| 20:22.46 | freemangordon | sure, why not? |
| 20:22.48 | DocScrutinizer05 | though you *could* even run WLAN in ACT_DEAD X-P |
| 20:23.09 | DocScrutinizer05 | there's a config in iirc mce/config |
| 20:23.12 | Pali | I'm asking what does that actdead mean for you... |
| 20:23.18 | Pali | as in maemo it is special system runlevel |
| 20:23.19 | freemangordon | what you explained |
| 20:23.25 | freemangordon | yes, I know |
| 20:23.26 | Pali | devuan uses that runlevel for different thing |
| 20:23.33 | Pali | so there cannot be 1:1 mapping |
| 20:23.43 | freemangordon | I don't think anything besides 0,1,2 and 6 is used |
| 20:23.54 | DocScrutinizer05 | errr |
| 20:24.03 | Pali | yes, there are used |
| 20:24.10 | freemangordon | what for? |
| 20:24.19 | Pali | they are same |
| 20:24.23 | Pali | do same thing |
| 20:24.38 | freemangordon | 2-5? sure, but I can redefine those |
| 20:24.53 | DocScrutinizer05 | hmmm https://wiki.debian.org/RunLevel |
| 20:24.55 | Pali | but then you need to redefine all, I mean all, scripts from all deb packages |
| 20:25.05 | Pali | basically all daemons starts in those 2-5 runlevels |
| 20:25.32 | freemangordon | no, I will just disable services that are not needed, for example when maemo-system-services package gets installed |
| 20:25.38 | Pali | it is impossible to create in debian e.g. runlevel 5 in which only one daemon would run (fake-bme) |
| 20:25.58 | freemangordon | why not? |
| 20:25.59 | Pali | but those services are provided in different deb packages |
| 20:26.12 | DocScrutinizer05 | anyway, have fun! :-) I'm off |
| 20:26.22 | freemangordon | oh, I meant - disable them gracefully |
| 20:26.26 | Pali | are you going to edit every one deb package and change it to stop own service in runlevel 5? |
| 20:26.30 | freemangordon | no, no |
| 20:26.47 | Pali | you cannot do it in other way, you need to edit header of init script |
| 20:26.57 | Pali | in which is writting for which runlevels it should start |
| 20:27.03 | Pali | and for each it should stop |
| 20:27.23 | DocScrutinizer05 | init scripts are distro specific. My point |
| 20:27.26 | freemangordon | fur upstart, I can disable a job with a command, the same goes for sysvinit |
| 20:27.33 | freemangordon | *for |
| 20:27.49 | Pali | look e.g. at lightdm |
| 20:28.05 | Pali | in /etc/init.d/lightdm is: |
| 20:28.05 | Pali | # Default-Start: 2 3 4 5 |
| 20:28.05 | Pali | # Default-Stop: 0 1 6 |
| 20:28.12 | freemangordon | Pali: I understand what you mean, just truing to tell you there is a way |
| 20:28.17 | freemangordon | this is the defaults |
| 20:28.43 | Pali | yes, defaults, configured when installing/upgrading |
| 20:28.58 | Pali | you can overwrite defaults after installing deb package |
| 20:29.39 | Pali | https://wiki.debian.org/RunLevel: Editing runlevels: Runlevels can be edited manually by editing control scripts in /etc/init.d and symbolic links in /etc/rc0.d ... /etc/rc6.d. |
| 20:30.01 | freemangordon | Pali: update-rc.d |
| 20:30.37 | Pali | yes, but that is for updating *existing* init script *after* installation of deb package |
| 20:31.08 | Pali | it is for case admin want to change own script's runlevel after installation |
| 20:31.24 | Pali | and it is normal that admin would make some temporary changes |
| 20:31.34 | Pali | and then reset serttings to *defaults* |
| 20:31.45 | freemangordon | Pali: yes, but one can put a trigger in debconf (or whatever it is called) |
| 20:32.02 | freemangordon | and check what is enabled after avaery installed .deb |
| 20:32.05 | freemangordon | *every |
| 20:32.08 | Pali | I would be angry if somebody break update-rc.d defauls! |
| 20:32.36 | freemangordon | Pali: ok, I don't want to make you angry, then we might invent another runleve, like 7 |
| 20:32.53 | freemangordon | 8 is already used for MALF in maemo :) |
| 20:33.04 | Pali | creating a new runlevel is PITA too |
| 20:33.09 | DocScrutinizer05 | too late, runlevels 7 to 9 already exist :-) |
| 20:33.22 | freemangordon | Pali: also, we're talking maemo here, not devuan running on a server |
| 20:33.26 | Pali | as scripts do not have confiugured to stop in new invented runlevels |
| 20:33.49 | Pali | and do not forget that scripts/daemons have its own shutdown procedure in init files |
| 20:34.01 | freemangordon | actually it is "stop on runlevel [!2345]" |
| 20:34.03 | Pali | which is sometimes needed and simple kill -9 would cause problems |
| 20:34.15 | Pali | e.g. udev |
| 20:34.38 | freemangordon | Pali: ok, got it, what you suggest then |
| 20:34.41 | Pali | "stop on runlevel [!2345]" is better, but that is upstart right? |
| 20:34.46 | freemangordon | right |
| 20:34.56 | Pali | I'm thinging about better solution.... |
| 20:35.12 | DocScrutinizer05 | get your distro specific init |
| 20:35.18 | freemangordon | ok, I am all ears... well, eyes :) |
| 20:35.46 | DocScrutinizer05 | init is one of the major distro specific config topics |
| 20:35.48 | freemangordon | DocScrutinizer05: for the Nth time - it will break all upstream services |
| 20:36.09 | DocScrutinizer05 | no |
| 20:36.26 | Pali | cannot be runlevel 1 modified for it? |
| 20:36.33 | DocScrutinizer05 | devuan gets their own init config and it doesn't break debian upstream |
| 20:36.37 | Pali | in 1 running small number of services |
| 20:36.49 | freemangordon | yes, it will, as maemo-upstart looks in /etc/event.d , not in /etc/init |
| 20:37.04 | DocScrutinizer05 | every distro has their own init config |
| 20:37.07 | Pali | and init script for single could be modified to check presence e.g. of /run/actdead and based on this decide if real single is started |
| 20:37.09 | freemangordon | Pali: single user for battery charging. why not |
| 20:37.10 | Pali | or just actdead |
| 20:37.50 | DocScrutinizer05 | actually everything under /etc is highly proprietary to the particular distro |
| 20:38.41 | freemangordon | Pali: ok, sounds like a plan |
| 20:38.49 | freemangordon | but what about MALF? |
| 20:39.00 | freemangordon | or use 1 as well |
| 20:39.02 | Pali | also 1? |
| 20:39.17 | DocScrutinizer05 | systemd is forcing pan-distro uniformity, anot the least by moving init config to /usr/ |
| 20:39.33 | Pali | you can create some file in /run to check if current state is actdead or malf |
| 20:39.47 | Pali | if e.g. some dsme/mce/bme needs to know this fact |
| 20:39.54 | freemangordon | it is already created, /var/dsme/saved_state or something |
| 20:40.02 | Pali | so better |
| 20:40.30 | freemangordon | but then, who is going to do the "split"? |
| 20:40.39 | freemangordon | and start the services? |
| 20:41.24 | freemangordon | what are the drawbacks of runlevel 7 and 8? |
| 20:42.29 | Pali | that not all services would be turned off |
| 20:42.47 | freemangordon | but this is what we want actually |
| 20:43.24 | freemangordon | you don;t need anything besides mce/dsme running, right? |
| 20:43.51 | freemangordon | and this is needed only for fancy stuff like LEDs |
| 20:44.21 | freemangordon | ah, wait |
| 20:44.29 | freemangordon | not all will be off? |
| 20:44.51 | freemangordon | so, if a runlevel is missing in LSB, the service will be started? |
| 20:45.02 | freemangordon | LSB header that is |
| 20:45.21 | Pali | yes, because if in init.d script is written to stop in 0, 1 and 6, then it would not be stopped in 7 |
| 20:45.41 | Pali | if is missing, then service would not be started nor stopped |
| 20:45.49 | freemangordon | but we're talking after reboot here |
| 20:45.51 | Pali | so if is already running, then it stay running |
| 20:45.59 | freemangordon | so nothing is started |
| 20:46.18 | freemangordon | hmm, "init: illegal runlevel: 7" |
| 20:48.45 | freemangordon | Pali: ok, please, think about that, I'll follow whatever you say here |
| 20:49.04 | freemangordon | I don;t feel comfortable with those boot scripts anyway |
| 20:49.45 | freemangordon | Pali: actually 1 in not single-user state |
| 20:49.57 | freemangordon | is is 'S' or 's' |
| 20:53.54 | Pali | read this: https://manpages.debian.org/stretch/sysvinit-core/init.8.en.html |
| 21:07.42 | freemangordon | Pali: ok, read it. now, the main question remains - do we aim for sysvinit? |
| 21:08.15 | freemangordon | or for upstart or for something else? |
| 21:08.33 | Pali | if you want fully working debian/devuan system and allow installation of any software from repository, then you can use only things supported by debian/devuan |
| 21:08.38 | Pali | init daemon is critical |
| 21:08.41 | freemangordon | sure |
| 21:08.57 | freemangordon | but devuan supports both upstart and sysvinit |
| 21:09.16 | freemangordon | and parazyd said they will support openrc (or somesuch) soon |
| 21:09.22 | Pali | if upstart is working, then you can choose upstart |
| 21:09.50 | Pali | but I think everything (systemd, upstart, openrc...) would just use compatibility layer for sysv init scripts |
| 21:10.21 | Pali | as debian daemon packages install maximally systemd units and sysvinit init.d scripts |
| 21:10.36 | freemangordon | ok, I guess I can remove upstart scripts then |
| 21:10.56 | freemangordon | an stay with sysvinit only |
| 21:11.16 | freemangordon | however, this doesn's solve the runlevel issue |
| 21:11.28 | Pali | so basically there would not be functional difference between upstart and sysvinit |
| 21:12.49 | Pali | maybe... I would play with idea to drop both malf and actdead runlevel |
| 21:13.30 | Pali | and if something like actdead is needed, then implement it in one of the early script, which would block whole booting? |
| 21:13.40 | freemangordon | ok, but do we really need runlevel 5? as it seems more complicated than that, most-probably ACT_DEAD is defined by Xsession.actead rather than runlevel |
| 21:14.28 | freemangordon | as I don;t see anybody changing the runlevel on n900 when it is in act_dead state |
| 21:15.08 | freemangordon | Pali: look at what /sbin/telinit does |
| 21:17.57 | freemangordon | it basically put the next state (if needed) in /var/lib/dsme/saved_state and then reboots or does shutdown |
| 21:18.02 | freemangordon | *puts |
| 21:18.19 | freemangordon | no runlevel change really |
| 21:18.52 | freemangordon | maybe thoser runlevels are some remnants from maemo 4 |
| 21:44.51 | DocScrutinizer05 | https://www.nytimes.com/2017/09/07/business/equifax-cyberattack.html |
| 21:49.44 | DocScrutinizer05 | freemangordon: quite possible. there's a lot like this, in preinit, in NAND partitions (orphaned initfs), basically everywhere |
| 22:14.51 | *** join/#maemo dafox (~dafox@2a02:a448:c25a:1:7061:3b2a:37df:ded3) |
| 22:52.50 | timeless | frowns |
| 22:52.59 | timeless | so, `disown` is apparently bashis |
| 22:53.00 | timeless | t |
| 23:07.40 | Enrico_Menotti | I was playing around with kernel modules - in particular, I was trying to build the Android binder, which is in mainline kernel. I did make menuconfig. I'm unable to select this driver as a loadable module - just select it or not. Any idea? |
| 23:09.10 | Enrico_Menotti | (Anyway, now bedtime - I will read eventual comments tomorrow. Bye!) :) |
| 23:18.26 | *** join/#maemo LjL (~ljl@unaffiliated/ljl) |
| 23:24.17 | *** join/#maemo pagurus` (~user@i59F7C7AA.versanet.de) |
| 23:31.01 | DocScrutinizer05 | timeless: (bashism) yes, absolutely. `man disown` -> BASH_BUILTINS(1) |
| 23:31.20 | timeless | gave up and used `screen` |
| 23:31.29 | timeless | (which is what i would normally use anyway!) |
| 23:32.01 | timeless | i have a slow starting tomcat server behind apache, and i wanted to have apache automatically switch from a `maintenance page` to connecting to tomcat once tomcat is `ready` |
| 23:33.12 | timeless | solution: add a private (localhost) vhost mapped to the tomcat ajp, use curl to wait for tomcat to be ready -- once the command finishes, reload apache's config (with the primary tomcat bridge enabled) |
| 23:33.27 | timeless | when it's down, a fallback vhost for the same domain points to static apache content :) |
| 23:33.48 | timeless | but... the trick was running this from a calling script and being able to continue doing other things while that waited |
| 23:34.09 | timeless | screen -S waitfortomcat -d -m ~/bin/connect-tomcat |
| 23:34.20 | timeless | has never used `-m` before |
| 23:40.13 | *** join/#maemo Alexxxlrus (~Alexxxlru@176.212.68.34) |
| 23:42.09 | Alexxxlrus | дÑÑги никÑо n900 не пÑодаеÑ? |
| 23:43.04 | DocScrutinizer05 | never had the idea to use `screen` in scripts |
| 23:43.24 | timeless | someone had a thing describing how to use screen to debug cron jobs |
| 23:44.09 | timeless | but i can't find that today |
| 23:45.18 | DocScrutinizer05 | for parallelism in shellscripts I jave a disgusting example (made by me a maybe 10 years ago): http://termbin.com/gmrp |
| 23:49.16 | timeless | pretty fancy |
| 23:49.28 | timeless | read it once but doesn't have the stomach for pieces of it |
| 23:56.09 | *** join/#maemo LjL (~ljl@unaffiliated/ljl) |
| 23:59.34 | timeless | sighs https://www.irccloud.com/pastebin/yRdzZNCZ/ |