date:20141003

We're working on rewriting the themes. So the patches might not be merged
upstream.

On 3 October 2014 22:03, poma  wrote:

> On 11.09.2014 06:42, Satyajit Sahoo wrote:
> > Yeah. Got caught up in work. Will merge this weekend.
>
>   I was hoping at least upstream would say that your patch was the right
> approach.
>   Did they reply to you on the patches?
>
>   Kevin Fenzi
>   https://bugzilla.redhat.com/show_bug.cgi?id=1114161#c34
>
>
> poma
>
>
>


-- 

Satyajit Sahoo
Digital artist
DeviantArt Profile 

We're all stories, in the end. Just make it a good one, eh? — The Doctor,
Season 5, Episode 13.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: The Shimmer Project - Desktop Suites & GTK+ 3

Also, this patch misses a lot of stuff which are needed for GTK3.14
compatibility.

On 3 October 2014 22:04, Satyajit Sahoo  wrote:

> We're working on rewriting the themes. So the patches might not be merged
> upstream.
>
> On 3 October 2014 22:03, poma  wrote:
>
>> On 11.09.2014 06:42, Satyajit Sahoo wrote:
>> > Yeah. Got caught up in work. Will merge this weekend.
>>
>>   I was hoping at least upstream would say that your patch was the right
>> approach.
>>   Did they reply to you on the patches?
>>
>>   Kevin Fenzi
>>   https://bugzilla.redhat.com/show_bug.cgi?id=1114161#c34
>>
>>
>> poma
>>
>>
>>
>
>
> --
>
> Satyajit Sahoo
> Digital artist
> DeviantArt Profile 
>
> We're all stories, in the end. Just make it a good one, eh? — The Doctor,
> Season 5, Episode 13.
>



-- 

Satyajit Sahoo
Digital artist
DeviantArt Profile 

We're all stories, in the end. Just make it a good one, eh? — The Doctor,
Season 5, Episode 13.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: How to handle upgrades to Fedora 21

On Wed, Oct 01, 2014 at 04:28:22PM -0400, Stephen Gallagher wrote:
> The thing to note is that in all scenarios, the user *MUST* fully update
> their F20 system first, or the results will be undefined and could be
> unpleasant. We need to spell this out very clearly to our upgrading
> users.

Here's what I'm thinking...

Converting from vanilla to and from productized Fedora is a separate issue
from upgrading. It's something that someone might want to do at any point,
and it's something that we'll want to have beyond just the F21 release.

I can see the convenience value of letting people check a box or give a flag
at the F20->F21 upgrade point. I wish we had thought of that several months
ago, but I don't think anyone did (or we dropped it if it were mentioned,
sadly). At this point, since the fedup maintainers aren't sold and we're
working on validating the beta already, *and* because the upgrade-to-convert
situation is a one time thing, I think we should put our efforts into the
convert-at-any-time situation.

-- 
Matthew Miller

Fedora Project Leader
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: The Shimmer Project - Desktop Suites & GTK+ 3

Yeah. I know. We're working on complete 3.14 compatibility.
On Oct 3, 2014 10:11 PM, "poma"  wrote:

> On 03.10.2014 18:37, Satyajit Sahoo wrote:
> > Also, this patch misses a lot of stuff which are needed for GTK3.14
> > compatibility.
>
> Sahoo, my patch is intended for the specific case, and certainly better
> than without it.
>
>
> poma
>
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: The Shimmer Project - Desktop Suites & GTK+ 3

They have completey rewritten Adwaita and integrated it into GTK. If they
change it again, it'll be hard for them too. But let's hope for the best :D

On 3 October 2014 22:18, poma  wrote:

> On 03.10.2014 18:43, Satyajit Sahoo wrote:
> > Yeah. I know. We're working on complete 3.14 compatibility.
> > On Oct 3, 2014 10:11 PM, "poma"  wrote:
> >
> >> On 03.10.2014 18:37, Satyajit Sahoo wrote:
> >>> Also, this patch misses a lot of stuff which are needed for GTK3.14
> >>> compatibility.
>
> BTW Sahoo, GNOME folks will break it again very soon, don't worry.
>
>
> poma
>
>
>


-- 

Satyajit Sahoo
Digital artist
DeviantArt Profile 

We're all stories, in the end. Just make it a good one, eh? — The Doctor,
Season 5, Episode 13.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: The Shimmer Project - Desktop Suites & GTK+ 3

2014-10-03 Thread Matthias Clasen

On Fri, 2014-10-03 at 22:20 +0530, Satyajit Sahoo wrote:
> They have completey rewritten Adwaita and integrated it into GTK. If
> they change it again, it'll be hard for them too. But let's hope for
> the best :D

Even better to just talk to 'them' - we are right here, and happy to
answer questions. It is hard to give your issues equal weight unless we
hear about them. 

In terms of 'breaking it again', you should be aware of this change: 

https://git.gnome.org/browse/gtk
+/commit/?id=4d9d655b4efe9fd23ad18449d3e45fb8cd4d9cf0

Themes will be css-only in 3.16.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: EPEL [Extra Packages for Enterprise Linux] #4: Decide on criteria to unretire packages.

2014-10-03 Thread Extra Packages for Enterprise Linux

#4: Decide on criteria to unretire packages.
-+
  Reporter:  till|  Owner:  epel-wranglers
  Type:  defect  | Status:  new
  Priority:  major   |  Milestone:
 Component:  Policy problem  |Version:
Resolution:  |   Keywords:
-+

Comment (by smooge):

 Update to ticket. We did not have a full body of committee members on
 2014-10-03 meeting so are going to put this to the next meeting.

 Second note. We are going to look at reviewing xerces-c using old method
 so that broken deps can be dealt with.

-- 
Ticket URL: 
Extra Packages for Enterprise Linux 
Extra Packages for Enterprise Linux
___
epel-devel mailing list
epel-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: The Shimmer Project - Desktop Suites & GTK+ 3

We're not relying on any engine and writing CSS only code. So we are at the
safe side \o/

And it's awesome to see support for box-shadow in GTK3.14. Keep up the good
work.

On 3 October 2014 22:25, Matthias Clasen  wrote:

> On Fri, 2014-10-03 at 22:20 +0530, Satyajit Sahoo wrote:
> > They have completey rewritten Adwaita and integrated it into GTK. If
> > they change it again, it'll be hard for them too. But let's hope for
> > the best :D
>
> Even better to just talk to 'them' - we are right here, and happy to
> answer questions. It is hard to give your issues equal weight unless we
> hear about them.
>
> In terms of 'breaking it again', you should be aware of this change:
>
> https://git.gnome.org/browse/gtk
> +/commit/?id=4d9d655b4efe9fd23ad18449d3e45fb8cd4d9cf0
>
> Themes will be css-only in 3.16.
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct




-- 

Satyajit Sahoo
Digital artist
DeviantArt Profile 

We're all stories, in the end. Just make it a good one, eh? — The Doctor,
Season 5, Episode 13.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: The Shimmer Project - Desktop Suites & GTK+ 3

On 03.10.2014 18:37, Satyajit Sahoo wrote:
> Also, this patch misses a lot of stuff which are needed for GTK3.14
> compatibility.

Sahoo, my patch is intended for the specific case, and certainly better than 
without it.


poma

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: The Shimmer Project - Desktop Suites & GTK+ 3

On 11.09.2014 06:42, Satyajit Sahoo wrote:
> Yeah. Got caught up in work. Will merge this weekend.

  I was hoping at least upstream would say that your patch was the right 
approach. 
  Did they reply to you on the patches?
 
  Kevin Fenzi
  https://bugzilla.redhat.com/show_bug.cgi?id=1114161#c34


poma


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: The Shimmer Project - Desktop Suites & GTK+ 3

On 03.10.2014 18:34, Satyajit Sahoo wrote:
> We're working on rewriting the themes. So the patches might not be merged
> upstream.
>

Fenzi, there you go.
Thanks Sahoo.


poma

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: The Shimmer Project - Desktop Suites & GTK+ 3

On 03.10.2014 18:43, Satyajit Sahoo wrote:
> Yeah. I know. We're working on complete 3.14 compatibility.
> On Oct 3, 2014 10:11 PM, "poma"  wrote:
> 
>> On 03.10.2014 18:37, Satyajit Sahoo wrote:
>>> Also, this patch misses a lot of stuff which are needed for GTK3.14
>>> compatibility.

BTW Sahoo, GNOME folks will break it again very soon, don't worry.


poma


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

5tFTW: Last bit on Shellshock, plus, Fedora Governance, Flock, Fedocal, and F21 (2014-10-03)

Reposted from .

Fedora is a big project, and it’s hard to keep up with it all. 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 October 3rd, 2014:

Shellshock (CVE-2014-6271/CVE-2014-7169) followup
-

Hopefully this is the last word on this (knock on wood), but there are
a few tidbits to note. First, the Fedora Docker images on the Docker
hub have all been updated, from the base image to all of the pre-made
specific images including Node.js, OwnCloud, MariaDB, and so on.
Second, we have awarded an electrifying new badge to the dozens of
people who helped us get the update out. Thanks to all of you!

If you missed it but are still curious, see all of our coverage on
Fedora Magazine under the shellshock tag.

* https://registry.hub.docker.com/_/fedora/
* https://registry.hub.docker.com/repos/fedora/
* https://badges.fedoraproject.org/badge/shellshocked
* http://fedoramagazine.org/tag/shellshock/

Important Fedora governance discussion
--

In the months leading up to Flock, at Flock, and after, the Fedora
Project board and interested community members have been talking about
a new top-level governance model for the project. This is intended to
provide more clear project-level communication, increase meritocratic
representation of people directly involved in the project, and set up a
framework for more efficient use of our limited resources for the most
impact.

The new body, which we are calling the *Fedora Council*, will replace
the Fedora board as stewards of the Fedora mission and our shared core
values. This is important to everyone involved in the project — end
users and all contributors to all aspects of Fedora, at any level. Take
a look at the (in-progress and evolving) draft charter, and join the
conversation on the public board-discuss mailing list.

* https://fedoraproject.org/wiki/Overview#Our_Mission
* https://fedoraproject.org/wiki/Foundations
* https://fedoraproject.org/wiki/MatthewMiller/council-draft
* https://lists.fedoraproject.org/mailman/listinfo/board-discuss

Finalizing Flock locations
--

As mentioned last week, we have four bids for 2015’s Flock
conference in North America. Flock organizer Ruth Suehle recently
announced a call for input on the proposals Your response would be
very helpful, if you’re thinking of attending — and if you’re a Fedora
contributor or want to become one, I hope to see you there next summer!

* http://fedoramagazine.org/5tftw-2014-09-26/
*
https://lists.fedoraproject.org/pipermail/flock-planning/2014-September/000571.html

Fedora Calendar upgrade
---

A few months ago, I wrote about Fedora’s calendaring system,
Fedocal. Among other things like scheduling team meetings,
contributors use it to note their vacations, so the rest of us can
coordinate around that. There have been some complaints that this
ends up being harder to read than the old wiki-page solution, but this
week, Fedocal developer Pierre-Yves Chibon announced a new version
which includes a list view which addresses that. It’s in “staging” now
(that is, on a test server), but will go into production use soon.
Testing is welcome on the staging instance.

* http://fedoramagazine.org/five-things-in-fedora-this-week-2014-04-15/
* https://apps.fedoraproject.org/calendar/
* https://fedorahosted.org/fedocal/ticket/130
*
https://lists.fedoraproject.org/pipermail/infrastructure/2014-October/014921.html
* https://apps.stg.fedoraproject.org/calendar/list/test/

Fedora 21 progress
--

The Fedora Alpha was released last week, and we’re in the process of
evaluating the test criteria for the Beta release scheduled for
October 28th, and fixing corresponding bugs. If you’re interested in
helping, join the QA team, or simply participate in a Test Day.
(If you haven’t before, it’s easy. Read Amita Sharma’s article on what
it’s like to get a feel, or just jump in.)

Also, please keep in mind that Fedora release days are targets, not
deadlines — we aim for them, but our releases come out only when we
meet our criteria for quality. We hope that there won’t be any more
schedule slips, but when that happens, it’s just part of the process,
not some sort of failure.

* http://fedoraproject.org/wiki/Releases/21/Schedule
* https://fedoraproject.org/wiki/QA/Join
* http://fedoraproject.org/wiki/QA/Test_Days
*
http://fedoramagazine.org/how-it-feels-when-you-participate-in-a-test-day-testing-jenkins/

--
Matthew Millermat...@mattdm.org
Fedora Project Leader mat...@fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/dev

EPEL Fedora 7 updates-testing report

2014-10-03 Thread updates

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
  14  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2657/python-oauth2-1.5.211-7.el7
   9  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2748/nodejs-0.10.32-1.el7,v8-3.14.5.10-14.el7
   8  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2825/nginx-1.6.2-1.el7
   8  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2861/nodejs-qs-0.6.6-3.el7
   8  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2870/nodejs-send-0.3.0-4.el7
   3  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2992/check-mk-1.2.4p5-2.el7
   1  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3070/phpMyAdmin-4.2.9.1-1.el7
   1  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3062/golang-1.3.3-1.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

impallari-lobster-fonts-1.4-8.el7
mate-notification-daemon-1.8.0-2.el7
mate-power-manager-1.8.1-1.el7
mate-screensaver-1.8.1-1.el7
mate-settings-daemon-1.8.2-1.el7
mate-terminal-1.8.1-1.el7
mod_gnutls-0.5.10-14.el7
nfs-ganesha-2.1.0-9.el7
nodejs-errs-0.3.0-2.el7
php-horde-Horde-Core-2.14.2-1.el7
php-horde-Horde-CssMinify-1.0.2-1.el7
php-horde-Horde-Dav-1.1.0-1.el7
php-horde-Horde-Db-2.1.4-1.el7
php-horde-Horde-Mail-Autoconfig-1.0.1-1.el7
php-horde-Horde-Mime-Viewer-2.0.7-3.el7
php-horde-Horde-Pack-1.0.4-1.el7
php-horde-Horde-Test-2.4.4-1.el7
php-horde-horde-5.2.1-2.el7
php-phpunit-PHPUnit-4.3.0-1.el7
php-phpunit-PHPUnit-MockObject-2.3.0-1.el7
php-phpunit-diff-1.2.0-1.el7
php-theseer-autoload-1.16.0-1.el7
pycolumnize-0.3.5-2.el7
python-click-3.3-1.el7
python-logbook-0.7.0-1.el7
python-xmltodict-0.9.0-1.el7
tangerine-fonts-1.3-2.el7

Details about builds:



 impallari-lobster-fonts-1.4-8.el7 (FEDORA-EPEL-2014-3094)
 Hand written font with various ligatures for better connecting of letters

Update Information:

Initial Package




 mate-notification-daemon-1.8.0-2.el7 (FEDORA-EPEL-2014-3108)
 Notification daemon for MATE Desktop

Update Information:

- try fix rhbz (#890728)

ChangeLog:

* Fri Oct  3 2014 Wolfgang Ulbrich  - 1.8.0-2
- try fix rhbz (#890728)

References:

  [ 1 ] Bug #890728 - [abrt] mate-notification-daemon-1.5.0-1.fc18: 
_cairo_arc_in_direction: Process /usr/libexec/mate-notification-daemon was 
killed by signal 6 (SIGABRT)
https://bugzilla.redhat.com/show_bug.cgi?id=890728




 mate-power-manager-1.8.1-1.el7 (FEDORA-EPEL-2014-3091)
 MATE power management service

Update Information:

- update to 1.8.1 release

ChangeLog:

* Fri Oct  3 2014 Wolfgang Ulbrich  - 1.8.1-1
- update to 1.8.1 release
- remove upstreamed upower-0.99 patches




 mate-screensaver-1.8.1-1.el7 (FEDORA-EPEL-2014-3107)
 MATE Screensaver

Update Information:

- update to 1.8.1 release

ChangeLog:

* Thu Oct  2 2014 Wolfgang Ulbrich  - 1.8.1-1
- update to 1.8.1 release




 mate-settings-daemon-1.8.2-1.el7 (FEDORA-EPEL-2014-3111)
 MATE Desktop settings daemon

Update Information:

- update to 1.8.2 release

ChangeLog:

* Thu Oct  2 2014 Wolfgang Ulbrich  - 1.8.2-1
- update to 1.8.2 release




 mate-terminal-1.8.1-1.el7 (FEDORA-EPEL-2014-3103)
 Terminal emulator for MATE

EPEL Fedora 6 updates-testing report

2014-10-03 Thread updates

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 894  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6
 226  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0590/oath-toolkit-2.0.2-4.el6
 113  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1616/puppet-2.7.26-1.el6
  14  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2655/python-oauth2-1.5.211-7.el6
   9  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2750/libsrtp-1.4.4-10.20101004cvs.el6
   9  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2719/nodejs-0.10.32-1.el6,v8-3.14.5.10-14.el6
   9  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2742/TeXmacs-1.0.7.2-3.el6
   9  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2713/putty-0.63-3.el6
   8  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2850/nginx-1.0.15-7.el6
   8  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2811/nodejs-qs-0.6.6-3.el6
   8  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2821/nodejs-send-0.3.0-4.el6
   8  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2801/seamonkey-2.21-8.ESR_24.8.0.el6
   3  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2981/check-mk-1.2.4p5-2.el6
   2  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3024/rssh-2.3.4-1.el6
   1  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3080/phpMyAdmin-4.0.10.4-1.el6
   1  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3082/golang-1.3.3-1.el6


The following builds have been pushed to Fedora EPEL 6 updates-testing

impallari-lobster-fonts-1.4-8.el6
nfs-ganesha-2.1.0-9.el6
php-horde-Horde-Core-2.14.2-1.el6
php-horde-Horde-CssMinify-1.0.2-1.el6
php-horde-Horde-Dav-1.1.0-1.el6
php-horde-Horde-Db-2.1.4-1.el6
php-horde-Horde-Mail-Autoconfig-1.0.1-1.el6
php-horde-Horde-Mime-Viewer-2.0.7-3.el6
php-horde-Horde-Pack-1.0.4-1.el6
php-horde-Horde-Test-2.4.4-1.el6
php-horde-horde-5.2.1-2.el6
php-pecl-igbinary-1.2.1-1.el6
python-click-2.6-1.el6
tangerine-fonts-1.3-2.el6
tipcutils-2.0.6-1.el6

Details about builds:



 impallari-lobster-fonts-1.4-8.el6 (FEDORA-EPEL-2014-3100)
 Hand written font with various ligatures for better connecting of letters

Update Information:

Initial Package




 nfs-ganesha-2.1.0-9.el6 (FEDORA-EPEL-2014-3093)
 Ganesha NFS Server

Update Information:

build and install admintools, restore exclusion of gluster gfapi on rhel
/etc/sysconfig/nfs-ganesha file added in 2.1, just noticed now

ChangeLog:

* Thu Oct  2 2014 Kaleb S. KEITHLEY  2.1.0-9
- restore exclusion of gluster gfapi on rhel
* Thu Oct  2 2014 Kaleb S. KEITHLEY  2.1.0-8
- install /etc/dbus-1/system.d/org.ganesha.nfsd.conf
- build and install admin tools
* Mon Sep 29 2014 Kaleb S. KEITHLEY  2.1.0-7
- install /etc/sysconfig/nfs-ganesha file
* Fri Aug 29 2014 Kaleb S. KEITHLEY 
- Ceph FSAL typo, #1135437
* Sun Aug 17 2014 Fedora Release Engineering  
- 2.1.0-6
- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_22_Mass_Rebuild




 php-horde-Horde-Core-2.14.2-1.el6 (FEDORA-EPEL-2014-2766)
 Horde Core Framework libraries

Update Information:

Packaging changes:
- don't use system javascript libraries as this breaks horde and its cache 
system
- use /var/log/horde for logging
- use /var/lib/horde/cache for caching
- use /var/lib/horde/static for js and css cache
- fix regex filter, fix missing horde-power*.png


Horde_Core 2.14.2
* [mjr] Fix generating reply text from EAS clients that only reply in HTML (Bug 
#13615).
* [mjr] Remove Yahoo related code from HordeMap API.
* [mjr] Add Reply-To header to email sent via ActiveSync if available in 
identity (Ticket #13592).
* [mjr] Prevent sending contact lists as results in GAL searches.

Horde_Core 2.14.1
* [mjr] Fix handling of EAS categories containing spaces in the name.
* [jan] Catch exceptions if not being able to find an LDAP user DN (Bug #13571).
* [mms] Fix using master SMTP credentials when a CLI script uses the 
'user_admin' registry flag.


ChangeLog:

* Thu Oct  2 2014 Remi Collet  - 2.14.2-1
- Update to 2.14.2
* Tue Sep 23 2014 Remi Colle

Re: How to handle upgrades to Fedora 21

2014-10-03 Thread Owen Taylor

On Fri, 2014-10-03 at 12:37 -0400, Matthew Miller wrote:
> On Wed, Oct 01, 2014 at 04:28:22PM -0400, Stephen Gallagher wrote:
> > The thing to note is that in all scenarios, the user *MUST* fully update
> > their F20 system first, or the results will be undefined and could be
> > unpleasant. We need to spell this out very clearly to our upgrading
> > users.
> 
> Here's what I'm thinking...
> 
> Converting from vanilla to and from productized Fedora is a separate issue
> from upgrading. It's something that someone might want to do at any point,
> and it's something that we'll want to have beyond just the F21 release.

Are arbitrary inter-product conversions supportable long-term? We can
test if a default install of F20 converts into a reasonable
approximation of Fedora Workstation 21. But are we going test that a F23
Workstation converts properly to a F23 Server?

> I can see the convenience value of letting people check a box or give a flag
> at the F20->F21 upgrade point. I wish we had thought of that several months
> ago, but I don't think anyone did (or we dropped it if it were mentioned,
> sadly). At this point, since the fedup maintainers aren't sold and we're
> working on validating the beta already, *and* because the upgrade-to-convert
> situation is a one time thing, I think we should put our efforts into the
> convert-at-any-time situation.

I don't see it as a convenience value - rather it's our main point of
control make sure that everybody who wants to be on a product line
actually ends up on a product line.

As an example: this subject came up on the workstation mailing list
because there was a proposal to make the network login functionality in
Fedora 21 a package that is pulled in by fedora-release-workstation
rather than gnome-shell. If we carry through with that (probably depends
on the result of this discussion), then people who upgraded to
non-productized F21 would be missing one of the most useful new features
in Fedora 21 workstation.

But that's just one example of how a non-productized Fedora is not what
we're advertising. With subsequent releases of Fedora the gap will grow
- but *now* is the best time to make people pick a product if they want
one.

We could compensate a bit for lack of the feature by making fedup put up
a big warning message that directed people to a wiki page with manual
instructions - I don't think it looks professional, but it would be
better than nothing.

- Owen

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retiring OpenShift v2 non-client packages from Fedora

2014-10-03 Thread Haïkel

This makes sense to me, though it annoys me as a token of our failure
to be an attractive platform for such use cases.

DId you consider providing a copr repository ?

Regards,
H.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

2014-10-03 Thread Orion Poplawski


On 10/01/2014 08:39 PM, Rahul Sundaram wrote:

Hi

Is it worth considering using Dash as the default (non-interactive)
shell in Fedora?  Other distributions including Ubuntu and Debian
(https://lwn.net/Articles/343924/) have been using dash as the default
shell and Android uses mksh.  While this appears to have been done
primary to increase bootup efficiency (which is not relevant with
systemd), it might help with security


More bashism's in .spec files:

+ pushd src
/tmp/rpm/rpm-tmp.047Jay: 43: /tmp/rpm/rpm-tmp.047Jay: pushd: not found



--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retiring OpenShift v2 non-client packages from Fedora

2014-10-03 Thread Stephen Gallagher

On Fri, 2014-10-03 at 21:43 +0200, Haïkel wrote:
> This makes sense to me, though it annoys me as a token of our failure
> to be an attractive platform for such use cases.
> 
> DId you consider providing a copr repository ?

A COPR repository probably wouldn't work, because they'd have to provide
a conflicting version of the ruby platform. I doubt that would fly. They
*could* stick a private copy of ruby in a non-standard location and use
it, but that's an awful lot of work for uncertain gain.

* I'm not an OpenShift dev

signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

On Fri, Oct 03, 2014 at 02:29:53PM -0600, Orion Poplawski wrote:
> >Is it worth considering using Dash as the default (non-interactive)
> >shell in Fedora?  Other distributions including Ubuntu and Debian
> >(https://lwn.net/Articles/343924/) have been using dash as the default
> >shell and Android uses mksh.  While this appears to have been done
> >primary to increase bootup efficiency (which is not relevant with
> >systemd), it might help with security
> 
> More bashism's in .spec files:
> + pushd src
> /tmp/rpm/rpm-tmp.047Jay: 43: /tmp/rpm/rpm-tmp.047Jay: pushd: not found

All the other things aside, I think it'd be fine for us to leave bash as the
shell for spec file scripts even if we changed /bin/sh and/or the root
shell.

-- 
Matthew Miller

Fedora Project Leader
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retiring OpenShift v2 non-client packages from Fedora

2014-10-03 Thread Haïkel

2014-10-03 22:30 GMT+02:00 Stephen Gallagher :
>
>
>
> On Fri, 2014-10-03 at 21:43 +0200, Haïkel wrote:
>> This makes sense to me, though it annoys me as a token of our failure
>> to be an attractive platform for such use cases.
>>
>> DId you consider providing a copr repository ?
>
>
> A COPR repository probably wouldn't work, because they'd have to provide
> a conflicting version of the ruby platform. I doubt that would fly. They
> *could* stick a private copy of ruby in a non-standard location and use
> it, but that's an awful lot of work for uncertain gain.
>
> * I'm not an OpenShift dev
>

In this case, I was thinking about using an SCL. Just asking, not
forcing a burden upon anyone.m

I guess, this is where the work from Env&Stack WG will be critical to
ensure that Fedora remains a viable platform for services developers
(not only OpenShift).

H.

> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: How to handle upgrades to Fedora 21

2014-10-03 Thread Stephen Gallagher




On Wed, 2014-10-01 at 16:28 -0400, Stephen Gallagher wrote:
> 
> 
> On Wed, 2014-09-24 at 12:16 -0400, Stephen Gallagher wrote:
> > There has been some discussion in various forums lately about how we
> > will handle fedup upgrades from Fedora 20 to Fedora 21 products.
> > 
> > Several suggestions have been made that warrant discussion:
> > 
> >  1) Upgrades from Fedora 20 remain non-productized. They pick up
> > fedora-release-standard and upgrade only their existing packages.
> 
> 
> I've had a number of conversations with the yum/dnf and fedup people
> over the last week. The tl;dr version: option 1) is the only realistic
> option.
> 
> So, a bit more contributing detail:
> 
> First, the Products have both a minimal set and a default set of
> functionality that they want to have exposed if that Product is
> installed. What we've decided that this means is that, barring explicit
> influence, anyone who is installing Fedora Workstation or Fedora Server
> should be getting the default set of functionality and can later (or in
> a kickstart file) trim it back.
> 
> Without changing the fedup package in Fedora, we could do upgrades to
> each of the Products or non-productized versions by providing on F20 a
> do-nothing fedora-release-[standard|cloud|server|workstation] file that
> in F21 has explicit requirements on any of the packages necessary to
> reach the minimal set of functionality. We can't force it to the default
> set (without allowing RPM soft dependencies, which is not currently
> supported or well-tested in Fedora), so upgrading through this path
> wouldn't guarantee the preferred result state (particularly for
> Workstation, which wants to have a certain set of common applications
> installed by default). Furthermore, it makes the upgrade process more
> complicated because it would require the user to manually install
> 'fedora-release-standard' in order to get the non-productized experience
> and they would not be able to upgrade *at all* without selecting one of
> them.
> 
> Fedora officially only supports upgrades from a *fully-upgraded Fedora*
> to the next version, so we could work around this by adding a temporary
> explicit Requires: fedora-release-standard on the F20 fedora-release
> package, thereby forcing all upgrades to be non-productized. This is my
> recommended approach as it requires only a single change (the added
> Requires:) to fedora-release to make it work. The end-result of this
> upgrade is a system that is just a newer version of whatever DIY set of
> packages the previously-F20 system was running.
> 
> It's also possible that we could rig up a selectable approach by
> creating a full set of empty fedora-release-* packages and arranging it
> so that fedora-release-standard satisfied the upgrade requirement if it
> wasn't specified, but this requires us to make sure that the automatic
> dependency-resolution for all of yum, dnf, gnome-software, yumex and
> apper all selects the correct default. I know for a fact that at least
> yum and dnf follow different resolution patterns, so while it could be
> possible, it would be a nasty hack relying on internal knowledge of the
> tools. That seems somewhat fragile to me, but it could be done if we
> strongly want it.
> 
> The thing to note is that in all scenarios, the user *MUST* fully update
> their F20 system first, or the results will be undefined and could be
> unpleasant. We need to spell this out very clearly to our upgrading
> users.



Yet one more change. A number of folks from the Workstation, Server and
fedup teams got together in #fedora-workstation today and hashed out a
new plan. We decided that it was fine to modify fedup and that it was
also acceptable to force the user to make a choice at upgrade time.

To that end, fedup will grow a new mandatory option: --product. It will
take one of four arguments: "standard" (non-productized), "server",
"workstation" or cloud.

For each of the Products, fedup will inject the appropriate set of
packages necessary to make the resulting system contain a superset of
the packages that one would get with a default installation of the
selected Product. (In a technical sense, it would essentially be
injecting "@^$PRODUCT-product-environment" onto the yum installation
command to ensure that all of those packages are part of the
transaction).

I have sent an email to the QA folks to get this arrangement added to
the Beta Criteria, since that's our last chance to realistically test
upgrades before release. So fixing this becomes a blocker to Beta.


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: How to handle upgrades to Fedora 21

2014-10-03 Thread Owen Taylor

On Fri, 2014-10-03 at 16:57 -0400, Stephen Gallagher wrote:
> To that end, fedup will grow a new mandatory option: --product. It will
> take one of four arguments: "standard" (non-productized), "server",
> "workstation" or cloud.

I volunteered to come up with the text if you dont' specify --product.
An initial draft follows:

-
This installation of Fedora does not belong to a product, so you
must provide the --product=PRODUCTNAME option to specify what product
you want to upgrade to. PRODUCTNAME should be one of:

 workstation: the default Fedora experience for laptops and desktops
 server: the default Fedora experience for servers
 cloud: a base image for use on public and private clouds
 standard: choose this if none of the above apply; in particular choose
   this if you are using an alternate-desktop spin of Fedora

See https://fedoraproject.org/wiki/Upgrading for more information.
---

Feedback from this wide audience appreciated. Would you know what option
to pick?

Thanks,
Owen

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: How to handle upgrades to Fedora 21

Hi

On Fri, Oct 3, 2014 at 4:57 PM, Stephen Gallagher  wrote:

> To that end, fedup will grow a new mandatory option: --product. It will
> take one of four arguments: "standard" (non-productized), "server",
> "workstation" or cloud.
>

When the discussion about the "standard" name came up earlier in fedora
desktop list, one counter point was that standard isn't going to be very
visible to users but if you are going to use that term in fedup, it becomes
even more visible.  Do you still want to not use "generic" here?

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: How to handle upgrades to Fedora 21

2014-10-03 Thread Reindl Harald


Am 03.10.2014 um 23:12 schrieb Rahul Sundaram:
> On Fri, Oct 3, 2014 at 4:57 PM, Stephen Gallagher wrote:
> 
> To that end, fedup will grow a new mandatory option: --product. It will
> take one of four arguments: "standard" (non-productized), "server",
> "workstation" or cloud.
> 
> When the discussion about the "standard" name came up earlier in fedora 
> desktop list, one counter point was that
> standard isn't going to be very visible to users but if you are going to use 
> that term in fedup, it becomes even
> more visible.  Do you still want to not use "generic" here?

"generic" is technical speak or for "normal" people outside IT at best
has a negative context to "generica" and spam - "standard" for the
ordinary user means "not specialized so likely the best decision for me"

well, that may be somehow different in native english countries




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

2014-10-03 Thread Orion Poplawski


On 10/03/2014 02:34 PM, Matthew Miller wrote:

On Fri, Oct 03, 2014 at 02:29:53PM -0600, Orion Poplawski wrote:

Is it worth considering using Dash as the default (non-interactive)
shell in Fedora?  Other distributions including Ubuntu and Debian
(https://lwn.net/Articles/343924/) have been using dash as the default
shell and Android uses mksh.  While this appears to have been done
primary to increase bootup efficiency (which is not relevant with
systemd), it might help with security


More bashism's in .spec files:
+ pushd src
/tmp/rpm/rpm-tmp.047Jay: 43: /tmp/rpm/rpm-tmp.047Jay: pushd: not found


All the other things aside, I think it'd be fine for us to leave bash as the
shell for spec file scripts even if we changed /bin/sh and/or the root
shell.



Yeah, I'm wondering if an rpm bug is in order here now to explicitly use 
/bin/bash.


--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: How to handle upgrades to Fedora 21

Hi

On Fri, Oct 3, 2014 at 5:38 PM, Reindl Harald  wrote:

> "generic" is technical speak or for "normal" people outside IT at best
> has a negative context to "generica" and spam

It is not really technical.  Generic is often used in other contexts by
"normal" people:  Ex: Generic drugs which means non branded.

 - "standard" for the
> ordinary user means "not specialized so likely the best decision for me"
>

Exactly the message Fedora doesn't want to send to its users.  Thanks for
confirming.

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

2014-10-03 Thread Orion Poplawski


On 10/03/2014 03:55 PM, Orion Poplawski wrote:

On 10/03/2014 02:34 PM, Matthew Miller wrote:

On Fri, Oct 03, 2014 at 02:29:53PM -0600, Orion Poplawski wrote:

Is it worth considering using Dash as the default (non-interactive)
shell in Fedora?  Other distributions including Ubuntu and Debian
(https://lwn.net/Articles/343924/) have been using dash as the default
shell and Android uses mksh.  While this appears to have been done
primary to increase bootup efficiency (which is not relevant with
systemd), it might help with security


More bashism's in .spec files:
+ pushd src
/tmp/rpm/rpm-tmp.047Jay: 43: /tmp/rpm/rpm-tmp.047Jay: pushd: not found


All the other things aside, I think it'd be fine for us to leave bash
as the
shell for spec file scripts even if we changed /bin/sh and/or the root
shell.



Yeah, I'm wondering if an rpm bug is in order here now to explicitly use
/bin/bash.


http://rpm.org/ticket/877

--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

Hi

On Fri, Oct 3, 2014 at 9:04 AM, Garry T. Williams 
wrote:

>
> $ (checkbashisms -f -p $(grep -rlE '^#! ?/bin/(env )?sh' /usr/bin) )
> 2>&1 >/dev/null|grep 'possible bashism'|awk '{print $4}'|sort -u|wc -l
> 113
> $
>
> Many of these trigger multiple warnings from checkbashisms.  The total
> here was 717.  (Fedora 20, KDE.)
>

Those numbers are fairly misleading if you look a bit closer.   Each
individual script has to be run through dash to confirm that it isn't a
false warning.  If it truly uses bash specific syntax, then there is a bug
in the script  and it should be changed to use !/usr/bin/bash (quicker) as
opposed to !/bin/bash or fixed to remove bash specific syntax (more
portable).  Regardless of whether we are switching the default system
shell, any shell script that uses bash syntax should be fixed to use
!/usr/bin/bash.  A lot of this work has already been done by Debian/Ubuntu.

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: How to handle upgrades to Fedora 21

2014-10-03 Thread Reindl Harald


Am 03.10.2014 um 23:57 schrieb Rahul Sundaram:
> On Fri, Oct 3, 2014 at 5:38 PM, Reindl Harald wrote:
> 
> "generic" is technical speak or for "normal" people outside IT at best
> has a negative context to "generica" and spam
> 
> 
> It is not really technical.  Generic is often used in other contexts by 
> "normal" 
> people:  Ex: Generic drugs which means non branded.

"generic drugs" is the one thing nobody wants to have in context honestly

> - "standard" for the
> ordinary user means "not specialized so likely the best decision for me"
> 
> Exactly the message Fedora doesn't want to send to its users. Thanks for 
> confirming

why? "not specialized" means "i can likely do anything i want with that" and is 
true

it is the exactly right message for any user which has no clue
what the products may mean for him or if he is unsure which
one is the best - so in doubt just use "standard" and later
install whatever you need as all the years before is the
correct decision

why would you try to force somebody to a "prodcut setup"
if he can't give you an answer to the question "which"?



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: How to handle upgrades to Fedora 21

Hi

On Fri, Oct 3, 2014 at 6:15 PM, Reindl Harald  wrote:

>
> "generic drugs" is the one thing nobody wants to have in context honestly
>

Not true  but irrelevant anyway since I was just pointing out that generic
is not a technical term.

why would you try to force somebody to a "prodcut setup"
> if he can't give you an answer to the question "which"?
>

Noone is forcing anything since non productized variants are continued to
be supported but the emphasis is on the products (whether you think it
should be is a different discussion) and as you confirmed, the use of the
term "standard" doesn't convey that to the user

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: How to handle upgrades to Fedora 21

2014-10-03 Thread Reindl Harald


Am 04.10.2014 um 00:29 schrieb Rahul Sundaram:
> On Fri, Oct 3, 2014 at 6:15 PM, Reindl Harald wrote: 
> 
> "generic drugs" is the one thing nobody wants to have in context honestly
> 

> Not true  but irrelevant anyway since I was just pointing out that generic is 
> not a technical term.
> 
> why would you try to force somebody to a "prodcut setup"
> if he can't give you an answer to the question "which"?
> 
> Noone is forcing anything since non productized variants are continued to be 
> supported but the emphasis is on the
> products (whether you think it should be is a different discussion) and as 
> you confirmed, the use of the term
> "standard" doesn't convey that to the user

and *because* non productized variants are continued there should
be no emphasis instead *equal options* - the products make sense
for a user who can answer within 5 seconds sitting in front of
the option to chose the question which one is the best for him

i bet many can't because they would need multiple choice



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: How to handle upgrades to Fedora 21

Hi

On Fri, Oct 3, 2014 at 6:34 PM, Reindl Harald  wrote:

> and *because* non productized variants are continued there should
> be no emphasis instead *equal options*
>

Fedora as a project has already discussed that extensively and decided
otherwise.  We are not really revisiting that discussion here.

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

2014-10-03 Thread Nico Kadel-Garcia

On Fri, Oct 3, 2014 at 6:14 PM, Rahul Sundaram  wrote:
> Hi
>
> On Fri, Oct 3, 2014 at 9:04 AM, Garry T. Williams 
> wrote:
>>
>>
>> $ (checkbashisms -f -p $(grep -rlE '^#! ?/bin/(env )?sh' /usr/bin) )
>> 2>&1 >/dev/null|grep 'possible bashism'|awk '{print $4}'|sort -u|wc -l
>> 113
>> $
>>
>> Many of these trigger multiple warnings from checkbashisms.  The total
>> here was 717.  (Fedora 20, KDE.)
>
>
> Those numbers are fairly misleading if you look a bit closer.   Each
> individual script has to be run through dash to confirm that it isn't a
> false warning.  If it truly uses bash specific syntax, then there is a bug
> in the script  and it should be changed to use !/usr/bin/bash (quicker) as
> opposed to !/bin/bash or fixed to remove bash specific syntax (more
> portable).  Regardless of whether we are switching the default system shell,
> any shell script that uses bash syntax should be fixed to use
> !/usr/bin/bash.  A lot of this work has already been done by Debian/Ubuntu.

And it's going to break backports to EPEL for RHEL 5 or RHEL 6, or
CentOS or Scientific Linux,  pretty seriously. It's unnecessary,
confusing, and non-backwards-compatible: I wouldn't suggest this until
well after RHEL 7 or later becomes the majority of EPEL traffic, just
out of courtesy to the paying customers who  fund Fedora developers.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

Hi

On Fri, Oct 3, 2014 at 6:59 PM, Nico Kadel-Garci wrote:

> And it's going to break backports to EPEL for RHEL 5 or RHEL 6, or
> CentOS or Scientific Linux,  pretty seriously
>

Please explain how.

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

2014-10-03 Thread Jakub Jelinek

On Fri, Oct 03, 2014 at 06:14:05PM -0400, Rahul Sundaram wrote:
> On Fri, Oct 3, 2014 at 9:04 AM, Garry T. Williams 
> wrote:
> 
> >
> > $ (checkbashisms -f -p $(grep -rlE '^#! ?/bin/(env )?sh' /usr/bin) )
> > 2>&1 >/dev/null|grep 'possible bashism'|awk '{print $4}'|sort -u|wc -l
> > 113
> > $
> >
> > Many of these trigger multiple warnings from checkbashisms.  The total
> > here was 717.  (Fedora 20, KDE.)
> >
> 
> Those numbers are fairly misleading if you look a bit closer.   Each
> individual script has to be run through dash to confirm that it isn't a
> false warning.  If it truly uses bash specific syntax, then there is a bug
> in the script  and it should be changed to use !/usr/bin/bash (quicker) as
> opposed to !/bin/bash or fixed to remove bash specific syntax (more
> portable).  Regardless of whether we are switching the default system
> shell, any shell script that uses bash syntax should be fixed to use
> !/usr/bin/bash.  A lot of this work has already been done by Debian/Ubuntu.

But why?  Seriously, bash has lots of nice extensions, are you going in this
quest to stop using extensions going to suggest that we get rid of GNU C
library extensions usages in the distro programs next, or GCC extensions,
what else?  Several people are using the term bashism as something negative,
I'm not convinced it should be something negative just because Ubuntu
decided to use a less featured shell by default.

Jakub
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

Hi

On Fri, Oct 3, 2014 at 7:12 PM, Jakub Jelinek wrote:

>
> But why?  Seriously, bash has lots of nice extensions, are you going in
> this
> quest to stop using extensions
>

You seem to have misread what I said.   Bash is great and I love some of
the extensions but if you want to use bash, just make sure you have
!/usr/bin/bash on your shell scripts and not !/bin/sh.  That's all

Rahul.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: How to handle upgrades to Fedora 21

2014-10-03 Thread Michael Catanzaro

On Fri, 2014-10-03 at 17:06 -0400, Owen Taylor wrote:
>  standard: choose this if none of the above apply; in particular
> choose
>this if you are using an alternate-desktop spin of Fedora

I'd add a comma right after "in particular."

> Feedback from this wide audience appreciated. Would you know what
> option
> to pick?

Yes, it's clear.

I agree with Rahul that "standard" is not a great name for the
nonstandard, non-productized upgrade, though. "Generic" is more
descriptive anyway.


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

2014-10-03 Thread Chris Adams

Once upon a time, Jakub Jelinek  said:
> But why?  Seriously, bash has lots of nice extensions, are you going in this
> quest to stop using extensions going to suggest that we get rid of GNU C
> library extensions usages in the distro programs next, or GCC extensions,
> what else?

To be fair, portable programs wrap GCCisms in #ifdefs.
-- 
Chris Adams 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: How to handle upgrades to Fedora 21

On Fri, Oct 03, 2014 at 06:18:11PM -0500, Michael Catanzaro wrote:
> I agree with Rahul that "standard" is not a great name for the
> nonstandard, non-productized upgrade, though. "Generic" is more
> descriptive anyway.

But vanilla is the most delicious.

-- 
Matthew Miller

Fedora Project Leader
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: How to handle upgrades to Fedora 21

2014-10-03 Thread Ray Strode

Hi,
> I agree with Rahul that "standard" is not a great name for the
> nonstandard, non-productized upgrade, though. "Generic" is more
> descriptive anyway.

I'm not sure it's worth repainting the bikeshed at this point, but
during the alluded-to discussion a few alternative names came up that
would have been better than fedora-release-standard:

1) fedora-release-nonstandard
2) fedora-release-custom
3) fedora-release-diy
4) fedora-release-noncompliant

and i'll just throw another out there now

5) fedora-release-respin

If we do want to change it, it should happen soon

--Ray
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: btrfs as default filesystem for F22?

2014-10-03 Thread Ian Kent

On Fri, 2014-10-03 at 13:18 +0200, Juan Orti Alcaine wrote:
> El 2014-10-03 11:38, Steven Whitehouse escribió:
> > Hi,
> > I should also add (just in case anybody gets the wrong idea!) that I
> > think it should definitely be made as easy as possible for anybody who
> > wants to evaluate running btrfs on Fedora, but it is far too early to
> > make it the default yet,
> > 
> 
> I agree with your opinion, it's a bit too early. An experienced user can 
> deal with the idiosyncrasies of btrfs and it's great when you learn it, 
> but pushing it as the default seems too adventurous.
> 
> I want to add to the list of problems the performance degradation over 
> time in database-like files (journal, vm images, firefox and other 
> sqlite db). I have experienced minutes of delay consulting the journal 
> in heavily fragmented journal files.

I still have to agree with not making btrfs the default.

Sadly, I see BUG(), ENOSPC error reports (seem to have returned), and
btrfs-progs SEGV reports on the btrfs mailing quite regularly and while
much of the functionality may now be stable all the features of the
default file system will get stressed more than the other file systems,
including the perhaps not so stable ones.

> 
> -- 
> Juan Orti
> https://miceliux.com
> 


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell