What features/changes would you like to see in future Slackware?

sahko · 02-12-2013, 07:50 AM

Enter 2013.

Now that qjson is part of Slackware is there any chance of seeing libkgapi in Slackware?

Quote:

LibKGAPI is a KDE-based library for accessing various Google services via their public API.

https://projects.kde.org/projects/ex.../libs/libkgapi

This does the same thing akonadi-googledata used to be responsible for, as far as i can tell without having dependencies outside of Slackware.

Thanks.

sahko · 02-21-2013, 09:56 PM

What is the reason the glibc-i18n package is also packaged seperately from glibc?
That package is 113mb while the whole glibc one is 136mb.
It is equal to the size of qt in current & more that double the size of firefox.

Didier Spaier · 02-21-2013, 11:13 PM

Quote:

Originally Posted by sahko

What is the reason the glibc-i18n package is also packaged seperately from glibc?

As stated in package description:

Quote:

These files go in /usr/lib/locale and /usr/share/i18n/ to provide internationalization support. You'll need this package unless you will be using US English only.

The opportunity of making a separate package (allowing people using only US English to save the additional space on disk if they wish) is stated here:

Quote:

One large and relatively independent part of glibc is the locale API and definitions of concrete locales; related to this is the subsystem dealing with various charsets and converting between them.

Conversely, there are users who do need this package but not the whole glibc.

Remember, Slackware gives you as many choices as possible and that's one of the distinctive features that many users (including me) like in it.

sahko · 02-21-2013, 11:23 PM

Eh, i thought glibc included glibc-i18n and wondered how i hadn't noticed before.
Thanks for replying.

Cyanobacteriophage · 02-22-2013, 01:40 AM

VLC!! VLC, VLC.. and possible Wine. But, other than that, I don't really need much and can find them anywhere..

D1ver · 02-22-2013, 08:25 AM

I'd like to see kernel upgrades for Slackware stable handled by slackpkg. Following the kernel tree that the stock kernel ships with.

For example, slackware 14.0 could be able to upgrade the generic kernel to 3.2.xx whenever a new version is released. I know it's not terribly hard to do this manually but it'd be nice if it was handled by slackpkg and the kernels were compiled by someone more competent than me.

Maybe by default have this blacklisted in /etc/slackpkg/blacklist so people need to opt in?

I realize this would be a bit of work to maintain for each release across multiple architectures and slackware releases, but it would be nice..

Alien Bob · 02-22-2013, 09:18 AM

Remember, slackpkg only knows what is part of a Slackware package tree. Everything you build yourself, you manage yourself. Slackwares-stable never has a kernel upgrade.

Eric

D1ver · 02-22-2013, 09:32 AM

Quote:

Originally Posted by Alien Bob

Remember, slackpkg only knows what is part of a Slackware package tree. Everything you build yourself, you manage yourself. Slackwares-stable never has a kernel upgrade.

Eric

This is kind of my point. It'd be nice to be able to run slackware-stable and have optional stable kernel updates handled by slackpkg.

jtsn · 02-22-2013, 10:37 AM

Slackpkg doesn't know anything about kernels. These are not in the scope of this tool.

D1ver · 02-22-2013, 12:26 PM

Quote:

Originally Posted by jtsn

Slackpkg doesn't know anything about kernels. These are not in the scope of this tool.

I'm not sure if I'm missing something or if I'm not doing a very good job at explaining what I'm getting at..

Slackpkg does know about kernels..

Code:

root@satellite:/# slackpkg search kernel*        

Looking for kernel* in package list. Please wait... DONE

The list below shows all packages with name matching "kernel*".

[ installed ] - kernel-firmware-20120804git-noarch-1
[ installed ] - kernel-generic-3.2.29-x86_64-1
[ installed ] - kernel-huge-3.2.29-x86_64-1
[ installed ] - kernel-modules-3.2.29-x86_64-1
[ installed ] - kernel-headers-3.2.29-x86-1
[ installed ] - kernel-source-3.2.29-noarch-1

If a kernel-generic-3.2.37 package was put up into /patches I'd be able to upgrade to it using slackpkg. Correct?

This is the 'changes you'd like to see' thread, and I would like to see the ability to receive (optional) updates to the kernel using proper Slackware package management.

Didier Spaier · 02-22-2013, 01:22 PM

@D1ver: I believe hat you stated very clearly what you'd like to see.

However I wouldn't bet that you'll get satisfaction very soon: that would mean that Slackware ceases to be a version-ed system.

But hey, I could be wrong and am not the decider

kikinovak · 02-22-2013, 01:40 PM

Quote:

Originally Posted by Robert.Thompson

Please don't get me wrong on this, I am not trying to start a big discussion.

I would like the *option* because when I want to install something, I want to install it. That's all. If it has dependencies, so be it - install them too.

For those who want more control, they wouldn't pick the *optional* 'do it all' approach.

I'll give 'slapt-get' a look-see.

I'm mostly using slackpkg and sbopkg for package management, but recently, I gave slapt-get a try on Xfce-based desktops. I installed spkg, slapt-get and slapt-src from Salix and - starting from a Slackware base system with X11 and Xfce, configured the Salix repos and installed all needed apps step by step. Works nice, and adds some comfort. Only thing I did was blacklist sysvinit-scripts and lilo, so they wouldn't get crushed by Salix versions after an upgrade.

Here's the resulting Slackware-plus-Salix desktop:

http://www.microlinux.fr/images/slac...plus_salix.png

Cheers,

Niki

jtsn · 02-22-2013, 02:03 PM

Quote:

Originally Posted by D1ver

Slackpkg does know about kernels..

Code:

root@satellite:/# slackpkg search kernel*        

Looking for kernel* in package list. Please wait... DONE

The list below shows all packages with name matching "kernel*".

Slackpkg knows about packages, but it does know nothing about the purpose of the contents. These packages have the word "kernel" in their name, but that's just convention. You can find other distributions, that call them "linux" or something different.

Quote:

If a kernel-generic-3.2.37 package was put up into /patches I'd be able to upgrade to it using slackpkg. Correct?

You can upgrade it using upgradepkg or you can let slackpkg execute upgradepkg for you. That's all about it.

Quote:

This is the 'changes you'd like to see' thread, and I would like to see the ability to receive (optional) updates to the kernel using proper Slackware package management.

You receive kernel updates via patches, if there is a severe reason, like a major bug or a security issue. Otherwise there is no need for upgrades, because Slackware -stable is called "stable" for a reason.

If you want prepackaged kernel upgrades just for fun you have build them yourself or mandate someone to do it for you.

Alien Bob · 02-22-2013, 04:01 PM

Quote:

Originally Posted by D1ver

If a kernel-generic-3.2.37 package was put up into /patches I'd be able to upgrade to it using slackpkg. Correct?

You saw my line "Slackwares-stable never has a kernel upgrade"?

In Slackware history, there was exactly one case where a newer kernel was added to the patches directory after a stable release. This was for Slackware 12.2 and it addresses a critical local root exploit.

Code:

+--------------------------+
Tue Aug 18 14:35:23 CDT 2009
patches/packages/linux-2.6.27.31/:
  Added new kernels and kernel packages for Linux 2.6.27.31 to address
  a bug in proto_ops structures which could allow a user to use the
  kernel sendpage operation to execute arbitrary code in page zero.
  This could allow local users to gain escalated privileges.
  This flaw was discovered by Tavis Ormandy and Julien Tinnes of the
  Google Security Team.
  For more information, see:
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2692
  In addition, these kernels change CONFIG_DEFAULT_MMAP_MIN_ADDR kernel
  config option value to 4096, which should prevent the execution of
  arbitrary code by future NULL dereference bugs that might be found in
  the kernel.  If you are compiling your own kernel, please check this
  option in your .config.  If it is set to =0, you may wish to edit it
  to 4096 (or some other value > 0) and then reconfigure, or the kernel
  will not have default protection against zero page attacks from
  userspace.
  (* Security fix *)
patches/packages/kernel-mmap_min_addr-4096-noarch-1.tgz:
  This package adds an init script to edit /etc/sysctl.conf, adding
  this config option:
    vm.mmap_min_addr = 4096
  This will configure the kernel to disallow mmap() to userspace of any
  page lower than 4096, preventing privilege escalation by CVE-2009-2692.
  This is a hot fix package and will take effect immediately upon
  installation on any system running a kernel that supports configurable
  /proc/sys/vm/mmap_min_addr (kernel 2.6.23 or newer).
  (* Security fix *)
+--------------------------+

Don't count on things like this happening more often though.

Eric

volkerdi · 02-22-2013, 04:41 PM

Quote:

Originally Posted by Alien Bob

You saw my line "Slackwares-stable never has a kernel upgrade"?

In Slackware history, there was exactly one case where a newer kernel was added to the patches directory after a stable release. This was for Slackware 12.2 and it addresses a critical local root exploit.

It has happened more than once. There were actually two kernel security patches issued for Slackware 8.1. However, most of the time there were security related updates for the kernel over Slackware's history, Slackware was more of a rolling release and didn't have a /patches directory, so it's easy to miss those.