Plans for 2015

[pavroo]

New 2015 year started already so it's time to make plans.

Releases for 2015:

4.0 - 25th Of June
4.1 - 25th of September
4.2 - 21st of December

To do:
1. Keep moving all sparky tools to the sourceforge git repos - done
2. Merge 'sparky-remastersys' and 'sparky-backup-sys' into a one tool to be used by devs and lets users to make others spins - done
3. Rebuid efi images and add EFI support for 32 bit machines  - under development (MoroS) - done
4. Replace LXDE and Razor-Qt Editions into LXQt - done - not repladed, but LXQt added; so LXDE and LXQt available, Razor-Qt dropped
5. Due to changes in LXDE - replace LXDE for Xfce(?) in GameOver edition ? - not needed yet, GameOver still with LXDE
6. Keep building Enlightenment packages to provide the freshes E versions.
7. Re-Branding - done
8. Users Wiki - under development http://sparkylinux.org/wiki

Razor-Qt spin will be dropped for sure, but I am not sure about LXDE.
Other suggestions leave under this topic so we can talk about that.

Debian Jessie will be stable this year so Sparky should change its numbering from 3 to 4.
We need a new code name as well !

[0dder0tter]

I'll use this reply as a bit of an introduction ...

I would like to see the documentation -- user guides, FAQ, tutorials, that sort of thing -- expand for Sparky in 2015. In that vein, pavroo and I have been exchanging ideas through email. We've talked about setting up a wiki, so hopefully that will happen soon and maybe some people will feel motivated to contribute to it!

My name is Mark and I'm a US citizen. I work in the IT field at a small college (only Windows, unfortunately) and have some experience writing documentation for Linux. I've been using Linux since around '98 but have not always owned a computer during that time, so don't let the fact that I started with Linux 15+ years ago fool you into thinking I'm an expert.  :) For the vast majority of that time I've used Debian or a Debian-based distro and Enlightenment has been my favored GUI for ~5 years.

That's all for now. I'm open to any ideas anyone has for docs/wiki/guides/etc.

mark

[MoroS]

3. Rebuid efi images and add EFI support for 32 bit machines

Under development. ;)

6. Keep building enlightenment packages to provide the freshes E versions.

I'm thinking about (and currently designing) a port-based system for Sparky (for internal use) to ease our tasks in building custom packages. It'll be something similar to Arch's pacman and Gentoo's portage, but a lot simpler. We don't need that level of complexity (at least not now). Basic features I've been thinking about:

• Dependency management - download and install required *-dev packages or, if required, build dependencies prior to building the target package
• Build management - handle the few popular building systems available (autogen, configure, make, cmake or simple repackaging and compression)
• DEB package creation - automatically create DEB packages from the built sources

I'm quite laze when it comes to building everything, so I want to have a system that'll require only modifying metadata and issuing a command or two. Pavroo, your experiences in building E packages will be quite valuable here. :)

[The Black Pig]

Merge 'sparky-remastersys' and 'sparky-backup-sys' into a one tool to be used by devs and lets users to make others spins - done
Is this now available ? if so how do we install ?

[pavroo]

It's done already:
http://sparkylinux.org/sparky-backup-system-20150119/
It can be used from a command line or fully automatically via a gui.
Simply install/upgrade sparky-backup-sys up to version 20150119 (changed numbering from 0.x.x to a date).

[The Black Pig]

 8)

[Nimsy]

[I'm thinking about (and currently designing) a port-based system for Sparky (for internal use) to ease our tasks in building custom packages. It'll be something similar to Arch's pacman and Gentoo's portage, but a lot simpler. We don't need that level of complexity (at least not now). Basic features I've been thinking about:

• Dependency management - download and install required *-dev packages or, if required, build dependencies prior to building the target package
• Build management - handle the few popular building systems available (autogen, configure, make, cmake or simple repackaging and compression)
• DEB package creation - automatically create DEB packages from the built sources

I've actually been researching how to custom-compile Portage for my system.  There was a guide written for it about ten years ago.

See: http://forums.gentoo.org/viewtopic.php?t=125553. 

I don't know enough about writing or editing shell scripts to be able to poke at this on my own without quite a bit of trepidation.

But something that might make Sparky more cutting edge would be to figure out how to modernize this guide and include it as an option, particularly in the case of USE-flags.  I've been trying to figure out how to workaround the longstanding incompatibility with Wine and SSL/https.  The main inspiration behind wanting to solve this is to be able to play the Net-7 emulator for the old Earth & Beyond game, which requires being able to handle and accept an SSL.  Everything else works with Wine 1.6.2 to 1.7.33 (and presumably earlier than that).

However, ever since 'libgluezilla' disappeared (rather literally), it seems that Wine moved on without trying to replace it.

See:  http://wiki.gentoo.org/wiki/Wine

[stevendupuis]

[I'm thinking about (and currently designing) a port-based system for Sparky (for internal use) to ease our tasks in building custom packages. It'll be something similar to Arch's pacman and Gentoo's portage, but a lot simpler. We don't need that level of complexity (at least not now). Basic features I've been thinking about:

• Dependency management - download and install required *-dev packages or, if required, build dependencies prior to building the target package
• Build management - handle the few popular building systems available (autogen, configure, make, cmake or simple repackaging and compression)
• DEB package creation - automatically create DEB packages from the built sources

I've actually been researching how to custom-compile Portage for my system.  There was a guide written for it about ten years ago.

See: http://forums.gentoo.org/viewtopic.php?t=125553. 

I don't know enough about writing or editing shell scripts to be able to poke at this on my own without quite a bit of trepidation.

But something that might make Sparky more cutting edge would be to figure out how to modernize this guide and include it as an option, particularly in the case of USE-flags.  I've been trying to figure out how to workaround the longstanding incompatibility with Wine and SSL/https.  The main inspiration behind wanting to solve this is to be able to play the Net-7 emulator for the old Earth & Beyond game, which requires being able to handle and accept an SSL.  Everything else works with Wine 1.6.2 to 1.7.33 (and presumably earlier than that).

However, ever since 'libgluezilla' disappeared (rather literally), it seems that Wine moved on without trying to replace it.

See:  http://wiki.gentoo.org/wiki/Wine

Hi ..
I'm going to take a look at the portage stuff (from your URL above). I've worked with the shell for a long time, and would like to modify / modernize it - initially to see if we get something a) thats workable, and b) actually repeatable.

I have some time over the next week to do some work on it, if no one objects. If someone else has the same thing in mind, let me know and maybe we can collaborate.

Regards,
Steve Dupuis
Ottawa, Canada

[Nimsy]

Definitely keep me posted, and even included, if possible.  :)

This is a project that I was fully willing to poke at for however long I needed, to teach myself any method of making it work.  :)

[MoroS]

Not so fast guys. I'm not making another Portage. ;)

I'm making a build system for releasing custom packages easily to the Sparky's repository, so that's a little different. It has a task of building and packaging some software packages with getting the needed dependecies installed for compilation time and removing them when done (and if they weren't installed manually). It's thought to ease the development work for us, not to provide a ports system to the community, although it'll be available to download from the code repository to poke around, once it's ready. :)

[Nimsy]

I didn't suggest it as a replacement to what you were working on, MoroS. :)

But, for Linux-reliant gamers everywhere, it would be a majorly amazing thing.  There are quite a few games out there that create SSL issues.

So what I'm really suggesting, in all honesty, is for you and Pavroo to consider including the concept of it in a mainstream release (i.e. a variant of GameOver), if we're successful at getting it to work.  :)

[MoroS]

There are quite a few games out there that create SSL issues.

That I haven't heard about yet. If you have some example links, then could you post them?

As for games on Debian/Sparky, there is the PlayDeb repository with a lot of them, so it might be worthwhile to check it out (and add support for enabling that repo perhaps?).

Maybe we should move this discussion to a separate thread? Pavroo?

[Nimsy]

I will definitely make a point to dig up some links when I have more time (I have too much stuff to do away from the computer, after I reply).

As I mentioned previously, my personally-primary inspiration is to get the Earth & Beyond Emulator up and running.  I used to be a part of the community there, many years ago.  It is more than a bit frustrating that there is that one little thing preventing me from rejoining them.  :P

There's a lot more potential for incorporating the concept of USE-flags besides configuring Wine to accept SSL, of course.  But if you search for "Wine SSL" - you might be surprised by how many topics come back about people struggling with the issue.

[pavroo]

Just I changed status for the question 1 for done - all sparky tools have been moved to git repo now.
Added new point No 7 - Re-Branding

[drew]

The sparky tools are great and should be in every user friendly distro.  ;)