date:20130831

Re: [ACTION REQUIRED] Retiring long-term FTBFS packages for Fedora 20 v2

2013-08-31 Thread Till Maas

On Sat, Aug 31, 2013 at 10:00:02AM +0800, Christopher Meng wrote:
 I've solved the bug 992800 as tqsllib FTBFS caused by openssl version.
 
 Please see
 
 https://bugzilla.redhat.com/show_bug.cgi?id=992800

I added the patch and rebuilt the package for F20 and Rawhide.

 If no response still, please release his ownership.

Please follow this procedure:
https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers

Regards
Till
-- 
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: [ACTION REQUIRED] Retiring long-term FTBFS packages for Fedora 20 v2

2013-08-31 Thread Christopher Meng

On Sat, Aug 31, 2013 at 3:06 PM, Till Maas opensou...@till.name wrote:
 On Sat, Aug 31, 2013 at 10:00:02AM +0800, Christopher Meng wrote:
 I've solved the bug 992800 as tqsllib FTBFS caused by openssl version.

 Please see

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

 I added the patch and rebuilt the package for F20 and Rawhide.

 If no response still, please release his ownership.

 Please follow this procedure:
 https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers


Ok, if you add it I will not request.

Cheers.
-- 
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: Builder update

2013-08-31 Thread Zbigniew Jędrzejewski-Szmek

On Wed, Aug 28, 2013 at 09:59:49AM -0600, Kevin Fenzi wrote:
 On Wed, 28 Aug 2013 11:41:31 -0400
 Colin Walters walt...@verbum.org wrote:
 
  I think the most practical thing is to build version N of self-hosting
  systems using version N-1 (in addition to supporting building N with
  N). If you are using the latest to build the latest, you can more
  easily get into unstable states.
  
  For example, if a new version of the Fedora kernel broke virtio-net,
  and you immediately upgrade the build VMs, then the system falls
  apart and requires manual system administrator intervention - you
  can't build a new fixed kernel.
 
 Sure. 
 
 For example, the builders should stay Fedora 19 until Fedora 20 is
 officially released, then we will switch them to 20, etc. 
It would be a good time to review
https://bugzilla.redhat.com/show_bug.cgi?id=995753
(aka https://fedorahosted.org/koji/ticket/267), which
converts koji to systemd units.

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

Re: COPR

2013-08-31 Thread Frankie Onuonga

On Fri, 2013-08-30 at 11:39 +0200, Miroslav Suchý wrote:
Hi,
I would like to get your feedback about COPR [1]

[1] http://miroslav.suchy.cz/blog/archives/2013/08/29/what_is_copr/index.html

We are the beggining and there are two options of where we can go:
http://miroslav.suchy.cz/blog/archives/2013/08/29/copr_and_integration_with_koji/index.html
http://miroslav.suchy.cz/blog/archives/2013/08/30/copr_implemented_using_obs/index.html

I would like to ask *you* what is your opinion?
First,thank you very much for the blog post.

In regards to this I think it is difficult or should I say time
consuming to get people to move from what they are already used to.
I think OBS works differently from Koji.
Personally I prefer what we have, but this is just a matter of
preference.
I think we need to consider what is easy for users/developers to use.

I think also security needs to be looked into as described in one of the
earlier posts.

There are features that are there in the other system , I think we can
easily get a team that can build something similar for us.

There are a lot of great minds here.
The most attractive tip for me was:

build package in VM, which is safer then Koji (just chroot in Koji). And
that VM is without network, which is safer then current COPR which
allows network connections.

This is something that needs to be worked on.

Thank you again.

--
Miroslav Suchy, RHCE, RHCDS
Red Hat, Software Engineer, #brno, #devexp, #fedora-buildsys

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

Re: [linux-sunxi] Re: Announcing Fedora 19 ARM remix for Allwinner SOCs release 1, now with A20 support

2013-08-31 Thread Hans de Goede


Hi,

On 08/30/2013 07:24 PM, elias@gmail.com wrote:

Op vrijdag 19 juli 2013 00:12:35 UTC+2 schreef Hans de Goede:

The following has been ported / is supported:

   -sound: analog in/out
Fedora 19 ARM should also work on the following devices:

* A13-OLinuXino (Olimex)



Hi, thanks very much for the release!

I've already tested the Fedora 18 remix on my A13-OLinuXino (even with WIFI 
working!), but I can't get the audio to work:
ALSA reports that no soundcards could be detected.

However using the Debian image of Olimex, I was able to get audio through my headphones and the mic worked also. I looked up 
the driver, and it appeared to be sun5i-CODEC. On the rootfs of the Fedora image, I looked into 
/lib/modules/sun5i-kernel/kernel/sound/soc/, but I only could see a sun4i directory, even 
without a sun4i-CODEC counterpart.
I read somewhere else that code of /sound/soc/sun5i was merged with /sound/soc/sun4i, 
but I tried to modprobe each driver in /sound/soc/sun4i without success.

Do I have to recompile the whole kernel, or just compile the sun5i-CODEC 
module, or do I have to do something different to get audio working?
Thank you very much!


You're not seeing the sun4i-codec module (which works for sun5i too) because it 
is build into the kernel.

You should see some audio devices under /dev/snd and /sys/class/sound

While checking things work with Fedora 19 ARM remix for Allwinner SOCs release 
1 I did notice that there
is an error in the fex file for the A13-OLinuXino, causing only audio-out to be 
present, I've just pushed
an updated fex file here:
https://github.com/linux-sunxi/sunxi-boards/blob/master/sys_config/a13/a13-olinuxino.fex

If you save this file, convert it to a script.bin file using the fex2bin 
utility from here:
https://github.com/linux-sunxi/sunxi-tools

And then overwrite script.bin in the uboot partition of your sdcard with the 
new one you should
also get a capture device.

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: [ACTION REQUIRED] Packages depending on retired packages

2013-08-31 Thread Nicolas Chauvet

2013/8/29 Till Maas opensou...@till.name

 On Wed, Aug 28, 2013 at 10:53:53PM +0200, Till Maas wrote:

Package(co)maintainers
 
 ===
  directfb   orphan, kwizart

  tslib  orphan

 These seem to be retired by accident:
 https://lists.fedoraproject.org/pipermail/devel/2013-June/183702.html

 Nicolas, can you please comment on this?

Yep I've retired this package. At that time the directfb project was more
and more relying on an external kernel module to be full featured. I've
probably missed to block this package at that time.

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

HEADS UP - libcue soname bump in Fedora 20/21.

2013-08-31 Thread Peter Lemenkov

Hello All!
I'm going to update libcue up to 1.4.0 from current 1.3.0, with soname
bump. The following packages are affected by this upgrade:

* audacious-plugins-0:3.4-0.6.beta1.fc19.x86_64
* cmus-0:2.5.0-2.fc19.x86_64
* tracker-0:0.16.1-3.fc19.x86_64

I'll rebuild them as soon as libcue-1.4.0 will be available.

-- 
With best regards, Peter Lemenkov.
-- 
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: HEADS UP - libcue soname bump in Fedora 20/21.

2013-08-31 Thread Michael Schwendt

On Sat, 31 Aug 2013 20:11:12 +0400, Peter Lemenkov wrote:

 Hello All!
 I'm going to update libcue up to 1.4.0 from current 1.3.0, with soname
 bump. The following packages are affected by this upgrade:
 
 * audacious-plugins-0:3.4-0.6.beta1.fc19.x86_64

Wherever you've run that query, this is an old package from May
which has been updated since.

 * cmus-0:2.5.0-2.fc19.x86_64
 * tracker-0:0.16.1-3.fc19.x86_64
 
 I'll rebuild them as soon as libcue-1.4.0 will be available.
-- 
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: Graphics driver support in F21+

2013-08-31 Thread Pavel Alexeev

Hi

28.08.2013 20:31, Basil Mohamed Gohar wrote:
 On 08/28/2013 10:41 AM, Solomon Peachy wrote:
 On Wed, Aug 28, 2013 at 10:13:09AM -0400, Basil Mohamed Gohar wrote:
 Sorry to come out of left field like this, but would the system profile
 info we collect on install be useful in determining the weight of the
 need for some of these drivers?  For example, if there is still a bunch
 of SIS video adapters out there, we might prioritize support for that
 driver, but then not for others that don't show-up in our hardware surveys.
 Another way to look at it is the platform capabilities of these graphics 
 devices.  For example, Fedora 19's release notes claims a minimum of 1GB 
 RAM is required.  Were there any pre-PCIe platforms capable of 
 supporting this much RAM?
 Plenty!  The common limitation in the pre-PCIe era was 2GB or 4GB (e.g.,
 common 32-bit architecture memory limits).  I have several that are
 non-PCIe and have 2GB of RAM.  They run Fedora just fine.  They do,
 however, have more modern AGP-based video cards installed, however.  I
 haven't bothered with the embedded video adapter on them, so I cannot
 speak to their suitability for running Fedora 19.
I have old desktop installation with matrox-mga driver used. Is it will
only single VESA driver choose which do smaller resolution for that?

-- 
With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact
with me use jabber: hubbi...@jabber.ru

-- 
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: [ACTION REQUIRED] Packages depending on retired packages

2013-08-31 Thread Till Maas

On Sat, Aug 31, 2013 at 06:06:16PM +0200, Nicolas Chauvet wrote:
 2013/8/29 Till Maas opensou...@till.name
 
  On Wed, Aug 28, 2013 at 10:53:53PM +0200, Till Maas wrote:
 
 Package(co)maintainers
  
  ===
   directfb   orphan, kwizart
 
   tslib  orphan
 
  These seem to be retired by accident:
  https://lists.fedoraproject.org/pipermail/devel/2013-June/183702.html
 
  Nicolas, can you please comment on this?
 
 Yep I've retired this package. At that time the directfb project was more
 and more relying on an external kernel module to be full featured. I've
 probably missed to block this package at that time.

Directfb is now blocked in f20+ and dead.packaged in GIT. xine-lib
maintainer need to rebuild without directfb support, which is already
the default for arm.

Regards
Till
-- 
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-Qt] Created tag perl-Qt-0.96.0-9.fc20

2013-08-31 Thread Paul Howarth

The lightweight tag 'perl-Qt-0.96.0-9.fc20' was created pointing to:

 11aa26b... Add some fixes from upstream git for Perl 5.18 compatibilit
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Qt] Created tag perl-Qt-0.96.0-9.fc21

2013-08-31 Thread Paul Howarth

The lightweight tag 'perl-Qt-0.96.0-9.fc21' was created pointing to:

 11aa26b... Add some fixes from upstream git for Perl 5.18 compatibilit
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 991871] perl-Qt: FTBFS in rawhide

2013-08-31 Thread bugzilla

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

Paul Howarth p...@city-fan.org changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Qt-0.96.0-9.fc20
 Resolution|--- |RAWHIDE
Last Closed||2013-08-31 04:29:25



--- Comment #3 from Paul Howarth p...@city-fan.org ---
I've applied the two commits from upstream (skipping a couple of hunks that
didn't apply, one for the cmake buildsystem that changed a file that doesn't
exist in the old CPAN version, and one for a GUI test that doesn't get run
during the build anyway), and the package now builds.

I still think it would be a good idea to switch upstreams to the KDE one.

-- 
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=jB0WH56rgia=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

42 matches

Mail list logo