These are also missing in Puppy, so it's not Nathan's fault...plinej wrote:libgdk-x11-2.0.so
libatk-1.0.so
libgdk_pixbuf-2.0.so
libpangocairo-1.0.so
libpango-1.0.so
libpangoft2-1.0.so
libpangomm-1.4.so
libpangox-1.0.so
libpangoxft-1.0.so
libgtkmm-2.4.so
libgobject-2.0.so
libgmodule-2.0.so
libglib-2.0.so
Grafpup-2.xx fourth (and final) alpha
- Dougal
- Posts: 2502
- Joined: Wed 19 Oct 2005, 13:06
- Location: Hell more grotesque than any medieval woodcut
What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind
Some say your nose
Some say your toes
But I think it's your mind
- Nathan F
- Posts: 1764
- Joined: Wed 08 Jun 2005, 14:45
- Location: Wadsworth, OH (occasionally home)
- Contact:
No actually it is, at least partially. I took Puppy's devx module and just dropped in my development packages over it. However, Barry puts these "third level" symlinks in devx rather than the iso, whereas I put them in the iso. So for a lot of the packages that I upgraded there were stale symlinks laying around in there. Since devx gets inserted into the union above the main filesystem they were covering them up.
This is also why I didn't encounter the problem, because I added mine while the system was already running, using the aufs utils, and it was loaded below graf_004.sfs in the union. So the symlinks in the filesystem were covering those in devx in my case.
It's a moot point now though, because I uploaded a revised version. However I still can't gaurantee it will be perfect.
Nathan
This is also why I didn't encounter the problem, because I added mine while the system was already running, using the aufs utils, and it was loaded below graf_004.sfs in the union. So the symlinks in the filesystem were covering those in devx in my case.
It's a moot point now though, because I uploaded a revised version. However I still can't gaurantee it will be perfect.
Nathan
Bring on the locusts ...
- Nathan F
- Posts: 1764
- Joined: Wed 08 Jun 2005, 14:45
- Location: Wadsworth, OH (occasionally home)
- Contact:
Well supposing you have mounted devx_004.sfs on /initrd/graf_ro4, either with losetup or just a mount -o loop. You would then do this:
There are a few other options you can specify also, but that's the gist of it. You can also remove branches, but it seems to be unreliable. It works on my main desktop but not on my kids box. The only reason I can find is a difference in the amount of physical memory. Anyway, to remove a branch the command is identical except you would replace "append" with "del".
You have to use mount-FULL because plain mount is a busybox applet that can't cope correctly with what aufs is asking it to do. The command syntax was different in unionfs, where it used the unionctl command. Aufs contains a script that is supposed to translate the unionctl command into the "mount -o remount" commands used by aufs, but it didn't work when I tried it so I removed it from the package to avoid anyone stuffing up their system.
I plan to take advantage of this ability pretty soon with a small utility, basically just a filechooser that lets you add in squashfiles as aufs branches while already running. I had a more advanced system in place in an earlier Grafpup, but the union was then on /usr so everything worked more reliably. Anyhow the little chooser is already partially written, but has sat now for a few weeks.
Nathan
Code: Select all
mount-FULL -o remount,append:/initrd/graf_ro4 /
You have to use mount-FULL because plain mount is a busybox applet that can't cope correctly with what aufs is asking it to do. The command syntax was different in unionfs, where it used the unionctl command. Aufs contains a script that is supposed to translate the unionctl command into the "mount -o remount" commands used by aufs, but it didn't work when I tried it so I removed it from the package to avoid anyone stuffing up their system.
I plan to take advantage of this ability pretty soon with a small utility, basically just a filechooser that lets you add in squashfiles as aufs branches while already running. I had a more advanced system in place in an earlier Grafpup, but the union was then on /usr so everything worked more reliably. Anyhow the little chooser is already partially written, but has sat now for a few weeks.
Nathan
Bring on the locusts ...
Hi,
Just registered in order to join the discussion on Grafpup latest test version (20070321). Firstly many thanks for creating Grafpup! It seems like the ideal Puppy for my new server.
I have a VIA mini ITX motherboard and want to compile C programs on it. It will also be a data server using Samba. I can successfully boot Grafpup from IDE CF Card, including the devx package. I have the card formatted as a superfloppy of 512Mb.
I had one issue with the IDE CF card, which was that when I came to save my session to the card (for it was the only storage, and will continue to be, as HDDs will only be used for data). Initially I saved the session files to hda 'as a partition' but that caused problems on reboots, giving the error message "graf_ro2 is overlapped" then a Kernel Panic, settling into repeated "atkbd.c Spurious ACK on isa0060".
The workaround was to make an SFS file on the memory card, instead of my preferred solution of using the entire parition. However, the workaround was successful and reboots are now reliable, and I also load the devx sfs from the card.
The board's LAN port (VIA Rhine 10/100) comes up at 10 mbps half duplex. I don't know why yet, perhaps some parameters in modules.conf might help my board.
The only other problem at present is that my SATA HDD is not recognised. It's attached to an Si3114 based controller card. 'Conventional' Puppy 2.14 recognises it just fine.
However my motivation for using Grafpup is the presence of usernames, and this machine will end up as a headless server with only Samba access & SSH login. Thus I need distinct usernames.
Compiling works well for me but my programs are small and simple. I do use Subversion so thanks for including that....
Last point for now, the Release Notes of what I thought was the 20070321 iso appear to include the date 19/3/07. I need to bust open the iso again and check it, to be sure.
Perhaps the overlap issue is unexpected since all my other issues are hardware related and are due to drivers/etc not present. I am fairly good with linux, but by no means an expert.
Just registered in order to join the discussion on Grafpup latest test version (20070321). Firstly many thanks for creating Grafpup! It seems like the ideal Puppy for my new server.
I have a VIA mini ITX motherboard and want to compile C programs on it. It will also be a data server using Samba. I can successfully boot Grafpup from IDE CF Card, including the devx package. I have the card formatted as a superfloppy of 512Mb.
I had one issue with the IDE CF card, which was that when I came to save my session to the card (for it was the only storage, and will continue to be, as HDDs will only be used for data). Initially I saved the session files to hda 'as a partition' but that caused problems on reboots, giving the error message "graf_ro2 is overlapped" then a Kernel Panic, settling into repeated "atkbd.c Spurious ACK on isa0060".
The workaround was to make an SFS file on the memory card, instead of my preferred solution of using the entire parition. However, the workaround was successful and reboots are now reliable, and I also load the devx sfs from the card.
The board's LAN port (VIA Rhine 10/100) comes up at 10 mbps half duplex. I don't know why yet, perhaps some parameters in modules.conf might help my board.
The only other problem at present is that my SATA HDD is not recognised. It's attached to an Si3114 based controller card. 'Conventional' Puppy 2.14 recognises it just fine.
However my motivation for using Grafpup is the presence of usernames, and this machine will end up as a headless server with only Samba access & SSH login. Thus I need distinct usernames.
Compiling works well for me but my programs are small and simple. I do use Subversion so thanks for including that....
Last point for now, the Release Notes of what I thought was the 20070321 iso appear to include the date 19/3/07. I need to bust open the iso again and check it, to be sure.
Perhaps the overlap issue is unexpected since all my other issues are hardware related and are due to drivers/etc not present. I am fairly good with linux, but by no means an expert.
- Nathan F
- Posts: 1764
- Joined: Wed 08 Jun 2005, 14:45
- Location: Wadsworth, OH (occasionally home)
- Contact:
Hey first off, thanks for the feedback. Let me go through a few things in your post here.
Since Grafpup is now using a new kernel it is probable that there will be at least one or two regressions as far as hardware support go. Having said that most of the reports I'm getting are favorable in this regard, as is my own experience. I can promise I'll look into your sata issue though, because that kind of disturbs me.
Interesting use for Grafpup you have there too. I would like to point out that if the box is going to run just as a server then the ability to run X as a non-root user is kind of a moot point. You can create and modify users in Puppy as well, and do just about anything command line related without being root (as long as you have permissions for it that is). The only limitation user-wise in Puppy right now is the ability to run X as non-root.
Now, the release notes are off as you stated. I had originally planned to get this one out the door two days earlier but time got away from me. Basically I forgot to update the date in the release notes when I pushed the release back.
Anything you think I can do to make Grafpup better don't hesitate to drop me a note. I can't be everywhere at once but I try to take all critiques seriously.
Nathan
Since Grafpup is now using a new kernel it is probable that there will be at least one or two regressions as far as hardware support go. Having said that most of the reports I'm getting are favorable in this regard, as is my own experience. I can promise I'll look into your sata issue though, because that kind of disturbs me.
Interesting use for Grafpup you have there too. I would like to point out that if the box is going to run just as a server then the ability to run X as a non-root user is kind of a moot point. You can create and modify users in Puppy as well, and do just about anything command line related without being root (as long as you have permissions for it that is). The only limitation user-wise in Puppy right now is the ability to run X as non-root.
Now, the release notes are off as you stated. I had originally planned to get this one out the door two days earlier but time got away from me. Basically I forgot to update the date in the release notes when I pushed the release back.
Anything you think I can do to make Grafpup better don't hesitate to drop me a note. I can't be everywhere at once but I try to take all critiques seriously.
Nathan
Bring on the locusts ...
Have you messed with the cdrkit package yet? I got it all compiled but haven't tried it out yet. It depends on an extra library though (libcap). I compiled libcap-1.92 and it's only 24.3 kilobytes. From what I've read is the binaries all have different names and symlinks should be placed since they use the same parameters. wodim is the replacement binary for cdrecord. I'll play around with it and see if it works out.
Here are dmesg outputs from both Grafpup 20070321 and 'Plain Puppy' 2.14 running on the same hardware (VIA Eden M10000 mobo).
The Sata card (card, not integrated) is not reported under Grafpup.
If I read correctly, Puppy 2.14 uses kernel 2.6.18.1 which does detect the SATA correctly.
And also if I read your comments correctly, I might be able to use plain Puppy (really, a cut down one such as Barebones. I just need to satisfy myself it will be fairly secure -- my compiled programs shouldn't really run as root. I would also have to remove the automatic root login.
If as you say, other users can be added under plain Puppy (without much drama) then it might be a good solution. I'll have a look.
I followed the Grafpup route since it has multi users set up, and my programs also have an imaging purpose. I will be generating graphic files & mpeg films which I could view while physically at the server, or remotely using VNC or remote X desktop. Without X, I could 'get by' but I think it would make life easier.
The Sata card (card, not integrated) is not reported under Grafpup.
If I read correctly, Puppy 2.14 uses kernel 2.6.18.1 which does detect the SATA correctly.
And also if I read your comments correctly, I might be able to use plain Puppy (really, a cut down one such as Barebones. I just need to satisfy myself it will be fairly secure -- my compiled programs shouldn't really run as root. I would also have to remove the automatic root login.
If as you say, other users can be added under plain Puppy (without much drama) then it might be a good solution. I'll have a look.
I followed the Grafpup route since it has multi users set up, and my programs also have an imaging purpose. I will be generating graphic files & mpeg films which I could view while physically at the server, or remotely using VNC or remote X desktop. Without X, I could 'get by' but I think it would make life easier.
- Attachments
-
- dmesg_puppy214.gz
- (4.78 KiB) Downloaded 341 times
Nathan, I also ran across this cd burning project:
http://libburnia.pykix.org/
I've compiled those 2 programs and will probably do some playing around this weekend.
The wrapper program called cdrskin is designed to run with the same parameters passed to cdrecord.
http://libburnia.pykix.org/
I've compiled those 2 programs and will probably do some playing around this weekend.
The wrapper program called cdrskin is designed to run with the same parameters passed to cdrecord.
The cdrskin cli frontend for libburn looks promising. They're still working on a cli frontend for libisofs called genisofs that will be mkisofs compatible. I'll try out the genisoimage from the cdrkit package, that is their version of mkisofs.
Last edited by plinej on Thu 05 Apr 2007, 03:02, edited 1 time in total.
- klhrevolutionist
- Posts: 1121
- Joined: Wed 08 Jun 2005, 10:09
- Nathan F
- Posts: 1764
- Joined: Wed 08 Jun 2005, 14:45
- Location: Wadsworth, OH (occasionally home)
- Contact:
I thought it must be fixable with a permissions change. Sorry I haven't gotten to this yet. I had to recompile the kernel again because of a few mistakes I made doing the config the first time. Kind of a long process, especially since it means recompiling all the extra drivers also, and right now I only have ssh access to my machine. Anyway I'm glad to have that done, and now sata and firewire should both be fixed.
Considering all the possible permutations of hardware, with multiple optical drives possible as well as sata changing the naming, I think it might be best to modify the cd/dvd wizard to do any chmod'ing of the dev files, rather than to set the permissions when the iso is built. I'drather not have too many block devices that are world writable. If it turns out that this is all that needs done the fix could be in place with a couple minutes work
Nathan
Considering all the possible permutations of hardware, with multiple optical drives possible as well as sata changing the naming, I think it might be best to modify the cd/dvd wizard to do any chmod'ing of the dev files, rather than to set the permissions when the iso is built. I'drather not have too many block devices that are world writable. If it turns out that this is all that needs done the fix could be in place with a couple minutes work
Nathan
Bring on the locusts ...