Re: Draft Product Description for Fedora Workstation
On Mon, Nov 04, 2013 at 11:05:21PM +0100, Nicolas Mailhot wrote: As all such schemes it works as long as you ignore the fact that apps process data and communicate with other apps. That's not being overlooked. Probably the presentation already addresses this concern. -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1026715] New: perl-Test-Class-0.40 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1026715 Bug ID: 1026715 Summary: perl-Test-Class-0.40 is available Product: Fedora Version: rawhide Component: perl-Test-Class Keywords: FutureFeature, Triaged Assignee: st...@silug.org Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-de...@lists.fedoraproject.org, st...@silug.org Latest upstream release: 0.40 Current version/release in Fedora Rawhide: 0.39-3.fc20 URL: http://search.cpan.org/dist/Test-Class/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=PnnubSWEdxa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Draft Product Description for Fedora Workstation
On Mon, Nov 04, 2013 at 06:19:48PM +0100, Kevin Kofler wrote: I disagree with the premise that to get anywhere, we would need to bend over backwards to the proprietary market and adopt their inferior software distribution strategies. If that were true, we could give up right here, we'd have already lost. [..] If Adobe were to want Photoshop on a linux desktop, I think that would be great news. It would be hugely disruptive. Hugely disruptive to your freedom, indeed… What's wrong with GIMP? I don't get why you want to force your view of freedom onto everyone. These sandboxed applications is not just for proprietary software. I don't think it'll replace the current distribution model. It will generate some competition. IMO competition is good, instead of preventing sandboxed applications, show that the packaged applications are preferred. Now such distribution of applications also easily allow proprietary applications: Awesome, finally! Easy to run Steam, Photoshop, etc. The kernel is GPL and doesn't force this licence on Adobe. You can have whatever license you want as application. These sandboxed applications do suffer from various drawbacks, so better to believe in your solution than to try and block another view IMO. -- Regards, Olav -- 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: Old kernels from FC19
Łukasz Trąbiński wrote:
when i boot machines with many ethernet devices I got
random number ethX. Once eth0 is eth0, after reboot eth0 is eth1.
After again boot eth1 is eth1 and so on.
I had a problem like that, which began when I upgraded to Fedora 17. I
worked around it by writing these Udev rules in a file
named /etc/udev/rules.d/01-network-interface-naming.rules:
ACTION==add, SUBSYSTEM==net, ATTR{address}==00:0c:46:16:d0:bc,
NAME:=world
ACTION==add, SUBSYSTEM==net, ATTR{address}==00:1e:8c:cf:cd:e5,
NAME:=gigabit
ACTION==add, SUBSYSTEM==net, ATTR{address}==00:16:6f:a9:95:34,
NAME:=wifi
--
Björn Persson
Sent from my computer.
signature.asc
Description: PGP 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: Draft Product Description for Fedora Workstation
Le Lun 4 novembre 2013 23:02, Nicolas Mailhot a écrit : The problem is not to get code in the hands of developers. You don't need distros for that. The problem is to get the code to end-users and developers spend more time fighting the constrains it involves than trying to understand this problem-space. Of course the aim might not be to reach end users but to push code from developpers to other developers. And if that is the case, there is a huge disconnect between GNOME goals and Fedora Workstation goals. GNOME speakers repeat all year round their software is not aimed at power users, but developers are the über power user. -- Nicolas Mailhot -- 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: Draft Product Description for Fedora Workstation
On Tue, Nov 5, 2013 at 12:35 PM, Nicolas Mailhot nicolas.mail...@laposte.net wrote: Le Lun 4 novembre 2013 23:02, Nicolas Mailhot a écrit : The problem is not to get code in the hands of developers. You don't need distros for that. The problem is to get the code to end-users and developers spend more time fighting the constrains it involves than trying to understand this problem-space. Of course the aim might not be to reach end users but to push code from developpers to other developers. And if that is the case, there is a huge disconnect between GNOME goals and Fedora Workstation goals. GNOME speakers repeat all year round their software is not aimed at power users, but developers are the über power user. Depends on what you mean by power user (I hate this meaningless term) if it means software developer then yes. If it means someone that spends his whole day in config dialogs then no. -- 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: Draft Product Description for Fedora Workstation
On Tue, Nov 5, 2013 at 6:35 AM, Nicolas Mailhot nicolas.mail...@laposte.net wrote: Le Lun 4 novembre 2013 23:02, Nicolas Mailhot a écrit : The problem is not to get code in the hands of developers. You don't need distros for that. The problem is to get the code to end-users and developers spend more time fighting the constrains it involves than trying to understand this problem-space. Of course the aim might not be to reach end users but to push code from developpers to other developers. And if that is the case, there is a huge disconnect between GNOME goals and Fedora Workstation goals. GNOME speakers repeat all year round their software is not aimed at power users, but developers are the über power user. Fortunately, the WG can highlight the areas in whatever software they choose that need to be modified to accomplish the WG's goals. And due to the wonderfulness of open source, Fedora can make those changes. Work with whatever upstream is in question to see if there are changes that can be done in a manner that benefit both. Basically, collaboration and compromise are going to be required. josh -- 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: Draft Product Description for Fedora Workstation
On Tue, 5 Nov 2013 12:53:15 +0100 drago01 drag...@gmail.com wrote: Depends on what you mean by power user (I hate this meaningless term) if it means software developer then yes. If it means someone that spends his whole day in config dialogs then no. Maybe? http://www.techterms.com/definition/poweruser -- Regards, Frank www.frankly3d.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: Draft Product Description for Fedora Workstation
On Tue, Nov 5, 2013 at 12:58 PM, Frank Murphy frankl...@gmail.com wrote: On Tue, 5 Nov 2013 12:53:15 +0100 drago01 drag...@gmail.com wrote: Depends on what you mean by power user (I hate this meaningless term) if it means software developer then yes. If it means someone that spends his whole day in config dialogs then no. Maybe? http://www.techterms.com/definition/poweruser This is mostly about having powerful hardware, which our users have the freedom to buy and run fedora on. Since we build software and not hardware it does not matter much. -- 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: Draft Product Description for Fedora Workstation
On Tue, 5 Nov 2013 12:35:30 +0100 Nicolas Mailhot nicolas.mail...@laposte.net wrote: And if that is the case, there is a huge disconnect between GNOME goals and Fedora Workstation goals. GNOME speakers repeat all year round their software is not aimed at power users, but developers are the über power user. Not all developers use Gnome, if they did, the other DEs' would not exist (within Fedora). -- Regards, Frank www.frankly3d.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
F-20 Branched report: 20131105 changes
Compose started at Tue Nov 5 09:15:06 UTC 2013 Broken deps for armhfp -- [blueman] blueman-1.23-7.fc20.armv7hl requires obex-data-server = 0:0.4.3 blueman-1.23-7.fc20.armv7hl requires gvfs-obexftp [bwm-ng] bwm-ng-0.6-11.1.fc20.armv7hl requires libstatgrab.so.9 [cloud-init] cloud-init-0.7.2-7.fc20.noarch requires dmidecode [cobbler] cobbler-2.4.0-2.fc20.noarch requires syslinux [condor-wallaby] condor-wallaby-client-5.0.3-4.fc20.noarch requires python-qmf = 0:0.9.1073306 [fts] fts-server-3.1.1-1.fc20.armv7hl requires libactivemq-cpp.so.14 [glpi] glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Version glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Stdlib glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-ServiceManager glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Loader glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-I18n glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Cache-apc glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Cache [gnome-do-plugins] gnome-do-plugins-thunderbird-0.8.4-14.fc20.armv7hl requires thunderbird [gofer] ruby-gofer-0.75-4.fc20.noarch requires rubygem(qpid) = 0:0.16.0 [gradle] gradle-1.0-18.fc20.noarch requires plexus-container-default [grass] grass-6.4.3-2.fc20.armv7hl requires libgeos-3.3.8.so grass-libs-6.4.3-2.fc20.armv7hl requires libgeos-3.3.8.so [gtkd] gtkd-geany-tags-2.0.0-29.20120815git9ae9181.fc18.noarch requires gtkd = 0:2.0.0-29.20120815git9ae9181.fc18 [kawa] 1:kawa-1.11-5.fc19.armv7hl requires servlet25 [koji] koji-vm-1.8.0-2.fc20.noarch requires python-virtinst [kyua-cli] kyua-cli-0.5-3.fc19.armv7hl requires liblutok.so.0 kyua-cli-tests-0.5-3.fc19.armv7hl requires liblutok.so.0 [monotone] monotone-1.0-11.fc19.armv7hl requires libbotan-1.8.2.so perl-Monotone-1.0-11.fc19.armv7hl requires perl(:MODULE_COMPAT_5.16.2) [mozilla-firetray] mozilla-firetray-thunderbird-0.3.6-0.5.143svn.fc18.1.armv7hl requires thunderbird = 0:11 [msp430-libc] msp430-libc-20120224-2.fc19.noarch requires msp430-gcc = 0:4.6.3 [nifti2dicom] nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtksys.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkWidgets.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkVolumeRendering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkViews.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkTextAnalysis.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkRendering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkParallel.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkInfovis.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkImaging.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkIO.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkHybrid.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGraphics.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGeovis.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGenericFiltering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkFiltering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkCommon.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkCharts.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libQVTK.so.5.10 [nocpulse-common] nocpulse-common-2.2.7-2.fc20.noarch requires perl(RHN::DBI) [openbox] gdm-control-3.5.2-2.fc20.armv7hl requires gnome-panel gnome-panel-control-3.5.2-2.fc20.armv7hl requires gnome-panel [openpts] openpts-0.2.6-7.fc20.armv7hl requires tboot [osm2pgsql] osm2pgsql-0.82.0-1.fc20.armv7hl requires libgeos-3.3.8.so [oyranos] oyranos-libs-0.4.0-7.fc19.armv7hl requires libraw.so.5 [perl-BerkeleyDB] perl-BerkeleyDB-0.53-1.fc20.armv7hl requires libdb = 0:5.3.21 [perl-Language-Expr] perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) [perl-MIME-Lite-HTML] perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) [perl-Padre] perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) [pure] pure-doc-0.57-4.fc20.noarch requires pure = 0:0.57-4.fc20 [python-tag] python-tag-2013.1-1.fc20.armv7hl requires libboost_python.so.1.53.0 [rootplot] rootplot-2.2.1-7.fc19.noarch requires root-python [ruby-spqr] ruby-spqr-0.3.6-7.fc20.noarch requires ruby-qpid-qmf [rubygem-audited-activerecord] rubygem-audited-activerecord-3.0.0-3.fc19.noarch requires rubygem(activerecord) 0:4 [rubygem-fog] rubygem-fog-1.11.1-1.fc20.noarch requires rubygem(nokogiri) 0:1.6 [scala]
Re: Packages have proxy word.
On Fri, Nov 01, 2013 at 02:54:15PM +0100, Stanislav Ochotnicky wrote: Quoting Zbigniew Jędrzejewski-Szmek (2013-11-01 13:52:31) On Fri, Nov 01, 2013 at 12:09:03PM +, Daniel P. Berrange wrote: On Fri, Nov 01, 2013 at 02:07:22AM +0100, Zbigniew Jędrzejewski-Szmek wrote: On Fri, Nov 01, 2013 at 01:08:33AM +0200, مصعب الزعبي wrote: بسم الله الرّحمن الرّحيم Hi, The result of updating Fedora by yum is fail !! When any package have proxy word marked to (install or update) , error message will appear with http 403 error forbidden. In my country Syria (maybe others) all URLs have proxy word are forbidden and couldn't open by default way. I think you'll have to use a... proxy to work around this problem. Or maybe it'll be enough to use a https connection to the mirror. NB, US export restrictions that Fedora is subject to mean users from Syria should not be downloading Fedora at all[1], via a proxy or not. Let's consider how likely this export restriction is to prevent a member of the Syrian government or military from obtaining a copy of Fedora? Not very likely. How likely this export restriction is to hurt a random person, e.g. trying to install open source to avoid restrictions imposed by their government? The first is a joke, the second is high enough to keep this restriction in the same contempt as the Syrian government's ban on proxy. You are walking on thin ice and should stop immediately He's right though. The law as it applies to general purpose software is stupid, immoral and counterproductive. But it is the law, at least in the United States and European Union[1]. Rich. [1] http://ec.europa.eu/trade/policy/countries-and-regions/countries/syria/ -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top -- 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: Old kernels from FC19
Thank I will try this solution and i will try catch ooops from kernel.
2013/11/5 Björn Persson bj...@xn--rombobjrn-67a.se
Łukasz Trąbiński wrote:
when i boot machines with many ethernet devices I got
random number ethX. Once eth0 is eth0, after reboot eth0 is eth1.
After again boot eth1 is eth1 and so on.
I had a problem like that, which began when I upgraded to Fedora 17. I
worked around it by writing these Udev rules in a file
named /etc/udev/rules.d/01-network-interface-naming.rules:
ACTION==add, SUBSYSTEM==net, ATTR{address}==00:0c:46:16:d0:bc,
NAME:=world
ACTION==add, SUBSYSTEM==net, ATTR{address}==00:1e:8c:cf:cd:e5,
NAME:=gigabit
ACTION==add, SUBSYSTEM==net, ATTR{address}==00:16:6f:a9:95:34,
NAME:=wifi
--
Björn Persson
Sent from my computer.
--
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: Draft Product Description for Fedora Workstation
On Mon, 2013-11-04 at 18:19 +0100, Kevin Kofler wrote: Chris Murphy wrote: Right, because that's a model for success that shouldn't be either emulated or improved upon, it's better for each little fiefdom's paradise to erect walls to ensure cross influence isn't happening. Your insulting the Free Software community as a fiefdom really offends me. Well Kevin, I normally agree with a lot of what you say, but if fiefdom offends you, your pretense to decide for the users *really* offends me. I will not cite every passage here, but you keep complaining that allowing a different distribution model somehow implicitly will cast doom on Free Software. First of all that is plain nonsense, the distribution model has nothing to do with licenses and a Free software App store is no more proprietary than a distribution specific repository, which in our case is exactly the default Fedora App Store if you want. But what I find terrible is that you want to make technical decisions that *limit* users freedom, and this is *inexcusable*. One of the most important things about freedom is to let the user be *free*. Yes, to the point he can entrap himself. Our duty as Free Software developers is to provide Free Software alternatives, not to make life difficult for our users to try to force them in our own world view, that's what totalitarianism is about. Users will choose anyway, so the only thing you attain when trying to put bars around a user is to have the users go away. Nobody likes cages not even if they are made of Free Software bars. Hugely disruptive to your freedom, indeed… What's wrong with GIMP? Yeah and what's wrong with the *actual* Freedom to choose what to use ? We are not talking about distributing proprietary apps in fedora or making them better than Free Software apps, so stop being stubborn and look at the reality of things. Users want a better experience, and upstreams are often in a position to do so, we just need to provide them with the tools to do it w/o compromising the platform in the process. A system that allows a user to install sandboxed[*] applications is better than what we have now for some cases, and I see no reason why you should be so upset about allowing a technical solution to a problem users have whether you like what they are going to do with it or not. Simo. * and *ideally* I mean SELinux sanbdboxed with specific APIs that must be used to interact with the rest of the system, so that the application doesn't have free reign over users files. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1026708] perl-IPC-Cmd-0.86 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1026708 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-IPC-Cmd-0.86-1.fc21 Resolution|--- |RAWHIDE Last Closed||2013-11-05 08:36:23 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=lQPH81rskwa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Test-Reporter-1.60.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Test-Reporter: e36fc3c25a71b2ceba2ae21c6a2e02fc Test-Reporter-1.60.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-Reporter] 1.60 bump
commit 00647923a7b0a583abb8f1b9513d6d8d83ffd35c
Author: Petr Písař ppi...@redhat.com
Date: Tue Nov 5 14:37:26 2013 +0100
1.60 bump
.gitignore |1 +
perl-Test-Reporter.spec | 11 +++
sources |2 +-
3 files changed, 9 insertions(+), 5 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 720b01c..b080b3b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
/Test-Reporter-1.58.tar.gz
/Test-Reporter-1.59.tar.gz
+/Test-Reporter-1.60.tar.gz
diff --git a/perl-Test-Reporter.spec b/perl-Test-Reporter.spec
index ba2262e..b8d2d2f 100644
--- a/perl-Test-Reporter.spec
+++ b/perl-Test-Reporter.spec
@@ -1,6 +1,6 @@
Name: perl-Test-Reporter
-Version:1.59
-Release:3%{?dist}
+Version:1.60
+Release:1%{?dist}
Summary:Sends test results to cpan-test...@perl.org
License:GPL+ or Artistic
Group: Development/Libraries
@@ -8,7 +8,7 @@ URL:http://search.cpan.org/dist/Test-Reporter/
Source0:
http://www.cpan.org/authors/id/D/DA/DAGOLDEN/Test-Reporter-%{version}.tar.gz
BuildArch: noarch
BuildRequires: perl
-BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(ExtUtils::MakeMaker) = 6.17
BuildRequires: perl(strict)
BuildRequires: perl(warnings)
# Run-time:
@@ -57,11 +57,14 @@ find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {}
\;
make test
%files
-%doc Changes CONTRIBUTING COPYING LICENSE README
+%doc Changes CONTRIBUTING LICENSE README
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
+* Tue Nov 05 2013 Petr Pisar ppi...@redhat.com - 1.60-1
+- 1.60 bump
+
* Sun Aug 04 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.59-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
diff --git a/sources b/sources
index 5e98247..731484d 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-7b81be1fa634a8312775e1428b0adee5 Test-Reporter-1.59.tar.gz
+e36fc3c25a71b2ceba2ae21c6a2e02fc Test-Reporter-1.60.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1026716] perl-Test-Reporter-1.60 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1026716 --- Comment #1 from Petr Pisar ppi...@redhat.com --- This is a bug-fixing release suitable for all Fedoras. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=gZL7bTRoGra=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Test-Announce] Fedora 20 Beta Release Candidate 3 (RC3) Available Now!
NOTE: The 64-bit Desktop Live, and the 32- and 64-bit Security Spins are over their respective size targets. As per the Fedora 20 schedule [1], Fedora 20 Beta Release Candidate 3 (RC3) is now available for testing. Content information, including changes, can be found at https://fedorahosted.org/rel-eng/ticket/5787#comment:24 . Please see the following pages for download links (including delta ISOs) and testing instructions. Normally dl.fedoraproject.org should provide the fastest download, but download-ib01.fedoraproject.org is available as a mirror (with an approximately 1 hour lag) in case of trouble. To use it, just replace dl with download-ib01 in the download URL. Installation: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test Base: https://fedoraproject.org/wiki/Test_Results:Current_Base_Test Desktop: https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test Ideally, all Alpha and Beta priority test cases for Installation [2], Base [3], and Desktop [4] should pass in order to meet the Beta Release Criteria [5]. Help is available on #fedora-qa on irc.freenode.net [6], or on the test list [7]. Create Fedora 20 Beta test compose (TC) and release candidate (RC) https://fedorahosted.org/rel-eng/ticket/5787 Current Blocker and Freeze Exception bugs: http://qa.fedoraproject.org/blockerbugs/current [1] http://fedorapeople.org/groups/schedule/f-20/f-20-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Installation_validation_testing [3] https://fedoraproject.org/wiki/QA:Base_validation_testing [4] https://fedoraproject.org/wiki/QA:Desktop_validation_testing [5] https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria [6] irc://irc.freenode.net/fedora-qa [7] https://admin.fedoraproject.org/mailman/listinfo/test signature.asc Description: OpenPGP digital signature ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora 20-Beta RC3 AMIS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi all, Beta RC2 images have been uploaded to EC2 and are available at ami-afcc94c6 : us-east-1 image for i386 ami-a5cd95cc : us-east-1 image for x86_64 additionally if your looking to the AMI's they have been added to files in the release tree http://dl.fedoraproject.org/pub/alt/stage/20-Beta-RC3/Images/i386/Fedora-Images-i386-20-Beta-AMI http://dl.fedoraproject.org/pub/alt/stage/20-Beta-RC3/Images/x86_64/Fedora-Images-x86_64-20-Beta-AMI when we get to final Beta and the images are uploaded to all regions they will all be listed and the file will be gpg signed in the final tree Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJSePznAAoJEH7ltONmPFDRZUMP/0OKQWw6gAUfoZF9Npxr/cUv bpy72rO8diw6gnP75DREvNpIBv+0Ud3EjSqgz58ZLRt8EVRBufNFAVHa4yqgaPUj IKkNcm6+INOY5xEDDblxzTduvJaeW5hv0y8cAirIgN63Yz3TEfFa1PV05bdb7Gnx NJ0qdaSRkDnXJ6RwIe0CIH7VSlUsw2atBVBw3vZPeXZ/RJALyDDBwJXxlrvgoM5h zuk4x8c960FHGplSd3h2bvYo9+weapcA10Jc+78j8qQoHzTLPtg6G18Yoqs/EFq8 TDR/zdogw2bFQfgsaBPEVpfAs0tnrUo0bHrp8ojQTXpKXOlZmvzVk23x903v9LsT SsgnpvoCs4u/n0dMKzF10uw7MgpZBY9BIPTumnKg+/+iCqhcjKzJy1uOnFVeG8UT DeyuI2NFZ18NM+iXqMPmMEWawiNys2p9JY3L5TiGEK5iJXuOaX5BXcXGhX1BOrai t0YtlKRa3afYogMgzJmb2/ZLiV8fuvt40VbJ3Io+wJUHougMhGYMjivJd7dfmd7c KHnlst54J00rnm9Ul47VvrYQg2HuFQEyuJA/uDy9qYMBInqGIQlfyGM7yM4lMt8V pPZ6gMi0EbTbnRh1t0mf4J2TdzuPj7wODk1zZ1PzY54mIlCNr76bQ8a9aukz0dzJ M6uLJmRzUTom0Az+r3Pa =6Hha -END PGP 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: Source file audit - 2013-09-30
Kevin Fenzi wrote: monnerat:BADURL:openca-ocspd-1.5.1-rc1.tar.gz:ocspd The URL is not available anymore. I've just packaged 1.9.0 for rawhide/f20/f19/f18. It is not the latest version, but it's the latest that doesn't use libpki. I've submitted a review request for this library, but nobody was interested in reviewing (https://bugzilla.redhat.com/show_bug.cgi?id=723575). When I discovered that this library was flawn with a lot of memory leakage bugs, I retired the request. Source for version 1.9.0 is still downloadable. monnerat:BADURL:Synchro-PHPMailer-4d9434e-5.2.6.tar.gz:php-PHPMailer Works for me. Regards, Patrick -- 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: Packaging Python 3.4.0
On Tue, Nov 05, 2013 at 07:29:35AM -0500, Bohuslav Kabrda wrote: Hi all, I started working on updating python3 to 3.4.0. So far, this is only in a private branch python3.4 in dist-git, since I'll need to get a Change approved for Fedora 21. I already created the Change [1], but I was told that it will get on FESCo schedule when Fedora 21 schedule and future is more clear, so for now I'll just work on Python 3.4.0. Hmmm Putting on a fesco hat, I would be more than willing to approve changes for F21 now We've already approved Python3 as Default which has both F21 and F22 goals. I think that the F21 Schedule and Product desciptions are somewhat orthogonal to some features including this. The things I'm looking at that imply that are: * Something that either is non-specific to one of our products * Something that is an upgrade of packages already in Fedora So in my view -- submit the Change! :-) When Python 3.4.0 reaches beta1 (which means feature freeze, which also means that the bytecode format should no longer change) - November 24 [2] - I plan to create a repo in Copr so that everyone has access to built RPMs, and also I want to start rebuilding as many packages as possible to see how they work with Python 3.4. nod The rebuilding make me want to get this into the main repos early. As for the current state of Python 3.4 in the dist-git branch: - It still seems a bit unclear what upstream will do with the sha3 implementation (although they will probably keep it), so I didn't rebase the fips patch yet, there is still plenty of time for that. I think Christian outlined what they are going to do with sha3 yesterday (but yeah, it depends on what is happening with the sha3 standard so there's a bit of uncertainty there still). - pep453 [3] (pip bootstraping) hasn't been implemented yet. The pep also contains recommendation for distro packagers, so here's what we should do. -- Make a circular dependency between python3 and python3-pip (ugly, will require bootstraping with every new Python minor version). Do you mean minor version as in the 4 in 3.4 or as in the micro level (0 in 3.4.0)? We can get around bootstrapping at minor version revs if pip is only used at runtime, not at buildtime. We can still get around bootstrapping at micro version if we are careful never to include pip's code in the package. Only figure out where to find pip's code. -- Definitely delete bundled CA certificates and use system certificates instead. +1 -- Maybe remove the bundled pip (although this goes against the pep) and use python3-pip. E.g. everything would work as expected, but under the wraps, python3-pip package would be used. So when doing security updates, we'd just fix python3-pip. It is however true that if Fedora's pip would be different from the upstream bundled one, users may experience some behaviour differencies. I'd like to hear your opinions on how we should approach this. We should definitely do this. pip itself bundles code that we've had to unbundle locally -- maintaining that morass of software again (it's also bundled inside of virtualenv...) is going to lead to a lot of work anytime an update needs to happen. However, talking with ncoghlan it may not be simple. The case that makes things tricky is pyvenv. Upstream python wants to protect venv's from changes to code on the system. ie: if a user installs a backwards incompatible pip on the system, that should not affect the pip inside the existing venvs. Equally, if there are security issues found with pip, those changes would not be propogated to the pip inside the venvs. ncoghlan proposed that we create wheels in the pip package (and all the packages that pip bundles that we have to unbundle) and then when ensurepip installs into a venv, it copies those wheels in there. I'm wondering if we could do a little better. Instead of keeping around two copies of all this software on the system, if we can reconstruct a wheel zip (or possibly just copy the files in) from the wheel metadata and files on the system. I know that sysadmins and developers will hotfix software on the system for issues that they care about. Having those changes propogate to newly installed venvs seems like a better plan than having the venvs get the old copies that were built at rpm build time. -Toshio pgpQBZ2fP8GGy.pgp Description: PGP signature ___ python-devel mailing list python-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: Draft Workstation WG Governance Charter
On Mon, Nov 4, 2013 at 6:57 PM, Owen Taylor otay...@redhat.com wrote: On Wed, 2013-10-30 at 15:22 -0400, Josh Boyer wrote: On Wed, Oct 30, 2013 at 3:16 PM, Ray Strode halfl...@gmail.com wrote: Hi, On Wed, Oct 30, 2013 at 9:01 AM, Josh Boyer jwbo...@fedoraproject.org wrote: The other positions will be filled by general election every two years. As a special exception, four seats will be filled in one year, with those positions chosen at random (unless some number of members decide to step down). Voting will follow the standard Fedora election process and be open to all contributors in the CLA+1 group. In the event that a current member relinquishes their seat, that seat will be filled by the first runner up in the previous election. If that person is not able or willing to fill the seat, it will go to each successive runner up until the seat is filled. I think, I personally, would rather see the previous working group decide new members of the working group. They're the ones doing the work, so they should get the most say in the direction the work goes. (the whole fedora is a meritocracy not a democracy thing). Put another way: I don't think someone who works on desktop related software should have much say in who gets to be put in the cloud working group, or vice-versa. Let the people already doing the work decide the continuing direction of the work. If things really get off course, fesco can intervene, but I don't think that will happen. Fair. To be honest, the more I think about it the more I dislike the idea of doing full blown elections. They seem overkill and cumbersome when it comes to coordinating, etc. I strongly support this view - the end result of having too many elections is that only a tiny fraction of people have the attention to understand what is going on and vote. Repeating myself from the server list: I don't think long serving terms, and especially indefinite serving terms, are healthy: there should be an easy way for the community to self-correct without requiring extraordinary effort like finding a thick-skinned opposition leader to set up a recall election or the like. AFAICT unlike (Czech and US at least) national governments, the Fedora elections have always had very low overhead and basically no campaign / pre-election posturing seasons disruptive to the project; there hasn't been much election-related burden to speak of. It also seems problematical to have a elected working group that falls under the supervision of FESCO which is also elected. What if FESCO and the group disagree? This can just as well happen with a non-elected group. Mirek -- 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: Draft Workstation WG Governance Charter
On Tue, Nov 5, 2013 at 9:51 AM, Miloslav Trmač m...@volny.cz wrote: On Mon, Nov 4, 2013 at 6:57 PM, Owen Taylor otay...@redhat.com wrote: On Wed, 2013-10-30 at 15:22 -0400, Josh Boyer wrote: On Wed, Oct 30, 2013 at 3:16 PM, Ray Strode halfl...@gmail.com wrote: Hi, On Wed, Oct 30, 2013 at 9:01 AM, Josh Boyer jwbo...@fedoraproject.org wrote: The other positions will be filled by general election every two years. As a special exception, four seats will be filled in one year, with those positions chosen at random (unless some number of members decide to step down). Voting will follow the standard Fedora election process and be open to all contributors in the CLA+1 group. In the event that a current member relinquishes their seat, that seat will be filled by the first runner up in the previous election. If that person is not able or willing to fill the seat, it will go to each successive runner up until the seat is filled. I think, I personally, would rather see the previous working group decide new members of the working group. They're the ones doing the work, so they should get the most say in the direction the work goes. (the whole fedora is a meritocracy not a democracy thing). Put another way: I don't think someone who works on desktop related software should have much say in who gets to be put in the cloud working group, or vice-versa. Let the people already doing the work decide the continuing direction of the work. If things really get off course, fesco can intervene, but I don't think that will happen. Fair. To be honest, the more I think about it the more I dislike the idea of doing full blown elections. They seem overkill and cumbersome when it comes to coordinating, etc. I strongly support this view - the end result of having too many elections is that only a tiny fraction of people have the attention to understand what is going on and vote. Repeating myself from the server list: I don't think long serving terms, and especially indefinite serving terms, are healthy: there should be an easy way for the community to self-correct without requiring extraordinary effort like finding a thick-skinned opposition leader to set up a recall election or the like. Isn't that something that's addressed by FESCo oversight here? AFAICT unlike (Czech and US at least) national governments, the Fedora elections have always had very low overhead and basically no campaign / pre-election posturing seasons disruptive to the project; there hasn't been much election-related burden to speak of. It's not necessarily about burden, though I think there is some burden here. It's mostly about the voting body either having no idea who to pick because they aren't participating in this area, or being entirely indifferent and not voting for the same reasons. Coordinating a full election for the WG seems overkill. It also seems problematical to have a elected working group that falls under the supervision of FESCO which is also elected. What if FESCO and the group disagree? This can just as well happen with a non-elected group. Yes. I don't think the WG can change this itself anyway. The WGs are under the supervision (used very loosely here) of FESCo. josh -- 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: Draft Product Description for Fedora Workstation
The term 'Power user' is not meaningless if you use it to refer to users of Fedora on IBM Power architecture ;) But apart from that I do agree that the term as generally used doesn't provide a very clear target for development. Christian - Original Message - From: drago01 drag...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Tuesday, November 5, 2013 6:53:15 AM Subject: Re: Draft Product Description for Fedora Workstation On Tue, Nov 5, 2013 at 12:35 PM, Nicolas Mailhot nicolas.mail...@laposte.net wrote: Le Lun 4 novembre 2013 23:02, Nicolas Mailhot a écrit : The problem is not to get code in the hands of developers. You don't need distros for that. The problem is to get the code to end-users and developers spend more time fighting the constrains it involves than trying to understand this problem-space. Of course the aim might not be to reach end users but to push code from developpers to other developers. And if that is the case, there is a huge disconnect between GNOME goals and Fedora Workstation goals. GNOME speakers repeat all year round their software is not aimed at power users, but developers are the über power user. Depends on what you mean by power user (I hate this meaningless term) if it means software developer then yes. If it means someone that spends his whole day in config dialogs then no. -- 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
[perl-Module-Build] 0.4008 bump
commit 7842d063cfab19f636149dbe69bf86ca062ce41a
Author: Jitka Plesnikova jples...@redhat.com
Date: Tue Nov 5 16:37:13 2013 +0100
0.4008 bump
.gitignore |1 +
perl-Module-Build.spec |7 +--
sources|2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 24abc28..b88c003 100644
--- a/.gitignore
+++ b/.gitignore
@@ -9,3 +9,4 @@ Module-Build-0.2808.tar.gz
/Module-Build-0.4004.tar.gz
/Module-Build-0.4005.tar.gz
/Module-Build-0.4007.tar.gz
+/Module-Build-0.4008.tar.gz
diff --git a/perl-Module-Build.spec b/perl-Module-Build.spec
index 5f235c8..2830fae 100644
--- a/perl-Module-Build.spec
+++ b/perl-Module-Build.spec
@@ -1,11 +1,11 @@
%global cpan_version_major 0.40
-%global cpan_version_minor 07
+%global cpan_version_minor 08
%global cpan_version %{cpan_version_major}%{?cpan_version_minor}
Name: perl-Module-Build
Epoch: 2
Version:
%{cpan_version_major}%{?cpan_version_minor:.%cpan_version_minor}
-Release:3%{?dist}
+Release:1%{?dist}
Summary:Build and install Perl modules
License:GPL+ or Artistic
Group: Development/Libraries
@@ -123,6 +123,9 @@ LANG=C TEST_SIGNATURE=1 MB_TEST_EXPERIMENTAL=1 ./Build test
%{_mandir}/man3/*
%changelog
+* Tue Nov 05 2013 Jitka Plesnikova jples...@redhat.com - 2:0.40.08-1
+- 0.4008 bump
+
* Wed Aug 14 2013 Jitka Plesnikova jples...@redhat.com - 2:0.40.07-3
- Perl 5.18 re-rebuild of bootstrapped packages
diff --git a/sources b/sources
index 957405c..e07fd09 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-d589909669f3c3e8ace554f00eb815a1 Module-Build-0.4007.tar.gz
+01675c01f6a42c528d02dc34cc5383bf Module-Build-0.4008.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-Simple/f20] Update to 1.001002
Summary of changes: dd82ca2... Update to 1.001002 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-Simple] Created tag perl-Test-Simple-1.001002-1.fc20
The lightweight tag 'perl-Test-Simple-1.001002-1.fc20' was created pointing to: dd82ca2... Update to 1.001002 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-Simple] Created tag perl-Test-Simple-1.001002-1.fc21
The lightweight tag 'perl-Test-Simple-1.001002-1.fc21' was created pointing to: dd82ca2... Update to 1.001002 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Draft Product Description for Fedora Workstation
Hi Ryan, I been discussing the possibilities of doing some surveys with Langdon White, so hopefully yes. We just need to rustle up the budget first :) Christian - Original Message - From: Ryan Lerch rle...@redhat.com To: Discussions about development for the Fedora desktop desk...@lists.fedoraproject.org, devel@lists.fedoraproject.org Sent: Monday, November 4, 2013 11:14:21 AM Subject: Re: Draft Product Description for Fedora Workstation On 01/11/13 10:24, Christian Fredrik Kalager Schaller wrote: Hi everyone, Attached is the draft PRD for the Workstation working group. The proposal tries to be relatively high level and focus on goals and principles, but I have included some concrete examples at times to try to provide some clarity on how the goals and principles could play out in practice. I hope the community at large will take the time to read through it and provide feedback so that when the working group meet next we can use that feedback to start tuning in on the final form of the PRD. Also in the name of openness, before I sent this here, I showed the PRD draft to key stakeholders and decision makers inside Red Hat, to ensure that we have the necessary support for these plans to get the kind of engineering resources allocated from Red Hat we will need to pull this off. Sincerely, Christian F.K. Schaller P.S. I am celebrating both our wedding anniversary and my wifes birthday this weekend so I will not be able to be online a lot. That said I will make the time to go online to check my email from time to time so that I can respond to any questions that has come in, just don't expect immediate answers from me this weekend :) Although i am not sure if the PRD is the place for it, But should we also think about conducting some user surveys to help define our target audience further? Also, some User testing on what we have already would also be useful for a baseline to check against in the future when we start implementing changes. cheers, ryanlerch -- 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: gtk3 broken/missing icons on kde
On Tue, 2013-11-05 at 08:23 +0100, drago01 wrote: On Tue, Nov 5, 2013 at 3:03 AM, Adam Williamson awill...@redhat.com wrote: On Sun, 2013-10-27 at 01:46 +0200, Kevin Kofler wrote: Adam Williamson wrote: I don't think we'd really be correct in blocking the release for such issues - especially not Beta. We used to have 'polish' criteria for Final which at least required the icons used in the system menus - i.e. what's specified in the app's .desktop file - to be sane for all installed applications, but we dropped that (and other polish criteria) with the F19/F20 criteria re-write on the basis that they were really stretching a bit too far and would be unlikely to hold up to a 'last blocker before release' acid test. Stuff like this doesn't break anyone's use of the system catastrophically and can reasonably be fixed with updates. But it also affects the live images (making them look very unpolished) and we don't respin those. That's why I said 'reasonably' not 'perfectly' :) I can see an argument for blocking Final, though in practice, I don't think our current standards are such that it really makes sense to claim our final releases are so smooth as to be worth enforcing a high standard of polish via the blocker mechanisms Then we should that. There is a difference between perfect and something that looks obviously broken. Are we really fighting about the classification of fixed bugs here, or is there a new issue that I am not aware of ? -- 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: Draft Product Description for Fedora Workstation
On Sat, Nov 2, 2013 at 5:20 PM, Kevin Kofler kevin.kof...@chello.at wrote: I think it is a very bad idea to try to explicitly and officially support third-party software, especially proprietary third-party software. The thing is, making third-party software easier to maintain and deploy will in the vast majority of causes also make in-distribution software easier to maintain and deploy. And being actively hostile to third-party software, feeling free to break APIs and ABIs because Open Source can in theory adapt, and, in the extreme, celebrating actions that are hostile to third-party software, often ends up to also being hostile to in-distribution software with limited number of interested contributors. Look at all the software that has been written for GTK1 and obsolete libraries that hasn't been ported and therefore no longer runs on Fedora. Wouldn't it have been nice to continue to have a practical option to use that software, even if it doesn't integrate that well and it no longer has an active maintainer? Mirek -- 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: gtk3 broken/missing icons on kde
On Tuesday, November 5, 2013, Matthias Clasen wrote: On Tue, 2013-11-05 at 08:23 +0100, drago01 wrote: On Tue, Nov 5, 2013 at 3:03 AM, Adam Williamson awill...@redhat.comjavascript:; wrote: On Sun, 2013-10-27 at 01:46 +0200, Kevin Kofler wrote: Adam Williamson wrote: I don't think we'd really be correct in blocking the release for such issues - especially not Beta. We used to have 'polish' criteria for Final which at least required the icons used in the system menus - i.e. what's specified in the app's .desktop file - to be sane for all installed applications, but we dropped that (and other polish criteria) with the F19/F20 criteria re-write on the basis that they were really stretching a bit too far and would be unlikely to hold up to a 'last blocker before release' acid test. Stuff like this doesn't break anyone's use of the system catastrophically and can reasonably be fixed with updates. But it also affects the live images (making them look very unpolished) and we don't respin those. That's why I said 'reasonably' not 'perfectly' :) I can see an argument for blocking Final, though in practice, I don't think our current standards are such that it really makes sense to claim our final releases are so smooth as to be worth enforcing a high standard of polish via the blocker mechanisms Then we should that. There is a difference between perfect and something that looks obviously broken. Are we really fighting about the classification of fixed bugs here, Yes ;) -- 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: Draft Product Description for Fedora Workstation
Am 05.11.2013 17:22, schrieb Miloslav Trmač: Look at all the software that has been written for GTK1 and obsolete libraries that hasn't been ported and therefore no longer runs on Fedora. Wouldn't it have been nice to continue to have a practical option to use that software, even if it doesn't integrate that well and it no longer has an active maintainer? no because exactly that is terrible from security point of view this means unmaintained code careless in the distribution you can be pretty sure that in the case bad tings happening later Fedora as distribution and Linux at all will be made responsible for such bad behavior look they have the same troubles and no longer more secure than OSX and Windows 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
[Test-Announce] Printing Test Day today (Tuesday 2013-11-05)
The Printing Test Day for Fedora 20 is today. https://fedoraproject.org/wiki/Test_Day:2013-11-05_Printing This test day is for testing all aspects of printing, including setting up the printer, sharing printers on the network, and printing jobs. The changes in Fedora 20 are relatively minor: switching to CUPS 1.7 and Ghostscript 9.10, and some improvements to cups-filters and the Printers part of GNOME Settings. Remember that CUPS unit testing is only one small part of the story: printing is very much in need of integration testing. Try printing with different applications, using options you don't normally use in the print dialog. Try to see how many different ways you can break it! If you have access to a printer and a machine running Fedora 20 (a live CD is fine), please join in! We'll be on IRC at the usual place: irc://irc.freenode.net/fedora-test-day Tim. */ ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Discontinued Packing of NetBeans IDE
Is it correct that the NetBeans IDE is currently not packed for Fedora? I checked the netbeans package, which was last built for fc17. Is there any technical or license reason for this or is just nobody packing it right now? --ManuelFaux -- 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: Discontinued Packing of NetBeans IDE
Hi On Tue, Nov 5, 2013 at 11:45 AM, Manuel Faux wrote: Is it correct that the NetBeans IDE is currently not packed for Fedora? I checked the netbeans package, which was last built for fc17. Is there any technical or license reason for this or is just nobody packing it right now? Someone from Sun used to be the maintainer and noone is doing it right now. No technical or licensing issues if anyone is interested in packaging it afaik. 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: Draft Product Description for Fedora Workstation
On Tue, 2013-11-05 at 12:35 +0100, Nicolas Mailhot wrote: Le Lun 4 novembre 2013 23:02, Nicolas Mailhot a écrit : The problem is not to get code in the hands of developers. You don't need distros for that. The problem is to get the code to end-users and developers spend more time fighting the constrains it involves than trying to understand this problem-space. Of course the aim might not be to reach end users but to push code from developpers to other developers. And if that is the case, there is a huge disconnect between GNOME goals and Fedora Workstation goals. GNOME speakers repeat all year round their software is not aimed at power users, but developers are the über power user. Why do you think the two sets of goals have to be one and the same ? The Fedora Workstation effort (not a great name, by the way), is brand new, and its goals have only just been drafted. How could the goals that GNOME has followed in the past 3 years be perfectly align with it ? And why should they, for that matter ? This is not a GNOME project, it is about saving Fedora. -- 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: Discontinued Packing of NetBeans IDE
On 11/05/2013 09:46 AM, Rahul Sundaram wrote: Someone from Sun used to be the maintainer and noone is doing it right now. No technical or licensing issues if anyone is interested in packaging it afaik. I've been loving using netbeans however I've been using the upstream package.. I looked into the original package but the spec file is so complicated and I have no idea how java programs are packagaed so shied away. If someone else thinks collectively we could bring it back up to a recent version. I'd be delighted to co-maintain it. -- Nathanael d. Noblet t 403.875.4613 -- 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: Discontinued Packing of NetBeans IDE
Quoting Rahul Sundaram (2013-11-05 17:46:55) Hi On Tue, Nov 5, 2013 at 11:45 AM, Manuel Faux wrote: Is it correct that the NetBeans IDE is currently not packed for Fedora? I checked the netbeans package, which was last built for fc17. Is there any technical or license reason for this or is just nobody packing it right now? Someone from Sun used to be the maintainer and noone is doing it right now. No technical or licensing issues if anyone is interested in packaging it afaik. More specifically look at: https://lists.fedoraproject.org/pipermail/java-devel/2010-November/003980.html Reason nobody picked it up is that is has relatively big dependency chain and there was nobody interested enough (from maintainer perspective). Most Java packages are in Fedora because they are dependencies of following packages: * Tomcat * Maven * Eclipse * WildFly * (new) Big Data SIG stuff * and of course a few more apps here and there -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.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: ntp-4.2.6p5-11.fc19.src.rpm does not rpmbuild...
On Fri 18 Oct 2013 17:59:31 Miroslav Lichvar wrote: On Fri, Oct 18, 2013 at 02:14:40PM +0100, Barry Scott wrote: On Thu 17 Oct 2013 17:56:57 Barry Scott wrote: I need to patch ntp for my uses. But I find that the src rpm will not build on F19. cd . env PATH=/home/bscott/rpmbuild/BUILD/ntp-4.2.6p5/ntpd:/home/bscott/bin:/usr /loc al/bin:/bin:/usr/bin:/usr/local/sbin:/sbin:/usr/sbin autogen -L ../include --writable -Tagman1.tpl -bntpd ntpd-opts.def ice-9/psyntax.scm:1259:12: In procedure dobody: ice-9/psyntax.scm:1259:12: Syntax error: That looks like https://bugzilla.redhat.com/show_bug.cgi?id=958908. It's fixed in autogen-5.18-1.fc20. The F19 ntp spec includes a workaround touch ntpd/ntpd.1 util/ntp-keygen.1, which prevents autogen from rebuilding the man pages. If you are patching other autogen files in the ntp code, you'll need to update the autogen package or similarly touch the other man pages. Thanks for the info. I found the touch commands in the first F20 ntp SRPM and that got the rpmbuild working. Barry -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Meeting minutes from today's Env-and-Stacks WG meeting (2013-11-05)
#fedora-meeting: Env and Stacks (2013-11-05) Meeting started by mmaslano at 16:02:38 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2013-11-05/environment_and_stacks.2013-11-05-16.02.log.html . Meeting summary --- * init process (mmaslano, 16:05:34) * communication channels (mmaslano, 16:06:15) * mailing list was set env-and-sta...@lists.fedoraproject.org (mmaslano, 16:12:19) * no new irc channel because of many time zones most of the communication will be happening on mailing list (mmaslano, 16:13:00) * Meeting frequency and times (mmaslano, 16:15:26) * LINK: http://whenisgood.net/fedenvstk/results/q3gmp7 (abadger1999, 16:24:49) * odd and even weeks will have different time for meetings because of time zones (mmaslano, 16:30:02) * AGREED: 16:00 UTC for week starting 19th November (mmaslano, 16:31:00) * everyone will look at whenisgood and will try to pick second date. The preferred time by juhp_ and bkabrda should be acceptable for most of the group (mmaslano, 16:33:58) * trac (mmaslano, 16:34:06) * handsome_pirate will create wiki for our WG (mmaslano, 16:41:28) * Discussions around the WG governance charter (mmaslano, 16:42:01) * LINK: https://fedoraproject.org/wiki/Cloud/Governance is Cloud's (handsome_pirate, 16:45:14) * abadger1999 will put together a governance draft (mmaslano, 17:05:57) * LINK: https://lists.fedoraproject.org/pipermail/desktop/2013-October/008245.html (juhp_, 17:11:49) * rest of the discussion will happen on mailing list. abadger1999 will write up the charter as soon as we will know what do we want to do (mmaslano, 17:32:28) * Open Floor (mmaslano, 17:34:59) Meeting ended at 17:37:58 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * handsome_pirate (85) * mmaslano (83) * abadger1999 (70) * tjanez (46) * juhp_ (41) * drieden (18) * samkottler (15) * hhorak (15) * pkovar (10) * zodbot (4) * nirik (2) * masta (1) * pknirsch (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot 16:02:38 mmaslano #startmeeting Env and Stacks (2013-11-05) 16:02:38 zodbot Meeting started Tue Nov 5 16:02:38 2013 UTC. The chair is mmaslano. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:02:38 zodbot Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:02:42 * samkottler is here 16:02:47 handsome_pirate Yay 16:02:50 mmaslano #meetingname Environment and Stacks 16:02:50 zodbot The meeting name has been set to 'environment_and_stacks' 16:02:56 * handsome_pirate waves from the crows nest 16:03:01 tjanez Hi 16:03:04 juhp_ hi 16:03:06 * pkovar is here 16:03:13 * mmaslano just arrived 16:03:29 mmaslano hhorak: is here, hi 16:03:31 * abadger1999 here 16:03:41 drieden Hi 16:03:57 * hhorak is greeting 16:04:23 * handsome_pirate will be right back 16:04:46 mmaslano Jens is not here 16:04:57 juhp_ I am Jens :) 16:05:05 mmaslano great :) hi 16:05:25 mmaslano I'll do table of members for next week... 16:05:34 mmaslano #topic init process 16:06:10 mmaslano so let's discuss what other groups already discussed 16:06:15 mmaslano #topic communication channels 16:06:28 mmaslano We have mailing list 16:06:51 samkottler do we want to setup a new IRC channel? 16:07:42 tjanez Regarding the mailing list, I just updated its description a couple of hours ago 16:08:00 drieden I think an IRC channel for env and stacks would be helpful 16:08:05 tjanez Open to suggestions/improvements, though 16:09:16 tjanez I don't feel we need a new IRC channel (yet) 16:09:35 samkottler why not? 16:09:45 samkottler what's the disadvantage of having it? 16:10:07 tjanez samkottler: Just though mailing-list is where discussion should take place 16:10:36 tjanez samkottler: And there are plenty of existing IRC channels 16:10:40 abadger1999 better than a new irc channel would just being able to find everyone on irc but given the difficulty setting up a common meeting time, that's probably a wishlist item ;-) 16:10:41 mmaslano discussion with friends about a problem is fine, but discussion about future of something is different thing 16:10:50 mmaslano abadger1999: yeah 16:11:06 juhp_ abadger1999, hehe :) 16:11:25 mmaslano do you want to vote about every topic or we just agreed on something? 16:11:37 juhp_ well I don't mind but also feel that irc channel is not so urgent 16:11:46 samkottler I think we can use general concensus in this case 16:11:55 samkottler most people don't want a new channel :-) 16:12:13 hhorak I'd also prefer discussions of mailing list, it's more transparent for everyone.. we can set irc channel later.. 16:12:16 tjanez I'm fine with both, voting and consensus 16:12:19 mmaslano #info mailing list
[389-devel] Please review (take #2) ticket 47575: add test case for ticket47560
Hi All, This review is new proposal to implement CI test cases inside 389-DS. The layout of the tests will be: head/dirsrvtests/ tickets/ ticket_abc_test.py ticket_xyz_test.py ... finalizer testsuites/ acl_test.py replication_test.py ... Each ticket_xyz_test.py will contain framework functions that will allocate a fresh installed instance then the test functions: framework functions are _ds_create_standalone, DSInstance class and ds_instance pytest fixture. tests functions are named 'test_ticket_xyz' with 'ds_instance' fixture as argument. py.test will call the test functions 'test_ticket_xyz'. Its argument is an instance (ds_instance) of DSInstance where ds_instance.instance is a connection to the instance. The first instance of DSInstance (first ticket being tested), get a newly created instance (e.g. slapd-standalone) and creates a backup of the instance (under /tmp/slapd-standalone.bck/backup_HHMMSS.tar.gz). Then when running others ticket test cases, the instance is reinitialized from the backup. So each ticket test case will have an instance almost like it was just created. py.test will discover all the ticket_xxx_test.py files and run them. In order to remove the created instances, py.test is called a second time to run finalizer.py. So a jenkins job script, will do something like: cd head/dirsrvtests/tickets py.test -v # that will run all the ticket_xxx_tests and create the instance py.test -v finalizer.py Note: in order to check/backup/restore instance, new functions are added in lib389 ( checkInstanceBackupFS, instanceBackupFS, instanceRestoreFS), I will send an other review for them as it is not in 389-DS repos. https://fedorahosted.org/389/attachment/ticket/47575/0002-Ticket-47575-CI-test-add-test-case-for-ticket47560.patch -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Review Request: prboom-plus - Free enhanced DOOM engine
Hello everyone. I'm searching for volunteers willing to review the prboom-plus engine: https://bugzilla.redhat.com/show_bug.cgi?id=1026517 Anybody want to help with that? Thanks in advance. Regards, Jaromir. -- Jaromir Capik Red Hat Czech, s.r.o. Software Engineer / Secondary Arch Email: jca...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkynova 99/71, 612 45, Brno, Czech Republic IC: 27690016 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Call for ideas] Defining the scope of the Environments and stacks WG
Hi! I would like to invite all of you who are interested in helping defining the scope (i.e. what we will do document) of the Environments and stacks WG to join the discussion [0] at our new env-and-stacks mailing list [1]. If you have an idea/expectation/suggestion, please write it up. We especially encourage members of other WGs to express their expectations with respect to our WG, so we can align them better. Best regards, Tadej [0] https://lists.fedoraproject.org/pipermail/env-and-stacks/2013-November/18.html [1] https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks -- 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: Draft Product Description for Fedora Workstation
On Mon, Nov 04, 2013 at 09:21:15AM -0500, Ray Strode wrote: I think this is a pretty good starting point for our development direction, and sets the stage for us making positive progress in the new working group model. I do think we should keep it open to tweaks in the future as things play out, (at the discretion of the 9 members on the working group). In other words, I think it lays a solid outline for enabling us all to know which direction to go, but i want to make sure if it doesn't ever get in the way. The working group should treat it as a living document that gets updated as necessary to reflect changes in the landscape. Agreed, it's a good start. One question... Case 2: Independent Developer Personal development system for an independent software developer doing contract work or developing apps for a new opportunity. Desktop Apps: Up to date desktop with email client, browser, productivity suite, messaging, and complete set of desktop apps and utilities. Desktop apps should be sufficient to make this system the developer's only computer. s/and complete/and a complete/ s/make this/make this/ [... snip other use cases that sound good ...] Other users While the developer workstation is the main target of this system and what we try to design this for, we do of course also welcome other users to the Fedora Workstation. In fact many of the changes and improvements we expect to implement for developers will be equally beneficial to other user segments, I think this is a really important point. Developers are users, too, just trying to get their work done. We should make sure the OS doesn't get in the way, and that it doesn't enforce artificial barriers to entry. Just because a user may know how the sausage is made, doesn't mean we should make them stuff their own (so to speak). And if a user/developer doesn't know the inner workings of Fedora, that's okay, too. We should be enabling the user to get the things done he/she cares about, not forcing them to learn the things we care about. There should be no You must be this tall to ride Fedora Workstation signs. [...snip...] Is it the intent that the developer cases here completely subsume the case of a developer who is working primarily on Fedora itself (including the Worsktation)? Perhaps we should call that out to correctly prioritize integration of the various developer tools currently available or planned for the Workstation. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.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
R: Re: Discontinued Packing of NetBeans IDE
hi see https://fedoraproject.org/wiki/Features/NetBeans_7.3 (should be update) problem(s): - latest NB releases use some libraries available in java8 e.g. https://github.com/furosys/nashorn Nashorn for Java 7 https://bitbucket.org/ramonza/nashorn-backport (used by NB) https://bugzilla.redhat.com/show_bug.cgi?id=1005932 - eclipse integration, i/we haven't no intentions to use eclipse libraries (e. g. eclipse jgit) if users was use thesefeatures should/must use eclipse ide - some libraries was updates, and others should be adapted for latest release 7.4 for now porting of NB is stopped regards gil Messaggio originale Da: sochotni...@redhat.com Data: 05/11/2013 18.03 A: Development discussions related to Fedoradevel@lists.fedoraproject.org Ogg: Re: Discontinued Packing of NetBeans IDE Quoting Rahul Sundaram (2013-11-05 17:46:55) Hi On Tue, Nov 5, 2013 at 11:45 AM, Manuel Faux wrote: Is it correct that the NetBeans IDE is currently not packed for Fedora? I checked the netbeans package, which was last built for fc17. Is there any technical or license reason for this or is just nobody packing it right now? Someone from Sun used to be the maintainer and noone is doing it right now. No technical or licensing issues if anyone is interested in packaging it afaik. More specifically look at: https://lists.fedoraproject.org/pipermail/java-devel/2010-November/003980. html Reason nobody picked it up is that is has relatively big dependency chain and there was nobody interested enough (from maintainer perspective). Most Java packages are in Fedora because they are dependencies of following packages: * Tomcat * Maven * Eclipse * WildFly * (new) Big Data SIG stuff * and of course a few more apps here and there -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.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 -- 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: Review Request: prboom-plus - Free enhanced DOOM engine
Il 05/11/2013 18:56, Jaromir Capik ha scritto: Hello everyone. I'm searching for volunteers willing to review the prboom-plus engine: https://bugzilla.redhat.com/show_bug.cgi?id=1026517 Anybody want to help with that? Thanks in advance. Regards, Jaromir. -- Jaromir Capik Red Hat Czech, s.r.o. Software Engineer / Secondary Arch Email: jca...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkynova 99/71, 612 45, Brno, Czech Republic IC: 27690016 hi take... can you take https://bugzilla.redhat.com/show_bug.cgi?id=1005796 ? if you have time thanks regards gil attachment: puntogil.vcf-- 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: Draft Product Description for Fedora Workstation
Hi, - Original Message - We should be enabling the user to get the things done he/she cares about, not forcing them to learn the things we care about. There should be no You must be this tall to ride Fedora Workstation signs. [...snip...] Is it the intent that the developer cases here completely subsume the case of a developer who is working primarily on Fedora itself (including the Worsktation)? Perhaps we should call that out to correctly prioritize integration of the various developer tools currently available or planned for the Workstation. That's a good point, too. My mail is trying to make sure we consider developers who don't work on Fedora, but just use Fedora for development. Paul makes a very reasonable point that we should be clear to accomodate (and not alienate) ourselves (Fedora contributors) as well. So, as a throw-away example..., It might not make sense to have fedpkg in the default install, but having an easily obtainable Fedora SDK of sorts that includes all the bits needed to get up and going might be a good idea. --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
Draft v2 Workstation WG Governance Charter
Hi All, Here's the second draft of the charter. I think I captured most of the discussion to date, but there's always a chance I missed something. Please read this over and provide any feedback you have. Please pay particular attention to the (NOTE:) items. Thanks. josh == Fedora Workstation WG Governance == This document describes the governing structure for the Fedora Workstation Work Group. === Membership === The Fedora Workstation Work Group has nine voting members, with one member selected by the Fedora Engineering Steering Committee as the liaison to FESCo. The FESCo liaison is always a member of the decision making group for the Work Group. The liaison is responsible for presenting the WG decisions and summary of WG discussions to FESCo on a regular basis. They will also take feedback or requirements from FESCo back to the WG. The liaison is not required to be a FESCo member, but should be able to regularly attend the FESCo meetings. Members of the Work Group are chosen by the Work Group as seats become available. In the event that a current member relinquishes their seat, the Work Group will fill the seat by selecting a candidate and approving by majority consensus. Eligible candidates must be in the FPCA+1 group. The Work Group is highly encouraged to seek out candidates that have been showing persistent and high quality contribution to the Workstation product. (NOTE: I believe this is a decent encapsulation of the discussion we've had thus far. I've omitted term limits for now, but I'm open to suggestions. The FPCA+1 requirement seems reasonable to me as we want to make sure they're a Fedora contributor first and foremost. Suggestions/questions welcome.) === Current Members === * Josh Boyer (FESCo Liaison) (jwb) * Matthias Clasen (mclasen) * Kalev Lember (kalev) * Ryan Lerch (ryanlerch) * Jens Petersen (juhp) * Christian Schaller (cschalle) * Owen Taylor (otaylor) * Lukáš Tinkl (ltinkl) * Christoph Wickert (cwickert) === Making Decisions === Because Fedora is a global project, members of the working group may be distributed across multiple timezones. It may be possible to have a real-time IRC meetings, but in general we will conduct business on the mailing list. Many of our decisions can be made through lazy consensus;. Under this model, an intended action is announced on the mailing list, discussed, and in the absence of a group of dissenting contributors within a few days, simply done. For bigger issues, where there may be disagreement, or where there is long-term impact, or where an action may not easily be undone, we will put forth a formal proposal on the mailing list with a [Proposal for Vote] header in the email Subject: field. Working group members can vote +1 to approve, -1 to disagree, or 0 to abstain; five +1 votes are necessary for a measure to pass. Non-members may comment on the item and (of course) discuss on the mailing list, but are asked to refrain from putting votes on official proposal threads. In the event that a live meeting is held in IRC to discuss an issue, proposals will be done in much the same way. A member will put forth an official proposal by prefixing a summary of such with Proposal: and WG members will vote as above. Results will be recorded and posted in any meeting minutes. (NOTE: I chose option #2 from the previous draft for now. If you'd like to see something different, please speak up. I don't believe anyone commented on this section specifically.) === Changing these Rules === This document will be approved by consensus of the initial Working Group members and approved by FESCo. After initial ratification, any substantive changes can be approved by majority vote and sent to FESCo for acceptance. -- 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: Draft Product Description for Fedora Workstation
On Fri, 2013-11-01 at 14:22 -0400, Josh Boyer wrote: - What about watching films, listening to music? I think it is a basic requirement for students (at least for me). Maybe we should add a that a student should be able to play videos and listen to music. It should be easy to install required codes (free/nonfree/patente) if they are available in the repositories (yes, I mean rpmfusion) This would require approval beyond the WG, as it goes against Fedora's policies. Note, I am not saying you are incorrect, just that it's a conversation to be had elsewhere first. Ensuring that it's possible/easy to install plugins from third party repositories when appropriate if those third party repositories are defined is not, I don't believe, against any policies, or we could not have the automatic codec installation mechanisms in Totem and Rhythmbox. (Which, as I read it, is the kind of thing this comment was about). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- 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: Draft Product Description for Fedora Workstation
On Tue, Nov 5, 2013 at 2:58 PM, Adam Williamson awill...@redhat.com wrote: On Fri, 2013-11-01 at 14:22 -0400, Josh Boyer wrote: - What about watching films, listening to music? I think it is a basic requirement for students (at least for me). Maybe we should add a that a student should be able to play videos and listen to music. It should be easy to install required codes (free/nonfree/patente) if they are available in the repositories (yes, I mean rpmfusion) This would require approval beyond the WG, as it goes against Fedora's policies. Note, I am not saying you are incorrect, just that it's a conversation to be had elsewhere first. Ensuring that it's possible/easy to install plugins from third party repositories when appropriate if those third party repositories are defined is not, I don't believe, against any policies, or we could not have the automatic codec installation mechanisms in Totem and Rhythmbox. (Which, as I read it, is the kind of thing this comment was about). The codec search only works if you have repositories configured that have packages that match the Provides (as far as I understand). Fedora policy says that we do not promote or install such repositories. This is the don't talk about RPMFusion rule. So sure, we can have software that will pull things in if the user has done some manual intervention. We just cant, currently, do that thing for them. josh -- 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: Draft Product Description for Fedora Workstation
On Tue, Nov 5, 2013 at 9:23 PM, Josh Boyer jwbo...@fedoraproject.org wrote: On Tue, Nov 5, 2013 at 2:58 PM, Adam Williamson awill...@redhat.com wrote: On Fri, 2013-11-01 at 14:22 -0400, Josh Boyer wrote: - What about watching films, listening to music? I think it is a basic requirement for students (at least for me). Maybe we should add a that a student should be able to play videos and listen to music. It should be easy to install required codes (free/nonfree/patente) if they are available in the repositories (yes, I mean rpmfusion) This would require approval beyond the WG, as it goes against Fedora's policies. Note, I am not saying you are incorrect, just that it's a conversation to be had elsewhere first. Ensuring that it's possible/easy to install plugins from third party repositories when appropriate if those third party repositories are defined is not, I don't believe, against any policies, or we could not have the automatic codec installation mechanisms in Totem and Rhythmbox. (Which, as I read it, is the kind of thing this comment was about). The codec search only works if you have repositories configured that have packages that match the Provides (as far as I understand). Fedora policy says that we do not promote or install such repositories. This is the don't talk about RPMFusion rule. And I still think this kind of censorship is a bit to paranoid but IANAL. -- 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: Draft Product Description for Fedora Workstation
On Mon, 2013-11-04 at 11:13 +0100, drago01 wrote: On Mon, Nov 4, 2013 at 11:11 AM, Frank Murphy frankl...@gmail.com wrote: On Mon, 4 Nov 2013 11:03:45 +0100 drago01 drag...@gmail.com wrote: Apps shipping from upstream direcly does not have to be closed source. Firefox for instance could use that, or libreoffice, or eclipse. If a user needs a newer version (or nightly build) without having upstream worry about the specific distribution. I haven't read every post in the thread. Confused are use asking users to build nightlies (or other ver) from src? No we are just creating a way to allow those upstreams to create those builds for users (as Florian said without having them to update to rawhide or wait six months for the next release). Haven't read the whole thread yet, but in case it hasn't been said: Build a way would be great. I've said a few times that it'd be nice for there to be a cross-distro framework for third-party app distribution. Promote as the Proper Way To Get Apps On GNOME / Fedora Desktop would NOT be great. Having spent a lot of time thinking about both sides of the debate I'm still firmly in the 'coherent distribution is the ideal state' camp. Upstream distribution is probably never going to go away entirely, and it'd be good to make it as painless and reliable as possible _where it's really necessary to use it_. But it should never be the primary/preferred method of software distribution on Fedora, in my opinion. It should always be an exception. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- 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: Draft Product Description for Fedora Workstation
On Mon, 2013-11-04 at 21:03 +0100, drago01 wrote: On Mon, Nov 4, 2013 at 9:02 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 04.11.2013 20:56, schrieb drago01: On Mon, Nov 4, 2013 at 8:49 PM, Reindl Harald h.rei...@thelounge.net wrote: that's all true but you can be pretty sure if a app-store with bundeled applications exists *nobody* would package and maintain them as RPM - everybody would point with his finger to the app No because RPM packages apps *do* have benifits .. otherwise we wouldn't have this discussion. if it goes in that direction, and it starts faster than anybody likes you do a dramatical harm to the userbase which likes the consistent package managment and *really used* conecpt of shared libraries Again those are NOT MUTUALLY EXCLUSIVE. You can have sandboxed *and* rpm packaged apps at the same time. the most imporant word in your answer is *CAN* but you will not, nobody will package whatever application as RPM if he is fine with the app-store, so you *could* have both but i doubt at the end of the day it will happen And I disagree ... but there is a way to find out ... lets try and see ;) That's rather a cavalier attitude. You seem to agree that the future Harald posits is at least a possibility. If so, I think you, he and I would all agree it would be a negative outcome in at least some respects. It is, therefore, a future risk. It's not an easily reversible risk: we can't invent a sandboxed app distribution mechanism, promote it as a blessed and 'supported' method of app distribution for Fedora, and then suddenly say 'hey, wait, that was a bad idea!' and take it away again. Or, rather, we could, but that path would have its own negative consequences. So: you, he and I all agree that the path your propose implies a risk. You would also argue, I'm sure, that it may result in a benefit. In this situation what we should do is carefully consider the relative possibilities of the good, bad and mixed outcomes with as much precision as we can, and try to come up with a path forward which makes the likelihood of a good outcome as high as possible and the likelihood of a bad outcome as low as possible. Let's just try it and see what happens! is not a mature approach to risk management. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- 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: Draft Product Description for Fedora Workstation
On Mon, 2013-11-04 at 16:15 -0500, Bastien Nocera wrote: - Original Message - I don't get your example but I agree with Reindl Harald - Linux Distribution is a set of software that works as one coherent environment. Let it be 10, 100 or 1000 different packages but they're chosen, compiled and adjusted to work together. This is the strength of Linux as operating system. I'd like to see the QA matrix on that one... It's hideous, but I suspect the QA matrix for sandboxed apps would be even worse. Are you going to guarantee to me that the sandboxing will be 100% perfect - that we'll *never* have the case where a 'sandboxed' app works on Ubuntu 13.04 but not on Fedora 18? Yeah, I didn't think so... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora Workstation product name
On Tue, Nov 05, 2013 at 11:25:18AM -0500, Matthias Clasen wrote: The Fedora Workstation effort (not a great name, by the way), is brand It doesn't have to end up with that name, for the record. That's just a working title and indicative of the conversation at Flock. Peter Jones had suggested Fedora Client, and there were some others as well. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- 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: Draft Product Description for Fedora Workstation
On Tue, Nov 05, 2013 at 12:44:21PM -0800, Adam Williamson wrote: Promote as the Proper Way To Get Apps On GNOME / Fedora Desktop would NOT be great. Having spent a lot of time thinking about both sides of the debate I'm still firmly in the 'coherent distribution is the ideal state' camp. Upstream distribution is probably never going to go away entirely, and it'd be good to make it as painless and reliable as possible _where it's really necessary to use it_. But it should never be the primary/preferred method of software distribution on Fedora, in my opinion. It should always be an exception. I really would like all my desktop applications to run in a sandbox, whether they come from upstream directly or from us. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- 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: Draft Product Description for Fedora Workstation
On Tue, 2013-11-05 at 16:04 -0500, Matthew Miller wrote: On Tue, Nov 05, 2013 at 12:44:21PM -0800, Adam Williamson wrote: Promote as the Proper Way To Get Apps On GNOME / Fedora Desktop would NOT be great. Having spent a lot of time thinking about both sides of the debate I'm still firmly in the 'coherent distribution is the ideal state' camp. Upstream distribution is probably never going to go away entirely, and it'd be good to make it as painless and reliable as possible _where it's really necessary to use it_. But it should never be the primary/preferred method of software distribution on Fedora, in my opinion. It should always be an exception. I really would like all my desktop applications to run in a sandbox, whether they come from upstream directly or from us. I would like that too, to be clear. That is why I used the term upstream distribution and not the term sandboxed apps. Sandboxing is a desirable technology for both upstream and centralized distribution, which makes its conflation with upstream distribution unfortunate in this debate: I think that has come about because sandboxing is arguably more _urgently_ desirable for upstream distribution, but what we're really arguing about here is the old 'upstream vs. distro-based' chestnut, not sandboxing. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- 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: Draft Product Description for Fedora Workstation
On Tue, Nov 5, 2013 at 9:56 PM, Adam Williamson awill...@redhat.com wrote: On Mon, 2013-11-04 at 21:03 +0100, drago01 wrote: On Mon, Nov 4, 2013 at 9:02 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 04.11.2013 20:56, schrieb drago01: On Mon, Nov 4, 2013 at 8:49 PM, Reindl Harald h.rei...@thelounge.net wrote: that's all true but you can be pretty sure if a app-store with bundeled applications exists *nobody* would package and maintain them as RPM - everybody would point with his finger to the app No because RPM packages apps *do* have benifits .. otherwise we wouldn't have this discussion. if it goes in that direction, and it starts faster than anybody likes you do a dramatical harm to the userbase which likes the consistent package managment and *really used* conecpt of shared libraries Again those are NOT MUTUALLY EXCLUSIVE. You can have sandboxed *and* rpm packaged apps at the same time. the most imporant word in your answer is *CAN* but you will not, nobody will package whatever application as RPM if he is fine with the app-store, so you *could* have both but i doubt at the end of the day it will happen And I disagree ... but there is a way to find out ... lets try and see ;) That's rather a cavalier attitude. You seem to agree that the future Harald posits is at least a possibility. No I don't. I just think that at this point the best way to prove that to him is simply to show it how it works out in practice. I still don't get why we have to argue that much about something like this .. is giving upstreams a well defined way how to ship there applications instead of letting them come up with a hack really that bad? Upstreams will always (and always had) seek was to do that .. simply because there is demand. No one is forcing anyone to install such apps. -- 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: Draft Product Description for Fedora Workstation
On Tue, Nov 05, 2013 at 12:56:47PM -0800, Adam Williamson wrote: bad outcome as low as possible. Let's just try it and see what happens! is not a mature approach to risk management. Ehr, instead of promoting something as supported, just start off slow. Call if alpha, write down all the concerns, etc. Announcing this as the new supported + preferred way is not what is intended IMO. Your post effectively read as stop energy IMO. It is impossible to get everything right at the first version. Just ensure everyones expectation is correct. Call it experimental + alpha initially. Various concerns have been raised. Just write them down, make a plan to address them, done. -- Regards, Olav -- 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: Fedora Workstation product name
On Tue, Nov 5, 2013 at 4:00 PM, Matthew Miller mat...@fedoraproject.org wrote: On Tue, Nov 05, 2013 at 11:25:18AM -0500, Matthias Clasen wrote: The Fedora Workstation effort (not a great name, by the way), is brand It doesn't have to end up with that name, for the record. That's just a working title and indicative of the conversation at Flock. Peter Jones had suggested Fedora Client, and there were some others as well. People long ago dropped desktop@ from the CC list on the thread you took this from. If there is a desire to debate and suggest new names for the Workstation product, it should probably be done on desktop@ and not devel@. Please start a new thread there. josh -- 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: Draft Product Description for Fedora Workstation
On Mon, 2013-11-04 at 23:50 +0100, Michael Scherer wrote: Le lundi 04 novembre 2013 à 21:02 +0100, Reindl Harald a écrit : Am 04.11.2013 20:56, schrieb drago01: On Mon, Nov 4, 2013 at 8:49 PM, Reindl Harald h.rei...@thelounge.net wrote: that's all true but you can be pretty sure if a app-store with bundeled applications exists *nobody* would package and maintain them as RPM - everybody would point with his finger to the app No because RPM packages apps *do* have benifits .. otherwise we wouldn't have this discussion. if it goes in that direction, and it starts faster than anybody likes you do a dramatical harm to the userbase which likes the consistent package managment and *really used* conecpt of shared libraries Again those are NOT MUTUALLY EXCLUSIVE. You can have sandboxed *and* rpm packaged apps at the same time. the most imporant word in your answer is *CAN* but you will not, nobody will package whatever application as RPM if he is fine with the app-store, so you *could* have both but i doubt at the end of the day it will happen If no one think that using a rpm is bringing any value, then indeed, no one will do the job. Now, if someone think this is better for whatever reasons, then this someone will do the job. It seems that your fear is that if people are not forced to make rpm, they will not see the value of doing so, and so would not do it. So if that's the problem, then the solution is to demonstrate the value of packaging and rpm rather than restricting all others alternatives. So to me this is the nub of the debate, and it's both fantastically interesting and fantastically difficult to work out in advance. In an ideal world things would work the way Michael describes, and also, the stock market would behave precisely as neat theories based on rational actors predict, and no-one would have any difficulty solving the three door problem, and healthcare.gov would never have been launched in a state in which it could not possibly work... And in the real world, well, it's the real world. :) So let me step into my handy Tardis and bring back a vignette from the Real World after Fedora and other distributions bless upstream app distribution as a preferred channel: --- Scene: an office, much like this one. Manager: ...so, executive summary: you're saying you'd _like_ to spend a not insubstantial chunk of your fairly expensive time working to jump through some hoops so our Shiny New Application can be included in these 'downstream distribution' things, but if I insist, you can whack a button to put it in the Linux App Store and we can go to press with our announcement tomorrow? Well-Intentioned Techie A: (gulps)...yes. Manager: Whack that button, techie. Whack it hard. Now get out of my office, I have to call the PR department. Well-Intentioned Techie A: (sighs) OK. So, when will you let me have some time to work on having the app packaged in distributions further down the road? Manager: What were the concrete benefits to us again? Well-Intentioned Techie A: Err, well, in an extremely theoretical way that you will never understand no matter how many times I explain it to you, it probably makes our app - and the rest of the ecosystem! - more secure. Manager: Less of this 'ecosystem' crap, Techie, no-one cares about that. ZDNet is not yelling about any security issues in our product right now, right? WITA: Er, no. Manager: Okay, not my problem, then. What else? WITA: (sighs, continues with an ever-increasing sense of foreboding) Well, it might reduce storage and memory usage on the user's system by an amount that wouldn't really be appreciable and would be difficult for a non-technical user to associate with our app in the first pl- you're never going to give me time to work on this, are you? Manager: No. No, I'm not. But here, have another bottle of rye. WITA: (sighs, returns to office, resumes drinking) --- Now after I've collected my Tony awards...I hope you get the point. In theory, we'd still be able to evangelize the benefits of centralized distribution in a world where we blessed a form of upstream distribution. In practice, things may well be messier than that. If distros move away from the gospel of centralized distribution to a sufficient extent, we may wind up in a 'tragedy of the commons' where it's just not enough in anyone's short-term direct interest to invest the resources in supported centralized distribution, even though many people would recognize the arguments in its favour on a long-term, ecosystem-wide level. We can post it on the store and it'll work on everyone's system tomorrow is an *extremely* powerful argument. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora
AppData: what if screenshots are the wrong aspect ratio?
I just took a look at making AppData xml files for the packages I maintain. I started with the alphabetically first one (why not?): abe. Here is my first attempt: ?xml version=1.0 encoding=UTF-8? application id type=desktopabe.desktop/id licenceCC0/licence summaryAbe's Amazing Adventure/summary description p Abe's Amazing Adventure is a scrolling, platform-jumping, key-collecting, ancient pyramid exploring game, vaguely in the style of similar games for the Commodore+4. The game is intended to show young people (I'm writing it for my son's birthday) all the cool games they missed. /p /description screenshots screenshot type=defaulthttp://abe.sourceforge.net/screen0-4-1.png/screenshot screenshothttp://abe.sourceforge.net/screen2-4-2.png/screenshot /screenshots url type=homepagehttp://abe.sourceforge.net//url !-- FIXME: change this to an upstream email address for spec updates updatecontactsomeone_who_cares@upstream_project.org/updatecontact -- /application But those screenshots are not the right aspect ratio. What is the right thing to do here? Just use this anyway and let the GUIs decide how to resize the screenshots? Download the screenshots and figure out how to massage them into the right aspect ratio on my machine? If so, where do I store the massaged screenshots? Also, the documentation at http://people.freedesktop.org/~hughsient/appdata/ doesn't say what a screenshot type is supposed to be. I gathered that one should have type default and the rest should have no type by looking at some examples. If that's not correct, could the documentation be updated to explain this, please? Thanks, -- Jerry James http://www.jamezone.org/ -- 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: Draft Product Description for Fedora Workstation
On Tue, 2013-11-05 at 15:23 -0500, Josh Boyer wrote: On Tue, Nov 5, 2013 at 2:58 PM, Adam Williamson awill...@redhat.com wrote: On Fri, 2013-11-01 at 14:22 -0400, Josh Boyer wrote: - What about watching films, listening to music? I think it is a basic requirement for students (at least for me). Maybe we should add a that a student should be able to play videos and listen to music. It should be easy to install required codes (free/nonfree/patente) if they are available in the repositories (yes, I mean rpmfusion) This would require approval beyond the WG, as it goes against Fedora's policies. Note, I am not saying you are incorrect, just that it's a conversation to be had elsewhere first. Ensuring that it's possible/easy to install plugins from third party repositories when appropriate if those third party repositories are defined is not, I don't believe, against any policies, or we could not have the automatic codec installation mechanisms in Totem and Rhythmbox. (Which, as I read it, is the kind of thing this comment was about). The codec search only works if you have repositories configured that have packages that match the Provides (as far as I understand). Fedora policy says that we do not promote or install such repositories. This is the don't talk about RPMFusion rule. So sure, we can have software that will pull things in if the user has done some manual intervention. We just cant, currently, do that thing for them. Right, that's exactly what I was saying. I just think this is all the _original poster_ was talking about, not any kind of automatic configuration of such repositories. (Or at least, you can read it that way). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- 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: Draft Product Description for Fedora Workstation
On Tue, Nov 5, 2013 at 4:29 PM, Adam Williamson awill...@redhat.com wrote: On Tue, 2013-11-05 at 15:23 -0500, Josh Boyer wrote: On Tue, Nov 5, 2013 at 2:58 PM, Adam Williamson awill...@redhat.com wrote: On Fri, 2013-11-01 at 14:22 -0400, Josh Boyer wrote: - What about watching films, listening to music? I think it is a basic requirement for students (at least for me). Maybe we should add a that a student should be able to play videos and listen to music. It should be easy to install required codes (free/nonfree/patente) if they are available in the repositories (yes, I mean rpmfusion) This would require approval beyond the WG, as it goes against Fedora's policies. Note, I am not saying you are incorrect, just that it's a conversation to be had elsewhere first. Ensuring that it's possible/easy to install plugins from third party repositories when appropriate if those third party repositories are defined is not, I don't believe, against any policies, or we could not have the automatic codec installation mechanisms in Totem and Rhythmbox. (Which, as I read it, is the kind of thing this comment was about). The codec search only works if you have repositories configured that have packages that match the Provides (as far as I understand). Fedora policy says that we do not promote or install such repositories. This is the don't talk about RPMFusion rule. So sure, we can have software that will pull things in if the user has done some manual intervention. We just cant, currently, do that thing for them. Right, that's exactly what I was saying. I just think this is all the _original poster_ was talking about, not any kind of automatic configuration of such repositories. (Or at least, you can read it that way). OK. I guess that's fine, but it seems like a non-goal to me. I mean, it already works that way. All adding it to the PRD would do would make an easy thing to check off the list as met. josh -- 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: Draft Product Description for Fedora Workstation
On Tue, 2013-11-05 at 22:15 +0100, Olav Vitters wrote: On Tue, Nov 05, 2013 at 12:56:47PM -0800, Adam Williamson wrote: bad outcome as low as possible. Let's just try it and see what happens! is not a mature approach to risk management. Ehr, instead of promoting something as supported, just start off slow. Call if alpha, write down all the concerns, etc. Announcing this as the new supported + preferred way is not what is intended IMO. Your post effectively read as stop energy IMO. It is impossible to get everything right at the first version. Just ensure everyones expectation is correct. Call it experimental + alpha initially. Various concerns have been raised. Just write them down, make a plan to address them, done. What I'm trying to do is contribute to ensuring that happens. As I wrote in another post, I've always thought it'd be great if distros could collaborate on a single approved framework/channel for third party software releases (preferably before Valve does it for us). But it definitely _does_ need to be the case that this is done carefully and with a clear decision made on to what extent we choose to 'bless' this mechanism in comparison to the distro repositories. Essentially I'm trying to make the point that this is an extremely sensitive issue which has the potential to cause long-term and non-reversible changes to software distribution paradigms we've been using for decades, so it needs to be handled carefully and with an appreciation of all the consequences, not just with a 'hey, let's build it, slap together some press about it and see what happens' kind of attitude... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- 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: Draft Product Description for Fedora Workstation
On Tue, 2013-11-05 at 16:32 -0500, Josh Boyer wrote: On Tue, Nov 5, 2013 at 4:29 PM, Adam Williamson awill...@redhat.com wrote: On Tue, 2013-11-05 at 15:23 -0500, Josh Boyer wrote: On Tue, Nov 5, 2013 at 2:58 PM, Adam Williamson awill...@redhat.com wrote: On Fri, 2013-11-01 at 14:22 -0400, Josh Boyer wrote: - What about watching films, listening to music? I think it is a basic requirement for students (at least for me). Maybe we should add a that a student should be able to play videos and listen to music. It should be easy to install required codes (free/nonfree/patente) if they are available in the repositories (yes, I mean rpmfusion) This would require approval beyond the WG, as it goes against Fedora's policies. Note, I am not saying you are incorrect, just that it's a conversation to be had elsewhere first. Ensuring that it's possible/easy to install plugins from third party repositories when appropriate if those third party repositories are defined is not, I don't believe, against any policies, or we could not have the automatic codec installation mechanisms in Totem and Rhythmbox. (Which, as I read it, is the kind of thing this comment was about). The codec search only works if you have repositories configured that have packages that match the Provides (as far as I understand). Fedora policy says that we do not promote or install such repositories. This is the don't talk about RPMFusion rule. So sure, we can have software that will pull things in if the user has done some manual intervention. We just cant, currently, do that thing for them. Right, that's exactly what I was saying. I just think this is all the _original poster_ was talking about, not any kind of automatic configuration of such repositories. (Or at least, you can read it that way). OK. I guess that's fine, but it seems like a non-goal to me. I mean, it already works that way. All adding it to the PRD would do would make an easy thing to check off the list as met. I suppose we should go back to the OP and ask for clarification of exactly what the idea was, at this point :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- 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: Draft Product Description for Fedora Workstation
Hi On Tue, Nov 5, 2013 at 4:06 PM, Adam Williamson wrote: I would like that too, to be clear. That is why I used the term upstream distribution and not the term sandboxed apps. Sandboxing is a desirable technology for both upstream and centralized distribution, I am not sure that is a good distinction either. I mean, upstream could provide some metadata which can be aggregated and used by a centralized interface. Perhaps we should use distribution packages vs upstream packages instead? 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: Draft Product Description for Fedora Workstation
- Original Message - On Mon, 2013-11-04 at 16:15 -0500, Bastien Nocera wrote: - Original Message - I don't get your example but I agree with Reindl Harald - Linux Distribution is a set of software that works as one coherent environment. Let it be 10, 100 or 1000 different packages but they're chosen, compiled and adjusted to work together. This is the strength of Linux as operating system. I'd like to see the QA matrix on that one... It's hideous, but I suspect the QA matrix for sandboxed apps would be even worse. Are you going to guarantee to me that the sandboxing will be 100% perfect - that we'll *never* have the case where a 'sandboxed' app works on Ubuntu 13.04 but not on Fedora 18? There's bugs in every software. But it should work. That's the aim. Yeah, I didn't think so... Might not want to put answers in people's mouths. Did you read up on the various bundling techniques that were explored and the API/ABI guarantees we want to offer? I'll stop short of paraphrasing you. -- 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: Draft Product Description for Fedora Workstation
On Tue, 2013-11-05 at 16:32 -0500, Josh Boyer wrote: Right, that's exactly what I was saying. I just think this is all the _original poster_ was talking about, not any kind of automatic configuration of such repositories. (Or at least, you can read it that way). OK. I guess that's fine, but it seems like a non-goal to me. I mean, it already works that way. All adding it to the PRD would do would make an easy thing to check off the list as met. I would actually like to go a little further, and make it easy to enable 'clean' third-party repositories. If we imagine a future where e.g. valve is hosting a repository with their steam client, or say, the chromium web browser is available from the a fedora people page, I would really like it if searching for 'steam' or 'chromium' in gnome-software would bring up a text that said something like: The software you are looking for is available from a third-party repository. Do you want to enable it ? Matthias -- 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: Draft Product Description for Fedora Workstation
On Tue, 2013-11-05 at 13:23 -0800, Adam Williamson wrote: If distros move away from the gospel of centralized distribution Some people working on technologies in this area may have that as a goal, but I think it's absolutely crucial to continue to support the package model of application distribution as well. Consider applications like Boxes or virt-manager - these are tightly tied into the virtualization libraries which are in turn tightly tied into the operating system plumbing - and that's fine and makes sense! The two other cases are: - Less tightly coupled Free Software - Proprietary software This is a fantastically complex discussion for a number of reasons just with respect to terminology - for example, Debian has a non-free repository that is centralized, or at least more centralized than Fedora. I know you had a long mail, but your example didn't state whether Shiny New Application was Free Software or proprietary, or whether it was tightly coupled or not, etc. These aspects matter, and there's a lot of grey area in the continuum. But I guess a bottom line is as a member of the upstream GNOME community, I would argue very much against any application mechanism which did not allow applications to *also* be shipped in the traditional package model. -- 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: AppData: what if screenshots are the wrong aspect ratio?
On Tue, Nov 5, 2013 at 10:25 PM, Jerry James loganje...@gmail.com wrote: I just took a look at making AppData xml files for the packages I maintain. I started with the alphabetically first one (why not?): abe. Here is my first attempt: ?xml version=1.0 encoding=UTF-8? application id type=desktopabe.desktop/id licenceCC0/licence summaryAbe's Amazing Adventure/summary description p Abe's Amazing Adventure is a scrolling, platform-jumping, key-collecting, ancient pyramid exploring game, vaguely in the style of similar games for the Commodore+4. The game is intended to show young people (I'm writing it for my son's birthday) all the cool games they missed. /p /description screenshots screenshot type=defaulthttp://abe.sourceforge.net/screen0-4-1.png/screenshot screenshothttp://abe.sourceforge.net/screen2-4-2.png/screenshot /screenshots url type=homepagehttp://abe.sourceforge.net//url !-- FIXME: change this to an upstream email address for spec updates updatecontactsomeone_who_cares@upstream_project.org/updatecontact -- /application But those screenshots are not the right aspect ratio. What is the right thing to do here? Just use this anyway and let the GUIs decide how to resize the screenshots? Download the screenshots and figure out how to massage them into the right aspect ratio on my machine? If so, where do I store the massaged screenshots? Also, the documentation at http://people.freedesktop.org/~hughsient/appdata/ doesn't say what a screenshot type is supposed to be. I gathered that one should have type default and the rest should have no type by looking at some examples. If that's not correct, could the documentation be updated to explain this, please? http://blogs.gnome.org/hughsie/2013/10/08/how-to-take-169-screenshots/ -- 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: AppData: what if screenshots are the wrong aspect ratio?
On Tue, Nov 5, 2013 at 4:20 PM, drago01 drag...@gmail.com wrote: http://blogs.gnome.org/hughsie/2013/10/08/how-to-take-169-screenshots/ I was confused until I got to the comments. :-) Thanks for the pointer. That cleared things up for me. Regards, -- Jerry James http://www.jamezone.org/ -- 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: Draft Product Description for Fedora Workstation
Matthias Clasen wrote: I would actually like to go a little further, and make it easy to enable 'clean' third-party repositories. If we imagine a future where e.g. valve is hosting a repository with their steam client, or say, the chromium web browser is available from the a fedora people page, I would really like it if searching for 'steam' or 'chromium' in gnome-software would bring up a text that said something like: The software you are looking for is available from a third-party repository. Do you want to enable it ? I think users will not understand why all the vendor repositories with non- free crap are there and the stuff they are actually looking for is not. Kevin Kofler -- 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: Draft Product Description for Fedora Workstation
Matthew Miller wrote: I really would like all my desktop applications to run in a sandbox, whether they come from upstream directly or from us. Why? This artificially restricts what your applications can do and also hurts performance. It doesn't buy us anything other than problems! And what about libraries? Will they get bundled into each sandbox as the app principle seems to suggest? Kevin Kofler (who has SELinux disabled) -- 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: Draft Product Description for Fedora Workstation
I wrote: So now after the good balance, you bring up the Change with a capital 'C' (plagiarized from Barack Obama). Can you please cut down on the buzzword-loaden rhetoric bullshit? PS: Since it has been pointed out to me that it can be misunderstood as such, please don't take this as a rant against Obama. It's a rant against plagiarizing the Change rhetoric to promote just about anything as long as it's different. Riding the buzzword wave to promote just about anything with a regurgitation of somebody else's fashionable discourse is easy, but not the way to win any argument. Kevin Kofler -- 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: Draft Product Description for Fedora Workstation
On Tue, Nov 5, 2013 at 5:02 PM, Matthias Clasen mcla...@redhat.com wrote: On Tue, 2013-11-05 at 16:32 -0500, Josh Boyer wrote: Right, that's exactly what I was saying. I just think this is all the _original poster_ was talking about, not any kind of automatic configuration of such repositories. (Or at least, you can read it that way). OK. I guess that's fine, but it seems like a non-goal to me. I mean, it already works that way. All adding it to the PRD would do would make an easy thing to check off the list as met. I would actually like to go a little further, and make it easy to enable 'clean' third-party repositories. If we imagine a future where e.g. valve is hosting a repository with their steam client, or say, the chromium web browser is available from the a fedora people page, I would really like it if searching for 'steam' or 'chromium' in gnome-software would bring up a text that said something like: The software you are looking for is available from a third-party repository. Do you want to enable it ? That was how I understood the original proposal. And that's the conversation that needs to happen at a higher level outside of the WG before it can really be a reality. josh -- 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: Draft Product Description for Fedora Workstation
drago01 wrote: Depends on what you mean by power user (I hate this meaningless term) if it means software developer then yes. If it means someone that spends his whole day in config dialogs then no. A power user is somebody experienced with computers who uses them regularly and who wants to customize his/her system to his/her liking, not be forced into a straightjacket UI designed for people who have never touched a computer before that cannot be configured in any way. Software developers definitely fit into that category. Nobody will spend their whole day in configuration dialogs. Even if they are many options, those dialogs are something you set your preferences in once and then (hopefully) never have to touch again. (Of course, if you change your defaults every day due to some usability study on complete newbies which totally ignores the habit factor, then yes, they would have to reenter the dialogs. But not offering the option does not help, it will just make the user curse at you for making him suffer an unwanted change to his/her habitual workflow or move to a software that gives him/her the option.) And offering the option does not preclude having sane defaults, which means only those people who WANT to change something even SEE the dialog at all. So the option does not hurt the people who are not looking for it, that claim is just not true. In short: Make the defaults as sane as possible, but still allow the user to change them if they disagree with you on what is sane. The more options, the better. Kevin Kofler -- 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: Draft Product Description for Fedora Workstation
Bastien Nocera wrote: Might not want to put answers in people's mouths. Did you read up on the various bundling techniques that were explored and the API/ABI guarantees we want to offer? I'll stop short of paraphrasing you. The fact that bundling is even being explored as a technique at all makes me puke! Kevin Kofler -- 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: Draft Product Description for Fedora Workstation
Simo Sorce wrote: * and *ideally* I mean SELinux sanbdboxed with specific APIs that must be used to interact with the rest of the system, so that the application doesn't have free reign over users files. So you want to remove my freedom to disable SELinux? SARCASMWay to go… /SARCASM Kevin Kofler -- 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: Draft Product Description for Fedora Workstation
Miloslav Trmač wrote: Look at all the software that has been written for GTK1 and obsolete libraries that hasn't been ported and therefore no longer runs on Fedora. Wouldn't it have been nice to continue to have a practical option to use that software, even if it doesn't integrate that well and it no longer has an active maintainer? You're talking to the person who is doing most of the maintenance effort on qt3 and kdelibs3 and who is always vetoing any proposals to retire them. I do care about keeping the stuff we ship working, a lot even. But keeping compatibility libraries for old sonames where a simple rebuild is enough to fix all the software we ship is just useless. Compatibility libraries only make sense where porting is not trivial. Kevin Kofler -- 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: Draft Product Description for Fedora Workstation
Olav Vitters wrote: Various concerns have been raised. Just write them down, make a plan to address them, done. But many of those concerns are inherent to the concept of sandboxed applications or the methods of delivery they'd enable and cannot possibly be addressed, ever. The whole concept is fatally flawed. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Test-Announce] Fedora 20 Beta Release Candidate 4 (RC4) Available Now!
NOTE: The 32- and 64-bit Security Spins are over their respective size targets. As per the Fedora 20 schedule [1], Fedora 20 Beta Release Candidate 4 (RC4) is now available for testing. Content information, including changes, can be found at https://fedorahosted.org/rel-eng/ticket/5787#comment:26 . Please see the following pages for download links (including delta ISOs) and testing instructions. Normally dl.fedoraproject.org should provide the fastest download, but download-ib01.fedoraproject.org is available as a mirror (with an approximately 1 hour lag) in case of trouble. To use it, just replace dl with download-ib01 in the download URL. Installation: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test Base: https://fedoraproject.org/wiki/Test_Results:Current_Base_Test Desktop: https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test Ideally, all Alpha and Beta priority test cases for Installation [2], Base [3], and Desktop [4] should pass in order to meet the Beta Release Criteria [5]. Help is available on #fedora-qa on irc.freenode.net [6], or on the test list [7]. Create Fedora 20 Beta test compose (TC) and release candidate (RC) https://fedorahosted.org/rel-eng/ticket/5787 Current Blocker and Freeze Exception bugs: http://qa.fedoraproject.org/blockerbugs/current [1] http://fedorapeople.org/groups/schedule/f-20/f-20-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Installation_validation_testing [3] https://fedoraproject.org/wiki/QA:Base_validation_testing [4] https://fedoraproject.org/wiki/QA:Desktop_validation_testing [5] https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria [6] irc://irc.freenode.net/fedora-qa [7] https://admin.fedoraproject.org/mailman/listinfo/test signature.asc Description: OpenPGP digital signature ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce-- 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: Draft Product Description for Fedora Workstation
On Tue, 2013-11-05 at 16:52 -0500, Matthew Miller wrote: On Tue, Nov 05, 2013 at 01:23:01PM -0800, Adam Williamson wrote: So let me step into my handy Tardis and bring back a vignette from the Real World after Fedora and other distributions bless upstream app distribution as a preferred channel: I'm not sure I can match this for evocativeness, but: Manager: ...so, executive summary: you're saying you'd _like_ to spend a not insubstantial chunk of your fairly expensive time working to jump through some hoops so our Shiny New Application can be included in these 'downstream distribution' things, but if I insist, you can whack a button to put it in the Linux App Store and we can go to press with our announcement tomorrow? Well-Intentioned Techie A: (gulps)...yes. Manager: Whack that button, techie. Whack it hard. Now get out of my office, I have to call the PR department. In a different future where there is no such magic button, what brings enlightenment to the manager? I think maybe the conversation goes much like yours, except with and don't bother me about 'getting into downstream distributions' again. There's two differences: 1) It's substantially easier for users to get your app from their distro repos than from your own distribution system 2) It's probably rather more work for you to maintain your own distribution system To summarize it cynically - the comparative shittiness of current third-party distribution methods (various podunk frameworks which don't really work, non-repo packages, or the old statically-compiled-binary-in-a-tarball being your only options) works in favour of distro packaging. Yes, in an ideal world (as I was saying) we could get everyone on board with 'distro packaging is better than even a good third party distribution framework once you get over the initial startup costs!' even if we improve third party distribution, but in the _real_ world, it may be the case that once we make third party distribution X% more convenient for both sides and X% more officially blessed by distributions, suddenly no-one cares about distro packaging any more. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora 20-Beta RC4 AMIS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi all, Beta RC2 images have been uploaded to EC2 and are available at ami-c3e3bbaa : us-east-1 image for i386 ami-d3e2baba : us-east-1 image for x86_64 additionally if your looking to the AMI's they have been added to files in the release tree http://dl.fedoraproject.org/pub/alt/stage/20-Beta-RC4/Images/i386/Fedora-Images-i386-20-Beta-AMI http://dl.fedoraproject.org/pub/alt/stage/20-Beta-RC4/Images/x86_64/Fedora-Images-x86_64-20-Beta-AMI when we get to final Beta and the images are uploaded to all regions they will all be listed and the file will be gpg signed in the final tree Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJSeaP8AAoJEH7ltONmPFDRk9IP/jnNhm8M088uIJw/4LQYfy7n UtBF6NnEb1yUg2TSMuprVc4z1ZczG2t/UPZiQW5j6QnXLg+72XjYmr/9W/BhH1AR rrzIOzQskrD1HK0yvkTt8P2KEgulCsUknx5PDgwY1pe3A55kHLiB/ePpUY0Sow8V 6bzHAaOdyX8RhumqkwB1GkVMavH89jgzmSntu0+qa/Yp8Y4H6gPr+6BpNtLUz9tu fH15kqBayGzvNhoXzDtgiKF+eH/KITcdngNxjVIDSWYacYdhgbN3cYXI6z9D9Ylj b5g11XfNwlB50hzQIldFyOdHVJtIqEA97uixPlHVBGfP1+vF5cbb40DK2qWNv87m MmqGpXb3nvC9RKwQWbEHgAaIDAOFqFs+AD5AyDlBJRl9J0w4WvXEZpJwCWaaRJLf 1gEyr5m/K0GAyFPgtxsAvGjNzJUrA958++5QHy4Ogpq2dXd0ZcTedIz3Vu5FLvTG tHsmSJet3wmfMsVXw5lqGdSKqsYMfxIe/eLSzhqkSn9ckbrLMBpUqSxqiFXel3Lt qNvnyec8lDZcn1PsN6OhAvktpB5bvfy0xcOObikmGAEaQByNZ3sCxxOp8zJ7azrR 9E1MfpGgle1S1arOLoVCvG5S+Gp3HFxdI37BqFG6Qxwu2Cab9dYAN8T7whNzr68z 8yCKj2s2W3dctfNK4FYv =5Nfl -END PGP 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: AppData: what if screenshots are the wrong aspect ratio?
Hi, drago01 already answered your screenshot question, but... On Tue, 2013-11-05 at 14:25 -0700, Jerry James wrote: I just took a look at making AppData xml files for the packages I maintain. I started with the alphabetically first one (why not?): abe. Here is my first attempt: ?xml version=1.0 encoding=UTF-8? application id type=desktopabe.desktop/id I'm pretty sure it should just be abe here, not abe.desktop. licenceCC0/licence summaryAbe's Amazing Adventure/summary description p Abe's Amazing Adventure is a scrolling, platform-jumping, key-collecting, ancient pyramid exploring game, vaguely in the style of similar games for the Commodore+4. The game is intended to show young people (I'm writing it for my son's birthday) all the cool games they missed. /p Maybe split that into two paragraphs, so it looks nicer and more readable in the GUI? -- Mathieu -- 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: gtk3 broken/missing icons on kde
On Tue, 2013-11-05 at 11:19 -0500, Matthias Clasen wrote: On Tue, 2013-11-05 at 08:23 +0100, drago01 wrote: On Tue, Nov 5, 2013 at 3:03 AM, Adam Williamson awill...@redhat.com wrote: On Sun, 2013-10-27 at 01:46 +0200, Kevin Kofler wrote: Adam Williamson wrote: I don't think we'd really be correct in blocking the release for such issues - especially not Beta. We used to have 'polish' criteria for Final which at least required the icons used in the system menus - i.e. what's specified in the app's .desktop file - to be sane for all installed applications, but we dropped that (and other polish criteria) with the F19/F20 criteria re-write on the basis that they were really stretching a bit too far and would be unlikely to hold up to a 'last blocker before release' acid test. Stuff like this doesn't break anyone's use of the system catastrophically and can reasonably be fixed with updates. But it also affects the live images (making them look very unpolished) and we don't respin those. That's why I said 'reasonably' not 'perfectly' :) I can see an argument for blocking Final, though in practice, I don't think our current standards are such that it really makes sense to claim our final releases are so smooth as to be worth enforcing a high standard of polish via the blocker mechanisms Then we should that. There is a difference between perfect and something that looks obviously broken. Are we really fighting about the classification of fixed bugs here, or is there a new issue that I am not aware of ? It's become a question of whether there should be a Beta or Final requirement for icons to be present / look good, I think. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- 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: AppData: what if screenshots are the wrong aspect ratio?
On Tue, Nov 5, 2013 at 7:17 PM, Mathieu Bridon boche...@fedoraproject.org wrote: Hi, drago01 already answered your screenshot question, but... On Tue, 2013-11-05 at 14:25 -0700, Jerry James wrote: I just took a look at making AppData xml files for the packages I maintain. I started with the alphabetically first one (why not?): abe. Here is my first attempt: ?xml version=1.0 encoding=UTF-8? application id type=desktopabe.desktop/id I'm pretty sure it should just be abe here, not abe.desktop. Well, the example on http://people.freedesktop.org/~hughsient/appdata/ has the .desktop extension, as did the gimp appdata file that I looked at while doing this. licenceCC0/licence summaryAbe's Amazing Adventure/summary description p Abe's Amazing Adventure is a scrolling, platform-jumping, key-collecting, ancient pyramid exploring game, vaguely in the style of similar games for the Commodore+4. The game is intended to show young people (I'm writing it for my son's birthday) all the cool games they missed. /p Maybe split that into two paragraphs, so it looks nicer and more readable in the GUI? Sure, easy enough. Thanks for the feedback! -- Jerry James http://www.jamezone.org/ -- 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: AppData: what if screenshots are the wrong aspect ratio?
On Tue, 2013-11-05 at 20:14 -0700, Jerry James wrote: On Tue, Nov 5, 2013 at 7:17 PM, Mathieu Bridon boche...@fedoraproject.org wrote: On Tue, 2013-11-05 at 14:25 -0700, Jerry James wrote: ?xml version=1.0 encoding=UTF-8? application id type=desktopabe.desktop/id I'm pretty sure it should just be abe here, not abe.desktop. Well, the example on http://people.freedesktop.org/~hughsient/appdata/ has the .desktop extension, as did the gimp appdata file that I looked at while doing this. Indeed, you are right. Sorry about that. -- Mathieu -- 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: Draft Product Description for Fedora Workstation
On Wed, 2013-11-06 at 01:13 +0100, Kevin Kofler wrote: Simo Sorce wrote: * and *ideally* I mean SELinux sanbdboxed with specific APIs that must be used to interact with the rest of the system, so that the application doesn't have free reign over users files. So you want to remove my freedom to disable SELinux? SARCASMWay to go… /SARCASM If this is all you have to say about what I wrote (strawman on a note and ignore completely the rest) you have nothing valid to say in this discussion. Go away troll. Simo. -- Simo Sorce * Red Hat, Inc * New York -- 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: [Fedora Base Design WG] Committee FESCO approved, next steps
On Nov 4, 2013 12:01 PM, Stephen Gallagher sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/04/2013 11:07 AM, Phil Knirsch wrote: Hi everyone. A quick update from my side regarding the Base Design WG: - My proposed committee was approved by FESCO last Wednesday. One negative vote came from Stephen Gallagher that he would have very much preferred to have Lennart instead of Harald or Josh on the committee. To be completely clear, I said I would have preferred having Lennart on the WG. I did not state that I thought Harald or Josh should not be members. That's an important distinction, I think :) I felt strongly enough that Lennart belonged on this group that I chose to cast a token vote, knowing that it would not affect the outcome. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJ34PkACgkQeiVVYja6o6MrUwCgpYhhbnQ2eFX/c4Eb8bSAbBVs fB4AoIKJyckoVozKnZyh03E0MfMzmpxy =L79V -END PGP 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 Howdy folks. Looking forward to getting to work on base design. Regarding the voting members I feel we have a great group. Everyone intersted (voting or not) should participate in our discussions. My vote will certainly be influenced by anyone in the community willing to participate. :-) One thing I would like to talk about is embedded Fedora, mostly as that is my personal area of involvement with the project. There is not an embedded working group, and it's my agenda to hopefully have the base design double as embedded. It makes sense to me in the sense that base ring-zero is sort of the embedded core into cloud, server, or workstation. By itself base would be suitable for the smallest deployment. Another item I'd like to consider for the initial discussion is the release cycle for the base design. My feeling is that base is small enough and simple enough to allow a more frequent release, perhaps even continuously. My guess is the other WGs will have their own ideas for how frequently they output. So base WG would need to be the lowest common denominator in that way. Obviouly rel-eng and qa need to represent for this topic. :-) Thanks, -Jon Disnard -- 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: R: Re: Discontinued Packing of NetBeans IDE
Il 05/11/2013 18:59, punto...@libero.it ha scritto: hi see https://fedoraproject.org/wiki/Features/NetBeans_7.3 (should be update) problem(s): - latest NB releases use some libraries available in java8 e.g. https://github.com/furosys/nashorn Nashorn for Java 7 https://bitbucket.org/ramonza/nashorn-backport (used by NB) https://bugzilla.redhat.com/show_bug.cgi?id=1005932 - eclipse integration, i/we haven't no intentions to use eclipse libraries (e. g. eclipse jgit) if users would like to use these features should/must use eclipse ide - some libraries was updates, and others should be adapted for latest release 7.4 for now porting of NB is stopped regards gil Messaggio originale Da: sochotni...@redhat.com Data: 05/11/2013 18.03 A: Development discussions related to Fedoradevel@lists.fedoraproject.org Ogg: Re: Discontinued Packing of NetBeans IDE Quoting Rahul Sundaram (2013-11-05 17:46:55) Hi On Tue, Nov 5, 2013 at 11:45 AM, Manuel Faux wrote: Is it correct that the NetBeans IDE is currently not packed for Fedora? I checked the netbeans package, which was last built for fc17. Is there any technical or license reason for this or is just nobody packing it right now? Someone from Sun used to be the maintainer and noone is doing it right now. No technical or licensing issues if anyone is interested in packaging it afaik. More specifically look at: https://lists.fedoraproject.org/pipermail/java-devel/2010-November/003980. html Reason nobody picked it up is that is has relatively big dependency chain and there was nobody interested enough (from maintainer perspective). Most Java packages are in Fedora because they are dependencies of following packages: * Tomcat * Maven * Eclipse * WildFly * (new) Big Data SIG stuff * and of course a few more apps here and there -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.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 attachment: puntogil.vcf-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Schedule for Wednesday's FESCo Meeting (2013-11-06)
Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2013-11-06 18:00 UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1185 Enable -Werror=format-security by default .fesco 1185 https://fedorahosted.org/fesco/ticket/1185 = New business = #topic #1192 OpenH264 as an automatic download by firefox/Statement to the ietf WebRTC working group .fesco 1192 https://fedorahosted.org/fesco/ticket/1192 #topic #1193 reboots for all updates -- are we ready for this? .fesco 1193 https://fedorahosted.org/fesco/ticket/1193 #topic #1188 Stalled bug 560361 -- requesting intervention .fesco 1188 https://fedorahosted.org/fesco/ticket/1188 .bug 560361 Dhclient doesn't use client-identifier; may cause issues in certain bridged environments https://bugzilla.redhat.com/show_bug.cgi?id=560361 #topic #1189 Stalled bug 758826 -- requesting intervention .fesco 1189 https://fedorahosted.org/fesco/ticket/1189 .bug 758826 system-config-firewall should include 'submission' in list of known ports https://bugzilla.redhat.com/show_bug.cgi?id=758826 #topic #1194 Ratify Server Working Group governance charter .fesco 1194 https://fedorahosted.org/fesco/ticket/1194 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -Toshio pgporQfJIY7kI.pgp Description: PGP 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
[Bug 1026704] New: perl-DBD-MySQL-4.025 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1026704 Bug ID: 1026704 Summary: perl-DBD-MySQL-4.025 is available Product: Fedora Version: rawhide Component: perl-DBD-MySQL Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, mmasl...@redhat.com, perl-devel@lists.fedoraproject.org Latest upstream release: 4.025 Current version/release in Fedora Rawhide: 4.024-1.fc21 URL: http://search.cpan.org/dist/DBD-mysql/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=DpO1dQEQDpa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1026705] New: perl-ExtUtils-MakeMaker-6.82 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1026705 Bug ID: 1026705 Summary: perl-ExtUtils-MakeMaker-6.82 is available Product: Fedora Version: rawhide Component: perl-ExtUtils-MakeMaker Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 6.82 Current version/release in Fedora Rawhide: 6.80-1.fc21 URL: http://search.cpan.org/dist/ExtUtils-MakeMaker/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=TukCvbkehaa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1026708] New: perl-IPC-Cmd-0.86 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1026708 Bug ID: 1026708 Summary: perl-IPC-Cmd-0.86 is available Product: Fedora Version: rawhide Component: perl-IPC-Cmd Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 0.86 Current version/release in Fedora Rawhide: 0.84-1.fc20 URL: http://search.cpan.org/dist/IPC-Cmd/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=I8Q41vMZK3a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1026711] New: perl-Module-Build-0.4008 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1026711 Bug ID: 1026711 Summary: perl-Module-Build-0.4008 is available Product: Fedora Version: rawhide Component: perl-Module-Build Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org Latest upstream release: 0.4008 Current version/release in Fedora Rawhide: 0.40.07-3.fc20 URL: http://search.cpan.org/dist/Module-Build/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=efuQXVus5ja=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1026716] New: perl-Test-Reporter-1.60 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1026716 Bug ID: 1026716 Summary: perl-Test-Reporter-1.60 is available Product: Fedora Version: rawhide Component: perl-Test-Reporter Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 1.60 Current version/release in Fedora Rawhide: 1.59-3.fc20 URL: http://search.cpan.org/dist/Test-Reporter/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=tWVdYnuar8a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-BerkeleyDB
perl-BerkeleyDB has broken dependencies in the F-20 tree: On x86_64: perl-BerkeleyDB-0.53-1.fc20.x86_64 requires libdb = 0:5.3.21 On i386: perl-BerkeleyDB-0.53-1.fc20.i686 requires libdb = 0:5.3.21 On armhfp: perl-BerkeleyDB-0.53-1.fc20.armv7hl requires libdb = 0:5.3.21 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
