Re: f21 Mass rebuild, freeze, and other status

2014-08-20 Thread Dan Horák 
On Wed, 20 Aug 2014 17:27:39 -0600
Kevin Fenzi  wrote:

> Just thought I would drop a quick note to the list about the status of
> various things, at least as I know them. ;) 
> 
> First, astute readers will note that we were scheduled to go into
> freeze for f21 yesterday and that we didn't do so. This was discussed
> at the FESCo meeting today and we decided to go into Alpha freeze the
> day after we have a viable Test Compose for f21. Going into freeze
> before we have that would make it harder to get there, and just
> slipping a week for freeze might not be needed. 
> 
> The recent mass rebuild for glibc/gcc fixes finished monday. However,
> it was discovered that there was a rpm bug present for the last ~1300
> or so builds in the mass rebuild. This bug would cause packages that
> override provides/requires to just not add their requires at all. 
> https://bugzilla.redhat.com/show_bug.cgi?id=1131892
> I have just finished scraping the logs for those ~1300 f21 builds and
> identified the packages affected. I will be rebuilding them in f21 and
> rawhide. Happily it isn't too many packages. Packages outside of the
> mass rebuild may also be affected, maintainers are advised to
> doublecheck their build.log if they override provides/requires and
> built anything the last few days. 

the fix is in rpm-4.12.0-0.beta1.4.fc22 if I see correctly, but what
are the broken rpm versions? I would like to skip them on secondary
arches. We don't have replicate also all the bugs :-)


Dan
-- 
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: Mono3.4 in Fedora 21, or troll?

2014-08-20 Thread Christopher Meng 
I haven't seen any efforts from Claudio or whosoever to rebuild all
mono packages (it's a MUST as Mono is not a _small_ package, he could
use koji or his personal computer to do that) and feedback the results
(most of status from the change page are "Need Test", I think it's
nonsense and ridiculous), and I didn't see at least 1 ownership of him
in pkgdb (it's not petty). Looks like getting sponsored is quite easy,
one requested a incomplete feature and when we are close to the freeze
one said he "need help to be a packager".

I don't want to see that mono is updated with a version bump only,
that doesn't make sense to me, because there is no tests, no
preliminaries, only a page with full of TODO items.

Nevertheless, I still want to tell you that the latest Mono is 3.6.
You should use 3.6 instead of 3.4 to avoid the crap:

https://bugzilla.xamarin.com/show_bug.cgi?id=18690

Next time I hope you can step in with a detailed plan/schedule. You
were too hasty IMO.

Yours sincerely,
Christopher Meng

http://cicku.me
-- 
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: build failures on rawhide [PATCH]

2014-08-20 Thread Zbigniew Jędrzejewski-Szmek 
On Wed, Aug 20, 2014 at 08:33:55PM -0500, Jerry Vonau wrote:
> Hi All:
> 
> I'd like to point out that there are images/livecd's that are failing to
> build for rawhide[1]. With the change in /etc/resolv.conf handling the
> builds are now failing with "IOError: [Errno 2] No such file or directory:
> '/var/tmp/imgcreate-ChCMoB/install_root/etc/resolv.conf'" Looking the code
> in python-ingcreate[3] it appears that /etc/resolv.conf is opened,
> permissions changed, then closed. Think the sequence should be open, close,
> change permissions, or can that block of code go away? At any rate patch to
> reverse the order.
> 
> diff --git a/imgcreate/kickstart.py b/imgcreate/kickstart.py
> index aef3ef2..b87fd59 100644
> --- a/imgcreate/kickstart.py
> +++ b/imgcreate/kickstart.py
> @@ -441,8 +441,8 @@ class SelinuxConfig(KickstartConfig):
>          for fn in ("/etc/resolv.conf",):
>              path = self.path(fn)
>              f = file(path, "w+")
> -            os.chmod(path, 0644)
>              f.close()
> +            os.chmod(path, 0644)
The order does not matter here.

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

build failures on rawhide [PATCH]

2014-08-20 Thread Jerry Vonau 
Hi All:

I'd like to point out that there are images/livecd's that are failing to
build for rawhide[1]. With the change in /etc/resolv.conf handling the
builds are now failing with "IOError: [Errno 2] No such file or directory:
'/var/tmp/imgcreate-ChCMoB/install_root/etc/resolv.conf'" Looking the code
in python-ingcreate[3] it appears that /etc/resolv.conf is opened,
permissions changed, then closed. Think the sequence should be open, close,
change permissions, or can that block of code go away? At any rate patch to
reverse the order.

diff --git a/imgcreate/kickstart.py b/imgcreate/kickstart.py
index aef3ef2..b87fd59 100644
--- a/imgcreate/kickstart.py
+++ b/imgcreate/kickstart.py
@@ -441,8 +441,8 @@ class SelinuxConfig(KickstartConfig):
         for fn in ("/etc/resolv.conf",):
             path = self.path(fn)
             f = file(path, "w+")
-            os.chmod(path, 0644)
             f.close()
+            os.chmod(path, 0644)
 
         if ksselinux.selinux == ksconstants.SELINUX_DISABLED:
             return



Jerry


1. https://apps.fedoraproject.org/releng-dash/
2. https://kojipkgs.fedoraproject.org//work/tasks/970/7430970/root.log
3. https://git.fedorahosted.org/cgit/livecd/tree/imgcreate/kickstart.py
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

taking python-elixir (was Re: Some orphaned packages)

2014-08-20 Thread Dan Callaghan 
Excerpts from Toshio Kuratomi's message of 2014-08-15 03:01 +10:00:
> python-elixir => (orphan Fedora devel, Fedora 21, Fedora 20, Fedora 
> 19, Fedora EPEL 5)

I will take this one, in order to keep the TurboGears1 stack alive. If 
anyone is actually using it, or is interested in helping maintain it, 
please get in touch with me.

-- 
Dan Callaghan 
Software Engineer, Hosted & Shared Services
Red Hat, Inc.


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

f21 Mass rebuild, freeze, and other status

2014-08-20 Thread Kevin Fenzi 
Just thought I would drop a quick note to the list about the status of
various things, at least as I know them. ;) 

First, astute readers will note that we were scheduled to go into
freeze for f21 yesterday and that we didn't do so. This was discussed
at the FESCo meeting today and we decided to go into Alpha freeze the
day after we have a viable Test Compose for f21. Going into freeze
before we have that would make it harder to get there, and just
slipping a week for freeze might not be needed. 

The recent mass rebuild for glibc/gcc fixes finished monday. However,
it was discovered that there was a rpm bug present for the last ~1300 or
so builds in the mass rebuild. This bug would cause packages that
override provides/requires to just not add their requires at all. 
https://bugzilla.redhat.com/show_bug.cgi?id=1131892
I have just finished scraping the logs for those ~1300 f21 builds and
identified the packages affected. I will be rebuilding them in f21 and
rawhide. Happily it isn't too many packages. Packages outside of the
mass rebuild may also be affected, maintainers are advised to
doublecheck their build.log if they override provides/requires and
built anything the last few days. 

The mass rebuild has been tagged into f21 and rawhide and should appear
in composes tomorrow. This means lots of packages will appear as
updates for everyone. 

Due to all the signing of new f21 and rawhide packages, it's been hard
to get everything signed for updates pushes, however, there are some
going finally now. Should land later tonight. 

Releng is hard at work today to get a TC built. Hopefully we will have
one soon and can then enter F21 Alpha Freeze. 

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: Mono3.4 in Fedora 21, or troll?

2014-08-20 Thread Christopher Meng 
On Aug 21, 2014 2:09 AM, "Dan Horák"  wrote:
> please be aware that updating the mono packages is only first step, the
> maintainer should put reasonable effort into ensuring the rest of the
> mono stack also builds after such major rebase

That's what I'm concerned about.
-- 
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 from today's FESCo Meeting (2014-08-20)

2014-08-20 Thread Tomas Hozza 
===
#fedora-meeting: FESCO (2014-08-20)
===


Meeting started by thozza at 17:04:28 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting/2014-08-20/fesco.2014-08-20-17.04.log.html
.



Meeting summary
---
* init process  (thozza, 17:04:48)

* #1178 Fedora 21 scheduling strategy  (thozza, 17:08:36)
  * AGREED: Go into freeze the day after we have a usable TC. revisit
schedule next meeting to see if we need to adjust/delay/change
anything. (+6)  (thozza, 17:24:56)
  * ACTION: dgilmore will send the heads-up on devel list once we have
TC (day before freeze)  (thozza, 17:25:24)

* #1322 F21 Changes - Progress on Changes Freeze  (thozza, 17:25:43)
  * ACTION: thozza will update the ticket asking for update on Changes
progress  (thozza, 17:28:58)

* #1330 F22 System Wide Change: Perl 5.20 -
  https://fedoraproject.org/wiki/Changes/perl5.20  (thozza, 17:29:12)
  * AGREED: F22 System Wide Change: Perl 5.20 has been approved (+6)
(thozza, 17:34:42)

* #1331 The package pipelight violates Fedora guidelines regarding
  (thozza, 17:34:56)
  * ACTION: sgallagh to discuss proper review policy with the approver.
(sgallagh, 17:38:46)

* #1332 F22 retire orphan packags after 4 weeks instead of once per
  release  (thozza, 17:53:22)
  * ACTION: sgallagh to talk to maintainer as well (previous topic)
(sgallagh, 17:53:45)
  * ACTION: thozza ask reporter to move the discussion to the devel list
(thozza, 18:04:37)

* #1333 OpenJDK maintainer refuses to address F20->F21 upgrade bug once
  per release  (thozza, 18:04:48)
  * LINK:

https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#To_Fedora_21_pre-release
should work  (kalev, 18:14:57)
  * AGREED: Ask jvanek to make f20->f21 upgrades result in a working
system, reasonably similar to a clean f21 install. FESCo declares BZ
1130247 to be a blocker for F21 Beta. (+6)  (thozza, 18:19:57)

* Next week's chair  (thozza, 18:20:34)
  * nirik to chair next week’s meeting  (thozza, 18:23:56)

* Open Floor  (thozza, 18:24:11)

Meeting ended at 18:32:41 UTC.




Action Items

* dgilmore will send the heads-up on devel list once we have TC (day
  before freeze)
* thozza will update the ticket asking for update on Changes progress
* sgallagh to discuss proper review policy with the approver.
* sgallagh to talk to maintainer as well (previous topic)
* thozza ask reporter to move the discussion to the devel list




Action Items, by person
---
* dgilmore
  * dgilmore will send the heads-up on devel list once we have TC (day
before freeze)
* sgallagh
  * sgallagh to discuss proper review policy with the approver.
  * sgallagh to talk to maintainer as well (previous topic)
* thozza
  * thozza will update the ticket asking for update on Changes progress
  * thozza ask reporter to move the discussion to the devel list
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* thozza (59)
* nirik (47)
* sgallagh (45)
* jvanek (32)
* mitr (28)
* kalev (27)
* jwb (10)
* dgilmore (7)
* zodbot (5)
* mmaslano (0)
* mattdm (0)
* t8m (0)




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: Mono3.4 in Fedora 21, or troll?

2014-08-20 Thread Ismael Olea 
On Wed, Aug 20, 2014 at 7:38 PM, Claudio Rodrigo 
wrote:

> I need help to became packager, I talk with Xavier Lamien to sponsor me.
> But he is busy.
> I want see mono 3.4 in fedora officially. It is a great goal.
> Additional I was father last week.
>

Congratulations!!!


> Anyone who want help to complete this proposal, will be welcome.
>

I tried to do the formal review for hamekoz-tiempos but last spec didn't
build to me: https://bugzilla.redhat.com/show_bug.cgi?id=1084190#c14

I'm still open to do this.
-- 

Ismael Olea

http://olea.org/diario/
-- 
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: Mono3.4 in Fedora 21, or troll?

2014-08-20 Thread Dan Horák 
On Wed, 20 Aug 2014 14:38:09 -0300
Claudio Rodrigo  wrote:

> I need help to became packager, I talk with Xavier Lamien to sponsor
> me. But he is busy.
> I want see mono 3.4 in fedora officially. It is a great goal.
> Additional I was father last week.
> 
> If someone sponsor my first package I will glade to push mono 3.4
> Anyone who want help to complete this proposal, will be welcome.

please be aware that updating the mono packages is only first step, the
maintainer should put reasonable effort into ensuring the rest of the
mono stack also builds after such major rebase

[dan@eagle ~]$ repoquery --repoid=rawhide-source --arch=src --whatrequires 
mono-devel avahi-0:0.6.31-28.fc22.src
banshee-0:2.6.2-5.fc22.src
banshee-community-extensions-0:2.4.0-8.fc21.src
bareftp-0:0.3.9-7.fc21.src bless-0:0.6.0-13.fc21.src
boo-0:0.9.4.9-9.fc21.src
cdcollect-0:0.6.0-20.fc21.src
dbus-sharp-1:0.7.0-10.fc21.src
dbus-sharp-glib-0:0.5.0-8.fc21.src
docky-0:2.2.0-3.fc21.src
f-spot-0:0.8.2-12.fc21.src
flickrnet-0:2.2-15.fc21.src
gdata-sharp-0:1.4.0.2-12.fc21.src
gecko-sharp2-0:0.13-25.fc21.src
gio-sharp-0:0.3-9.fc21.src
gkeyfile-sharp-0:0.1-14.fc21.src
gmime-0:2.6.20-3.fc22.src
gnome-desktop-sharp-0:2.26.0-22.fc21.src
gnome-do-0:0.95.1-2.fc21.src
gnome-do-plugins-0:0.8.5-2.fc21.src
gnome-guitar-0:0.8.1-15.fc21.src
gnome-keyring-sharp-0:1.0.1-0.16.133722svn.fc21.src
gnome-rdp-0:0.3.1.0-8.fc22.src
gnome-sharp-0:2.24.2-5.fc21.src
gnome-subtitles-0:1.3-3.fc21.src
gsf-sharp-0:0.8.1-21.fc21.src
gtk-sharp-beans-0:2.14.0-12.fc21.src
gtk-sharp2-0:2.12.11-11.fc21.src
gtksourceview-sharp-0:2.0.12-20.fc21.src
gudev-sharp-0:0.1-13.fc21.src
hyena-0:0.5-8.fc21.src
ice-0:3.5.1-4.fc21.src
keepass-0:2.26-9.fc21.src
libappindicator-0:12.10.0-5.fc22.src
libgpod-0:0.8.3-4.fc21.src
log4net-0:1.2.13-2.fc21.src
mono-addins-0:0.6.2-10.fc21.src
mono-basic-0:2.10-7.fc20.src
mono-bouncycastle-0:1.7-7.fc21.src
mono-cecil-flowanalysis-0:0.1-0.21.20110512svn100264.fc21.src
mono-debugger-0:2.10-8.fc21.src
mono-reflection-0:0.1-0.8.20110613git304d1d.fc21.src
mono-tools-0:2.10-11.fc22.src
mono-zeroconf-0:0.9.0-12.fc21.src
monodevelop-0:2.8.8.4-6.fc21.src
monodevelop-debugger-gdb-0:2.8.8.4-5.fc21.src
monodevelop-vala-0:2.8.8.1-6.fc21.src
nant-1:0.90-15.fc21.src
ndesk-dbus-0:0.6.1a-16.fc21.src
ndesk-dbus-glib-0:0.4.1-17.fc21.src
nini-0:1.1.0-5.fc21.src
notify-sharp-0:0.4.0-0.22.20100411svn.fc21.src
pdfmod-0:0.9.1-8.fc21.src
pinta-0:1.4-2.fc19.src
poppler-sharp-0:0.0.3-6.fc21.src
sparkleshare-0:1.1.0-5.fc22.src
taglib-sharp-0:2.0.3.7-10.fc21.src
taoframework-0:2.1.0-14.fc21.src
themonospot-base-0:0.8.2-12.fc21.src
themonospot-console-0:0.1.1-11.fc21.src
themonospot-gui-gtk-0:0.2.2-12.fc21.src
themonospot-gui-qt-0:0.1.3-15.fc21.src
themonospot-plugin-avi-0:0.1.1-11.fc21.src
themonospot-plugin-mkv-0:0.1.1-11.fc21.src
thrift-0:0.9.1-13.fc21.src
webkit-sharp-0:0.3-12.fc21.src
xsp-0:2.10.2-7.fc21.src


Dan

 
> 
> 2014-08-20 14:19 GMT-03:00 Ismael Olea :
> 
> >
> >
> >
> > On Wed, Aug 20, 2014 at 12:54 PM, Christopher Meng
> >  wrote:
> >
> >> Hi,
> >>
> >> Can someone tell me the status of the mono 3.4 proposal? I
> >> contacted chkr last year and he said it's a big task. He didn't
> >> say anything about the feature although the mono package is
> >> obsolete already. And I don't know why 3.4 was proposed by a
> >> stranger this year again(someone is not even a packager yet with
> >> no communication to the development).
> >>
> > Claudio did it because he was interested and anybody more was too.
> >
> > He maintains a copr repo:
> >
> >- http://copr.fedoraproject.org/coprs/elsupergomez/mono/
> >- https://fedoraproject.org/wiki/Changes/Mono_3.4
> >
> >
> > I should have helped him but I couldn't plan the needed time. My
> > fault.
> >
> >
> > --
> >
> > Ismael Olea
> >
> > http://olea.org/diario/
> >
> 
> 
> 
> -- 
> --
> Claudio Rodrigo Pereyra Diaz
> Ingeniero en Informática
-- 
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: Mono3.4 in Fedora 21, or troll?

2014-08-20 Thread Ismael Olea 
On Wed, Aug 20, 2014 at 12:54 PM, Christopher Meng 
wrote:

> Hi,
>
> Can someone tell me the status of the mono 3.4 proposal? I contacted chkr
> last year and he said it's a big task. He didn't say anything about the
> feature although the mono package is obsolete already. And I don't know why
> 3.4 was proposed by a stranger this year again(someone is not even a
> packager yet with no communication to the development).
>
Claudio did it because he was interested and anybody more was too.

He maintains a copr repo:

   - http://copr.fedoraproject.org/coprs/elsupergomez/mono/
   - https://fedoraproject.org/wiki/Changes/Mono_3.4


I should have helped him but I couldn't plan the needed time. My fault.


-- 

Ismael Olea

http://olea.org/diario/
-- 
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: FESCo #1263 question (optional javadocs)

2014-08-20 Thread Christopher 
As a hypothetical, I was mainly concerned about backporting a new F21 java
package as a F20 update to make it available to users still on that
version, and whether that would require javadocs. Just in case, I've added
a "%if 0%{fedora} < 21" condition for javadocs, and the appropriate
Obsoletes line when the condition fails (>=20), but that's more to maintain
in the specfile, and it'd be much simpler to just not declare any
subpackaging for javadocs.


--
Christopher L Tubbs II
http://gravatar.com/ctubbsii


On Wed, Aug 20, 2014 at 8:29 AM, Miloslav Trmač  wrote:

> Hello,
>
> Regarding https://fedorahosted.org/fesco/ticket/1263
>
> Does this policy change affect updates to older releases still receiving
> updates? Or only F21 and later?
>
> It has been approved as a F21 Change, so it should affect only F≥21.
> Technically, the packaging guideline change is somewhat independent from
> the Change process; I’d argue that updates to existing F≤20 packages should
> not remove functionality, though.
> 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
>
-- 
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: D-Bus RPM Provides?

2014-08-20 Thread Richard Hughes 
On 20 August 2014 14:59, Adam Jackson  wrote:
> I think it would be worthwhile, yes.  The question of how to enumerate
> the dbus services in the OS has come up before, and it's lame that we
> don't try to track it.

This is something I needed to do for the AppStream metadata; code
available here:
https://github.com/hughsie/appstream-glib/blob/master/libappstream-builder/plugins/asb-plugin-dbus.c

I'm sure it would be pretty easy to put that in rpm somewhere.

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: Schedule for Wednesday's FESCo Meeting (2014-08-20)

2014-08-20 Thread Matthew Miller 
I'm afraid I'm likely to miss this one too -- lots of crazy busy stuff going
on _in addition_ to the expected insanity of being at LinuxCon. :)

-- 
Matthew Miller

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

Re: appdata questions

2014-08-20 Thread Michael Catanzaro 
On Wed, 2014-08-20 at 15:42 +0200, Karel Volný wrote:
> why do we penalize users by hiding contents from them when some
> upstream 
> just doesn't care about this stuff? (see also comment 7 about the
> "unjust 
> burden")?

To clarify, the goal is not to penalize users: quite the opposite. We
want applications in the software installer to have good descriptions
and screenshots to help the user decide if he wants to install the
application. The status quo in F20 is that many apps have just a
sentence fragment of description taken from the desktop file, which is
not very helpful to users and makes our software center look bad. Hiding
applications without good descriptions will improve the quality of 
the results we show, and also encourage Fedora packagers to add the
descriptions. (If upstream doesn't want to add an appdata file, you can
do so in your packaging!)

Michael


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

Re: appdata questions

2014-08-20 Thread Richard Hughes 
On 20 August 2014 14:42, Karel Volný  wrote:
> 1) Why not to take the information from the .desktop file by default and use
> appdata.xml only if the author/packager wants to provide additional
> information that cannot be in the .desktop file?

That's what we do. Some data can't go in the .desktop file, as you
can't put 5 localized screenshot URLs, with captions into an ini-style
document without it looking crazy, and multi-paragraph text with lists
is also as hard to do. You also might want different "names" for
applications shown locally (e.g. "Web") than in the software center
(e.g. "Epiphany"). This is why we read the values in the AppData file,
and then fall back to the .desktop files.

> 2) What is it good for to install appdata.xml into %{_datadir}/appdata/ when
> the installer (Apper, GNOME Software) takes the information from
> /usr/share/app-info/xmls so the files in /usr/share/appdata/ will lay on
> end-users' systems completely unused?

This is for four reasons:

* For distros not shipping AppStream metadata at all yet, e.g. Ubuntu
* For applications that have been installed locally, but from a repo
that doesn't support AppStream, e.g. Chrome or Steam could do this in
the future.
* You need to install the file to the filesystem so that it's present
in the correct binary package
* You might have installed a different version of an application to
what the metadata was built against, e.g. installing F22 packages in
an F21 system.

> 3) Almost the same goes for icons, if appstream-data will copy icons to
> /usr/share/app-info/icons, why to have two copies of the same image?

The AppStream ones are pre-resized, optimised and padded to 64x64 PNG
format, as processing lots of .svgs or large PNGs takes a lng time
to render when we start the session installer. We also might want to
ship a different icon in the software center to the installed version.
The bigger problem is you'd have to hardlink things in /usr when
installing, which really isn't a good idea at all just to save a few
tens of kb's.

> why do we penalize users by hiding contents from them when some upstream
> just doesn't care about this stuff? (see also comment 7 about the "unjust
> burden")?

We have both a carrot and a stick. The carrot is that if you ship high
quality translated descriptions, keywords and screenshots with the
correct aspect ratio you get included higher up in the search results.
The stick is that applications that are really bad or that are dead
upstream don't show. They'll still show up in the "installed" view if
you install them on the command line, we just don't make them easy to
install. I'm intending to keep raising the bar for applications in the
next few years, and at the moment the bar is set so very low.

> 5) If there is a trend to split localised information into separate
> langpacks, why to mix all locales into one file, not allowing any split?

We're not doing anything with langpacks. The only time languages comes
into the story is when the metadata gets built we decompress the
application and any packages it requires from the same srpm and then
run some tools to find out what locales are included in the
application so we can suggest applications higher that are available
in the users locale. In the software center, installing inkscape
should probably just install all languages, and I'm hoping to use the
new soft-dependencies feature of rpm to achieve this. If you install
it on the command line, you can choose just the language packs you
want, but for the saving of a few Mb it's not something I wanted to
clog up the UI for. If the language packs are huge and that important,
I guess you could use metainfo files to install them as addons, just
like we're doing with eclipse extensions and browser plugins, but
that's not something I'm super interested in.

> Also, no localised screenshots allowed - "Screenshots should be taken with
> US English as the display language." - even if they could be tagged with
> language code too?

You can take localised screenshots and tag them with the right
language code, but at the moment we just ignore them in the extractor.
There's exactly one application in the whole of F21 that has localised
screenshots (in just two languages) but it's an open feature request
in libappstream-glib to support this better. At the moment it's an
uphill battle getting upstreams to take screenshots, and I didn't want
the message to be "take them in any language you like". Realistically,
we need automated screenshot capture to be a reality before we can
advertise "localized screenshots" as a feature.

> 6) If we copy the screenshots, why not to provide them also in an optional
> package?

Why? What use would they be when you've installed the application? We
already mirror them to the mirror network, and we cache them locally.

> I've heard there are still some people who don't have Internet connection
> and install Fedora from DVD (do we still allow to install more packages from
> DVD after t

Re: D-Bus RPM Provides?

2014-08-20 Thread Adam Jackson 
On Wed, 2014-08-20 at 13:04 +, Petr Pisar wrote:

> I discovered that many org.freedesktop.Notifications server packages
> provide `desktop-notification-daemon' RPM symbol. I think it would be
> much better if the dependency was expressed as, e.g.,
> `dbus(org.freedesktop.Notifications)'. It would be more generic and it
> would allow to express the dependencies not only for desktop
> notificiations servers. The Provides symbols could be generated by
> rpm-build scripts from the D-Bus service definition files.
> 
> Is this idea worth for pursuing?

I think it would be worthwhile, yes.  The question of how to enumerate
the dbus services in the OS has come up before, and it's lame that we
don't try to track it.

- ajax

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

rawhide report: 20140820 changes

2014-08-20 Thread Fedora Rawhide Report 
Broken deps for i386
--
[APLpy]
APLpy-0.9.8-5.fc21.noarch requires pywcs
[PyKDE]
PyKDE-3.16.6-14.fc20.i686 requires sip-api(10) >= 0:10.0
[audtty]
audtty-0.1.12-9.fc20.i686 requires libaudclient.so.2
[authhub]
authhub-0.1.2-3.fc19.i686 requires libjson.so.0
[aws]
aws-devel-3.1.0-6.fc21.i686 requires libgrypt-devel
[compat-gcc-34]
compat-gcc-34-c++-3.4.6-29.fc19.i686 requires libstdc++ < 0:4.9.0
[csound]
csound-java-5.19.01-1.fc20.i686 requires libgcj_bc.so.1
csound-java-5.19.01-1.fc20.i686 requires java-gcj-compat
csound-java-5.19.01-1.fc20.i686 requires java-gcj-compat
csound-java-5.19.01-1.fc20.i686 requires java-1.5.0-gcj
csound-tk-5.19.01-1.fc20.i686 requires libtk8.5.so
csound-tk-5.19.01-1.fc20.i686 requires libtcl8.5.so
[deltacloud-core]
deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires 
rubygem(cloudfiles)
[docker-registry]
docker-registry-0.7.3-1.fc22.noarch requires docker-io
[dragonegg]
dragonegg-3.4-0.3.rc0.fc21.i686 requires gcc = 0:4.8.2-14.fc21
[edelib]
edelib-2.1-4.fc21.i686 requires libedelib.so
edelib-devel-2.1-4.fc21.i686 requires libedelib.so
[eucalyptus]
eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.i686 requires 
hibernate3-jbosscache >= 0:3.6.10-7
[fatrat]
1:fatrat-1.2.0-0.20.beta2.fc21.i686 requires libtorrent-rasterbar.so.7
1:fatrat-1.2.0-0.20.beta2.fc21.i686 requires libgloox.so.11
[flashrom]
flashrom-0.9.6.1-5.svn1705.fc20.i686 requires libftdi.so.1
[flush]
flush-0.9.12-9.fc21.i686 requires libtorrent-rasterbar.so.7
[freesteam]
freesteam-ascend-2.1-5.20140724svn753.fc22.i686 requires libascend.so.1
[gcc-python-plugin]
gcc-python2-debug-plugin-0.12-18.fc21.i686 requires gcc = 
0:4.8.2-14.fc21
gcc-python2-plugin-0.12-18.fc21.i686 requires gcc = 0:4.8.2-14.fc21
gcc-python3-debug-plugin-0.12-18.fc21.i686 requires 
libpython3.3dm.so.1.0
gcc-python3-debug-plugin-0.12-18.fc21.i686 requires gcc = 
0:4.8.2-14.fc21
gcc-python3-plugin-0.12-18.fc21.i686 requires libpython3.3m.so.1.0
gcc-python3-plugin-0.12-18.fc21.i686 requires gcc = 0:4.8.2-14.fc21
[gedit-valencia]
gedit-valencia-0.4.0-1.20131223git94442bf.fc21.i686 requires 
libvala-0.24.so.0
[gfal]
gfal-1.16.0-4.fc21.i686 requires libgsoap.so.4
gfal-doc-1.16.0-4.fc21.i686 requires libgsoap.so.4
gfal-python-1.16.0-4.fc21.i686 requires libgsoap.so.4
[gnome-python2-desktop]
gnome-python2-metacity-2.32.0-18.fc21.i686 requires 
libmetacity-private.so.0
[gnome-shell-extension-pomodoro]
gnome-shell-extension-pomodoro-0.10.0-4.fc21.i686 requires 
libupower-glib.so.2
[gofer]
ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0
[golang-github-smarterclayton-go-systemd]

golang-github-smarterclayton-go-systemd-devel-0-0.5.git5cb9e9e.fc21.noarch 
requires golang(github.com/guelfey/go.dbus)
[ice]
ice-php-3.5.1-4.fc21.i686 requires php(zend-abi) = 0:20121212-32
ice-php-3.5.1-4.fc21.i686 requires php(api) = 0:20121113-32
[iguanaIR]
1:iguanaIR-devel-1.0.5-4.fc22.i686 requires iguanaIR = 0:1.0.5-4.fc22
1:iguanaIR-python-1.0.5-4.fc22.i686 requires iguanaIR = 0:1.0.5-4.fc22
[leiningen]
leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks
leiningen-1.7.1-7.fc20.noarch requires classworlds
[libghemical]
libghemical-2.99.1-24.fc20.i686 requires libf77blas.so.3
libghemical-2.99.1-24.fc20.i686 requires libatlas.so.3
[libopensync-plugin-irmc]
1:libopensync-plugin-irmc-0.22-7.fc20.i686 requires libopenobex.so.1
[libvirt]
libvirt-lock-sanlock-1.2.7-1.fc22.i686 requires sanlock >= 0:2.4
libvirt-lock-sanlock-1.2.7-1.fc22.i686 requires libsanlock_client.so.1
[ltsp]
ltsp-client-5.4.5-8.fc21.i686 requires fuse-unionfs
ltsp-server-5.4.5-8.fc21.i686 requires cdialog
[meshmagick]
meshmagick-0.6.0-20.svn2898.fc21.i686 requires libOgreMain.so.1.8.1
meshmagick-libs-0.6.0-20.svn2898.fc21.i686 requires libOgreMain.so.1.8.1
[monodevelop-vala]
monodevelop-vala-2.8.8.1-6.fc21.i686 requires vala < 0:0.25.0
[netdisco]
netdisco-1.1-7.fc21.noarch requires perl(SNMP::Info::Layer2::Bay)
[ocaml-camlimages]
ocaml-camlimages-4.1.0-4.fc21.i686 requires ocaml(runtime) = 0:4.01.0
ocaml-camlimages-4.1.0-4.fc21.i686 requires ocaml(Unix) = 
0:93736a394d3d85d6d127fe238ddc6092
ocaml-camlimages-4.1.0-4.fc21.i686 requires ocaml(Sys) = 
0:5acfec22153eb1403597926ecd15f4f5
ocaml-camlimages-4.1.0-4.fc21.i686 requires ocaml(String) = 
0:db7f34081ef8fcaf499f19523d0736c6
ocaml-camlimages-4.1.0-4.fc21.i686 requires ocaml(Sort) = 
0:bbf3cb6d6b6965786380d6b6dd21c59d
ocaml-camlimages-4.1.0-4.fc21.i686 requires ocaml(Printf) = 
0:d012329cc712e91d0f10a5ee

appdata questions

2014-08-20 Thread Karel Volný 


Hi.

I have a few concerns about AppData that don't seem to be covered 
elsewhere, or at least I haven't found the answers
- not counting Richard's talk[1], as I gave up after five minutes, because 
I just couldn't get used to the accent ... sorry, I'm not native speaker, 
this was just too exhausting for me (plus I'm not exactly happy about 
having to spend time listening to 99% of sauce to get to 1% of information 
I'm interested in)


I've put those concerns onto the ticket[2] but the only answer I got was 
that it is wrong communication channel, so I'm copying it here:



1) Why not to take the information from the .desktop file by default and 
use appdata.xml only if the author/packager wants to provide additional 
information that cannot be in the .desktop file?


2) What is it good for to install appdata.xml into %{_datadir}/appdata/ 
when the installer (Apper, GNOME Software) takes the information from 
/usr/share/app-info/xmls so the files in /usr/share/appdata/ will lay on 
end-users' systems completely unused?


3) Almost the same goes for icons, if appstream-data will copy icons to 
/usr/share/app-info/icons, why to have two copies of the same image?


4) from ​http://people.freedesktop.org/~hughsient/appdata/


What happens if I don't ship this file?

The GNOME Software Center currently shows a nag message that the upstream
project doesn't ship the additional data. Additionally, we will penalize
apps that do not ship the extra metadata by showing them lower in the 

search

results.


why do we penalize users by hiding contents from them when some upstream 
just doesn't care about this stuff? (see also comment 7 about the "unjust 
burden")?


5) If there is a trend to split localised information into separate 
langpacks, why to mix all locales into one file, not allowing any split?


Also, no localised screenshots allowed - "Screenshots should be taken with 
US English as the display language." - even if they could be tagged with 
language code too?


6) If we copy the screenshots, why not to provide them also in an optional 
package?


I've heard there are still some people who don't have Internet connection 
and install Fedora from DVD (do we still allow to install more packages 
from DVD after the initial install, right?) Or some may prefer not to get 
online just to browse the applications list ...



- TIA for the answers,
K.


[1] ​https://www.youtube.com/watch?v=mSWIodEQMqo

[2] https://fedorahosted.org/fpc/ticket/414#comment:31

--
Karel Volný
QE BaseOs/Daemons Team
Red Hat Czech, Brno
tel. +420 532294274
(RH: +420 532294111 ext. 8262074)
xmpp ka...@jabber.cz
:: "Never attribute to malice what can
::  easily be explained by stupidity."

--
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] 2014-08-20 @ 16:00 UTC ** F21 Blocker Bug Review

2014-08-20 Thread Kamil Paral 
# F21 Blocker Review meeting
# Date: 2014-08-20
# Time: 16:00 UTC (12:00 EDT, 09:00 PDT)
# Location: #fedora-blocker-review on irc.freenode.net

It's the time again for another blocker bug meeting, and it's happening today!
At the moment there are 3 proposed blockers and 1 proposed freeze exception
for F21 Alpha. The full list can be found here:
https://qa.fedoraproject.org/blockerbugs/milestone/21/alpha/buglist

We'll be evaluating these bugs to see if they violate the Alpha
Release Criteria and warrant the blocking of a release if they're not
fixed. Information on the release criteria for F21 can be found on the
wiki:
https://fedoraproject.org/wiki/Fedora_Release_Criteria

Product specific plans are still being solidified, but that should be sorted
quickly.

For more information about the Blocker and Freeze exception process,
check out these links:
  - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
  - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process

And for those of you who are curious how a Blocker Review Meeting
works - or how it's supposed to go - check out the SOP on the wiki:
  - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting

We hope to see many of you!

Kamil
___
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

D-Bus RPM Provides?

2014-08-20 Thread Petr Pisar 
Hello,

I've no experience with packaging desktop software so maybe my question
will be stupid.

I'm updating a package which, when running tests, uses libnotify
library to send a notification to a desktop environment. The library
uses D-Bus to route the notification to org.freedesktop.Notifications
D-Bus service. So package needs to build-require an
org.freedesktop.Notifications server implementation.

Now tha packaging question: How to express this dependency?

I discovered that many org.freedesktop.Notifications server packages
provide `desktop-notification-daemon' RPM symbol. I think it would be
much better if the dependency was expressed as, e.g.,
`dbus(org.freedesktop.Notifications)'. It would be more generic and it
would allow to express the dependencies not only for desktop
notificiations servers. The Provides symbols could be generated by
rpm-build scripts from the D-Bus service definition files.

Is this idea worth for pursuing?

-- Petr

-- 
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: is there a way to view a spec file?

2014-08-20 Thread Josh Boyer 
On Wed, Aug 20, 2014 at 8:11 AM, Nico Kadel-Garcia  wrote:
> On Tue, Aug 19, 2014 at 9:01 AM, Neal Becker  wrote:
>> Something like github for fedora, where I can view/dl arbitrary files?  I'd 
>> like
>> to be able to view a spec file for any given package, without d/l the whole
>> package.
>
> CentOS is doing something like this at https://git.centos.org.
> Unfortunately, it's nightmarishly bad for simple viewability of
> specific RPM You see, they seem unwilling to believe in 'git tags'.
> They believe that it's somehow smarter and more reliable to rely on
> using a git log with the word "import" in it as an indicator of which
> corresponding SRPM the repository is tied to, and using the revision
> of that git log as the way to indicate the state of the git repo for
> that SRPM build.
>
> I leave it to our faithful readers to ponder the number of ways this
> is *completely* nuts. It's also already broken, with SRPM's being
> built without a corresponding "git log" entry in the git repository
> for at least one package. I also leave it to our faithful readers to
> look over the festonery and contemplate the security implications of
> not using signed git tags to ensure the provenance of the contents of
> a local git clone of a remote repository with critical system
> software.
>
> Please, please, please never do this with Fedora? Please? If and as we
> use git repos, use tags?

We've been using git repos for packages since 2010.  We don't use
tags.  Mostly because that would require koji to write back to the
SCM, which it doesn't do.  It does log which sha1sum it built the
SRPM/RPM from though, and that is immutable.

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

F-21 Branched report: 20140820 changes

2014-08-20 Thread Fedora Branched Report 
Compose started at Wed Aug 20 07:15:02 UTC 2014

Broken deps for armhfp
--
[APLpy]
APLpy-0.9.8-5.fc21.noarch requires pywcs
[PyKDE]
PyKDE-3.16.6-14.fc20.armv7hl requires sip-api(10) >= 0:10.0
[audtty]
audtty-0.1.12-9.fc20.armv7hl requires libaudclient.so.2
[authhub]
authhub-0.1.2-3.fc19.armv7hl requires libjson.so.0
[csound]
csound-java-5.19.01-1.fc20.armv7hl requires libgcj_bc.so.1
csound-java-5.19.01-1.fc20.armv7hl requires java-gcj-compat
csound-java-5.19.01-1.fc20.armv7hl requires java-gcj-compat
csound-java-5.19.01-1.fc20.armv7hl requires java-1.5.0-gcj
csound-tk-5.19.01-1.fc20.armv7hl requires libtk8.5.so
csound-tk-5.19.01-1.fc20.armv7hl requires libtcl8.5.so
[deltacloud-core]
deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires 
rubygem(cloudfiles)
[docker-registry]
docker-registry-0.7.3-1.fc21.noarch requires docker-io
[dragonegg]
dragonegg-3.4-0.3.rc0.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21
[edelib]
edelib-2.1-4.fc21.armv7hl requires libedelib.so
edelib-devel-2.1-4.fc21.armv7hl requires libedelib.so
[eucalyptus]
eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.armv7hl 
requires hibernate3-jbosscache >= 0:3.6.10-7
[fatrat]
1:fatrat-1.2.0-0.20.beta2.fc21.armv7hl requires 
libtorrent-rasterbar.so.7
1:fatrat-1.2.0-0.20.beta2.fc21.armv7hl requires libgloox.so.11
[flashrom]
flashrom-0.9.6.1-5.svn1705.fc20.armv7hl requires libftdi.so.1
[flush]
flush-0.9.12-9.fc21.armv7hl requires libtorrent-rasterbar.so.7
[freesteam]
freesteam-ascend-2.1-5.20140724svn753.fc21.armv7hl requires 
libascend.so.1
[gcc-python-plugin]
gcc-python2-debug-plugin-0.12-18.fc21.armv7hl requires gcc = 
0:4.8.2-14.fc21
gcc-python2-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21
gcc-python3-debug-plugin-0.12-18.fc21.armv7hl requires 
libpython3.3dm.so.1.0
gcc-python3-debug-plugin-0.12-18.fc21.armv7hl requires gcc = 
0:4.8.2-14.fc21
gcc-python3-plugin-0.12-18.fc21.armv7hl requires libpython3.3m.so.1.0
gcc-python3-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21
[gedit-valencia]
gedit-valencia-0.4.0-1.20131223git94442bf.fc21.armv7hl requires 
libvala-0.24.so.0
[ghc-concrete-typerep]
ghc-concrete-typerep-devel-0.1.0.2-4.fc21.armv7hl requires 
ghc-devel(ghc-7.6.3-9662c0f342b2d5c9e1cd2b6330e697bc)
[ghc-ghc-mtl]
ghc-ghc-mtl-devel-1.2.1.0-2.fc21.armv7hl requires 
ghc-devel(ghc-7.6.3-9662c0f342b2d5c9e1cd2b6330e697bc)
[ghc-hint]
ghc-hint-devel-0.4.2.0-2.fc21.armv7hl requires 
ghc-devel(ghc-7.6.3-9662c0f342b2d5c9e1cd2b6330e697bc)
[ghc-ltk]
ghc-ltk-devel-0.12.1.0-12.fc21.armv7hl requires 
ghc-devel(ghc-7.6.3-9662c0f342b2d5c9e1cd2b6330e697bc)
[gnome-python2-desktop]
gnome-python2-metacity-2.32.0-18.fc21.armv7hl requires 
libmetacity-private.so.0
[gnome-shell-extension-pomodoro]
gnome-shell-extension-pomodoro-0.10.0-4.fc21.armv7hl requires 
libupower-glib.so.2
[gofer]
ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0
[golang-github-smarterclayton-go-systemd]

golang-github-smarterclayton-go-systemd-devel-0-0.5.git5cb9e9e.fc21.noarch 
requires golang(github.com/guelfey/go.dbus)
[haddock]
ghc-haddock-devel-2.13.2-4.fc21.armv7hl requires 
ghc-devel(ghc-7.6.3-9662c0f342b2d5c9e1cd2b6330e697bc)
[hibernate-search]
hibernate-search-4.5.1-4.fc21.noarch requires mvn(org.apache.avro:avro)
[ice]
ice-php-3.5.1-4.fc21.armv7hl requires php(zend-abi) = 0:20121212-32
ice-php-3.5.1-4.fc21.armv7hl requires php(api) = 0:20121113-32
[leiningen]
leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks
leiningen-1.7.1-7.fc20.noarch requires classworlds
[leksah]
ghc-leksah-devel-0.12.1.3-15.fc21.armv7hl requires 
ghc-devel(ghc-7.6.3-9662c0f342b2d5c9e1cd2b6330e697bc)
[leksah-server]
ghc-leksah-server-devel-0.12.1.2-15.fc21.armv7hl requires 
ghc-devel(ghc-7.6.3-9662c0f342b2d5c9e1cd2b6330e697bc)
[libghemical]
libghemical-2.99.1-24.fc20.armv7hl requires libf77blas.so.3
libghemical-2.99.1-24.fc20.armv7hl requires libatlas.so.3
[libopensync-plugin-irmc]
1:libopensync-plugin-irmc-0.22-7.fc20.armv7hl requires libopenobex.so.1
[libvirt]
libvirt-lock-sanlock-1.2.7-1.fc21.armv7hl requires sanlock >= 0:2.4
libvirt-lock-sanlock-1.2.7-1.fc21.armv7hl requires 
libsanlock_client.so.1
[licq]
licq-1.8.2-1.fc21.armv7hl requires libgloox.so.11
[ltsp]
ltsp-client-5.4.5-8.fc21.armv7hl requires fuse-unionfs
ltsp-server-5.4.5-8.fc21.armv7hl requires cdialog
[meshmagick]
meshmagick-0.6.0-20.svn2898.fc21.armv7hl requires libOgreMain.so.1.8.1
meshmagick-libs-0.6.0-20.svn2898.fc21.armv7hl requires 
libOgreMain.so.1.8.1
[monodevelop-vala]
monodevelop-vala-2.8.8.1-6

Re: FESCo #1263 question (optional javadocs)

2014-08-20 Thread Miloslav Trmač 
Hello, 

> Regarding https://fedorahosted.org/fesco/ticket/1263

> Does this policy change affect updates to older releases still receiving
> updates? Or only F21 and later?

It has been approved as a F21 Change, so it should affect only F≥21. 
Technically, the packaging guideline change is somewhat independent from the 
Change process; I’d argue that updates to existing F≤20 packages should not 
remove functionality, though. 
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: is there a way to view a spec file?

2014-08-20 Thread Nico Kadel-Garcia 
On Tue, Aug 19, 2014 at 9:01 AM, Neal Becker  wrote:
> Something like github for fedora, where I can view/dl arbitrary files?  I'd 
> like
> to be able to view a spec file for any given package, without d/l the whole
> package.

CentOS is doing something like this at https://git.centos.org.
Unfortunately, it's nightmarishly bad for simple viewability of
specific RPM You see, they seem unwilling to believe in 'git tags'.
They believe that it's somehow smarter and more reliable to rely on
using a git log with the word "import" in it as an indicator of which
corresponding SRPM the repository is tied to, and using the revision
of that git log as the way to indicate the state of the git repo for
that SRPM build.

I leave it to our faithful readers to ponder the number of ways this
is *completely* nuts. It's also already broken, with SRPM's being
built without a corresponding "git log" entry in the git repository
for at least one package. I also leave it to our faithful readers to
look over the festonery and contemplate the security implications of
not using signed git tags to ensure the provenance of the contents of
a local git clone of a remote repository with critical system
software.

Please, please, please never do this with Fedora? Please? If and as we
use git repos, use tags?
-- 
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: Mono3.4 in Fedora 21, or troll?

2014-08-20 Thread Ankur Sinha 
On Wed, 2014-08-20 at 18:54 +0800, Christopher Meng wrote:
> Hi, 
> 
> Can someone tell me the status of the mono 3.4 proposal? I contacted
> chkr last year and he said it's a big task. He didn't say anything
> about the feature although the mono package is obsolete already. And I
> don't know why 3.4 was proposed by a stranger this year again(someone
> is not even a packager yet with no communication to the development). 
> 
> As some of the websites in my country have written this feature in the
> news, I'm afraid I have to ask here.

Christopher, Links to what you've read will make this easier to confirm.
-- 
Thanks,
Warm regards,
Ankur (FranciscoD)

http://fedoraproject.org/wiki/User:Ankursinha

Join Fedora! Come talk to us!
http://fedoraproject.org/wiki/Fedora_Join_SIG



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

Mono3.4 in Fedora 21, or troll?

2014-08-20 Thread Christopher Meng 
Hi,

Can someone tell me the status of the mono 3.4 proposal? I contacted chkr
last year and he said it's a big task. He didn't say anything about the
feature although the mono package is obsolete already. And I don't know why
3.4 was proposed by a stranger this year again(someone is not even a
packager yet with no communication to the development).

As some of the websites in my country have written this feature in the
news, I'm afraid I have to ask here.

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