ArchPup - First Puppy with pacman for installing apps
I've made quick test of what will happen if there are two files that that fit adrv name: 'adrv-*_132.sfs'. So I renamed
libreoffice.sfs to adrv-libreoffice.sfs_132.sfs, rebooted and.... only adrv-openbox_132.sfs was loaded. For next attempt
I used adrv-xlibreoffice.sfs_132.sfs, and in that case got environment variable was not set. So, init
script loads sfs file which beginning letter comes after in alfabet , oposite of what I expected - but it's still OK.
libreoffice.sfs to adrv-libreoffice.sfs_132.sfs, rebooted and.... only adrv-openbox_132.sfs was loaded. For next attempt
I used adrv-xlibreoffice.sfs_132.sfs, and in that case got environment variable was not set. So, init
script loads sfs file which beginning letter comes after in alfabet , oposite of what I expected - but it's still OK.
stifiling wrote:Scooby,Scooby wrote:I tried Carolina puppy linux - vertical two finger scroll does work out of the
box.
maybe you could try this massive procedure of changing to the carolina kernel, and see if you have more luck with it.
I removed everything from xorg.conf.d except 20-intel.conf
Then I replaced my xorg.conf with the one from Carolina
Woe and behold, mouse-gestures work!
Hope I didnt brake anything in the process.
also added syndaemon to .xinitrc which disables touchpad during typing.
I run a modified synaptics driver, I dunnow if it is needed but I use
xf86-input-synaptics-mtpatch from AUR
Thank god I didnt have to change kernels, puh!
Thanks for pointing me in right direction stifling.
I feel there is a little unresponsiveness after tap. anyone know good configuration
for touchpad, taptime etc?
Oh no! FlashPlayer/iPlayer issues again?!
The default FP on offer doesn't seem to work with the default Firefox? [But there is also a problem with a simple restartX command in ArchPup]. We've run into this with just about every other Pup, so it needs one of the GB gurus like TerryP to advise on the best (only?!) FP version that matches e.g. FF version in the repo. Blame Adobe, but it doesn't help.
Again, as with other early Pup developments, strongly recommend a default browser, even if it's Dillo, so that we can gain immediate access to the InterWeb. It would also help to have a (non-CLI) one-button menu item to get the default packages installed if it is the intention not to have these in the base .iso. Please stick BBCRadio4 or WorldService in the default radio list - almost sine qua non; can live with most radio streams, certainly without mid-European mathematical apologies for 'music' , but world+dog needs one authoritative speech channel, surely?! Radio Moscow or Al-Jezeera also operate acceptable news channels in the b*st*rd language that most of the world manages with.
{PS. Personally don't care for the .sfs approach - too cumbersome, all-embracing and pre-determined, apart from which these lean-mean versions are best suited to mobile liveCD without predetermined machine options already containing savefiles.}
It'll be an interesting struggle to keep this one down to 78Mb as the suggestions/demands for defaults roll in.
The default FP on offer doesn't seem to work with the default Firefox? [But there is also a problem with a simple restartX command in ArchPup]. We've run into this with just about every other Pup, so it needs one of the GB gurus like TerryP to advise on the best (only?!) FP version that matches e.g. FF version in the repo. Blame Adobe, but it doesn't help.
Again, as with other early Pup developments, strongly recommend a default browser, even if it's Dillo, so that we can gain immediate access to the InterWeb. It would also help to have a (non-CLI) one-button menu item to get the default packages installed if it is the intention not to have these in the base .iso. Please stick BBCRadio4 or WorldService in the default radio list - almost sine qua non; can live with most radio streams, certainly without mid-European mathematical apologies for 'music' , but world+dog needs one authoritative speech channel, surely?! Radio Moscow or Al-Jezeera also operate acceptable news channels in the b*st*rd language that most of the world manages with.
{PS. Personally don't care for the .sfs approach - too cumbersome, all-embracing and pre-determined, apart from which these lean-mean versions are best suited to mobile liveCD without predetermined machine options already containing savefiles.}
It'll be an interesting struggle to keep this one down to 78Mb as the suggestions/demands for defaults roll in.
The idea with sticking to SFS and Pacman is to keep package management consistent. Hopefully a pacman GUI will be included in the non-super-tinkerer edition.
I think the way to go is make Puppy programs work on standard Arch, then they will work on Puppy, ArchPup and Arch Linux. This has already been done with PBurn - though I haven't tested myself.
I think the way to go is make Puppy programs work on standard Arch, then they will work on Puppy, ArchPup and Arch Linux. This has already been done with PBurn - though I haven't tested myself.
Pacman GUI would be overkill? As indicated, it is entirely a personal factor of the way I prefer to work that I don't use the .sfs system, chacun a son gout.
As for 'mak(ing) Puppy programs work on standard Arch' surely somewhat pretentious?! Arch is, as its name suggests, arcane and archaic, the sort of distro designed to deter incomers, but entirely fine for those skilled in the art. Definitely not in the Puppy tradition of simplicity and intuitiveness. It will always be a minority sport, but none the worse for that. Might be better if those that are able, to contribute to ARM projects, notably RPi at present, which is clearly in the mind of BK. Pacman is not adopted by any of the major developers so is not a logical choice.
As for 'mak(ing) Puppy programs work on standard Arch' surely somewhat pretentious?! Arch is, as its name suggests, arcane and archaic, the sort of distro designed to deter incomers, but entirely fine for those skilled in the art. Definitely not in the Puppy tradition of simplicity and intuitiveness. It will always be a minority sport, but none the worse for that. Might be better if those that are able, to contribute to ARM projects, notably RPi at present, which is clearly in the mind of BK. Pacman is not adopted by any of the major developers so is not a logical choice.
what if you do:Scooby wrote:Batti com plains about no socket in run/dbus/system-bus-socket
Code: Select all
mkdir /run/dbus
dbus-daemon --system
Re: ArchPup - First Puppy with pacman for installing apps
Is this the current thinking or leftover from previous versions of the first post?simargl wrote: Here I will add my To-do list, changes compared to stable version and other future plans related to ArchPup development:
21 Jan
<snip>
- make two iso images:
- -one with only window manager, text editor and file manager --> small number of gui applications, and all inside adrv.sfs
-second with archapps added to adrv.sfs. Down-side is that all development files from archapps must be in adrv.sfs
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
outputstifiling wrote:
what if you do:
does batti run?Code: Select all
mkdir /run/dbus dbus-daemon --system
Code: Select all
[12:11 root@archpup ~] > dbus-daemon --system
Unknown username "polkitd" in message bus configuration file
Unknown username "polkitd" in message bus configuration file
Failed to start message bus: Could not get UID and GID for username "dbus"
Stifing I want to ask you another question.
I have an older computer on which I want to run ArchPup but when I start it it says
it can only handle non-pae kernel.
Is there a non-pae Arch-Kernel and do you think it'll work using your standard
"replace the kernel"-method. If so do I have to downgrade packages?
Would you please give some input before I embark on this en devour?
A number of puppies are using vattery.Scooby wrote:anyone know a good battery monitor for archpup?
tried batterymon-clone but I get division by zero error
Batti com plains about no socket in run/dbus/system-bus-socket
Vaterry is in AUR. You may want to try it.
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
I was thinking what is the best way to distribute next version, so here is final decision for version 132, that will be based on
packages from 1st February 2013:
- First there will be archpup-132-alpha, iso with only archpup.sfs and adrv.sfs size around 80 Mb.
- After some period of testing and probably fixing this alpha version, next iso will be archpup.sfs+adrv.sfs+archapps.sfs
and around 150 Mb size. I will no longer make this minimal 80 MB iso, because everyone can remove archapps.sfs and still
OS would be functional.
- In archapps will be included pacmanxg4, but not yaourt. Instead for managing packages from AUR there will be packer in
another sfs - archdev. Reason is simple, you need development sfs to compile packages from AUR, so packer is moved to
that module.
- Evince will be removed, and as new pdf viewer there will be qpdfview
- Under system menu new entry is added "Update package databases", easier for beginners no need for manual pacman -Sy.
packages from 1st February 2013:
- First there will be archpup-132-alpha, iso with only archpup.sfs and adrv.sfs size around 80 Mb.
- After some period of testing and probably fixing this alpha version, next iso will be archpup.sfs+adrv.sfs+archapps.sfs
and around 150 Mb size. I will no longer make this minimal 80 MB iso, because everyone can remove archapps.sfs and still
OS would be functional.
- In archapps will be included pacmanxg4, but not yaourt. Instead for managing packages from AUR there will be packer in
another sfs - archdev. Reason is simple, you need development sfs to compile packages from AUR, so packer is moved to
that module.
- Evince will be removed, and as new pdf viewer there will be qpdfview
- Under system menu new entry is added "Update package databases", easier for beginners no need for manual pacman -Sy.
Looks like a good plan.simargl wrote: - First there will be archpup-132-alpha, iso with only archpup.sfs and adrv.sfs size around 80 Mb.
- After some period of testing and probably fixing this alpha version, next iso will be archpup.sfs+adrv.sfs+archapps.sfs
and around 150 Mb size. I will no longer make this minimal 80 MB iso, because everyone can remove archapps.sfs and still
OS would be functional.
However you may want to try the "big" version as alpha.
Three reasons,
more people (including novices) may use it and thus identify more issues (which of course means more work ). But the common wisdom is " the wider the testing, the better the app/pup"
May reveal apps related bugs that will go unnoticed/undetected with a "small" alpha till is too late.
Will give you the chance to have some user feedback on the kind/mix of apps you will include in the "final" release.
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
I like the idea of "big" version as alpha as well. Great reasons listed!mavrothal wrote:Looks like a good plan.simargl wrote: - First there will be archpup-132-alpha, iso with only archpup.sfs and adrv.sfs size around 80 Mb.
- After some period of testing and probably fixing this alpha version, next iso will be archpup.sfs+adrv.sfs+archapps.sfs
and around 150 Mb size. I will no longer make this minimal 80 MB iso, because everyone can remove archapps.sfs and still
OS would be functional.
However you may want to try the "big" version as alpha.
Three reasons,
more people (including novices) may use it and thus identify more issues (which of course means more work ). But the common wisdom is " the wider the testing, the better the app/pup"
May reveal apps related bugs that will go unnoticed/undetected with a "small" alpha till is too late.
Will give you the chance to have some user feedback on the kind/mix of apps you will include in the "final" release.
mavrothal & xstylezx,
That all sounds reasonable, but with my upload speed (or slowness) it takes more than 2 hours to upload
this small iso with 80MB. Imagine time required for uploading full CD size 700 MB.. actually no need to imagine
I just would not do it. archapps sfs will mostly stay as-is now, although with qpdfview and
pacmanxg added so I'm hoping there will be no problems.
Scooby,
I think conky also has support for battery monitor, so that's another option.
That all sounds reasonable, but with my upload speed (or slowness) it takes more than 2 hours to upload
this small iso with 80MB. Imagine time required for uploading full CD size 700 MB.. actually no need to imagine
I just would not do it. archapps sfs will mostly stay as-is now, although with qpdfview and
pacmanxg added so I'm hoping there will be no problems.
Scooby,
I think conky also has support for battery monitor, so that's another option.
Ouch.simargl wrote: That all sounds reasonable, but with my upload speed (or slowness) it takes more than 2 hours to upload
this small iso with 80MB.
For the testing phase, you may want to use deltas of whatever is already uploaded.
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
Sorry I repeat my question here
I have an older computer on which I want to run ArchPup but when I start it it says
it can only handle non-pae kernel.
Is there a non-pae Arch-Kernel and do you think it'll work to insert kernel?
Do you have to recompile?
If so do I have to downgrade packages?
Vattery works fine but is not the styliest , Conky looks very interesting I think
I'm gonna tinker a bit with it
I fixed batterymon. I realized it was a script file and not a binary.
So I added check for avoiding division by zero. Guess I have hacked in python now as well
seems to work! notifications and all
I have an older computer on which I want to run ArchPup but when I start it it says
it can only handle non-pae kernel.
Is there a non-pae Arch-Kernel and do you think it'll work to insert kernel?
Do you have to recompile?
If so do I have to downgrade packages?
Vattery works fine but is not the styliest , Conky looks very interesting I think
I'm gonna tinker a bit with it
I fixed batterymon. I realized it was a script file and not a binary.
So I added check for avoiding division by zero. Guess I have hacked in python now as well
seems to work! notifications and all
Last edited by Scooby on Tue 22 Jan 2013, 19:30, edited 1 time in total.
yes:Scooby wrote:maybe create users?, huh? No time to tinker for me now, at work.
Code: Select all
adduser dbus
Code: Select all
rm /var/run/dbus/pid &
dbus-daemon --system &
i'm presently using the retroprecise non-pae kernel and it's working perfectly fine. at the same time though, i'm still using archpup-12.12.iso which is before 12.12.1 and 12.12.2 and also before the adrv was implemented. i will be upgrading to the new release though.Scooby wrote:I have an older computer on which I want to run ArchPup but when I start it it says it can only handle non-pae kernel.
so with all that being said, i don't see why switching the kernel using the method i illustrated wouldn't work. bark_bark_bark had a problem getting it to work though, on the newer archpup. so i can't say for 'certain' that it'll work, but i don't see why it wouldn't.
if you decide to try it out, let me know if it works. if you're getting that same 'error loading to ram/sfs mount' issue that bark_bark_bark was saying he got, when he tried using the slacko kernel.....i'll take a closer look at it.
sim,
are you able to:
i was testing samba and couldn't see my own shares and narrowed it down to having to first run the command:
i was then able to ping localhost.
are you able to:
Code: Select all
ping localhost
Code: Select all
ifconfig lo 127.0.0.1