**** BEGIN LOGGING AT Thu Sep 07 03:00:01 2017 Sep 07 07:21:40 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? Sep 07 07:40:51 I doubt devuan would prevent you from using any of those init systems Sep 07 07:41:03 but I don't really see any benefit for maemo on devuan Sep 07 07:41:20 53 Sep 07 07:41:58 bencoh: benefit over what? Sep 07 07:42:44 parazyd: of choosing any specific init systems over the default one in devuan Sep 07 07:42:54 -s Sep 07 09:03:01 sixwheeledbeast: not sure why you'd not just migrate to a maintained and decent init system Sep 07 09:12:31 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. Sep 07 09:13:51 I fully agree regarding maintained, but unless there's a bug/vulnerability what needs changing? Sep 07 09:30:16 it's a dead project Sep 07 09:30:57 I have no interest in taking maintenance of dead init systems Sep 07 09:31:08 s/taking/taking up/ Sep 07 09:31:09 Wizzup meant: I have no interest in taking up maintenance of dead init systems Sep 07 09:31:45 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 Sep 07 09:32:12 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. Sep 07 09:36:46 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 Sep 07 09:37:08 not this again. Sep 07 09:38:08 there is no reinventing an init system, there's only applying hygiene and porting scripts. Sep 07 09:39:02 yeah sure Sep 07 09:39:12 do you believe that maemo is defined by the fact that it uses upstart? Sep 07 09:39:26 as I saud, have fun porting a bazillion scripts in maemo-extras Sep 07 09:39:56 I believe that maemo is defined by the synergy of 3 dozen details Sep 07 09:40:10 and yes, init system is part of that Sep 07 09:40:27 so you essentially don't want to change anything that 'defines' it by your definition Sep 07 09:41:03 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?) Sep 07 09:41:23 and if there are things in whatever repo that depend on hal, they will need to be fixed Sep 07 09:41:28 that's part of maintaining an ecosystem Sep 07 09:41:48 it's not different for an init system, although it might be more work/invasive Sep 07 09:41:50 then go the heck and develop devuan, why abuse the name maemo? Sep 07 09:42:10 sure enough, let's see what a better name would be. Sep 07 09:42:20 if that saves us from future abuse Sep 07 09:42:27 demeaman? Sep 07 09:42:40 maevuan? Sep 07 09:43:03 devaemo Sep 07 09:43:03 right now there's maedevu, that might work Sep 07 09:43:16 but we can always change it later, not too interested in naming atm Sep 07 09:43:46 pronounced meh-deh-voo ? Sep 07 09:44:12 I'm kind of leaning towards daemo Sep 07 09:49:29 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*? Sep 07 09:51:31 no, clearly systemd is required to make phonecalls reliably. Sep 07 09:51:34 * Wizzup sighs Sep 07 09:52:09 mmm, wouldnt it be beautiful to integrate all maemo daemons into systemd? Sep 07 09:52:24 onebinary ramdisk and voila! Sep 07 09:53:10 Wizzup: you're telling BS. systemd is unrelated to phonecalls Sep 07 09:53:34 cgroups however are very important for maemo Sep 07 09:53:52 I was ridiculing your senseless arguments Sep 07 09:54:06 yeah, in an anept way Sep 07 09:54:31 since I never sdayd anything that faunly warants this BS statement about systemd for cals Sep 07 09:54:48 'said' Sep 07 09:55:26 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 Sep 07 09:55:39 and if you're not going to do any work, and just flame and throw shit around, I'm going to ignore your opinion Sep 07 09:56:54 no, I never suggested that. maybe you need some coffee to wake up Sep 07 09:57:22 you're ignoring my opinion anyway, you always did Sep 07 09:57:43 you're even ignoring the meaning of my statements Sep 07 09:57:53 and instead quote me incorrectly Sep 07 09:59:41 and your statements make me ignore your option since you evidently have less clue about the implicit requirements regarding phonecalls than Enrico_Menotti Sep 07 09:59:50 opinion* Sep 07 10:12:21 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? Sep 07 10:13:17 if you make it work with all of devuans packages and do all the work to port it, then there is no problem Sep 07 10:13:38 and if you would, you'd realise that you're working against the flow, against the path of least effort Sep 07 10:14:38 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 Sep 07 10:14:45 just because of some legacy init scripts Sep 07 10:15:11 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 Sep 07 10:15:44 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 Sep 07 10:28:43 I would have thought getting upstart working on Devuan would be easier than making OpenRC work with Maemo, but I am no expert. Sep 07 10:30:42 The problem is having it continue to work over months/years/releases Sep 07 10:31:02 Thinking only about the short-term solution is short sighted and will come back to bite Sep 07 10:39:22 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. Sep 07 10:41:58 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. Sep 07 10:42:37 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. Sep 07 10:42:53 Down that path lies insanity Sep 07 10:42:57 I wish it was different, but it's not Sep 07 10:43:12 Making something to work to a future goal should have better long term support over back patching but "Maemo" is a weird beast. Sep 07 10:43:16 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 Sep 07 10:43:18 My expectation would be that people could port over packages with relative ease or ask others to do so Sep 07 10:43:36 sixwheeledbeast: I don't care if it is called maemo or not, I want a nice GNU/Linux OS for my devices Sep 07 10:43:42 said poettering Sep 07 10:44:44 he probably didnt say 'nice', but 'mine' Sep 07 10:46:30 Any comparison of this discussion and poetterings general attitude is silly & trolling Sep 07 10:47:47 Even when you keep upstart and change devuan to work with it, the maemo-extras packages still won't work without additional changes Sep 07 10:48:37 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 Sep 07 10:48:55 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. Sep 07 10:49:02 *You* are free to pick a different system. *Nobody* is forcing you to do anything Sep 07 10:49:26 Stop pissing on other people Sep 07 10:50:02 swb: i guess that comment was about having to keep some compatibility layer Sep 07 10:50:07 sixwheeledbeast: it won't the tls libraries of course Sep 07 10:50:15 it won't affect* Sep 07 10:50:47 KotCzarny: that was about the near impossibility of such a compatibility layer within a sane os/distro Sep 07 10:50:53 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 Sep 07 10:51:32 DocScrutinizer05: devuan imports most packages directly from debian Sep 07 10:51:35 in case you didn't know Sep 07 10:51:40 so my statement is as true as it gets Sep 07 10:52:04 in case you didn't know, I understood how devuan works before I sugested maemo goes devuan Sep 07 10:52:13 then why state such falsehoods? Sep 07 10:52:50 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 Sep 07 10:53:05 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 Sep 07 10:53:29 * Wizzup rolls his eyes Sep 07 10:53:33 I'll await your implement of all of this Sep 07 10:54:32 it's YOU not me who's about to invent and failing to implement a new OS falsely dubbed maemo devuan Sep 07 10:55:31 it mostly seems like you slinging shit at everyone who doesn't do exactly as you wish Sep 07 10:55:39 I suggested maemo & devuan join forces back when, *because* devuan allows keeping particularly upstart and cgroups Sep 07 10:55:53 openrc and systemd support cgroups just fine Sep 07 10:56:11 you're telling bullshit without end Sep 07 10:56:42 systemd evidently takes cgroups hostage Sep 07 10:56:56 and is NOT compatible with maemo Sep 07 10:57:30 and when you want systemd then why the heck you pester the poor devuan people with that? Sep 07 10:57:44 >when you want systemd Sep 07 11:01:01 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 Sep 07 11:01:02 know where to stop calling you out, so I rather stop right here Sep 07 11:02:29 'there is no such a particular init system in devuan?' Sep 07 11:02:46 no, devuan is about init dreedom Sep 07 11:03:22 maemo upstart is perfectly fine inside devuan Sep 07 11:03:26 OK, do it Sep 07 11:03:38 no, why should I? Sep 07 11:04:53 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? Sep 07 11:05:10 whatinit syste is nowhere supported? Sep 07 11:05:22 and why are you saying I am trying to redefine what devuan means? Sep 07 11:05:41 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 Sep 07 11:05:45 meh, you are trolling me, or you're dense Sep 07 11:06:00 * buZz hands out liquorice Sep 07 11:06:15 * KotCzarny never tried liquir rice Sep 07 11:06:22 *liquor Sep 07 11:07:55 :P Sep 07 11:08:36 liquorice is one of the most traditional of all dutch candies Sep 07 11:08:57 its what you give to your kids when they are fighting on the backseat of the car Sep 07 11:09:00 so they stfu Sep 07 11:09:25 i wonder what would happen if you gave them liquor rice Sep 07 11:09:39 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? Sep 07 11:09:58 KotCzarny: I imagine it does the same Sep 07 11:10:26 You just end up with a messy car Sep 07 11:10:40 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 Sep 07 11:10:41 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 Sep 07 11:11:06 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 Sep 07 11:11:17 if you're not going to do it, kindly piss off Sep 07 11:11:32 I'm not going to bend to your will, especially if you're not going to put in any effort yourself Sep 07 11:12:24 somebody doing the wrong thing doesn't earn privileges to tell others to do the right ting or piss off Sep 07 11:13:28 How long do you want to keep everyone in here hostage? Sep 07 11:13:55 That was completely uncalled for Sep 07 11:14:07 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 Sep 07 11:14:14 Unless you want to force people to move discussion about this topic to a channel where you don't exist Sep 07 11:14:30 yes, do that Sep 07 11:14:31 no, you don't agree with my logic and I've long given up trying to talk to you Sep 07 11:14:34 wizzup, /ignore works wonders Sep 07 11:14:42 KotCzarny: I want my refund for my neo900 first Sep 07 11:14:46 then I will just that Sep 07 11:14:48 I will do* Sep 07 11:14:58 it's YOU who is insulting people and telling them to piss off, so who's holding anybody histage here? Sep 07 11:15:07 Wizzup: did you order a pyra yet? :D Sep 07 11:15:23 I don't know man, calling people's arguments 'total BS' is kind of offensive Sep 07 11:15:32 buZz: I will use the refund to do that Sep 07 11:15:38 \o w00p Sep 07 11:15:57 isnt neo900 refund like 5 pyras? :P Sep 07 11:16:12 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 Sep 07 11:17:12 DocScrutinizer05: did you see my question about the refund in the neo900 channel? Sep 07 11:18:00 did you see my moaning about some irc users in #freenode? Sep 07 11:18:59 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 Sep 07 11:19:03 did anyone watch american dad s14e21 yet? Sep 07 11:19:14 buZz: me :) Sep 07 11:19:14 I don't need to rethink anything. I just don't want to have to deal with you Sep 07 11:19:15 i'm hungry Sep 07 11:19:25 parazyd: nice, right? :D Sep 07 11:19:26 This is not the first time, and I want this to be the last time. Sep 07 11:19:32 buZz: indeed :D Sep 07 11:19:35 i mean, -any- topic better than this ^_^ Sep 07 11:19:57 KotCzarny: hi hungry, i am buZz Sep 07 11:20:14 hi buzz, what are you buzzing about? Sep 07 11:20:27 maybe i will finally check that n900 Sep 07 11:20:27 :) Sep 07 11:20:33 i am F5-ing some order pages Sep 07 11:20:36 or not. left it at other place, eh Sep 07 11:20:46 getting a GTX1060 today , and some parts for 3D printer Sep 07 11:21:19 the part that keeps me from doing it i would have to replace screens to make it boot/be usable Sep 07 11:21:56 unless someone has a workaround to enable tvout without working lcd Sep 07 11:22:12 (my guess fb is uninitialized and fails to setup tvout) Sep 07 11:22:17 hmm Sep 07 11:22:30 maybe if you can ssh into it? Sep 07 11:22:45 to ssh one would have to enable usb net or wifi Sep 07 11:22:53 add a serial line? Sep 07 11:23:02 serial line isnt trivial Sep 07 11:23:13 *shrug* Sep 07 11:23:23 if it's trivial, it's not fun Sep 07 11:23:32 i wonder if it's just a setting somewhere in xomap or kernel Sep 07 11:24:26 wouldnt it be great if you boot, it detects missing lcd but setups things anyway to make tvout work? Sep 07 11:25:20 (that was my original plan with that n900) Sep 07 11:25:55 should work, except afaik for NOLO Sep 07 11:26:14 nope. bad/missing lcd results in flatline on tvout Sep 07 11:26:15 Nobody Only Lives Once Sep 07 11:26:26 seems NOLO vlows chunks when LCD controller chip init fails Sep 07 11:26:37 buZz: lol Sep 07 11:26:40 it boots fully, but no tvout Sep 07 11:27:00 i only see the 1px yellow line in the middle (probably some message pops up) Sep 07 11:27:16 (most likely about missing modem functions) Sep 07 11:27:32 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? Sep 07 11:27:34 swapping lcds makes tvout work as expected Sep 07 11:28:17 trivial to check, just disconnect ribbon and connect to tv set (set wifi to auto connect before though for checks) Sep 07 11:29:02 hmm, or not. Seems video init also in SoC and thus for TVout too, is failing when SoC cannot talk to LCD Sep 07 11:30:06 anyway I'd suggest to NOT load the kernel driver for LCD controller, that might help Sep 07 11:31:10 my guess is that lcd init populates height/width structures which are not hardcoded. but it's just a guess Sep 07 11:32:08 might be also that failing lcd init stops tv init from happening Sep 07 11:37:58 KotCzarny: >>lcd init populates height/width structures<< yes, exactly my guess too Sep 07 11:38:44 hmm, i wonder if that means it would be possible to drive higher res lcd with n900 Sep 07 11:38:56 judging from my involuntary experiments with broken I2C(?) connection to LCD controller a 6(?) years ago Sep 07 11:39:19 yes, should be possible Sep 07 11:39:35 were there any reports of such experiments? Sep 07 11:40:00 check OMAP3430 TRM section "video" or whatever Sep 07 11:40:37 OMAP3430 has a range of resolutions it supports Sep 07 11:40:52 and a generic display hardware interface Sep 07 11:42:30 pdf says 'any size up to 2048x2048 with 8px granularity' Sep 07 11:43:02 in section 15 Sep 07 11:44:05 but mipi dsi says 'xga @60fps with 24depth' Sep 07 11:45:56 yep, OMAP34xx_ES3.1.x_PUBLIC_TRM_vZM___SWPU223M.pdf section 15 "display subsystem" Sep 07 11:48:02 http://susepaste.org/64625507 Sep 07 11:48:28 yes, but see mipi section too Sep 07 11:49:22 basically boils down to >> Programmable pixel rate up to 75 MHz<< Sep 07 11:49:34 MIPI is just an industry standard Sep 07 11:50:02 isnt that the actual connector/standard used? Sep 07 11:50:46 unless all of those standards on the same connector Sep 07 11:50:54 the one *used* in N900 maybe, but not the only supported one Sep 07 11:51:05 yes, the latter Sep 07 11:51:48 well, there's pinmux, depends what is allowed/suppported on which of the available pins/balls Sep 07 11:53:07 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 Sep 07 12:11:24 KotCzarny: mipi SDI or mipi DBI Sep 07 12:11:57 ugh DSI too Sep 07 12:24:37 anyone has an idea of the serial protocol uses in popular cheap smartwatch DZ09 and clones? Sep 07 12:30:51 sicelo: doesn't https://www.ixquick.com/do/search?q=serial+protocol++DZ09 help? Sep 07 12:34:07 always a good goto: bunnie https://www.bunniestudios.com/blog/?p=4297 Sep 07 12:34:13 bunnie <3 Sep 07 12:40:23 thanks. Sep 07 12:40:29 lookinkg Sep 07 12:40:40 in the meantime have been downloading the f/w Sep 07 14:01:03 thats good... http://www.bunniefoo.com/fernvale/fernvale-31c3.pdf Sep 07 14:15:50 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 Sep 07 14:16:18 i notice i didn't mention bluetooth in my earlier question Sep 07 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? Sep 07 14:18:43 sicelo: or that even lower inside bt fw module? Sep 07 14:20:13 no idea. i'm no better than you are .. i bet i know way less Sep 07 14:22:43 establishing a bluetooth link using rfcomm is very easy .. my problem is in knowing what to send Sep 07 14:27:38 bt simplifies things a tad, since at least you have a profile that predicts which protocol being used to send/receive Sep 07 14:27:56 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 ? Sep 07 14:36:02 DocScrutinizer05: have you ever had `zless foo.gz` not `work`? Sep 07 14:36:15 for me, i get a warning that this may be a binary file Sep 07 14:36:26 and then less lets me look at the uncompressed file :-( Sep 07 14:36:33 hmm, never really used zless Sep 07 14:36:58 oh! Sep 07 14:37:00 * timeless sighs Sep 07 14:37:04 SHELL=/bin/false Sep 07 14:37:05 weird. cehck ending, maybe needs .tgz or .tar.gz Sep 07 14:37:06 that's awesome Sep 07 14:37:14 LOL Sep 07 14:37:32 so, zless honors shell Sep 07 14:37:42 if in doubt, try mc ;-) Sep 07 14:37:46 and since i'm running as a service account, where shell=/bin/false, doesn't work Sep 07 14:38:02 * timeless wonders if this is really the right behavior Sep 07 14:38:51 I *guess* zless is just a tiny bash wrapper around tar/zip and less, doing uncompressing and piping to $PAGER Sep 07 14:39:13 zless is a binary that does some wrappings Sep 07 14:39:17 but yes, kinda Sep 07 14:39:29 it mostly sets LESSOPEN / LESSPIPE and friends Sep 07 14:39:34 except, apparently it honors SHELL Sep 07 14:39:44 * timeless is still trying to decide why anyone would think that's the right behavior Sep 07 14:40:51 * DocScrutinizer05 wonders how logging in interactively to an account with SHELL=/bin/false is the right behavior anyway Sep 07 14:41:09 sudo -u tomcat /bin/bash Sep 07 14:41:14 HOME=`eval echo ~$USER` Sep 07 14:41:21 * timeless clearly needs to add SHELL=/bin/bash Sep 07 14:41:47 i'm trying to avoid having lots of scripts that run as root Sep 07 14:41:49 less honors SHELL, not zless Sep 07 14:41:59 bencoh: ah Sep 07 14:42:34 can you walk me through why it should do that? is the expectation that someone would want SHELL=psh and LESSPIPE={perl} ? Sep 07 14:42:39 I just 2 days ago googled for shel = /bin/false resp /bin/nologin and it's a pretty weird topic Sep 07 14:42:50 oh, yeah Sep 07 14:43:03 it *should* forbid any interactive login Sep 07 14:43:07 more or less one is "use this for services" and the other is "use this for accounts that have been disabled" Sep 07 14:43:33 well, the way computers work, a permission has to exist, so this account has permissions Sep 07 14:43:41 and you can create a permission, and then ask it to run a program Sep 07 14:43:45 e.g. tomcat (i.e. java) Sep 07 14:43:56 or you can asks it to run some other program (e.g. bash) Sep 07 14:43:59 well, technically there's little difference between false and nologin, just the latter prints a polite message about the fact Sep 07 14:44:04 yep Sep 07 14:44:13 hence nologin is really "how to tell a user to go away" Sep 07 14:44:24 and false is what you use for a service account -- something a user shouldn't be trying to log into Sep 07 14:44:30 it's for hysterical raisins Sep 07 14:44:40 my favorite part of that dance is that the location of those files has changed over time Sep 07 14:44:45 yep Sep 07 14:45:00 false was part of the base system, so people cheated and used it for locking accounts/services Sep 07 14:45:06 but eventually they wanted to be fancier Sep 07 14:45:29 sort of, yes Sep 07 14:45:49 aiui there's no best common practice Sep 07 14:47:19 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... Sep 07 14:48:35 then there's also fun with PAM Sep 07 14:49:05 timeless: env what say after login? Sep 07 14:55:55 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 Sep 07 14:56:11 but then that's just what came to my mind right now Sep 07 14:57:22 drathir: this isn't a `login` proper, it's a `sudo` Sep 07 14:57:54 DocScrutinizer05: partially, `sshd` can easily ignore an empty password Sep 07 14:58:05 which is why the screwy system is the way it is... Sep 07 14:58:29 you shouldn't have sshd in an account that's not meant to have ssh login Sep 07 14:58:57 sshd doesn't really live inside an account :) Sep 07 14:59:08 but if you mean ~/.ssh/authorized_keys -- well... Sep 07 14:59:10 well, depends on your system config Sep 07 14:59:26 sshd is almost always owned by root :) Sep 07 14:59:39 sure, it's /possible/ to run sshd as another user (i do it occasionally to debug things), but... Sep 07 14:59:53 basically sshd is a glorified login + su Sep 07 15:00:55 it *should* get configured in a way so it behaves pretty much identical or evem *less* permissive than normal login Sep 07 15:02:11 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] Sep 07 15:03:45 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... Sep 07 15:05:15 well, at least I guess you could, I never tried this and I think defualt is not allowing it Sep 07 15:06:04 * DocScrutinizer05 glares at git Sep 07 15:07:33 or just use a different pam configuration? ... Sep 07 15:07:56 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 Sep 07 15:07:57 yeah, pam / ldap Sep 07 15:08:17 DocScrutinizer05: usually you're configured to login as the `git` user Sep 07 15:08:24 (or in hg the `hg` user) Sep 07 15:08:47 well, nevertheless git is greeting you with your name when you simply ssh git@foo.bar Sep 07 15:08:50 but the way those usually work is that there's essentially only one `user` and each authorized_key line has a `command` Sep 07 15:09:07 yeah, so, that's all through the magic of `command=...` Sep 07 15:09:14 yep Sep 07 15:09:15 * timeless has a whole bunch of `command=` things Sep 07 15:09:34 basically that can set the "user" for the program Sep 07 15:09:44 so it can greet you / know to do things as "you" Sep 07 15:10:34 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 Sep 07 15:10:58 https://serverfault.com/questions/162238/openssh-with-public-keys-from-database Sep 07 15:11:02 AuthorizedKeysCommand Sep 07 15:11:05 AuthorizedKeysCommandRunAs Sep 07 15:11:32 those look promising :) Sep 07 15:11:48 *cough* Sep 07 15:11:56 but yeah, prolly that's it Sep 07 15:12:31 https://github.com/blog/530-how-we-made-github-fast Sep 07 15:12:35 apparently not :o Sep 07 15:18:47 github my ass Sep 07 15:29:41 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? Sep 07 15:30:28 theere must be sth magic going on behind the scenes, in ssh protocol Sep 07 15:30:54 it doesn't need to know Sep 07 15:30:59 and there is no magic Sep 07 15:31:32 ssh (client) uses the specified (or default) key Sep 07 15:31:36 and ... that's it Sep 07 15:31:42 err it doesn't need to know which of a 100 pubkeys to use to verify the authentication request? Sep 07 15:31:48 no Sep 07 15:32:08 it only needs to check that submitted pubkey is indeed present Sep 07 15:32:18 that sounds like a communication problem between you and me Sep 07 15:32:29 DocScrutinizer05: then I repeat, 18:31 < bencoh> ssh (client) uses the specified (or default) key Sep 07 15:32:44 the fact that you think it doesn't is the issue :) Sep 07 15:32:51 huh? Sep 07 15:33:16 client decides whether to use and supply a pubkey Sep 07 15:33:19 please explain me what I think, I fail to understand what I'm supposed to be thinking Sep 07 15:33:28 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? Sep 07 15:33:36 I'm only referring to this Sep 07 15:33:40 and this very question is wrong Sep 07 15:33:50 and what did I say I'm thinking there? Sep 07 15:34:04 that sshd should somehow know which key to use Sep 07 15:34:39 which doesn't really makes sense in my opinion Sep 07 15:34:58 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 Sep 07 15:35:16 sshd doesn't get to choose Sep 07 15:35:27 client supplies a pubkey Sep 07 15:35:28 since sshd MUST use a particular key in azthoirzed_keys, that's why they exist Sep 07 15:35:35 sshd checks whether it matches any in the list Sep 07 15:35:42 no, it doesn't Sep 07 15:35:47 so there you have it Sep 07 15:36:01 it gets told which key to use Sep 07 15:36:06 by client, yes Sep 07 15:36:11 18:31 < bencoh> ssh (client) uses the specified (or default) key Sep 07 15:36:12 :) Sep 07 15:36:31 >>ssh (client) uses the specified (or default) key<< is very fuzzy Sep 07 15:36:37 mybad then :) Sep 07 15:37:20 also my question wasn't about client but about server Sep 07 15:37:54 I know which private key the client uses Sep 07 15:38:31 but obviously it needs to tell server about which pubkey to use Sep 07 15:38:37 that's true, yes Sep 07 15:38:42 s/true/exact/ Sep 07 15:38:43 bencoh meant: that's exact, yes Sep 07 15:40:44 so now we're talking. How is the pubkey to use getting identified / referred to, in the communication from client to server? Sep 07 15:41:27 "identified"? Sep 07 15:41:34 I guess not by transferring it a second time, since the client has no access or knowledge about the pubkey Sep 07 15:41:35 it's simply sent from client to server Sep 07 15:41:46 err, it does Sep 07 15:41:56 client has both pubkey and privkey Sep 07 15:42:05 it has* Sep 07 15:42:22 only id privkey includes a pubkey version Sep 07 15:42:26 if* Sep 07 15:42:47 $ ls .ssh/id_rsa* Sep 07 15:42:47 .ssh/id_rsa .ssh/id_rsa.pub Sep 07 15:42:52 I'm only pointing to privjey in my ssh client command Sep 07 15:43:17 no? Sep 07 15:43:28 pointing to a key usually refers to a pair Sep 07 15:43:59 I even think you could set up a client by only providing the privkey file, the system never get to see the pubkey. Sep 07 15:45:14 Public keys can be (re)generated from private keys Sep 07 15:45:19 I've created key pairs for users, sent the privkey to user and the pubkey to server, neither knew of the other part Sep 07 15:45:59 https://askubuntu.com/questions/53553/how-do-i-retrieve-the-public-key-from-a-ssh-private-key Sep 07 15:46:05 timeless: then that's the solution, pretty much in line with my >>only if privkey includes a pubkey version<< Sep 07 15:47:05 https://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-and-connection-process Sep 07 15:47:08 so the sshd would only compare if the provided pubkey is already in authorized_keys ? Sep 07 15:47:13 exactly Sep 07 15:47:26 :-) Sep 07 15:47:55 sounds suboptimal but meh Sep 07 15:48:06 from above page https://www.irccloud.com/pastebin/3AYIJGSU Sep 07 15:48:23 I had thought the protocol would want to keep the pubkey also sort of non-public Sep 07 15:48:46 Nope, the public key is actively sent from client to server Sep 07 15:49:06 so isn't there an attack vector for MITM? Sep 07 15:49:16 If it isn't recognized, the server says "I don't know that one, try another" Sep 07 15:49:37 SSH starts by clients connecting to servers Sep 07 15:49:41 MITM would say "hey great that's a known key" while storing it ;-) Sep 07 15:49:43 Servers present their public keys Sep 07 15:50:05 If the client has a public key for the server and it doesn't match, the client screams Sep 07 15:50:21 The public key doesn't really do much Sep 07 15:50:25 we all seen that, yes :-D Sep 07 15:50:46 I'm about to trigger that for one of our systems... Sep 07 15:50:48 ok,, learned sth for today Sep 07 15:51:15 thanks! Sep 07 15:51:28 Anyway, the SSH model allows a client to offer key after key after key Sep 07 15:51:39 Usually after a certain number, the server gets annoyed Sep 07 15:51:48 hehehehe Sep 07 15:52:41 * timeless has triggered that... Sep 07 15:52:58 it's a tad weird an approach to not keep the actual pubkey out of the communication Sep 07 15:53:26 I had just send a hash over the pubkey Sep 07 15:53:41 if I were to design the protocol Sep 07 15:54:13 if I *had* to... Sep 07 15:54:15 there's no real reason not to send the pubkey Sep 07 15:54:53 it significantly complicates MITM attacks Sep 07 15:55:07 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 Sep 07 15:55:22 so you've already got that aspect covered Sep 07 15:55:25 yes, I know Sep 07 15:56:34 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? Sep 07 15:58:13 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 Sep 07 16:00:00 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'..." Sep 07 16:00:19 DocScrutinizer05: you're supposed to know the fingerprint Sep 07 16:00:24 and ssh displays it Sep 07 16:00:52 I don't see any valid reason why server would have your pubkey while you wouldn't have his Sep 07 16:00:56 where from would I possibly know the fingerprint of the host's identify key? Sep 07 16:01:33 ssh-keyscan from a trusted computer on a trusted network, for instance Sep 07 16:02:05 or by using sshfp and dnssec Sep 07 16:02:05 honestly not a single of my known_hosts seen any verification, I wouldn't even know how to do that Sep 07 16:03:19 I never seen a howto for server identity key verification Sep 07 16:03:45 or I forgot if I actually did Sep 07 16:05:27 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 Sep 07 16:05:48 :) Sep 07 16:07:35 I'm not sure but I doubt e.g. Hetzner gave me a fingerprint to verify against, when they sent me my server credentials Sep 07 16:09:12 neither would I know of maemo fingerprints being published anywhere Sep 07 16:11:50 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?" Sep 07 16:13:14 alas I don't know of any source for the key to add it to my known_hosts Sep 07 16:13:48 other than the just mentioned client based method Sep 07 16:16:32 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 Sep 07 16:16:55 ideally via email or other non-ssh based channel Sep 07 16:18:28 compare ZRTP where that "OOB" channel is voice that's hard to fake by a rogue software in a MITM Sep 07 16:19:20 ZRTP also doesn't share keys ever, making any MITM attack even harder Sep 07 16:20:54 iirc Sep 07 16:26:33 HMMMM http://man.openbsd.org/ssh-keyscan#SECURITY Sep 07 16:32:15 DocScrutinizer05: man ssh-keygen /fingerprint and see /etc/ssh* Sep 07 16:35:07 hmm, not sure what exactly you refer to Sep 07 16:35:34 to view fingerprints? Sep 07 16:36:12 yes Sep 07 16:37:06 ta Sep 07 16:44:00 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 Sep 07 16:46:43 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) Sep 07 16:47:25 s/ssh-copy-id command that /ssh-copy-id command to user per encrypted email that / Sep 07 16:47:25 DocScrutinizer05 meant: so an admin could send a ssh-copy-id command to user per encrypted email 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, o... Sep 07 16:48:45 that's basically reverse pubkey-is-secret aproach Sep 07 16:49:05 except that your pubkey is public Sep 07 16:49:11 not a psk Sep 07 16:49:38 well, I didn't say anything different Sep 07 16:50:35 it's just the fow of secret info is from admin to user instead of from user to admin (via providing the pubkey) Sep 07 16:51:27 the secret info are the parameters to ssh-copy-id-ng Sep 07 16:52:27 these could even include the fingerprint of server id key Sep 07 16:52:50 or already the key itself Sep 07 16:52:57 to add it to known hosts Sep 07 16:55:10 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 Sep 07 16:56:03 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. Sep 07 16:56:11 *note Sep 07 16:56:41 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 Sep 07 16:56:42 not to say that the whole maemo boot process is a total mess Sep 07 16:57:15 part of it is upstart, another part in /etc/Xsession.d scripts Sep 07 16:57:55 without an easy to be seen sequence Sep 07 16:58:03 if there is a sequence at all Sep 07 16:58:05 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 Sep 07 16:58:39 maemo-upstart is already nuked in the project I am participating in Sep 07 16:59:46 yeah, maemo compatibility is nuked in many aspects in that project, armhf only being an elephant to start with Sep 07 17:01:01 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 Sep 07 17:01:20 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 Sep 07 17:01:55 it is not mandated by devuan, that's for sure. It is mandated by the fact that maemo is horribly outdated Sep 07 17:02:45 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 Sep 07 17:02:45 so, without having the RnD size of ex-Nokia's, the only sane way I see is to reuse as much upstream as possible Sep 07 17:03:29 my take on that is to reuse as much *maemo* as possible Sep 07 17:03:45 sure Sep 07 17:03:52 but init system is not part of it Sep 07 17:04:18 which directly results in "don't change the init system just because we can" considerations Sep 07 17:04:54 the change is not because we can, but because we can;t reuse it without an effort that doesn worths it Sep 07 17:05:39 I don;t see the point spending 2 or 3 months porting maemo-upstart to upstream libs Sep 07 17:06:01 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 Sep 07 17:06:42 in devuan, right now I can choose between upstart and sysvinit Sep 07 17:06:52 all devuan upstream supports sysvinit as well right now, and will do so for a long time still Sep 07 17:07:29 sure, but maemo sysvinit scripts are not LSB compatible in their most Sep 07 17:07:46 so they just don;t get started Sep 07 17:07:55 the same goes for maemo upstart scripts Sep 07 17:08:37 sorry, I'm not feeling like discussing this any further, it doesn't seem tolead anywhere Sep 07 17:08:54 and we can;t just put maemo-upstart there, because upstream services are not compatible with it Sep 07 17:09:47 why not, you seem to know how it works? Sep 07 17:10:24 Maybe a hang over from original sysv nokia tablets that there are both? Sep 07 17:10:28 all this leads to is bitching and flamewares very much similar to those seen from systemd people against devuan Sep 07 17:11:20 and I'm not interested in this sort of battle Sep 07 17:12:12 sixwheeledbeast: can;t parse, sorry :) Sep 07 17:12:22 I won't convince anybody anyway, obviously. And I'm sick of taking insults when pointing at inconsistencies in other people's argumentation chains Sep 07 17:12:35 You say there are duplicate sysv and upstart scripts? Sep 07 17:12:51 DocScrutinizer05: hmm? I insulted you? Sep 07 17:12:51 DocScrutinizer05 Seen a mention of my name at 12.59 CEST. What did you mean? Sep 07 17:12:59 freemangordon: not you Sep 07 17:13:03 :-) Sep 07 17:13:06 sixwheeledbeast: yep, should be something like that Sep 07 17:13:24 DocScrutinizer05: then please, don;t put me in a group I don;t belong, ok Sep 07 17:13:48 Enrico_Menotti: never mind, I just referred to yur learning about why it's so complicated to implement proper phonecalls in linux Sep 07 17:13:54 even if we assume such a group exists Sep 07 17:14:04 freemangordon: sorry, wasn't my intention Sep 07 17:14:47 I didn't invent or refer to any groups either Sep 07 17:15:01 DocScrutinizer05 Ok. Sep 07 17:16:51 Is maemo-upstart hugely different from upstream, I wasn't aware, I suppose that is a valid point. Sep 07 17:17:07 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 Sep 07 17:26:34 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 Sep 07 17:26:35 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 Sep 07 17:28:24 after all Nokia engineers themselves for sure were interested in minimizing own workload by staying as close to upstream as possible Sep 07 17:29:25 you can tell from maemo being what it is, and not looking like android or whatever Sep 07 17:30:55 Nokia clearly had no agenda to buold walled gardens like pretty much all other smartphone OS developers like Goggle and Apple and younameit do Sep 07 17:31:26 at least not with maemo5, for HARM aka maemo6 things changed a bit Sep 07 17:31:47 If there is a huge amount of work you have to consider options and how best to use your time to reach the goal. Sep 07 17:32:21 how is that statement related, however true it may be? Sep 07 17:33:46 unless it'smeant as being supportive for Nokia engineers' motivation Sep 07 17:34:38 then yes, exactly this, so they didn't add changes from upstream for shits'n'giggles, they had no time for that Sep 07 17:36:22 any change that created differneces to upstream was clearly motivated by a factual need created by the usecase Sep 07 17:37:27 well, at least 95% were, I give then a 5% for ignorance or just "personal" or corporate-identity goals Sep 07 17:44:20 compare to Google what has like 98% corporate goals in android Sep 07 17:45:41 or RedHat that has 100% corporate goals as in masterplan, in pushing systemd avalanche Sep 07 19:14:11 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 Sep 07 19:14:12 all this, but no success yet. Sep 07 19:16:21 Enrico_Menotti: check for .git dirs (ls -a) Sep 07 19:16:54 DocScrutinizer05 No such dirs, already done that. Sep 07 19:17:29 Even tried, from /, ls -Ral|grep .git. I only find .git dirs related to old clones of other projects. Sep 07 19:17:33 what was your exactl git command? Sep 07 19:18:25 git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git. Sep 07 19:19:30 Enrico_Menotti: git will clean up if it fails Sep 07 19:20:22 Enrico_Menotti: du -h / | sort -h | less Sep 07 19:20:46 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. Sep 07 19:20:52 DocScrutinizer05 Ok, a minute. Sep 07 19:22:02 this will take longer than a minute to complete, on an old hardware Sep 07 19:22:15 :) Sep 07 19:22:38 anyway should help you spot the nasty space hogs Sep 07 19:23:28 use > to jump to end with hugest dirs, then b to page backwards Sep 07 19:24:10 don't press q or you start again ;-) Sep 07 19:29:01 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. Sep 07 19:29:38 DocScrutinizer05: funny question about `find(1)` Sep 07 19:30:34 consider: `find . -mtime 1`; `find . -mtime +1`; `find . -daystart -mtime +1` Sep 07 19:31:05 based on reading the `man 1 find` under the section for `-mtime`, would you expect `-daystart` to matter? Sep 07 19:31:14 any clue why "power off" button in system menu leads to "telinit 5" what is runlevel 5 on maemo? Sep 07 19:31:15 haha mtime, huge inbconsistency between manpages and implementations Sep 07 19:31:57 I would expect runlevel 0 Sep 07 19:31:57 to start with, you wonder if mtamine +1 means one day back or to the future Sep 07 19:32:47 * timeless nods Sep 07 19:32:53 find's syntax is insane Sep 07 19:33:06 and the various implementations of find make it even more exciting Sep 07 19:33:18 for simplicity, let's limit hell to gnu-find Sep 07 19:33:22 freemangordon: l5:5:wait:/etc/init.d/rc 5 Sep 07 19:33:54 l0:0:wait:/etc/init.d/minishutdown ;; l6:6:wait:/etc/init.d/minireboot Sep 07 19:34:13 DocScrutinizer05: anyway, my `man 1 find` man page for `-mtime` says ~see -atime for details~ ... but `-atime` doesn't mention `-daystart` which seems unfortunate Sep 07 19:34:21 hmm Sep 07 19:34:31 but then, as you mentioned already, maemo has maemopstart Sep 07 19:34:52 isn't that sysvint script? Sep 07 19:35:18 -daystart Sep 07 19:35:19 Measure times (for -amin, -atime, -cmin, -ctime, -mmin, and -mtime) from the beginning of today rather than from 24 hours ago. This option only affects tests which appear Sep 07 19:35:21 later on the command line. Sep 07 19:35:48 DocScrutinizer05: right... but... wouldn't it make sense for `atime` to mention `-daystart`? Sep 07 19:35:54 freemangordon: yes, rzc/inittab Sep 07 19:36:01 etc Sep 07 19:36:55 timeless: man pages are not always 100% comprehensive Sep 07 19:37:02 why the hell Nokia used runlevel 5 for shutdown?!? Sep 07 19:37:11 timeless: -daystart mentions atime Sep 07 19:37:12 that doesn;t make any sense Sep 07 19:37:12 DocScrutinizer05: just looking for support for filing a bug to improve it Sep 07 19:37:18 yes Sep 07 19:37:37 freemangordon: do they? Sep 07 19:37:39 it just seems silly that -mtime has a backreference to -atime, but -atime doesn't have a backreference to -daystart Sep 07 19:38:00 timeless: ack Sep 07 19:38:06 DocScrutinizer05: telinit 5 will power off the device Sep 07 19:38:28 iiuc Sep 07 19:38:30 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. Sep 07 19:40:09 DocScrutinizer05: sorry, my fault Sep 07 19:40:09 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 Sep 07 19:40:25 yeah, right, I misread what you posted Sep 07 19:41:03 I think dsme tries to enter act_dead mode through telinit 5 Sep 07 19:41:15 that sounds more like it Sep 07 19:42:52 but then this log https://pastebin.com/JqRHg5bb doesn;t make sense to me Sep 07 19:44:02 esp those 2 "go to actdead via reboot" and "Issuing telinit 5" Sep 07 19:44:35 sorry, no clue, bever looked into it Sep 07 19:44:47 Pali: any idea ^^^ ? Sep 07 19:45:49 might well be maemopstart mess Sep 07 19:46:08 I suggest having a look into sbin/preinit Sep 07 19:48:10 freemangordon: http://paste.ubuntu.com/25485776 Sep 07 19:49:26 no idea about runlevels Sep 07 19:49:34 every linux distro uses own scheme Sep 07 19:49:48 and maemo is doubleplusweird Sep 07 19:50:05 I would not be surprised if some RHEL would use runlevel 4 for shutdown Sep 07 19:50:34 why not runlevel 9 ? ;-D Sep 07 19:50:50 great! in that script enter_state is nice mapping Sep 07 19:51:06 Pali: no, the question is why dsme issues telinit 5 for rebooting to act_dead Sep 07 19:51:26 in inittab it is "l5:5:wait:/etc/init.d/rc 5" Sep 07 19:51:57 maybe because of some charger problem? Sep 07 19:52:20 hmmm.... right... I remember one problem with kernel-power in qemu emulator Sep 07 19:52:52 Pali: well, this is VMWare running maemo perted over devuan, for sure thre is a problem with the charger :D Sep 07 19:52:57 *ported Sep 07 19:52:59 when I turned off Maemo via power button under normal stock kernel in qemu, then it was correctly turned off Sep 07 19:53:21 and when I used same setup, just with kernel-power then it always go to actdead Sep 07 19:53:26 rebooted to nolo Sep 07 19:53:31 and then nolo turned it off Sep 07 19:53:44 yeah, seem same for some time Sep 07 19:53:48 but telinit 5 should not reboot it Sep 07 19:54:02 and it is possible that similar problem is also on real n900 device with kernel-power Sep 07 19:54:22 so maybe it is mce/dsme problem that it does not detect something related to charger correctly? Sep 07 19:54:36 in kernel-power there is bme replacement Sep 07 19:54:43 and nokia's bme daemon is not used Sep 07 19:54:47 :-D see my pastebin above, getbootstate Sep 07 19:54:57 so maybe because of this dsme/mce can be confused, Sep 07 19:54:58 ? Sep 07 19:55:05 yes Sep 07 19:55:22 detecting charger is tricky Sep 07 19:55:27 very tricky Sep 07 19:55:31 I know Sep 07 19:55:48 in kernel there is a hack for it Sep 07 19:55:53 anyway sorry, I'm out. Busy Sep 07 19:55:53 and glue code between 3 layers Sep 07 19:56:08 * freemangordon is going to issue telnint 5 on the device to see what will happen Sep 07 19:57:06 freemangordon: see dsme/modules/state.c Sep 07 19:57:29 that would happen when CHARGER_STATE_UNKNOWN Sep 07 19:57:41 function select_state Sep 07 19:58:32 start on line 182 Sep 07 19:58:32 hehe: DSME_RUNLEVEL_ACTDEAD = 5 Sep 07 19:58:44 ok, so runlevel 5 is actdead :D Sep 07 19:58:49 yes Sep 07 19:59:12 I guess I should stop hildon-desktop and whatnot on that runlevel, right? Sep 07 20:00:08 Pali: btw https://github.com/fremantle-gtk2/mce/blob/gtk2/modules/battery-upower.c Sep 07 20:00:08 you're trying to re-implement act_dead? prolyl not worth the effort Sep 07 20:00:15 prolly* Sep 07 20:00:32 looks like it works, though it is yet to be tested on a device Sep 07 20:00:59 act_dead is mainly meeded for BME/charging Sep 07 20:01:24 so unless you plan to also implement that, you may forget about ACT_DEAD Sep 07 20:02:00 yes, I plan to implement act_dead Sep 07 20:02:10 remember, port whatever possible :) Sep 07 20:02:23 and if you actually plan to reimplement that whole mess, please accept my condolences. It's probably very frustrating Sep 07 20:03:09 even Nokia took literally years to finally debug it so it worked as supposed Sep 07 20:03:17 looks like if you start dsme, its charger state is in CHARGER_STATE_UNKNOWN Sep 07 20:03:24 the result is the very mess you just discovered Sep 07 20:03:39 and when you request shutdown or reboot when in CHARGER_STATE_UNKNOWN, then you enter into actdead mode Sep 07 20:04:09 yeah Sep 07 20:04:25 * DocScrutinizer05 shudders figuring the state diagram Sep 07 20:04:28 so if you do not setup charger after starting dsme, you alvways get runlevel 5 Sep 07 20:04:34 I see Sep 07 20:04:52 in dsme is "batttest" program Sep 07 20:05:00 which can be used to change charger state Sep 07 20:05:26 run it with -c 0 Sep 07 20:05:32 (charger disconnected) Sep 07 20:05:37 and then it should work Sep 07 20:05:40 ok, seems I should tweak hildon-desktop and other init scripts to stop on runlevel 5 Sep 07 20:06:24 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 Sep 07 20:06:40 no, unfortunately it is not Sep 07 20:07:05 if I do that, the whole devuan stuff in means of services will become useless Sep 07 20:07:36 Pali: but, do you have idea who is supposed to reboot then? Sep 07 20:07:56 * freemangordon checks runlevel 5 services on n900 Sep 07 20:07:58 errr I do not understand question Sep 07 20:08:08 see pastebin ^^^ Sep 07 20:08:33 "go to actdead via reboot" Sep 07 20:08:48 and what is the problem? Sep 07 20:08:57 who is doing that reboot? Sep 07 20:10:47 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 Sep 07 20:10:55 so DSME issued that reboot Sep 07 20:11:22 yes, that's what i'd think too Sep 07 20:11:42 it either started reboot script (which just send signal to upstart to do REAL reboot) or tell it to upstart directly Sep 07 20:11:42 yes, this is what happens Sep 07 20:11:50 but at the end dsme issues telinit 5 Sep 07 20:12:01 and expect device to reboot Sep 07 20:12:19 and? Sep 07 20:12:33 I *think* (rather suspect) that dsme talks directly to kernel Sep 07 20:12:44 I don't see who is rebooting on runlevel 5 Sep 07 20:12:52 nope, reboot/shutdown is done by upstart for sure Sep 07 20:12:57 mhm Sep 07 20:13:03 then /sbin/init Sep 07 20:13:12 so upstart Sep 07 20:13:20 yes, but how? Sep 07 20:13:22 but finally always it's kernel to shut down system Sep 07 20:13:47 yes, but after upstart kill all services, start all "on shutdown scripts" Sep 07 20:13:49 etc... Sep 07 20:14:02 upstart will then issue kernel syscall for shutdown Sep 07 20:14:24 upstart is pid 1 daemon which listen for signals and also for commands from socket Sep 07 20:14:34 and there is upstart client, named telinit Sep 07 20:14:37 isn't it like kernel executes shutdown when pid1 terminates? Sep 07 20:14:44 no Sep 07 20:14:53 when pid1 terminates, then kernel panic! Sep 07 20:14:57 it will just panic afaik Sep 07 20:15:00 ouch :-D Sep 07 20:15:28 somebody must issue reboot syscall and pid1 needs to be still alive Sep 07 20:15:59 killing pid 1 with SIGKILL would also lead to kernel panic :-) Sep 07 20:17:23 echo "off" >/err/powerwhatever ? Sep 07 20:17:29 ok, found it Sep 07 20:17:40 telinit on maemo is a script Sep 07 20:17:53 LOL Sep 07 20:18:00 which does /etc/init.d/minireboot in runlevel 5 Sep 07 20:18:07 *on Sep 07 20:18:09 sbin/init is 104kB ELF Sep 07 20:18:21 init != telinit Sep 07 20:18:24 yes, it is upstart Sep 07 20:18:28 yes, thus LOL Sep 07 20:18:46 telinit is upstart client Sep 07 20:18:57 init is upstart daemon (pid1) Sep 07 20:18:58 in former good ole' times telinit was a symlink to init Sep 07 20:19:04 or even a hardlink Sep 07 20:19:48 maybe it can be implemented based on argv[0] also today... Sep 07 20:19:55 ok, mystery revealed, now, how to fix that Sep 07 20:19:57 or based on getpid() Sep 07 20:20:17 that's how telinit/init does it Sep 07 20:20:30 maybe put some act_dead upstart service that does what telinit 5 in maemo does Sep 07 20:20:43 getpid()!=0 -> I'm telinit Sep 07 20:20:51 and what do you want to achieve? Sep 07 20:21:03 going to actdead on telinit 5 Sep 07 20:21:16 and what does actdead mean for you? Sep 07 20:21:18 define ACT_DEAD ;-) Sep 07 20:21:54 see in /etx/X11/Xsession.actdead Sep 07 20:22:09 because in maemo it is runlevel in which nothing is running, just bme daemon + some led pattern Sep 07 20:22:16 Pali: not sure I understand your question Sep 07 20:22:18 yep Sep 07 20:22:20 yes Sep 07 20:22:39 so you want to have also own actdead-like runlevel in devuan? Sep 07 20:22:46 sure, why not? Sep 07 20:22:48 though you *could* even run WLAN in ACT_DEAD X-P Sep 07 20:23:10 there's a config in iirc mce/config Sep 07 20:23:12 I'm asking what does that actdead mean for you... Sep 07 20:23:18 as in maemo it is special system runlevel Sep 07 20:23:19 what you explained Sep 07 20:23:24 yes, I know Sep 07 20:23:26 devuan uses that runlevel for different thing Sep 07 20:23:33 so there cannot be 1:1 mapping Sep 07 20:23:43 I don't think anything besides 0,1,2 and 6 is used Sep 07 20:23:54 errr Sep 07 20:24:03 yes, there are used Sep 07 20:24:10 what for? Sep 07 20:24:19 they are same Sep 07 20:24:23 do same thing Sep 07 20:24:38 2-5? sure, but I can redefine those Sep 07 20:24:53 hmmm https://wiki.debian.org/RunLevel Sep 07 20:24:54 but then you need to redefine all, I mean all, scripts from all deb packages Sep 07 20:25:05 basically all daemons starts in those 2-5 runlevels Sep 07 20:25:32 no, I will just disable services that are not needed, for example when maemo-system-services package gets installed Sep 07 20:25:38 it is impossible to create in debian e.g. runlevel 5 in which only one daemon would run (fake-bme) Sep 07 20:25:57 why not? Sep 07 20:25:59 but those services are provided in different deb packages Sep 07 20:26:13 anyway, have fun! :-) I'm off Sep 07 20:26:22 oh, I meant - disable them gracefully Sep 07 20:26:26 are you going to edit every one deb package and change it to stop own service in runlevel 5? Sep 07 20:26:30 no, no Sep 07 20:26:47 you cannot do it in other way, you need to edit header of init script Sep 07 20:26:57 in which is writting for which runlevels it should start Sep 07 20:27:03 and for each it should stop Sep 07 20:27:23 init scripts are distro specific. My point Sep 07 20:27:26 fur upstart, I can disable a job with a command, the same goes for sysvinit Sep 07 20:27:33 *for Sep 07 20:27:47 look e.g. at lightdm Sep 07 20:28:05 in /etc/init.d/lightdm is: Sep 07 20:28:05 # Default-Start: 2 3 4 5 Sep 07 20:28:05 # Default-Stop: 0 1 6 Sep 07 20:28:12 Pali: I understand what you mean, just truing to tell you there is a way Sep 07 20:28:17 this is the defaults Sep 07 20:28:43 yes, defaults, configured when installing/upgrading Sep 07 20:28:58 you can overwrite defaults after installing deb package Sep 07 20:29:39 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. Sep 07 20:30:01 Pali: update-rc.d Sep 07 20:30:37 yes, but that is for updating *existing* init script *after* installation of deb package Sep 07 20:31:08 it is for case admin want to change own script's runlevel after installation Sep 07 20:31:24 and it is normal that admin would make some temporary changes Sep 07 20:31:34 and then reset serttings to *defaults* Sep 07 20:31:45 Pali: yes, but one can put a trigger in debconf (or whatever it is called) Sep 07 20:32:02 and check what is enabled after avaery installed .deb Sep 07 20:32:05 *every Sep 07 20:32:08 I would be angry if somebody break update-rc.d defauls! Sep 07 20:32:36 Pali: ok, I don't want to make you angry, then we might invent another runleve, like 7 Sep 07 20:32:52 8 is already used for MALF in maemo :) Sep 07 20:33:04 creating a new runlevel is PITA too Sep 07 20:33:09 too late, runlevels 7 to 9 already exist :-) Sep 07 20:33:22 Pali: also, we're talking maemo here, not devuan running on a server Sep 07 20:33:26 as scripts do not have confiugured to stop in new invented runlevels Sep 07 20:33:48 and do not forget that scripts/daemons have its own shutdown procedure in init files Sep 07 20:34:01 actually it is "stop on runlevel [!2345]" Sep 07 20:34:03 which is sometimes needed and simple kill -9 would cause problems Sep 07 20:34:15 e.g. udev Sep 07 20:34:38 Pali: ok, got it, what you suggest then Sep 07 20:34:40 "stop on runlevel [!2345]" is better, but that is upstart right? Sep 07 20:34:46 right Sep 07 20:34:56 I'm thinging about better solution.... Sep 07 20:35:12 get your distro specific init Sep 07 20:35:18 ok, I am all ears... well, eyes :) Sep 07 20:35:46 init is one of the major distro specific config topics Sep 07 20:35:48 DocScrutinizer05: for the Nth time - it will break all upstream services Sep 07 20:36:09 no Sep 07 20:36:26 cannot be runlevel 1 modified for it? Sep 07 20:36:33 devuan gets their own init config and it doesn't break debian upstream Sep 07 20:36:37 in 1 running small number of services Sep 07 20:36:49 yes, it will, as maemo-upstart looks in /etc/event.d , not in /etc/init Sep 07 20:37:04 every distro has their own init config Sep 07 20:37:06 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 Sep 07 20:37:09 Pali: single user for battery charging. why not Sep 07 20:37:10 or just actdead Sep 07 20:37:50 actually everything under /etc is highly proprietary to the particular distro Sep 07 20:38:40 Pali: ok, sounds like a plan Sep 07 20:38:49 but what about MALF? Sep 07 20:39:00 or use 1 as well Sep 07 20:39:02 also 1? Sep 07 20:39:17 systemd is forcing pan-distro uniformity, anot the least by moving init config to /usr/ Sep 07 20:39:33 you can create some file in /run to check if current state is actdead or malf Sep 07 20:39:47 if e.g. some dsme/mce/bme needs to know this fact Sep 07 20:39:53 it is already created, /var/dsme/saved_state or something Sep 07 20:40:02 so better Sep 07 20:40:30 but then, who is going to do the "split"? Sep 07 20:40:39 and start the services? Sep 07 20:41:24 what are the drawbacks of runlevel 7 and 8? Sep 07 20:42:29 that not all services would be turned off Sep 07 20:42:46 but this is what we want actually Sep 07 20:43:23 you don;t need anything besides mce/dsme running, right? Sep 07 20:43:50 and this is needed only for fancy stuff like LEDs Sep 07 20:44:21 ah, wait Sep 07 20:44:29 not all will be off? Sep 07 20:44:51 so, if a runlevel is missing in LSB, the service will be started? Sep 07 20:45:01 LSB header that is Sep 07 20:45:21 yes, because if in init.d script is written to stop in 0, 1 and 6, then it would not be stopped in 7 Sep 07 20:45:41 if is missing, then service would not be started nor stopped Sep 07 20:45:49 but we're talking after reboot here Sep 07 20:45:51 so if is already running, then it stay running Sep 07 20:45:59 so nothing is started Sep 07 20:46:18 hmm, "init: illegal runlevel: 7" Sep 07 20:48:44 Pali: ok, please, think about that, I'll follow whatever you say here Sep 07 20:49:03 I don;t feel comfortable with those boot scripts anyway Sep 07 20:49:44 Pali: actually 1 in not single-user state Sep 07 20:49:57 is is 'S' or 's' Sep 07 20:53:54 read this: https://manpages.debian.org/stretch/sysvinit-core/init.8.en.html Sep 07 21:07:42 Pali: ok, read it. now, the main question remains - do we aim for sysvinit? Sep 07 21:08:15 or for upstart or for something else? Sep 07 21:08:33 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 Sep 07 21:08:38 init daemon is critical Sep 07 21:08:41 sure Sep 07 21:08:57 but devuan supports both upstart and sysvinit Sep 07 21:09:16 and parazyd said they will support openrc (or somesuch) soon Sep 07 21:09:21 if upstart is working, then you can choose upstart Sep 07 21:09:50 but I think everything (systemd, upstart, openrc...) would just use compatibility layer for sysv init scripts Sep 07 21:10:20 as debian daemon packages install maximally systemd units and sysvinit init.d scripts Sep 07 21:10:36 ok, I guess I can remove upstart scripts then Sep 07 21:10:56 an stay with sysvinit only Sep 07 21:11:16 however, this doesn's solve the runlevel issue Sep 07 21:11:27 so basically there would not be functional difference between upstart and sysvinit Sep 07 21:12:49 maybe... I would play with idea to drop both malf and actdead runlevel Sep 07 21:13:30 and if something like actdead is needed, then implement it in one of the early script, which would block whole booting? Sep 07 21:13:40 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 Sep 07 21:14:28 as I don;t see anybody changing the runlevel on n900 when it is in act_dead state Sep 07 21:15:08 Pali: look at what /sbin/telinit does Sep 07 21:17:57 it basically put the next state (if needed) in /var/lib/dsme/saved_state and then reboots or does shutdown Sep 07 21:18:02 *puts Sep 07 21:18:19 no runlevel change really Sep 07 21:18:52 maybe thoser runlevels are some remnants from maemo 4 Sep 07 21:44:51 https://www.nytimes.com/2017/09/07/business/equifax-cyberattack.html Sep 07 21:49:44 freemangordon: quite possible. there's a lot like this, in preinit, in NAND partitions (orphaned initfs), basically everywhere Sep 07 22:52:50 * timeless frowns Sep 07 22:52:58 so, `disown` is apparently bashis Sep 07 22:53:00 t Sep 07 23:07:40 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? Sep 07 23:09:10 (Anyway, now bedtime - I will read eventual comments tomorrow. Bye!) :) Sep 07 23:31:01 timeless: (bashism) yes, absolutely. `man disown` -> BASH_BUILTINS(1) Sep 07 23:31:20 * timeless gave up and used `screen` Sep 07 23:31:29 (which is what i would normally use anyway!) Sep 07 23:32:01 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` Sep 07 23:33:12 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) Sep 07 23:33:27 when it's down, a fallback vhost for the same domain points to static apache content :) Sep 07 23:33:48 but... the trick was running this from a calling script and being able to continue doing other things while that waited Sep 07 23:34:08 screen -S waitfortomcat -d -m ~/bin/connect-tomcat Sep 07 23:34:20 * timeless has never used `-m` before Sep 07 23:42:09 други никто n900 не продает? Sep 07 23:43:04 never had the idea to use `screen` in scripts Sep 07 23:43:24 someone had a thing describing how to use screen to debug cron jobs Sep 07 23:44:09 but i can't find that today Sep 07 23:45:19 for parallelism in shellscripts I jave a disgusting example (made by me a maybe 10 years ago): http://termbin.com/gmrp Sep 07 23:49:16 pretty fancy Sep 07 23:49:28 * timeless read it once but doesn't have the stomach for pieces of it Sep 07 23:59:34 * timeless sighs https://www.irccloud.com/pastebin/yRdzZNCZ/ Sep 08 00:02:20 * timeless sighs Sep 08 00:02:35 my "failover" mail server has 1/2 the ram of the supposed "primary" mail server Sep 08 00:02:42 (i've been failed over to the failover for months) Sep 08 00:03:24 lol, "don't use >5!" OK, 25 then Sep 08 00:03:42 ~5! Sep 08 00:03:43 somebody said 5! was 120 Sep 08 00:15:01 DocScrutinizer05: my thoughts exactly Sep 08 00:15:14 * timeless moved it to 30 Sep 08 00:16:11 May 4 09:35:22 mail spamd[21809]: prefork: server reached --max-children setting, consider raising it Sep 08 00:16:19 indeed, i am hitting that limit Sep 08 00:17:28 err, not "hitting it" so much as pounding against it Sep 08 00:42:15 well, aiui it's a question of parallelizing spam filtering. I don't see why this needs any particular number of preforked processes, except for performance optimization. when there are >25 concurrent inbound mails, they will need to get processed in a serialized way, which is what my system's spamd does anyway Sep 08 00:44:33 I'd think "hitting the `limit´ " is pretty normal for this sort of things Sep 08 00:45:12 actaully _not_ hitting the limit ever would raise concerns Sep 08 00:50:31 it's not like infinite number of child processes would boost system performance to infinity too. Rather the system eventually hits other limits and a 50 processes that tun from swap are for sure several magnitudes slower than a 25 processes filtering same amount of data in a serialized way within RAM rather than spinning circles in swap hell Sep 08 00:51:13 s/ tun/ run/ Sep 08 00:51:13 DocScrutinizer05 meant: it's not like infinite number of child processes would boost system performance to infinity too. Rather the system eventually hits other limits and a 50 processes that run from swap are for sure several magnitudes slower than a 25 processes filtering same... Sep 08 01:13:25 timeless: however I noticed spamd getting incredibly slow during last maybe 12 to 24 months, must be something about internet connections to servers with spam blacklists or whatever Sep 08 01:15:24 maybe investigating what exactly is going on, and possibly setting up a transparent proxy or (if spamassassin supports that) a local database cache, might be worth it when you run a system where you need >25 concurrent instances to process all your inbound mail Sep 08 01:18:22 as a ballpark figure reference, my spamd seems to take random amount of time between 0.5s and sometimes 20s for filtering one email. A 2 or 3 years ago I witnessed it filtering a maybe 20 mails per second, sustainably Sep 08 01:19:07 I'm running one spamd instance Sep 08 01:52:14 * DocScrutinizer05 might try to find out about spamd's internet activities from firewall/NAT logs **** ENDING LOGGING AT Fri Sep 08 02:59:59 2017