Porteus 3.2 and Firefox/Flashplayer problem

Please reproduce your error on a second machine before posting, and check the error by running without saved changes or extra modules (See FAQ No. 13, "How to report a bug"). For unstable Porteus versions (alpha, beta, rc) please use the relevant thread in our "Development" section.
User avatar
Ed_P
Contributor
Contributor
Posts: 3423
Joined: 06 Feb 2013, 22:12
Distribution: Cinnamon 3.2.2 64-bit ISO
Location: Western NY, USA

Re: Porteus 3.2 and Firefox/Flashplayer problem

Post#16 by Ed_P » 25 Nov 2016, 15:14

ncmprhnsbl wrote:deactivating a module shouldnt be creating them if theyre there ...
Well something is creating them. The problem IMO is either the deactivating of the module or the update-flash process.

Thanks ncmprhnsbl for helping to narrow down this bug. :beer:
Ed

User avatar
brokenman
Site Admin
Site Admin
Posts: 5659
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v3.2rcX all desktops
Location: Brazil
Contact:

Re: Porteus 3.2 and Firefox/Flashplayer problem

Post#17 by brokenman » 25 Nov 2016, 21:16

Can you please explain to me where the bug is? Obviously whiteouts are the culprit but I am lost as to where exactly they were and how they got there.

a) The update script doesn't create them.
b) Activating/deactiving a module doesn't create them.
How do i become super user?
Wear your underpants on the outside and put on a cape.

User avatar
Ed_P
Contributor
Contributor
Posts: 3423
Joined: 06 Feb 2013, 22:12
Distribution: Cinnamon 3.2.2 64-bit ISO
Location: Western NY, USA

Re: Porteus 3.2 and Firefox/Flashplayer problem

Post#18 by Ed_P » 25 Nov 2016, 23:10

brokenman wrote:Can you please explain to me where the bug is?
:) You think I know!! Based on my expert knowledge, somewhere in Porteus Cinnamon 3.2 final. :)
Obviously whiteouts are the culprit
I agree.
but I am lost as to where exactly they were
Where I can answer:
Ed_P wrote:

Code: Select all

root@porteus:/home/guest# rm /mnt/loop/usr/lib/.wh.kde4
root@porteus:/home/guest# rm /mnt/loop/usr/lib/.wh.mozilla
root@porteus:/home/guest# rm /mnt/loop/usr/lib64/.wh.kde4
root@porteus:/home/guest# rm /mnt/loop/usr/lib64/.wh.mozilla
root@porteus:/home/guest# rm /mnt/loop/usr/bin/.wh.flash-player-properties
root@porteus:/home/guest# rm /mnt/loop/var/log/scripts/.wh.flashplayer-plugin-23.0.0.162-x86_64-1
root@porteus:/home/guest# rm /mnt/loop/var/log/packages/.wh.flashplayer-plugin-23.0.0.162-x86_64-1
root@porteus:/home/guest# rm /mnt/loop/usr/share/.wh.kde4
root@porteus:/home/guest# rm /mnt/loop/usr/share/icons/hicolor/??x??/apps/.wh.flash-player-properties.png
root@porteus:/home/guest# rm /mnt/loop/usr/share/pixmaps/.wh.flash-player-properties.png

and how they got there.
That is indeed the question.

After reencountering the problem when I ran the update-flash update last night I shutdown the system without updating the changes= file. Which means the save.dat was still clean of the .wh. files I deleted earlier. When I rebooted today the updated flash module that I had copied to my Modules folder worked!! I have since rebooted updating my changes= file in the process and the rebooted system's updated plugin continues to work.
a) The update script doesn't create them.
b) Activating/deactiving a module doesn't create them.
Assuming shutting down with a changes= shortcut Porteus deactivates all modules before updating the changes= file that would indicate to me with my reboots that the deactivate function is not the problem. To me that implies the culprit is the update-flash function. If when shutting down Porteus doesn't deactivate all modules then to me that function is still possibly the culprit.


-update-

In that I updated flash yesterday the /usr/local/bin/ folder shows it with a date of Sep while firefox shows a date of Nov.

Code: Select all

guest@porteus:~$ ls -g /usr/local/bin/update-*
-rwxr-xr-x 1 root 40055 Nov  6 22:26 /usr/local/bin/update-firefox-live*
-rwxr-xr-x 1 root  5880 Sep  7 14:40 /usr/local/bin/update-flash-live*
guest@porteus:~$ 
Shouldn't it reflect the date it was run? :unknown:
Ed

User avatar
Ed_P
Contributor
Contributor
Posts: 3423
Joined: 06 Feb 2013, 22:12
Distribution: Cinnamon 3.2.2 64-bit ISO
Location: Western NY, USA

Re: Porteus 3.2 and Firefox/Flashplayer problem

Post#19 by Ed_P » 26 Nov 2016, 06:05

-update-

I booted 3.2 final, with the changes=EXIT code, I did not deactivate the flashplayer module, I did not run firefox, I ran the commands below.

Code: Select all

guest@porteus:~$ su
Password: 
root@porteus:/home/guest# find /mnt/live/memory/images/changes -name .wh.*
root@porteus:/home/guest# 

root@porteus:/home/guest# update-flash
[OK] User is root
[OK] Distro is Porteus
[OK] Flash is installed

[OK] Internet connection exists
Downloading live script ...
Downloading: update-flash-live  DONE

Searching online for latest flash player version ...

Installed version:	11.2.202.644
Latest version:		23.0.0.207

 Would you like to continue? [y/n]
 Would you like to create a Porteus module? [y/n]

Removing package /var/log/packages/flashplayer-plugin-23.0.0.207-x86_64-1...
Removing files:
  --> Deleting symlink /usr/lib/kde4/kcm_adobe_flash_player.so
  --> Deleting symlink /usr/lib64/mozilla
  --> Deleting symlink /usr/share/pixmaps/flash-player-properties.png
  --> /usr/share/applications/flash-player-properties.desktop was found in another package. Skipping.
  --> Deleting /usr/bin/flash-player-properties
  --> Deleting /usr/lib/mozilla/plugins/libflashplayer.so
  --> Deleting /usr/lib64/kde4/kcm_adobe_flash_player.so
  --> Deleting /usr/share/icons/hicolor/16x16/apps/flash-player-properties.png
  --> Deleting /usr/share/icons/hicolor/22x22/apps/flash-player-properties.png
  --> Deleting /usr/share/icons/hicolor/24x24/apps/flash-player-properties.png
  --> Deleting /usr/share/icons/hicolor/32x32/apps/flash-player-properties.png
  --> Deleting /usr/share/icons/hicolor/48x48/apps/flash-player-properties.png
  --> Deleting /usr/share/kde4/services/kcm_adobe_flash_player.desktop
  --> Deleting empty directory /usr/lib64/kde4/
  --> Deleting empty directory /usr/lib/mozilla/plugins/
  --> Deleting empty directory /usr/lib/mozilla/
  --> Deleting empty directory /usr/lib/kde4/
Quiet mode: off
grep: /var/log/packages/flashplayer-plugin-23.0.0.207-x86_64-1: No such file or directory
Updating shared library links:  /sbin/ldconfig
Updating CINNAMON menu: update-desktop-database
Downloading: install_flash_player_11_linux.x86_64.tar.gz  DONE
libflashplayer.so
readme.txt
LGPL/
LGPL/LGPL.txt
LGPL/notice.txt
usr/
usr/lib64/
usr/lib64/kde4/
usr/lib64/kde4/kcm_adobe_flash_player.so
usr/share/
usr/share/pixmaps/
usr/share/pixmaps/flash-player-properties.png
usr/share/kde4/
usr/share/kde4/services/
usr/share/kde4/services/kcm_adobe_flash_player.desktop
usr/share/icons/
usr/share/icons/hicolor/
usr/share/icons/hicolor/24x24/
usr/share/icons/hicolor/24x24/apps/
usr/share/icons/hicolor/24x24/apps/flash-player-properties.png
usr/share/icons/hicolor/48x48/
usr/share/icons/hicolor/48x48/apps/
usr/share/icons/hicolor/48x48/apps/flash-player-properties.png
usr/share/icons/hicolor/32x32/
usr/share/icons/hicolor/32x32/apps/
usr/share/icons/hicolor/32x32/apps/flash-player-properties.png
usr/share/icons/hicolor/16x16/
usr/share/icons/hicolor/16x16/apps/
usr/share/icons/hicolor/16x16/apps/flash-player-properties.png
usr/share/icons/hicolor/22x22/
usr/share/icons/hicolor/22x22/apps/
usr/share/icons/hicolor/22x22/apps/flash-player-properties.png
usr/share/applications/
usr/share/applications/flash-player-properties.desktop
usr/bin/
usr/bin/flash-player-properties
usr/lib/
usr/lib/kde4/
usr/lib/kde4/kcm_adobe_flash_player.so
chmod: cannot operate on dangling symlink 'usr/lib/kde4/kcm_adobe_flash_player.so'

Slackware package maker, version 3.141593.

Searching for symbolic links:
usr/lib/kde4/kcm_adobe_flash_player.so	/usr/lib64/kde4/kcm_adobe_flash_player.so
usr/share/pixmaps/flash-player-properties.png	../icons/hicolor/48x48/apps/flash-player-properties.png
usr/lib64/mozilla	/usr/lib/mozilla

Making symbolic link creation script:
( cd usr/lib/kde4 ; rm -rf kcm_adobe_flash_player.so )
( cd usr/lib/kde4 ; ln -sf /usr/lib64/kde4/kcm_adobe_flash_player.so kcm_adobe_flash_player.so )
( cd usr/share/pixmaps ; rm -rf flash-player-properties.png )
( cd usr/share/pixmaps ; ln -sf ../icons/hicolor/48x48/apps/flash-player-properties.png flash-player-properties.png )
( cd usr/lib64 ; rm -rf mozilla )
( cd usr/lib64 ; ln -sf /usr/lib/mozilla mozilla )

Unless your existing installation script already contains the code
to create these links, you should append these lines to your existing
install script. Now's your chance. :^)

Would you like to add this stuff to the existing install script and
remove the symbolic links ([y]es, [n]o)? y


Removing symbolic links:
removed './usr/lib/kde4/kcm_adobe_flash_player.so'
removed './usr/share/pixmaps/flash-player-properties.png'
removed './usr/lib64/mozilla'

Updating your ./install/doinst.sh...

This next step is optional - you can set the directories in your package
to some sane permissions. If any of the directories in your package have
special permissions, then DO NOT reset them here!

Would you like to reset all directory permissions to 755 (drwxr-xr-x) and
directory ownerships to root.root ([y]es, [n]o)? n

Creating Slackware package:  /tmp/flashplayer-plugin-23.0.0.207-x86_64-1.txz

./
install/
install/doinst.sh
install/slack-desc
usr/
usr/lib/
usr/lib/mozilla/
usr/lib/mozilla/plugins/
usr/lib/mozilla/plugins/libflashplayer.so
usr/lib/kde4/
usr/bin/
usr/bin/flash-player-properties
usr/share/
usr/share/applications/
usr/share/applications/flash-player-properties.desktop
usr/share/icons/
usr/share/icons/hicolor/
usr/share/icons/hicolor/22x22/
usr/share/icons/hicolor/22x22/apps/
usr/share/icons/hicolor/22x22/apps/flash-player-properties.png
usr/share/icons/hicolor/16x16/
usr/share/icons/hicolor/16x16/apps/
usr/share/icons/hicolor/16x16/apps/flash-player-properties.png
usr/share/icons/hicolor/32x32/
usr/share/icons/hicolor/32x32/apps/
usr/share/icons/hicolor/32x32/apps/flash-player-properties.png
usr/share/icons/hicolor/48x48/
usr/share/icons/hicolor/48x48/apps/
usr/share/icons/hicolor/48x48/apps/flash-player-properties.png
usr/share/icons/hicolor/24x24/
usr/share/icons/hicolor/24x24/apps/
usr/share/icons/hicolor/24x24/apps/flash-player-properties.png
usr/share/kde4/
usr/share/kde4/services/
usr/share/kde4/services/kcm_adobe_flash_player.desktop
usr/share/pixmaps/
usr/lib64/
usr/lib64/kde4/
usr/lib64/kde4/kcm_adobe_flash_player.so

Slackware package /tmp/flashplayer-plugin-23.0.0.207-x86_64-1.txz created.

Verifying package flashplayer-plugin-23.0.0.207-x86_64-1.txz.
Installing package flashplayer-plugin-23.0.0.207-x86_64-1.txz:
PACKAGE DESCRIPTION:
# flashplayer-plugin (flash plugin for web browsers)
#
# Provides Adobe Flash plugin for browsers that recognize
# /usr/lib/mozilla/plugins as a valid plugin directory
#
# Plugin is subject to Adobe terms of use: 
#  http://www.adobe.com/go/labs_term_of_use
#
# Plugin is subject to Adobe Flash EULA:
#  http://labs.adobe.com/technologies/eula/flashplayer.html
#
Executing install script for flashplayer-plugin-23.0.0.207-x86_64-1.txz.
Package flashplayer-plugin-23.0.0.207-x86_64-1.txz installed.

Creating /tmp/flashplayer-plugin-23.0.0.207-x86_64-1.xzm

root@porteus:/home/guest# 

root@porteus:/home/guest# find /mnt/live/memory/images/changes -name .wh.*
root@porteus:/home/guest# 

root@porteus:/home/guest# find /mnt/live/memory/changes -name .wh.*
/mnt/live/memory/changes/usr/bin/.wh.flash-player-properties
/mnt/live/memory/changes/usr/lib64/.wh.kde4
/mnt/live/memory/changes/usr/lib64/.wh.mozilla
/mnt/live/memory/changes/usr/lib/.wh.kde4
/mnt/live/memory/changes/usr/lib/.wh.mozilla
/mnt/live/memory/changes/usr/share/kde4/services/.wh.kcm_adobe_flash_player.desktop
/mnt/live/memory/changes/usr/share/icons/hicolor/48x48/apps/.wh.flash-player-properties.png
/mnt/live/memory/changes/usr/share/icons/hicolor/32x32/apps/.wh.flash-player-properties.png
/mnt/live/memory/changes/usr/share/icons/hicolor/24x24/apps/.wh.flash-player-properties.png
/mnt/live/memory/changes/usr/share/icons/hicolor/22x22/apps/.wh.flash-player-properties.png
/mnt/live/memory/changes/usr/share/icons/hicolor/16x16/apps/.wh.flash-player-properties.png
/mnt/live/memory/changes/usr/share/pixmaps/.wh.flash-player-properties.png
/mnt/live/memory/changes/usr/share/applications/.wh.flash-player-properties.desktop
/mnt/live/memory/changes/var/log/scripts/.wh.flashplayer-plugin-23.0.0.207-x86_64-1
/mnt/live/memory/changes/var/log/packages/.wh.flashplayer-plugin-23.0.0.207-x86_64-1
/mnt/live/memory/changes/.wh..wh.orph
/mnt/live/memory/changes/.wh..wh.plnk
/mnt/live/memory/changes/.wh..wh.aufs
/mnt/live/memory/changes/home/guest/Backups/FireFox/.wh.bookmarks-2016-10-20.json
/mnt/live/memory/changes/home/guest/.local/share/gvfs-metadata/.wh.home-c058e065.log
/mnt/live/memory/changes/home/guest/.local/share/gvfs-metadata/.wh.uuid-01CD20066B8BF780-b86c9e9c.log
/mnt/live/memory/changes/home/guest/.local/share/gvfs-metadata/.wh.home-695cd35e.log
/mnt/live/memory/changes/home/guest/.local/share/gvfs-metadata/.wh.home-806afc90.log
/mnt/live/memory/changes/home/guest/.cache/mozilla/firefox/dxsqumip.default/cache2/entries/.wh.8E83DD6FE19776435C78C82841409180553AE2F7
/mnt/live/memory/changes/home/guest/.mozilla/firefox/dxsqumip.default/saved-telemetry-pings/.wh.6b2a864b-04bd-4493-8e30-ce37075399d6
/mnt/live/memory/changes/home/guest/.mozilla/firefox/dxsqumip.default/saved-telemetry-pings/.wh.d0f5d3d2-8288-410e-8862-347bd20f9235
/mnt/live/memory/changes/home/guest/.mozilla/firefox/dxsqumip.default/saved-telemetry-pings/.wh.c507e7c9-1602-4024-9c52-00d6223c8381
/mnt/live/memory/changes/home/guest/.mozilla/firefox/dxsqumip.default/saved-telemetry-pings/.wh.4174dd04-1e22-4666-a13b-f11b41be0e92
/mnt/live/memory/changes/home/guest/.mozilla/firefox/dxsqumip.default/bookmarkbackups/.wh.bookmarks-2016-10-23_174_ADNf3C24iqFLP19y-UYUAQ==.jsonlz4
/mnt/live/memory/changes/home/guest/.wh.32downloadsURL.txt
root@porteus:/home/guest# 

root@porteus:/home/guest# ls /mnt/sda5/porteus3.2/Modules/*.xzm
/mnt/sda5/porteus3.2/Modules/07-printing-x86_64-21.11.2016.xzm*
/mnt/sda5/porteus3.2/Modules/firefox-50.0b5-x86_64-1.xzm*
/mnt/sda5/porteus3.2/Modules/flashplayer-plugin-23.0.0.207-x86_64-1.xzm*

root@porteus:/home/guest# ./bootmode.sh x
Boot device: /dev/sda5
Device format: "ntfs" 
Boot ISO: /ISOs/Porteus-CINNAMON-v3.2-x86_64-nu.iso
 Changes to be saved to a save.dat file.
Save.dat: /porteus3.2/changes/porteussave.dat
Changes:  changes=EXIT:/porteus3.2/changes/porteussave.dat
Cmdline:  quiet from=/ISOs/Porteus-CINNAMON-v3.2-x86_64-nu.iso kmap=us changes=EXIT:/porteus3.2/changes/porteussave.dat extramod=/porteus3.2/Modules  
root@porteus:/home/guest# 

root@porteus:/home/guest# ls -g /usr/local/bin/update-*
-rwxr-xr-x 1 root 40055 Nov  6 22:26 /usr/local/bin/update-firefox-live*
-rwxr-xr-x 1 root  5880 Sep  7 14:40 /usr/local/bin/update-flash-live*
root@porteus:/home/guest# 

I then start firefox to post this.

The Flashplayer plugin again doesn't work in Firefox. IMO the bug is in the update-flash app.
Ed

User avatar
ncmprhnsbl
DEV Team
DEV Team
Posts: 1030
Joined: 20 Mar 2012, 03:42
Distribution: 3.2.2-64bit xfce/openbox
Location: australia
Contact:

Re: Porteus 3.2 and Firefox/Flashplayer problem

Post#20 by ncmprhnsbl » 27 Nov 2016, 00:02

so...(disclaimer asumptions ahead)
what happens is..??
1.you have a save.dat(essentially a module) with a previous flashplugin installed
2.this part of update-flash-live:

Code: Select all

# Remove any installed flash
if [[ `ls /var/log/packages/flashplayer-plugin* 2>/dev/null` ]]; then
	removepkg flashplayer-plugin
fi
results in whiteouts in /mnt/live/memory/changes because save.dat is essentially a module..
3.whiteouts then prevent new flash-module files appearing..
4.whiteouts then written to save.dat on exit

heres a sort of similar scenario:
1. i activate firefox module, run firefox, close it.
2. i delete ~/.mozilla (creates whiteout in /mnt/live/memory/changes/~/)
3. i activate ffsettngs.xzm(contains ~/.mozilla)
4. ~/.mozilla not there

suggestion: something in update-flash-live to detect such whiteouts and remove them... ? its probly beyond the scope of the script to manage save.dat s?
Forum Rules : http://forum.porteus.org/viewtopic.php?f=35&t=44

User avatar
Ed_P
Contributor
Contributor
Posts: 3423
Joined: 06 Feb 2013, 22:12
Distribution: Cinnamon 3.2.2 64-bit ISO
Location: Western NY, USA

Re: Porteus 3.2 and Firefox/Flashplayer problem

Post#21 by Ed_P » 27 Nov 2016, 01:04

ncmprhnsbl wrote:so...(disclaimer asumptions ahead)
what happens is..??
Yup.
suggestion: something in update-flash-live to detect such whiteouts and remove them... ?
If the 3.2 update script(s) don't work with save.dat files then IMO they should test for the presence of the /mnt/live/memory/changes/ folder at the beginning of the script and issue a warning that they don't support save.dat usage and exit. Similar to their testing for running under guest.
its probly beyond the scope of the script to manage save.dat s?
I understand. A concern is this is not the only 3.2 update script that's going to cause this type of problem. In that USM did these update functions in earlier releases I'm not sure why it is being phased out.
Ed

Bogomips
Full of knowledge
Full of knowledge
Posts: 2563
Joined: 25 Jun 2014, 15:21
Distribution: 3.2.2 Cinnamon & KDE5
Location: London

Re: Porteus 3.2 and Firefox/Flashplayer problem

Post#22 by Bogomips » 27 Nov 2016, 01:53

Ed_P wrote: In that USM did these update functions in earlier releases I'm not sure why it is being phased out.
Does not appear to me like that. It's more that these seem to be important modules whose creation could benefit from not relying on an all purpose script like USM.
Linux porteus 4.4.0-porteus #3 SMP PREEMPT Sat Jan 23 07:01:55 UTC 2016 i686 AMD Sempron(tm) 140 Processor AuthenticAMD GNU/Linux
NVIDIA Corporation C61 [GeForce 6150SE nForce 430] (rev a2) MemTotal: 901760 kB MemFree: 66752 kB

User avatar
ncmprhnsbl
DEV Team
DEV Team
Posts: 1030
Joined: 20 Mar 2012, 03:42
Distribution: 3.2.2-64bit xfce/openbox
Location: australia
Contact:

Re: Porteus 3.2 and Firefox/Flashplayer problem

Post#23 by ncmprhnsbl » 27 Nov 2016, 04:25

Ed_P wrote:should test for the presence of the /mnt/live/memory/changes/ folder
more like, look in /mnt/live/memory/images for 1. save.dat, 2. flash installed in it..
then maybe warn that it needs to be decompressed(or loop mounted), remove the relevent files and recompressed ...
or possibly do it, maybe via a supplementary script 'savedatmanager' that would:
1.find the physical location of the save.dat
2.mount or extract
3.remove the offending files/package
4.recompress(or unmount)
5.overwrite the original
6.prompt to reboot (with clean save.dat)
Ed_P wrote: I'm not sure why it is being phased out.
yeah, no. it's not, as bogomips says, update scripts for some(frequently updated) things and usm for (almost)everything else..
or usm for everything if desired.. (tho dont forget that update-<browser> includes the porteus ddg search which generates income)
one great thing about these update-live scripts is they live on the server, so brokenman can tweek them without having to push updates to us...
Forum Rules : http://forum.porteus.org/viewtopic.php?f=35&t=44

User avatar
Ed_P
Contributor
Contributor
Posts: 3423
Joined: 06 Feb 2013, 22:12
Distribution: Cinnamon 3.2.2 64-bit ISO
Location: Western NY, USA

Re: Porteus 3.2 and Firefox/Flashplayer problem

Post#24 by Ed_P » 27 Nov 2016, 05:16

Bogomips wrote:It's more that these seem to be important modules whose creation could benefit from not relying on an all purpose script like USM.
Why not just have current modules with the appropiate Porteus tweaks available for downloads on http://dl.porteus.org/x86_64/ or mirrors ? Or even add their location to USM's list of sites.
ncmprhnsbl wrote:
Ed_P wrote:should test for the presence of the /mnt/live/memory/changes/ folder
more like, look in /mnt/live/memory/images for 1. save.dat, 2. flash installed in it..
hmmm... Your implying that the /mnt/live/memory/changes/ folder only exists if there is a /mnt/live/memory/images/changes folder. Interesting. I had assumed that the /mnt/live/memory/changes/ folder always existed. I'll have to check the next time I boot AF mode.
tpossibly do it, maybe via a supplementary script 'savedatmanager' that would:
I don't see that happening for each of the update scripts.
(tho dont forget that update-<browser> includes the porteus ddg search which generates income)
Now that is a good point. With prior releases the ISO could be downloaded with a browser included which had the Porteus tweaks embedded. Adding updated browser modules used the browser tweaks that were in the ISO. 3.2 doesn't have that option which is probably what lead to the update scripts. Having browser modules that contain the Porteus tweaks that users could download might be easier than these update scripts.
one great thing about these update-live scripts is they live on the server, so brokenman can tweek them without having to push updates to us...
Whether the scripts update themselves or we download updated scripts or script modules seems to be 6 of one ..... :wink:
Ed

User avatar
ncmprhnsbl
DEV Team
DEV Team
Posts: 1030
Joined: 20 Mar 2012, 03:42
Distribution: 3.2.2-64bit xfce/openbox
Location: australia
Contact:

Re: Porteus 3.2 and Firefox/Flashplayer problem

Post#25 by ncmprhnsbl » 27 Nov 2016, 07:19

Ed_P wrote:hmmm... Your implying that the /mnt/live/memory/changes/ folder only exists if there is a /mnt/live/memory/images/changes folder
no. my impression is that /mnt/live/memory/changes/ folder only contains whats changed in the current running system, so wont contain whats in the save.dat..
Ed_P wrote:6 of one

well theres easier for the users and theres easier for brokenman :wink:
Forum Rules : http://forum.porteus.org/viewtopic.php?f=35&t=44

User avatar
brokenman
Site Admin
Site Admin
Posts: 5659
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v3.2rcX all desktops
Location: Brazil
Contact:

Re: Porteus 3.2 and Firefox/Flashplayer problem

Post#26 by brokenman » 27 Nov 2016, 15:45

I will do my best to keep an updated version of the browsers on the server for direct download. The real problem will be users knowing that it is there.

The whiteout files causing the problem are indeed generated by the removepkg slackware script. When a current install of flashplayer is detected it will first be removed. Ideally, the update- scripts should not invoke removepkg at all. I will see if there is an alternative. First check is to see if the module can be deactivated in /mnt/live/memory/images while it is in use.

Thanks for testing.
How do i become super user?
Wear your underpants on the outside and put on a cape.

Bogomips
Full of knowledge
Full of knowledge
Posts: 2563
Joined: 25 Jun 2014, 15:21
Distribution: 3.2.2 Cinnamon & KDE5
Location: London

Re: Porteus 3.2 and Firefox/Flashplayer problem

Post#27 by Bogomips » 27 Nov 2016, 17:52

brokenman wrote:I will do my best to keep an updated version of the browsers on the server for direct download. The real problem will be users knowing that it is there.
On the presumption that users are aware of update scripts, but not so aware of updated version on server, all the update script has to do is
  • After doing fastest-server( :good: really convenient)
  • Check if version on server is latest, and if so just downoad it
  • Otherwise give user option of a direct download of version on server or building latest version module.
Linux porteus 4.4.0-porteus #3 SMP PREEMPT Sat Jan 23 07:01:55 UTC 2016 i686 AMD Sempron(tm) 140 Processor AuthenticAMD GNU/Linux
NVIDIA Corporation C61 [GeForce 6150SE nForce 430] (rev a2) MemTotal: 901760 kB MemFree: 66752 kB

User avatar
brokenman
Site Admin
Site Admin
Posts: 5659
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v3.2rcX all desktops
Location: Brazil
Contact:

Re: Porteus 3.2 and Firefox/Flashplayer problem

Post#28 by brokenman » 27 Nov 2016, 18:17

That sounds like a good idea. :)
How do i become super user?
Wear your underpants on the outside and put on a cape.

donald
Full of knowledge
Full of knowledge
Posts: 1247
Joined: 17 Jun 2013, 13:17
Distribution: Porteus 3.2.2 XFCE 32bit
Location: Germany

Re: Porteus 3.2 and Firefox/Flashplayer problem

Post#29 by donald » 27 Nov 2016, 19:19

just thinking loud..

Provide Browser-modules without any kind of flash included.
If a user needs flash, (s)he has to activate a module.
The update-flash script will have nothing more to do as to
look for and point to an upgraded/new module.
(maybe download it into /tmp)
We also have USM to look for a new flashplayer,no?

btw
I did the activate/deactivate steps without having any issues.
(Pale Moon 26.5.0 + flash-plugin-11.2.202.644-i686-bundle.xzm)
.. while the browser is closed of course..
(not that i would ever allow "flash" to be on my system;only for testing.. :) )

User avatar
Ed_P
Contributor
Contributor
Posts: 3423
Joined: 06 Feb 2013, 22:12
Distribution: Cinnamon 3.2.2 64-bit ISO
Location: Western NY, USA

Re: Porteus 3.2 and Firefox/Flashplayer problem

Post#30 by Ed_P » 28 Nov 2016, 02:15

brokenman wrote:I will do my best to keep an updated version of the browsers on the server for direct download. The real problem will be users knowing that it is there.
A simple script similar to normalGuy's UPS could check the server and download a file if it is newer than what a user has, or download it if it's something to be added to their system. For example they are using Firefox and want to try Chrome.
The whiteout files causing the problem are indeed generated by the removepkg slackware script. When a current install of flashplayer is detected it will first be removed. Ideally, the update- scripts should not invoke removepkg at all.
I agree. If I'm using Flashplayer and it needs to be updated simply downloading and installing the new version over the top of the existing version, deactivating it if it's active before doing the installing. And I think the same concept would apply to most browser updates.

A concern is where do you install the new module. As jssouza found with his modules script seeing what modules are active is easy, knowing where they were loaded from not so much. Obviously storing all new/updated modules in the /tmp/ folder works, until the user reboots. Having the user specify where they want the module stored would be helpful. Having the user's module location stored and used for further updates would be even better. :wink:

Thanks for looking into this brokenman. Sorry it didn't come out in the 3.2rc tests.
Ed

Post Reply