Re: Clang error: unknown target CPU 'pentium-m'
Sergio Pascual wrote: > I imaging that -march=native is returning the arch of the builder, that is > not supported. How can I make this work? -march=native is NOT allowed in distribution packages. It means to compile binaries which only run on the machine it is compiled on. (-mtune=native would be more tolerable, but still doesn't make sense, why would you want to tune based on what the builder happens to be?) The package needs fixing to use sane compiler flags (ideally our RPM_OPT_FLAGS, if Clang can grok those, otherwise an as large subset of them as possible, but no bogus extra flags such as -march=native, and -O3 is also usually frowned upon). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADSUP] Atlas changed libraries
Susi Lehtola wrote: > FPC maintains packaging guidelines. If you think that BLAS/LAPACK > packages should have their own guideline, then file a proposition to > the FPC. FESCO is still there if the matter needs to be escalated from > the FPC. https://fedorahosted.org/fpc/ticket/352 Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADSUP] Atlas changed libraries
Susi Lehtola wrote:
> Yes, but everyone knows that if you want ATLAS, the link command is
> -L%{_libdir} -llapack -lf77blas -latlas
"Everyone knows"? I think pretty much everyone expects to link their stuff
with -llapack -lblas and get the most efficient implementation out there,
especially when ATLAS *already* goes through the trouble of overriding all
these libraries:
libcblas.so.3
libclapack.so.3
libf77blas.so.3
liblapack.so.3
libptcblas.so.3
libptf77blas.so.3
Only libblas.so.3 is renamed to libatlas.so.3 for some reason I cannot
fathom.
The behavior is inconsistent and broken. But the new behavior, while more
consistent, is at least as broken. There is ONE correct behavior (and that
goes for ANY BLAS/LAPACK implementation: ATLAS, OpenBLAS etc.): ship
libblas.so.3 and liblapack.so.3, NOT libjoesblas.so.31337.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dbh and/or DBH
On Sat, Sep 28, 2013 at 09:24:11PM +0200, Antonio Trande wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi all. > > Are the dbh package (http://pkgs.fedoraproject.org/cgit/dbh.git/) and > the DBH from http://sourceforge.net/projects/dbh/files/dbh/5.0.7/ same > software ? Yes. It looks as if Fedora is shipping a truely ancient version (from 2005!). The sourceforge page appears to be the new location of the upstream. For some reason I can't quite work out, the version numbers lept from 1.0.24 -> 4.5.0 in 2006, even though it seems to be maintained by the same author. Probably a good idea to ask the Fedora maintainer. I see you've already filed a bug about it: https://bugzilla.redhat.com/show_bug.cgi?id=1013710 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: LVM thinp expectations in anaconda 20
On Sep 30, 2013, at 10:34 AM, Alasdair G Kergon wrote: > On Mon, Sep 30, 2013 at 10:04:08AM -0600, Chris Murphy wrote: >> For an LV to take advantage of thinp snapshots needs to be a virtual >> size LV drawn from the thin pool, correct? So it is a virtual size LV >> in any case, it's just that the installer isn't going to let users >> specify total LV virtual sizes greater than the pool, right? > > Yes, that's my undestanding.\ Tried it and checked the anaconda log, and the resulting layout with ssm list. It's as described. LVs home and root are virtual sized LV's, and swap is a conventional LV. One problem though is that the resulting system doesn't boot. I'm dropped to a dracut shell. Filed a bug: https://bugzilla.redhat.com/show_bug.cgi?id=1013767 Chris Murphy -- 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: LVM thinp expectations in anaconda 20
On Mon, Sep 30, 2013 at 10:04:08AM -0600, Chris Murphy wrote: > For an LV to take advantage of thinp snapshots needs to be a virtual > size LV drawn from the thin pool, correct? So it is a virtual size LV > in any case, it's just that the installer isn't going to let users > specify total LV virtual sizes greater than the pool, right? Yes, that's my undestanding. Alasdair -- 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: LVM thinp expectations in anaconda 20
On Sep 27, 2013, at 12:59 PM, Alasdair G Kergon wrote: > On Fri, Sep 27, 2013 at 11:55:43AM -0600, Chris Murphy wrote: >> I still can't choose a Desired Capacity that's larger than free space >> in the VG. Ergo, I can't create a virtual size LV. Is this expected? > > At this stage, yes. It might change in future, but I think it was felt > to be both too much code to change and too much change for users to take > on board if it was all changed at once. For an LV to take advantage of thinp snapshots needs to be a virtual size LV drawn from the thin pool, correct? So it is a virtual size LV in any case, it's just that the installer isn't going to let users specify total LV virtual sizes greater than the pool, right? Chris Murphy -- 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: what left in mass rebuild x264/ffmpeg for F20
Am 30.09.2013 05:28, schrieb Sérgio Basto: > Hi, checking whatrequires ffmpeg-libs and x264-libs, and can't install > on F20 vm is : > > mythtv > acoustid-fingerprinter > bino > bombono-dvd > chromaprint-tools > dvbcut > ffmpegthumbnailer > ffmpegthumbs > gstreamer1-libav > k3b-extras-freeworld > kmediafactory > lightspark > mlt > mpd > qmmp-plugins-freeworld > xbmc > xine-lib-extras-freeworld and these are all *rpmfusion* packages as well as ffmpeg and x264 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Owner-change] Fedora packages ownership change
Change in ownership over the last 168 hours === 1 packages were orphaned python-zope-interface [EL-5,devel,f18,f19,f20] was orphaned by fschwarz Zope 3 Interface Infrastructure https://admin.fedoraproject.org/pkgdb/acls/name/python-zope-interface 5 packages unorphaned - kalev unorphaned : gnome-backgrounds [devel,f18,f19,f20] kalev unorphaned : gnome-icon-theme [devel,f18,f19,f20] mbooth unorphaned : bouncycastle [devel,f18,f19,f20] besser82unorphaned : quilt [EL-5,EL-6] mbooth unorphaned : bouncycastle-mail [devel,f18,f19,f20] 3 packages were retired olpc-library [devel] was retired by dsd OLPC library page generator https://admin.fedoraproject.org/pkgdb/acls/name/olpc-library libeio [devel,f20] was retired by patches Event-based fully asynchronous I/O library https://admin.fedoraproject.org/pkgdb/acls/name/libeio linpack [EL-5,EL-6,devel,f18,f19,f20] was retired by besser82 FORTRAN subroutines to analyze and solve linear equations https://admin.fedoraproject.org/pkgdb/acls/name/linpack 3 packages changed owner limbgave to valtri : canl-c [EL-5] limbgave to mrunge : python-django-tagging [EL-5] kevin gave to orion : libdwarf [EL-6] Sources: https://github.com/pypingou/fedora-owner-change -- 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: bcache-tools and bcache support in other linux packages
On Sep 30, 2013, at 9:04 AM, Rolf Fokkens wrote: > Hi > > It was brought to my attention that there's a confusing typo in the > message below regarding the planning of bcache support for anaconda. The > claim that it is planned for F20 is not true, it is planned for F21: > > https://fedorahosted.org/fesco/ticket/1145 Is there no chance for Intel SRT support in the kernel? There's an increasing amount of hardware shipping with the feature enabled (e.g. from HP) and of course this isn't supported. Presently anaconda indicates to the user there are no drives at all attached, no destination for installation. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Mozilla-PublicSuffix] Update to 0.1.16 Drop upstreamed patch
commit 54e49a8b9fba2d99dfefb8fe4d1cc19646cf7e07
Author: Yanko Kaneti
Date: Mon Sep 30 18:05:45 2013 +0300
Update to 0.1.16
Drop upstreamed patch
.gitignore |1 +
...atest-suffix-list-and-fixup-test-01-accor.patch | 36
perl-Mozilla-PublicSuffix.spec | 12 +++---
sources|2 +-
4 files changed, 8 insertions(+), 43 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 4268dbd..34ca667 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
/Mozilla-PublicSuffix-v0.1.13.tar.gz
/Mozilla-PublicSuffix-v0.1.15.tar.gz
+/Mozilla-PublicSuffix-v0.1.16.tar.gz
diff --git a/perl-Mozilla-PublicSuffix.spec b/perl-Mozilla-PublicSuffix.spec
index 60c8450..e7594e2 100644
--- a/perl-Mozilla-PublicSuffix.spec
+++ b/perl-Mozilla-PublicSuffix.spec
@@ -1,8 +1,8 @@
%global publicsuffix_date 20130918
Name: perl-Mozilla-PublicSuffix
-Version:0.1.15
-Release:3.%{publicsuffix_date}%{?dist}
+Version:0.1.16
+Release:1.%{publicsuffix_date}%{?dist}
Summary:Get a domain name's public suffix via the Mozilla Public
Suffix List
License:MIT
Group: Development/Libraries
@@ -11,9 +11,6 @@ Source0:
http://www.cpan.org/authors/id/R/RS/RSIMOES/Mozilla-PublicSuffix
#
http://mxr.mozilla.org/mozilla-central/source/netwerk/dns/effective_tld_names.dat?raw=1
Source1:effective_tld_names.dat
-# https://github.com/rsimoes/Mozilla-PublicSuffix/pull/3
-Patch1:0001-Update-to-latest-suffix-list-and-fixup-test-01-accor.patch
-
BuildArch: noarch
BuildRequires: perl >= 0:5.008
BuildRequires: perl(File::Temp)
@@ -34,7 +31,6 @@ From the official website at http://publicsuffix.org/
%prep
%setup -q -n Mozilla-PublicSuffix-v%{version}
-%patch1 -p1 -b .tests
cp -a %{SOURCE1} ./
%build
@@ -55,6 +51,10 @@ perl Build.PL installdirs=vendor 0.1.16-1.20130918
+- Update to 0.1.16
+- Drop upstreamed patch
+
* Thu Sep 26 2013 Yanko Kaneti 0.1.15-3.20130918
- Latest public suffix list from publicsuffix.org
- Fixup tests in 0.1.15 to match the new list
diff --git a/sources b/sources
index 8da1718..767308a 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-4fee72c5faaa306b4c2f2b1e917bc87d Mozilla-PublicSuffix-v0.1.15.tar.gz
+0277aaecfd7501a82d0cd49faf7f1c63 Mozilla-PublicSuffix-v0.1.16.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Mozilla-PublicSuffix-v0.1.16.tar.gz uploaded to lookaside cache by yaneti
A file has been added to the lookaside cache for perl-Mozilla-PublicSuffix: 0277aaecfd7501a82d0cd49faf7f1c63 Mozilla-PublicSuffix-v0.1.16.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: bcache-tools and bcache support in other linux packages
Hi It was brought to my attention that there's a confusing typo in the message below regarding the planning of bcache support for anaconda. The claim that it is planned for F20 is not true, it is planned for F21: https://fedorahosted.org/fesco/ticket/1145 Sorry for any confusion, Rolf Op 26-09-13 11:56 schreef Rolf Fokkens : >Hi, > >Like I did on the 14th on the linux-bcache list I'd like to send an >update on the progress of bcache related packages. While focussing on >Fedora packaging of bcache-tools, I had some good collaboration with >other packagers resulting in improved bcache support in other packages >as well. Other Linux distro's may benefit from these updated packages too. > >util-linux >== >On 27th of September util-linux v2.24 RC will probably be released. This >release supports the identification of bcache superblocks in libblkid, >actually integrating and obsoleting probe-bcache. Because of this udev >rules for bcache can be simplified because they only need blkid. Of >course this only applies to systems where util-linux v2.24 RC (or >higher) actually is installed, otherwise probe-bcache is still needed. > >Dracut >== >Since version 032 Dracut already had bcache support. Since version 033 >it adds support for util-linux v2.24 RC, so even without (obsoleted) >probe-bcache it is able to identify bcache using blkid. Additionally >Dracut benefits from blkid being able to identify bcache, because it >uses blkid to identify all necessary kernel modules automatically, so no >-N option is needed anymore. > >LVM2 > >With the release of v2_01_102 LVM2 now accepts Physical Volumes on >bcache by default. This simplifies the creation of initramfs (by Dracut) >because no specific LVM2 option (--lvmconf) needs to be passed to >Dracut.For the user this means that updating a kernel just works out of >the box! > >bcache-tools > >The bcache-tools package is available in Fedora 20. I plan to build an >updated package that no longer includes probe-bcache when the new >util-linux is released. > >Anaconda > >Anaconda (the Fedora installer) does not support bcache yet. This is >planned for Fedora 20. This is important when installing Fedora on a >system and having your root filesystem on bcache. Althought other >Distro's don't use Anaconda, I guess their installers also need to be >changed in some way to supportbcache. > >Currently having Fedora installed with your root Filesystem on bcache is >possible, but It's done in a fewsteps: >1. Install Fedora using Anaconda without using bcache, but create an >extra partition to supportan alternate root FS >2. From the running system build a bcache device using the extra >partition. Copy the current root FS to the bcache root FS >3. Reboot your system in the bcache root FS, and reclaim the spaces used >by the non-bcache root partition > >More information can be found below, related to the "SSD Cache Fedora >test day". > >The SSD Cache Fedora test day >= >On 13th of October there's an "SSD Cache Fedora test day": see the Wiki >page https://fedoraproject.org/wiki/Test_Day:2013-10-13_SSD_Cache. This >page is work in progress, any feedback is welcome. People interested in >testing are invited to participate on 13th of October. > >When there's anything new toreport, I'll keep you posted. > >Rolf Fokkens -- 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: what left in mass rebuild x264/ffmpeg for F20
On Seg, 2013-09-30 at 07:09 -0500, Bruno Wolff III wrote: > On Mon, Sep 30, 2013 at 04:28:16 +0100, >Sérgio Basto wrote: > >Hi, checking whatrequires ffmpeg-libs and x264-libs, and can't install > >on F20 vm is : > > That's rpmfusion stuff. Sorry, wrong mailing list ... I wanted to send to rpmfusion-devel . Best regards, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Tree-Simple/f20] Upstream update.
Summary of changes: b5cc9c0... Upstream update. (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: are you annoyed by frequent password prompts?
On Wed, 11 Sep 2013 16:10:48 +0200 drago01 wrote: > On Wed, Sep 11, 2013 at 2:53 PM, Daniel J Walsh > wrote: > > Random crap from the internet not a good idea. > > Since firefox can out and crab stuff to install, and I would > > never no. > > No one is that insane ;) This is all about signed packages. Does it matter who signs them signed by "destroy_d...@at.idontgiveatoss.evil" or are you talking fedora@ only? -- Regards, Frank www.frankly3d.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: are you annoyed by frequent password prompts?
Hello, On Wed, Sep 11, 2013 at 9:10 AM, Dhiru Kholia wrote: > In FESCo ticket #1115, it was decided to modify the privilege escalation > policy in order to allow local, active, admin user to update/remove/etc > signed software without requiring a password. > In FESCo ticket #1117, it was decided to extend this policy to > potentially cover other privileged operations. At this point, "we" are > looking for more use cases. Lot of such use cases are already listed on > the following page, The question FESCo was considering is not "which password prompts are annoying", but "what system-wide policy does something useful"? For example, the "Scope" part of https://fedoraproject.org/wiki/Privilege_escalation_policy is a general policy (providing a specific security-relevant promise), and the rest of the page is just a specific implementation. Similarly, see https://fedorahosted.org/fesco/ticket/1117#comment:2 attempts to approach the problem from a similar angle. Starting with annoying use cases an using them to find how the general policy needs to change does make a lot of sense, or course; I just wanted to make sure that the subject of the email does not mislead us into just killing passwords left and right. 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: The final push for the application installer in Fedora 20
On 30 September 2013 12:56, tim.laurid...@gmail.com wrote: > AppData is focusing alot about application AppData and AppStream are focussed on applications primarily, but we do currently have some experimental support for icons and input sources. The format of those in the metadata might change a bit, so I've not pushed that upstream just yet. I have however had a lot of help from the Ibus people. > what about content : icons, themes, backgrounds I don't know if that's in scope. I think it would be a distraction to start enumerating all possible things there now, and we should really keep the focus on apps and a few tightly-specified other add-on types. 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: The final push for the application installer in Fedora 20
On 09/30/2013 08:42 AM, tim.laurid...@gmail.com wrote:
vlc is not part of fedora, cause of patent related stuff, not a legal
expert, but I dont think fedora cant contain somethng there links to
these kind of applications
If you create a new kind of application metadata, would it not be a good
idea to start using the information we allready have in the .spec files
and build from that
instead of starting from scratch, it is better than no information at all
Tim
The following query will build a template (it assumes the package name
is the same as the desktop file name).
#!/bin/bash
echo `rpmquery $1 --qf "\
$1.desktop\
CC0$1%{SUMMARY}\
%{DESCRIPTION}\
%{URL}\
height="600">\
"`
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: The final push for the application installer in Fedora 20
On 30 September 2013 12:00, Michael Schwendt wrote: > Could you highlight how much of a "cross-distro effort" this really is? You can use gnome-software from git master on Fedora and SUSE now, as I've spent quite a bit of last week with the SUSE rel-eng people making their metadata validate. I've got a few more compat bits to add, and then you'll be able to add Ubuntu and Arch to that list too. The idea is that all the software centers (USC, a couple of smaller ones) would consume this too, so it's not even gnome-software specific. > Audacious upstream has asked whether the AppData file would only be used > by Fedora? Writing a simple file and including it in the Fedora rpms is > easy, but it would look more beautiful with an official screenshot and > an official updatecontact address. Yes, it's designed to be upstream unless there's a very good reason. Over a 110 upstream projects have already merged AppData files, although most are not present in Fedora as you have to normally wait for a new tarball release. If you can convince them to translate the appdata file too, that'd be double awesome. 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
[Bug 1013535] perl-GStreamer-0.19 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1013535 Jitka Plesnikova changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-GStreamer-0.19-1.fc21 Resolution|--- |RAWHIDE Last Closed||2013-09-30 08:13:10 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=rr8oOv4wQ5&a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: what left in mass rebuild x264/ffmpeg for F20
On Mon, Sep 30, 2013 at 04:28:16 +0100, Sérgio Basto wrote: Hi, checking whatrequires ffmpeg-libs and x264-libs, and can't install on F20 vm is : That's rpmfusion stuff. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: The final push for the application installer in Fedora 20
AppData is focusing alot about application, what about content : icons, themes, backgrounds Tim On Mon, Sep 30, 2013 at 1:00 PM, Michael Schwendt wrote: > On Fri, 27 Sep 2013 11:24:45 +0100, Richard Hughes wrote: > > > In GNOME Software, we show a list of applications for each category > > that we think are frikin’ awesome. Some have AppData[1], and some > > don’t. For the ones that don’t yet have AppData it leaves the > > responsibility of writing the long description to the Linux community, > > where we can push the data back to upstream so that all the > > distributions can benefit. So far we’ve had a superb reaction from > > lots of upstream projects and a lot of descriptions have been merged. > > Could you highlight how much of a "cross-distro effort" this really is? > Audacious upstream has asked whether the AppData file would only be used > by Fedora? Writing a simple file and including it in the Fedora rpms is > easy, but it would look more beautiful with an official screenshot and > an official updatecontact address. > -- > 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
F-20 Branched report: 20130930 changes
Compose started at Mon Sep 30 09:15:03 UTC 2013 Broken deps for armhfp -- [blueman] blueman-1.23-7.fc20.armv7hl requires obex-data-server >= 0:0.4.3 blueman-1.23-7.fc20.armv7hl requires gvfs-obexftp [bwm-ng] bwm-ng-0.6-11.1.fc20.armv7hl requires libstatgrab.so.9 [cloud-init] cloud-init-0.7.2-4.fc20.noarch requires dmidecode [cobbler] cobbler-2.4.0-2.fc20.noarch requires syslinux [evolution-rss] 1:evolution-rss-0.3.93-4.fc20.armv7hl requires libedataserver-1.2.so.17 1:evolution-rss-0.3.93-4.fc20.armv7hl requires libedata-book-1.2.so.19 1:evolution-rss-0.3.93-4.fc20.armv7hl requires libebackend-1.2.so.6 1:evolution-rss-0.3.93-4.fc20.armv7hl requires libcamel-1.2.so.44 [fawkes] fawkes-doc-0.5.0-9.fc20.noarch requires fawkes = 0:0.5.0-9.fc20 [fts] fts-server-3.1.1-1.fc20.armv7hl requires libactivemq-cpp.so.14 [glusterfs] glusterfs-ufo-3.4.0-8.fc20.noarch requires openstack-swift-proxy = 0:1.8.0 glusterfs-ufo-3.4.0-8.fc20.noarch requires openstack-swift-object = 0:1.8.0 glusterfs-ufo-3.4.0-8.fc20.noarch requires openstack-swift-container = 0:1.8.0 glusterfs-ufo-3.4.0-8.fc20.noarch requires openstack-swift-account = 0:1.8.0 glusterfs-ufo-3.4.0-8.fc20.noarch requires openstack-swift = 0:1.8.0 [gradle] gradle-1.0-18.fc20.noarch requires plexus-container-default [gtkd] gtkd-geany-tags-2.0.0-29.20120815git9ae9181.fc18.noarch requires gtkd = 0:2.0.0-29.20120815git9ae9181.fc18 [kawa] 1:kawa-1.11-5.fc19.armv7hl requires servlet25 [koji] koji-vm-1.8.0-2.fc20.noarch requires python-virtinst [kyua-cli] kyua-cli-0.5-3.fc19.armv7hl requires liblutok.so.0 kyua-cli-tests-0.5-3.fc19.armv7hl requires liblutok.so.0 [monotone] monotone-1.0-11.fc19.armv7hl requires libbotan-1.8.2.so perl-Monotone-1.0-11.fc19.armv7hl requires perl(:MODULE_COMPAT_5.16.2) [msp430-libc] msp430-libc-20120224-2.fc19.noarch requires msp430-gcc >= 0:4.6.3 [nifti2dicom] nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtksys.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkWidgets.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkVolumeRendering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkViews.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkTextAnalysis.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkRendering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkParallel.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkInfovis.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkImaging.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkIO.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkHybrid.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGraphics.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGeovis.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGenericFiltering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkFiltering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkCommon.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkCharts.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libQVTK.so.5.10 [nocpulse-common] nocpulse-common-2.2.7-2.fc20.noarch requires perl(RHN::DBI) [openbox] gdm-control-3.5.2-2.fc20.armv7hl requires gnome-panel gnome-panel-control-3.5.2-2.fc20.armv7hl requires gnome-panel [openpts] openpts-0.2.6-7.fc20.armv7hl requires tboot [ovirt-engine] ovirt-engine-notification-service-3.1.0-1.fc19.noarch requires classpathx-mail [oyranos] oyranos-libs-0.4.0-7.fc19.armv7hl requires libraw.so.5 [perl-Language-Expr] perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) [perl-MIME-Lite-HTML] perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) [perl-MooseX-TrackDirty-Attributes] perl-MooseX-TrackDirty-Attributes-2.002-2.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) [perl-Padre] perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) [player] player-3.0.2-32.fc20.armv7hl requires libstatgrab.so.9 [pure] pure-doc-0.57-4.fc20.noarch requires pure = 0:0.57-4.fc20 [python-tag] python-tag-2013.1-1.fc20.armv7hl requires libboost_python.so.1.53.0 [rootplot] rootplot-2.2.1-7.fc19.noarch requires root-python [rubygem-audited-activerecord] rubygem-audited-activerecord-3.0.0-3.fc19.noarch requires rubygem(activerecord) < 0:4 [scala] scala-2.9.2-2.fc19.noarch requires osgi(org.scala-ide.scala.library) scala-2.9.2-2.fc19.noarch requires /usr/share/java/jansi.jar [scilab] scilab-doc-5.4.1-4.fc20.noarch requires scilab = 0:5.4.1-4.fc20 scilab-t
Re: The final push for the application installer in Fedora 20
On Fri, 27 Sep 2013 11:24:45 +0100, Richard Hughes wrote: > In GNOME Software, we show a list of applications for each category > that we think are frikin’ awesome. Some have AppData[1], and some > don’t. For the ones that don’t yet have AppData it leaves the > responsibility of writing the long description to the Linux community, > where we can push the data back to upstream so that all the > distributions can benefit. So far we’ve had a superb reaction from > lots of upstream projects and a lot of descriptions have been merged. Could you highlight how much of a "cross-distro effort" this really is? Audacious upstream has asked whether the AppData file would only be used by Fedora? Writing a simple file and including it in the Fedora rpms is easy, but it would look more beautiful with an official screenshot and an official updatecontact address. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: The final push for the application installer in Fedora 20
On 30 September 2013 07:42, tim.laurid...@gmail.com wrote: > vlc is not part of fedora, cause of patent related stuff, not a legal > expert, but I dont think fedora cant contain somethng there links to these > kind of applications Agreed. > If you create a new kind of application metadata, would it not be a good > idea to start using the information we allready have in the .spec files and > build from that > instead of starting from scratch, it is better than no information at all The descriptions in spec files are usually worse than the ones found in Debian. Most are one or two lines of text and nothing approaching the prose required in the AppData style guide. 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: Hello! Also, packaging baresip for Fedora
On Mon, 30 Sep 2013 10:35:33 +0300, Oron Peled wrote: > > On Sunday 29 September 2013 21:22:24 Lars Kellogg-Stedman wrote: > > I went ahead and generated a patch to the Makefile that uses the > > package version for the library version. > > That's wrong, as library versions represent API/ABI changes and > the numbering has different *semantics* than package version numbering. > > [the libtool info file has a good introduction to ABI version numbering] The way it has been done, any minor version update would break dependencies: $ rpm -qp --provides libre-0.4.4-5.fc20.x86_64.rpm libre = 0.4.4-5.fc20 libre(x86-64) = 0.4.4-5.fc20 libre.so.0.4.4()(64bit) That's the opposite scenario of "no soname", where every new upstream release might break the ABI/API. Which is more dangerous, if such changes are not noticed with rpmsodiff or abi checker tools. That may not be seen as a problem to you, however, if you plan to check new releases painstakingly. There are no guidelines about it. -- 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: Hello! Also, packaging baresip for Fedora
On Sun, 29 Sep 2013 12:38:25 -0400, Lars Kellogg-Stedman wrote: > [...] what the upstream Makefile > currently produces. I wasn't sure how invasive I should be in terms > of patching the upstream build process. The build output is "silent" using '@' command invocations in the Makefile. Patching that confirmed that Fedora's compiler flags aren't used: https://fedoraproject.org/wiki/Packaging:Guidelines#Compiler_flags Nowadays, some packagers apply a trick similar to %build %configure || : make … or %build [ -f configure ] || touch configure ; chmod +x configure %configure make … for exporting CFLAGS (and more) properly. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: The final push for the application installer in Fedora 20
On 30 September 2013 09:10, Brendan Jones wrote: > I've submitted a patch for rosegarden submitted upstream. Brilliant, thanks. 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
Taking owner ship of mod_scgi: re-review, and rutorrent review swap
Hi, mod_scgi was orphaned quite a while back since it wouldn't build on new releases, with the new apache. I found a set of patches in the suse rpm that fix the build. I'd like to get mod_scgi back into the repos. It's required by most rtorrent front ends, like rutorrent that I've just submitted for review. I'll be more than happy to co-maintain this module with someone more knowledgeable with apache and friends :) Bugz: https://bugzilla.redhat.com/show_bug.cgi?id=1013485 - mod_scgi re-review https://bugzilla.redhat.com/show_bug.cgi?id=1013488 - rutorrent Review swaps are welcome as always. -- 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
Re: The final push for the application installer in Fedora 20
On 09/27/2013 12:24 PM, Richard Hughes wrote: In GNOME Software, we show a list of applications for each category that we think are frikin’ awesome. Some have AppData[1], and some don’t. For the ones that don’t yet have AppData it leaves the responsibility of writing the long description to the Linux community, where we can push the data back to upstream so that all the distributions can benefit. So far we’ve had a superb reaction from lots of upstream projects and a lot of descriptions have been merged. For Fedora 20 we want all the awesome apps to have AppData, so users can evaluate the application before installing it. It would add a really nice bit of polish to the whole experience. If you can spare 5 minutes and want to help. I’ve got another shared document that just needs a few details for each application: https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdElaYUoxcXRxeVRVS05Femg4Zzk2NWc#gid=0 The list of awesome-but-unloved apps is: audacity, ardour2, gnome-banshee, rosegarden, sound-juicer, doom, openarena, xonotic, tremulous, btanks, frozen-bubble, quadrapassel, neverball, gnomine, wesnoth, supertuxkart, redeclipse, lyx, gparted, virt-manager, eclipse, gitg, monodevelop, blender, shotwell, octave, saoimage, workrave, celestia, polari, pidgin, chromium, pitivi, vlc and openshot. I've submitted a patch for rosegarden submitted upstream. regards, Brendan -- 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: Hello! Also, packaging baresip for Fedora
On Sunday 29 September 2013 21:22:24 Lars Kellogg-Stedman wrote: > I went ahead and generated a patch to the Makefile that uses the > package version for the library version. That's wrong, as library versions represent API/ABI changes and the numbering has different *semantics* than package version numbering. [the libtool info file has a good introduction to ABI version numbering] IMO, there are two alternatives: * If upstream decide to manage ABI versions that's best. * Otherwise, you can number the library as .0.0 and increment for every new upstream release -- which means we assume each of them breaks ABI compatibility :-( (since currently, this library has only one client, it shouldn't be too painful). -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron "I love deadlines, especially the whooshing sound they make as they go by." -- Douglas Adams -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [linux-sunxi] Announcing Fedora 19 ARM remix for Allwinner SOCs release 2
Hi, On 09/30/2013 03:20 AM, jonsm...@gmail.com wrote: I didn't know about the command line option. This looks like the problem Kernel command line: console=tty0 root=/dev/mmcblk0p3 ro rootwait loglevel=5 panic=10 console=ttyS0,115200 disp.screen0_output_mode=EDID:1280x720 p60 hdmi.audio=EDID:0 sunxi_g2d_mem_reserve=0 sunxi_ve_mem_reserve=0 sunxi_fb_me m_reserve=20 sunxi_no_mali_mem_reserve Might make sense to set it so that mali/cedar can load. That way people will be able to work on them. The idea is to give people the largest amount of free RAM possible in the default config, this is esp. important for 256MB RAM boards. People who want to use cedar / mali will need to do all kind of reconfiguration themselves anyways. I'll add something about needing to tweak the kernelcmdline for this to the README. Regards, Hans -- 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: [HEADSUP] Atlas changed libraries
On Mon, 30 Sep 2013 10:03:14 +0300
Susi Lehtola wrote:
> On Sun, 29 Sep 2013 23:57:21 +0200
> Kevin Kofler wrote:
>
> > Susi Lehtola wrote:
> >
> > > On Sun, 29 Sep 2013 01:04:31 +0200
> > > Kevin Kofler wrote:
> > >> Susi Lehtola wrote:
> > >> > If you link to -lblas, you're shooting yourself in the leg in the first
> > >> > place, since that's the reference implementation on current Fedoras.
> > >>
> > >> In fact, I noticed that, and that's a serious packaging bug.
> > >>
> > >> If a package links -lblas -llapack, if ATLAS is installed, it'll get
> > >> reference BLAS and ATLAS LAPACK! If it links -llapack -lblas, it'll
> > >> probably get the ATLAS functions throughout, because then libatlas is
> > >> resolved first. That's very unexpected and broken behavior.
> > >
> > > No, you're assuming nonstandard behavior. ATLAS has never done this.
> >
> > I am describing the behavior that actually happens with the Fedora 18 (and
> > I
> > presume 19 too) atlas-sse2 package!
> >
> > Try running ldd on LAPACK-using stuff, you'll see how the ATLAS liblapack
> > is
> > picked up (but libblas is not overridden, which is a bug).
>
> Yes, but everyone knows that if you want ATLAS, the link command is
> -L%{_libdir} -llapack -lf77blas -latlas
> If you link to -lblas you're assuming nonstandard behavior. Fedora is
> not Debian.
>
> Nowadays this is just
> -L%{_libdir} -lsatlas
> a much easier version.
.. and this is also the main reason why I think that the new scheme is
loads better. At the linking phase you can be 100% sure of what library
you're using, and also that you're not going to run into problems with
incompatible libraries.
--
Susi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADSUP] Atlas changed libraries
On Sun, 29 Sep 2013 23:57:21 +0200
Kevin Kofler wrote:
> Susi Lehtola wrote:
>
> > On Sun, 29 Sep 2013 01:04:31 +0200
> > Kevin Kofler wrote:
> >> Susi Lehtola wrote:
> >> > If you link to -lblas, you're shooting yourself in the leg in the first
> >> > place, since that's the reference implementation on current Fedoras.
> >>
> >> In fact, I noticed that, and that's a serious packaging bug.
> >>
> >> If a package links -lblas -llapack, if ATLAS is installed, it'll get
> >> reference BLAS and ATLAS LAPACK! If it links -llapack -lblas, it'll
> >> probably get the ATLAS functions throughout, because then libatlas is
> >> resolved first. That's very unexpected and broken behavior.
> >
> > No, you're assuming nonstandard behavior. ATLAS has never done this.
>
> I am describing the behavior that actually happens with the Fedora 18 (and I
> presume 19 too) atlas-sse2 package!
>
> Try running ldd on LAPACK-using stuff, you'll see how the ATLAS liblapack is
> picked up (but libblas is not overridden, which is a bug).
Yes, but everyone knows that if you want ATLAS, the link command is
-L%{_libdir} -llapack -lf77blas -latlas
If you link to -lblas you're assuming nonstandard behavior. Fedora is
not Debian.
Nowadays this is just
-L%{_libdir} -lsatlas
a much easier version.
--
Susi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
bcache, udev rules and calling blkid
Hi, On bugzilla there was a brief discussion on how to reduce the number of blkid calls during udev rules processing: https://bugzilla.redhat.com/show_bug.cgi?id=1004693 The general idea was to rely on earlier calls to blkid instead of having later rules calling blkid themselves. Specifically for bcache this meant relying on 13-dm-disk.rules and 60-persistent-storage-rules, which all worked fine until... ...until I tested stacking bcache on top of raid (md). In that situation 61-bcache.rules was out of luck, because there was no prior call to blkid so bcache was not detected. The straight forward solution appears to be te call blkid from 61-bcache.rules, this works any way. An alternative solution might be to move 61-bcache.rules to 65-bcache.rules so it is run after 64-md-raid.rules, that might work. In general I'm a little uncomfortable with this: relying that other rules to call blkid may work most of the time, but not always. If rules should rely on prior calls to blkid, wouldn't it be better to call blkid as rule 00-blk.rules or so? In that case no other rule would ever have to call blkid ever. And yes, it may happen that blkid is sometimes called without the output actually being used. Any advice is appreciated, Thanks, Rolf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
