I'm the change owner. The benefit is a ready to work Fedora for astronomers. One special reason for the KDE desktop is KStars. It is part of the KDE project and the leading free software for observatory control. There are no Gtk equivalents and I really don't want to ship a GNOME-based spin and then add a huge bunch of KDE software. With KStars and INDI it is possible to boot your system using the Spin, just connect telescope and camera and then have fun :) This is very nice to get new Fedora users in field of amateur astronomy. Many of them say "Linux is so complicated...", with a Spin just give them a live medium and let them play with it. You could also have a look at http://indilib.org/, especially the Forum. KStars/Ekos is the most commonly used software in this field.
Additional Information: We are currently discussing about a modified title: https://fedorahosted.org/council/ticket/35#comment:2
On Fri Jun 26 14:41:04 UTC 2015, Stephen Gallagher wrote:
On Fri, 2015-06-26 at 10:32 -0400, Jan Kurik wrote:
>/ = Proposed Self Contained Change: Astronomy Spin =
/>/ Change owner(s): Christian Dersch <lupinix at mailbox dot org >
/>/ A Fedora Spin providing a complete toolchain for both amateur and
/>/ professional astronomers.
/>/ == Detailed Description ==
/>/ In both amateur and professional astronomy and astrophysics Linux is
/>/ a very popular operating system. More and more data analysis is
/>/ performed using Python, especially the astropy project is a quite new
/>/ effort providing a professional toolchain. The Astronomy Spin
/>/ provides a complete scientific Python environment (2 and 3) as well
/>/ as the AstrOmatic software. For observational astronomy, KStars
/>/ provides a complete solution for astrophotography using the INDI
/>/ library. In addition to an astronomical collection of packages the
/>/ spin also adds a menu for astronomy to make work more comfortable.
/>/ == Scope ==
/>/ * Other developers: N/A (not a System Wide Change)
/>/ * Release engineering: Add spin to spin-kickstarts, ensure spin has
/>/ been tested, and release with rest of spins
/>/ * Policies and guidelines: N/A (not a System Wide Change)
/>/ * Trademark approval: Requested
I don't really see what benefit there is to having a spin for this. It
sounds like it might be just as effective to work with the GNOME
Software folks on getting an Astronomy Tools group in the Software app
made highly visible.
We could then just advertise Astronomy-related functionality as a new
feature of Workstation.
= Proposed Self Contained Change: Astronomy Spin =
Change owner(s): Christian Dersch <lupinix at mailbox dot org >
A Fedora Spin providing a complete toolchain for both amateur and professional astronomers.
== Detailed Description ==
In both amateur and professional astronomy and astrophysics Linux is a very popular operating system. More and more data analysis is performed using Python, especially the astropy project is a quite new effort providing a professional toolchain. The Astronomy Spin provides a complete scientific Python environment (2 and 3) as well as the AstrOmatic software. For observational astronomy, KStars provides a complete solution for astrophotography using the INDI library. In addition to an astronomical collection of packages the spin also adds a menu for astronomy to make work more comfortable.
== Scope ==
* Other developers: N/A (not a System Wide Change)
* Release engineering: Add spin to spin-kickstarts, ensure spin has been tested, and release with rest of spins
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: Requested
devel-announce mailing list
I'm trying to figure out the best way to handle the situation where a
project decides to use submodules in Git. The archive generated doesn't
incorporate the submodule files.
I've done some searching on this, and haven't really come up with much.
I've reviewed: Packaging:Github
; but that really doesn't address the submodule issue.
I looked through some packages that are currently in the Fedora repository
and found where a few folks have rebuilt the tarball and referenced that
version as the Source in the spec file; then they put in a comment stating:
The source of this package was pulled from upstreams' vcs. Use the
commands to generate the tarball:
- git clone
- git submodule init
- git submodule update
This approach is the best that I've found. Any other suggestions?
- Interview potential candidates for new memberships
- Optionally accept new members
- readonly root - plan to get rid of fedora-readonly? drop in favor of
- Open Floor
Please add items by replying to this mail.
GDB has switched from Python 2 to Python 3 (bug #1014549), so the
packages shipping gdb plugins have to switch to Python 3 too. Here is
the list of components providing "*-gdb.py" files in Fedora 22:
The plugins need to be Python 3 compatible and the packages must
own the .pyc files .
The elections for Env and Stacks - June 2015 have concluded, and the results
are shown below.
Env and Stacks is electing 5 seats this time.
A total of 71 ballots were cast, meaning a candidate
could accumulate up to 426 votes (71 * 6).
The results for the elections are as follows:
# votes | name
307 | Honza Horak (hhorak)
262 | Nick Coghlan (ncoghlan)
219 | Václav Pavlín (vpavlin)
197 | Jens Petersen (petersen)
175 | Jan Kaluza (jkaluza)
154 | Stuart Campbell (sic)
Congratulations to the winning candidates, and thank you all
candidates for running this elections!
devel-announce mailing list
Hi, guys and gals,
I am currently running the FEL spin of f20. I am going to upgrade to a
later version, probably F22, by the save users and reformat process.
However in the rush to cloud/workstation, FEL spin no longer appears
anywhere at this time. I currently have listed all the programs I use
and wish to restore to get back to my current level of development.
Also there seems to have been a devolution towards binary system files
that has somehow taken over linux. This is not good. there is
absolutely no need for binary formatted system files, and to have them
is to devolve to an earlier era, circa 1960. The move to eliminate
binary files was due to the issues of upgrading to new systems and the
inability to read and decipher what an older system was doing.
You may lambaste me for not posing this stuff as a question or even
just as a rant, but losing FEL was not good, and the other spins from
people who had solved the issues required to get a system to be a master
development station in an area of study were apparently thrown out with
the old bathwater so to speak. All of this is a sad loss for Fedora,
and even a cash loss to Redhat eventually if they go the same way.
Please, before going too far, look, discuss the history and find out
why Linux was developed the way it was.
I have to choose a distribution to use. For now I will update to F22.
But if this run to the past continues, I will find another solution. I
must take care of my long standing of development and good design
principles. I hope you all get to that perspective without losing too
much of the good stuff that so many have brought to the Linux community.