**** BEGIN LOGGING AT Wed Jan 15 02:59:57 2020
Jan 15 11:58:34 * enyc meows
Jan 15 12:18:55 * badcloud_ opens a tin of tuna
Jan 15 14:16:53 <badcloud_> I tried making a desktop file for osso-xterm which would run bash. "Exec=/usr/bin/osso-xterm -e bash" didn't work, even though running that command from osso-xterm brings up a new window with bash
Jan 15 14:17:40 <badcloud_> Is there any way to have a hildon menu entry which launches osso-xterm with bash?
Jan 15 14:18:00 <badcloud_> Instead of ash
Jan 15 14:18:18 <badcloud_> I don't want to change default shell in /etc/passwd
Jan 15 14:18:43 <badcloud_> Just have a separate entry in hildon
Jan 15 14:19:51 <KotCzarny> make a script?
Jan 15 14:21:00 <badcloud_> Sure, why not
Jan 15 14:39:45 <badcloud_> It seems to work only when running the script within an existing osso-xterm window
Jan 15 14:40:54 <badcloud_> I tried /usr/bin/maemo-summoner /usr/bin/osso-xterm.launch -e bash
Jan 15 15:00:57 <bencoh> badcloud_: try adding Terminal=true
Jan 15 15:04:37 <badcloud_> Nope, it just quits after opening an osso-xterm window, thinking a lot (spinning animation) and then quitting
Jan 15 15:15:39 <badcloud_> Why's it gotta be so convoluted, Nokia??
Jan 15 15:15:51 * badcloud_ shakes fists at the air
Jan 15 15:16:28 <KotCzarny> i think its not nokia, that whole app bussiness was earlier
Jan 15 15:17:29 <badcloud_> Gotcha
Jan 15 15:19:31 <halftux> badcloud_: try this Exec=/usr/bin/osso-xterm 'bash'
Jan 15 15:20:09 <KotCzarny> umm
Jan 15 15:20:14 <KotCzarny> shouldnt it be full path?
Jan 15 15:20:21 <KotCzarny> ie. /usr/bin/bash or whatever?
Jan 15 15:20:39 <KotCzarny> since bash is not officially installed, check where it is
Jan 15 15:22:51 <halftux> could be that a full path is needed, but remove the -e and put it in inverted commas
Jan 15 15:25:27 <badcloud_> which bash gave me /bin/bash
Jan 15 15:25:49 <badcloud_> I tried inverted commas
Jan 15 15:26:19 <badcloud_> How is leste in this regard, easier to customize?
Jan 15 15:27:37 <halftux> which bash version you have installed?
Jan 15 15:27:53 <badcloud_> 4
Jan 15 15:28:42 <badcloud_> Bear in mind that when I run any variant of the Exec value in an existing xterm window, works fine
Jan 15 15:29:13 <badcloud_> osso-xterm -e bash works
Jan 15 15:29:33 <badcloud_> osso-xterm bash does too
Jan 15 15:30:36 <badcloud_> So does '/usr/bin/maemo-summoner /usr/bin/osso-xterm.launch  -e bash'
Jan 15 15:30:51 <badcloud_> It's only from the hildon menu that things go south
Jan 15 15:30:54 <KotCzarny> full path?
Jan 15 15:32:05 <badcloud_> Yup
Jan 15 15:33:10 <badcloud_> Exec=/usr/bin/osso-xterm -e `/bin/bash/` was my last attempt
Jan 15 15:33:18 <KotCzarny> um
Jan 15 15:33:20 <badcloud_> using inverted commas
Jan 15 15:33:24 <KotCzarny>  /bin/bash ?
Jan 15 15:33:31 <KotCzarny> and drop backticks
Jan 15 15:34:29 <badcloud_> Yes, /bin/bash is where bash is
Jan 15 15:34:35 <badcloud_> Still nothing
Jan 15 15:37:21 <badcloud_> Please tell me that leste is easier to configure
Jan 15 15:37:47 <KotCzarny> i strongly suspect what are you trying to achieve is doable, just some stupid typo somewhere
Jan 15 15:38:35 <badcloud_> I'll post my .desktop file later when I get a chance
Jan 15 15:39:05 <badcloud_> Ciao for now
Jan 15 15:39:10 <KotCzarny> :)
Jan 15 16:37:48 <halftux> Pali: Hello Pali I have a question regarding 0xFFFF and the dump fiasco option. First I getting initfs_tmp is empty, removing it. And later Error: Cannot open image file initfs_tmp: No such file. However I get a fiasco file is it save to flash it? Can I ignore this message?
Jan 15 16:38:22 <Pali> hello
Jan 15 16:38:35 <Pali> can you please post full log?
Jan 15 16:39:38 <halftux> is there a log option or should I redirect the output to > log.txt
Jan 15 16:39:46 <Pali> record
Jan 15 16:39:51 <Pali> or post output from terminal
Jan 15 16:50:57 <halftux> ok I will do it later still at work
Jan 15 17:03:22 <badcloud_> https://pastebin.com/nSyjdui5
Jan 15 17:03:38 <badcloud_> ^ the osso-xterm bash desktop file
Jan 15 18:08:57 <halftux> badcloud_: it is a bit tricky with bash but it works
Jan 15 18:09:41 <halftux> make sure in desktop file there is no line X-Osso-Service=xterm
Jan 15 18:10:27 <halftux> Exec=/usr/bin/osso-xterm '/opt/bash.sh'
Jan 15 18:13:02 <halftux> bash script: #!/bin/sh [newline] sleep 2 [newline] /usr/bin/osso-xterm '/bin/bash' [newline] return
Jan 15 18:14:52 <halftux> thats it
Jan 15 18:17:40 <badcloud_> Wow, bravo
Jan 15 18:18:55 <badcloud_> Thanks :)
Jan 15 18:19:01 <halftux> np
Jan 15 18:20:16 <halftux> going offline will be back later if you still facing a problem with it
Jan 15 18:20:29 <KotCzarny> you exec osso-xterm twice
Jan 15 18:20:44 <halftux> yes and with return I close the first one
Jan 15 18:20:51 <KotCzarny> why not just make it /bin/sh /yourscript ?
Jan 15 18:22:01 <KotCzarny> anyway, as long it works..
Jan 15 18:22:17 <halftux> lol yeah should also work thinking to complicated sometimes
Jan 15 18:23:01 <halftux> cya later
Jan 15 18:48:42 <DocScrutinizer05> https://www.youtube.com/watch?v=ZBq7VMIkgPk
Jan 15 18:49:00 <DocScrutinizer05> TLBLEED
Jan 15 18:59:36 <DocScrutinizer05> sorry, not exactly news
Jan 15 19:01:42 <DocScrutinizer05> badcloud_: >>Terminal=false<< HMMM??
Jan 15 19:02:26 <badcloud_> I tried it with true as well
Jan 15 19:02:51 <badcloud_> halftux's script did the trick though
Jan 15 19:12:01 <DocScrutinizer05> this works for a script for me https://termbin.com/hgh7
Jan 15 19:12:22 <DocScrutinizer05> not bash though
Jan 15 19:12:33 <DocScrutinizer05> I wonder if bash is special
Jan 15 19:16:20 <badcloud_> Thanks
Jan 15 19:38:55 <DocScrutinizer05> could you try echo "/bin/bash" >>/etc/shells; ?
Jan 15 19:39:48 <DocScrutinizer05> sorry when I'm a tad lazy trying that on my own phone
Jan 15 19:40:12 <DocScrutinizer05> since I already got this and possibly other mods already
Jan 15 19:41:07 <DocScrutinizer05> changing login shell on etc/passwd is strongly deprecated, it may result in system boot failure
Jan 15 19:42:08 <DocScrutinizer05> thanks to subtle differences between bash and messybox which are relied upon in startup scripts
Jan 15 19:45:24 <DocScrutinizer05> man 5 shells  >>/etc/shells is a text file which contains the full pathnames of valid login shells<<
Jan 15 19:46:18 <DocScrutinizer05> good question if starting an xterm would invoke a *login* shell
Jan 15 19:48:47 <DocScrutinizer05> though  >>Be  aware  that  there are programs which consult this file to find out if a user is a normal user; for example, FTP daemons traditionally disallow access to users with shells not included in this file.<<
Jan 15 19:49:44 <DocScrutinizer05> your description of what works and what doesn't sounds much like a specific login shell problem
Jan 15 19:53:52 <Maxdamantus> I just have my shell set to /bin/bash .. should be able to do something like `chsh -s /bin/bash`
Jan 15 20:00:32 <DocScrutinizer05> >>On OSX, by default, the Terminal application runs a login shell. (As I explain, the program that starts the shell decides whether the shell acts as a login shell.) That's not the normal way to do things. <<  https://unix.stackexchange.com/questions/38175/difference-between-login-shell-and-non-login-shell
Jan 15 20:02:45 <Maxdamantus> I think that's talking about a different meaning of "login shell". It's talking there about whether or not it passes `-l` to the shell.
Jan 15 20:03:06 <Maxdamantus> I think reading /etc/passwd to figure out what shell to use is a fairly standard behaviour for terminals. urxvt does it.
Jan 15 20:04:43 <Maxdamantus> A regular xterm (not osso) does it too.
Jan 15 20:05:03 <halftux> in principle no script is needed checked again the mistacke was only this line in the desktop file X-Osso-Service=xterm
Jan 15 20:05:24 <halftux> mistake
Jan 15 20:07:23 <halftux> badcloud_: only removing X-Osso-Service=xterm will solve the issue no other steps are needed
Jan 15 20:07:25 <DocScrutinizer05> though   man xterm >>-ls     This option indicates that the shell that is started in the xterm window will be a login shell (i.e., the first character of argv[0] will be a dash, indicating to the shell that it should read the user's .login or .profile).<< // man 5 shells  >>/etc/shells is a text file which contains the full pathnames of valid login shells<<
Jan 15 20:08:50 <DocScrutinizer05> X-Osso-Service=xterm  means: "send a dbus-msg to either start (if no instance is running) or bring to front and focus an already running instance of xterm" AFAIK
Jan 15 20:10:07 <DocScrutinizer05> obviously you need a different name for an xterm with different behavior than the one defined in dbus config
Jan 15 20:12:13 <badcloud_> Fixed the desktop file
Jan 15 20:15:33 <KotCzarny> see? i knew it was something trivial
Jan 15 20:15:35 <KotCzarny> :)
Jan 15 20:15:46 <halftux> :)
Jan 15 20:16:27 * DocScrutinizer05 still wonders if osso-xterm checks /etc/shells
Jan 15 20:16:54 <KotCzarny> osso-xterm runs user's shell then a command inside that shell
Jan 15 20:17:06 <DocScrutinizer05> err
Jan 15 20:17:12 <Maxdamantus> My N900 doesn't have an /etc/shells file
Jan 15 20:17:21 <DocScrutinizer05> this is an answer to my question?
Jan 15 20:18:02 <DocScrutinizer05> also doesn't seem correct
Jan 15 20:18:09 <Maxdamantus> I think /etc/shells is just something used by `chsh`, not the terminal/login mechanism.
Jan 15 20:18:23 <DocScrutinizer05>  xterm [-toolkitoption ...] [-option ...] [shell]
Jan 15 20:18:27 <Maxdamantus> that is, it should prevent people from putting non-standard shells into their line in /etc/passwd
Jan 15 20:19:12 <Maxdamantus> but obviously root can just edit the /etc/passwd file directly to avoid that limitation.
Jan 15 20:20:20 <DocScrutinizer05> quite possibly osso-xterm is a simplified generic xterm, it still may accept commands to run *instead* of shell rather than *in* shell
Jan 15 20:20:25 <Maxdamantus> man chsh >> The only restriction placed on the login shell is that the command name must be listed in /etc/shells, unless the invoker is the superuser, and then any value may be added.
Jan 15 21:20:19 <DocScrutinizer05> ayayayay https://termbin.com/jgm4
Jan 15 21:45:13 <halftux> looks ugly
Jan 15 22:12:27 <halftux> Pali: http://www.setius.net/downs/maemo/dump0.log
Jan 15 22:12:54 <Pali> what arguments have you used?
Jan 15 22:13:52 <halftux> 0xFFFF -E dump0.fiasco &> dump0.log
Jan 15 22:14:30 <Pali> seems that you have desynced stdout and stderr
Jan 15 22:14:39 <Pali> at first lines is stderr and then stdout
Jan 15 22:14:48 <Pali> but nevermind...
Jan 15 22:15:17 <Pali> "File initfs_tmp is empty, removing it..." --> this is OK, stock Maemo on N900 does not use initfs
Jan 15 22:15:22 <Pali> so it is empty
Jan 15 22:15:43 <halftux> great I know sdcard was to small with this attempt
Jan 15 22:16:10 <Pali> "Error: Not enough free space (have: 27616083968, need: 28995223552)" --> this is due to small SD card
Jan 15 22:16:18 <Pali> you cannot put dump of SD card to SD card
Jan 15 22:16:42 <Pali> "Error: Cannot open image file mmc_tmp: No such file or directory" --> this is just a reason for previous error
Jan 15 22:17:00 <Pali> "Error: Cannot open image file initfs_tmp: No such file or directory" --> ignore this, 0xFFFF should probably do not show such message
Jan 15 22:17:06 <halftux> I see I thought it is emmc
Jan 15 22:17:48 <Pali> yea, you are right, this is eMMC MyDocs, not SD card
Jan 15 22:18:10 <halftux> I needed to umount /home/usr/MyDocs
Jan 15 22:18:44 <halftux> and this whole image can be flashed back?
Jan 15 22:18:50 <halftux> with emmc?
Jan 15 22:18:58 <Pali> it is complicated
Jan 15 22:19:26 <Pali> \/opt is stored on second partition of eMMC and this stuff is not backed up
Jan 15 22:19:27 <halftux> why that it is a none working fiasco file?
Jan 15 22:19:43 <Pali> and this stuff cannot be even put into FIASCO image
Jan 15 22:19:59 <Pali> so there is no way for do whole backup+restore
Jan 15 22:20:26 <halftux> ah I see, is there a way to back it up seperatly und push it back?
Jan 15 22:20:43 <Pali> you can do backup of /opt manually
Jan 15 22:20:56 <DocScrutinizer05> halftux: -v for those who love ugly
Jan 15 22:20:56 <Pali> e.g. via unix dd
Jan 15 22:21:10 <Pali> restore is problematic
Jan 15 22:21:24 <Pali> without /opt Maemo system does not bootup
Jan 15 22:21:34 <halftux> rescue os?
Jan 15 22:21:36 <Pali> but there is a way, look at my "bootmenu"
Jan 15 22:21:37 <DocScrutinizer05> /usr/share/applications/hildon # update-desktop-database   
Jan 15 22:21:39 <DocScrutinizer05> /usr/share/applications/hildon # 
Jan 15 22:22:00 <Pali> it can export whole eMMC via USB prior to booting Maemo
Jan 15 22:22:20 <Pali> so if rootfs has installed bootmenu, and rootfs is in fiasco dump
Jan 15 22:22:38 <Pali> you would be able to restore rootfs, jump into bootmenu, export eMMC via USB
Jan 15 22:22:43 <Pali> and then restore /opt
Jan 15 22:23:06 <Pali> I do not know what is supported by backupmenu, but maybe something similar is possible
Jan 15 22:23:39 <halftux> ok I will have a look thank you for your explanation
Jan 15 22:23:46 <Pali> flashing MyDocs is problematic, IIRC it erases /opt
Jan 15 22:23:46 <DocScrutinizer05> well, technically I think you could put /home on FIASCO
Jan 15 22:24:07 <DocScrutinizer05> aka EMMC
Jan 15 22:24:18 <Pali> no, you cannot
Jan 15 22:24:31 <Pali> eMMC fiasco can contain only MyDocs part
Jan 15 22:24:37 <DocScrutinizer05> ooh
Jan 15 22:24:47 <Pali> part /home is IIRC maped to /opt
Jan 15 22:24:57 <Pali> it is on same partition
Jan 15 22:25:09 <Pali> there is symlink or bind mount or other technique
Jan 15 22:25:45 <Pali> but I do not remember all details, at least I was not able to put /opt or /home into fiasco image
Jan 15 22:26:03 <Pali> but that is not a final proof that it is impossible
Jan 15 22:26:54 <halftux> but it is interesting, is stock /opt empty?
Jan 15 22:27:53 <Pali> yes, stock /opt is empty, but stock rootfs has some init scripts which moves some parts from /usr to /opt
Jan 15 22:28:03 <DocScrutinizer05> basically yes, though root image runs optify
Jan 15 22:28:14 <Pali> init scripts which do that only on first boot of stock rootfs
Jan 15 22:28:16 <DocScrutinizer05> ~optification
Jan 15 22:28:17 <infobot> optification is a inventive duct tape workaround to reclaim space in fs root, done due to the fact the systeminit *and* partitioning is FUBAR,  http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Packaging,_Deploying_and_Distributing/Installing_under_opt_and_MyDocs, or ""OMG - I wish they looked into FHS and moved /usr to eMMC"", http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE2 bullet1,2 and fhs-2.3.html#PURPOSE16 dot3"
Jan 15 22:28:36 <Pali> and all maemo applications from extras install DEB packages to /opt
Jan 15 22:29:05 <DocScrutinizer05> hmm, I think they also run optify
Jan 15 22:29:23 <DocScrutinizer05> or at least that's one of the options
Jan 15 22:36:42 <DocScrutinizer05> https://termbin.com/ac0l
Jan 15 22:47:05 <DocScrutinizer05> https://termbin.com/dc19
Jan 15 22:47:36 <Pali> another problem of 0xFFFF is that it does not have implementation of flashing eMMC images (I had not time to finish it)
Jan 15 22:47:43 <halftux> Pali: when I using your fiasco for cloning N900 HW:2101 to N900 HW:2104 I need to extract the fiasco and correct the xloader.bin and nolo.bin?
Jan 15 22:49:41 <halftux> ah I see now your message that is sad I thought the original eMMC
Jan 15 22:49:55 <Pali> seems that 2101 and 2104 HW revs uses different bootloader
Jan 15 22:50:18 <Pali> Nokia's flasher-3.5 can flash eMMC images viac USB
Jan 15 22:50:27 <Pali> but 0xFFFF does not implement it
Jan 15 22:51:13 <Pali> anyway, here is a quick fix to hide those error messages about missing files: https://github.com/pali/0xFFFF/commit/e94279eecbfdd1988912ac7ce24e6d4d702695a1
Jan 15 22:51:23 <DocScrutinizer05> you generally shall not flash NOLO 
Jan 15 22:51:46 <Pali> that is truth, unless you have old version
Jan 15 22:52:30 <Pali> 0xFFFF has some filter argument to specify which image types from FIASCO images would be flashed
Jan 15 22:52:44 <Pali> so unpack & pack could be avoided
Jan 15 22:52:48 <halftux> ah ok thats something
Jan 15 22:52:49 <DocScrutinizer05> how could you? was NOLO ever updated? and if yes, what for?
Jan 15 22:53:05 <Pali> yes, PR1.3 has new version of NOLO as in PR1.0
Jan 15 22:53:24 <Pali> and IIRC Nokia distributed all devices with PR1.0 version
Jan 15 22:53:39 <DocScrutinizer05> wow
Jan 15 22:53:45 <DocScrutinizer05> forgot
Jan 15 22:53:58 <Pali> but if you are going to unpack FIASCO, do not forget about metadata
Jan 15 22:54:14 <Pali> so when building a new fiasco, do not forget for specififying image version and HW revision
Jan 15 22:54:29 <Pali> and type
Jan 15 22:55:03 <DocScrutinizer05> I actually wonder how Nokia made COMBINED that did not have optification already done on them
Jan 15 22:55:17 <halftux> what is image version?
Jan 15 22:56:35 <halftux> or better what does it mean in your example you have 1.0
Jan 15 22:56:38 <Pali> e.g. version of NOLO, version of kernel or version of rootfs
Jan 15 22:56:54 <Pali> use "-i" argument to show it
Jan 15 22:57:28 <halftux> ok thank you lots of input this evening :)
Jan 15 22:58:35 <Pali> there is an unfinished attempt for writing support for flashing eMMC images: https://github.com/pali/0xFFFF/issues/6
Jan 15 22:58:44 <Pali> if somebody want to finish it I can help
Jan 15 23:00:37 <halftux> hmm I will look if I am able to understand
**** ENDING LOGGING AT Thu Jan 16 02:59:59 2020