Standard, consistent subject lines for automated emails

[Richard W.M. Jones]

Here are a small collection of subject lines of emails sent
automatically to me by various Fedora systems in the past few days:

Subject: upgradepath PASSED for FEDORA-2015-850e89be8b
Subject: [Fedora Update] [comment] auto-buildrequires-1.2-1.fc23
Subject: rjones's libguestfs-1.33.1-2.fc24 completed
Subject: rpmlint PASSED for libguestfs-1.33.1-2.fc24
Subject: Broken dependencies: libguestfs
Subject: ABRT report for package gnome-boxes has reached 10 occurrences
Subject: [Bug 1269975] svirt very occasionally prevents parallel libvirt [..]
Subject: Fedora 'packager' sponsor needed for suanand
Subject: sailer's mingw-sqlite-3.10.1.0-1.fc24 failed to build
Subject: libguestfs's builds are back to normal in f24
Subject: dchen pushed to ocaml-lwt (el6).  "New upstream version 2.2.0."

The only consistent thing is there's nothing consistent about them :-/

I'd like to propose a very lightweight "standard" for subject lines of
emails.

(1) The first word should be the package name which the email
concerns.  If the email is not about a package, but about a person,
then the first word should be the FAS username of that person.

(2) The second word should be the status, reflecting what the reader
needs to know or do, for example "succeeded", "failed", "submitted".

That's it!

The above subject lines might become (chopped to 72 characters to
simulate what you might see in a text-based email reader):

Subject: auto-buildrequires passed: upgradepath FEDORA-2015-850e89be8b
Subject: auto-buildrequires submitted: auto-buildrequires-1.2-1.fc23
Subject: libguestfs completed: rjones's libguestfs-1.33.1-2.fc24 build c
Subject: libguestfs passed: rpmlint libguestfs-1.33.1-2.fc24
Subject: libguestfs failed: Broken dependencies found in package libgues
Subject: gnome-boxes failed: ABRT report for package gnome-boxes has rea
Subject: selinux-policy comment: [Bug 1269975] svirt very occasionally p
Subject: suanand requested: Fedora 'packager' sponsor needed for suanand
Subject: mingw-sqlite failed: sailer's mingw-sqlite-3.10.1.0-1.fc24 fail
Subject: libguestfs passed: libguestfs's builds are back to normal in f2
Subject: ocaml-lwt pushed: dchen pushed to ocaml-lwt (el6).  "New upstre

Maybe you have some better ideas?

A related topic is headers, which could be used for filtering.
Various systems add headers -- see examples below -- but again there's
not much consistency and the headers aren't particularly useful for
filtering.

Rich.

X-Fedmsg-Topic: org.fedoraproject.prod.taskotron.result.new
X-Fedmsg-Category: taskotron
X-Fedmsg-Package: libguestfs

X-Bodhi-Update-Builds: auto-buildrequires-1.2-1.fc23
X-Bodhi-Update-Pushed: True
X-Bodhi-Update-Type: enhancement
X-Bodhi-Update-Release: F23
X-Bodhi-Update-Status: testing
X-Bodhi-Update-Request: stable
X-Bodhi-Update-Submitter: rjones
X-Bodhi-Update-Title: auto-buildrequires-1.2-1.fc23
X-Bodhi: fedoraproject.org

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

rawhide report: 20160116 changes

[Fedora Rawhide Report]

 Hughes <rhug...@redhat.com> - 3.19.4-1
- Update to 3.19.4


Size change: 4157 bytes

gonvert-0.2.38-1.fc24
-
* Fri Jan 15 2016 Jon Ciesla <limburg...@gmail.com> - 0.2.38-1
- Latest upstream.


Size change: -187 bytes

gpaste-3.18.3-1.fc24

* Fri Jan 15 2016 Mohamed El Morabity <melmorab...@fedoraproject.org> - 3.18.3-1
- Update to 3.18.3


Size change: 615 bytes

graphviz-2.38.0-32.fc24
---
* Tue Jan 12 2016 Vít Ondruch <vondr...@redhat.com> - 2.38.0-32
- Rebuilt for https://fedoraproject.org/wiki/Changes/Ruby_2.3


Size change: 127 bytes

greenisland-0.7.1-1.fc24

* Fri Jan 15 2016 Pier Luigi Fiorini <pierluigi.fior...@gmail.com> - 0.7.1-1
- Update to 0.7.1


Size change: -1973 bytes

grive2-0.5.0-1.20160114gitae06ecc.fc24
--
* Fri Jan 15 2016 Christian Dersch <lupi...@mailbox.org> - 
0.5.0-1.20160115gitae06ecc
- new version 0.5.0


Size change: 323 bytes

hawaii-shell-0.6.0-2.fc24
-
* Thu Jan 14 2016 Pier Luigi Fiorini <pierluigi.fior...@gmail.com> - 0.6.0-2
- Require Green Island >= 0.7.1
- Update QML plugins path

* Thu Jan 14 2016 Pier Luigi Fiorini <pierluigi.fior...@gmail.com> - 0.6.0-1
- Update to 0.6.0


Size change: -78499 bytes

hivex-1.3.13-3.fc24
---
* Tue Jan 12 2016 Vít Ondruch <vondr...@redhat.com> - 1.3.13-3
- Rebuilt for https://fedoraproject.org/wiki/Changes/Ruby_2.3


Size change: 120 bytes

hyperestraier-1.4.13-24.fc24

* Wed Jan 13 2016 Mamoru TASAKA <mtas...@fedoraproject.org> - 1.4.13-24
- F-24: rebuild against ruby23


Size change: 129 bytes

ignition-math-2.3.0-1.fc24
--
* Fri Jan 15 2016 Rich Mattes <richmat...@gmail.com> - 2.3.0-1
- Update to release 2.3.0


Size change: 10278 bytes

jersey-2.22.1-2.fc24

* Fri Jan 15 2016 Orion Poplawski <or...@cora.nwra.com> 2.22.1-2
- Rebuild for osgi-resource-locator change


Size change: 146 bytes

k3d-0.8.0.5-2.fc24
--
* Fri Jan 15 2016 Adam Jackson <a...@redhat.com> 0.8.0.5-2
- Rebuild for glew 1.13


Size change: 113 bytes

kazehakase-0.5.8-20.svn3873_trunk.fc24
--
* Wed Jan 13 2016 Mamoru TASAKA <mtas...@fedoraproject.org> - 0.5.8-20.svn3873
- F-24: rebuild against ruby23

* Wed Jun 17 2015 Mamoru TASAKA <mtas...@fedoraproject.org> - 0.5.8-19.svn3873
- F-23: don't call gnutls_certificate_type_set_priority any more

* Wed Jun 17 2015 Fedora Release Engineering <rel-...@lists.fedoraproject.org> 
- 0.5.8-18.svn3873_trunk.1
- Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild


Size change: 139 bytes

kde-partitionmanager-2.0.0-1.fc24
-
* Thu Jan 14 2016 Mattia Verga <mattia.ve...@tiscali.it> - 2.0.0-1
- Update to stable 2.0.0
- Bind to same KPMcore version
- Library removed from sources


Size change: 1232 bytes

kst-2.0.8-5.fc24

* Mon Jan 25 2016 Jon Ciesla <limburg...@gmail.com> - 2.0.8-5
- Rebuild for new getdata.


Size change: 126 bytes

libappstream-glib-0.5.6-1.fc24
--
* Fri Jan 15 2016 Richard Hughes <rich...@hughsie.com> 0.5.6-1
- New upstream release
- Accept various 'or later' metadata content licenses
- Check the project_group when validating
- Cull the application blacklist now we depend on AppData files
- Fix things up for xdg-app use
- Install gettext ITS rules


Size change: 4982 bytes

libcaca-0.99-0.27.beta19.fc24
-
* Tue Jan 12 2016 Vít Ondruch <vondr...@redhat.com> - 0.99-0.27.beta19
- Rebuilt for https://fedoraproject.org/wiki/Changes/Ruby_2.3


Size change: 143 bytes

libdmtx-0.7.2-18.fc24
-
* Tue Jan 12 2016 Vít Ondruch <vondr...@redhat.com> - 0.7.2-18
- Rebuilt for https://fedoraproject.org/wiki/Changes/Ruby_2.3


Size change: 157 bytes

libdwarf-20160115-1.fc24

* Sat Jan 16 2016 Tom Hughes <t...@compton.nu> - 20160115-1
- Update to 20160116 upstream release


Size change: 74949 bytes

libisds-0.10.2-1.fc24
-
* Fri Jan 15 2016 Petr Pisar <ppi...@redhat.com> - 0.10.2-1
- 0.10.2 bump


Size change: 330 bytes

liblxqt-0.10.0-7.fc24
-
* Fri Jan 15 2016 Helio Chissini de Castro <he...@kde.org> - 0.10.0-7
- Remove razorqt obsoletes. Solves bug #1244155
- RazortQt EOL code should be maintained by bug requesters


Size change: 226 bytes

libreoffice-5.1.0.2-2.fc24
--
* Thu Jan 14 2016 Adam Jackson <a...@redhat.com> - 1:5.1.0.2-2
- Rebuild for glew 1.13

* Thu Jan 14 2016 David Tardon <dtar...@redhat.com> - 1:5.1.0.2-1
- update to 5.1.0 rc2


Size change: 228278 bytes

libsbml-5.12.0-4.fc24
-
* Tue Jan 12 2016 Vít Ondruch <vondr...@redhat.com> - 5.12.

Re: Standard, consistent subject lines for automated emails

[Reindl Harald]

Am 16.01.2016 um 14:34 schrieb Richard W.M. Jones:

Here are a small collection of subject lines of emails sent
automatically to me by various Fedora systems in the past few days:

Subject: upgradepath PASSED for FEDORA-2015-850e89be8b
Subject: [Fedora Update] [comment] auto-buildrequires-1.2-1.fc23
Subject: rjones's libguestfs-1.33.1-2.fc24 completed
Subject: rpmlint PASSED for libguestfs-1.33.1-2.fc24
Subject: Broken dependencies: libguestfs
Subject: ABRT report for package gnome-boxes has reached 10 occurrences
Subject: [Bug 1269975] svirt very occasionally prevents parallel libvirt [..]
Subject: Fedora 'packager' sponsor needed for suanand
Subject: sailer's mingw-sqlite-3.10.1.0-1.fc24 failed to build
Subject: libguestfs's builds are back to normal in f24
Subject: dchen pushed to ocaml-lwt (el6).  "New upstream version 2.2.0."

The only consistent thing is there's nothing consistent about them :-/

I'd like to propose a very lightweight "standard" for subject lines of
emails.

(1) The first word should be the package name which the email
concerns


in context of that the subjects below needs to be fixed listing all 
subpackages and exceed TWO KILOBYTE subject header because place the 
package in front would prevent to see anything else (in case of other 
packages not exceeding 2048 byte but have subpackages too)


Jan  7 05:23:03 mail-gw postfix/cleanup[2859]: 3pbZDQ6RR5z2B: reject: 
header Subject: [Fedora Update] [CRITPATH] [comment] 
kf5-kdoctools-5.18.0-1.fc23 kf5-kdbusaddons-5.18.0-1.fc23 
kf5-kio-5.18.0-1.fc23 kf5-kjsembed-5.18.0-1.fc23 
kf5-ktextwidgets-5.18.0-1.fc23 kf5-kidletime-5. from 
bastion01.fedoraproject.org[209.132.181.2]; 
from= to= proto=ESMTP 
helo=: 5.7.1 Administrative Prohibition 
(Subject-Header Too Long)




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: New tbb in Rawhide

[Jerry James]

On Sat, Jan 16, 2016 at 2:46 AM, Marcin Juszkiewicz
 wrote:
> Please do check on secondary archs as well. {arm,ppc,s390}-koji works
> without any extra configuration needed.

I haven't yet had time to do this, but I will try to do it next week,
unless the individual package owners beat me to it.
-- 
Jerry James
http://www.jamezone.org/
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: New tbb in Rawhide

[Marcin Juszkiewicz]

W dniu 15.01.2016 o 23:14, Jerry James pisze:

I am going to build the latest version of tbb in Rawhide soon.



I have already done successful rebuilds of these packages in mock for
x86_64, so I don't expect any trouble.  Nevertheless, if a build fails,
I will look into it.


Please do check on secondary archs as well. {arm,ppc,s390}-koji works 
without any extra configuration needed.

--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: ZFS on linux

[Kevin Kofler]

Gerald B. Cox wrote:
> Fedora has it's own rules and can ship or not ship what they want.  I'm
> perfectly fine with that.  As I previously stated, IMO BTRFS is a much
> better choice.  My point was simply that I don't believe saying it would
> be a GPL violation to include ZFS in a Linux distribution is one of them. 
> If it were, I can't imagine Canonical would be doing it.

Canonical also has no qualms shipping the NVidia driver, which has the exact 
same licensing issue. They decided that they don't care.

Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: ZFS on linux

[Andrew Lutomirski]

On Sat, Jan 16, 2016 at 7:38 AM, Neal Gompa  wrote:
> On Sat, Jan 16, 2016 at 10:13 AM, Kevin Kofler  wrote:
>> Gerald B. Cox wrote:
>>> Fedora has it's own rules and can ship or not ship what they want.  I'm
>>> perfectly fine with that.  As I previously stated, IMO BTRFS is a much
>>> better choice.  My point was simply that I don't believe saying it would
>>> be a GPL violation to include ZFS in a Linux distribution is one of them.
>>> If it were, I can't imagine Canonical would be doing it.
>>
>> Canonical also has no qualms shipping the NVidia driver, which has the exact
>> same licensing issue. They decided that they don't care.
>>
>
> Canonical ships everything as source code, so their justification
> likely is that they aren't doing binary distribution, for whatever
> that's worth.
>
> The benchmark is probably what Debian and their team thinks of it,
> because Debian and Fedora have similarly strict guidelines for stuff
> like this because they *do* care.

As a technical matter, Fedora could ship ZFS source only.  I don't
know whether that would help the legal issues.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: How to fix a package name with wrong capitalization?

[Haïkel]

2016-01-16 16:10 GMT+01:00 Kevin Kofler :
> Hi,
>
> in the following review:
> https://bugzilla.redhat.com/show_bug.cgi?id=1285042
> a package was reviewed and approved under the name "kpmcore", which matches
> how upstream calls its tarballs. However, the subject line incorrectly
> spelled the name as "KPMcore" in camel-case, which was not caught during
> review, and so when the package was created in pkgdb, the submitter
> accidentally requested the module as "KPMcore". Unfortunately, the automated
> checks apparently do not notice mismatches between the specfile name and the
> subject line, and neither did the reviewer.
>
> In addition, since nobody reviewed that rename, it also does not handle
> Provides correctly, there isn't even a Provides for the correct name.
>
> So I would like to ask:
> * How can this particular package get fixed? I sure hope the answer is not
>   to stick to the incorrect camel-case name forever! Can the administrators
>   please look into this?


Since this package only hit rawhide, I guess we can accept that releng
fixes the repo and
avoid the rename process.
http://koji.fedoraproject.org/koji/packageinfo?packageID=21440

If it were a stable or branched release, I would insist to follow the
rename process.

> * Can we add some additional sanity checks to prevent this from happening
>   again in the future? I guess the issue there is that specfile links do not
>   necessarily contain the file name in the link or even contain it, they can
>   be fpaste links, links into some SCM viewer, etc. We would also need to
>   check the latest specfile link, not the first, because sometimes, package
>   names are fixed as part of the review process. But if we can find a
>   solution that does not break current use cases, I think it would be very
>   helpful.
>
> Kevin Kofler

That is an excellent idea, I encourage you to open a ticket in pkgdb2.

I guess we could add sanity check to the bugzilla sync script
https://github.com/fedora-infra/pkgdb2/blob/0b40ed5e7543a587b0acc8118f0f99ca14c256a8/utility/pkgdb-sync-bugzilla

It could be either a flash message warning packager or plainly refuses
to create the request if you don't fix the ticket.

Regards,
H.


> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Another strange Koji error

[Björn Esser]

Am 16.01.2016 um 19:13 schrieb Mattia Verga:

I was trying to do a scratch build for a review ticket submission and I
got this:
http://koji.fedoraproject.org/koji/taskinfo?taskID=12578072

All builds on different architectures are ok, but in the build result it
says something strange about static libraries.
This is the first time I compile a package with static libraries, can
someone explain me about this error?


The problem is caused by making the -static sub-pkg noarch.  Why are 
static libs packaged anyways?  There is an unversioned so-lib in the 
arch'ed main-package, besides a c-compiled python-module and ~ 4MBytes 
of stuff in /usr/share, etc…  Making the -devel package noach can be 
problematic, too…


Just findings from a quick glance on the built packages…
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: ZFS on linux

[Gerald B. Cox]

On Sat, Jan 16, 2016 at 9:55 AM, Kevin Fenzi  wrote:

> The benchmark if it's legal to include something in Fedora is
> what Fedora Legal says.
>

I basically would agree with everything you stated, except I would change
the sentence to read:  "The benchmark if it's permissible..."
Fedora has it's own rules, but when you use the term "legal" the
connotation is that the other distributions which are distributing ZFS
are breaking the law.  Fedora cannot make that determination; and blanket
statements like that lead to FUD and misquotes.
If Fedora chooses not to distribute ZFS for any reason, that is perfectly
fine - however, the fact
that we choose not to do so doesn't make it illegal.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: ZFS on linux

[Neal Gompa]

On Sat, Jan 16, 2016 at 10:13 AM, Kevin Kofler  wrote:
> Gerald B. Cox wrote:
>> Fedora has it's own rules and can ship or not ship what they want.  I'm
>> perfectly fine with that.  As I previously stated, IMO BTRFS is a much
>> better choice.  My point was simply that I don't believe saying it would
>> be a GPL violation to include ZFS in a Linux distribution is one of them.
>> If it were, I can't imagine Canonical would be doing it.
>
> Canonical also has no qualms shipping the NVidia driver, which has the exact
> same licensing issue. They decided that they don't care.
>

Canonical ships everything as source code, so their justification
likely is that they aren't doing binary distribution, for whatever
that's worth.

The benchmark is probably what Debian and their team thinks of it,
because Debian and Fedora have similarly strict guidelines for stuff
like this because they *do* care.

I don't know if it's possible to talk to the Debian folks about it,
because they've clearly discussed it for quite a while[0][1][2]. In
terms of legal things, Debian appears to use the SFLC for legal advice
about ZFS, and I don't know (nor wish to speculate) whether Red Hat
Legal talks to those folks.

[0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686447
[1]: https://lists.debian.org/debian-devel-announce/2015/04/msg6.html
[2]: https://lists.debian.org/debian-devel-announce/2015/05/msg4.html



-- 
真実はいつも一つ！/ Always, there's only one truth!
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Fedora Rawhide 20160116 compose check report

[Fedora compose checker]

Missing expected images:

Kde disk raw armhfp
Workstation live i386
Workstation live x86_64

Images in this compose but not Rawhide 20160115:

Cloud_atomic disk raw x86_64
Games live x86_64
Games live i386
Scientific_kde live x86_64
Cloud_atomic disk qcow x86_64
Scientific_kde live i386

No images in Rawhide 20160115 but not this.

Failed openQA tests: 7 of 63

ID: 3249Test: x86_64 kde_live default_install@uefi
URL: https://openqa.fedoraproject.org/tests/3249
ID: 3248Test: x86_64 kde_live default_install
URL: https://openqa.fedoraproject.org/tests/3248
ID: 3253Test: i386 kde_live default_install
URL: https://openqa.fedoraproject.org/tests/3253
ID: 3224Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/3224
ID: 3231Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/3231
ID: 3226Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/3226
ID: 3232Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/3232

Passed openQA tests: 53 of 63
3 openQA tests may be still running or broken!
-- 
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: How to fix a package name with wrong capitalization?

[Pierre-Yves Chibon]

On Sat, Jan 16, 2016 at 05:43:19PM +0100, Haïkel wrote:
> 2016-01-16 16:10 GMT+01:00 Kevin Kofler :
> > Hi,
> >
> > in the following review:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1285042
> > a package was reviewed and approved under the name "kpmcore", which matches
> > how upstream calls its tarballs. However, the subject line incorrectly
> > spelled the name as "KPMcore" in camel-case, which was not caught during
> > review, and so when the package was created in pkgdb, the submitter
> > accidentally requested the module as "KPMcore". Unfortunately, the automated
> > checks apparently do not notice mismatches between the specfile name and the
> > subject line, and neither did the reviewer.
> >
> > In addition, since nobody reviewed that rename, it also does not handle
> > Provides correctly, there isn't even a Provides for the correct name.
> >
> > So I would like to ask:
> > * How can this particular package get fixed? I sure hope the answer is not
> >   to stick to the incorrect camel-case name forever! Can the administrators
> >   please look into this?
> 
> 
> Since this package only hit rawhide, I guess we can accept that releng
> fixes the repo and
> avoid the rename process.
> http://koji.fedoraproject.org/koji/packageinfo?packageID=21440
> 
> If it were a stable or branched release, I would insist to follow the
> rename process.

The easiest might be to open a ticket on either the rel-eng trac or the infra
one.
 
> > * Can we add some additional sanity checks to prevent this from happening
> >   again in the future? I guess the issue there is that specfile links do not
> >   necessarily contain the file name in the link or even contain it, they can
> >   be fpaste links, links into some SCM viewer, etc. We would also need to
> >   check the latest specfile link, not the first, because sometimes, package
> >   names are fixed as part of the review process. But if we can find a
> >   solution that does not break current use cases, I think it would be very
> >   helpful.
> >
> That is an excellent idea, I encourage you to open a ticket in pkgdb2.
> 

There are two projects involved here:
- pkgdb2 when the package request is created, this one does some basic checks
  in:
  https://github.com/fedora-infra/pkgdb2/blob/master/pkgdb2/api/extras.py
- packagedb-cli which ships pkgdb-admin ran by the rel-eng people to process
  these requests. This one does some more thorough checks and would have my
  preference as the place to fix this (since it would have to parse all the
  comments from the review to find the spec file and try to extract a name).


Pierre
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: ZFS on linux

[Kevin Fenzi]

On Sat, 16 Jan 2016 10:38:42 -0500
Neal Gompa  wrote:

> On Sat, Jan 16, 2016 at 10:13 AM, Kevin Kofler
>  wrote:
> > Gerald B. Cox wrote:  
> >> Fedora has it's own rules and can ship or not ship what they
> >> want.  I'm perfectly fine with that.  As I previously stated, IMO
> >> BTRFS is a much better choice.  My point was simply that I don't
> >> believe saying it would be a GPL violation to include ZFS in a
> >> Linux distribution is one of them. If it were, I can't imagine
> >> Canonical would be doing it.  
> >
> > Canonical also has no qualms shipping the NVidia driver, which has
> > the exact same licensing issue. They decided that they don't care.
> >  
> 
> Canonical ships everything as source code, so their justification
> likely is that they aren't doing binary distribution, for whatever
> that's worth.

I'm confused by the two above sentences. :) The NVida binary only non
free driver's source is only available to AMD/nvidia. The shim that
connects it to the kernel has source available, but the driver
itself does not. 

> The benchmark is probably what Debian and their team thinks of it,
> because Debian and Fedora have similarly strict guidelines for stuff
> like this because they *do* care.

Nope. The benchmark if it's legal to include something in Fedora is
what Fedora Legal says. Thats it. We have (and likely will continue) to
disagree with Debian on some things (like mp3). 

IMHO, someone needs to ask Legal if it can be included. If for some
reason things have changed and they say yes, then it would hit the out
of tree kmods issues and likely be impractical there.

So, no, I don't think it's going to be possible or practical to include
ZFS. 

kevin


pgpi6DGXlex45.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

How to fix a package name with wrong capitalization?

[Kevin Kofler]

Hi,

in the following review:
https://bugzilla.redhat.com/show_bug.cgi?id=1285042
a package was reviewed and approved under the name "kpmcore", which matches 
how upstream calls its tarballs. However, the subject line incorrectly 
spelled the name as "KPMcore" in camel-case, which was not caught during 
review, and so when the package was created in pkgdb, the submitter 
accidentally requested the module as "KPMcore". Unfortunately, the automated 
checks apparently do not notice mismatches between the specfile name and the 
subject line, and neither did the reviewer.

In addition, since nobody reviewed that rename, it also does not handle 
Provides correctly, there isn't even a Provides for the correct name.

So I would like to ask:
* How can this particular package get fixed? I sure hope the answer is not
  to stick to the incorrect camel-case name forever! Can the administrators
  please look into this?
* Can we add some additional sanity checks to prevent this from happening
  again in the future? I guess the issue there is that specfile links do not
  necessarily contain the file name in the link or even contain it, they can
  be fpaste links, links into some SCM viewer, etc. We would also need to
  check the latest specfile link, not the first, because sometimes, package
  names are fixed as part of the review process. But if we can find a
  solution that does not break current use cases, I think it would be very
  helpful.

Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Bullet version bump

[Rich Mattes]

On 01/15/2016 10:56 PM, Orion Poplawski wrote:

On 01/15/2016 07:31 PM, Rich Mattes wrote:

Hi,

I plan on building bullet-2.83 in rawhide this weekend.  Bullet uses a
soversion that's equal to the package version, so each bullet version
bump requires a rebuild of all dependent packages.


Just out of curiosity - has anyone ever tried educating upstream about
using a proper soname versioning scheme?  I wonder how much longer we
will have to be tilting at this particular windmill...




I took a quick look with abi-compliance-checker, there are indeed 
several binary incompatibilities between 2.82 and 2.83.  It doesn't seem 
like they're trying to maintain compatibility between their major 
releases, so at least in this instance I think tying the soname to the 
library version seems warranted.


It's certainly better than the case where the soname doesn't change and 
everything breaks at runtime.


Rich
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

eseyman pushed to bugzilla (master). "Update to 5.0.2"

[notifications]

From fbfe368dc1f3440fa87450876beb540699064930 Mon Sep 17 00:00:00 2001
From: Emmanuel Seyman 
Date: Sat, 16 Jan 2016 18:24:29 +0100
Subject: Update to 5.0.2

---
 .gitignore  |   1 +
 README.fedora.bugzilla  |   2 +-
 bugzilla-dnf.patch  |  20 +++
 bugzilla-rw-paths.patch |  37 +++--
 bugzilla-yum.patch  |  20 ---
 bugzilla.spec   | 140 ++--
 sources |   2 +-
 7 files changed, 132 insertions(+), 90 deletions(-)
 create mode 100644 bugzilla-dnf.patch
 delete mode 100644 bugzilla-yum.patch

diff --git a/.gitignore b/.gitignore
index ec294de..3d873aa 100644
--- a/.gitignore
+++ b/.gitignore
@@ -24,3 +24,4 @@ bugzilla-3.6.1.tar.gz
 /bugzilla-4.4.8.tar.gz
 /bugzilla-4.4.10.tar.gz
 /bugzilla-4.4.11.tar.gz
+/bugzilla-5.0.2.tar.gz
diff --git a/README.fedora.bugzilla b/README.fedora.bugzilla
index 4663885..20725f7 100644
--- a/README.fedora.bugzilla
+++ b/README.fedora.bugzilla
@@ -9,7 +9,7 @@ the values in this file are accurate for your environment.
 
 Once this is done, you may need to modify default settings for your database
 to ensure it accepts Bugzilla data properly.  Please see 
-http://www.bugzilla.org/docs/4.0/en/html/configuration.html for specifics of 
+https://bugzilla.readthedocs.org/en/5.0/ for specifics of
 database setting modifications.
 
 Lastly, simply re-run checksetup.pl to populate the database tables, set up
diff --git a/bugzilla-dnf.patch b/bugzilla-dnf.patch
new file mode 100644
index 000..78c1d18
--- /dev/null
+++ b/bugzilla-dnf.patch
@@ -0,0 +1,20 @@
+--- bugzilla-4.01/Bugzilla/Install/Requirements.pm 2011-05-01 
17:09:35.0 +0200
 bugzilla-4.01-yum/Bugzilla/Install/Requirements.pm 2011-05-01 
17:11:28.0 +0200
+@@ -648,7 +648,7 @@
+ if ($output && $check_results->{any_missing} && !ON_ACTIVESTATE
+ && !$check_results->{hide_all}) 
+ {
+-print install_string('install_all', { perl => $^X });
++# print install_string('install_all', { perl => $^X });
+ }
+ if (!$check_results->{pass}) {
+ print colored(install_string('installation_failed'), COLOR_ERROR),
+@@ -797,7 +797,7 @@
+ $package = $module->{package};
+ }
+ else {
+-$command = "$^X install-module.pl \%s";
++$command = "dnf install \"perl(\%s)\"";
+ # Non-Windows installations need to use module names, because
+ # CPAN doesn't understand package names.
+ $package = $module->{module};
diff --git a/bugzilla-rw-paths.patch b/bugzilla-rw-paths.patch
index 1bad35c..3f60dea 100644
--- a/bugzilla-rw-paths.patch
+++ b/bugzilla-rw-paths.patch
@@ -1,30 +1,35 @@
-diff -up ./Bugzilla/Constants.pm.orig ./Bugzilla/Constants.pm
 ./Bugzilla/Constants.pm.orig   2013-09-02 22:51:11.831245853 +0200
-+++ ./Bugzilla/Constants.pm2013-09-02 22:53:27.733416972 +0200
-@@ -627,20 +627,20 @@ sub bz_locations {
- # make sure this still points to the CGIs.
- 'cgi_path'=> $libpath,
+diff -up bugzilla-5.0.1/Bugzilla/Constants.pm.rw-paths 
bugzilla-5.0.1/Bugzilla/Constants.pm
+--- bugzilla-5.0.1/Bugzilla/Constants.pm.rw-paths  2015-09-10 
21:36:29.0 +0300
 bugzilla-5.0.1/Bugzilla/Constants.pm   2015-09-28 19:20:45.347013271 
+0300
+@@ -670,7 +670,7 @@ sub _bz_locations {
+ $datadir = "data";
+ }
+ 
+-$datadir = "$libpath/$datadir";
++$datadir = "/var/lib/bugzilla/$datadir";
+ # We have to return absolute paths for mod_perl. 
+ # That means that if you modify these paths, they must be absolute paths.
+ return {
+@@ -682,11 +682,11 @@ sub _bz_locations {
  'templatedir' => "$libpath/template",
--'template_cache' => "$datadir/template",
-+'template_cache' => "/var/lib/bugzilla/$datadir/template",
+ 'template_cache' => "$datadir/template",
  'project' => $project,
 -'localconfig' => "$libpath/$localconfig",
--'datadir' => $datadir,
--'attachdir'   => "$datadir/attachments",
 +'localconfig' => "/etc/bugzilla/$localconfig",
-+'datadir' => "/var/lib/bugzilla/$datadir",
-+'attachdir'   => "/var/lib/bugzilla/$datadir/attachments",
+ 'datadir' => $datadir,
+ 'attachdir'   => "$datadir/attachments",
  'skinsdir'=> "$libpath/skins",
 -'graphsdir'   => "$libpath/graphs",
 +'graphsdir'   => "/var/lib/bugzilla/graphs",
  # $webdotdir must be in the web server's tree somewhere. Even if you 
use a 
  # local dot, we output images to there. Also, if $webdotdir is 
  # not relative to the bugzilla root directory, you'll need to 
- # change showdependencygraph.cgi to set image_url to the correct 
- # location.
+@@ -695,7 +695,7 @@ sub _bz_locations {
  # The script should really generate these graphs directly...
--'webdotdir'   => "$datadir/webdot",
-+   

Re: Koji build fails on the same place on i686 in Rawhide

[Kevin Fenzi]

On Fri, 15 Jan 2016 16:23:54 +0100
Dan Horák  wrote:

> On Fri, 15 Jan 2016 16:14:03 +0100
> Peter Lemenkov  wrote:
> 
> > Hello All!
> > I'm afraid I'm stuck with one of my packages. It fails to build on
> > i686 in Rawhide but builds fine if koji was started with
> > --arch-override=i686 (no other builds in parallel).
> > 
> > I suppose I run into some "limits exceeded" issue. Unfortunately all
> > I've got is the segfault during the documentation build.  
> 
> hmm, OOM killer in kernel in action? because both i686 and x86_64
> tasks have used buildhw-11.phx2.fedoraproject.org
> 
> > Technically I could disable docs on i686, but I really don't want
> > to. Could someone take a look inside - what's going on there?
> > 
> > Here is my latest build attempt:
> > 
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=12563046  

Doesn't seem to be OOM to me... in the i686 build.log: 

/bin/sh: line 6: 18505 Segmentation fault  (core dumped) erl -boot
start_clean -noshell -pa ebin -s erl_html_tools top_index
src /builddir/build/BUILD/otp-OTP-18.2.2 ../html 18 -s erlang halt

Is the difference between a working and failed i686 build if it gets a
buildvm or buildhw?

kevin


pgpK9zTii9qWE.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: How to fix a package name with wrong capitalization?

[Mattia Verga]

Il 16/01/2016 17:43, Haïkel ha scritto:


Since this package only hit rawhide, I guess we can accept that releng
fixes the repo and
avoid the rename process.
http://koji.fedoraproject.org/koji/packageinfo?packageID=21440

If it were a stable or branched release, I would insist to follow the
rename process.


I have already opened a review request for renaming package:

https://bugzilla.redhat.com/show_bug.cgi?id=1299147
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: ZFS on linux

[Reindl Harald]

Am 16.01.2016 um 19:43 schrieb Gerald B. Cox:


On Sat, Jan 16, 2016 at 9:55 AM, Kevin Fenzi > wrote:

The benchmark if it's legal to include something in Fedora is
what Fedora Legal says.


I basically would agree with everything you stated, except I would
change the sentence to read:  "The benchmark if it's permissible..."
Fedora has it's own rules, but when you use the term "legal" the
connotation is that the other distributions which are distributing ZFS
are breaking the law


nonsense

if it comes to law topics in many cases 5 lawyers are coming up with 6 
opinions and every decision made has *nothing* to do with any other party



Fedora cannot make that determination


it don't make it for others
it just makes it for Fedora

if Redhat legal says "no" to be on the safe side that has *nothing* to 
do with any otehr distribution



blanket statements like that lead to FUD and misquotes.
If Fedora chooses not to distribute ZFS for any reason, that is
perfectly fine - however, the fact
that we choose not to do so doesn't make it illegal


see above

and now please *stop* this topic
ZFS and external kmods don't make it to Fedora
suck it!



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[EPEL-devel] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 313  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
  76  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
  39  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-f82c6fc04a   
p7zip-15.09-4.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-864da6c179   
nghttp2-1.6.0-1.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e21e03e52f   
mono-2.10.8-9.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-3e181e41ca   
openvpn-2.3.10-1.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e04c714f9d   
gajim-0.16.5-1.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-ec85678f0c   
nodejs-ws-1.0.1-1.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-dd35749dd3   
wordpress-4.4.1-1.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-43613cf75a   
keepassx-0.4.4-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e34ffdd692   
prosody-0.9.9-2.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-273a82f7db   
owncloud-8.0.10-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-8da165e1bb   
mbedtls-2.2.1-1.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-6f526f521d   
python-rsa-3.3-2.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-925e9374c9   
python-pymongo-3.0.3-1.el7


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

atomic-reactor-1.6.1-1.el7
gpaste-3.14.4.1-1.el7
libisds-0.10.2-1.el7
libwhirlpool-1.0-1.el7
log4cplus-1.1.3-0.4.rc3.el7
perl-WWW-Twilio-API-0.18-2.el7
php-symfony-2.7.9-2.el7
python-beanbag-1.9.2-2.el7
python-pymongo-3.0.3-1.el7
python3-PyYAML-3.11-2.el7
smtpping-1.1.2-2.el7
tayga-0.9.2-3.el7

Details about builds:



 atomic-reactor-1.6.1-1.el7 (FEDORA-EPEL-2016-e9f7a6ffe3)
 Improved builder for Docker images

Update Information:

New upstream release.




 gpaste-3.14.4.1-1.el7 (FEDORA-EPEL-2016-d2f94b1cf4)
 Clipboard management system

Update Information:

GNOME 3.14 support

References:

  [ 1 ] Bug #1288281 - gnome-shell-extension-gpaste is not compatible with EL 
7.2
https://bugzilla.redhat.com/show_bug.cgi?id=1288281




 libisds-0.10.2-1.el7 (FEDORA-EPEL-2016-a1783f74ea)
 Library for accessing the Czech Data Boxes

Update Information:

This release fixes building with disabled libxurl support.




 libwhirlpool-1.0-1.el7 (FEDORA-EPEL-2016-969ea72593)
 Whirlpool cryptographic hash function library

Update Information:

1.0 -- 2015-12-16* First public release

References:

  [ 1 ] Bug #1292216 - Review Request: libwhirlpool - Whirlpool cryptographic 
hash function library
https://bugzilla.redhat.com/show_bug.cgi?id=1292216




 log4cplus-1.1.3-0.4.rc3.el7 (FEDORA-EPEL-2016-2b0a5fdc60)
 Logging Framework for C++

Update Information:

Fixed one bug

References:

  [ 1 ] Bug #1297906 - log4cplus is not compiled with C++11 support because of 
typo in spec
https://bugzilla.redhat.com/show_bug.cgi?id=1297906




 perl-WWW-Twilio-API-0.18-2.el7 (FEDORA-EPEL-2016-7eef5cd0bf)
 Accessing Twilio's REST API with Perl

Update Information:

Revision history for Perl extension 

[Bug 1297527] Review Request: perl-WWW-Twilio-API - Accessing Twilio's REST API with Perl

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1297527

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #11 from Fedora Update System  ---
perl-WWW-Twilio-API-0.18-2.el7 has been pushed to the Fedora EPEL 7 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-7eef5cd0bf

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: ZFS on linux

[Chris Murphy]

On Sat, Jan 16, 2016 at 12:39 PM, Luya Tshimbalanga
 wrote:
> Does Oracle include ZFS in their ISO by default?

No, and as far as I know they don't contribute to ZFS on Linux. There
is a distinction between ZFS and OpenZFS that's kinda important. ZFS
on Linux is based on OpenZFS, not ZFS. There're incompatible features
since pool version 28 in each, so they're essentially diverging. I
don't know if that qualifies them as defacto forks (either from each
other, or from ZFS pool version 28). Anyway, Oracle only includes ZFS
in Solaris. And they continue to contribute to Btrfs.


-- 
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Koji build fails on the same place on i686 in Rawhide

[Kevin Fenzi]

On Sat, 16 Jan 2016 21:21:40 +0100
Peter Lemenkov  wrote:

> The only difference was --arch-override=i686 for a successful build.

So that was also a scratch build vs a real one?

> This was an out-of-memory issue. I've changed Java environmental
> variables from -Xmx1024m to -Xmx512m and it builds fine now!
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=12578827
> 
> Although I think it's safe to say that the issue is fixed now
> (workaround applied).  I'd like to have more details about Koji jobs.
> 
> Also it would be great if different build tasks won't interfere with
> each other. I suppose that the limits should be applied to each
> arch-build separately rather than for the entire task.

They should only apply to each task. Each task is done on whatever
builders are available. Its pretty rare that multiple tasks from the
same build would end up on the same builder (but obviously not
impossible). Each task is done in it's own mock chroot, so settings
in one shouldn't matter for settings in another. 

The only thing I can think of here is somehow the failed builds always
landed on buildhw vs buildvm or something. 

kevin
 



pgpalR5jfUDlQ.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: ZFS on linux

[Reindl Harald]

Am 16.01.2016 um 22:07 schrieb Neal Gompa:

On Sat, Jan 16, 2016 at 3:00 PM, Chris Murphy  wrote:

On Sat, Jan 16, 2016 at 12:39 PM, Luya Tshimbalanga
 wrote:

Does Oracle include ZFS in their ISO by default?


No, and as far as I know they don't contribute to ZFS on Linux. There
is a distinction between ZFS and OpenZFS that's kinda important. ZFS
on Linux is based on OpenZFS, not ZFS. There're incompatible features
since pool version 28 in each, so they're essentially diverging. I
don't know if that qualifies them as defacto forks (either from each
other, or from ZFS pool version 28). Anyway, Oracle only includes ZFS
in Solaris. And they continue to contribute to Btrfs.


They do, however, include DTrace in their distribution, which remains
CDDL licensed in their distribution


stop that FUD - CDDL is not the problem - MIXING is the topic
and don't bring "cdrecrord" to the topic, the author is the problem

back to topic:
even if DTrace would be closed source Oracle could include it because 
tehy are the *copyright holder* and can release it under *every* license 
they like to do





signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: ZFS on linux

[Reindl Harald]

Am 16.01.2016 um 22:19 schrieb Neal Gompa:

On Sat, Jan 16, 2016 at 4:18 PM, Reindl Harald  wrote:



Am 16.01.2016 um 22:07 schrieb Neal Gompa:


On Sat, Jan 16, 2016 at 3:00 PM, Chris Murphy 
wrote:


On Sat, Jan 16, 2016 at 12:39 PM, Luya Tshimbalanga
 wrote:


Does Oracle include ZFS in their ISO by default?


No, and as far as I know they don't contribute to ZFS on Linux. There
is a distinction between ZFS and OpenZFS that's kinda important. ZFS
on Linux is based on OpenZFS, not ZFS. There're incompatible features
since pool version 28 in each, so they're essentially diverging. I
don't know if that qualifies them as defacto forks (either from each
other, or from ZFS pool version 28). Anyway, Oracle only includes ZFS
in Solaris. And they continue to contribute to Btrfs.


They do, however, include DTrace in their distribution, which remains
CDDL licensed in their distribution


stop that FUD - CDDL is not the problem - MIXING is the topic
and don't bring "cdrecrord" to the topic, the author is the problem

back to topic:
even if DTrace would be closed source Oracle could include it because tehy
are the *copyright holder* and can release it under *every* license they
like to do


DTrace is a kernel module that is CDDL licensed in Oracle Linux. So, not FUD


come on get a laywer and dicuss that topic somewhere else

first they laywer needs to find out *which* of both licenses maybe 
violated - if it's the CDDL then it's no problem for Oracle, if it's the 
GPL, well it needs a lawsuit in doubt


IT DOES NOT MATTER what Oracle does
IT DOES NOT MATTER what anybody else does
ABOVE DOES NOT MATTER for Fedora

licensing is a minefield and hence Fedora / Redhat legal stays on the 
SAVE SIDE - so WHAT needs to be discussed again and again


and since you still did not realize it:
even without the legal questions a out-of-tree module WON'T make it into 
Fedora and so the whole topic is done






signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: ZFS on linux

[Kevin Fenzi]

On Sat, 16 Jan 2016 10:43:12 -0800
"Gerald B. Cox"  wrote:

> On Sat, Jan 16, 2016 at 9:55 AM, Kevin Fenzi  wrote:
> 
> > The benchmark if it's legal to include something in Fedora is
> > what Fedora Legal says.
> >  
> 
> I basically would agree with everything you stated, except I would
> change the sentence to read:  "The benchmark if it's permissible..."
> Fedora has it's own rules, but when you use the term "legal" the
> connotation is that the other distributions which are distributing ZFS
> are breaking the law.  Fedora cannot make that determination; and
> blanket statements like that lead to FUD and misquotes.
> If Fedora chooses not to distribute ZFS for any reason, that is
> perfectly fine - however, the fact
> that we choose not to do so doesn't make it illegal.

I can't image anyone misinterpreting my statement that way, but yes, I
was not trying to suggest anything anyone else does is legal or not,
simply that any inclusion in Fedora would need approval of Fedora legal
and continuing to post about it or speculate is just a waste of time. 

kevin



pgpQNrc2056lX.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Standard, consistent subject lines for automated emails

[Kevin Fenzi]

On Sat, 16 Jan 2016 13:34:12 +
"Richard W.M. Jones"  wrote:

> Here are a small collection of subject lines of emails sent
> automatically to me by various Fedora systems in the past few days:
> 
> Subject: upgradepath PASSED for FEDORA-2015-850e89be8b
> Subject: [Fedora Update] [comment] auto-buildrequires-1.2-1.fc23
> Subject: rjones's libguestfs-1.33.1-2.fc24 completed
> Subject: rpmlint PASSED for libguestfs-1.33.1-2.fc24
> Subject: Broken dependencies: libguestfs
> Subject: ABRT report for package gnome-boxes has reached 10
> occurrences Subject: [Bug 1269975] svirt very occasionally prevents
> parallel libvirt [..] Subject: Fedora 'packager' sponsor needed for
> suanand Subject: sailer's mingw-sqlite-3.10.1.0-1.fc24 failed to build
> Subject: libguestfs's builds are back to normal in f24
> Subject: dchen pushed to ocaml-lwt (el6).  "New upstream version
> 2.2.0."
> 
> The only consistent thing is there's nothing consistent about them :-/
> 
> I'd like to propose a very lightweight "standard" for subject lines of
> emails.
...snip...

I think this is a great idea! 

I'll bring up the subject on the infrastructure list and see what folks
there think of it. 

kevin




pgpWFa2xLxycD.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: ZFS on linux

[Reindl Harald]

Am 16.01.2016 um 20:51 schrieb Gerald B. Cox:

On Sat, Jan 16, 2016 at 11:35 AM, Kevin Fenzi > wrote:

I can't image anyone misinterpreting my statement that way, but yes, I
was not trying to suggest anything anyone else does is legal or not,
simply that any inclusion in Fedora would need approval of Fedora legal
and continuing to post about it or speculate is just a waste of time.

ROFL... you know the internet Kevin... and any conspiracy theory can and
will be
propagated... but I didn't believe you intended to imply that...


hence the next time as Fedora legal directly instead repeat the same 
discussion again (it's not the first time this topic appeared) where 
people in the thread even point to "Oracle Linux" with "but they do too" 
while Orcale holds all copryrights and patents in ZFS after buyed Sun 
long ago




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Koji build fails on the same place on i686 in Rawhide

[Peter Lemenkov]

2016-01-16 18:49 GMT+01:00 Kevin Fenzi :
> On Fri, 15 Jan 2016 16:23:54 +0100
> Dan Horák  wrote:
>
>> On Fri, 15 Jan 2016 16:14:03 +0100
>> Peter Lemenkov  wrote:
>>
>> > Hello All!
>> > I'm afraid I'm stuck with one of my packages. It fails to build on
>> > i686 in Rawhide but builds fine if koji was started with
>> > --arch-override=i686 (no other builds in parallel).
>> >
>> > I suppose I run into some "limits exceeded" issue. Unfortunately all
>> > I've got is the segfault during the documentation build.
>>
>> hmm, OOM killer in kernel in action? because both i686 and x86_64
>> tasks have used buildhw-11.phx2.fedoraproject.org
>>
>> > Technically I could disable docs on i686, but I really don't want
>> > to. Could someone take a look inside - what's going on there?
>> >
>> > Here is my latest build attempt:
>> >
>> > http://koji.fedoraproject.org/koji/taskinfo?taskID=12563046
>
> Doesn't seem to be OOM to me... in the i686 build.log:
>
> /bin/sh: line 6: 18505 Segmentation fault  (core dumped) erl -boot
> start_clean -noshell -pa ebin -s erl_html_tools top_index
> src /builddir/build/BUILD/otp-OTP-18.2.2 ../html 18 -s erlang halt
>
> Is the difference between a working and failed i686 build if it gets a
> buildvm or buildhw?

The only difference was --arch-override=i686 for a successful build.

This was an out-of-memory issue. I've changed Java environmental
variables from -Xmx1024m to -Xmx512m and it builds fine now!

http://koji.fedoraproject.org/koji/taskinfo?taskID=12578827

Although I think it's safe to say that the issue is fixed now
(workaround applied).  I'd like to have more details about Koji jobs.

Also it would be great if different build tasks won't interfere with
each other. I suppose that the limits should be applied to each
arch-build separately rather than for the entire task.

-- 
With best regards, Peter Lemenkov.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[EPEL-devel] Fedora EPEL 6 updates-testing report

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 209  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-6828   
chicken-4.9.0.1-4.el6
 192  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7031   
python-virtualenv-12.0.7-1.el6
 186  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 117  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-8148   
optipng-0.7.5-5.el6
 117  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-8156   
nagios-4.0.8-1.el6
  76  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
  47  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-9514f006a5   
mono-2.10.8-5.el6
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-b654a785a7   
openvpn-2.3.10-1.el6
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-83e43636a6   
nodejs-ws-1.0.1-1.el6
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-819f6356ea   
tomcat-7.0.65-1.el6
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-77ee2edf04   
wordpress-4.4.1-1.el6
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-550132e830   
flite-1.3-24.el6
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-7601108cdf   
keepassx-0.4.4-1.el6
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-570414d664   
prosody-0.9.9-2.el6
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-2b26e78b1e   
owncloud-7.0.12-1.el6
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-75614c9a4f   
mbedtls-2.2.1-1.el6
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-7aa48cd8b9   
python-rsa-3.3-2.el6


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

libwhirlpool-1.0-1.el6
open-vm-tools-9.10.2-1.el6
perl-WWW-Twilio-API-0.18-2.el6
radcli-1.2.5-1.el6
smtpping-1.1.2-2.el6
tayga-0.9.2-3.el6

Details about builds:



 libwhirlpool-1.0-1.el6 (FEDORA-EPEL-2016-71fb68b388)
 Whirlpool cryptographic hash function library

Update Information:

1.0 -- 2015-12-16* First public release

References:

  [ 1 ] Bug #1292216 - Review Request: libwhirlpool - Whirlpool cryptographic 
hash function library
https://bugzilla.redhat.com/show_bug.cgi?id=1292216




 open-vm-tools-9.10.2-1.el6 (FEDORA-EPEL-2016-6c12e8a733)
 Open Virtual Machine Tools for virtual machines hosted on VMware

Update Information:

Update to bring the package version on par with the RHEL 7 one.

References:

  [ 1 ] Bug #1295000 - open-vm-tools in EPEL 6 too old
https://bugzilla.redhat.com/show_bug.cgi?id=1295000




 perl-WWW-Twilio-API-0.18-2.el6 (FEDORA-EPEL-2016-2807c20ee4)
 Accessing Twilio's REST API with Perl

Update Information:

Revision history for Perl extension WWW::Twilio::API.   r24 | scott | 2014-10-13
10:24:23 -0600 (Mon, 13 Oct 2014) | 1 line   - document utf8 argument
  r23 |
scott | 2014-10-13 10:17:31 -0600 (Mon, 13 Oct 2014) | 1 line   - version bump:
0.18  
r22 | scott | 2014-10-13 10:17:07 -0600 (Mon, 13 Oct 2014) | 1 line   - enable
utf8 support [Kris Matthews] [rt#98963]0.17 - LWP callback support (thanks:
Preston Gilchrist)
  r20 |
scott | 2012-07-14 21:17:56 -0600 (Sat, 14 Jul 2012) | 1 line   - LWP callback
added (Preston Gilchrist)
0.16
- GET parameters (e.g., SMS/Messages) are now passed correctly
  r17 |
scott | 2011-10-10 20:47:27 -0600 (Mon, 10 Oct 2011) | 2 lines   - fixes for GET
parameters


References:

  [ 1 ] Bug #1297527 - Review Request: perl-WWW-Twilio-API - Accessing 

Re: Koji build fails on the same place on i686 in Rawhide

[Peter Lemenkov]

2016-01-16 21:51 GMT+01:00 Kevin Fenzi :
> On Sat, 16 Jan 2016 21:21:40 +0100
> Peter Lemenkov  wrote:
>
>> The only difference was --arch-override=i686 for a successful build.
>
> So that was also a scratch build vs a real one?

No. If I start scratchbuild w/o arch-override it also fails. if I add
--arch-override it works fine.


-- 
With best regards, Peter Lemenkov.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[EPEL-devel] MPI Fortran compiler detection failed on EPEL7

[Antonio Trande]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello everybody,

OpenMPI Fortran compiler detection fails during
Sundials-OpenMPI(1.10.0) rebuilds on EPEL7:

http://koji.fedoraproject.org/koji/taskinfo?taskID=12582324

Unexpectedly, cmake's Fortran compiler test works on ppc64le arch,
but fails on x86_64.

> 
> -- Looking for MPI Fortran compiler script 
> /usr/lib64/openmpi/bin/mpifort

> -- Trying to compile and link a simple MPI Fortran program...
> FAILED
> 

This does not happen on Fedora (OpenMPI-1.8.8) and EPEL6
(OpenMPI-1.8.1);  see

http://koji.fedoraproject.org/koji/taskinfo?taskID=12581901 (rawhide)
http://koji.fedoraproject.org/koji/taskinfo?taskID=12582140 (epel6)

Am I missing something?
Any comment/idea?

Regards.
- -- 
Antonio Trande

mailto: sagitter 'at' fedoraproject 'dot' org
http://fedoraos.wordpress.com/
https://fedoraproject.org/wiki/User:Sagitter
GPG Key: 0x565E653C
Check on https://keys.fedoraproject.org/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWmsfdAAoJEF5tK7VWXmU8Q8AH/2ZQQ1NUlhGwzHNsu9e50a9X
BoxG3K2M/nYYXePR+qQ61rBEZNPW3KS8TGaq688sjU+CuECzBws+nrQHn+pKbc0I
lNt0BqN1//lb5a0F2d6cwaoQkAYFeSKz6Ap0rAQiS4mVuSVCajDItFnjKpJ8JhSC
MjlZ9hekvcrkfS0Es/ARDYk2yx29W9C/Ehe9KVeN3Cl9tnzwoKmnyKCW+lOCEHWq
3AGVPfl/Z9mjPuKh4Aonb43bDEaSyfEdJo3LZUV9dfP7KxuJ5F4xAJ8dGhOVlDdi
gGzBVnSYiEjmlpOykHfLHoA5h/6QLZQw3MctqVub5sfqI1ish3qw2X4pkwtoLfI=
=8mTb
-END PGP SIGNATURE-
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

limb created the branch 'el5' for the package 'perl-Crypt-RC4'

[notifications]

limb created the branch 'el5' for the package 'perl-Crypt-RC4'
https://admin.fedoraproject.org/pkgdb/package/perl-Crypt-RC4/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

limb changed robert's 'watchcommits' permission on perl-Crypt-RC4 (el5) to 'Approved'

[notifications]

limb changed robert's 'watchcommits' permission on perl-Crypt-RC4 (el5) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Crypt-RC4/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

limb changed robert's 'commit' permission on perl-Crypt-RC4 (el5) to 'Approved'

[notifications]

limb changed robert's 'commit' permission on perl-Crypt-RC4 (el5) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Crypt-RC4/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

limb changed robert's 'watchbugzilla' permission on perl-Crypt-RC4 (el5) to 'Approved'

[notifications]

limb changed robert's 'watchbugzilla' permission on perl-Crypt-RC4 (el5) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Crypt-RC4/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

limb changed robert's 'approveacls' permission on perl-Crypt-RC4 (el5) to 'Approved'

[notifications]

limb changed robert's 'approveacls' permission on perl-Crypt-RC4 (el5) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Crypt-RC4/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

limb changed robert's branch request for perl-Crypt-RC4 in el5 from Awaiting Review to Approved

[notifications]

limb changed robert's branch request for perl-Crypt-RC4 in el5 from Awaiting 
Review to Approved
https://admin.fedoraproject.org/pkgdb/package/perl-Crypt-RC4/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1297527] Review Request: perl-WWW-Twilio-API - Accessing Twilio's REST API with Perl

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1297527



--- Comment #12 from Fedora Update System  ---
perl-WWW-Twilio-API-0.18-2.fc22 has been pushed to the Fedora 22 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2016-a21b459a4e

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: ZFS on linux

[Luya Tshimbalanga]

On 14/01/16 02:28 PM, Dave Love wrote:
> Reindl Harald  writes:
>
 who is "Lawrence Livermore"?
>>> Lawrence Livermore National Laboratory is an organization founded by
>>> the University of California to do research and development for
>>> academic and government purposes. The US Department of Energy
>>> commissioned them to port ZFS to Linux quite a long time ago[0], which
>>> is the foundation of the current ZFS on Linux codebase.
>> and they build a large, genral purpose, linux distribution?
> Doubtless it doesn't count, but an old version of the LLNL HPC-oriented
> GNU/Linux distribution which incorporates ZFS is at
> .  (I don't know
> if the RHEL7-derived one is published.)  There's another from a US lab
> that you may have heard of
> .
>
> There is a distribution of Linux by a US corporation with CDDL modules
> 
> for their general purpose GNU/Linux distribution.
>
Does Oracle include ZFS in their ISO by default? If so, it is asking for
trouble by violating GPL license mixing with an incompatible CDDL. Note
that Oracle owns ZFS and has the liberty to sue any large commercial
distribution. For that reason, it is not worth a legal risk.

-- 
Luya Tshimbalanga
Graphic & Web Designer
E: l...@fedoraproject.org
W: http://www.coolest-storm.net
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: ZFS on linux

[Gerald B. Cox]

On Sat, Jan 16, 2016 at 11:35 AM, Kevin Fenzi  wrote:

> I can't image anyone misinterpreting my statement that way, but yes, I
> was not trying to suggest anything anyone else does is legal or not,
> simply that any inclusion in Fedora would need approval of Fedora legal
> and continuing to post about it or speculate is just a waste of time.
>

ROFL... you know the internet Kevin... and any conspiracy theory can and
will be
propagated... but I didn't believe you intended to imply that...
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[Bug 1297527] Review Request: perl-WWW-Twilio-API - Accessing Twilio's REST API with Perl

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1297527



--- Comment #13 from Fedora Update System  ---
perl-WWW-Twilio-API-0.18-2.el6 has been pushed to the Fedora EPEL 6 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-2807c20ee4

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: ZFS on linux

[Neal Gompa]

On Sat, Jan 16, 2016 at 3:00 PM, Chris Murphy  wrote:
> On Sat, Jan 16, 2016 at 12:39 PM, Luya Tshimbalanga
>  wrote:
>> Does Oracle include ZFS in their ISO by default?
>
> No, and as far as I know they don't contribute to ZFS on Linux. There
> is a distinction between ZFS and OpenZFS that's kinda important. ZFS
> on Linux is based on OpenZFS, not ZFS. There're incompatible features
> since pool version 28 in each, so they're essentially diverging. I
> don't know if that qualifies them as defacto forks (either from each
> other, or from ZFS pool version 28). Anyway, Oracle only includes ZFS
> in Solaris. And they continue to contribute to Btrfs.
>

They do, however, include DTrace in their distribution, which remains
CDDL licensed in their distribution.



-- 
真実はいつも一つ！/ Always, there's only one truth!
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: ZFS on linux

[Neal Gompa]

On Sat, Jan 16, 2016 at 4:18 PM, Reindl Harald  wrote:
>
>
> Am 16.01.2016 um 22:07 schrieb Neal Gompa:
>>
>> On Sat, Jan 16, 2016 at 3:00 PM, Chris Murphy 
>> wrote:
>>>
>>> On Sat, Jan 16, 2016 at 12:39 PM, Luya Tshimbalanga
>>>  wrote:

 Does Oracle include ZFS in their ISO by default?
>>>
>>>
>>> No, and as far as I know they don't contribute to ZFS on Linux. There
>>> is a distinction between ZFS and OpenZFS that's kinda important. ZFS
>>> on Linux is based on OpenZFS, not ZFS. There're incompatible features
>>> since pool version 28 in each, so they're essentially diverging. I
>>> don't know if that qualifies them as defacto forks (either from each
>>> other, or from ZFS pool version 28). Anyway, Oracle only includes ZFS
>>> in Solaris. And they continue to contribute to Btrfs.
>>
>>
>> They do, however, include DTrace in their distribution, which remains
>> CDDL licensed in their distribution
>
>
> stop that FUD - CDDL is not the problem - MIXING is the topic
> and don't bring "cdrecrord" to the topic, the author is the problem
>
> back to topic:
> even if DTrace would be closed source Oracle could include it because tehy
> are the *copyright holder* and can release it under *every* license they
> like to do
>

DTrace is a kernel module that is CDDL licensed in Oracle Linux. So, not FUD.



-- 
真実はいつも一つ！/ Always, there's only one truth!
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Appdata files template for Fedora Workstation

[Luya Tshimbalanga]

Based on the Workstation wiki related to appdata addons[1], I created
each metainfo.xml for the missing addons including for some applications
like Blender.[2]

Nearly all on them are associated with the related applications and it
is a matter of filling the missing informations. Each metainfo.xml is
validated by appstream-lib so downstream can submit the completed addon
appdata to upstream.

For more details, please read
http://www.freedesktop.org/software/appstream/docs/sect-Quickstart-Addons.html


P.S: I realized I forgot to add .desktop extension but the guideline
will suffice.

Reference:
---
[1] https://fedoraproject.org/wiki/Workstation/AddonAppdata
[2] https://luya.fedorapeople.org/appdata/

-- 
Luya Tshimbalanga
Graphic & Web Designer
E: l...@fedoraproject.org
W: http://www.coolest-storm.net
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[EPEL-devel] Re: MPI Fortran compiler detection failed on EPEL7

[Orion Poplawski]

On 01/16/2016 03:44 PM, Antonio Trande wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello everybody,

OpenMPI Fortran compiler detection fails during
Sundials-OpenMPI(1.10.0) rebuilds on EPEL7:

http://koji.fedoraproject.org/koji/taskinfo?taskID=12582324

Unexpectedly, cmake's Fortran compiler test works on ppc64le arch,
but fails on x86_64.



-- Looking for MPI Fortran compiler script
/usr/lib64/openmpi/bin/mpifort



-- Trying to compile and link a simple MPI Fortran program...
FAILED



This does not happen on Fedora (OpenMPI-1.8.8) and EPEL6
(OpenMPI-1.8.1);  see

http://koji.fedoraproject.org/koji/taskinfo?taskID=12581901 (rawhide)
http://koji.fedoraproject.org/koji/taskinfo?taskID=12582140 (epel6)

Am I missing something?
Any comment/idea?


Really impossible to tell without the cmake output logs, specifically 
CMakeFiles/CMakeError.log.


--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Re: New tbb in Rawhide

[Jerry James]

Jonathan,

On Fri, Jan 15, 2016 at 3:43 PM, Jonathan Wakely
 wrote:
> How soon will you be doing the rebuilds?
>
> gazebo also needs to be rebuilt for Boost 1.60, which I'm currently
> doing in the f24-boost side tag. If you're going to be rebuilding it
> soon anyway shall I wait and not do gazebo?
>
> And if you get round to it soon, it would be better to also use the
> f24-boost side tag, so that it rebuilds using the new boost-1.60.0
> package at the same time as the new tbb.

I'm very sorry.  That would have been great, but I in fact started the
rebuilds pretty much simultaneously with sending the previous message,
so I did not rebuild in the side tag.  I apologize for my impatience.
-- 
Jerry James
http://www.jamezone.org/
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Standard, consistent subject lines for automated emails

[Adam Williamson]

On Sat, 2016-01-16 at 12:54 -0700, Kevin Fenzi wrote:
> On Sat, 16 Jan 2016 13:34:12 +
> "Richard W.M. Jones"  wrote:
> 
> > Here are a small collection of subject lines of emails sent
> > automatically to me by various Fedora systems in the past few days:
> > 
> > Subject: upgradepath PASSED for FEDORA-2015-850e89be8b
> > Subject: [Fedora Update] [comment] auto-buildrequires-1.2-1.fc23
> > Subject: rjones's libguestfs-1.33.1-2.fc24 completed
> > Subject: rpmlint PASSED for libguestfs-1.33.1-2.fc24
> > Subject: Broken dependencies: libguestfs
> > Subject: ABRT report for package gnome-boxes has reached 10
> > occurrences Subject: [Bug 1269975] svirt very occasionally prevents
> > parallel libvirt [..] Subject: Fedora 'packager' sponsor needed for
> > suanand Subject: sailer's mingw-sqlite-3.10.1.0-1.fc24 failed to build
> > Subject: libguestfs's builds are back to normal in f24
> > Subject: dchen pushed to ocaml-lwt (el6).  "New upstream version
> > 2.2.0."
> > 
> > The only consistent thing is there's nothing consistent about them :-/
> > 
> > I'd like to propose a very lightweight "standard" for subject lines of
> > emails.
> ...snip...
> 
> I think this is a great idea! 
> 
> I'll bring up the subject on the infrastructure list and see what folks
> there think of it. 

I'm happy to take requests for the check-compose emails, if a common
scheme is decided.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Another strange Koji error

[Mattia Verga]

I was trying to do a scratch build for a review ticket submission and I 
got this:

http://koji.fedoraproject.org/koji/taskinfo?taskID=12578072

All builds on different architectures are ok, but in the build result it 
says something strange about static libraries.
This is the first time I compile a package with static libraries, can 
someone explain me about this error?


Thanks
Mattia
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org