Porteus-v1.0-rc1-x86_64 last call for testing

New features which should be implemented in Porteus; suggestions are welcome. All questions or problems with testing releases (alpha, beta, or rc) should go in their relevant thread here, rather than the Bug Reports section.
Post Reply
User avatar
Hamza
Warlord
Warlord
Posts: 1846
Joined: 28 Dec 2010, 07:41
Distribution: Porteus
Location: France

Re: Porteus-v1.0-rc1-x86_64 last call for testing

Post#91 by Hamza » 26 Apr 2011, 12:30

If you want KDE4 in German , you can install this package.

http://alien.slackbook.org/ktown/4.6.2/ ... 1alien.txz

Be Aware , this package is only for KDE 4.6.2 with a x86_64 cpu.
NjVFQzY2Rg==

User avatar
Rava
Contributor
Contributor
Posts: 1319
Joined: 11 Jan 2011, 02:46
Distribution: Porteus 3.1.0 x86-64 XFCe
Location: Germany

Re: Porteus-v1.0-rc1-x86_64 last call for testing

Post#92 by Rava » 26 Apr 2011, 12:55

Hamza wrote:If you want KDE4 in German
Nope, not KDE. That I will remove as quick as I can, when I get some more programs to run with x86_64 and LXDe or XFCe...

I want / need German/UTF-8 with:
Virtual Consoles (that already works due to a hack I put into the /etc/rc.d/rc.local)
LXDE
LXTerminal
_________________________________

Anyhow, the Menu entries of later loaded modules still not gets updated in 1.0rc1...
_________________________________

(GIMP part removed, updates on that later...)
Cheers!
Yours Rava

User avatar
Hamza
Warlord
Warlord
Posts: 1846
Joined: 28 Dec 2010, 07:41
Distribution: Porteus
Location: France

Re: Porteus-v1.0-rc1-x86_64 last call for testing

Post#93 by Hamza » 26 Apr 2011, 13:01

Could you post your xactivate script ?
NjVFQzY2Rg==

User avatar
Rava
Contributor
Contributor
Posts: 1319
Joined: 11 Jan 2011, 02:46
Distribution: Porteus 3.1.0 x86-64 XFCe
Location: Germany

Re: Porteus-v1.0-rc1-x86_64 last call for testing

Post#94 by Rava » 26 Apr 2011, 13:50

Hamza wrote:Could you post your xactivate script ?
?
What do you mean with xactivate script?
_________________________

rpm2txz gives an error message even when everything is okay:

Code: Select all

root@porteus:/mnt/DL# rpm2txz libgegl-0_0-0-0.1.0-2.3.x86_64.rpm libgegl-0_0-0-.1.0-2.3.x86_64.txz 

Slackware package maker, version 3.14159.

[...] 

Slackware package /mnt/DL/libgegl-0_0-0-0.1.0-2.3.x86_64.txz created.

ERROR:  rpm2cpio failed.  (maybe libgegl-0_0-0-0.1.0-2.3.x86_64.txz is not an RPM?)
root@porteus:/mnt/DL# ls -l libgegl-0_0-0-0.1.0-2.3.x86_64.*
-rw-r--r-- 1 rava rava 317935 Apr 26 15:37 libgegl-0_0-0-0.1.0-2.3.x86_64.rpm
-rw-r--r-- 1 root root 277112 Apr 26 15:40 libgegl-0_0-0-0.1.0-2.3.x86_64.txz
The scripts seems working fine, but it should not print that error "rpm2cpio failed." at the end...
Cheers!
Yours Rava

User avatar
Hamza
Warlord
Warlord
Posts: 1846
Joined: 28 Dec 2010, 07:41
Distribution: Porteus
Location: France

Re: Porteus-v1.0-rc1-x86_64 last call for testing

Post#95 by Hamza » 26 Apr 2011, 13:58

ERROR: rpm2cpio failed. (maybe libgegl-0_0-0-0.1.0-2.3.x86_64.txz is not an RPM?)
You have this error , because , you trying to use rpm2cpio with a TXZ Package (Slackware Package)
NjVFQzY2Rg==

User avatar
Rava
Contributor
Contributor
Posts: 1319
Joined: 11 Jan 2011, 02:46
Distribution: Porteus 3.1.0 x86-64 XFCe
Location: Germany

Re: Porteus-v1.0-rc1-x86_64 last call for testing

Post#96 by Rava » 26 Apr 2011, 14:09

Hamza wrote:
ERROR: rpm2cpio failed. (maybe libgegl-0_0-0-0.1.0-2.3.x86_64.txz is not an RPM?)
You have this error , because , you trying to use rpm2cpio with a TXZ Package (Slackware Package)
Nope, what I am trying is txz2xzm on a txz.
It converts okay but still gives that error message at the end.

P.S.
Hamza, you not told me what you meant with your "xactivate " question.
_________________________

Is there a better way to tell Porteus 1.0rc1 to have, like, 10 loop devices more than it needs itself?
I sure can create one each time I need access to a truecrypt container, or need to mount an iso...
But I would prefer when I could tell Porteus I want some more. All I know is that fanthom told me for 1.0a and / or 1.0b that the kernel parameter for loop devices is no longer needed when I boot Porteus.
_________________________

Anyhow, I have issues with creating GIMP for x86_64:
Update on GIMP for x86_64:
I found the needed libbabl and libgegl on pkgs.org, but the found babl-0.1.0-x86_64-1.txz and gegl-0.1.0-x86_64-1.txz really included the libbabl-0.0.so.0.100.0 and libgegl-0.0.so.0.100.0 versions... :%)
Maybe the new trinity64 managed to get the needed libs...
Then I can mount an iso again (see above)

:) :D
Cheers!
Yours Rava

User avatar
Hamza
Warlord
Warlord
Posts: 1846
Joined: 28 Dec 2010, 07:41
Distribution: Porteus
Location: France

Re: Porteus-v1.0-rc1-x86_64 last call for testing

Post#97 by Hamza » 26 Apr 2011, 14:12

When you activating a module on LXDE , a script is called 'xactivate'.

If you want find it , open a terminal and type : ls /usr/bin/*activate*

Normally , this script doesn't call rpm2cpio.

If you find it , could you post it here?
NjVFQzY2Rg==

User avatar
Rava
Contributor
Contributor
Posts: 1319
Joined: 11 Jan 2011, 02:46
Distribution: Porteus 3.1.0 x86-64 XFCe
Location: Germany

Re: Porteus-v1.0-rc1-x86_64 last call for testing

Post#98 by Rava » 26 Apr 2011, 18:48

Code: Select all

bash-4.1$ l /usr/bin/*activate*
-rwxr-xr-x 1 root 3310 2011-04-11 11:25 /usr/bin/activate
-rwxr-xr-x 1 root 3043 2011-04-10 20:29 /usr/bin/deactivate
-rwxr-xr-x 1 root 4988 2011-04-08 14:38 /usr/bin/xactivate
-rwxr-xr-x 1 root 1373 2011-04-08 14:39 /usr/bin/xdeactivate
Ups... silly me, I always called activate, not xactivate, since I do so for ages and I get the lil window telling me the module was inserted successfully...
I try it out as soon as I can and tell you if the issue is now solved...
______________________________________

Anyhow, an update on the browser front and my 2 cents:
I run FFx with NoScript, AdBlockPlus and Lastpass, since that is the safest and most convenient combination...
When it is decided to include the 2 modules that got put into FFx, I will need to deinstall these every time I update Porteus. But that would be not that of and issue, since I have done that Since Slax 6.1.2 anyway...

About Opera: that one has a similar plugins that are comparable to NoScript - "NotScripts" and one similar to AdBlockPlus - "Opera Adblock"
The NotScript don't let me access its settings and so I cannot really use some pages cause I cannot allow some needed javascript...
And with FFx Lastpass can be opened not on https://lastpass.com/?ac=1&opensettings=1but locally via chrome://lastpass/content/home.xul ...
On Opera that only is possible by using the https way, and by changing one single bit the data need to be loaded back and there again, since lastpass does that anyway to have the best security the net could offer, and that means that using Lastpass with Opera it is quite slower.

Also some sites that heavily use javascript are very slow with Opera, FFx seem to manage all that better.

Just as info for you folks on here. I think we should keep FFx as the one and only browser. :)
Cheers!
Yours Rava

User avatar
Hamza
Warlord
Warlord
Posts: 1846
Joined: 28 Dec 2010, 07:41
Distribution: Porteus
Location: France

Re: Porteus-v1.0-rc1-x86_64 last call for testing

Post#99 by Hamza » 26 Apr 2011, 18:55

Ups... silly me, I always called activate, not xactivate, since I do so for ages and I get the lil window telling me the module was inserted successfully...
I try it out as soon as I can and tell you if the issue is now solved...
Okay , let me know if it works or no?
Anyhow, an update on the browser front and my 2 cents:
I run FFx with NoScript, AdBlockPlus and Lastpass, since that is the safest and most convenient combination...
When it is decided to include the 2 modules that got put into FFx, I will need to deinstall these every time I update Porteus. But that would be not that of and issue, since I have done that Since Slax 6.1.2 anyway...

About Opera: that one has a similar plugins that are comparable to NoScript - "NotScripts" and one similar to AdBlockPlus - "Opera Adblock"
The NotScript don't let me access its settings and so I cannot really use some pages cause I cannot allow some needed javascript...
And with FFx Lastpass can be opened not on https://lastpass.com/?ac=1&opensettings=1but locally via chrome://lastpass/content/home.xul ...
On Opera that only is possible by using the https way, and by changing one single bit the data need to be loaded back and there again, since lastpass does that anyway to have the best security the net could offer, and that means that using Lastpass with Opera it is quite slower.

Also some sites that heavily use javascript are very slow with Opera, FFx seem to manage all that better.

Just as info for you folks on here. I think we should keep FFx as the one and only browser. :)
If you won't enable JS in some website , you can the function of FF for disable it in some URL/IP.

Thanks for reporting bug !

Cheers!
NjVFQzY2Rg==

User avatar
Rava
Contributor
Contributor
Posts: 1319
Joined: 11 Jan 2011, 02:46
Distribution: Porteus 3.1.0 x86-64 XFCe
Location: Germany

Re: Porteus-v1.0-rc1-x86_64 last call for testing

Post#100 by Rava » 27 Apr 2011, 09:56

Hamza wrote:Okay , let me know if it works or no?
The only module I would use like that would be GIMP but like I said above: no luck creating the module so far... :unknown:

P.S.
I suggest that we can create new topics for issues creating x86_64 modules for Porteus, since these issues are usually not a matter of any beta, rc1 or rc2 but as in my case above a matter of messed up packets...
And we need more working x86_64 soon anyway, since a OS without programs is ... off-ish.
Cheers!
Yours Rava

User avatar
Hamza
Warlord
Warlord
Posts: 1846
Joined: 28 Dec 2010, 07:41
Distribution: Porteus
Location: France

Re: Porteus-v1.0-rc1-x86_64 last call for testing

Post#101 by Hamza » 27 Apr 2011, 10:08

Have you activated your module with success on LXDE with xactivate script?

For creating a module , you need just use the scripts converters , xzm2dir/dir2xzm/txz2xzm , if it doesn't works , you can try with

Code: Select all

mksquashfs /path/to/folder  /tmp/mymodule.xzm -b 256K
Or , you can use this script.

Code: Select all

#!/bin/bash

mksquashfs $1 $2 -b 256K
1) copy 'n paste this text in a file
2) make the file as +x with chmod /path/to/file +x
3) execute it in terminal with the same synthax as dir2xzm.
P.S.
I suggest that we can create new topics for issues creating x86_64 modules for Porteus, since these issues are usually not a matter of any beta, rc1 or rc2 but as in my case above a matter of messed up packets...
And we need more working x86_64 soon anyway, since a OS without programs is ... off-ish.
If you issue is only with Porteus v1 rc1 x86_64 , you're in right place , otherwise , you must open a new thread in Bug Report x86_64.
NjVFQzY2Rg==

User avatar
fanthom
Site Admin
Site Admin
Posts: 4547
Joined: 28 Dec 2010, 02:42
Distribution: Porteus Kiosk
Location: Poland, currently - Cork, IE
Contact:

Re: Porteus-v1.0-rc1-x86_64 last call for testing

Post#102 by fanthom » 27 Apr 2011, 10:29

@Rava
"How do you do it with rc1 and your Polish localization, or do you run it with en_US as well?"
default en_US

"X terminal itself only gives me "?" instead of "ä" - or any other Umlaut - and "ss" instead of "ß"..."
do you mean xterm? i also cant get it to work with polish letters, will ask Blaze as he got it to work with russian in the past.

"want / need German/UTF-8 with:
Virtual Consoles (that already works due to a hack I put into the /etc/rc.d/rc.local)"
could you share this hack?

"Anyhow, the Menu entries of later loaded modules still not gets updated in 1.0rc1..."
works ok here.
lxpanel gets reloaded when /usr/share/applications.*desktop file is discovered inside the module. no point for reloading it for non GUI apps.
please show me example of a module which doesn't work for you.

"rpm2txz gives an error message even when everything is okay:"
wrong command syntax:
rpm2txz libgegl-0_0-0-0.1.0-2.3.x86_64.rpm libgegl-0_0-0-.1.0-2.3.x86_64.txz (wrong - app thinks that you want to convert 2 packages)
rpm2txz libgegl-0_0-0-0.1.0-2.3.x86_64.rpm (good)

"Is there a better way to tell Porteus 1.0rc1 to have, like, 10 loop devices more than it needs itself?"
there is a function in rc.M which adds one free loop device during boot time. i can:
1) tweak the rc.M script to add 10 loops during boot
2) introduce new cheatcode which adds required amount of loop devices at boot time.
3) tweak 'activate' script to add one free loop after each insertion so there will always be one free.
which idea is the best?

BTW - you can always use "max_loop=" cheatcode, but this solution is not perfect. the number of loops will be is static: as you wont be able to add more devices then specified in "max_loop="

"Ups... silly me, I always called activate, not xactivate"
you can use 'activate' as it calls 'xactivate' automatically when X session is discovered.

"Anyhow, I have issues with creating GIMP for x86_64"
i'm sure i have seen 64bit GIMP somewhere, search user repos.

"run FFx with NoScript, AdBlockPlus and Lastpass"
do you suggest to include them by default?

"I suggest that we can create new topics for issues creating x86_64 modules for Porteus"
As Hamza said: wait on a Final and then use 64bit BUG section of the forum. until we reach FINAL please use this thread.

Cheers
Please add [Solved] to your thread title if the solution was found.

User avatar
Rava
Contributor
Contributor
Posts: 1319
Joined: 11 Jan 2011, 02:46
Distribution: Porteus 3.1.0 x86-64 XFCe
Location: Germany

Re: Porteus-v1.0-rc1-x86_64 last call for testing

Post#103 by Rava » 27 Apr 2011, 21:22

fanthom wrote:do you mean xterm? i also cant get it to work with polish letters, will ask Blaze as he got it to work with russian in the past.
Yes, LXTerminal to be precise...
"want / need German/UTF-8 with:
Virtual Consoles (that already works due to a hack I put into the /etc/rc.d/rc.local)"
could you share this hack?
Sure can, but running V08 once again (since I need 2 different browsers and Opera is quite suckish... or its way the plugins work (lastpass) or plugins that try to copy what NoScript or AdblockPlus can do better)

So either I edit this post in a minute when I found it, or put in the info later...
"Is there a better way to tell Porteus 1.0rc1 to have, like, 10 loop devices more than it needs itself?"
there is a function in rc.M which adds one free loop device during boot time. i can:
1) tweak the rc.M script to add 10 loops during boot
2) introduce new cheatcode which adds required amount of loop devices at boot time.
3) tweak 'activate' script to add one free loop after each insertion so there will always be one free.
which idea is the best?
What about 1) and also a script that can add some more when you call it like "addloopdevices 5" then it adds 5 more loop devices.
The thing with tweaking the "activate" script: When you use truecrypt or mount an iso then you also need loop devices for each mount, and we cannot start creating scripts for all these matters...
So I suggest adding 10 more at boot time and also introducing a new script ("addloopdevices" was just my first idea of how to name that script...)

The cheat code sounds good as well, but how to handle that one and the "+10 more by default" together?
"Ups... silly me, I always called activate, not xactivate"
you can use 'activate' as it calls 'xactivate' automatically when X session is discovered.
But then it should have worked since my activate_ramdisk script that I use calls activate:

Code: Select all

LZMSTRING="Squashfs filesystem, little endian, version 4.0"
if [ -f $modfile ]; then
    # file exists
    # now file $1 for lzm
    file $modfile|grep "$LZMSTRING" &>/dev/null
    dummy=$?
    if [ $dummy -eq 0 ]; then
	cp -v $modfile /tmp
        sleep 1
        modfile=$(basename $modfile)
        activate /tmp/$modfile
    else
	echo -e $bld$red'file '$modfile' is not of filetype \n"'$LZMSTRING'". Abort!'$off
	exit 1
    fi
else
    echo -e $bld$red"file $modfile doesn't exist. Abort!"$off
fi
For some reason the "sleep 1" after the cp was needed or something strange happened ...
'm sure i have seen 64bit GIMP somewhere, search user repos.
I already found 64bit GIMP, but that is not working without these 2 libraries...
I will search on...
"run FFx with NoScript, AdBlockPlus and Lastpass"
do you suggest to include them by default?
Indeed I do, these three are the most secure, addfree way to browse the web. And I also suggest to leave away the 2 you included, since they are not needed then.
And since AdBlockPlus not even loads all the ads it is also quicker.

But there are some minor issues as well:
The user needs to choose one subscription for AdblockPlus since these subscriptions differ by the country you are in.
But that only is asked at the beginning, then all works by itself.

NoScript will break some video hosting sites; and to give youtube as example: you need to tell NoScript to allow scripts on youtube, but also on ytimg.com...
But I gladly try to help setting up a good working basis with the prefs.js (at least it got stored in that in the past, and it seems that it's valid for FFx 4.0 as well)
Also it will happen that the user allows javascript on other sites, like forums.

But that is a matter convenient vs secure...

Lastpass has no issues whatsoever, only one: if you do forget the one last password to enter your vault, then not even the guys from lastpass.com can access it for you, since they wanted the vault to be that secure...

As Hamza said: wait on a Final and then use 64bit BUG section of the forum. until we reach FINAL please use this thread.
'K. :)

Verfasst after 8 minutes 58 seconds:
fanthom wrote:do you mean xterm? i also cant get it to work with polish letters, will ask Blaze as he got it to work with russian in the past.
Yes, LXTerminal to be precise...
"want / need German/UTF-8 with:
Virtual Consoles (that already works due to a hack I put into the /etc/rc.d/rc.local)"
could you share this hack?
Sure can, but running V08 once again (since I need 2 different browsers and Opera is quite suckish... or its way the plugins work (lastpass) or plugins that try to copy what NoScript or AdblockPlus can do better)

It's in /etc/profile.local :

Code: Select all

grep "U1400" /proc/cpuinfo 1>&2 >/dev/null
declare -i cputest=$?
if [ $cputest -eq 0 ]; then
    loadkeys /usr/share/kbd/keymaps/i386/qwerty/uk.map
else
    loadkeys /usr/share/kbd/keymaps/i386/qwertz/de-latin1-nodeadkeys.map
fi
The above hack is needed for me since my Samsung Q40 has UK keymap, while all others use the de-latin1-nodeadkeys.map

One "loadkeys ...*map" line is enough to load a certain keymap for the chosen language, as long as it is to be found...

I suggest: when a cheatcode is used like lang=de then we have a list that tells us which *.map best to choose and insert a certain line into the /etc/profile
"Is there a better way to tell Porteus 1.0rc1 to have, like, 10 loop devices more than it needs itself?"
there is a function in rc.M which adds one free loop device during boot time. i can:
1) tweak the rc.M script to add 10 loops during boot
2) introduce new cheatcode which adds required amount of loop devices at boot time.
3) tweak 'activate' script to add one free loop after each insertion so there will always be one free.
which idea is the best?
What about 1) and also a script that can add some more when you call it like "addloopdevices 5" then it adds 5 more loop devices.
The thing with tweaking the "activate" script: When you use truecrypt or mount an iso then you also need loop devices for each mount, and we cannot start creating scripts for all these matters...
So I suggest adding 10 more at boot time and also introducing a new script ("addloopdevices" was just my first idea of how to name that script...)

The cheat code sounds good as well, but how to handle that one and the "+10 more by default" together?
"Ups... silly me, I always called activate, not xactivate"
you can use 'activate' as it calls 'xactivate' automatically when X session is discovered.
But then it should have worked since my activate_ramdisk script that I use calls activate:

Code: Select all

LZMSTRING="Squashfs filesystem, little endian, version 4.0"
if [ -f $modfile ]; then
    # file exists
    # now file $1 for lzm
    file $modfile|grep "$LZMSTRING" &>/dev/null
    dummy=$?
    if [ $dummy -eq 0 ]; then
	cp -v $modfile /tmp
        sleep 1
        modfile=$(basename $modfile)
        activate /tmp/$modfile
    else
	echo -e $bld$red'file '$modfile' is not of filetype \n"'$LZMSTRING'". Abort!'$off
	exit 1
    fi
else
    echo -e $bld$red"file $modfile doesn't exist. Abort!"$off
fi
For some reason the "sleep 1" after the cp was needed or something strange happened ...
'm sure i have seen 64bit GIMP somewhere, search user repos.
I already found 64bit GIMP, but that is not working without these 2 libraries...
I will search on...
"run FFx with NoScript, AdBlockPlus and Lastpass"
do you suggest to include them by default?
Indeed I do, these three are the most secure, addfree way to browse the web. And I also suggest to leave away the 2 you included, since they are not needed then.
And since AdBlockPlus not even loads all the ads it is also quicker.

But there are some minor issues as well:
The user needs to choose one subscription for AdblockPlus since these subscriptions differ by the country you are in.
But that only is asked at the beginning, then all works by itself.

NoScript will break some video hosting sites; and to give youtube as example: you need to tell NoScript to allow scripts on youtube, but also on ytimg.com...
But I gladly try to help setting up a good working basis with the prefs.js (at least it got stored in that in the past, and it seems that it's valid for FFx 4.0 as well)
Also it will happen that the user allows javascript on other sites, like forums.

But that is a matter convenient vs secure...

Lastpass has no issues whatsoever, only one: if you do forget the one last password to enter your vault, then not even the guys from lastpass.com can access it for you, since they wanted the vault to be that secure...

As Hamza said: wait on a Final and then use 64bit BUG section of the forum. until we reach FINAL please use this thread.
'K. :)
Cheers!
Yours Rava

beny
Full of knowledge
Full of knowledge
Posts: 720
Joined: 02 Jan 2011, 11:33
Location: italy

Re: Porteus-v1.0-rc1-x86_64 last call for testing

Post#104 by beny » 28 Apr 2011, 11:59

hi fanthom seem 13.37 is out good luck

User avatar
Hamza
Warlord
Warlord
Posts: 1846
Joined: 28 Dec 2010, 07:41
Distribution: Porteus
Location: France

Re: Porteus-v1.0-rc1-x86_64 last call for testing

Post#105 by Hamza » 28 Apr 2011, 12:03

@beny ,
I confirm , the Slackware 13.37 development version is out.
http://www.slackware.com/announce/13.37.php

Thanks for reporting this info.
NjVFQzY2Rg==

Post Reply