ArchPup - First Puppy with pacman for installing apps
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
stif,
Don't remember precisely when, but I added this in rc.sysinit (It was needed by cups daemon)
ping localhost and ping 127.0.0.1 work this way, could you test that or maybe I should make replacement in rc.sysinit with
Edit: For starting dbus looks like /etc/init.d/messagebus needs some fixing, it reports missing /run/dbus/system_bus_socket.
And only reason I added exec dbus-launch $WINDOW_MANAGER in /root/.xinitrc was to get thumbnails to show in thunar (tumbler used it).
In spacefm thumbnails are shown without it, but something else might need dbus-daemon so I'll leave this line.
Don't remember precisely when, but I added this in rc.sysinit (It was needed by cups daemon)
Code: Select all
ifconfig lo up
Code: Select all
ifconfig lo up 127.0.0.1
And only reason I added exec dbus-launch $WINDOW_MANAGER in /root/.xinitrc was to get thumbnails to show in thunar (tumbler used it).
In spacefm thumbnails are shown without it, but something else might need dbus-daemon so I'll leave this line.
Last edited by simargl on Tue 22 Jan 2013, 20:43, edited 3 times in total.
I followed this guide http://chakra-linux.org/wiki/index.php/D-Bus and after adding
dbus group and user and changing PIDFILE=/var/run/dbus/pid to PIDFILE=/run/dbus/pid
in /etc/init.d/messagebus dbus seems to start regularly.
No need for launching dbus within /root/.xinitrc so that line is removed.
dbus group and user and changing PIDFILE=/var/run/dbus/pid to PIDFILE=/run/dbus/pid
in /etc/init.d/messagebus dbus seems to start regularly.
No need for launching dbus within /root/.xinitrc so that line is removed.
Here is example rc.conf from earlier Arch Linux http://kissmyarch.blogspot.com/p/etcrc.html. You see that it also has network
setup, so I want to implement that in ArchPup. Here is current /etc/rc.conf:
and /etc/init.d/network daemon that reads info from rc.conf
What do you think about this? Is it possible to setup wireless this way? Obviously this needs
fixing for static IP, but it's just beginning. Also, I'm not at all expert in all of those different network
configurations so your help is welcome (and needed).
setup, so I want to implement that in ArchPup. Here is current /etc/rc.conf:
Code: Select all
#!/bin/sh
# USER SELECTED VARIABLES
X_AUTOLOGIN="yes"
AUTOMOUNT_VOLUMES="no"
SAVEFILE_DIALOG_FORCE="no"
DAEMONS="metalog alsa cups messagebus network rc.pcmcia rsync Pwireless2 sfs_load"
MODULES=""
# NETWORK
# Use 'ip addr' or 'ls /sys/class/net/' to see all available interfaces.
#
# Wired network setup
# - interface: name of device (required)
# - address: IP address (leave blank for DHCP)
# - netmask: subnet mask (ignored for DHCP)
# - gateway: default route (ignored for DHCP)
#
# Static IP example
# interface=eth0
# address=192.168.0.2
# netmask=255.255.255.0
# gateway=192.168.0.1
#
# DHCP example
# interface=eth0
# address=
# netmask=
# gateway=
interface=eth0
address=
netmask=
gateway=
Code: Select all
#!/bin/sh
#
# Starting and stopping wired network
. /etc/rc.conf
case $1 in
start)
ifconfig $interface up
dhcpcd $interface ;;
stop)
ifconfig $interface down
killall dhcpcd ;;
*)
echo "Usage: network {start|stop}"
exit 1
esac
fixing for static IP, but it's just beginning. Also, I'm not at all expert in all of those different network
configurations so your help is welcome (and needed).