F23 Self Contained Change: Cinnamon Spin
by Jan Kurik
= Proposed Self Contained Change: Cinnamon Spin =
https://fedoraproject.org/wiki/Changes/Cinnamon_Spin
Change owner(s): Dan Book <grinnz(a)gmail.com>
A Fedora Spin using the Cinnamon desktop environment.
== Detailed Description ==
Cinnamon is a Linux desktop which provides advanced innovative features and a traditional user experience. The desktop layout is similar to Gnome 2. The underlying technology is forked from Gnome Shell. The emphasis is put on making users feel at home and providing them with an easy to use and comfortable desktop experience.
== Scope ==
* Proposal owners: Track existing Cinnamon desktop environment group, and test the Spin:
* * Boot and auto-login to Cinnamon
* * Functionality of desktop, panel, menu, windows
* * Themes of panel/menu, windows, controls, icons
* * Default panel launchers and menu favorites
* * Install and verify functionality after install
* 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)
--
Jan Kurik
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
9 years
SIMVoleon, SoQt rebuilt against Coin3 on f22 and rawhide
by Ralf Corsepius
Hi,
as some already might have noticed, Coin3 is about to land in Fedora.
Therefore, I rebuilt SIMVoleon and SoQt (two addon-packages to Coin),
against Coin3 on rawhide and f22. I do not expect this to impose
problems to Fedora, because I can't spot any packages depending on these
in Fedora.
On Fedora <= 21 these packages will have to stay with Coin2 to avoid
breaking backward-compatibility.
Though it's thinkable to do so, I do not plan to provide Coin3-compiled
versions of these packages for fc20, f21 and Coin2-compiled versions for
fc22, f23, at the moment. Please speak up now, should you have such a
demand.
Ralf
9 years
Self Introduction - Pranav Kant
by Pranav Kant
Hello all,
As of this writing, I am final year undergraduate Computer Science
student going to graduate later this month (May 2015).
I have been doing package reviews for last few months, and now I have
just been sponsored into the packager group by Mamoru Tasaka.
In other FOSS communities, I am an active GNOME developer, and a GNOME
Foundation member. I started my GNOME contributions with GSoC 2014
being my first. I contributed to gnome-photos, gnome-online-accounts,
gnome-online-miners during the summer. After that, I kept contributing
to other GNOME modules regularly, mainly gnome-photos and gnome
-documents; consequently, the GNOME Foundation member.
I have also contributed to Mozilla in the past to necko group, and am
also a Firefox Student Ambassador and Firefox club lead for my college.
I am doing GSoC (2015) again this summer for libreoffice, and would be
mainly working on improving tiled rendering and integrating it into
gnome-documents via libreofficekit, and other potential consumers
(maybe evince). Michael Meeks and Miklos Vajna would be mentoring me
for this.
During the summer, I also have plans to join FUDCON Pune and explore
more ways of contributions to fedora. I am really excited about my
first step of contributions, being a packager, into fedora and hope to
be contributing to it in all possible ways that interests me in the
near future.
After the summers, I would be looking for a matching job, if possible,
but continue to contribute to FOSS communities including fedora.
Being a part of this wonderful community feels awesome, and I hope to
learn a lot from all of you in near future. In the end, I would like
to thank Mamoru Tasaka for sponsoring me into packager group, and
Debarshi Ray for his guidance which has immensely helped me exploring
new FOSS communities.
--
Regards,
Pranav Kant,
Department of Computer Science & Engineering,
National Institute of Technology Hamirpur, India
http://pranavk.me
9 years
RFE: Stackable namespaced repositories
by Orion Poplawski
I've been working on trying to package python virtual environments with
rpm (outline here:
http://orionlibre.blogspot.com/2015/05/deploying-scientific-python-enviro...).
While this particular project is python based, the same basic concept can be
applied to anything else that allows manipulating the load path - which is
pretty much everything (PATH, LD_LIBRARY_PATH, PERLINC, etc). I'm most
familiar with the HPC world which does this a lot - providing different
versions of various packages in a hierarchy and using environment modules to
allow users to load the desired stack at runtime. This is also essentially
the same thing that SCLs do, though SCLs are more isolated from the base system.
The big problem that this exposes in rpm packaging is "namespacing" the
rpms: rpms in the "stacked" repo can depend on packages in the system repos,
but not vice-versa. So we need to put them into a different namespace
manually (I'm using a %{?pyvenv_name_prefix} macro, SCLs use %{scl_prefix}).
Complicating this is that one needs to add the prefix to the names of other
packages in the repository when specifying requirements - which may not be
known ahead of time. It would be very nice if this could be handled
automatically.
What I think would work is if a repository could be marked as a "stacked"
repository and given a namespace - essentially a prefix to the names in the
repository. For example, my pyvenv-nwra repo could be given that prefix - and
marked as such - say with pyvenv-nwra:. Then when depsolving dnf would allow
dependencies in the pyvenv-nwra repo to be satisfied by packages in base
repositories but not allow the reverse. Installed packages/depnames would be
given the pyvenv-nwra: prefix to keep them separate from the system resources.
This strikes me as a complicated technical challenge, so I really would
like to hear back from the packaging ecosystem folks their thoughts about it.
But I really think this could move us into the model of providing software
stacks targeting different applications with different package/version
requirements that build upon a stable OS core while still allowing for the
tracking and deployment benefits of using rpm packages. And by having
pre-populated buildroots that make any needed macro changes (say %_prefix),
many packages could be built unmodified from the Fedora git repos as opposed
to having to hack in the namespace prefixes into the spec files.
- Orion
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
9 years
Orphaned Packages in rawhide (2015-05-12)
by Till Maas
The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.
Package (co)maintainers Status Change
===========================================================================
blahtexml orphan 1 weeks ago
gvrpcd orphan 1 weeks ago
nss_compat_ossl orphan, kdudka, mharmsen, rcritten, 1 weeks ago
rrelyea
obexftp orphan, itamarjp 5 weeks ago
ovirt-node orphan, apevec, fabiand, jboggs, 1 weeks ago
mburns72h, pmyers
python-sqlalchemy0.5 orphan 6 weeks ago
python-sqlamp orphan 6 weeks ago
The following packages require above mentioned packages:
Depending on: nss_compat_ossl (1), status change: 2015-04-29 (1 weeks ago)
centerim (maintained by: lkundrak, awjb)
centerim-4.22.10-17.fc23.i686 requires libnss_compat_ossl.so.0
centerim-4.22.10-17.fc23.src requires nss_compat_ossl-devel = 0.9.6-9.fc22
Depending on: python-sqlalchemy0.5 (1), status change: 2015-03-31 (6 weeks ago)
python-migrate0.5 (maintained by: lmacken, mbacovsk)
python-migrate0.5-0.5.4-7.fc21.noarch requires python-sqlalchemy0.5 = 0.5.8-11.fc19
python-migrate0.5-0.5.4-7.fc21.src requires python-sqlalchemy0.5 = 0.5.8-11.fc19
Affected (co)maintainers
apevec: ovirt-node
awjb: nss_compat_ossl
fabiand: ovirt-node
itamarjp: obexftp
jboggs: ovirt-node
kdudka: nss_compat_ossl
lkundrak: nss_compat_ossl
lmacken: python-sqlalchemy0.5
mbacovsk: python-sqlalchemy0.5
mburns72h: ovirt-node
mharmsen: nss_compat_ossl
pmyers: ovirt-node
rcritten: nss_compat_ossl
rrelyea: nss_compat_ossl
Orphans (7): blahtexml gvrpcd nss_compat_ossl obexftp ovirt-node
python-sqlalchemy0.5 python-sqlamp
Orphans (dependend on) (2): nss_compat_ossl python-sqlalchemy0.5
Orphans (rawhide) for at least 6 weeks (dependend on) (1):
python-sqlalchemy0.5
Orphans (rawhide)(not depended on) (5): blahtexml gvrpcd obexftp
ovirt-node python-sqlamp
Orphans (rawhide) for at least 6 weeks (not dependend on) (1):
python-sqlamp
Depending packages (rawhide) (2): centerim python-migrate0.5
Packages depending on packages orphaned (rawhide) for more than 6
weeks (1): python-migrate0.5
Not found in repo (rawhide) (1): ovirt-node
--
The script creating this output is run and developed by Fedora
Release Engineering. Please report issues at its trac instance:
https://fedorahosted.org/rel-eng/
The sources of this script can be found at:
https://git.fedorahosted.org/cgit/releng/tree/scripts/find_unblocked_orph...
9 years
ping6 and other tool6 awkwardness
by Nikos Mavrogiannopoulos
While working for an updated ipcalc to support ipv6 transparently, I
figured we have more tools which are not IPv6-ready and awkwardly
provide an additional tool with a -6 suffix, supposedly for separate
IPv6 support. That looks like a relic of the past, we still drag. IPv6
support should be transparent in programs (fortunately we don't have
ssh6). Any objection to fill bugs to merge the following tools with
their ipv4 equivalent?
ping6, geoiplookup6, tracepath6, traceroute6
[0]. https://github.com/nmav/ipcalc
9 years
system-config-users and IPA
by Мартынов Александр
I am writing patch for system-config-users that allows configure users ang group from a IPA server with python library ipalib from package ipa-python. I would like the changes be included in the system-config-users. What is the best way to implement this from the point of view of architecture? I am now implementing API that is similar to API of libuser.
9 years
