gmane.linux.redhat.fedora.devel

The package erlang-erlzmq2 can't be built for F-17 and F-18 (blocked)

Peter Lemenkov — 2012-05-26T15:36:23

Hello.

This package was retired for some time and now it was re-enabled (see
review request in https://bugzilla.redhat.com/810205 ). Unfortunately
it still can't be built for F-17 anf F-18. Koji fails and returns
quite cryptic messages like this one -  "FAILED: BuildError: package
erlang-erlzmq2 is blocked for tag f18" (from this build attempt -
http://koji.fedoraproject.org/koji/taskinfo?taskID=4104295 ).
Surprisingly it builds just fine for F-16.

I wonder what did we miss so far? And what should we do to re-add it
back to the F-17 and Rawhide?

rawhide report: 20120526 changes

Fedora Rawhide Report — 2012-05-26T13:50:14

Compose started at Sat May 26 08:15:05 UTC 2012

Broken deps for x86_64
----------------------------------------------------------
[389-admin]
389-admin-1.1.28-1.fc18.i686 requires libicuuc.so.48
389-admin-1.1.28-1.fc18.i686 requires libicui18n.so.48
389-admin-1.1.28-1.fc18.i686 requires libicudata.so.48
389-admin-1.1.28-1.fc18.x86_64 requires libicuuc.so.48()(64bit)
389-admin-1.1.28-1.fc18.x86_64 requires libicui18n.so.48()(64bit)
389-admin-1.1.28-1.fc18.x86_64 requires libicudata.so.48()(64bit)
[389-dsgw]
389-dsgw-1.1.9-2.fc17.x86_64 requires libicuuc.so.48()(64bit)
389-dsgw-1.1.9-2.fc17.x86_64 requires libicui18n.so.48()(64bit)
389-dsgw-1.1.9-2.fc17.x86_64 requires libicudata.so.48()(64bit)
[aeolus-all]
aeolus-all-0.4.0-2.fc17.noarch requires aeolus-conductor-doc = 0:0.4.0-2.fc17
aeolus-all-0.4.0-2.fc17.noarch requires aeolus-conductor-daemons = 0:0.4.0-2.fc17
[aeolus-configserver]
aeolus-configserver-0.4.5-1.fc18.noarch requires ruby-nokogiri
[axis2c]
axis2c-1.6.0-4.fc17.i686 requires httpd-

Finding out about a pkg?

Frank Murphy — 2012-05-26T09:23:31

I'm trying to follow up on struts,
http://koji.fedoraproject.org/koji/buildinfo?buildID=239819
is the last mention I can see of it.

yum with *testing shows nothing.
How can I find if it's orphaned?

Fedora Kernel Meeting Minutes 05-24-2012

Josh Boyer — 2012-05-25T18:33:18

==============================
#fedora-meeting: Fedora Kernel
==============================


Meeting started by jwb at 18:00:29 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2012-05-25/fedora-kernel.2012-05-25-18.00.log.html
.



Meeting summary
---------------
* Release overview  (jwb, 18:01:02)

* Release overview - F15  (jwb, 18:01:53)
  * F15 to stay on 3.3.y until EOL  (jwb, 18:05:24)
  * bugs will be looked over and triaged one final time  (jwb, 18:05:45)

* Release overview - F16  (jwb, 18:05:50)

* Release overview - F16/F17  (jwb, 18:07:33)
  * F16/F17 moving to 3.4 once 3.3.7 moves to stable updates  (jwb,
    18:07:52)
  * iwlwifi seems to have more issues.  again.  for like the 3rd kernel
    release  (jwb, 18:09:23)
  * ACTION: jforbes to discuss 3.4 iwlwifi issues with linville before
    rebase  (jwb, 18:10:45)
  * F17 Gold.  Yay.  0-day kernel updates will be pending for all  (jwb,
    18:15:34)
  * 3.4 rebase (iwlwifi issues aside) should close a numbe

Review: BZ71830, BZ744432

Nelson Marques — 2012-05-25T15:30:56

If anyone can help with reviewing this 2 topics, it would be awesome,
considering that UH is on the Games SIG wishlist

- https://bugzilla.redhat.com/show_bug.cgi?id=718430
- https://bugzilla.redhat.com/show_bug.cgi?id=744432

rawhide report: 20120525 changes

Fedora Rawhide Report — 2012-05-25T14:29:47

Compose started at Fri May 25 08:15:05 UTC 2012

Broken deps for x86_64
----------------------------------------------------------
[389-admin]
389-admin-1.1.28-1.fc18.i686 requires libicuuc.so.48
389-admin-1.1.28-1.fc18.i686 requires libicui18n.so.48
389-admin-1.1.28-1.fc18.i686 requires libicudata.so.48
389-admin-1.1.28-1.fc18.x86_64 requires libicuuc.so.48()(64bit)
389-admin-1.1.28-1.fc18.x86_64 requires libicui18n.so.48()(64bit)
389-admin-1.1.28-1.fc18.x86_64 requires libicudata.so.48()(64bit)
[389-adminutil]
389-adminutil-1.1.15-2.fc17.i686 requires libicuuc.so.48
389-adminutil-1.1.15-2.fc17.i686 requires libicui18n.so.48
389-adminutil-1.1.15-2.fc17.i686 requires libicudata.so.48
389-adminutil-1.1.15-2.fc17.x86_64 requires libicuuc.so.48()(64bit)
389-adminutil-1.1.15-2.fc17.x86_64 requires libicui18n.so.48()(64bit)
389-adminutil-1.1.15-2.fc17.x86_64 requires libicudata.so.48()(64bit)
[389-dsgw]
389-dsgw-1.1.9-2.fc17.x86_64 requires libicuuc.so.48()(64bit)
389-dsgw-1.1.9-2.fc17.x86_64 requir

Still begging for reviews...

Simone Caronni — 2012-05-25T13:39:53

Hello,

I'm still begging for reviewers; I tried to contact many people with
Review Requests open that I could review but had no success; so I'm
reverting back to the mailing list.
Anyone with some free time willing to review one of these?

I particularly need the 4 libraries to proceed with other stuff;
they're small and easy:

libguac-client-vnc
libguac-client-rdp
libmd
libradius


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

Guacamole
https://bugzilla.redhat.com/show_bug.cgi?id=820543 - libguac-client-vnc
https://bugzilla.redhat.com/show_bug.cgi?id=820544 - libguac-client-rdp
https://bugzilla.redhat.com/show_bug.cgi?id=820561 - guacd
https://bugzilla.redhat.com/show_bug.cgi?id=825250 - guacamole-ext
(libguac, guacamole-common already approved)

Libraries supporting Apache auth Radius module:
https://bugzilla.redhat.com/show_bug.cgi?id=823444 - libmd
https://bugzilla.redhat.com/show_bug.cgi?id=823446 - libradius

Many thanks,
--Simone

F-17 Branched report: 20120525 changes

Fedora Branched Report — 2012-05-25T11:47:07

Compose started at Fri May 25 08:15:05 UTC 2012

Broken deps for x86_64
----------------------------------------------------------
[LuxRender]
LuxRender-blender-0.8.0-13.fc17.x86_64 requires blender(ABI) = 0:2.61
[aeolus-conductor]
aeolus-conductor-0.4.0-2.fc17.noarch requires rubygem(fastercsv)
aeolus-conductor-0.4.0-2.fc17.noarch requires ruby(abi) = 0:1.8
[aeolus-configserver]
aeolus-configserver-0.4.5-1.fc17.noarch requires ruby-nokogiri
[calf]
lv2-calf-plugins-0.0.18.6-6.fc17.x86_64 requires lv2core
[dh-make]
dh-make-0.55-4.fc17.noarch requires debhelper
[dustmite]
dustmite-1-4.20120304gitcde46e0.fc17.x86_64 requires libphobos2-ldc.so()(64bit)
[gnome-do-plugins]
gnome-do-plugins-banshee-0.8.4-8.fc17.x86_64 requires mono(Banshee.CollectionIndexer) = 0:2.2.0.0
[gorm]
gorm-1.2.13-0.2.20110331.fc17.i686 requires libobjc.so.3
gorm-1.2.13-0.2.20110331.fc17.i686 requires libgnustep-gui.so.0.20
gorm-1.2.13-0.2.20110331.fc17.i686 requires libgnustep-base.so.1.23
gorm-1.2.13-0.2.20110331.fc17.x86_64 r

Packaging pyroscope

Ankur Sinha — 2012-05-25T05:53:59

Hey folks,

I was wondering if anyone's ever considered packaging pyroscope[1] for
Fedora? It adds quite a lot of functionality to rtorrent. 

I've just started looking into it, and the building looks pretty messy.
This is the build script they use[2]. It downloads everything, including
rtorrent, and then applies the patches etc. to it. Is this okay? It's
going to take some looking into. 

I ask because it appears to be a good tool and there may be a reason
behind why it's still unpackaged. 

[1] http://code.google.com/p/pyroscope/wiki
[2]
http://pyroscope.googlecode.com/svn/trunk/pyrocore/docs/rtorrent-extended/build.sh

Fedora 17 Final is declared GOLD!

Robyn Bergeron — 2012-05-24T19:17:15

At the Fedora 17 Final Go/No-Go meeting today, the F17 Final Release 
(RC4) was declared GOLD and ready for GA on May 29, 2012.

Thanks to everyone who came today, and to everyone who helped get the 
Beefy Miracle ready for public devouring. :) Links to meeting minutes 
and logs follow below.

Cheers,

-Robyn




Meeting Minutes: 
http://meetbot.fedoraproject.org/fedora-meeting-1/2012-05-24/fedora_17_final_go_nogo_meeting_round_2.2012-05-24-17.01.html
Log: 
http://meetbot.fedoraproject.org/fedora-meeting-1/2012-05-24/fedora_17_final_go_nogo_meeting_round_2.2012-05-24-17.01.log.html


==========================================================
#fedora-meeting-1: Fedora 17 Final Go NoGo Meeting Round 2
==========================================================


Meeting started by rbergeron at 17:01:09 UTC. The full logs are
available at
http://meetbot.fedoraproject.org/fedora-meeting-1/2012-05-24/fedora_17_final_go_nogo_meeting_round_2.2012-05-24-17.01.log.html
.



Meeting summary
---------------
* Why are we

opensmtp for fedora - www.opensmtpd.org

Adrian Alves — 2012-05-24T14:50:47

any body is working on this:
http://www.opensmtpd.org/

am about to package it.
just wondering

Regards, Adrian.-

F-17 Branched report: 20120524 changes

Fedora Branched Report — 2012-05-24T11:09:12

Compose started at Thu May 24 08:15:05 UTC 2012

Broken deps for x86_64
----------------------------------------------------------
[LuxRender]
LuxRender-blender-0.8.0-13.fc17.x86_64 requires blender(ABI) = 0:2.61
[aeolus-conductor]
aeolus-conductor-0.4.0-2.fc17.noarch requires rubygem(fastercsv)
aeolus-conductor-0.4.0-2.fc17.noarch requires ruby(abi) = 0:1.8
[aeolus-configserver]
aeolus-configserver-0.4.5-1.fc17.noarch requires ruby-nokogiri
[calf]
lv2-calf-plugins-0.0.18.6-6.fc17.x86_64 requires lv2core
[dh-make]
dh-make-0.55-4.fc17.noarch requires debhelper
[dustmite]
dustmite-1-4.20120304gitcde46e0.fc17.x86_64 requires libphobos2-ldc.so()(64bit)
[gnome-do-plugins]
gnome-do-plugins-banshee-0.8.4-8.fc17.x86_64 requires mono(Banshee.CollectionIndexer) = 0:2.2.0.0
[gorm]
gorm-1.2.13-0.2.20110331.fc17.i686 requires libobjc.so.3
gorm-1.2.13-0.2.20110331.fc17.i686 requires libgnustep-gui.so.0.20
gorm-1.2.13-0.2.20110331.fc17.i686 requires libgnustep-base.so.1.23
gorm-1.2.13-0.2.20110331.fc17.x86_64 r

How to proceed with MiniDebugInfo

Alexander Larsson — 2012-05-24T07:28:16

I'm at a loss to how to proceed with the MiniDebugInfo work. I have
patches to rpmbuild that creates the compressed minidebuginfo putting
them in the main binaries, and I have patches to gdb that reads the
compressed debuginfo on demand. 

However, the whole thing is useless unless we agree that we want to
enable this by default. It seems some people like the idea, whereas
others disagree that its worth the increased binary size. It doesn't
look like either side is gonna be able to convince the other side, so
how do we get to a decision here?

Fedora ARM weekly meeting minutes 2012-05-23

Paul Whalen — 2012-05-24T01:09:34

Good day all, 

Thanks to those who were able to join us for the weekly status meeting today. For those that were unable, the minutes are posted below:

Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2012-05-23/fedora-meeting-1.2012-05-23-20.00.html
Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2012-05-23/fedora-meeting-1.2012-05-23-20.00.txt
Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2012-05-23/fedora-meeting-1.2012-05-23-20.00.log.html


Paul

SSD drives

Gerry Reno — 2012-05-24T00:38:30

What does Fedora do currently, if anything, to optimize for solid-state drives (SSD).

Things like swap and logging can generate a huge number of writes.  So I suppose those should maybe be placed on a
rotating drive if one is available but if not does Fedora do anything to reduce the amount of writes?  Or is everything
related to SSD the responsibility of the user?

Orphaning dzen2

David Cantrell — 2012-05-23T20:03:25

For both Fedora branches and EPEL.  If anyone wants it, let me know.  Or,
you know where to pick it up.

SystemD: When to start service for file system kernel module

Richard Shaw — 2012-05-23T19:23:30

Short story:
I'm working on creating kernel module packages for the ZFS file system
from zfsonlinux.org to be hosted at RPM Fusion and will utilize the
akmods utility to make sure that new modules are built on kernel
update.

Problem:
The zfs package also needs the SPL (Solaris Porting Layer) kernel
module so I have to control the order the kernel modules are built and
installed as the SPL one also has a kernel version specific devel
package that ZFS needs to build.

Question:
What is the right way to make sure it's built prior to mounting non
system volumes? Obviously you can't have your system volume be ZFS
with this setup, but with the current performance and stability, you
wouldn't want to.

Here's my current service file for SPL:
[Unit]
Description=Builds and installs new kmods for SPL
Before=local-fs-pre.target

[Service]
Type=oneshot
ExecStart=-/usr/sbin/akmods --from-init --akmod spl-kmod

[Install]
WantedBy=single-user.target

The one for ZFS is essentially the same except it also includes
"After=sp

/usr/sbin/validate clash with /usr/bin/validate

Paul Wouters — 2012-05-23T18:22:35

I just got caught in having two different "validate" commands in my
path.

The /usr/bin/validate version is from the dnssec-tools package. It has a
man page and usage info and is a tool to diagnose dnssec lookups.

The /usr/sbin/validate version is from the mod_auth_shadow package. It
has no man page, no usage, no -h or --help. It is executed by the apache
server to read /etc/shadow to do user auth. It is setuid root, and not
meant to be executed by a user.

I suggest moving /usr/sbin/validator into /usr/libexec, and probably
talking to Dan Walsh about using SElinux to further restrict it so it
cannot be executed by users or cgis.

Paul
ps. Jan: I also filed a crypt() NULL bug against mod_auth_shadow a while
ago with a patch.

Strategy for packaging an ARM Cortex-M toolchain

Rob Spanton — 2012-05-23T16:07:27

Hi,

There are an increasing number of ARM Cortex-M based boards around, and
I'd like to get a cross-compilation toolchain for them into the Fedora
repositories.  I'd like to make it just as easy to compile for Cortex-M
chips under Fedora as it is to compile for AVR or MSP430 targets right
now (i.e. `yum install ...`).

So I've cobbled together packages for a prototype toolchain [1],
consisting of binutils, gcc, newlib and gdb.  Currently with the
target-triplet "arm-none-eabi", which I think I'll be changing to
"arm-cortex_m-eabi".

I'd like to avoid this toolchain conflicting with, or duplicating the
effort put into other cross-compilation toolchains that are currently in
Fedora.

There are two things that I can think of that this cortex-m3 toolchain
might interact with at the moment:
     1. The arm-gp2x-linux toolchain currently in the repositories.
     2. Any cross-compilation toolchains generated by the Fedora ARM
        {primary,secondary} architecture stuff that's happening.

I think the binutils a

rawhide report: 20120523 changes

Fedora Rawhide Report — 2012-05-23T13:04:21

Compose started at Wed May 23 08:15:03 UTC 2012

Broken deps for x86_64
----------------------------------------------------------
[389-admin]
389-admin-1.1.28-1.fc18.i686 requires libicuuc.so.48
389-admin-1.1.28-1.fc18.i686 requires libicui18n.so.48
389-admin-1.1.28-1.fc18.i686 requires libicudata.so.48
389-admin-1.1.28-1.fc18.x86_64 requires libicuuc.so.48()(64bit)
389-admin-1.1.28-1.fc18.x86_64 requires libicui18n.so.48()(64bit)
389-admin-1.1.28-1.fc18.x86_64 requires libicudata.so.48()(64bit)
[389-adminutil]
389-adminutil-1.1.15-2.fc17.i686 requires libicuuc.so.48
389-adminutil-1.1.15-2.fc17.i686 requires libicui18n.so.48
389-adminutil-1.1.15-2.fc17.i686 requires libicudata.so.48
389-adminutil-1.1.15-2.fc17.x86_64 requires libicuuc.so.48()(64bit)
389-adminutil-1.1.15-2.fc17.x86_64 requires libicui18n.so.48()(64bit)
389-adminutil-1.1.15-2.fc17.x86_64 requires libicudata.so.48()(64bit)
[389-dsgw]
389-dsgw-1.1.9-2.fc17.x86_64 requires libicuuc.so.48()(64bit)
389-dsgw-1.1.9-2.fc17.x86_64 requir

[Test-Announce] Fedora 17 FINAL Go/No-Go Meeting (#2), Thursday,May 24, < at >13:00 Eastern

Robyn Bergeron — 2012-05-23T12:16:21

Please join us on irc.freenode.net in #fedora-meeting-1 for this 
important meeting, wherein we shall determine the shipment readiness of 
F17 Final.

Thursday, May 24, 2012 < at > 17:00 UTC (13:00 EDT/10:00 PDT)

"Before each public release Development, QA and Release Engineering meet 
to determine if the release criteria are met for a particular release. 
This meeting is called the Go/No-Go Meeting."

"Verifying that the Release criteria are met is the responsibility of 
the QA Team."

For more details about this meeting see:
https://fedoraproject.org/wiki/Go_No_Go_Meeting

In the meantime: Keep an eye on the blocker list here:
http://fedoraproject.org/wiki/Current_Release_Blockers

Let's ship the beefy miracle, folks! :)

-Robyn
_______________________________________________
test-announce mailing list
test-announce< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce