We already have all of the useful changes between it and 1.0.0; in fact, there's one change (my patch) in 1.0.1 that we definitely don't need, so we'll be passing on 1.0.1.

1 members found this post helpful.

Ah okay. Thanks Robby.

new cups-filter-1.8.2 (bug fix and enhancement)

https://www.openprinting.org/downloa...s-1.8.2.tar.xz

Just suggestion, maybe it's better to recompile gnome-keyring with libcap-ng.

newt was recently included in -current, but the source archive comes from Fedora, that is supposed to be upstream but does not actually use it and does zero maintenance (there are annoying pending bugs and "git log" is a desert). On the other hand Debian maintains newt more actively, because it uses whiptail in their text installer. So for instance they do apply a bidi patch that brings bidi to whiptail, shamelessly discarded by Fedora as shown in the ChangeLog, among others.

So I propose to use the source coming by Debian and to apply their patches. I have downloaded http://http.debian.net/debian/pool/m...18.orig.tar.xz and http://http.debian.net/debian/pool/m....debian.tar.xz from this page: https://packages.debian.org/es/source/stretch/newt and modified the SlackBuild accordingly, see attached patch. I have applied all patches picked by Debian, maybe some are only useful on Debian but I assume that doesn't hurt.

This would at least bring bidi to whiptail, which is its only advantage over dialog, IMHO. Maybe ncurses/dialog will have it one day, this is an item in Thomas E. Dickey's TODO list, but do not expect that to be available for Slackware 14.2.

Only caveat: this fails to compile against fribidi shipped in Slackware which is very old. One could revert to an older version of the bidi patch, shipped in newt_0.52.18-1.debian.tar.xz, but I think that it is preferable to update fribidi from 0.19.2 (26-Mar-2009) to 0.19.7 (05-Aug-2015) that builds OK. Honest: I didn't check that all programs shipped in Slackware current that depend on fribidi can be rebuilt OK (if they need to be rebuilt, of which I doubt). But looking at the ChangeLog I do not expect problems.

PS the only change I made in fribidi.SlackBuild is to discard the patch fribidi.glib.h, that seems fixed upstream.

Thanks for having read this long post.

Attached Files

newt.SlackBuild.patch.txt (2.2 KB, 15 views)

Again new python-setuptools-20.1.1:

just three new per week, in this moment

https://pypi.python.org/pypi/setuptools

Now you hopefully start to realize that it is sometimes wiser to wait instead of jumping on the download of every new release of every piece of software in Slackware. The added workload caused by the repeated package updates would not be tolerable...

5 members found this post helpful.

No problem, Eric, my proposals are only suggestions

Since it took me all of 1 minute to make, here I made a package for you guys.

python-setuptools-20.1.1
python-setuptools-20.1.1.asc

If Mplayer and Xine use the same ffmpeg, why isn't ffmpeg shipped as package(using ffmpeg-sources from the Mplayer release tarball) separately, and Mplayer build against that outsorced ffmpeg? This would ease adding codecs/recompilation/maintaining ffmpeg for the both Players. Also, audacious-plugins could be compiled against that ffmpeg. Almost no additional space on the source DVD would be needed.

1 members found this post helpful.

There may be a tipping point where we have to evaluate using a system installed ffmpeg, but I don't think we're there yet. At this point synergies between the ffmpeg used by MPlayer the one used by xine are minimal, limited to both using the same source tarball. The build process however is entirely different. MPlayer has its own way of building ffmpeg as part of its own build. For a long time building against a system installed ffmpeg wasn't even possible and even now I'm not sure how well tested that use case is. Xine only recently (with version 1.2) started requiring an external ffmpeg, and linking it statically means we can limit its functionality to the actual feature set xine can use.

The main drawback of a system installed ffmpeg would be that because of the many dependencies we don't ship in slackware I'm not entirely sure how many people would be happy with it. The version on SBo gives people the opportunity to build it exactly like they want it. And as for audacious, I don't see why an audacious-ffmpeg plugin couldn't find a home on SBo either.

2 members found this post helpful.

First a reminder on how EFI booting can be set up in Slackware64 during installation.

• A partition of type EFI (EF00) is set up by the user, a FAT32 file system installed there.
• This partition in mounted as /boot/efi with a line in /etc/fstab like e.g.
  Code:

  /dev/sda1       /boot/efi                defaults         1   0

• eliloconfig is run to install the stuff needed for EFI booting the installed system.

eliloconfig can do this:

• Allow booting using elilo.efi as boot loader, creating a structure and populating it like this (initrd.gz is optional; elilo.conf is elilo's config file):
  Code:

   boot
  └── efi
      └── EFI
          └── slackware
              ├── elilo.conf
              ├── elilo.efi
              ├── initrd.gz
              └── vmlinuz

• Optionally, create a boot entry for Slackware in the EFI firmware's boot menu.

I propose that eliloconfig set up the booting structure like below instead, assuming that the user has manually installed a generic kernel afterwards as an example of post-installation configuration:elilo.conf would look like this, assuming that the user has manually edited it to add the second boot entry for the generic kernel:Notes.

• The file startup.nsh contains a single word:
  Code:

  elilo

  According to the UEFI shell specification version 2.2, if the UEFI shell is properly set up, at startup it will find a "startup.nsh" script in an EFI system partition and execute it. In our case the script just runs elilo, possibly with options (actually this runs the elilo.efi EFI application, that finds its configuration in elilo.conf, see the docs in /usr/docs/elilo-<version>).
• So in most case elilo will be started. In our case it is started in interactive mode (prompt), then will launch "huge" by default after a timeout of 20 seconds if we do nothing. If we press [TAB] it will show the labels, and if we type a label then press [TAB] again it will show the description (see attached pic). If we like it we just press [Enter].
• This structure provides a mean of choosing which kernel to boot (as in the example above) and also of booting another distribution, just making the proper sub directories, moving the files into place and adding a relevant elilo stanza. For instance we could end up with this structure for a dual boot Slint and Salix:
  Code:

  boot
  └── efi
      └── EFI
          ├── elilo.conf
          ├── elilo.efi
          ├── Slackware
          │   ├── initrd.img
          │   ├── vmlinuz
          │   └── vmlinuz-generic
          ├── Salix
          │   ├── initrd.img
          │   ├── vmlinuz
          │   └── vmlinuz-generic
          └── startup.nsh

• When we make a change we do not need to run eliloconfig again (maybe only efibootmgr if we want to update/create boot entries in the firmware's boot menu): elilo.efi will just read the edited config file and act accordingly.
• Be careful: if there is a syntax error in elilo.conf it will be more difficult to boot: you will have to type the boot command manually. Been there, done that.
• All this allows to use elilo's features so it works similarly as lilo (but without the need to run a command to rewrite a boot sector).
• It is possible to do even better using the "textmenu" chooser: this allows to display an informative text when pressing a key. I didn't fiddle with that, see the docs including the provided example.
• tl;dr? Sorry then. But on the other hand I am prepared to write a README_ELILO.TXT if requested. It will be even longer

Have fun.

Attached Thumbnails

 

2 members found this post helpful.

On 14.1 i did build MPlayer(various svn snapshots) against diffrent ffmpeg-versions which occured the last 2 years, usually it compiled fine. The Mplayer webiste says to the 1.2.1-release
"It's also easier to build this release with a system-wide version of FFmpeg, since you don't need to copy internal FFmpeg headers anymore."

A systemwide ffmpeg still could be replaced by a more feature rich version from Sbo, and as long it has the same version all players would benefit from it without further recompilation. I don't see a drawback having a stripped systemwide ffmpeg against having none.

There is no audacious-ffmpeg, only audacious-plugins(already shipped with slackware) which links against ffmpeg if present at compiletime. So audacious would also benefit if an extended system ffmpeg is installed/replaced.

My current usecase in adding e.g. the opus-codec to my system/players is compiling
-opus
-ffmpeg
-audacious-plugins
-MPlayer
-Xine

With a all players linked against a systemwide ffmepg it would be:
-opus
-ffmpeg

Hi,

I'm not sure if that would be possible, because SBo as a general rule does not provide replacements to the system packages.

--
Best regards,
Andrzej Telszewski

Ah, now i got it, i didn't thought about the option of creating a subset-package from a stock package,
like audacious-aac