Re: Discontinued Packing of NetBeans IDE
Il 07/11/2013 08:27, Manuel Faux ha scritto: On Tue, 5 Nov 2013 18:38:38 + devel-requ...@lists.fedoraproject.org wrote: 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). I have investigated the build process of NetBeans and I can just can go along with the fact that its dependency chain is quite long. Nevertheless I would like to reactivate it. If anyone is interested in helping, feel free to contact me. It seems like, that also netbeans-platform was not updated since quite a long time, which means that this package needs to be updated before. Manuel hi, see https://fedoraproject.org/wiki/Features/NetBeans_7.3 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: AppData questions
On Wed, Nov 6, 2013 at 8:43 PM, Richard Hughes hughsi...@gmail.com wrote: On 6 November 2013 10:41, Michael Schwendt mschwe...@gmail.com wrote: # rpm -qf /usr/share/app-info/xmls/fedora-20.xml.gz gnome-software-3.10.3-1.fc20.x86_64 does. It's AppStream metadata. Whould it not be a good idea to have it in a separate package, such kind of metadata should not be included with the application package IMHO Tim -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
File HTML-Format-2.11.tar.gz uploaded to lookaside cache by corsepiu
A file has been added to the lookaside cache for perl-HTML-Format: e69875098e9c2777d8d196d95f96b62e HTML-Format-2.11.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-HTML-Format] Upstream update.
commit 43154eca459f6d905082a170420fdea0377f53de
Author: Ralf Corsépius corse...@fedoraproject.org
Date: Thu Nov 7 09:37:00 2013 +0100
Upstream update.
- Drop perl-HTML-Format-2.10.diff.
.gitignore |2 +-
perl-HTML-Format-2.10.diff | 12
perl-HTML-Format.spec | 14 ++
sources|2 +-
4 files changed, 8 insertions(+), 22 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index fa45785..d7cfb71 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-/HTML-Format-2.10.tar.gz
+/HTML-Format-2.11.tar.gz
diff --git a/perl-HTML-Format.spec b/perl-HTML-Format.spec
index 60a5fe6..a5e0885 100644
--- a/perl-HTML-Format.spec
+++ b/perl-HTML-Format.spec
@@ -1,14 +1,12 @@
Name: perl-HTML-Format
-Version:2.10
-Release:9%{?dist}
+Version:2.11
+Release:1%{?dist}
Summary:HTML formatter modules
Group: Development/Libraries
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/HTML-Format/
Source0:
http://www.cpan.org/authors/id/N/NI/NIGELM/HTML-Format-%{version}.tar.gz
-# Work-around testsuite failure
-Patch0: %{name}-%{version}.diff
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
BuildArch: noarch
@@ -76,9 +74,6 @@ A collection of modules that formats HTML as plaintext,
PostScript or RTF.
%prep
%setup -q -c -T -n %{name}-%{version}
%setup -q -T -D -n %{name}-%{version} -a0
-cd HTML-Format-%{version}
-%patch0 -p1
-cd ..
%build
cd HTML-Format-%{version}
@@ -98,12 +93,15 @@ RELEASE_TESTING=1 ./Build test
cd ..
%files
-%defattr(-,root,root,-)
%doc HTML-Format-%{version}/Changes HTML-Format-%{version}/README
HTML-Format-%{version}/LICENSE
%{perl_vendorlib}/HTML
%{_mandir}/man3/HTML*
%changelog
+* Thu Nov 07 2013 Ralf Corsépius corse...@fedoraproject.org - 2.11-1
+- Upstream update.
+- Drop perl-HTML-Format-2.10.diff.
+
* Sun Aug 04 2013 Petr Pisar ppi...@redhat.com - 2.10-9
- Perl 5.18 rebuild
diff --git a/sources b/sources
index 1202ace..0223ffa 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-34831ec506eaa8a7ad5da698224cf58d HTML-Format-2.10.tar.gz
+e69875098e9c2777d8d196d95f96b62e HTML-Format-2.11.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
Re: Draft Product Description for Fedora Workstation
On Thu, Nov 7, 2013 at 3:41 AM, Kevin Kofler kevin.kof...@chello.at wrote: Olav Vitters wrote: The definition given by Frank Murphy is totally different and doesn't align with above. Above also doesn't relate to developers. These align a lot with what I wrote though. :-) http://en.wiktionary.org/wiki/power_user http://en.wikipedia.org/wiki/Power_user No it doesn't if you go by them a developer is not a power user and neither of those really match your definition either. So you all proved that is a meaningless term (i.e buzzword). So can we go back to use proper use case definitions? I need X because I am a power user makes no sense at all. I need X because it helps me do . is way better to work with. -- 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-HTML-Format/f20] Upstream update.
Summary of changes: 43154ec... Upstream update. (*) (*) 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
Re: Discontinued Packing of NetBeans IDE
On Thu, 7 Nov 2013 09:11:37 +0100 punto...@libero.it punto...@libero.it wrote: Il 07/11/2013 08:27, Manuel Faux ha scritto: On Tue, 5 Nov 2013 18:38:38 + devel-requ...@lists.fedoraproject.org wrote: 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). I have investigated the build process of NetBeans and I can just can go along with the fact that its dependency chain is quite long. Nevertheless I would like to reactivate it. If anyone is interested in helping, feel free to contact me. It seems like, that also netbeans-platform was not updated since quite a long time, which means that this package needs to be updated before. Manuel hi, see https://fedoraproject.org/wiki/Features/NetBeans_7.3 gil Hi, I saw this page, but I could not find out, if anybody actually is working on this. All the TODO bugs are assigned to nobody and also the wiki page was not updated for a long time. Since you are the owner of this feature, is it okay to update it for NetBeans version 7.4 and go ahead with working on it? Manuel -- 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
Il 07/11/2013 09:47, Manuel Faux ha scritto: On Thu, 7 Nov 2013 09:11:37 +0100 punto...@libero.it punto...@libero.it wrote: Il 07/11/2013 08:27, Manuel Faux ha scritto: On Tue, 5 Nov 2013 18:38:38 + devel-requ...@lists.fedoraproject.org wrote: 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). I have investigated the build process of NetBeans and I can just can go along with the fact that its dependency chain is quite long. Nevertheless I would like to reactivate it. If anyone is interested in helping, feel free to contact me. It seems like, that also netbeans-platform was not updated since quite a long time, which means that this package needs to be updated before. Manuel hi, see https://fedoraproject.org/wiki/Features/NetBeans_7.3 gil Hi, I saw this page, but I could not find out, if anybody actually is working on this. All the TODO bugs are assigned to nobody and also the yes, because NB isn't really a priority now... (see Bigdata or Wildfly projects) really there are not many TODO just upudate (we don't want import in a separate package for e.g. netbeans-platform, or use eclipse apis) this package: netbeans-javaparser wiki page was not updated for a long time. Since you are the owner of this feature, is it okay to update it for NetBeans version 7.4 and go ahead with working on it? for the page contact Vedran Miletić riva...@gmail.com https://fedoraproject.org/wiki/User:Vedranm Manuel 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
On 7 Nov 2013 03:05, Kevin Kofler kevin.kof...@chello.at wrote: Josh Boyer wrote: What you say makes some sense. It also makes me very tired thinking about the threads coming when the details start getting presented by the WGs :). I guess that's what we've signed up for though. Well yes, each time you try to force a change through which actually makes things worse, there WILL be resistance. In fact, this is already what is happening in this thread, the app proposal coming from (parts of) the Workstation WG. I don't see many people forcing things through, I believe that the vast majority of contributors either like the change or aren't bothered by it. There's certainly no proof that it'll make anything worse. That doesn't mean its going to be perfect or without teething problems as the changes are made and things settle down. The fact that you don't like change or don't understand it means that you shouldn't try and project your opinion as that of the general community. Peter -- 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 7 Nov 2013 03:20, Kevin Kofler kevin.kof...@chello.at wrote: Olav Vitters wrote: On Wed, Nov 06, 2013 at 01:00:16AM +0100, Kevin Kofler wrote: 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! That's offtopic. How is pointing out a fundamental unfixable flaw in the approach you are advocating off topic? Just because you can't see a way to fix it doesn't mean its either unfixable or that there aren't people willing to step up to do so. Peter -- 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, 01 Nov 2013 10:24:20 -0400 Christian Fredrik Kalager Schaller cscha...@redhat.com wrote: Will the other DE's still exist after workstation Will a dev be able to use Xfce, Lxde as graphical choice. What would encourage say an xubuntu dev //* devs are still users */ working on foo, to switch to Fedora Workstation? -- 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 Thu, Nov 07, 2013 at 03:53:48AM +0100, Kevin Kofler wrote: Olav Vitters wrote: AFAIK (not sure), it should come somewhat easy once you the distribution is based upon systemd. That means it will exclude the most popular distribution out there. I fail to see the point of discussing non-Fedora distributions on Fedora devel mailing list. If you want to discuss GNOME, we also have a development list, see https://mail.gnome.org/mailman/listinfo/desktop-devel-list. A bit more logical to include people who actually work on this and less annoying to people who don't want to discuss other distributions on the Fedora mailing list. -- 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
[perl-Archive-Any/f20] Update to 0.0941
Summary of changes: 60054ed... Update to 0.0941 (*) (*) 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
Re: Draft Product Description for Fedora Workstation
On Thu, Nov 07, 2013 at 04:01:09AM +0100, Kevin Kofler wrote: Well yes, each time you try to force a change through which actually makes things worse, there WILL be resistance. In fact, this is already what is happening in this thread, the app proposal coming from (parts of) the Workstation WG. That you see a proposal as forcing things through is unfortunate. But I don't see much resistance, there are concerns and sometimes voiced in a strange way, but that's pretty much it. -- 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
[perl-Archive-Any] Created tag perl-Archive-Any-0.0941-1.fc20
The lightweight tag 'perl-Archive-Any-0.0941-1.fc20' was created pointing to: 60054ed... Update to 0.0941 -- 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 Thu, Nov 07, 2013 at 03:50:59AM +0100, Kevin Kofler wrote: Olav Vitters wrote: On Wed, Nov 06, 2013 at 01:00:16AM +0100, Kevin Kofler wrote: 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! That's offtopic. How is pointing out a fundamental unfixable flaw in the approach you are advocating off topic? You're pointing out that you want to puke. That's offtopic for this mailing list. I rather not know the amount of detail that you're displaying. -- 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
[perl-Archive-Any] Created tag perl-Archive-Any-0.0941-1.fc21
The lightweight tag 'perl-Archive-Any-0.0941-1.fc21' was created pointing to: 60054ed... Update to 0.0941 -- 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
2013/11/7 Olav Vitters o...@vitters.nl On Thu, Nov 07, 2013 at 03:53:48AM +0100, Kevin Kofler wrote: Olav Vitters wrote: AFAIK (not sure), it should come somewhat easy once you the distribution is based upon systemd. That means it will exclude the most popular distribution out there. I fail to see the point of discussing non-Fedora distributions on Fedora devel mailing list. I fail to see the point of discussing a feature that is meant to allow upstreams to provide installable bundles that work in all linuxes if it is only to work in 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: Draft Product Description for Fedora Workstation
On Thu, 7 Nov 2013 11:17:28 +0100 Olav Vitters o...@vitters.nl wrote: On Thu, Nov 07, 2013 at 03:53:48AM +0100, Kevin Kofler wrote: Olav Vitters wrote: AFAIK (not sure), it should come somewhat easy once you the distribution is based upon systemd. That means it will exclude the most popular distribution out there. I fail to see the point of discussing non-Fedora distributions on Fedora devel mailing list. If you want to discuss GNOME, we also have a development list, see https://mail.gnome.org/mailman/listinfo/desktop-devel-list. To be fair you introduced Guadec, aka Gnome developemt. (I'm not pro\anti Gnome) A bit more logical to include people who actually work on this and less annoying to people who don't want to discuss other distributions on the Fedora mailing list. May it be loosely to cover target audience, Why are they using distro X, is what the wg is doing going to win them over? -- 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
Kevin, On Thu, 2013-11-07 at 04:12 +0100, Kevin Kofler wrote: So where's the strawman? please stop with this. Simo wrote a rather long email post and argued he's view on users' freedom and all you did in reply was to nitpick on a footnote. Or in Simo's words again: On Tue, 2013-11-05 at 23:12 -0500, Simo Sorce wrote: 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. Regards, Tadej -- 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: rpm macro magic help
On Sat, 02 Nov 2013 18:40:46 +0100, Sandro Mani wrote:
On 02.11.2013 18:18, Kevin Kofler wrote:
Hi,
Sandro Mani wrote:
%define do_build() \
mkdir build_win%{1}_%{2}; \
(cd build_win%{1}_%{2}; \
%{mingw%{1}_qmake_%{2}} 'PREFIX=%{mingw%{1}_prefix}'
'TARGET=quazip-%{2}' ../libquazip; \
%{mingw%{1}_make} %{?_smp_mflags}; \
)\
%{nil}
Ewww!
Sorry to rain on your parade, but are you sure this (and with the fix for
the nested expansion, it becomes even more ugly) is compatible with the
spec files must be legible packaging guideline?
That is a valid point. I don't know what is better,
Well, a Shell Function would be more readable, for example. It would
accept normal arguments to fill in variables -- instead of global RPM
macros, which are substituted in the entire spec file.
--
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-Test-TCP/f20] Upstream update.
Summary of changes: 5535550... Upstream update. (*) (*) 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
[Bug 1027763] New: perl-XML-LibXSLT-1.82 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1027763 Bug ID: 1027763 Summary: perl-XML-LibXSLT-1.82 is available Product: Fedora Version: rawhide Component: perl-XML-LibXSLT Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-de...@lists.fedoraproject.org, z...@fastmail.fm Latest upstream release: 1.82 Current version/release in Fedora Rawhide: 1.81-2.fc20 URL: http://search.cpan.org/dist/XML-LibXSLT/ 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=SS47tgupEoa=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
Fedora 20 Beta Go/No-Go Meeting #3, Thursday, November 07 @ 17:00 UTC
Join us on irc.freenode.net in #fedora-meeting-2 for this important meeting, wherein we shall determine the readiness of the Fedora 20 Beta. This is the third attempt to release Fedora 20 Beta. Currently, RC5 is under validation, please help if you can [1]. Two new blocker bugs are proposed. Thursday, November 07, 2013 17:00 UTC (12 PM EST, 9 AM PST, 18:00 CET) (Beware of time change - now in the US!) Before each public release Development, QA and Release Engineering meet to determine if the release criteria are met for a particular release. This meeting is called the Go/No-Go Meeting. Verifying that the Release criteria are met is the responsibility of the QA Team. For more details about this meeting see: https://fedoraproject.org/wiki/Go_No_Go_Meeting In the meantime, keep an eye on the Fedora 20 Beta Blocker list: http://qa.fedoraproject.org/blockerbugs/milestone/20/beta/buglist [1] https://lists.fedoraproject.org/pipermail/test/2013-November/118688.html ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-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 11/06/2013 11:30 PM, Olav Vitters wrote: On Wed, Nov 06, 2013 at 10:55:30PM +0100, Sergio Pascual wrote: Has this sanboxed-bundled-from-upstream proposal been discussed with other distributions? If the final result is that the Universal Linux Package only works in Fedora we are not gaining anything. A lot of this is being based on technology that's not really available yet such as kdbus, Wayland, systemd bits. This has been discussed at GUADEC (GNOME conference): http://www.superlectures.com/guadec2013/sandboxed-applications-for-gnome Wayland and systemd strongly suggest no Ubuntu interoperability whatsoever. Shouldn't this be a top priority for bundled applications? -- Florian Weimer / Red Hat Product Security Team -- 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 11/06/2013 11:30 PM, Olav Vitters wrote: On Wed, Nov 06, 2013 at 10:55:30PM +0100, Sergio Pascual wrote: Has this sanboxed-bundled-from-upstream proposal been discussed with other distributions? If the final result is that the Universal Linux Package only works in Fedora we are not gaining anything. A lot of this is being based on technology that's not really available yet such as kdbus, Wayland, systemd bits. This has been discussed at GUADEC (GNOME conference): http://www.superlectures.com/guadec2013/sandboxed-applications-for-gnome Wayland and systemd strongly suggest no Ubuntu interoperability whatsoever. Shouldn't this be a top priority for bundled applications? If we get any traction on this, their customers/users will ask them for it themselves. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F21 System Wide Change: Python 3.4
= Proposed System Wide Change: Python 3.4 = https://fedoraproject.org/wiki/Changes/Python_3.4 Change owner(s): Slavek Kabrda bkab...@redhat.com Update the Python 3 stack in Fedora from Python 3.3 to Python 3.4. == Detailed description == Python 3.4 adds numerous features and optimizations. See the upstream notes at http://www.python.org/dev/peps/pep-0429/#features-for-3-4 and http://docs.python.org/dev/whatsnew/3.4.html. == Scope == Compare with the Python 3.3 feature page [1]. We need to wait for Python 3.4 to reach feature freeze (planned for 3.4.0 beta 1: November 24, 2013), so that the bytecode format for .pyc files is frozen, together with the ABI for extension modules. At that point we can rebase python3 to the latest release candidate of that code. We would then need to rebuild all python 3 packages. See https://fedoraproject.org/wiki/Python3#Python_3_already_in_Fedora For bonus points, we ought to tell file and rpmlint about the new bytecode format for .pyc files. Note that the suffix of some files should change, and this may require slight packaging tweaks in the various packages that ship Python 3 code: * bytecode files changing from .cpython-33.pyc (and .cpython-33.pyo) to .cpython-34.pyc (and .cpython-34.pyo) * extension modules changing from .cpython-33m.so to .cpython-34m.so and .cpython-33dm.so to .cpython-34dm.so Notes about porting from Python 3.3 can be found at http://docs.python.org/dev/whatsnew/3.4.html#porting-to-python-3-4. Proposal owners: This change is isolated to Python 3 stack, which is not yet crucial for Fedora. Still, as the time of moving Fedora to Python 3 is hopefully approaching, we need to do this very cautiously. I will prepare Python 3.4 prerelease RPMs in a private repo and will do a test rebuild of all Python 3 dependent packages, filing bugs/sending patches to upstreams. This will give us a good notion of how drastic this change will be and whether or not we really want to undergo it. Overall, the change should have roughly this schedule: * After change is accepted: Start building Python 3.4 prereleases in a private repo, continuously upgrading with latest upstream prerelease versions. * November 24, 2013 (3.4.0 beta 1: feature freeze): Start rebuilding Python 3 dependent packages in the repo. * February 23, 2014 (3.4.0 final) If everything goes well (meaning that all essential packages in Fedora build and work with Python 3.4) up to this point, merge into F21. Other developers: I'll gladly accept any help with rebuilding/porting/patching/bug reporting of dependent packages as well as suggestions for Python 3.4 packaging itself. When we're sure that we really want to do the transition, it'd be great if package owners rebuilt their packages themselves. Release engineering: Nothing. Policies and guidelines: None. [1] https://fedoraproject.org/wiki/Features/Python_3.3 ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-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
F-20 Branched report: 20131107 changes
Compose started at Thu Nov 7 09:15:02 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]
Consequences of library bundling (was: Re: OpenH264 in Fedora)
On 11/06/2013 08:52 PM, Adam Jackson wrote: Again: don't stop the solution short based on what the current code happens to implement. If we're building the bundles - and there's reasons we would want to - then we know the patches we need to apply. Despite significant efforts, we still have some trouble doing precisely that in the current environment. Ensuring that critical changes are applied to all relevant branches pretty much relies on individual developer effort and attention. From a birds-eye view, we perform bundling at the distribution level. Carrying patches back and forth is not easy. We've been dealing with this for a decade or more, yet supporting technology is still scarce. This has little to do with RPM and its limitations because it's about making sure that dist-git (both Fedora and further downstream) have the required or best possible versions of the code base. At this stage, the lack of multiple RPM database, multiple versions of the same package, etc. does not come into play. There are some constraints due to the processes involved, but everyone is free to use the data that is just out there and start their own side project to tackle this problem. Yet this hasn't happened. There have been some research efforts, but nothing came out of that which actually had a chance of integration. (Other distributions face the same challenge.) That's why I'm fairly convinced that the delivery mechanism isn't holding back a solution. It's just a very difficult problem, no matter how you eventually ship your bits. -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Copr
Dear developers and Fedora contributors, let me introduce Copr: http://copr-fe.cloud.fedoraproject.org/ Copr is a build system for third party repositories. It is intended for: * upstream teams - to make nightly and test builds * layered applications - if you build on top of Fedora, but you are not part of Fedora * packages not yet ready to be included in official Fedora repositories How it works? You provide src.rpm, we will provide resulting yum repo for RHEL 5,6 and Fedora 18, 19, 20... But see WARNING on bottom of this mail. I prepared quick tutorial for you: https://fedorahosted.org/copr/wiki/ScreenshotsTutorial and FAQ: https://fedorahosted.org/copr/wiki/UserDocs#FAQ Everybody with FAS account can build there. If you want to use command line client, you should install copr-cli from updates-testing. If you have ideas, questions, comments feel free to use one of our communication channels https://fedorahosted.org/copr/#Communications (mailing list is prefered) WARNING: Please do not rely on this service in production. This is very early release (following release early, release often). First of all, this service works in simple set-up, where resulting yum repos are *not* backed up. Yet. This is not yet officially part of Fedora infrastructure, so when Copr fails, it can take several hours to be restored. And yes, our WebUI is not perfect. It's work in progress. And since Copr can build packages already, I decided to publicly announce it, so you can experiment with it. We are working on Copr on full steam and in upcoming days you can expect: * improvements in WebUI * ability to build Software Collections there -- Miroslav Suchy, RHCE, RHCDS Red Hat, Software Engineer, #brno, #devexp, #fedora-buildsys -- 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: Rawhide nodebug and the 3.12 kernel
Le Mer 6 novembre 2013 21:39, Bruno Wolff III a écrit : On Wed, Nov 06, 2013 at 12:30:37 -0800, Adam Williamson awill...@redhat.com wrote: FWIW the ship has probably sailed now, but I really don't think it'd be much of a problem to have 3.12 in F20 at release time. It's what I've been running on my F20 box here for the last several weeks anyway, and based on my testing it's unlikely to cause us any particular problems. I asked about this last week and the kernel devs didn't feel comfortable about switching after beta or trying to get a freeze exception to get 3.12 into beta. I run rawhide nodebug kernels on three machines and am not seeing any regressions relative to 3.11. I'm seeing system hangs with rawhide kernels now (oops on boot with the latest one). No idea if it's a kernel hang or just dead input, and journalctl's lack of handling of logs that were interupted by a reset is not helping -- 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: AppData questions
On 6 November 2013 23:12, Michael Schwendt mschwe...@gmail.com wrote: $ file screenshot-soundconverter.png screenshot-soundconverter.png: PNG image data, 502 x 534, 8-bit/color RGBA, non-interlaced ScreenshotSizeWidthMin=624 ScreenshotSizeHeightMin=351 503 is smaller than 624 and the screenshot is the wrong aspect ratio. The reason we need a minim width is so we avoid *scaling up* the screenshot which looks awful. Richard -- 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 questions
On 7 November 2013 08:34, Tim Lauridsen tim.laurid...@gmail.com wrote: Whould it not be a good idea to have it in a separate package, such kind of metadata should not be included with the application package IMHO The plan is to ship this with the other metadata (and downloaded by dnf/yum) long term, but at the moment the metadata is shipped with the package as we're still tweaking the metadata format and adding extractor rules. I'm hopeful for F21 we can take this out the package. Richard. -- 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: rpm macro magic help
On 07.11.2013 12:38, Michael Schwendt wrote:
On Sat, 02 Nov 2013 18:40:46 +0100, Sandro Mani wrote:
On 02.11.2013 18:18, Kevin Kofler wrote:
Hi,
Sandro Mani wrote:
%define do_build() \
mkdir build_win%{1}_%{2}; \
(cd build_win%{1}_%{2}; \
%{mingw%{1}_qmake_%{2}} 'PREFIX=%{mingw%{1}_prefix}'
'TARGET=quazip-%{2}' ../libquazip; \
%{mingw%{1}_make} %{?_smp_mflags}; \
)\
%{nil}
Ewww!
Sorry to rain on your parade, but are you sure this (and with the fix for
the nested expansion, it becomes even more ugly) is compatible with the
spec files must be legible packaging guideline?
That is a valid point. I don't know what is better,
Well, a Shell Function would be more readable, for example. It would
accept normal arguments to fill in variables -- instead of global RPM
macros, which are substituted in the entire spec file.
Uhm, how can one this be done? Shell variables are substituted after
macro expansion, so i.e.
function do_build {
arch=$1
qt_version=$2
%{mingw${arch}_qmake_${qt_version}}
}
would hardly work? Or are you suggesting passing the entire macros as
arguments? I.e.
function do_build {
qmake=$1
make=$2
${qmake} args
${make} %{?_smp_mflags}}
[...]
do_build %{mingw32_qmake_qt4} %{mingw32_make}
Sandro
--
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 Mer 6 novembre 2013 19:24, Josh Boyer a écrit : I'm just having trouble wrapping my head around the intense focus on a new app packaging technology when the entire distro is making massive changes to how it's produced. Because all distributions can and do ship the same software and the main thing that differences distributions is attention to packaging. What build the Fedora brand is in huge part the hard work of packagers over the years and careful definition of packaging guidelines. There have been many people that claimed this process was awful in the past and their alternatives all sank. Mainly because they were addressing developer problems (freedom to take all the shortcuts that make integration hard and users miserable) and thought they would win marketshare this way (hint: you do not win marketshare by solving developer problems you win marketshare by solving user problems. Users always voted with their feet and rejected the developer-friendly solutions that made their own life harder). So what makes this initiative different? I guess that's because it promotes itself as making it possible to get software in Fedora, competing with and disparaging the work of packagers while hijacking the brand they helped building. Get this thing its own name. Let it win or lose user confidence on its own merit, and don't confuse users with in Fedora claims when you're absolutely *not* offering the same thing in Fedora means now. Right now this proposal has the potential to ruin user trust and become the same thorn nvidia drivers are for xorg and kernel people now. Of course people who build this trust do not like it. Is that clearer? Regards, -- 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
[389-devel] Please review lib389 ticket 47584 (take #3): CI tests: add backup/restore of an instance
This review differs from previous with: * skip verbose option (use of log.level). * use glob.glob to retrieve files matching rather that os.walk * fix a bug in instanceBackupFS that did not return an already existing backup * add two functions to handle instance backup: clearInstanceBackupFS (to remove one or all backups of an instance), _infoInstanceBackupFS (just to keep path/pattern info of backup into a single routine) https://fedorahosted.org/389/attachment/ticket/47584/0003-Ticket-47584-CI-tests-add-backup-restore-of-an-insta.patch -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Draft Product Description for Fedora Workstation
Le Jeu 7 novembre 2013 11:17, Olav Vitters a écrit : On Thu, Nov 07, 2013 at 03:53:48AM +0100, Kevin Kofler wrote: Olav Vitters wrote: AFAIK (not sure), it should come somewhat easy once you the distribution is based upon systemd. That means it will exclude the most popular distribution out there. I fail to see the point of discussing non-Fedora distributions on Fedora devel mailing list. If you want to discuss GNOME, we also have a development list, see https://mail.gnome.org/mailman/listinfo/desktop-devel-list. A bit more logical to include people who actually work on this and less annoying to people who don't want to discuss other distributions on the Fedora mailing list. I fail to see the point of discussing non-GNOME-specific problems on a GNOME development list. A bit more logical to include people who actually work on non-GNOME software and don't want to discuss non-GNOME app distribution on a GNOME list. Really, why do I have to write this at all? Fedora Workstation is not GNOME, that has already bee written in this thread. -- 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
F21 Self Contained Change: OpenCL
= Proposed Self Contained Change: OpenCL = https://fedoraproject.org/wiki/Changes/OpenCL Change Owner(s): Fabian Deutsch fabi...@fedoraproject.org This change will bring basic OpenCL support to Fedora to support the development of OpenCL enabled software and the development of OpenCL implementations itself. The change includes enabling Mesa's OpenCL state- tracker (in 9.3 with ICD support), packaging pocl - an CPU only OpenCL implementation - and the introduction of several other OpenCL related packages. == Detailed description == The change is intended to give developers a starting point to be able to use OpenCL and to improve existing OpenCL implementations. The change will include the following sub changes: Add OpenCL implementations * Enable OpenCL state-tracker in Mesa NEW * Package pocl - CPU-only OpenCL implementation DONE * Package beignet - Intel Ivy Bridge 1 only Package implementation dependencies: * Package libclc - needed by Mesa's state-tracker DONE * Fix OpenCL path owenrship - Who owns /etc/OpenCL DONE * Review Request: opencl-filesystem - OpenCL filesystem layout - A package owning shared paths DONE Package related packages * Review Request: gocl - GLib/GObject based library for OpenCL - glib based OpenCL library DONE * Review Request: clinfo - Enumerate OpenCL platforms and devices - A tool to query informations about the available OpenCL platforms DONE * Review Request: erlang-cl - OpenCL binding for Erlang DONE * Package ViennaCL - A math library whcih can utilize CPU (OpenMP) and GPU (OpenCL/CUDA) WIP * Package pyopencl - A python library for accessing OpenCL BLOCKED BY rhbz #1002898 * Package ocltoys - A couple of OpenCL examples for testing NEW * Update existing packages if needed ** gegl (to be investigated) ** ocl-icd (done) * Potential projects to be packaged: ** Package khronos icd - probably not ** Package radeontop - To monitor a Radeon GPU (which supports OpenCL) ** Package piglit - This will be a testuite for the OpenCL implementations, has some non-fedora deps * Other stuff: ** Add a new group to comps or a opencl-dev package? ** Add virtual provides to the opencl implementations - So a app requiring opencl just needs to require the virtual package (so any provider) ** Version opencl-headers == Scope == Proposal owners: Mainly packaging Other developers: N/A (not a System Wide Change) Release engineering: N/A (not a System Wide Change) Policies and guidelines: N/A (not a System Wide Change) ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-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: AppData questions
Richard Hughes wrote: It's not mandatory, but highly reccomended. See http://people.freedesktop.org/~hughsient/appdata/#screenshots for details. A little off-topic but I was wondering: The spec states Screenshots should be taken with US English as the display language.. However the spec also defines the tag for the software license to be licence / (UK English). Is this a mistake or just a matter of habit/preference? - Felix -- 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: Copr
On Thu, 2013-11-07 at 13:54 +0100, Miroslav Suchý wrote: Dear developers and Fedora contributors, let me introduce Copr: http://copr-fe.cloud.fedoraproject.org/ Copr is a build system for third party repositories. It is intended for: * upstream teams - to make nightly and test builds * layered applications - if you build on top of Fedora, but you are not part of Fedora * packages not yet ready to be included in official Fedora repositories How it works? You provide src.rpm, we will provide resulting yum repo for RHEL 5,6 and Fedora 18, 19, 20... But see WARNING on bottom of this mail. I prepared quick tutorial for you: https://fedorahosted.org/copr/wiki/ScreenshotsTutorial and FAQ: https://fedorahosted.org/copr/wiki/UserDocs#FAQ Everybody with FAS account can build there. If you want to use command line client, you should install copr-cli from updates-testing. If you have ideas, questions, comments feel free to use one of our communication channels https://fedorahosted.org/copr/#Communications (mailing list is prefered) WARNING: Please do not rely on this service in production. This is very early release (following release early, release often). First of all, this service works in simple set-up, where resulting yum repos are *not* backed up. Yet. This is not yet officially part of Fedora infrastructure, so when Copr fails, it can take several hours to be restored. And yes, our WebUI is not perfect. It's work in progress. And since Copr can build packages already, I decided to publicly announce it, so you can experiment with it. We are working on Copr on full steam and in upcoming days you can expect: * improvements in WebUI * ability to build Software Collections there Miroslav, let me congratulate you and all the people working on Copr, this is an awesome tool that I have already used in the past for development. It makes developing changes to packages and letting other users test them very easy, thanks a lot! 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: OpenH264 in Fedora
Le Mer 6 novembre 2013 20:52, Adam Jackson a écrit : Don't throw your hands up in resignation. Write code. Fix problems. Isn't that exactly what this proposal does? People claim packaging process is broken and needs to be replaced. But they've not even identified the problem parts, nor tried to fix them, let alone shown they can not be fixed. It's a grounds-up rewrite that people who didn't even bother to understand the current process. -- 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
Broken dependencies: perl-Language-Expr
perl-Language-Expr has broken dependencies in the rawhide tree: On x86_64: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-SOAP-Lite
perl-SOAP-Lite has broken dependencies in the rawhide tree: On x86_64: perl-SOAP-Lite-0.716-3.fc20.noarch requires perl(SOAP::Transport::TCP) On i386: perl-SOAP-Lite-0.716-3.fc20.noarch requires perl(SOAP::Transport::TCP) On armhfp: perl-SOAP-Lite-0.716-3.fc20.noarch requires perl(SOAP::Transport::TCP) Please resolve this as soon as possible. -- 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: OpenH264 in Fedora
On Thu, 2013-11-07 at 14:41 +0100, Nicolas Mailhot wrote: Le Mer 6 novembre 2013 20:52, Adam Jackson a écrit : Don't throw your hands up in resignation. Write code. Fix problems. Isn't that exactly what this proposal does? People claim packaging process is broken and needs to be replaced. But they've not even identified the problem parts, nor tried to fix them, let alone shown they can not be fixed. It's a grounds-up rewrite that people who didn't even bother to understand the current process. I wouldn't make that assumption only because some people came to a conclusion you do not like. 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: Copr
Le 07/11/2013 13:54, Miroslav Suchý a écrit : Dear developers and Fedora contributors, let me introduce Copr: http://copr-fe.cloud.fedoraproject.org/ Very nice tool (from a Copr tester) Thanks a lot. Remi. -- 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 questions
On 7 November 2013 13:36, Felix Kaechele fe...@fetzig.org wrote: A little off-topic but I was wondering: The spec states Screenshots should be taken with US English as the display language.. You can actually localize the screenshots if you want; I don't know of any project that wants to do that yet. However the spec also defines the tag for the software license to be licence / (UK English). Is this a mistake or just a matter of habit/preference? It's a mistake on my part. I'm from the UK, and but I suppose it should really be license -- too late now :) Richard. -- 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 Thu, Nov 07, 2013 at 11:33:57AM +0100, Sergio Pascual wrote: 2013/11/7 Olav Vitters o...@vitters.nl On Thu, Nov 07, 2013 at 03:53:48AM +0100, Kevin Kofler wrote: Olav Vitters wrote: AFAIK (not sure), it should come somewhat easy once you the distribution is based upon systemd. That means it will exclude the most popular distribution out there. I fail to see the point of discussing non-Fedora distributions on Fedora devel mailing list. I fail to see the point of discussing a feature that is meant to allow upstreams to provide installable bundles that work in all linuxes if it is only to work in Fedora. I already talked about other distributions so your concern has been addressed already. -- 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: Draft Product Description for Fedora Workstation
On Thu, Nov 07, 2013 at 02:28:09PM +0100, Nicolas Mailhot wrote: I fail to see the point of discussing non-GNOME-specific problems on a GNOME development list. A bit more logical to include people who actually work on non-GNOME software and don't want to discuss non-GNOME app distribution on a GNOME list. As mentioned, I said the interested people are on that mailing list. Anyway, if you want to discuss another distribution on Fedora mailing list, I think it is stupid and pointless, but that is just my opinion. -- 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: Draft Product Description for Fedora Workstation
On Thu, Nov 07, 2013 at 10:45:29AM +, Frank Murphy wrote: On Thu, 7 Nov 2013 11:17:28 +0100 Olav Vitters o...@vitters.nl wrote: On Thu, Nov 07, 2013 at 03:53:48AM +0100, Kevin Kofler wrote: Olav Vitters wrote: AFAIK (not sure), it should come somewhat easy once you the distribution is based upon systemd. That means it will exclude the most popular distribution out there. I fail to see the point of discussing non-Fedora distributions on Fedora devel mailing list. If you want to discuss GNOME, we also have a development list, see https://mail.gnome.org/mailman/listinfo/desktop-devel-list. To be fair you introduced Guadec, aka Gnome developemt. (I'm not pro\anti Gnome) I explained that this thought has been discussed and introduced at a conference. If people cannot the mention of GNOME: not my problem. -- 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: Draft Product Description for Fedora Workstation
On Thu, Nov 07, 2013 at 12:58:37PM +0100, Florian Weimer wrote: On 11/06/2013 11:30 PM, Olav Vitters wrote: On Wed, Nov 06, 2013 at 10:55:30PM +0100, Sergio Pascual wrote: Has this sanboxed-bundled-from-upstream proposal been discussed with other distributions? If the final result is that the Universal Linux Package only works in Fedora we are not gaining anything. A lot of this is being based on technology that's not really available yet such as kdbus, Wayland, systemd bits. This has been discussed at GUADEC (GNOME conference): http://www.superlectures.com/guadec2013/sandboxed-applications-for-gnome Wayland and systemd strongly suggest no Ubuntu interoperability whatsoever. Shouldn't this be a top priority for bundled applications? Canonical does what Canonical wants to do. They already have their own solution for something like this. It is just very distribution specific and not as secure as what this is proposing AFAIK. -- 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: Draft Product Description for Fedora Workstation
On Thu, Nov 7, 2013 at 8:20 AM, Nicolas Mailhot nicolas.mail...@laposte.net wrote: Le Mer 6 novembre 2013 19:24, Josh Boyer a écrit : I'm just having trouble wrapping my head around the intense focus on a new app packaging technology when the entire distro is making massive changes to how it's produced. Because all distributions can and do ship the same software and the main thing that differences distributions is attention to packaging. What build the Fedora brand is in huge part the hard work of packagers over the years and careful definition of packaging guidelines. I think you missed the point of my question. It might have been too subtle. It wasn't what is wrong with sandboxed/containerized apps?. See the follow ups. There have been many people that claimed this process was awful in the past and their alternatives all sank. Mainly because they were addressing developer problems (freedom to take all the shortcuts that make integration hard and users miserable) and thought they would win marketshare this way (hint: you do not win marketshare by solving developer problems you win marketshare by solving user problems. Users always voted with their feet and rejected the developer-friendly solutions that made their own life harder). Users want apps. Developers are increasingly not caring at all about distros. I think there's a middle ground to be had here. As I've said before, just saying this is bad without even thinking about if it has some positives and how it could work just seems shortsighted. So what makes this initiative different? I guess that's because it promotes itself as making it possible to get software in Fedora, competing with and disparaging the work of packagers while hijacking the brand they helped building. Get this thing its own name. Let it win or lose user confidence on its own merit, and don't confuse users with in Fedora claims when you're absolutely *not* offering the same thing in Fedora means now. And yet, now we have Coprs. Which lets people easily upload unreviewed, possibly bundled application SRPMs for easy distribution outside of the main Fedora repos. Everyone seems to think Coprs are awesome, but they can be used for the same things you deride containerized apps for. Right now this proposal has the potential to ruin user trust and become the same thorn nvidia drivers are for xorg and kernel people now. Of course people who build this trust do not like it. Is that clearer? No. 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: OpenH264 in Fedora
Le Jeu 7 novembre 2013 14:46, Simo Sorce a écrit : On Thu, 2013-11-07 at 14:41 +0100, Nicolas Mailhot wrote: Le Mer 6 novembre 2013 20:52, Adam Jackson a écrit : Don't throw your hands up in resignation. Write code. Fix problems. Isn't that exactly what this proposal does? People claim packaging process is broken and needs to be replaced. But they've not even identified the problem parts, nor tried to fix them, let alone shown they can not be fixed. It's a grounds-up rewrite that people who didn't even bother to understand the current process. I wouldn't make that assumption only because some people came to a conclusion you do not like. I can only react to what has been published, which so far is we'll do better because you suck. I'd be delighted to see an actual analysis, based on substantiated facts and not appeals to emotion. -- 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
fedora-gooey-karma is looking for sponsor
Hi, my little utility for easier karma submitting into bodhi is looking for sponsor. Package review [1] is in progress right now. I would really appreciate any comments and sponsoring. Thank you [1] https://bugzilla.redhat.com/show_bug.cgi?id=1020839 Branislav Blaškovič www.blaskovic.sk -- 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 Jeu 7 novembre 2013 14:57, Josh Boyer a écrit : And yet, now we have Coprs. Which lets people easily upload unreviewed, possibly bundled application SRPMs for easy distribution outside of the main Fedora repos. Everyone seems to think Coprs are awesome, but they can be used for the same things you deride containerized apps for. And Coprs have their own name. So they're doing exactly what I proposed. You didn't read my message -- 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: Copr
On Thu, Nov 7, 2013 at 1:54 PM, Miroslav Suchý msu...@redhat.com wrote: Dear developers and Fedora contributors, let me introduce Copr: http://copr-fe.cloud.fedoraproject.org/ Copr is a build system for third party repositories. It is intended for: * upstream teams - to make nightly and test builds * layered applications - if you build on top of Fedora, but you are not part of Fedora * packages not yet ready to be included in official Fedora repositories How it works? You provide src.rpm, we will provide resulting yum repo for RHEL 5,6 and Fedora 18, 19, 20... But see WARNING on bottom of this mail. I prepared quick tutorial for you: https://fedorahosted.org/copr/wiki/ScreenshotsTutorial and FAQ: https://fedorahosted.org/copr/wiki/UserDocs#FAQ Everybody with FAS account can build there. If you want to use command line client, you should install copr-cli from updates-testing. If you have ideas, questions, comments feel free to use one of our communication channels https://fedorahosted.org/copr/#Communications (mailing list is prefered) WARNING: Please do not rely on this service in production. This is very early release (following release early, release often). First of all, this service works in simple set-up, where resulting yum repos are *not* backed up. Yet. This is not yet officially part of Fedora infrastructure, so when Copr fails, it can take several hours to be restored. And yes, our WebUI is not perfect. It's work in progress. And since Copr can build packages already, I decided to publicly announce it, so you can experiment with it. We are working on Copr on full steam and in upcoming days you can expect: * improvements in WebUI * ability to build Software Collections there -- Miroslav Suchy, RHCE, RHCDS Red Hat, Software Engineer, #brno, #devexp, #fedora-buildsys -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Thanks a lot, a great tool, just what i have been looking for Tim -- 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 Thu, Nov 7, 2013 at 9:10 AM, Nicolas Mailhot nicolas.mail...@laposte.net wrote: Le Jeu 7 novembre 2013 14:57, Josh Boyer a écrit : And yet, now we have Coprs. Which lets people easily upload unreviewed, possibly bundled application SRPMs for easy distribution outside of the main Fedora repos. Everyone seems to think Coprs are awesome, but they can be used for the same things you deride containerized apps for. And Coprs have their own name. So they're doing exactly what I proposed. You didn't read my message Oh, I read it. I find it odd that we can have a tool with a name (Copr) that is officially part of the Fedora project and a tool without a name (containerized apps) that doesn't even exit yet that both solve similar issues and can be used in similar ways and somehow have the name being the only thing that makes it acceptable. So if we call containerized apps Appers and host it somewhere on Fedora infrastructure and tell people about it, you'd be totally OK with that? People seem to already be jumping to conclusions that Appers are going to somehow magically be THE WAY we deliver software, but yet nobody had the same thoughts around Coprs. The blinders involved here are pretty large. These things are tools. They aren't the end-all-be-all solution to software delivery. I just wish people would calm down and stop wasting so much energy fighting against something on grounds that aren't even with existing tools and before anyone even sees what it looks like. 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
Le Jeu 7 novembre 2013 15:19, Josh Boyer a écrit : So if we call containerized apps Appers and host it somewhere on Fedora infrastructure and tell people about it, you'd be totally OK with that? I think that would remove a lot of the emotion in this thread. People seem to already be jumping to conclusions that Appers are going to somehow magically be THE WAY we deliver software, but yet nobody had the same thoughts around Coprs. Maybe that's because Coprs were never announced with huge rants about market-share and how Fedora packaging sucked and was irrelevant? The blinders involved here are pretty large. It's not blinders it's the natural reaction of people to tactless pronouncements and dismissals. I do wish the people complaining about this list focused more on technical aspects and less on hype or we-ll-decide-somewhere-else-even-though-it-concerns-you. -- 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
Peter Robinson wrote: I don't see many people forcing things through, I believe that the vast majority of contributors either like the change or aren't bothered by it. There's certainly no proof that it'll make anything worse. That doesn't mean its going to be perfect or without teething problems as the changes are made and things settle down. There's plenty of reasons why you haven't seen any negative feedback. I'll share my views on this subject since I'm in the not sure ballpark of this new process. Where's the benefit of creating a handful of workgroups that now have some sort of power over the distribution? After reading all of the emails in the past week I have yet to see any benefits of this Fedora.next process. I agree Fedora needs to continue to evolve, but this process appears to shake the foundations of Fedora. Specifics: Different kernels per product, app sandboxing (lib bundling). Will the DVD/Live ISOs currently created cease to exist F21+? Fragmentation of Fedora into Cloud/Workstation/Server products? I'm just randomly spitting out ideas in my head that come to mind, but you cannot expect that silence equates to agreement in your favor. It strikes me as odd at the large number of @redhat accounts and small number of non-@redhat accounts in favor of this new process. Who is in charge of evolving Fedora at this point? I do value Red Hat involvement, but I don't want the common myth of Fedora = Red Hat beta to become a fact. I'm still going to keep my ears open and attempt at digesting what this new idea is bringing to the table, but it hasn't sit well on my stomach so far. -- 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
Peter Robinson wrote: Just because you can't see a way to fix it doesn't mean its either unfixable or that there aren't people willing to step up to do so. It's not that I can't see a way to fix it, it's that I can see that there is no way! The whole system relies on bundling, so it is provably impossible to implement it without getting the nasty drawbacks of bundling. 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
Hi Frank, They will, although in some sense I am the wrong person to ask this question as it will be up to the people developing and packaging these DE's just like it is now. The difference from today here though will be that there will be some requirements for being available for the workstation as the PRD states. The main one here that I foresee is that you can't conflict in terms of library requirements or binary names with the standard desktop of the workstation. I don't think that has been a big problem historically so it will likely have minimal impact, but it is now going to be a formal requirement as the PRD currently stands. I expect there will be other requirements defined too, but I want to make it clear that the goals of these requirements is not to make it impossible or even hard to package alternative DEs for the workstation. But what it will mean is that for instance it will be 100% clear that the responsibility to stay available rests on the alternative DEs packagers and developers and not on the core product developers. Of course with this also comes extra responsibility of the Workstation working group to ensure that development plans are shared as early as possible, to give everyone a chance to port over in time (ref. the recent Bluez discussion). But it all comes back to what I mentioned in an earlier email. The 3 products is a attempt at moving from primarily packaging upstream projects, to having concrete independent development targets for each product and to have engineers work on those independently of upstream priorities. So in some sense when people install alternative DEs that will to some degree mean that they are no longer using the Workstation as at least a subset of the features developed and announced as the big new features of a given release will not be available simply because they where features implemented or bugs fixed in the primary desktop. That is of course not specific to the Workstation product. Christian - Original Message - From: Frank Murphy frankl...@gmail.com To: devel@lists.fedoraproject.org Sent: Thursday, November 7, 2013 4:16:58 AM Subject: Re: Draft Product Description for Fedora Workstation On Fri, 01 Nov 2013 10:24:20 -0400 Christian Fredrik Kalager Schaller cscha...@redhat.com wrote: Will the other DE's still exist after workstation Will a dev be able to use Xfce, Lxde as graphical choice. What would encourage say an xubuntu dev //* devs are still users */ working on foo, to switch to Fedora Workstation? -- 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 -- 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
Peter Robinson wrote: I don't see many people forcing things through, I believe that the vast majority of contributors either like the change or aren't bothered by it. Ah, the silent majority hypothesis, always a fun argument to bring (with no evidence whatsoever) when one is clearly losing a discussion. Can't you just admit that the consensus is AGAINST Apple-like apps? 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
Josh Boyer wrote: Everyone seems to think Coprs are awesome, but they can be used for the same things you deride containerized apps for. Please don't count me as everyone. How is Coprs a benefit? -Allows easy Fedora fragmentation. Why bother with package reviews ever again? Were Ubuntu's PPAs seen as such an advantage because they allowed every John Doe and Jane Smith to release packages put together with duct tape? I highly value Fedora's packaging guidelines and now to provide a service that does away with them is insulting. -Who is going to police it? People will attempt at uploading binary packages. (steam, NVIDIA, skype, etc) -What's this do over running mock on your local system? Anyone can generate RPMs on their own system the same way Koji/Coprs do. -- 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 Thu, Nov 7, 2013 at 10:06 AM, Kevin Kofler wrote: Peter Robinson wrote: I don't see many people forcing things through, I believe that the vast majority of contributors either like the change or aren't bothered by it. Ah, the silent majority hypothesis, always a fun argument to bring (with no evidence whatsoever) when one is clearly losing a discussion. Can't you just admit that the consensus is AGAINST Apple-like apps? You haven't established any such consensus at all. On the contrary, I see a number of people on both sides. 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 Thu, 07.11.13 03:53, Kevin Kofler (kevin.kof...@chello.at) wrote: Olav Vitters wrote: AFAIK (not sure), it should come somewhat easy once you the distribution is based upon systemd. That means it will exclude the most popular distribution out there. If you are referring to Ubuntu, then yes. But then again, they already have their own app packaging format based around .debs and AppArmor. So yeah, we might be dicks by not supporting non-systemd systems, but they were dicks first, by not supporting non-Ubuntu systems for their app images. And that's quite some consolation, no? ;-) Lennart -- Lennart Poettering, Red Hat -- 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: OpenH264 in Fedora
Hi On Thu, Nov 7, 2013 at 8:58 AM, Nicolas Mailhot wrote: I can only react to what has been published, which so far is we'll do better because you suck Where has anyone said that? 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
[389-devel] Please review: ticket 47521 Complex filter in a search request doen't work as expected.
https://fedorahosted.org/389/ticket/47521 https://fedorahosted.org/389/attachment/ticket/47521/0001-Ticket-47521-Complex-filter-in-a-search-request-doen.patch -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: EPEL Retire from maintainership duties
Sam, Message: 2 Date: Wed, 6 Nov 2013 17:23:05 -0500 (EST) From: Sam Kottler skott...@redhat.com To: EPEL Development List epel-de...@lists.fedoraproject.org Subject: Re: EPEL Retire from maintainership duties - Original Message - I'll take over nagios-plugins, nagios-plugins-check_sip, and nrpe. Can you orphan those packages so I can become the owner? -S Do you know if we should be looking for an update to Nagios 4 anywhere in the near future? I'd like to do some testing on my end before that happens to see if my setup will seamlessly handle that upgrade. Thanks, Dario -- Dario Landazuri da...@ots.utsystem.edu Senior Systems Administrator (512) 471-2427 Office of Telecommunications Services ___ epel-devel mailing list epel-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
File Fedora-Rebuild-v0.10.0.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Fedora-Rebuild: 651705dd3754fe2574843da5e67f2c52 Fedora-Rebuild-v0.10.0.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-Fedora-Rebuild/f20] 0.10.0 bump
Summary of changes: 3c67235... 0.10.0 bump (*) (*) 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-Fedora-Rebuild/f19] 0.10.0 bump
commit 347b470af7ae759736263592c0e4dba9ae67c7ce
Author: Petr Písař ppi...@redhat.com
Date: Thu Nov 7 16:46:17 2013 +0100
0.10.0 bump
.gitignore |1 +
perl-Fedora-Rebuild.spec | 32
sources |2 +-
3 files changed, 22 insertions(+), 13 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 8a6a58d..29e5646 100644
--- a/.gitignore
+++ b/.gitignore
@@ -8,3 +8,4 @@
/Fedora-Rebuild-v0.8.0.tar.gz
/Fedora-Rebuild-v0.9.0.tar.gz
/Fedora-Rebuild-v0.9.1.tar.gz
+/Fedora-Rebuild-v0.10.0.tar.gz
diff --git a/perl-Fedora-Rebuild.spec b/perl-Fedora-Rebuild.spec
index 6a078dc..8b7e3bf 100644
--- a/perl-Fedora-Rebuild.spec
+++ b/perl-Fedora-Rebuild.spec
@@ -1,24 +1,26 @@
# This file is lincensed under the terms of GPLv2+.
Name: perl-Fedora-Rebuild
-Version:0.9.1
-Release:4%{?dist}
+Version:0.10.0
+Release:1%{?dist}
Summary:Rebuilds Fedora packages from scratch
License:GPLv3+
Group: Development/Libraries
URL:http://ppisar.fedorapeople.org/Fedora-Rebuild/
Source0:
http://ppisar.fedorapeople.org/Fedora-Rebuild/Fedora-Rebuild-v%{version}.tar.gz
BuildArch: noarch
+BuildRequires: perl
BuildRequires: perl(ExtUtils::MakeMaker)
-# Tests:
-BuildRequires: perl(Config::Tiny)
-BuildRequires: perl(Data::Compare)
+# Run-time:
+BuildRequires: perl(Carp)
+BuildRequires: perl(constant)
BuildRequires: perl(Data::Dumper)
BuildRequires: perl(DateTime)
BuildRequires: perl(File::Copy)
BuildRequires: perl(File::Path)
BuildRequires: perl(File::Spec)
-BuildRequires: perl(HTTP::Daemon)
-BuildRequires: perl(HTTP::Status)
+# File::Temp not used at tests
+# HTTP::Daemon not used at tests
+# HTTP::Status not used at tests
BuildRequires: perl(IO::Handle)
BuildRequires: perl(Moose)
BuildRequires: perl(Moose::Util::TypeConstraints)
@@ -31,14 +33,18 @@ BuildRequires: perl(RPM2)
BuildRequires: perl(RPM::VersionCompare)
BuildRequires: perl(Scalar::Util)
BuildRequires: perl(Storable)
+BuildRequires: perl(strict)
BuildRequires: perl(Term::ProgressBar)
-BuildRequires: perl(Test::Simple)
BuildRequires: perl(Thread::Semaphore)
BuildRequires: perl(threads)
BuildRequires: perl(threads::shared)
BuildRequires: perl(URI)
BuildRequires: perl(version) = 0.77
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+BuildRequires: perl(warnings)
+# Tests:
+BuildRequires: perl(Data::Compare)
+BuildRequires: perl(Test::Simple)
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
Requires: fedpkg
Requires: git
Requires: koji
@@ -56,13 +62,12 @@ new interpreter.
%setup -q -n Fedora-Rebuild-v%{version}
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
+perl Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+make pure_install DESTDIR=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
@@ -76,6 +81,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Thu Nov 07 2013 Petr Pisar ppi...@redhat.com - 0.10.0-1
+- 0.10.0 bump
+
* Thu Feb 14 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.9.1-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
diff --git a/sources b/sources
index 0518a91..f161634 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-7e3a504fafde3cc77dc3d242157ed4d0 Fedora-Rebuild-v0.9.1.tar.gz
+651705dd3754fe2574843da5e67f2c52 Fedora-Rebuild-v0.10.0.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-Fedora-Rebuild/f18] 0.10.0 bump
commit 9476c47d0a44c0123fb8246f2ff406b0dc07fffa
Author: Petr Písař ppi...@redhat.com
Date: Thu Nov 7 16:46:17 2013 +0100
0.10.0 bump
.gitignore |1 +
perl-Fedora-Rebuild.spec | 32
sources |2 +-
3 files changed, 22 insertions(+), 13 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 8a6a58d..29e5646 100644
--- a/.gitignore
+++ b/.gitignore
@@ -8,3 +8,4 @@
/Fedora-Rebuild-v0.8.0.tar.gz
/Fedora-Rebuild-v0.9.0.tar.gz
/Fedora-Rebuild-v0.9.1.tar.gz
+/Fedora-Rebuild-v0.10.0.tar.gz
diff --git a/perl-Fedora-Rebuild.spec b/perl-Fedora-Rebuild.spec
index 0dd3555..fc491e3 100644
--- a/perl-Fedora-Rebuild.spec
+++ b/perl-Fedora-Rebuild.spec
@@ -1,24 +1,26 @@
# This file is lincensed under the terms of GPLv2+.
Name: perl-Fedora-Rebuild
-Version:0.9.1
-Release:3%{?dist}
+Version:0.10.0
+Release:1%{?dist}
Summary:Rebuilds Fedora packages from scratch
License:GPLv3+
Group: Development/Libraries
URL:http://ppisar.fedorapeople.org/Fedora-Rebuild/
Source0:
http://ppisar.fedorapeople.org/Fedora-Rebuild/Fedora-Rebuild-v%{version}.tar.gz
BuildArch: noarch
+BuildRequires: perl
BuildRequires: perl(ExtUtils::MakeMaker)
-# Tests:
-BuildRequires: perl(Config::Tiny)
-BuildRequires: perl(Data::Compare)
+# Run-time:
+BuildRequires: perl(Carp)
+BuildRequires: perl(constant)
BuildRequires: perl(Data::Dumper)
BuildRequires: perl(DateTime)
BuildRequires: perl(File::Copy)
BuildRequires: perl(File::Path)
BuildRequires: perl(File::Spec)
-BuildRequires: perl(HTTP::Daemon)
-BuildRequires: perl(HTTP::Status)
+# File::Temp not used at tests
+# HTTP::Daemon not used at tests
+# HTTP::Status not used at tests
BuildRequires: perl(IO::Handle)
BuildRequires: perl(Moose)
BuildRequires: perl(Moose::Util::TypeConstraints)
@@ -31,14 +33,18 @@ BuildRequires: perl(RPM2)
BuildRequires: perl(RPM::VersionCompare)
BuildRequires: perl(Scalar::Util)
BuildRequires: perl(Storable)
+BuildRequires: perl(strict)
BuildRequires: perl(Term::ProgressBar)
-BuildRequires: perl(Test::Simple)
BuildRequires: perl(Thread::Semaphore)
BuildRequires: perl(threads)
BuildRequires: perl(threads::shared)
BuildRequires: perl(URI)
BuildRequires: perl(version) = 0.77
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+BuildRequires: perl(warnings)
+# Tests:
+BuildRequires: perl(Data::Compare)
+BuildRequires: perl(Test::Simple)
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
Requires: fedpkg
Requires: git
Requires: koji
@@ -56,13 +62,12 @@ new interpreter.
%setup -q -n Fedora-Rebuild-v%{version}
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
+perl Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+make pure_install DESTDIR=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
@@ -76,6 +81,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Thu Nov 07 2013 Petr Pisar ppi...@redhat.com - 0.10.0-1
+- 0.10.0 bump
+
* Fri Jul 20 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.9.1-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
diff --git a/sources b/sources
index 0518a91..f161634 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-7e3a504fafde3cc77dc3d242157ed4d0 Fedora-Rebuild-v0.9.1.tar.gz
+651705dd3754fe2574843da5e67f2c52 Fedora-Rebuild-v0.10.0.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
introducing myself
Hello, I have recently joined the Red Hat Security Technologies Team, and will help co-maintain the gnutls and nettle packages. My primary area of focus is security and cryptography and I'm working on few such projects (e.g. gnutls). I'd also like to bring in ocserv [0], an SSL VPN server. I hope there will be someone interested in reviewing and give feedback. [0]. https://bugzilla.redhat.com/show_bug.cgi?id=1027770 Best regards, Nikos -- 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: On Thu, Nov 07, 2013 at 11:33:57AM +0100, Sergio Pascual wrote: 2013/11/7 Olav Vitters o...@vitters.nl On Thu, Nov 07, 2013 at 03:53:48AM +0100, Kevin Kofler wrote: Olav Vitters wrote: AFAIK (not sure), it should come somewhat easy once you the distribution is based upon systemd. That means it will exclude the most popular distribution out there. I fail to see the point of discussing non-Fedora distributions on Fedora devel mailing list. I fail to see the point of discussing a feature that is meant to allow upstreams to provide installable bundles that work in all linuxes if it is only to work in Fedora. I already talked about other distributions so your concern has been addressed already. But I pointed out that you are leaving out the most popular one, and you responded by labeling me as off-topic when actually YOU were the one who started talking about other distributions. You advertise distribution-independent packages, so your packages really need to work on ALL distributions. Assuming systemd is already a non- starter. IMHO, trying to support cross-distro packages is a failed endeavour from the outstart, Fedora RPMs are the way to go. 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
Summary/Minutes for Wednesday's FESCo Meeting (2013-11-06)
== #fedora-meeting: fesco == Meeting started by abadger1999 at 18:02:39 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2013-11-06/fedora-meeting.2013-11-06-18.02.log.html . Meeting summary --- * Roll Call (abadger1999, 18:02:59) * #1185 Enable -Werror=format-security by default (abadger1999, 18:04:46) * Adding to gcc's -Wall as a local Fedora patch was rejected (abadger1999, 18:08:12) * Deferred another week awaiting results of mass rebuild (abadger1999, 18:08:45) * #1192 OpenH264 as an automatic download by firefox/Statement to the ietf WebRTC working group (abadger1999, 18:08:58) * LINK: https://fedorahosted.org/fesco/ticket/1192#comment:8 (abadger1999, 18:12:45) * additional text from pjones approved (+1:7, 0:0, -1:0) (abadger1999, 18:39:05) * ACTION: abadger1999 to take care of sending the statement to the ietf. (abadger1999, 18:40:38) * #1191 Fedora 20 schedule adjustment (abadger1999, 18:42:00) * Move up the final freeze by one week passed (+1:7, 0:0, -1:1) (abadger1999, 18:51:11) * #1194 Ratify Server Working Group governance charter (abadger1999, 18:51:54) * Server working group governance charter approved (+1:8, 0:0, -1:0) (abadger1999, 18:55:37) * #1193 reboots for all updates -- are we ready for this? (abadger1999, 18:55:56) * Change owners are trusted to, _and dependent upon_, highlight all relevant changes. Not noting important changes (whether due to oversight or intentionally) breaks the Change process, and would sadly motivate FESCo to institute a more heavy-handed and higher-overhead process, which nobody wants to have. (mitr, 19:22:54) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1001335 (jreznik, 19:23:51) * mitr's proposal to update change policy passed (+1:5, 0:0, -1:1) (abadger1999, 19:40:45) * Proposal to Keep F20 behavior as-is (all offline updates for gnome). Update Change page to reflect current implementation, update docs and release notes to match. Passed (+1:5, 0:2, -1:0) (abadger1999, 19:43:30) * #1189 Stalled bug 758826 -- requesting intervention (abadger1999, 19:46:21) * twoerner working on an update. Will update the bug report. (abadger1999, 19:50:39) * Open floor (abadger1999, 19:50:45) * F21 Change Process (abadger1999, 19:51:20) * F21 Change Process is open for submissions (abadger1999, 19:52:15) * Elections (abadger1999, 19:52:23) * jreznik will send an announcement that we're seeking an Election Wrangler. (abadger1999, 19:53:56) * Next week's Chair (abadger1999, 19:54:05) * nirik to chair next week's meeting (abadger1999, 19:55:03) * Open Floor (abadger1999, 19:55:10) * Regarding the earlier discussion on OpenH264, if Fedora community members have a project in Fedora that is intending to use OpenH264 in some way, please talk to FESCo before integrating code to use it. (notting, 20:02:39) Meeting ended at 20:06:34 UTC. Action Items * abadger1999 to take care of sending the statement to the ietf. Action Items, by person --- * abadger1999 * abadger1999 to take care of sending the statement to the ietf. * **UNASSIGNED** * (none) People Present (lines said) --- * abadger1999 (159) * nirik (70) * mattdm (60) * sgallagh (57) * pjones (48) * notting (47) * mitr (46) * adamw (38) * mclasen (33) * jreznik (24) * t8m (21) * drago01 (13) * zodbot (10) * twoerner (7) * jwb (7) * mmaslano (6) * jreznik2 (2) * masta (1) * Southern_Gentlem (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- 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 Thu, 7 Nov 2013 15:45:13 +0100 Nicolas Mailhot nicolas.mail...@laposte.net wrote: ...snip... It's not blinders it's the natural reaction of people to tactless pronouncements and dismissals. I do wish the people complaining about this list focused more on technical aspects and less on hype or we-ll-decide-somewhere-else-even-though-it-concerns-you. Thats one thing that puzzles me about this thread... this is all from: Work towards a system where applications can be installed inside a container to improve security and simplify compatibility through library bundling Which basically says that the working group is going to work on that. There's actually 0 technical details on how the implemetation will work out, or even if it will. Perhaps we could move this back to productive and suggest that the working group amend their PRD to have something like: Investigate the implementation and usage for application containers and then we can discuss details when there actually are some? kevin 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
On Thu, 07 Nov 2013 09:06:43 -0600 Michael Cronenworth m...@cchtml.com wrote: Josh Boyer wrote: Everyone seems to think Coprs are awesome, but they can be used for the same things you deride containerized apps for. Please don't count me as everyone. How is Coprs a benefit? -Allows easy Fedora fragmentation. Why bother with package reviews ever again? Were Ubuntu's PPAs seen as such an advantage because they allowed every John Doe and Jane Smith to release packages put together with duct tape? I highly value Fedora's packaging guidelines and now to provide a service that does away with them is insulting. Like repos.fedorapeople.org ? How on earth do you get to 'does away with them' ? -Who is going to police it? People will attempt at uploading binary packages. (steam, NVIDIA, skype, etc) The copr maintainers? along with anyone who looks at them who wishes to report something non distributable. Just like repos.fedorapeople.org -What's this do over running mock on your local system? Anyone can generate RPMs on their own system the same way Koji/Coprs do. Sure they can. This just allows them a place to publish them and not use local computing resources to build them. kevin 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
Bastien Nocera wrote: - [Florian Weimer wrote:] - Wayland and systemd strongly suggest no Ubuntu interoperability whatsoever. Shouldn't this be a top priority for bundled applications? If we get any traction on this, their customers/users will ask them for it themselves. Hahaha, you really think you can force Canonical into adopting your technologies that way? LOL! This is going to backfire spectacularly! (My guess: Canonical will come up with their own Ubuntu App model requiring Ubuntu technologies and all the third-party developers you are trying to attract will target only that one.) 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 Thu, Nov 7, 2013 at 4:58 PM, Kevin Kofler kevin.kof...@chello.at wrote: (My guess: Canonical will come up with their own Ubuntu App model requiring Ubuntu technologies If you had read Lennart's previous reply to this thread, you'd be aware that they already did. -- 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: OpenH264 in Fedora
On 11/07/2013 02:41 PM, Nicolas Mailhot wrote: Le Mer 6 novembre 2013 20:52, Adam Jackson a écrit : Don't throw your hands up in resignation. Write code. Fix problems. Isn't that exactly what this proposal does? People claim packaging process is broken and needs to be replaced. Who? I'd agree that the packaging workflow (review, QA, release etc.) would be in need of improvements, but that's it. But they've not even identified the problem parts, nor tried to fix them, let alone shown they can not be fixed. It's a grounds-up rewrite that people who didn't even bother to understand the current process. Agreed. Ralf -- 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
Josh Boyer wrote: So if we call containerized apps Appers The name Apper is already taken! 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
unaccessability
Is / was a rather political decision to make BitchX unavailable through this app-market / Software GUI thing? Since having to yum install it, I am beginning to have a negative feeling toward the app market idea; the thought being: what else is being left out? Regards, Richard -- 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: unaccessability
It's only for GUI applications, which BitchX isn't, and if it has become a GUI application in the ten years since I last looked at it, it's probably lacking AppData files. - Original Message - Is / was a rather political decision to make BitchX unavailable through this app-market / Software GUI thing? Since having to yum install it, I am beginning to have a negative feeling toward the app market idea; the thought being: what else is being left out? Regards, Richard -- 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: unaccessability
Hi, The core principle of the installer is that it operates on an application level and not a package level. The current way it determines if something is an application is by looking for a .desktop file. So in theory you could put a bitchx.desktop file into the bitchx package and it would appear in the installer. That said I don't think it is generally a bad idea if command line/terminal applications are installed from the command line, but there is no hard policy blocking such applications from making themselves available in the installer. Christian - Original Message - From: Richard Vickery richard.vicker...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org, Community support for Fedora users us...@lists.fedoraproject.org Sent: Thursday, November 7, 2013 12:13:25 PM Subject: unaccessability Is / was a rather political decision to make BitchX unavailable through this app-market / Software GUI thing? Since having to yum install it, I am beginning to have a negative feeling toward the app market idea; the thought being: what else is being left out? Regards, Richard -- 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: OpenH264 in Fedora
Le Jeu 7 novembre 2013 16:29, Rahul Sundaram a écrit : Hi On Thu, Nov 7, 2013 at 8:58 AM, Nicolas Mailhot wrote: I can only react to what has been published, which so far is we'll do better because you suck Where has anyone said that? For example: You're proposing a continuation of the adolescent state of Linux on the Desktop with its barriers to growing the market. Yes, let's build artificial walls keeping out new users and developers who don't agree with the existing community worldview who might, duh, change the platform to meet their needs. I want upstream to control their distribution of software and not be reliant on distributions shipping this or that update It is outrageous that it's 2013 and I still have to upgrade my whole system just to get the latest LibreOffice version to name an example. The flaw IMO is within the distribution method. It takes a long time and currently there is nothing that makes it easy. Luckily there is no other method at the moment to archive that. And so on -- 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: unaccessability
Hi On Thu, Nov 7, 2013 at 12:28 PM, Christian Schaller wrote: Hi, The core principle of the installer is that it operates on an application level and not a package level. The current way it determines if something is an application is by looking for a .desktop file. So in theory you could put a bitchx.desktop file into the bitchx package and it would appear in the installer. That said I don't think it is generally a bad idea if command line/terminal applications are installed from the command line, but there is no hard policy blocking such applications from making themselves available in the installer. It might be a good idea to rethink this strategy. I don't have a problem with using yum but I am not going to fire up the installer just for gui packages and fall back to command line to install command line applications. It is a confusing approach. Perhaps instead of ignoring them entirely, you can just sort the results or having a secondary view Click here for command line applications that match your search results etc can be considered. 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: OpenH264 in Fedora
Hi On Thu, Nov 7, 2013 at 12:28 PM, Nicolas Mailhot wrote: You're proposing a continuation of the adolescent state of Linux on the Desktop with its barriers to growing the market. Yes, let's build artificial walls keeping out new users and developers who don't agree with the existing community worldview who might, duh, change the platform to meet their needs. And so on So, not an exact quote. Using quote marks in this case is confusing. I see all of this as advocacy for more than one approach. Not replacing one with another. If you want technical details, you can watch the presentation or talk to the developers involved including Lennart and Alex or wait till those details are flushed out before arguing against it. 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
[389-devel] please review: Ticket 47541 - Replication of the schema may overwrite consumer 'attributetypes' even if consumer definition is a superset
https://fedorahosted.org/389//ticket/47541 https://fedorahosted.org/389/attachment/ticket/47541/0001-Ticket-47541-Replication-of-the-schema-may-overwrite.patch -- Mark Reynolds 389 Development Team Red Hat, Inc mreyno...@redhat.com -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: unaccessability
On Thu, Nov 7, 2013 at 6:36 PM, Rahul Sundaram methe...@gmail.com wrote: Perhaps instead of ignoring them entirely, you can just sort the results or having a secondary view Click here for command line applications that match your search results etc can be considered. I guess the main obstacle here is that there isn't really a good criterion which is as clear-cut as installs a (non-NoDisplay) .desktop file = this is a user-visible gui application for gui applications - mutt certainly is a user application, sshd clearly is not, zsh ... maybe? installs an executable in PATH (no libraries, libexec helpers) and does not install a .service file (no system services) would still consider /usr/bin/X a command line application ... -- 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: unaccessability
On Thu, Nov 7, 2013 at 9:36 AM, Rahul Sundaram methe...@gmail.com wrote: Hi On Thu, Nov 7, 2013 at 12:28 PM, Christian Schaller wrote: Hi, The core principle of the installer is that it operates on an application level and not a package level. The current way it determines if something is an application is by looking for a .desktop file. So in theory you could put a bitchx.desktop file into the bitchx package and it would appear in the installer. That said I don't think it is generally a bad idea if command line/terminal applications are installed from the command line, but there is no hard policy blocking such applications from making themselves available in the installer. It might be a good idea to rethink this strategy. I don't have a problem with using yum but I am not going to fire up the installer just for gui packages and fall back to command line to install command line applications. It is a confusing approach. Perhaps instead of ignoring them entirely, you can just sort the results or having a secondary view Click here for command line applications that match your search results etc can be considered. Rahul A thought as we move into the future: if we continue with the installer, end users may one day forget about the yum command and all the awesome packages out there; they may forget about the command line altogether. Richard -- 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: unaccessability
Hi On Thu, Nov 7, 2013 at 12:56 PM, Florian Müllner fmuell...@gnome.orgwrote: I guess the main obstacle here is that there isn't really a good criterion which is as clear-cut as installs a (non-NoDisplay) .desktop file = this is a user-visible gui application for gui applications - mutt certainly is a user application, sshd clearly is not, zsh ... maybe? Why do you want to differentiate between Mutt and sshd? If a user wants to install a specific piece of software, they search for it within a gui and if it matches, they install it and move on. If you really need some way to differentiate, you can have some form of tagging via fedora tagger or appdata which you can include in more than just gui packages. When I want some software, say Epiphany and Mutt, if I can only use the installer for the Epiphany but I have to use yum for Mutt, I rather just use yum for both where I don't have to switch between two different ways of getting it. I don't mind the focus on gui applications but leaving out command line tools altogether forces me to think about whether say htop would be considered a application by the installer or not which is not the level I want to differentiate at all. When I search for something within the installer and it returns nothing, is it because there is genuinely nothing that matches what I want within the repositories or is the installer just excluding it based on implementation level details like desktop files and appdata? How would I know? It is just too complex. 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: rpm macro magic help
Hi Sandro,
On 07.11.2013 15:10, Sandro Mani wrote:
Uhm, how can one this be done? Shell variables are substituted after
macro expansion, so i.e.
function do_build {
arch=$1
qt_version=$2
%{mingw${arch}_qmake_${qt_version}}
}
would hardly work? Or are you suggesting passing the entire macros as
arguments? I.e.
function do_build {
qmake=$1
make=$2
${qmake} args
${make} %{?_smp_mflags}}
[...]
do_build %{mingw32_qmake_qt4} %{mingw32_make}
For some time I am looking for a reason to test the Lua RPM feature:
http://rpm.org/wiki/PackagerDocs/RpmLua
Can you point me to the .spec in the question and a few more words which
is the desired result.
Kind Regards,
Alek
--
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 Thu, Nov 7, 2013 at 4:15 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Thu, 07.11.13 03:53, Kevin Kofler (kevin.kof...@chello.at) wrote: Olav Vitters wrote: AFAIK (not sure), it should come somewhat easy once you the distribution is based upon systemd. That means it will exclude the most popular distribution out there. If you are referring to Ubuntu, then yes. But then again, they already have their own app packaging format based around .debs and AppArmor. So yeah, we might be dicks by not supporting non-systemd systems, but they were dicks first, by not supporting non-Ubuntu systems for their app images. And that's quite some consolation, no? ;-) No, calling each other dicks is overall not at all consoling. Is there a technical reason why we can't use their packaging format, interpreting it with our technologies but staying compatible? 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 Product Description for Fedora Workstation
On 11/05/2013 10:33 PM, Adam Williamson wrote: 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 :) All I was asking for is the status quo. 3rd party repositories must be installed manually, but once they are installed automated codec installation should work. -- 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: unaccessability
Rahul Sundaram (methe...@gmail.com) said: I guess the main obstacle here is that there isn't really a good criterion which is as clear-cut as installs a (non-NoDisplay) .desktop file = this is a user-visible gui application for gui applications - mutt certainly is a user application, sshd clearly is not, zsh ... maybe? Why do you want to differentiate between Mutt and sshd? Because the purpose it was designed for was to install *applications*. sshd is not an application, at least not in the terms that the software was designed to handle. Bill -- 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: unaccessability
Well the installer is work in progress and there are a lot of features missing still, and there are still questions that we need to figure out the answer to in terms of installing various things. We are trying to nail down the core design first before adding support for 'everything', but there will be the need for a .desktop file and an appdata file for anything that wants to be in. Maybe long term we want to filter terminal applications into a separate 'tab' or similar, but regardless of long term presentation if you maintain a package with a terminal application and want it to show up in the installer the solution is to create a .desktop file and a appdata file for it. Christian - Original Message - From: Rahul Sundaram methe...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Thursday, November 7, 2013 1:09:19 PM Subject: Re: unaccessability Hi On Thu, Nov 7, 2013 at 12:56 PM, Florian Müllner fmuell...@gnome.org wrote: I guess the main obstacle here is that there isn't really a good criterion which is as clear-cut as installs a (non-NoDisplay) .desktop file = this is a user-visible gui application for gui applications - mutt certainly is a user application, sshd clearly is not, zsh ... maybe? Why do you want to differentiate between Mutt and sshd? If a user wants to install a specific piece of software, they search for it within a gui and if it matches, they install it and move on. If you really need some way to differentiate, you can have some form of tagging via fedora tagger or appdata which you can include in more than just gui packages. When I want some software, say Epiphany and Mutt, if I can only use the installer for the Epiphany but I have to use yum for Mutt, I rather just use yum for both where I don't have to switch between two different ways of getting it. I don't mind the focus on gui applications but leaving out command line tools altogether forces me to think about whether say htop would be considered a application by the installer or not which is not the level I want to differentiate at all. When I search for something within the installer and it returns nothing, is it because there is genuinely nothing that matches what I want within the repositories or is the installer just excluding it based on implementation level details like desktop files and appdata? How would I know? It is just too complex. 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 -- 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: unaccessability
Richard Vickery (richard.vicker...@gmail.com) said: A thought as we move into the future: if we continue with the installer, end users may one day forget about the yum command and all the awesome packages out there; they may forget about the command line altogether. We've been shipping a graphical package install tool since before we shipped yum. (As awesome as glint and glitter were) I, for one, am not going to worry about this particular slippery slope. Bill -- 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 status is Go, ongoing release schedule adjustments!
At the Fedora 20 Beta Go/No-Go Meeting that just occurred, it was agreed to Go with the Fedora 20 Beta by Fedora QA and Fedora Development (with silent approval from me ;-). Fedora 20 Beta will be publicly available on Tuesday, November 12, 2013. !!!Schedule adjustment!!! Due to possible collision with holidays, FESCo approved [1] one week shorter Beta to Final period with Final Change Deadline on Nov 26. Be aware of this change and queue your updates on time! Many thanks to everyone who helped with this release and fixing all (heisen)bugs! Meeting details can be seen here: Minutes: http://bit.ly/1dQmqdr Log: http://bit.ly/1bdSrZ3 Jaroslav ___ 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
Kevin Fenzi wrote: Like repos.fedorapeople.org ? I don't have a beef with r.f.o. They're no different from hosting a repo on a personal server. The top of the root page even contains a disclaimer. How on earth do you get to 'does away with them' ? It's a Fedora infrastructure server building non-Fedora packages. Why is it considered part of Fedora? Plus there is no disclaimer. The copr maintainers? along with anyone who looks at them who wishes to report something non distributable. Just like repos.fedorapeople.org Good. I see that feature. Sure they can. This just allows them a place to publish them and not use local computing resources to build them. I don't have anything wrong with creating a useful service if it respects Fedora's principles. -- 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: unaccessability
Hi On Thu, Nov 7, 2013 at 2:39 PM, Christian Schaller wrote: Maybe long term we want to filter terminal applications into a separate 'tab' or similar, but regardless of long term presentation if you maintain a package with a terminal application and want it to show up in the installer the solution is to create a .desktop file and a appdata file for it. Fair enough but if you want all the applications (including command line ones) to include a appdata and desktop file, you would need a lot more time to get package maintainers and upstream to do that and filtering apps based on appdata for Fedora 21 would be premature until there is a public roadmap that gives enough time to get everyone on board. Thanks! 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 Thu, Nov 07, 2013 at 08:57:06AM -0700, Kevin Fenzi wrote: Which basically says that the working group is going to work on that. There's actually 0 technical details on how the implemetation will work out, or even if it will. http://www.superlectures.com/guadec2013/sandboxed-applications-for-gnome So there have been lots of thought and work going into this. But maybe more needs to be written down in the proposal as you mentioned. -- 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
