Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Tue 18 Feb 2020, 10:28
All times are UTC - 4
 Forum index » Advanced Topics » Puppy Projects
DpupBuster CE 64 and 32 bit
Moderators: Flash, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 11 of 11 [163 Posts]   Goto page: Previous 1, 2, 3, ..., 9, 10, 11
Author Message
marcelo4768

Joined: 18 Sep 2017
Posts: 9

PostPosted: Mon 30 Dec 2019, 21:14    Post subject: bug
Subject description: in pararells
 

no detecta el mouse, touchpad del notebok.
Captura de Pantalla 2019-12-30 a la(s) 22.07.36-min (1).png
Description 
png

 Download 
Filename  Captura de Pantalla 2019-12-30 a la(s) 22.07.36-min (1).png 
Filesize  219.56 KB 
Downloaded  82 Time(s) 
Back to top
View user's profile Send private message 
josejp2424


Joined: 01 Aug 2010
Posts: 530

PostPosted: Tue 31 Dec 2019, 16:54    Post subject: Re: bug
Subject description: in pararells
 

marcelo4768 wrote:
no detecta el mouse, touchpad del notebok.


problemas de drivers? Confused . no detecta.

_________________
Shiba Inu | Pupjibaro jessie | My Blog
Back to top
View user's profile Send private message Visit poster's website 
s243a

Joined: 02 Sep 2014
Posts: 2447

PostPosted: Thu 02 Jan 2020, 16:28    Post subject:  

The following "Synergy Package" (i.e. synergy-1.7.6-x86_64-1_SBo.tgz) was built for fatdog64 but works on dpup buster:

s243a wrote:
Here are some random packages:

mono-4.8.0.495-x86_64…Bo.tgz
avahi-0.6.31-x86_64-1_SBo.tgz
libgdiplus-4.2-x86_64-1…Bo.tgz
dulwich-0.9.0-x86_64-1…Bo.tgz
spawn-fcgi-1.6.4-x86_6…Bo.tgz
synergy-1.7.6-x86_64-1_SBo.tgz

I built these a while ago in fatdog710 beta. The extension looks right. Let me know if there any problems and I'll remove and or rebuild the file.

I didn't compile avachi with all it's options. The options I used are as follows

Code:

./configure \
  --prefix=/usr \
  --libdir=/usr/lib${LIBDIRSUFFIX} \
  --sysconfdir=/etc \
  --localstatedir=/var \
  --mandir=/usr/man \
  --docdir=/usr/doc/$PRGNAM-$VERSION \
  --enable-tests \
  --disable-static \
  --disable-monodoc \
  --disable-autoipd \
  --enable-python-dbus \
  --enable-pygtk\
  --enable-glib \
  --enable-dbus \
  --enable-python \
  --enable-gtk \
  --enable-gtk3 \
  --enable-qt4 \
  --disable-qt3 \
  --enable-core-docs \
  --enable-compat-howl \
  --enable-compat-libdns_sd \
  --with-dbus-sys=/etc/dbus-1/system.d \
  --with-avahi-user=avahi \
  --with-avahi-group=avahi \
  --with-avahi-priv-access-group=netdev \
  --with-distro=slackware \
  --program-prefix= \
  --program-suffix= \
  --build=$ARCH-slackware-linux \
  $MONO


Slackbuild file attached.


http://www.murga-linux.com/puppy/viewtopic.php?p=956313#956313

To install download synergy, than:
Code:

pkg --get libqt4-network
pkg --get libqtgui4
pkg -i synergy-1.7.6-x86_64-1_SBo.tgz #In the download directory


Mono might also be required...but probably not.

I may eventually try compiling these packages on buster. I tested this using synergy between dpup buster64 and the lastest fatdog64 (i.e. "Fatdog64-810 Beta (9 Dec 2019) ")

_________________
Find me on minds and on pearltrees.
Back to top
View user's profile Send private message Visit poster's website 
Smithy


Joined: 12 Dec 2011
Posts: 1094

PostPosted: Fri 03 Jan 2020, 09:40    Post subject:  

Hi Joseph,
Any reason why the 32 bit version is 420mb? The 64 bit version is also 420mb.
I would have thought it might be nearer 210mb or so.
I tested the 64 bit version. (Latest version).
1. Changing cursors broken.
2.Theme changes. JWM broken in various places.
3. Frisbee persistent even when trying to change to SNS on taskbar.

Nice distro and pulse audio with pasytray implementation interesting!
Back to top
View user's profile Send private message 
nilsonmorales


Joined: 15 Apr 2011
Posts: 948
Location: El Salvador

PostPosted: Sun 05 Jan 2020, 22:20    Post subject: Solución al tapping en laptops
Subject description: ---------SOLUCION PARA 32 BITS--------
 

Marcelo4768 escribió
Quote:
no detecta el mouse, touchpad del notebok.

Adjunto archivo e instrucciones
https://my.pcloud.com/publink/show?code=XZSYEukZIWQPvH1micbRFJVfq79CBV8VKTty
1- Descomprimir el archivo fixtapflsynclient.tar
2- borrar los archivos ocultos /root/.flsynclient y /root/.flsynclient-tap-to-click
si lo hubiera
3- colocar el archivo .flsynclient-tap-to-click descomprimido en /root
4- Reemplazar el archivo flsynclient en /usr/bin
5- Reiniciar X ( cltrl+alt+backspace te lleva al prompt y escribes xwin para reiniciar X, servidor grafico, escritorio como se llame )
6- Abrir la terminal y escribir flsynclient
7- Ir a la pestaña tapping y configurar left finger one button

Ahora ya podras hacer click dando 1 toque al touchpad para configurar doble click creo que debes hacerlo desde las opciones de Rox.

_________________
My blog | | Github


Back to top
View user's profile Send private message 
marcelo4768

Joined: 18 Sep 2017
Posts: 9

PostPosted: Wed 08 Jan 2020, 21:20    Post subject: no way  

como todo eso sin mouse ?
Back to top
View user's profile Send private message 
josejp2424


Joined: 01 Aug 2010
Posts: 530

PostPosted: Thu 09 Jan 2020, 13:08    Post subject: Re: no way  

[quote="marcelo4768"]como todo eso sin mouse ?[/quote

Es raro. No te habrá cargado el zdvr.
]

_________________
Shiba Inu | Pupjibaro jessie | My Blog
Back to top
View user's profile Send private message Visit poster's website 
s243a

Joined: 02 Sep 2014
Posts: 2447

PostPosted: Wed 15 Jan 2020, 09:20    Post subject:  

sandbox.sh doesn't work for me:
Code:

[root@dpupbuster64 ~] $ sandbox.sh

mount-FULL: /mnt/sb/fakeroot: wrong fs type, bad option, bad superblock on aufs, missing codepage or helper program, or other error.
Unable to mount aufs br:/mnt/sb/sandbox=rw:Error:=ro:Expected=ro:at=ro:least=ro:6=ro:tokens=ro:for=ro:--checklist,=ro:have=ro:4.=ro:Use=ro:--help=ro:to=ro:list=ro:options.=ro
[root@dpupbuster64 ~] $


It was supposedly fixed:
Quote:

fix sandbox.sh

testing (#2)
@wdlkmpx
wdlkmpx committed on Mar 25, 2018 1 parent a31da76 commit e29f4217baea1c394a59ab0957678d2876f5fa5d


I want to learn about sandbox.sh to run a puppy in a chroot so I probably will need to modify it but first I wanted to see if it worked.

Here's some info on it:
http://distro.ibiblio.org/fatdog/web/faqs/sandbox.html

Edit: This seems to be a woof-CE problem, so I created a new issue:
"sandbox.sh -- items='' #1737"

_________________
Find me on minds and on pearltrees.
Back to top
View user's profile Send private message Visit poster's website 
jamesbond

Joined: 26 Feb 2007
Posts: 3455
Location: The Blue Marble

PostPosted: Wed 15 Jan 2020, 23:42    Post subject:  

s243a wrote:
sandbox.sh
...
This seems to be a woof-CE problem, so I created a new issue:
"sandbox.sh -- items='' #1737"


sandbox.sh used to work. I made the original commit and I made sure that it worked. It only did not work when running off the LiveCD without savefile, because /tmp was a symlink and not a real mounted filesystem, and that could easily be "fixed". When booting with a savefile/savedir, it worked. I had a few posts on this forum (can't find it now) that used sandbox.sh for testing.

Over the years changes to woof-CE apparently made it stops working, and a "fix" was committed in Jan 2018. Sadly the "fix" doesn't work, because it does not address the problem.

The root cause of this particular all the problem is because certain aufs mountpoints cannot be found in /proc/mounts.

See this for yourself. In terminal, type "cat /sys/fs/aufs/si_*/br0". You will see the mountpoint for the topmost layer (either pupsave or tmpfs).
Now "cat /proc/mounts" and see if that mountpoint is listed in there.
Experiment with pfix=ram and with savefile/savedir loaded, and you will see the same result.

This was __certainly__ not the case in the past, and something has been changed in puppy's initrd's init, probably in initrd-skeleton.

Now, demanding rollback to changes to puppy's initrd's init to accomodate one lowly app like sandbox is probably too much, so we just have to live with whatever it is and make sandbox.sh to work again.

The fix is NOT by doing this:
Code:
items="$(echo "$items" | grep squashfs)" #only need SFS's


But it should by doing
Code:
items="$(echo "$items" | grep -E "XXXX|YYYY")"
where XXXX and YYYY represents the top-layer mountpoints when puppy runs with savefile and without savefile (on upup bionic, this would be /initrd/mnt/dev_save and /initrd/mnt/tmpfs/pup_rw).

So my suggestion is to revert that particular "fix" commit and then work out the proper fix.

Until this is done, sandbox functionality should be considered BROKEN and sandbox.sh should be renamed to sandbox-BROKEN.sh until it is fixed.

(NOTE: Though, I would argue, "proper fix" is to make sure that all branches of aufs layers are visible in the /proc/mounts; because with the fix I suggested above, the sandbox will lose its ability to use existing customisations done in the topmost layer (because the topmost layer is now inaccessible) - which reduces it functionality by much).

_________________
Fatdog64 forum links: Latest version | Contributed packages | ISO builder
Back to top
View user's profile Send private message 
s243a

Joined: 02 Sep 2014
Posts: 2447

PostPosted: Thu 16 Jan 2020, 02:57    Post subject:  

jamesbond wrote:
s243a wrote:
sandbox.sh
...
This seems to be a woof-CE problem, so I created a new issue:
"sandbox.sh -- items='' #1737"


sandbox.sh used to work. I made the original commit and I made sure that it worked. It only did not work when running off the LiveCD without savefile, because /tmp was a symlink and not a real mounted filesystem, and that could easily be "fixed". When booting with a savefile/savedir, it worked. I had a few posts on this forum (can't find it now) that used sandbox.sh for testing.

Over the years changes to woof-CE apparently made it stops working, and a "fix" was committed in Jan 2018.

Was the original code committed before puppy started using save folders?
Code:

items=$(
{ echo ==mount==; cat /proc/mounts;
  echo ==losetup==; losetup-FULL -a;
  echo ==branches==; ls -v /sys/fs/aufs/$AUFS_ROOT_ID/br[0-9]* | xargs sed 's/=.*//';
  echo "==finised so print=="; } | \

https://github.com/puppylinux-woof-CE/woof-CE/issues/1737#issue-550190880


Quote:
Sadly the "fix" doesn't work, because it does not address the problem.

The root cause of this particular all the problem is because certain aufs mountpoints cannot be found in /proc/mounts.


by "cannot be found", I presume that you mean, the script can't find them but they are there. Perhaps though, once upon a time the save folder was directly mounted but I don't think that is the case now. Instead, I think only the partition where the savefolder resides is mounted.

Quote:
See this for yourself. In terminal, type "cat /sys/fs/aufs/si_*/br0". You will see the mountpoint for the topmost layer (either pupsave or tmpfs).

With my partial fixes:
Code:

[root@dpupbuster64 ~] $ cat /sys/fs/aufs/si_*/br0
/initrd/mnt/dev_save/dpup_buster/1-07092019/dpupbuster64save=rw
/mnt/sb/sandbox=rw


Quote:
Now "cat /proc/mounts" and see if that mountpoint is listed in there.

The top layer is sort of there. It shows up for me as:
Code:

/dev/sda2 /initrd/mnt/dev_save ext4 rw,noatime 0 0

except that it's missing the path to the save folder, "/dpup_buster/1-07092019/dpupbuster64save" which I don't think is really a mount point (even though it is the top layer).


Quote:

Experiment with pfix=ram and with savefile/savedir loaded, and you will see the same result.

Maybe later.

Quote:
This was __certainly__ not the case in the past, and something has been changed in puppy's initrd's init, probably in initrd-skeleton.

You can get the topy layer via "cat /proc/mounts" by appending to dev_save the path found in "/etc/rc.d" to the save location. From /etc/rc.d/PUPSTATE
Code:

PUPSAVE='sda2,ext4,/dpup_buster/1-07092019//dpupbuster64save'


Quote:
Now, demanding rollback to changes to puppy's initrd's init to accomodate one lowly app like sandbox is probably too much, so we just have to live with whatever it is and make sandbox.sh to work again.

Agreed.

Quote:
The fix is NOT by doing this:
Code:
items="$(echo "$items" | grep squashfs)" #only need SFS's

It's a partial fix but wdlkmpx, didn't really do this correctly anyway, because when we loop through the loop devices, the mount type of "squashfs" gets replaced with the name of the squash file. That's why my improvment to wdlkmpx partial fix was to use the following grep statement:

Code:

items="$(echo "$items" | grep "\(squashfs\|\.sfs\)")" #only need SFS's


but you're correct that we might also want to mount the save layer, so if we fix the awk code then we can get rid of this grep statement that was added by wdlkmpx.


Quote:
But it should by doing
Code:
items="$(echo "$items" | grep -E "XXXX|YYYY")"
where XXXX and YYYY represents the top-layer mountpoints when puppy runs with savefile and without savefile (on upup bionic, this would be /initrd/mnt/dev_save and /initrd/mnt/tmpfs/pup_rw).

These are symlinks which would be a different way to get the top layer and after much head scratching, I see the issue. The issue is that the path to the save layer is different than the mount point but the mountpoint is used as the key when looking up the mounttype in the following statment:

Code:

print $0, mounttypes[$0], "on"

/rootfs-skeleton/usr/bin/sandbox-rw.sh#L112

So when we try to lookup the mounttype using the path to the save file, then it returns nothing, which breaks the gui, because the gui expects three values but it only got two values. wdlkmpx's code changes suggest the viewpoint, that for a sandbox, we don't want the save location anyway. Otherwise it isn't really a sandbox. However, this isn't true if we mount the save-layer as readonly. That way it is still a sandbox. To fix the code we first check that mounttypes[$0] returns a value with a length greater than zero, otherwise maybe print some other value to indicate that it is not a mount point.

BTW, the comparison expression is wrong "else if (mode=4)" but it doesn't seem to matter (I think that this always returns true). For equality comparison it should be mode == 4.

Quote:
]So my suggestion is to revert that particular "fix" commit and then work out the proper fix.

Until this is done, sandbox functionality should be considered BROKEN and sandbox.sh should be renamed to sandbox-BROKEN.sh until it is fixed.


I don't think the fix is that hard so no need to revert the previous so called fix or call it broken.

Quote:
(NOTE: Though, I would argue, "proper fix" is to make sure that all branches of aufs layers are visible in the /proc/mounts; because with the fix I suggested above, the sandbox will lose its ability to use existing customisations done in the topmost layer (because the topmost layer is now inaccessible) - which reduces it functionality by much).


I don't think that this is actually a mount point if it is a save folder. I suppose we could separately mount the save folder but that would be redundant and might cause other issues (e.g. slowdown unmounting during shotwown.).

_________________
Find me on minds and on pearltrees.
Back to top
View user's profile Send private message Visit poster's website 
jamesbond

Joined: 26 Feb 2007
Posts: 3455
Location: The Blue Marble

PostPosted: Thu 16 Jan 2020, 06:10    Post subject:  

Quote:
Was the original code committed before puppy started using save folders?

Yes
Quote:
by "cannot be found", I presume that you mean, the script can't find them but they are there. Perhaps though, once upon a time the save folder was directly mounted but I don't think that is the case now. Instead, I think only the partition where the savefolder resides is mounted.

Correct.

Quote:
except that it's missing the path to the save folder, "/dpup_buster/1-07092019/dpupbuster64save" which I don't think is really a mount point (even though it is the top layer).

Okay. I see you have a point here. I've checked more thouroughly, yes, for LiveCD and savedir, this is the case. For savefile, then br0 is a mountpoint.

Quote:
These are symlinks which would be a different way to get the top layer and after much head scratching, I see the issue. The issue is that the path to the save layer is different than the mount point but the mountpoint is used as the key when looking up the mounttype in the following statment:
Correct.

Quote:
So when we try to lookup the mounttype using the path to the save file, then it returns nothing, which breaks the gui, because the gui expects three values but it only got two values.
Correct.

Quote:
wdlkmpx's code changes suggest the viewpoint, that for a sandbox, we don't want the save location anyway. Otherwise it isn't really a sandbox. However, this isn't true if we mount the save-layer as readonly. That way it is still a sandbox.
Most of the time we want to have a copy of the savelayer in the sandbox, otherwise you don't have /etc/resolv.conf (no network), etc etc. But that's why we have a dialog to enable the user to choose exactly which layer is to be included in the sandbox.

Quote:
To fix the code we first check that mounttypes[$0] returns a value with a length greater than zero, otherwise maybe print some other value to indicate that it is not a mount point.

After thinking about it, here is my updated suggestion. The $items contains 3 fields:
- path
- description
- "on"

Out of this 3 lines, only the first one ("path") is actually used in the next processing.
Our problem is because the top-layer isn't listed in /proc/mounts, the "description" part (which, for SFS, will show the SFS name, and for save-layer would normally show filesystem type (ext3, etc)) is empty. But it is not actually necessary for the rest of the processing, so my suggestion is to modify the awk code so that if mounttypes[$0] is empty, then just output something, e.g file system, or even blank.

So,
Code:
print $0, mounttypes[$0], "on"
becomes
Code:
if (mounttypes[$0])
    print $0, mounttypes[$0], "on"
else
    print $0, "filesystem", "on"

With this changes I can display the layer selection dialog and start sandbox successfully, in LiveCD mode, in savefolder, and in savefile, if I also comment out this line:
Code:
#items="$(echo "$items" | grep "\(squashfs\|\.sfs\)")


Quote:
BTW, the comparison expression is wrong "else if (mode=4)" but it doesn't seem to matter (I think that this always returns true). For equality comparison it should be mode == 4.
There is nothing wrong with this code.

Quote:
I don't think the fix is that hard so no need to revert the previous so called fix or call it broken.
I leave it to the maintainer or whoever is going to offer a patch to decide what to do - whether to revert and apply a new fix, or just apply a fix on to of the existing one.

I only suggest to rename it to -BROKEN so that people don't use it until it is fixed. If the fix can be given/applied in the next few hours then obviously no need to do so.

PS: If you offer a pull request, please make sure you fix sandbox-rw.sh too.

_________________
Fatdog64 forum links: Latest version | Contributed packages | ISO builder
Back to top
View user's profile Send private message 
s243a

Joined: 02 Sep 2014
Posts: 2447

PostPosted: Thu 16 Jan 2020, 23:48    Post subject:  

jamesbond wrote:
PS: If you offer a pull request, please make sure you fix sandbox-rw.sh too.


I created a pull request:
Quote:

fix sandbox.sh & sandbox-rw.sh #1739

Both sandbox.sh and sandbox-rw.sh are broken because:

1. The old script incorrectly assumed a savefolder was a mount point:
2. wdlkmpx, tried to fix this by only allowing sfs files but used the wrong grep expression, which returns nothing.

This fix uses the base filename for the save folder and consequently mitigates the need for wdlkmpx prevoius attempted fix. See discussion:
http://murga-linux.com/puppy/viewtopic.php?p=1047913#1047913

I so far only tested that we can successfully create the sandbox, when running puppy with a save folder. This is an improvement over the previous code but if people want we can do more testing prior to merging.


but for some reason, I don't see it on my github notifications page. Is this normal or am I on some kind of woof-CE naughty list?

_________________
Find me on minds and on pearltrees.
Back to top
View user's profile Send private message Visit poster's website 
s243a

Joined: 02 Sep 2014
Posts: 2447

PostPosted: Yesterday, at 21:09    Post subject:  

I installed ssh-server on DpupBuster. The folder /run/sshd seems to get deleted upon reboot. I recreated this folder with the standard permissions...that you get by creating a new folder in the file manager. Not sure if these permissions are correct. For the ssh server /run/sshd is needed when using the privilege separation option on your ssh server. Privilege separation is the default behavior for the ssh server in openssh.

This is probably a woof-CE bug, so I also reported it on github:
https://github.com/puppylinux-woof-CE/woof-CE/issues/1755

_________________
Find me on minds and on pearltrees.
Back to top
View user's profile Send private message Visit poster's website 
Display posts from previous:   Sort by:   
Page 11 of 11 [163 Posts]   Goto page: Previous 1, 2, 3, ..., 9, 10, 11
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Puppy Projects
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1632s ][ Queries: 12 (0.0250s) ][ GZIP on ]