Re: Sidux?

[Kel Modderman <kel@otaku42.de>]

Hi Lucas,

On Thursday 16 October 2008 16:21:16 Lucas Nussbaum wrote:
> Hi,
> 
> Are some DDs or -devel@ readers involved into Sidux development?

No Developers afaik. A couple of readers though.

> 
> What's their exact technical model? They duplicate the whole archive, or
> just change a few packages and use the normal Debian archive for the
> rest of the packages?

Distribute an installable live media which is based on software from the Debian
sid archive at any given point in time, plus the necessary packages required
for the live media to become possible (a live initramfs, some live media only
initscripts, installation infrastructure) as well as our own linux image/module
packages, some artwork and desktop preseed data.

We try to adhere to the DFSG as close as possible [0]. Our distributable media
contains only software which is in Debian main, or the main component of the
sidux software archive (software existing in sidux/main adheres to same
guidelines as Debian/main). No firmware, 3rd party multimedia stuff or other
proprietary software or drivers are provided on the distributed media.

There are a couple of home grown softwares included, such as a multi-lingual
'sidux' manual, a (K)control centre module for administrative tasks and an
application for writing basic /etc/network/interfaces stanzas for standard
desktop networking situations.

Support requests and bugs are proxied by the sidux forums and irc channel. The
community of sidux users make use of the infrastructure to discuss things
desktop users usually discuss, and occasionally they report problems with
broken packages which pop up in the sid archive. These problems can be dealt
with a couple of ways, someone can cook up some crackful sed/perl one-liner to
hack system files in ways not understood by the person executing them (thanks
pusling for pointing this out in another reply, but we do not do that) or the
bug report can be taken to the Debian BTS so that the problem may be addressed
in a packaging update or enhancement. We choose the latter method.

A lot of times a problem reported in the forum or on irc is already reported to
the Debian BTS and we can supply a transient package NMU via our repository
(fix.main section) to fix the immediate breakage, or we can put up a big
warning sign in the forum/irc so that people restrain from upgrading their
system during problematic periods and wait for the problem to be fixed within
Debian. If the problem is not yet reported, we try to get a bug report + patch
if possible to the BTS.

As a rule, we hardly ever maintain a delta to software existing in Debian
archive, except in the following situations:

* we require modifications to achieve particular needs/persuits/goals:
  - linux kernel packages (using same packaging as Debian, with a maintained
    delta)
  - kernel module packages which compile against these new Linux versions, or
    are not yet in Debian
  - gfxboot patches for legacy grub, to enhance user experience with live media
  - our live media infrastructure, which existed before live-initramfs/helper
    was forked from casper and we don't particularly want to throw away just
    now (we never used live-helper, as lamby's reply suggests, just shared some
    knowledge)
* it is severely broken and the Debian maintainer doesn't do anything for long
  periods (eg, sysvinit + libata shutdown, xserver-xorg-video-vesa)
* one of us is heavily involved in Debian maintenance of the software, giving
  us a pool of users to test changes before going to Debian with them
  (eg, wpasupplicant, insserv, lirc)


> (what does /etc/apt/* look like?) 

etc/apt/
|-- apt.conf.d
|   |-- 01autoremove
|   |-- 70debconf
|   `-- 80sidux
|-- secring.gpg
|-- sources.list
|-- sources.list.d
|   |-- debian.list
|   `-- sidux.list
|-- trustdb.gpg
|-- trusted.gpg
`-- trusted.gpg~

$ cat etc/apt/apt.conf.d/80sidux | grep -v '^//'
APT::Get::AutomaticRemove "0";
APT::Get::HideAutoRemove "1";
APT::Install-Recommends "0";
APT::Install-Suggests "0";
Debug::pkgAutoRemove "0";

$ cat etc/apt/sources.list.d/*.list
deb http://ftp.uk.debian.org/debian/ sid main
#deb-src http://ftp.uk.debian.org/debian/ sid main
deb http://sidux.com/debian/ sid main fix.main
#deb-src http://sidux.com/debian/ sid main fix.main


> 
> Are there opportunities to collaborate with them on some things?

We collaborate on a few things already, none of them particularly major with
respect to Debian's normal ongoings, but never the less, we try to exert our
influences in areas we care about if we have the opportunity and ability:

* maintain a few packages in Debian
* submit patches to enhance packages in Debian, or create packages which are
  later adopted by a Debian Developer
* report bugs in software distributed by Debian

The people who do this work do so on their own accord, and do not particularly
claim their allegiance to the sidux group or whatever by way of email address
or some footnote on bottom of every communication. Therefore, our activity in
Debian may fly under the radar sometimes, or depending on the developer, even
be considered insignificant.

In summary, we are volunteer group of people who enjoy using and supporting a
subset of Debian sid which makes for a good desktop distribution, and try to
give back when we can, to the best of our limited abilities.

Thanks, Kel.

[0] we don't actively strip the vanilla Linux kernel sources of embedded
    firmware (this is considered RC, but tagged release-ignore until it can be
    done in a meaningful way - dwmw2's efforts in mainline will allow this
    soon), but we do make every other achievable effort to adhere to the DFSG.