FYI - Slacko based on slackware-14-beta

[01micko]

Hi Slacko followers

I have just built an iso for the next development cycle of Slacko!

Sorry, it's not available for download as yet, maybe on the weekend.

I am amazed that it is reasonably sane.. posting from it now as a matter of fact. sure, there is about a million bugs but this isn't even pre-alpha! The amazing thing though, on my third build I got a full rox/jwm desktop and internet. I only started working on it last night.

I am going to have a massive to-do list so I thought I may as well start to build this now and maybe a month or so after Slackware-14 goes live we will be ready. It will take a month because Slacky is usually a month behind. I do like their repo, they build stuff like openshot, and gnome packages, come in handy for some users.

For woof followers, at this stage you need to disable the slacky repo. Salix does keep a "current" repo with dep checking, so that's where I got PACKAGES.txt

It is rather bloated though.. 132M iso without mesa. . At least it's not quite keeping up with Moore's Law .

Ok, here is a brief TODO list, mainly involving recompiling;

• seamonkey
  ffmpeg, +x264 and other deps
  mplayer
  gnome-mplayer
  gecko-media-player
  kernel(s)
  abiword
  gnumeric
  geany
  transmission
  xchat
  homebank
  epdfview (or similar)
  gparted

..and that's just the stuff in the iso.

I'm not going to bother with alternate browsers, I do have a script that grabs the latest seamonkey, firefox from the official mirrors, have added Iron to that too. Usually playdayz packages will work with the added deps of GConf and ORBit.

Slickpet will be dying! (I am totally sick of it!). It will be replaced by improved sfs management, improved graphics card detection and hopeful bugfixes to the PPM. This is not negotiable. it's a terribly written program and should have died a long time ago.

I will attempt to integrate techno's jwm_tools. (again). I have a better idea on how to do it. Fixmenus is terribly slow, even on a fast box.

One day (down the track) I am going to dump rox too. Spacefm is the front runner for a replacement. It can do pretty much what rox does and more.

I'm sure plenty would want me to retire JWM too, but no. Not happening. Maybe some improved lxpanel/openbox pets... there has been plenty of recent development with that and mate going on around the forum.

Ok, enough for now.

Cheers

[Lobster]

Hi Mick,
Thanks for keeping us informed.
I look forward to openshot as always.
From an end users perspective quickpet and slickpet were great. Maybe a selection of SFS will compensate.
I always find rox far more powerful than the alternatives, the preference for a simpler file list type program may be a developer need . . .
From an end user perspective I am finding Lucid and now Slacko provide my Puppy fix (once bitten we remain puppy for ever . . .)

Many thanks for all your work and much used and appreciated efforts.

[01micko]

The problem with rox is that it's codebase is getting very old, I can't get it to compile in the latest. We do need to start looking at alternatives.

I'm just totally uninterested in reviving slickpet. PPM should be good enough.

[russoodle]

You're a busy lad, Micko....don't know where you find time for your studies!

Spacefm looks quite comprehensive, doesn't it? I'd be interested in seeing how it goes, integrated within one of your Slack-babies

Ooh....the weekend's nearly here, too....(hint)..

[soundNICK]

Hi Slacko followers

<<snip>>

Cheers

micko01 / other slacko users...

I have been seeing mentions of Scribus having been included
in older(?) slacko menus/repositories, but, cannot find it in
current slacko repo. NOTE: Im using FatSlacko presently.

If I can find this to use with fatSlacko, it will save tracking down
all the files and trying to compile... anyone have link to already
compiled Scribus for slacko, with all the deps ? Im assuming,
if it was in quick/slick pet or menu, it would have been ready
to use.

thanks

soundNICK

[Billtoo]

seamonkey
ffmpeg, +x264 and other deps
mplayer
gnome-mplayer
gecko-media-player
kernel(s)
abiword
gnumeric
geany
transmission
xchat
homebank
epdfview (or similar)
gparted

I managed to get ffmpeg + x264,mplayer,and the new geany compiled in fatslacko.
I swiped the configure line for ffmpeg from fatdog,compiled the x264 snapshot in racy (I think),compiled mplayer,ffmpeg, and vlc 2.0.3 in fatslacko.
The version of qt that vlc is using is the 4.7.0 that comes with kde games so both kdegames and vlc work.
Anyway, having fun and looking forward to the new slacko.

[Iguleder]

I've already ported my distro to Slackware 14.0 and it works well - there won't be any disastrous issues until the release, so I'm just waiting for the final version.

01micko - make sure you have /run, this should go into Woof, too. Here's my solution (lines 15 to 23). Besides this and Mesa's dependency on LLVM, I haven't noticed anything special in 14.0

Regarding my 64-bit Puppy efforts, today I decided to resume work on Slacko64. I got many packages from pet_packages-common and pet_packages-slacko to build on my 64-bit distro, which uses Slackware 13.37 packages. It should be possible to build a slackware64-14.0 Puppy from these, once there is a kernel package - I guess I'll take my distro's kernel.

Since I have a busy week ahead of me, I plan do the first Slacko64 attempt next Friday

[soundNICK]

I've already ported my distro to Slackware 14.0 and it works well <SNIP>

hey igster... here is a request... call it a good idea : -0

I liked using Pdebthing immensely... presently I am working with
fatSlacko. Neither slacko nor slackware currently have dependency
grabber that I am aware of... so Im wondering... would it be
possible to use slackware repositories in Pdebthing, as it is,
to grab packages and dependencies, or, will Pdebthing /only/
work for getting debian files ? If this is the case, maybe
modifying Pdebthing shouldnt be too difficult, to produce
a PslaxThing ?

something which could get just packages and dependencies,
with the extracting / building of pet/SFS done manually would
be a major help for slacko.

Is this something you would be interested in throwing together ?
To me, building an entire distro... the roar-ng way... is over-doing
it, when all one requires is a latest music app / game / whatever.

any interest in doing a "PslaxThing" ?

thanks for looking

soundNICK

[01micko]

01micko - make sure you have /run, this should go into Woof, too. Here's my solution (lines 15 to 23). Besides this and Mesa's dependency on LLVM, I haven't noticed anything special in 14.0

Thanks Iguleder, I nearly went that way but I ended up following the FatDog lead and symlinking /run to /tmp. Seems to work fine.

On another note, busybox depmod doesn't produce good enough files to load the modules, so I am running full depmod in rc.sysinit and that fixed that. No harm there I think.

I have squashed a heap of bugs and compiled a heap of stuff and will likely upload a snapshot tomorrow. This will mainly be to gauge booting on different hardware and wireless network issues, they are always the main ones. There is also the 'vesa' bug where it boots to desktop out of range of some monitors, giving the user the impression that it has hung. Racy suffers this bug too on my hardware, Sage has also been a victim of this bug, so maybe it will get Barry's attention.

I am also using k3.2.26 compiled today. Seems pretty solid, also updated udev to 174, not the latest but it is late enough to compile Spacefm with it's internal vfs. I also have to patch glib2 with jemimah's patch for browsers so "help" works in abiword, gnumeric, geany, homebank. I'm thinking of tossing the other patch for '/mnt' and symlinking /media to /mnt.. anyone ever tried that? It seems the /mnt path is deprecated, every other linux use /media and have for awhile. Thoughts on that? maybe it's a T2 thing?

ok.. until tomorrow

[npierce]

It seems the /mnt path is deprecated, every other linux use /media and have for awhile. Thoughts on that?

If I remember correctly, the /media/ directory, was created to hold mount points for removable media only (floppies, SyQuest drives, Zip drives, CD-ROMs, flash drives, etc.) as an alternative to the common (but unofficial) practice of placing mount points for removable media in /mnt/.

Originally /mnt/ was a single temporary mount point, not a directory of mount points. So the creation of the /media/ directory was supposed to allow allow /mnt/ to go back to its original use as a single mount point.

Unfortunately, most Linux users also need to mount various filesystems that are not on removable media, such as various hard drive partitions and network shares. Since no alternative directory was created for holding those mount points, and since folks don't like to clutter up the top-level directory with a bunch of mount points, /mnt/ continues to be used for that purpose.

The Filesystem Hierarchy Standard 2.3 would still like /mnt/ to return to its original job as a single temporary mount point, but the standard still fails to give an alternative for filesystems that are not on removable media. So it is little wonder that /mnt/ continues to be used to hold mount points for such filesystems.

Personally, since the creation of /media/ failed to eliminate the need to use /mnt/ as a directory of mount points, I'd be happy to see the Linux community return to simply using /mnt/ for both removable and non-removable filesystems -- a practice that goes back at least a decade and a half. One of the 735 things that I liked about Puppy when I first discovered it was the fact that it had no /media/ directory, and I didn't have to stop and think about whether a filesystem was or was not on removable media before I mounted it. Besides "mnt" is easier to type and results in shorter pathnames than "media"

Of course, since /media/ is in the standard, and has gained popularity, having it available -- possibly as a symlink -- is probably a good idea. I wouldn't eliminate /mnt/.


Related reading - - -
Filesystem Hierarchy Standard 2.3:
/media : Mount point for removeable media
/mnt : Mount point for a temporarily mounted filesystem

[01micko]

Hi npierce

Thanks for the input.

I will create media as a symlink to /mnt. We'll see how well it works.

Cheers.

[Karl Godt]

Sage has also been a victim of this bug, so maybe it will get Barry's attention.

LOL

I'm thinking of tossing the other patch for '/mnt' and symlinking /media to /mnt.. anyone ever tried that? It seems the /mnt path is deprecated, every other linux use /media and have for awhile. Thoughts on that?

e17 if working hal and dbus correctly uses /media directory (a least for Macpups 4.3x) - but their's versions don't seem to update removeable devices "on the fly"

busybox depmod doesn't produce good enough files to load the modules, so I am running full depmod in rc.sysinit and that fixed that. No harm there I think.

I have always been a defender of busybox !
busybox depmod normally should create output like that :

/lib/modules/2.6.30.9-i586-dpup005-Celeron2G/kernel/crypto/DRIVER.ko[.cmpress]
(the full path at least for the Puppy 4.3 original busybox)

and normal depmod
kernel/crypto/DRIVER.ko[.cmpress]

but BB version 1.18.3 seems to create output like the normal depmod-FULL . ,which i don't like .

[Karl Godt]

Ah, and don't forget about the bluetooth drivers in the man eating halls of the kernel menuconfig .

[Karl Godt]

Ooh....the weekend's nearly here, too....(hint)..

After a rainy month-07 (barleycorn-month) we have beach weather since yesterday .