devel December 2014

devel@lists.fedoraproject.org

209 participants
219 discussions

Cinnamon Spin
by Dan Book 26 Jan '15

26 Jan '15

Hello, I have put together a basic Cinnamon Live spin, and was wondering if this is something people would like to see become official. It's not ready for submission quite yet, there is a bit of a hack to change the default gtk-theme to Zukitwo, as the Adwaita gtk-theme messes up title-bar and desktop icon colors (something that should probably be fixed upstream, this happens for any Cinnamon install by default in F21). I'm not a Fedora packager nor do I have a whole lot of time to put into this, but I am willing to update and maintain the spin as necessary. I have the kickstart files in this github repo: https://github.com/Grinnz/spin-kickstart-cinnamon And resulting images, which I have briefly tested and installed in a VM: https://grinnz.com/public/spins-cinnamon/ I added a skeleton wiki page as well: https://fedoraproject.org/wiki/Cinnamon_Spin -Dan Book

5 9

Re: python-dateutil update
by Zbigniew Jędrzejewski-Szmek 19 Jan '15

19 Jan '15

On Mon, Dec 08, 2014 at 09:10:59AM -0700, Pete Travis wrote: > On Dec 8, 2014 8:51 AM, "Zbigniew Jędrzejewski-Szmek" <zbyszek(a)in.waw.pl> > wrote: > > > > On Sun, Dec 07, 2014 at 04:45:12PM -0700, Pete Travis wrote: > > > python-dateutil is old[0]. Fedora is carrying version 1.5, and upstream > > > is up to 2.3 . If you're receiving this mail directly, you are a > > > maintainer of a package that depends on python-dateutil, and we need > > > your help. > > It seems that calibre is fine with the new version. I wanted to update > > pyton-dateutil to check if calibre works, and it seems that I > > installed python-dateutil-2.3 with pip --user couple of months ago and > > calibre didn't seem to mind. There's some dateutil usage in the installer, > > which I didn't test but which we probably don't care about. > > https://github.com/dateutil/dateutil/blob/master/NEWS also doesn't seem > > scary. > > > > So I think it's fine it python-dateutil is updated as a calibre dep. > > > > Zbyszek > > Great, thanks for responding. I'm a *light* calibre user, but I'd be > happy to help test with a newer dateutil when it becomes available if > that's the direction you are going. You can just install the python-dateutil-2.* package and test away ;) Looking at the list and your annoucement mail again, I wonder if it might be better to bump python-dateutil to 2.2 again as soon as the updated python-dateutil15 is available, and simply modify packages which either explicitly depend on dateutil < 2 or exhibit problems to depend on python-dateutil15. Proven packagers can do that trivially if necessary. Otherwise this could drag on for months. fedocal and python-django-tastypie are the only packages which explicitly require python-dateutil < 2. If you wish, I can volunteer file bugs to change the dependency for F21 and rawhide for those two packages and do it myself after a week if the maintainers don't respond or are fine with the change (got to use those provenpackager privs for something :)). Zbyszek

4 4

Best way to use zram in Fedora 21?
by Juan Orti Alcaine 13 Jan '15

13 Jan '15

Hi, I know how to manually configure the zram, but what's the best way to do it? I've seen the unit zram.service of anaconda-core, and it gets activated when booting with inst.zram=on, but it looks like very anaconda-centric. Should something like [1] be packaged and included in the distro? or maybe we should spin off the anaconda zram.service and do it more generic. I think this is a very interesting feature for memory constrained VMs and other devices. [1] https://github.com/mystilleef/FedoraZram

9 22

5tFTW: Fedora 21, 22, and 19, firewall discussion, and holiday break
by Matthew Miller 13 Jan '15

13 Jan '15

Reposted from <http://fedoramagazine.org/5tftw-2014-12-17/>. Fedora is a big project, and it’s hard to keep up with everything that goes on. This series highlights interesting happenings in five different areas every week. It isn’t comprehensive news coverage — just quick summaries with links to each. Here are the five things for December 17th, 2014: Fedora 21 Retrospective: What was awesome? What wasn’t? ------------------------------------------------------- While Fedora 22 is already rolling into the target zone, we do want to make sure we look back at this previous cycle and identify things we can improve — ideally, specific and actionable changes. In the end, we came out with (another!) great release, but there is always something to learn. In particular, we ended _yet again_ in a last minute scramble to get a release we could feel good about signing off on out before the holidays, and next time around it would be nice to put less stress on all of our contributors (including the quality assurance team and the developers needed to make those late fixes.) There will be more to it than this, but to get started, we have a F21 Retrospective wiki page, to help collect comments and ideas. * https://fedoraproject.org/wiki/Fedora_21_Retrospective Fedora 22: Coming up fast! -------------------------- FESCo (the Fedora Engineering Steering Committee, the elected organization which oversees technical decisions in the project) has indicated that we’re back to aiming for the traditional May/October Fedora release cycle, and although the F22 schedule isn’t finalized yet, we have a tentative plan calling for a release about 6 months from now. When you work back from that, it means that there’s really not much time to think about change proposals for F22, especially if we subtract out holiday time. So, if you’re thinking of working on something big, please start getting your proposal formalized — the tentative deadline is January 20th, 2015. Fedora 19: End of Life ---------------------- And on the other end of the cycle: it’s time to say farewell to Fedora 19. If you’re running this release, please plan to update before January 6th, 2015, when the last updates will go out. After that, there will be no further security fixes. The good news is that Fedora 20 was a great release, and Fedora 21 is *even better*, and I think you’ll be happy with the upgrade. * http://fedoramagazine.org/fedora-19-eol-01-06-2015/ Fedora Workstation firewall discussion -------------------------------------- This week’s big devel-list thread concerned the default firewall settings in Fedora Workstation. The Fedora Workstation Working Group was not happy with the user experience offered by blocking incoming “high ports” by default. Out of the box, nothing is listening on these, but if one installs software that expects to, it won’t work, and because we don’t have a good way yet to tie *attempts* to access ports to listening applications and communicate that to the user, the resulting failure is invisible. On the other hand, if you install something and it starts listening and you didn’t know that, that’s *also* invisible. So, pretty much everyone recognizes this as a not ideal situation. Everyone involved in the discussion also is concerned with enhancing user security in practice — the question is just how to best get there from an imperfect state. Originally, the Workstation WG asked to disable the firewall entirely. FESCo asked instead that it be left available, possibly with a less-restrictive out-of-the-box configuration — the path taken for F21. If you’re not running Workstation, this doesn’t affect you. If you are, and would like a different configuration, run the firewall configuration tool and either edit the Fedora Workstation zone or change the default zone. (There’s a long list of options, but “public” is a generally-restrictive choice.) You can also change the per-network zone. Unfortunately currently wired networks are all considered as one per interface, but wireless networks are distinguished individually. This can be done in a number of ways, but the easiest is to run the network configuration tool (in GNOME control center — press the overview key and start typing “network”), select the wifi network in question, press the little gear icon next to it, go down to Identity (?!), and choose the appropriate firewall zone. (Again, there’s a long list — go back to the firewall config tool to see exactly what they all do.) This is clearly, not the most friendly approach; it’s my understanding that the desktop designers, network tools team, and security team are going to work together to develop a better overall solution for Fedora 22 and beyond. Overall, the mailing list thread stayed relatively positive and constructive and avoided personal attacks, although there were some accusations of bad faith actions which do not seem warranted based on the actual history. It is, however, a case where more transparent discussion and communication could have helped; that’s something we’re continually working at making better and might make for a good component of the F21 retrospective mentioned above. * https://lists.fedoraproject.org/pipermail/devel/2014-December/205010.html Christmas break --------------- Of course things in Fedora never really stop, but it’s vacation time for many of us. Before I was a Red Hat employee, I was used to seeing extended days off as ideal for getting in some serious work on Fedora. Now, things are strangely inverted, and I’m going to use the time to unplug a bit. I’ll be back in January all recharged, and will catch up with everything that’s happened in the meantime — FtFTW will resume the week of January 15th — or possibly the week before, but let’s save the hard-to-keep resolutions for New Year’s Day. :) Check out the Fedora vacation calendar to see who else will be away, and make sure to add yourself if you will be too. (There's even a Fedora badge for doing so!) * https://apps.fedoraproject.org/calendar/vacation/ * https://badges.fedoraproject.org/badge/vacation -- Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/> Fedora Project Leader mattdm(a)fedoraproject.org <http://fedoraproject.org/>

14 35

Unresponsive maintainer : kanarip
by Marianne Lombard 09 Jan '15

09 Jan '15

Hi, A bug is open for perl-XML-TreePP since July (for opening a epel 7 branch) with no reaction (https://bugzilla.redhat.com/show_bug.cgi?id=1123681) I need this package so I'm volunteer to maintain it Cheers and seasons greetings Marianne / Jehane -- Marianne (Jehane) Lombard Geekfeminist and sysadmin

6 8

upcoming libtool rebase (2.4.2 ~> 2.4.3)
by Pavel Raiskup 09 Jan '15

09 Jan '15

Libtool upstream was able to cut the new release! I'll rebase the Rawhide package probably by the end of the next week or so, if there are no objections. Upstream maintainer calls this update fearless :) and that it needs a bit of luck [1] (asking for possible downstream cooperation); however after cutting F21 from rawhide we have probably good time for this rebase (the update should be more like bugfix anyway). There are some known incompatibilities; see the official announcement [2]. There is also scratch build for testing [3]. [1] http://osdir.com/ml/libtool-gnu/2014-10/msg00011.html [2] http://lists.gnu.org/archive/html/autotools-announce/2014-10/msg00000.html [3] http://koji.fedoraproject.org/koji/taskinfo?taskID=7975615 Regards, Pavel

3 5

Firefox Aurora in rawhide
by Alexander Ploumistos 08 Jan '15

08 Jan '15

Would it make sense to include Firefox Aurora / Developer Edition in rawhide?

3 2

Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
by Alexander Ploumistos 07 Jan '15

07 Jan '15

I've been meaning to write this for a week, but I wanted to do some research first. The more I read and thought on it, the issue became broader, the subject line kept changing and this message starting looking like an article. I will try to choose my words carefully; I do not intend to offend anyone nor do I want to appear biased. I hadn't used any graphical package manager on fedora for almost a decade (yumex was the last one) because I had been burned too many times and I don't trust them, but after doing a little work in the AppData area, I thought I'd take a look at gnome-software. It is one of the most beautiful UIs I have ever seen. It is elegant, simple yet functional, tidy, gorgeous to look at and it manages to stand out from all the other "market" or "store" applications. It incorporates some of the competition's best features, while avoiding their pitfalls (try living with Ubuntu's software center for a couple of days). I wholeheartedly agree with Richard Hughes in that software centers compliant with the AppStream specification help promote applications and are beneficial to both the users and the developers. About a week ago, while wondering why MATE applications do not appear in gnome-software, Richard was kind enough to point to a blog post from September 2013: http://blogs.gnome.org/hughsie/2013/09/19/gnome-software-on-mate-and-xfce/ I thought that developers and users might find it useful, so to quote Richard: > *tl;dr:* If you want to run GNOME Software on MATE or XFCE you need to > set an environment variable like > GNOME_SOFTWARE_COMPATIBLE_PROJECTS=MATE,GNOME,XFCE > This might have gone unnoticed since then, but I think it is an issue worth (re)visiting. I can understand and defend the design choices that have been made; allowing a user to mix and match packages from different DEs with different aesthetics, compiled against different/incompatible libraries or having three different applications appear as "Text Editor" or "Dictionary" would lead to a sub-optimal user experience. From that standpoint it makes sense to hide from the user packages tied to other DEs, especially if the same functionality is provided by Gnome packages. Of course, a user might install an application e.g. compiled against gtk2 and the result would be the same. I have not tested this much in other Fedora versions, only in F22 with GNOME. There, the default value in org.gnome.software compatible-projects is set to 'GNOME', 'KDE', 'XFCE'. (see https://mail.gnome.org/archives/commits-list/2013-November/msg00656.html) I do not understand this particular choice to include some DEs and exclude others. Why not enable or disable all of them? LXDE and MATE developers might be prone to attribute this to malice. Personally, on almost every machine I use, I have mixed packages from various sources - some due to personal preference, others because they offer unique functions. Then again, does gnome-software aspire to be a "universal" package manager on Fedora? If it does, then why not offer packages from every DE and metapackages for other environments? If gnome-software aims to be novice-user-friendly, at least the latter should definitely be an option. Let's not forget that Gnome is a modern desktop environment, that requires fairly modern hardware to run on and that is not always available. Also, can gnome-software be the distro-wide default package manager while adhering to the HIG? Allow me to digress a bit. Sometime in 2000, my professor told me that in order to use some molecular modeling packages and to modify their FORTRAN source code, I had to get linux, so after some searching, I went to a local bookstore and bought SuSE 5.3 or 6.0, can't remember any more (on a 56k analog modem at the time, downloading the iso or doing a network install was out of the question). The box came with two massive manuals (and some cute stickers) from which I learned the concept of the window manager or desktop environment. The choices I had been given got me really excited (almost as much as when I got my mouse wheel working) and after some weeks of playing with each DE, I routinely switched from KDE to enlightenment or to fvwm, according to the requirements of the task at hand, or just my mood. For years I kept the habit of alternating between almost every environment that was packaged for my distro, until I did not have the time to keep up with every change, so I settled with GNOME (mostly). Then came GNOME 3 and in the ensuing upheaval I gave every other DE another try. These days I use GNOME on my workstation, MATE on a netbook I take with me whenever I have field work (which sometimes literally means working in a field) and on an ancient dual Athlon MP workstation. On some other systems I manage or have lying around, I run E19, XFCE, MATE and GNOME. I have converted many friends and acquaintances over to linux, but for the past 2-3 years I don't think I have pointed anyone to anything but Ubuntu and I feel some guilt about it. For a number of reasons I can't quite put my finger on, Fedora does not "feel right" for newcomers. The upgrade process, software management and support time-frame are certainly among them. Most of these otherwise bright people have their IQ drop to the value of its logarithm when they sit in front of a computer screen and they all seem to suffer from a natural aversion towards the terminal and towards RTFM. I'm sure you are all well aware of them. When you tell them to go to fedoraproject.org and download the iso, you can be certain that a phone call is imminent, asking for step-by-step instructions, even though everything is well-documented. Explaining to them the difference between linux and distribution is hard and if you start talking about spins, they lose you. If they decide to search for a solution to an issue by themselves, they have no problem executing any commands they may find in a blog post from 2005, ignoring all the error messages that inevitably come along and then they will look genuinely surprised because something broke. Last week I upgraded my old workstation to F21. It has a GeForce 6800 that whenever I had used nouveau instead of nvidia's driver, seriously overheated and the computer sounded like the vacuum cleaners of yore. After the upgrade, I couldn't get to gdm, but entering MATE manually worked, so after a little digging, I found out about an issue with mutter and nvidia's driver. I tried a newer version of the driver from rpmfusion's build system, that didn't work, so I switched to lightdm. Now imagine one of those people, being faced with the same issue right after the adrenaline rush of upgrading with fedup. Even I have kept my main system on F20 because I need CUDA and I can't switch to OpenCL. Many of these people however exhibited an excitement far greater than mine, when after complaining about Unity for various reasons, I presented them with the alternatives. They were happy to spend time trying out other DEs, pointing out what felt right and what wrong. Some of them tried all of KDE, Cinnamon, MATE, LXDE, XFCE, GNOME and Enlightenment, for weeks even, before deciding what worked for them and their workflow. To my semi-surprise, some of those on higher-spec machines ended up on GNOME, which I thought had a steeper learning curve compared to most of the others (I still had to tell them about hidden stuff like gnome-session-properties or to get gnome-tweak-tool and look in extensions.gnome.org for extensions). Having said all that, I hear a lot of people complaining about losing users to Ubuntu, Mint and others, or why things like project Sputnik <http://www.dell.com/learn/us/en/555/campaigns/xps-linux-laptop> don't involve our community. The biggest issue here is which is the targeted user base of Fedora, if there is one? And what are the use cases we want fedora to cover? Can we have "Freedom" and be "First" and still cater to everyone's needs? Well, that's it. Happy holidays everyone!

26 108

Blacklisting of Indian xkb layouts
by Anish Patil 07 Jan '15

07 Jan '15

Hi, We have xkb layouts and m17n input methods to type Indian languages and both gets installed on GNOME by default. So it always creates confusion for uses that which are input methods and xkb layouts. However with xkb layouts one can't write conjuncts or complex characters. So it would be nice to have include m17n based input methods only, we discussed it over IRC and its log can be found on https://fedorahosted.org/i18n/ticket/36 Please let us know if anyone has better thoughts. Thanks, Anish P.

3 2

Re: Migration to Zanata
by David Cantrell 05 Jan '15

05 Jan '15

On Wed, Nov 26, 2014 at 03:13:59PM +1000, Noriko Mizumoto wrote: > Hi Fedora developers > > Having the consensus with FESCo [1], we FLP (aka translation team) have > started the process of migration to new fedora.zanata.org instance from > Transifex [2]. First all translators started to migrate in November 2014 > (still going on). > > Now it is time to migrate all projects. This is expected to start after > F21 GA. For the owners of the projects, there are two options to choose > for the migration below. > > One: Delegate us to implement migration > If this option is chosen, partially automated migration will be > performed by Zanata team. Once it completes, then the owner visits new > place and confirms everything intact (Some manual adjustment may be > required). > > Two: Manual migration > If this option is chosen, the owner performs all the migration process > by his/her self. Please advise the estimated completion date. > > I have attached the list of all the target projects below. If any > package is missing and it should be added into the list, please let me know. > > Could all Fedora developers please go through the list and advise which > option is preferred for your project, so that we will be able to > schedule them? For option One, we need to know current > maintainer's/owner's contact. > > Package Name Group > Anaconda main > Blivet main > Firstboot main > initial-setup main > pykickstart main > python-meh main > system-config-kickstart main These are all installer team projects. What are we required to do with the move to Zanata? -- David Cantrell <dcantrell(a)redhat.com> Manager, Installer Engineering Team Red Hat, Inc. | Westford, MA | EST5EDT

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel December 2014