Re: F15 / VirtualBox

2011-06-10 Thread Richard W.M. Jones
On Thu, Jun 09, 2011 at 04:30:07PM -0700, Dan Young wrote:
 On Thu, Jun 9, 2011 at 3:59 PM, Stephen John Smoogen smo...@gmail.com wrote:
  On Thu, Jun 9, 2011 at 18:37, Dave Jones da...@redhat.com wrote:
  I'm curious why virtualbox has gained so much inertia so quickly.
  Based solely on the number of kernel bug reports we get that seem to be
  related to it, I have almost zero confidence in it being reliable.
 
 
  1) It works in windows
  2) It works in mac os-x
  3) Oracle has put a lot of money/effort in pushing it via searches
 
  and probably a little of:
 
  4) It is not from Red Hat.
 
 5) Free as in beer Windows guest driver binaries?
 
 Acquiring these is non-obvious for KVM/libvirt virtio blk/net Windows
 guest drivers unless you're a RHEL customer.

http://alt.fedoraproject.org/pub/alt/virtio-win/ ?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: F15 / VirtualBox

2011-06-10 Thread Richard W.M. Jones
On Thu, Jun 09, 2011 at 06:37:19PM -0400, Dave Jones wrote:
 I'm curious why virtualbox has gained so much inertia so quickly.
 Based solely on the number of kernel bug reports we get that seem to be
 related to it, I have almost zero confidence in it being reliable.
 
 Why are people choosing it over other solutions, and what can we change
 in qemu/kvm to get users using that instead ?

VirtualBox has a nice GUI which compares well with old versions of
virt-manager.

However virt-manager has come a very long way since and I'd urge
people to try up-to-date versions.  New Fedora comes with it as
standard, or you can do:

  # yum install virt-manager

to install everything required (including libvirt and KVM bits).

The other feature is USB passthrough.  (KVM can do this, but IIRC it
only works for USB 1.1 devices and it's not integrated into the UI).

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


[Bug 696725] RPM doesn't create /var/run/amavisd

2011-06-10 Thread bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


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

Matthias Haase matthias_ha...@bennewitz.com changed:

   What|Removed |Added

 CC||matthias_ha...@bennewitz.co
   ||m

--- Comment #7 from Matthias Haase matthias_ha...@bennewitz.com 2011-06-10 
03:49:03 EDT ---
(In reply to comment #4)
 Created attachment 501354 [details]
 tmpfile.d file
 
 The fix seems to be to place this in /etc/tmpfile.d from the RPM. Is it
 possible to get this added so that things work properly out of the box? Thank
 you.

I have this file added and that doesn't work. No creation of the missed
directory in /var/run
even at boot or using start|stop of amavisd. May be this is  a timimg issue, I
couldn't find out why.

The only working solution at present is creating the missed directory inside of
the start|stop script, as Trever wrote already.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- 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-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel


Re: F15 / VirtualBox

2011-06-10 Thread Peter Robinson
On Thu, Jun 9, 2011 at 11:37 PM, Dave Jones da...@redhat.com wrote:
 On Thu, Jun 09, 2011 at 02:00:57PM +0100, Matthew Garrett wrote:
   On Thu, Jun 09, 2011 at 08:01:06PM +1000, Chris Jones wrote:
  
    I agree. As virtualization technology becomes more and more involved
    and frequent on users systems, particularly with advanced Linux users,
    I think there needs to be a strong focus on ensuring that all releases
    run in virtualized environments without any major issues. ie.
    Virtualbox.
   
    Perhaps a dedicated team among the developers who specialize in this 
 area.
  
   I don't think there are any developers working on this area, where this
   area is Virtualbox. We don't ship Virtualbox. We don't ship a kernel
   that has any knowledge of Virtualbox. There's a good argument for having
   this be part of the QA process and requiring that we boot in the common
   virtualisation environments as part of the release criteria, but I don't
   think we can realistically suggest that our virtualisation developers
   (who work on code that has nothing to do with Virtualbox) be responsible
   for that.

 I'm curious why virtualbox has gained so much inertia so quickly.
 Based solely on the number of kernel bug reports we get that seem to be
 related to it, I have almost zero confidence in it being reliable.

In the OLPC/Sugar world a lot of people use it on Windows/Mac because
its non invasive, simple to use, free, universal on all platforms and
they run Sugar on a Stick in a VM.

 Why are people choosing it over other solutions, and what can we change
 in qemu/kvm to get users using that instead ?

Problem is that in the education space Sugar is aiming at (K-6) Mac
and Windows is the primary OS.

Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: F15 / VirtualBox

2011-06-10 Thread Richard W.M. Jones
On Fri, Jun 10, 2011 at 09:03:16AM +0200, tim.laurid...@gmail.com wrote:
- Local shared folders. to share files from Fedora host to windows
client.

libvirt can do this now, and I think so can virt-manager (not
checked).

http://libvirt.org/formatdomain.html#elementsFilesystems

I'm not sure if it's supported by Windows guests, which may be a
deal-breaker.

- Save current state of guest, so I easy can switch clients with out
having to close the the client OS down.

Snapshots are being added shortly.

- Running Windows application in a windows guest, runs very smooth, no
delay in updating the GUI.

You should try new versions.  I've never had a problem with delays
updating the GUI, even in old versions.  With SPICE support, access
over the network beats everything.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: F15 / VirtualBox

2011-06-10 Thread Tom Hughes
On 10/06/11 09:12, Richard W.M. Jones wrote:
 On Fri, Jun 10, 2011 at 09:03:16AM +0200, tim.laurid...@gmail.com wrote:

 - Running Windows application in a windows guest, runs very smooth, no
 delay in updating the GUI.

 You should try new versions.  I've never had a problem with delays
 updating the GUI, even in old versions.  With SPICE support, access
 over the network beats everything.

Spice is cool, I just wish there was an agent/drivers for 64 bit Windows 
guests...

Not that I have any real problem with a Windows guest and VNC graphics 
but it would be very nice to have working cut and paste.

Tom

-- 
Tom Hughes (t...@compton.nu)
http://compton.nu/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: F15 / VirtualBox

2011-06-10 Thread Tomasz Torcz
On Thu, Jun 09, 2011 at 06:37:19PM -0400, Dave Jones wrote:
 I'm curious why virtualbox has gained so much inertia so quickly.
 Based solely on the number of kernel bug reports we get that seem to be
 related to it, I have almost zero confidence in it being reliable.
 
 Why are people choosing it over other solutions, and what can we change
 in qemu/kvm to get users using that instead ?

  For me, I installed VB to check (then) Sun's Fishworks emulator, which
was distributed as virtualbox image. Afterwards I stayed because:

 - my computer did not have VT-x/SVM (it's not relevant now, most
   computer have)
 - VB has 3D accell support for guest.  Enough to test for example Ubuntu Unity,
   and I believe gnome-shell also. This is BIG advantage.
 - virt-manager storage management is IMO a mess. I created LVM LV for
   new virtual-machine, then went to virt-manager to add this as raw
   file and got lost. I know that I want raw file, but the gui is
   talking about raw files separately from LVM pools.
 - bridged networking works with standard F15 install. With virt-manager
   one need to disable NetworkManager.
 - USB passthrough works.
 - changing virtual CD media is easy and reliable
 - VB provides yum repos

 VirtualBox has disadvantages:
 - it doesn't use kvm-intel for hardware virtualisation. I cannot run
   KVM and VB at the same time.
 - it's memory deduplication reimplements what already in-kernel (for the
   sake of cross platform)

-- 
Tomasz Torcz   Never underestimate the bandwidth of a station
xmpp: zdzich...@chrome.plwagon filled with backup tapes. -- Jim Gray

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


[Fwd: [fedora-arm] Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - TODAY]

2011-06-10 Thread Jon Masters

---BeginMessage---
Hi Folks,

We are hosting a Fedora 15 hardfp Virtual Fedora Activity Day today, at
14:00UTC (10:00 Eastern Daylight Time). The purpose of this session is
to co-ordinate the bootstrap of F15 hardfp (hardware floating point).

You can find a lot more detail here, along with all the pre-reqs/bits:

https://fedoraproject.org/wiki/Architectures/ARM/Fedora15_HardFP_Bootstrap_Virtual_FAD_20110610

Jon.


___
arm mailing list
a...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
---End Message---
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

New cfitsio in rawhide

2011-06-10 Thread Sergio Pascual
Hi, a new cfistio package (3.280) as landed in rawhide. Packages
depending on cfitsio should be rebuilt.


Regards, Sergio
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: F15 / VirtualBox

2011-06-10 Thread Richard W.M. Jones
On Fri, Jun 10, 2011 at 09:18:49AM +0100, Tom Hughes wrote:
 On 10/06/11 09:12, Richard W.M. Jones wrote:
 On Fri, Jun 10, 2011 at 09:03:16AM +0200, tim.laurid...@gmail.com wrote:
 
 - Running Windows application in a windows guest, runs very smooth, no
 delay in updating the GUI.
 
 You should try new versions.  I've never had a problem with delays
 updating the GUI, even in old versions.  With SPICE support, access
 over the network beats everything.
 
 Spice is cool, I just wish there was an agent/drivers for 64 bit
 Windows guests...

They are available, but I think you have to build them yourself from
source.  All the information is here:

http://spice-space.org/page/WinQXL#How_to_build_the_driver

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://et.redhat.com/~rjones/virt-top
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Outage: Server Updates/Reboots - 2011-06-14 21:00 UTC

2011-06-10 Thread Kevin Fenzi
Outage: Server Updates/Reboots - 2011-06-14 21:00 UTC

 There will be an outage starting at 2011-06-14 21:00 UTC, which will last
 approximately 1 hour.

 To convert UTC to your local time, take a look at
 http://fedoraproject.org/wiki/Infrastructure/UTCHowto
 or run:

 date -d '2011-06-14 21:00 UTC'

 Reason for outage:

 Another round of server updates and reboots. Note that these reboots will
 affect contributors/maintainers, but not end users.

 Affected Services:

 Buildsystem - http://koji.fedoraproject.org/
 GIT / Source Control

 Unaffected Services:

 BFO - http://boot.fedoraproject.org/
 Bodhi - https://admin.fedoraproject.org/updates/
 DNS - ns1.fedoraproject.org, ns2.fedoraproject.org
 Docs - http://docs.fedoraproject.org/
 Email system
 Fedora Account System - https://admin.fedoraproject.org/accounts/
 Fedora Community - https://admin.fedoraproject.org/community/
 Fedora Hosted - https://fedorahosted.org/
 Fedora Insight - https://insight.fedoraproject.org/
 Fedora People - http://fedorapeople.org/
 Fedora Talk - http://talk.fedoraproject.org/
 Main Website - http://fedoraproject.org/
 Mirror List - https://mirrors.fedoraproject.org/
 Mirror Manager - https://admin.fedoraproject.org/mirrormanager/
 Package Database - https://admin.fedoraproject.org/pkgdb/
 Smolt - http://smolts.org/
 Spins - http://spins.fedoraproject.org/
 Start - http://start.fedoraproject.org/
 Torrent - http://torrent.fedoraproject.org/
 Translation Services - http://translate.fedoraproject.org/
 Wiki - http://fedoraproject.org/wiki/

 Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/2823

 Contact Information:

 Please join #fedora-admin in irc.freenode.net or add comments to the
 ticket for this outage above.


signature.asc
Description: PGP signature
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide missed an implicit dependency for #!python

2011-06-10 Thread Panu Matilainen
On 06/10/2011 02:28 AM, Josh Stone wrote:
 On 06/02/2011 01:26 PM, Josh Stone wrote:
 Our dtrace script in systemtap-sdt-devel starts #!/usr/bin/python.
 Usually this leads to an implicit Requires: /usr/bin/python, but for
 some reason our rawhide build did not get this.  The F15, F14, and F13
 builds from the same spec required python as expected.
 [...]
 Is this a bug?  Or must we now explicitly require python?

 An output change in file-5.07 appears to have broken find-requires:
 https://bugzilla.redhat.com/show_bug.cgi?id=712251

 And since file-5.07-2.fc15 is now in updates, I would expect this to
 cause even more problems going forward.

Fixed now in rawhide rpm and an update for F15 is here:
https://admin.fedoraproject.org/updates/rpm-4.9.0-9.fc15

Please help testing to get this nasty regression fixed ASAP.

ALL packages containing scripts which have been built while file-5.07 
has been in rawhide (since May 11th)  F15 (in updates-testing since May 
23rd) are affected and will have missing dependencies because of this, 
requiring rebuilds to correct the situation.

Thanks Josh for reporting this, and also apologies for missing your 
initial mail on the subject, reacting then would've saved a week's worth 
of broken builds :-/

- Panu -
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


rawhide report: 20110610 changes

2011-06-10 Thread Rawhide Report
Compose started at Fri Jun 10 08:15:18 UTC 2011

Broken deps for x86_64
--
389-admin-1.1.16-1.fc16.i686 requires libadmsslutil.so.1
389-admin-1.1.16-1.fc16.i686 requires libadminutil.so.1
389-admin-1.1.16-1.fc16.x86_64 requires libadmsslutil.so.1()(64bit)
389-admin-1.1.16-1.fc16.x86_64 requires libadminutil.so.1()(64bit)
389-dsgw-1.1.6-3.fc16.x86_64 requires libadmsslutil.so.1()(64bit)
389-dsgw-1.1.6-3.fc16.x86_64 requires libadminutil.so.1()(64bit)
CGSI-gSOAP-1.3.4.0-2.fc15.i686 requires libvomsapi.so.0
CGSI-gSOAP-1.3.4.0-2.fc15.x86_64 requires libvomsapi.so.0()(64bit)
OpenEXR_Viewers-1.0.2-3.fc15.x86_64 requires libfltk.so.1.1()(64bit)
OpenEXR_Viewers-1.0.2-3.fc15.x86_64 requires libfltk_gl.so.1.1()(64bit)
acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell)
alsa-tools-1.0.24.1-2.fc15.x86_64 requires libfltk.so.1.1()(64bit)
amarok-2.4.1-2.fc16.x86_64 requires libmtp.so.8()(64bit)
bibletime-2.8.1-1.fc16.x86_64 requires libclucene.so.0()(64bit)
camcardsync-0.1.1-4.fc15.x86_64 requires libhal.so.1()(64bit)
clementine-0.7.1-1.fc16.x86_64 requires libmtp.so.8()(64bit)
coda-vcodacon-6.9.5-4.fc15.x86_64 requires libfltk.so.1.1()(64bit)
db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0
deskbar-applet-2.32.0-4.fc15.x86_64 requires gnome-python2-applet
deskbar-applet-2.32.0-4.fc15.x86_64 requires libcamel-1.2.so.23()(64bit)
dh-make-0.55-3.fc15.noarch requires debhelper
ed2k_hash-gui-0.4.0-10.fc13.x86_64 requires libfltk.so.1.1()(64bit)
emacs-common-mozc-1.1.717.102-2.fc16.x86_64 requires 
libprotobuf.so.6()(64bit)
exaile-0.3.2.1-1.fc16.noarch requires hal
fawkes-guis-0.4.2-4.fc16.i686 requires libgraph.so.4
fawkes-guis-0.4.2-4.fc16.i686 requires libcdt.so.4
fawkes-guis-0.4.2-4.fc16.i686 requires libgvc.so.5
fawkes-guis-0.4.2-4.fc16.x86_64 requires libgraph.so.4()(64bit)
fawkes-guis-0.4.2-4.fc16.x86_64 requires libcdt.so.4()(64bit)
fawkes-guis-0.4.2-4.fc16.x86_64 requires libgvc.so.5()(64bit)
fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires 
libgeos-3.2.1.so()(64bit)
file-browser-applet-0.6.6-1.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
fldigi-3.21.7-1.fc16.x86_64 requires libfltk_images.so.1.1()(64bit)
fldigi-3.21.7-1.fc16.x86_64 requires libfltk.so.1.1()(64bit)
flpsed-0.5.2-2.fc15.x86_64 requires libfltk.so.1.1()(64bit)
gdb-heap-0.5-4.fc15.x86_64 requires glibc(x86-64) = 0:2.13.90
gedit-valencia-0.3.0-4.fc14.x86_64 requires libvala-0.10.so.0()(64bit)
gipfel-0.3.2-8.fc15.x86_64 requires libfltk_images.so.1.1()(64bit)
gipfel-0.3.2-8.fc15.x86_64 requires libfltk.so.1.1()(64bit)
gmediaserver-0.13.0-7.fc15.x86_64 requires libupnp.so.3()(64bit)
gmediaserver-0.13.0-7.fc15.x86_64 requires libthreadutil.so.2()(64bit)
gnome-applet-bubblemon-2.0.15-1.fc13.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-cpufire-1.6-3.fc14.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-globalmenu-0.7.9-1.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-grandr-0.4.1-2.fc12.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-sensors-2.2.7-4.fc15.i686 requires libpanel-applet-2.so.0
gnome-applet-sensors-2.2.7-4.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-sshmenu-3.18-3.fc15.noarch requires ruby(panelapplet2)
gnome-applet-timer-2.1.4-2.fc15.x86_64 requires gnome-python2-applet = 
0:2.16
gnome-applet-window-picker-0.5.8-2.fc14.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-device-manager-0.2-6.fc15.x86_64 requires libhal.so.1()(64bit)
gnome-device-manager-devel-0.2-6.fc15.i686 requires hal-devel = 
0:0.5.10
gnome-device-manager-devel-0.2-6.fc15.i686 requires pkgconfig(hal)
gnome-device-manager-devel-0.2-6.fc15.x86_64 requires hal-devel = 
0:0.5.10
gnome-device-manager-devel-0.2-6.fc15.x86_64 requires pkgconfig(hal)
gnome-device-manager-libs-0.2-6.fc15.i686 requires libhal.so.1
gnome-device-manager-libs-0.2-6.fc15.i686 requires hal = 0:0.5.10
gnome-device-manager-libs-0.2-6.fc15.x86_64 requires 
libhal.so.1()(64bit)
gnome-device-manager-libs-0.2-6.fc15.x86_64 requires hal = 0:0.5.10
gnome-netstatus-2.28.2-1.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires 
libgpilotdconduit.so.3()(64bit)
gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires 
libgpilotd.so.5()(64bit)
gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires 
libgpilotdcm.so.4()(64bit)
gnome-pilot-eds-2.91.92-1.fc16.x86_64 requires 
libcamel-1.2.so.23()(64bit)
 

Re: F15 / VirtualBox

2011-06-10 Thread Genes MailLists
On 06/09/2011 06:37 PM, Dave Jones wrote:
 On Thu, Jun 09, 2011 at 02:00:57PM +0100, Matthew Garrett wrote:

  Long list already from others but a couple of other things that are
nice (dont know if qemu has these today, but didn't used to)


   (i) Variable size image for the VM
   - it grows to accommodate need


  (ii) Easy to duplicate VM image (with UUID change)

   So its easy to deploy images on same or different computers

 (iii) All VM data is stored in user home

This means installing a new OS does not negatively impact VM's

  (iv) Control over the network



  There are some cons - I have had it go crazy and exhaust memory - I
have had problems deleting an intermediate snapshot causing troubles for
later snapshots - but overall its easy to use and generally works.

  gene/

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: F15 / VirtualBox

2011-06-10 Thread Neal Becker
Dave Jones wrote:

 On Thu, Jun 09, 2011 at 02:00:57PM +0100, Matthew Garrett wrote:
   On Thu, Jun 09, 2011 at 08:01:06PM +1000, Chris Jones wrote:
   
I agree. As virtualization technology becomes more and more involved
and frequent on users systems, particularly with advanced Linux users,
I think there needs to be a strong focus on ensuring that all releases
run in virtualized environments without any major issues. ie.
Virtualbox.

Perhaps a dedicated team among the developers who specialize in this
area.
   
   I don't think there are any developers working on this area, where this
   area is Virtualbox. We don't ship Virtualbox. We don't ship a kernel
   that has any knowledge of Virtualbox. There's a good argument for having
   this be part of the QA process and requiring that we boot in the common
   virtualisation environments as part of the release criteria, but I don't
   think we can realistically suggest that our virtualisation developers
   (who work on code that has nothing to do with Virtualbox) be responsible
   for that.
 
 I'm curious why virtualbox has gained so much inertia so quickly.
 Based solely on the number of kernel bug reports we get that seem to be
 related to it, I have almost zero confidence in it being reliable.
 
 Why are people choosing it over other solutions, and what can we change
 in qemu/kvm to get users using that instead ?
 
 Dave
  

1. Easy setup of networking (bridged).
2. Support decent graphics mode in guests.  (After installing guest additions, 
a 
winxp guest on fedora host can run in any graphics resolution.  I don't think 
qemu/kvm does this).

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: F15 / VirtualBox

2011-06-10 Thread Thomas Sailer
On Fri, 2011-06-10 at 08:50 +0100, Richard W.M. Jones wrote:

 The other feature is USB passthrough.  (KVM can do this, but IIRC it
 only works for USB 1.1 devices and it's not integrated into the UI).

Last time I tried I had to specify USB device and bus numbers. This is
quite unusable, as they are not stable, when reconnecting the device
usually gets another device number. Some way to specify USB devices by
vendor/device ID or some Manufacturer/Product/Serial string is needed.

Also, I have a strange card reader which I would love to use under some
form of virtualisation, as the accompanying application only runs under
very old versions of windows.

The card reader has the misfeature that it requires firmware to be
loaded by the PC. To get the firmware, it connects, waits about 4
seconds, and if it doesn't get anything it disconnects and reconnects
again. Now qemu/kvm is currently much too slow for this, until the host
notices the USB device and hands it over to the guest, about 5-10sec
pass.

Tom


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: F15 / VirtualBox

2011-06-10 Thread Thomas Sailer
On Fri, 2011-06-10 at 10:24 +0200, Tomasz Torcz wrote:

  - it's memory deduplication reimplements what already in-kernel (for the
sake of cross platform)

Kernel deduplication runs amok on my machine. When I have two guests,
one Windows, one Rawhide, running under kvm/qemu, kernel deduplication
uses up one CPU core. For no benefit, I suspect there isn't much to
deduplicate between Windows and Rawhide.

Tom


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Provenpackager help for razertool removal

2011-06-10 Thread Christoph Wickert
Am Sonntag, den 05.06.2011, 13:19 +0200 schrieb Nicola Soranzo:
 razertool package is dead upstream 

razercfg [1] it the successor of razertool. If somebody packages it up,
it would be nice to have the package properly obsolete razertool.

Regards,
Christoph

[1] http://bues.ch/cms/hacking/razercfg.html

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


[perl-Newt] Perl 5.14 mass rebuild

2011-06-10 Thread Marcela Mašláňová
commit 5b996572e5f94e81faea0fb17c4d679849caa698
Author: Marcela Mašláňová mmasl...@redhat.com
Date:   Fri Jun 10 14:35:15 2011 +0200

Perl 5.14 mass rebuild

 perl-Newt.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Newt.spec b/perl-Newt.spec
index 8415f91..79eb48a 100644
--- a/perl-Newt.spec
+++ b/perl-Newt.spec
@@ -1,7 +1,7 @@
 Summary: Perl bindings for the Newt library
 Name: perl-Newt
 Version: 1.08
-Release: 28%{?dist}
+Release: 29%{?dist}
 Group: System Environment/Libraries
 BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-buildroot
 URL: http://search.cpan.org/~amedina/Newt-1.08/
@@ -62,6 +62,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/Newt*
 
 %changelog
+* Fri Jun 10 2011 Marcela Mašláňová mmasl...@redhat.com - 1.08-29
+- Perl 5.14 mass rebuild
+
 * Tue Feb 08 2011 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 1.08-28
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
 
--
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

[perl-PBS] Perl 5.14 mass rebuild

2011-06-10 Thread Marcela Mašláňová
commit 4d7d2773aaae65d4fc4b2c142824d9c87cc3dd75
Author: Marcela Mašláňová mmasl...@redhat.com
Date:   Fri Jun 10 14:35:42 2011 +0200

Perl 5.14 mass rebuild

 perl-PBS.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-PBS.spec b/perl-PBS.spec
index 0372c6d..a7abde8 100644
--- a/perl-PBS.spec
+++ b/perl-PBS.spec
@@ -1,6 +1,6 @@
 Name:   perl-PBS
 Version:0.33
-Release:12%{?dist}
+Release:13%{?dist}
 Summary:Perl binding for the Portable Batch System client library
 
 Group:  Development/Libraries
@@ -83,6 +83,9 @@ rm -rf $RPM_BUILD_ROOT
 
 
 %changelog
+* Fri Jun 10 2011 Marcela Mašláňová mmasl...@redhat.com - 0.33-13
+- Perl 5.14 mass rebuild
+
 * Tue Feb 08 2011 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 0.33-12
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
 
--
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

systemd: please stop trying to take over the world :)

2011-06-10 Thread Denys Vlasenko
Hi Lennart,

systemd is eating a lot more memory than any other init process
I ever played with.

Granted, systemd does a bit more that typical init, but I think
using *eleven plus megabytes* of malloced space is a bit much.

systemctl --all shows 258 units total on my machine,
thus systemd uses ~40 *KILO*bytes of state per unit?

I understand your desire to replace everything by systemd.
I really do. syslogd, klogd, mount, fsck, and a dozen other things
I forget or don't know. It's called featuritis.
Now I hear about plans to incorporate ConsoleKit into it
(hearsay, so maybe it's not true).

Look where it is now:

Top:

Mem total:2035840 anon:431208 map:78924 free:419084
 slab:91624 buf:108040 cache:942336 dirty:196 write:0
Swap total:4095996 free:4095996
  PID   VSZ VSZRW   RSS (SHR)*DIRTY (SHR) STACK COMMAND
 1818  624m  365m  185m 13472  155m64   224 /usr/lib/firefox-4/firefox
 1816  433m  189m  166m 17248  142m 0   204 evolution
 1257 53672 40400 22664  6004 18336  4176   132 /usr/bin/Xorg
1 15384 11856 13664  1340 11752 0   132 /sbin/init
^ ^ 11.7 megs of malloc space

 1839  275m 40224 24208 10572 11020 0   132 /usr/bin/gnome-terminal
 1713  202m 45284 20308  9736  9604   576   132 
/usr/libexec/xfce4/panel-plugins/xfce4-mixer-plugin
 1843  171m  9448 20264 10012  8440   344   204 xchat
 1770  152m 55672 19412 10972  6108 0   132 nautilus

It's the *fourth* largest process on my system!


# ldd `which systemd`
linux-gate.so.1 =  (0x00a6b000)
libselinux.so.1 = /lib/libselinux.so.1 (0x414f6000)
libdbus-1.so.3 = /lib/libdbus-1.so.3 (0x41bc1000)
libpthread.so.0 = /lib/libpthread.so.0 (0x0019a000)
libudev.so.0 = /lib/libudev.so.0 (0x422c9000)
libwrap.so.0 = /lib/libwrap.so.0 (0x420fa000)
libpam.so.0 = /lib/libpam.so.0 (0x420e6000)
libaudit.so.1 = /lib/libaudit.so.1 (0x420cc000)
libcap.so.2 = /lib/libcap.so.2 (0x4152f000)
librt.so.1 = /lib/librt.so.1 (0x00be8000)
libc.so.6 = /lib/libc.so.6 (0x00295000)
/lib/ld-linux.so.2 (0x00276000)
libdl.so.2 = /lib/libdl.so.2 (0x00af6000)
libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x00f68000)
libnsl.so.1 = /lib/libnsl.so.1 (0x0095c000)
libattr.so.1 = /lib/libattr.so.1 (0x420c5000)

Why does systemd link against libpam?
systemd does logins now, not /bin/login or gdm or ...?

libattr? Does it mean it requires filesystem which implements
extended attributes? If not, why does it use libattr then?

libwrap? systemd is a network application now too?

libaudit? What systemd has in common with audit?

libdbus?... this is a lost battle I guess...

I propose to stop for a second and optimize systemd down
instead of trying to add even more bells and whistles to it.
Or else you'll soon end up linking against every /lib/lib*.so*

At the very least, I would like to see its memory consumption
to go down substantially.

It is an *init replacement*, not the replacement for everything.
One of init's goal is to be *simple* and *stable*.
Every new feature you add and library you link against
works against that goal.

To be honest, I doubt the wisdom of implementing service manager
as an init process. There is no inherent reason why it has to be init -
you can run it as *a child of init*, and keep init very simple.
Then, if service manager would crash, at least it doesn't
take system down with it...

-- 
vda


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: F15 / VirtualBox

2011-06-10 Thread Przemek Klosowski
On 06/09/2011 07:44 PM, Chris Jones wrote:

 Also, for those that may not be aware, Virtualbox can be installed in
 just 2 commands in your Fedora system. Assuming you have wget installed.
...
 ~$ su
 wget
 http://download.virtualbox.org/virtualbox/4.0.8/VirtualBox-4.0-4.0.8_71778_fedora15-1.x86_64.rpm
 yum install VirtualBox-4.0-4.0.8_71778_fedora15-1.x86_64.rpm


Make it one command:

yum install 
http://download.virtualbox.org/virtualbox/4.0.8/VirtualBox-4.0-4.0.8_71778_fedora15-1.x86_64.rpm

(or VirtualBox-4.0-4.0.8_71778_fedora15-1.i686.rpm for 32-bit systems)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: systemd: please stop trying to take over the world :)

2011-06-10 Thread Michal Schmidt
On 06/10/2011 03:07 PM, Denys Vlasenko wrote:
 I understand your desire to replace everything by systemd.
 I really do. syslogd, klogd, mount, fsck, and a dozen other things
 I forget or don't know.

You're exaggerating.

 Why does systemd link against libpam?
 systemd does logins now, not /bin/login or gdm or ...?

to implement PAMName= (man systemd.exec)

 libattr? Does it mean it requires filesystem which implements
 extended attributes? If not, why does it use libattr then?

systemd uses libcap. libcap depends on libattr.

 libwrap? systemd is a network application now too?

to implement TCPWrapName= (man systemd.exec)

 libaudit? What systemd has in common with audit?

Start and stop of a service is an auditable event.
http://lists.fedoraproject.org/pipermail/devel/2010-August/141543.html

 To be honest, I doubt the wisdom of implementing service manager
 as an init process. There is no inherent reason why it has to be init -
 you can run it as *a child of init*, and keep init very simple.
 Then, if service manager would crash, at least it doesn't
 take system down with it...

systemd does not take the system down when it crashes. It catches the 
signal, dumps core and freezes, but does not exit.

Michal
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: F15 / VirtualBox

2011-06-10 Thread Richard W.M. Jones
On Fri, Jun 10, 2011 at 08:08:26AM -0400, Genes MailLists wrote:
(i) Variable size image for the VM
- it grows to accommodate need

Interested to know why sparse images or qcow2 don't fulfil your needs.
These have been supported in KVM (and Xen) since forever.

   (ii) Easy to duplicate VM image (with UUID change)
 
So its easy to deploy images on same or different computers

This is what I do:

https://rwmj.wordpress.com/2010/09/24/tip-my-procedure-for-cloning-a-fedora-vm/

Also I'm still looking at what to do about the virt-clone tool:

https://rwmj.wordpress.com/2011/05/11/virt-tools-survey-virt-clone/

  (iii) All VM data is stored in user home
 
 This means installing a new OS does not negatively impact VM's

You can do this with KVM too.  There is a performance penalty to using
files (but VirtualBox has the same penalty).  With old libvirt you had
to set SELinux labels manually, but new versions do it for you.

   (iv) Control over the network

I actually prefer libvirt's default (private network with NAT)
configuration.  It's good for what I do which is testing lots of VMs.

It's a lot better than Xen's default setting of bugger up the network,
or VMware's first, install these binary drivers in your kernel config.

For production, I change libvirt to use a shared bridge by adjusting a
couple of configuration files:

http://wiki.libvirt.org/page/Networking#Bridged_networking_.28aka_.22shared_physical_device.22.29

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://et.redhat.com/~rjones/virt-top
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: F15 / VirtualBox

2011-06-10 Thread Richard W.M. Jones
On Fri, Jun 10, 2011 at 08:22:37AM -0400, Neal Becker wrote:
 2. Support decent graphics mode in guests.  (After installing guest
 additions, a winxp guest on fedora host can run in any graphics
 resolution.  I don't think qemu/kvm does this).

With SPICE, maximum resolution is 2560x1600.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: systemd: please stop trying to take over the world :)

2011-06-10 Thread Steve Clark

On 06/10/2011 09:36 AM, Michal Schmidt wrote:

On 06/10/2011 03:07 PM, Denys Vlasenko wrote:

I understand your desire to replace everything by systemd.
I really do. syslogd, klogd, mount, fsck, and a dozen other things
I forget or don't know.

You're exaggerating.


Why does systemd link against libpam?
systemd does logins now, not /bin/login or gdm or ...?

to implement PAMName= (man systemd.exec)


libattr? Does it mean it requires filesystem which implements
extended attributes? If not, why does it use libattr then?

systemd uses libcap. libcap depends on libattr.


libwrap? systemd is a network application now too?

to implement TCPWrapName= (man systemd.exec)


libaudit? What systemd has in common with audit?

Start and stop of a service is an auditable event.
http://lists.fedoraproject.org/pipermail/devel/2010-August/141543.html


To be honest, I doubt the wisdom of implementing service manager
as an init process. There is no inherent reason why it has to be init -
you can run it as *a child of init*, and keep init very simple.
Then, if service manager would crash, at least it doesn't
take system down with it...

systemd does not take the system down when it crashes. It catches the
signal, dumps core and freezes, but does not exit.
^^^

So you just end up with a froze system instead of a crashed system

Michal



--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd: please stop trying to take over the world :)

2011-06-10 Thread Steve Clark

On 06/10/2011 09:07 AM, Denys Vlasenko wrote:

Hi Lennart,

systemd is eating a lot more memory than any other init process
I ever played with.

Granted, systemd does a bit more that typical init, but I think
using *eleven plus megabytes* of malloced space is a bit much.

systemctl --all shows 258 units total on my machine,
thus systemd uses ~40 *KILO*bytes of state per unit?

I understand your desire to replace everything by systemd.
I really do. syslogd, klogd, mount, fsck, and a dozen other things
I forget or don't know. It's called featuritis.
Now I hear about plans to incorporate ConsoleKit into it
(hearsay, so maybe it's not true).

Look where it is now:

Top:

Mem total:2035840 anon:431208 map:78924 free:419084
  slab:91624 buf:108040 cache:942336 dirty:196 write:0
Swap total:4095996 free:4095996
   PID   VSZ VSZRW   RSS (SHR)*DIRTY (SHR) STACK COMMAND
  1818  624m  365m  185m 13472  155m64   224 /usr/lib/firefox-4/firefox
  1816  433m  189m  166m 17248  142m 0   204 evolution
  1257 53672 40400 22664  6004 18336  4176   132 /usr/bin/Xorg
 1 15384 11856 13664  1340 11752 0   132 /sbin/init
^ ^ 11.7 megs of malloc space

  1839  275m 40224 24208 10572 11020 0   132 /usr/bin/gnome-terminal
  1713  202m 45284 20308  9736  9604   576   132 
/usr/libexec/xfce4/panel-plugins/xfce4-mixer-plugin
  1843  171m  9448 20264 10012  8440   344   204 xchat
  1770  152m 55672 19412 10972  6108 0   132 nautilus

It's the *fourth* largest process on my system!


# ldd `which systemd`
linux-gate.so.1 =   (0x00a6b000)
libselinux.so.1 =  /lib/libselinux.so.1 (0x414f6000)
libdbus-1.so.3 =  /lib/libdbus-1.so.3 (0x41bc1000)
libpthread.so.0 =  /lib/libpthread.so.0 (0x0019a000)
libudev.so.0 =  /lib/libudev.so.0 (0x422c9000)
libwrap.so.0 =  /lib/libwrap.so.0 (0x420fa000)
libpam.so.0 =  /lib/libpam.so.0 (0x420e6000)
libaudit.so.1 =  /lib/libaudit.so.1 (0x420cc000)
libcap.so.2 =  /lib/libcap.so.2 (0x4152f000)
librt.so.1 =  /lib/librt.so.1 (0x00be8000)
libc.so.6 =  /lib/libc.so.6 (0x00295000)
/lib/ld-linux.so.2 (0x00276000)
libdl.so.2 =  /lib/libdl.so.2 (0x00af6000)
libgcc_s.so.1 =  /lib/libgcc_s.so.1 (0x00f68000)
libnsl.so.1 =  /lib/libnsl.so.1 (0x0095c000)
libattr.so.1 =  /lib/libattr.so.1 (0x420c5000)

Why does systemd link against libpam?
systemd does logins now, not /bin/login or gdm or ...?

libattr? Does it mean it requires filesystem which implements
extended attributes? If not, why does it use libattr then?

libwrap? systemd is a network application now too?

libaudit? What systemd has in common with audit?

libdbus?... this is a lost battle I guess...

I propose to stop for a second and optimize systemd down
instead of trying to add even more bells and whistles to it.
Or else you'll soon end up linking against every /lib/lib*.so*

At the very least, I would like to see its memory consumption
to go down substantially.

It is an *init replacement*, not the replacement for everything.
One of init's goal is to be *simple* and *stable*.
Every new feature you add and library you link against
works against that goal.

To be honest, I doubt the wisdom of implementing service manager
as an init process. There is no inherent reason why it has to be init -
you can run it as *a child of init*, and keep init very simple.
Then, if service manager would crash, at least it doesn't
take system down with it...


Yes, whatever happened to the *NIX philosophy of simple non-complex programs 
that did
their job well. It has seemed to serve well since the 70's.

--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd: please stop trying to take over the world :)

2011-06-10 Thread Michal Schmidt
On 06/10/2011 03:59 PM, Steve Clark wrote:
 On 06/10/2011 09:36 AM, Michal Schmidt wrote:
 systemd does not take the system down when it crashes. It catches the
 signal, dumps core and freezes, but does not exit.
 ^^^
 So you just end up with a froze system instead of a crashed system

No, only systemd freezes itself. Other processes continue running.

Michal
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: F15 / VirtualBox

2011-06-10 Thread Mark Bidewell
 Why are people choosing it over other solutions, and what can we change
 in qemu/kvm to get users using that instead ?

 Dave


 1. Easy setup of networking (bridged).
 2. Support decent graphics mode in guests.  (After installing guest 
 additions, a
 winxp guest on fedora host can run in any graphics resolution.  I don't think
 qemu/kvm does this).

 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel


To add to the point about graphics support there is also the fact that
GNOME3/Unity will only run with accelerated graphics which only
VirtualBox supports.

-- 
Mark Bidewell
http://www.linkedin.com/in/markbidewell
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Orphaning Slim

2011-06-10 Thread Christoph Wickert
Am Donnerstag, den 09.06.2011, 13:40 +0400 schrieb Lucas:
 What kind of relation between Xfce maintainers and SLIM. 

The Fedora Xfce SIG considered SLIM but we didn't use it because (at
least at that time) it had some problems with ConsoleKit. 

We are still trying to get rid of GDM but we are more after LightDM now.
I have packaged it and it basically works on F = 15, but the package
and LightDM requires some more work.

I don't think that Xfce upstream has a relationship to SLIM in
particular because the project seems pretty much dead.

 I always thought SLIM is just display manager, which can start 
 whatever I want.

That is correct, but you either need to configure the default desktop or
use the sylm-dynwm script. For more info have a look at
https://fedoraproject.org/wiki/LXDE#SLiM

Regards,
Christoph


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Election Results for FESCo and Fedora Board seats

2011-06-10 Thread Jared K. Smith
I'm happy to announce the results of our recent round of elections for
at-large seats on the Fedora Board and FESCo, and FAmSCo.  The results
are as follows:

FESCo

There were five FESCo seats up for election this cycle.  A total of
200 ballots were cast in the FESCo election.  Each of the eight
candidates could receive up to 1600 votes (200 ballots multiplied by 8
candidates).

Votes | Candidate
--
1120 | Kevin Fenzi (nirik)
1020 | Bill Nottingham (notting)
 764 | Tomáš Mráz (t8m)
 699 | Peter Jones (pjones)
 567 | Stephen Gallagher (sgallagh)

 535 | Kyle McMartin (kylem)
 480 | Justin Forbes (jforbes)
 398 | Iain Arnell (iarnell)

The top five candidates were Kevin, Bill, Tomáš, Peter, and Stephen.
Each will server a full two-term position on the Fedora Engineering
Steering committee.

* * * * *

Fedora Board
-
There were three open seats on the Fedora Board this election cycle. A
total of 204 ballots were cast.  Due to the system of range voting
that we use in Fedora elections, this means that each of the six
candidates could receive up to 224 votes (204 ballots multiplied by 6
candidates).

Votes | Candidate
--
 833 | Rex Dieter (rdieter)
 608 | Jon Stanley (jds2001)
 607 | Peter Robinson (pbrobinson)

 421 | Robert 'Bob' Jensen (EvilBob)
 367 | Andrea Veri (averi)
 274 | Zach Oglesby (zoglesby)

I'm pleased to have Rex and Jon return as members of the Board, and
welcome Peter to the Fedora Board as well.  All three of these
individuals will serve full two-term positions on the Fedora Board.

--
Jared Smith
Fedora Project Leader
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15 / VirtualBox

2011-06-10 Thread Michael Cronenworth
Richard W.M. Jones wrote:
 They are available, but I think you have to build them yourself from
 source.  All the information is here:

This is not an argument for libvirt/kvm/qemu/spice but against.

Here's some constructive advice:

1. Give the Red Hat virtualization tools one, unique name and package it 
under that name. Having a new name for every new feature isn't helping 
your cause. Call it RHVM even. Anything is better than the current 
situation and I'm sure a marketing wizard would love to tackle this.
2. Make guest additions dead simple to install. Having to compile them 
with a Windows DDK is not dead simple.
3. Transparent network access. Having to setup bridges or manually edit 
config files is a big turn off to some folks. I know virt-manager has a 
GUI for some operations, but I still see editing config files a 
recommended method in recent mailing list postings.
4. Support USB 2.0+ in a easy-to-use way. Under VB, I can just click on 
a device I want to use, while the VM is running, and use it. When I'm 
done, I uncheck the device, again, while the VM is running, and it 
disconnects from the VM and returns for use to my Fedora box.
5. Exporting VMs must be a two-click process. Not a 9 command, terminal 
operation. Importing VMs must be just as easy.

Now, if you don't care to cater to dumb folk, then continue what you 
are doing. VirtualBox will continue to be used over anything Fedora offers.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: F15 / VirtualBox

2011-06-10 Thread Adam Jackson
On 6/10/11 10:39 AM, Mark Bidewell wrote:

 To add to the point about graphics support there is also the fact that
 GNOME3/Unity will only run with accelerated graphics which only
 VirtualBox supports.

I have Gnome 3 running with software GL.  I'll probably be blogging 
about it soon, it's not quite in a mergeable state for Mesa yet but it's 
looking quite credible.

- ajax
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: F15 / VirtualBox

2011-06-10 Thread Tom Hughes
On 10/06/11 16:12, Michael Cronenworth wrote:

 Richard W.M. Jones wrote:
 
 They are available, but I think you have to build them yourself from
 source.  All the information is here:

 2. Make guest additions dead simple to install. Having to compile them
 with a Windows DDK is not dead simple.

Actually building the driver (once I'd downloaded the 620Mb DDK) was 
quite easy. I'm still scratching my head over how to actually install it 
though ;-)

That was only the graphics driver anyway - what I really want is the 
agent for the clipboard protocol.

To be fair you can download both the drivers and the agent in prebuilt 
form at http://spice-space.org/download.html but only for 32 bit Windows 
at the moment.

Tom

-- 
Tom Hughes (t...@compton.nu)
http://compton.nu/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: F15 / VirtualBox

2011-06-10 Thread Michael Cronenworth
Tom Hughes on 06/10/2011 10:25 AM wrote:
 Actually building the driver (once I'd downloaded the 620Mb DDK) was
 quite easy. I'm still scratching my head over how to actually install it
 though ;-)

 That was only the graphics driver anyway - what I really want is the
 agent for the clipboard protocol.

 To be fair you can download both the drivers and the agent in prebuilt
 form at http://spice-space.org/download.html but only for 32 bit Windows
 at the moment.

I'm not sure why you're using this argument as a positive thing. In VB 
(or any third-party VM software) installing the guest additions for 
32-bit /and/ 64-bit OSes is as easy and clicking Install and 
rebooting. No driver downloads. No config file editing. Until 
libvirt/qemu/kvm/spice provide a similar solution there is no comparison.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: F15 / VirtualBox

2011-06-10 Thread Tom Hughes
On 10/06/11 16:54, Michael Cronenworth wrote:
 Tom Hughes on 06/10/2011 10:25 AM wrote:
 Actually building the driver (once I'd downloaded the 620Mb DDK) was
 quite easy. I'm still scratching my head over how to actually install it
 though ;-)

 That was only the graphics driver anyway - what I really want is the
 agent for the clipboard protocol.

 To be fair you can download both the drivers and the agent in prebuilt
 form at http://spice-space.org/download.html but only for 32 bit Windows
 at the moment.

 I'm not sure why you're using this argument as a positive thing. In VB
 (or any third-party VM software) installing the guest additions for
 32-bit /and/ 64-bit OSes is as easy and clicking Install and
 rebooting. No driver downloads. No config file editing. Until
 libvirt/qemu/kvm/spice provide a similar solution there is no comparison.

I wasn't trying to suggest that the current situation is perfect, just 
that it isn't always as bad as the DDK thing sounded.

Tom

-- 
Tom Hughes (t...@compton.nu)
http://compton.nu/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: F15 / VirtualBox

2011-06-10 Thread Thomas Sailer
On Fri, 2011-06-10 at 14:29 +0100, Richard W.M. Jones wrote:

 There's a bug for these issues (no resolution though):
 
 https://bugzilla.redhat.com/show_bug.cgi?id=541230

My case was way more extreme, one core pretty much fully used by ksmd.
It was with late F14, just before the release of F15.

 It's also worth noting that there are lots of knobs to tune KSM in
 /etc/ksmtuned.conf.  More information is here:

Yes, I eventually found out how to disable ksmd. I think that's not the
point, the point is that kvm/qemu/virt-manager could be improved in the
usability department. And that means it should do a reasonable job
without the user first modify lots of tunables.

virt-manager has gone a long way of making qemu/kvm a lot more useable,
but there's still room for improvements:

- I had occasional problems with the keyboard mapping

- Storage management is not always logical to me, I didn't find out how
to reuse an existing qcow2 image, so in the end I edited config files
manually

- USB is not really workable. Trying it just now with up2date F15
crashed qemu (guest rawhide) when trying to assign a host USB device to
the guest

Tom


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Orphaning Slim

2011-06-10 Thread Lucas
On 06/10/2011 07:04 PM, Christoph Wickert wrote:
 Am Donnerstag, den 09.06.2011, 13:40 +0400 schrieb Lucas:
 What kind of relation between Xfce maintainers and SLIM.

 The Fedora Xfce SIG considered SLIM but we didn't use it because (at
 least at that time) it had some problems with ConsoleKit.


I use xfce since fedora 13 and slim also. I always had to do something to make 
it works.
What are those problems with consolekit you mentioned?


 We are still trying to get rid of GDM but we are more after LightDM now.
 I have packaged it and it basically works on F= 15, but the package
 and LightDM requires some more work.

 I don't think that Xfce upstream has a relationship to SLIM in
 particular because the project seems pretty much dead.

 I always thought SLIM is just display manager, which can start
 whatever I want.

 That is correct, but you either need to configure the default desktop or
 use the sylm-dynwm script. For more info have a look at
 https://fedoraproject.org/wiki/LXDE#SLiM

 Regards,
 Christoph



I, personally, agree that GDM should be replaced, especially after someone 
decided to move reboot 
and shutdown to it. (I found it in Fedora XFCE spin), so now I am thinking 
how to allow systemctl 
reboot for normal user from xfce.
I will check LightDM, but as long as slim works for me, I am going to use it.


Thanks.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: systemd: please stop trying to take over the world :)

2011-06-10 Thread Denys Vlasenko
On Fri, 2011-06-10 at 15:36 +0200, Michal Schmidt wrote:
  Why does systemd link against libpam?
  systemd does logins now, not /bin/login or gdm or ...?
 
 to implement PAMName= (man systemd.exec)

I don't see any users of this feature on my F15.
I searched with Google and come up empty too.

But anyway, assuming it's a useful feature, why it has to be done by
systemd?

I looked at implementation.
systemd-26/src/execute.c::setup_pam():

/* We set up PAM in the parent process, then fork. The child
 * will then stay around until killed via PR_GET_PDEATHSIG or
 * systemd via the cgroup logic. It will then remove the PAM
 * session again. The parent process will exec() the actual
 * daemon. We do things this way to ensure that the main PID
 * of the daemon is the one we initially fork()ed. */

I don't see any attempt to free at least something in the child.
So, systemd forks a process with eleven megabyte of malloced stuff
to act just as a babysitter - wait for parent to die, call pam_end,
exit?
For how long will it hang around in the system - possibly days?

Yes, COW, so not all of these eleven megabytes will be around...
...at first, until parent execs, or modifies sufficiently many pages
so that most of them are copied.

But memory consumption is not really the gist of my argument, it's:
why systemd tries to be all things for all people?

Why it has to care about PAM? I think most tools which need it do it
themselves, and we can write a small, really small helper for those
which don't.


  libwrap? systemd is a network application now too?
 
 to implement TCPWrapName= (man systemd.exec)

Again, why it has to be done *by systemd*?




On Fri, 2011-06-10 at 10:09 -0400, Steve Clark wrote:
  Yes, whatever happened to the *NIX philosophy of simple non-complex
 programs that did their job well. It has seemed to serve well since
 the 70's.

Exactly my point.

-- 
vda


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: [FHS] helper scripts location

2011-06-10 Thread Toshio Kuratomi
On Thu, Jun 09, 2011 at 12:14:45PM +0200, 80 wrote:
 Hi,
 
 I'm reviewing osc and osc-source_validators (osc is Opensuse Build
 Service CLI, the latter a plugin to the former).
 An issue arose about helpers script location:
 1) Fedora packaging guidelines suggests helpers *should go*
 /usr/libexec for helpers == requires patching since osc search
 helpers in /usr/lib
 since it's not in FHS, it's almost certain that a patch won't be upstream-able

This would be the most proper location on Fedora.  Note that many upstreams
do take patches of this sort as long as the libexecdir is settable.
libexecdir is a GNU Coding Standard directory; on Debian or other systems
that disallow /usr/libexecdir, libexecdir gets set to /usr/lib.

http://www.gnu.org/prep/standards/html_node/Directory-Variables.html

 2) FHS explicitely allows shell scripts in /usr/lib

I don't actually see this.  Could you point me to the quote and section?

Additionally, the GNU Coding standards explicitly prohibit this (to be clear
the GNU coding standards are not definitive for Fedora like the FHS is at
this time; I'm including the quotation to show what current best practices
are in this regard):

‘libdir’
The directory for object files and libraries of object code. Do not install
executables here, they probably ought to go in ‘$(libexecdir)’ instead.


At similar weight is the fact that some programs currently violate the GNU
Coding Standard recommendation here.  However, I can't think of one of those
off the top of my head that is a unix-y program so those may be more
workaround than paradigm setters.

 3) FHS doesn't forbid putting them in /usr/share as helpers could be
 considered as arch independent data
 
nod

 There are recent packages that choose options 2  3 (namely, systemd
 and dracut).
 According to me, guidelines doesn't enforce any of these options, and
 choice is left to packager/reviewer appreciation, though you may
 distinguish an order of precedence.
 
 So, what's the take of my fellow packagers on that particular matter ?
 
Preference-wise, I would say $LIBEXECDIR; settable at build time to
/usr/libexec on Fedora-style distros and /usr/lib on Debian-style distros is
the best method here.  Since we're talking scripts (architecture
independent), /usr/share may also make sense but I'm not a big fan of it.
If you can find me the piece of FHS that explicitly allows shell scripts in
/usr/lib I can figure out how that compares to using /usr/lib.


-Toshio


pgpJOiL9MbpJG.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd: please stop trying to take over the world :)

2011-06-10 Thread Denys Vlasenko
On Fri, 2011-06-10 at 16:11 +0200, Michal Schmidt wrote:
 On 06/10/2011 03:59 PM, Steve Clark wrote:
  On 06/10/2011 09:36 AM, Michal Schmidt wrote:
  systemd does not take the system down when it crashes. It catches the
  signal, dumps core and freezes, but does not exit.
  ^^^
  So you just end up with a froze system instead of a crashed system
 
 No, only systemd freezes itself. Other processes continue running.

systemd-26/src/main.c::crash() is the function which does it.
Assuming it will not recurse by crashing again, of course. It calls
log_error and assert_se, which go into log_dispatch(), which logs to
syslog, may try to write to klog, and whatnot... this doesn't look
too robust to me.

But anyway. Assuming it successfully froze. Does it help?
Yes. How much? Well, it's better than instant oops which happens
when PID 1 exits, but reaping of processes reparented
to init will stop, which, for example, makes the hang from pid
exhaustion just a question of time.

Ultimately, this stems from the decision to make systemd
to run as PID 1 process. Are there technical reasons for this?

-- 
vda


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: systemd: please stop trying to take over the world :)

2011-06-10 Thread Lucas
On 06/10/2011 08:42 PM, Denys Vlasenko wrote:
 On Fri, 2011-06-10 at 15:36 +0200, Michal Schmidt wrote:
 Why does systemd link against libpam?
 systemd does logins now, not /bin/login or gdm or ...?

 to implement PAMName= (man systemd.exec)

 I don't see any users of this feature on my F15.
 I searched with Google and come up empty too.

 But anyway, assuming it's a useful feature, why it has to be done by
 systemd?

 I looked at implementation.
 systemd-26/src/execute.c::setup_pam():

  /* We set up PAM in the parent process, then fork. The child
   * will then stay around until killed via PR_GET_PDEATHSIG or
   * systemd via the cgroup logic. It will then remove the PAM
   * session again. The parent process will exec() the actual
   * daemon. We do things this way to ensure that the main PID
   * of the daemon is the one we initially fork()ed. */

 I don't see any attempt to free at least something in the child.
 So, systemd forks a process with eleven megabyte of malloced stuff
 to act just as a babysitter - wait for parent to die, call pam_end,
 exit?
 For how long will it hang around in the system - possibly days?

 Yes, COW, so not all of these eleven megabytes will be around...
 ...at first, until parent execs, or modifies sufficiently many pages
 so that most of them are copied.

 But memory consumption is not really the gist of my argument, it's:
 why systemd tries to be all things for all people?

 Why it has to care about PAM? I think most tools which need it do it
 themselves, and we can write a small, really small helper for those
 which don't.


 libwrap? systemd is a network application now too?

 to implement TCPWrapName= (man systemd.exec)

 Again, why it has to be done *by systemd*?




 On Fri, 2011-06-10 at 10:09 -0400, Steve Clark wrote:
 Yes, whatever happened to the *NIX philosophy of simple non-complex
 programs that did their job well. It has seemed to serve well since
 the 70's.

 Exactly my point.



It looks like it is the right time to think about upstart again. I will 
definitely check it out on 
rawhide.
Thanks to OP for pointing on some difficulties. More important that it will be 
not so easy to clean 
that all up latter and we will get eventually unmanageable windows.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: systemd: please stop trying to take over the world :)

2011-06-10 Thread Colin Walters
On Fri, Jun 10, 2011 at 9:07 AM, Denys Vlasenko dvlas...@redhat.com wrote:

 It's the *fourth* largest process on my system!


 # ldd `which systemd`

1) Looking at what libraries a binary links to a is a terrible way to
optimize memory usage; try massif, say
2) It'd be a lot more productive to be positive and not phrase your
message in such an antagonistic way (in fact, this message would
probably be better on the systemd-devel mailing list)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


[389-devel] Please review: Bug 706472 - [console] java exception throw in UI, but user gets created

2011-06-10 Thread Rich Megginson
https://bugzilla.redhat.com/show_bug.cgi?id=706472

https://bugzilla.redhat.com/attachment.cgi?id=504157action=diff
https://bugzilla.redhat.com/attachment.cgi?id=504159

https://bugzilla.redhat.com/attachment.cgi?id=504157action=edit
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel


Bodhi v0.8 in production

2011-06-10 Thread Luke Macken
https://admin.fedoraproject.org/updates

Frontend Web/Client Changes
---

* Buildroot Override Management
  http://fedoraproject.org/wiki/Bodhi/BuildRootOverrides
* Make update notes mandatory (fesco#457)
* Gracefully handle invalid update template values (#597)
* Fixed a bug that would prevent people from editing updates

Backend Changes
---

* Support blacklisting certain users from receiving bodhi emails (for 
autoqa)
* More robust handling of 'pending' koji tags (#594)
* More configurable for non-Fedora deployments
* Added more metrics to our report generator
* # of updates that reach the stable karma threshold
* # of updates that spent the minimum time in testing
* # of proventester karma types
* output: https://fedorahosted.org/fesco/ticket/517#comment:5

API Changes
---

* Optimize our 'list' API when querying updates by bug number (#610)
* Support adding comments without triggering email notifications (to 
prevent AutoQA spamming)


signature.asc
Description: PGP signature
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Heads up: protobuf .so version bump in Rawhide

2011-06-10 Thread BJ Dierkes
Hello all,

I've pushed the latest protobuf-2.4.1 to Rawhide, which bumps libprotobuf.so.6 
to libprotobuf.so.7.  This appears to affect the following base packages:

* libcompizconfig
* mozc
* mumble
* protobuf-c


The primary maintainers of the above have been BCC'd.

Thanks.

---
derks

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


orphaning xine-lib, EOL'ing phonon-backend-xine

2011-06-10 Thread Rex Dieter
The labor of love that was maintaining xine-lib has passed, as it will no 
longer be a dependency in f16's kde stack in any form.  As such, I'm 
orphaning it.  Kevin Kofler has offered to take ownership, though I'd 
venture he'd welcome any comaintainer assistance offered.

In a similar vein, phonon-backend-xine has officially been deprecated and is 
no longer supported.  We'll be EOL'ing this one soon.

-- Rex

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: F15 / VirtualBox

2011-06-10 Thread Neal Becker
Neal Becker wrote:

 Dave Jones wrote:
 
 On Thu, Jun 09, 2011 at 02:00:57PM +0100, Matthew Garrett wrote:
   On Thu, Jun 09, 2011 at 08:01:06PM +1000, Chris Jones wrote:
   
I agree. As virtualization technology becomes more and more involved
and frequent on users systems, particularly with advanced Linux users,
I think there needs to be a strong focus on ensuring that all releases
run in virtualized environments without any major issues. ie.
Virtualbox.

Perhaps a dedicated team among the developers who specialize in this
area.
   
   I don't think there are any developers working on this area, where this
   area is Virtualbox. We don't ship Virtualbox. We don't ship a kernel
   that has any knowledge of Virtualbox. There's a good argument for having
   this be part of the QA process and requiring that we boot in the common
   virtualisation environments as part of the release criteria, but I don't
   think we can realistically suggest that our virtualisation developers
   (who work on code that has nothing to do with Virtualbox) be responsible
   for that.
 
 I'm curious why virtualbox has gained so much inertia so quickly.
 Based solely on the number of kernel bug reports we get that seem to be
 related to it, I have almost zero confidence in it being reliable.
 
 Why are people choosing it over other solutions, and what can we change
 in qemu/kvm to get users using that instead ?
 
 Dave
  
 
 1. Easy setup of networking (bridged).
Just to followup, to setup bridged net on kvm I need to reboot my server.  
That's a non-starter.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Are 3.0 kernels working for anyone?

2011-06-10 Thread Bruno Wolff III
The 3.0 kernels are not working for me. (A cpu lockup is reporting during
boot.) I am wondering if things are broken for everyone where I should
probably just wait for updates and try again, or if I should get a picture
of the traceback and file a bug?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Are 3.0 kernels working for anyone?

2011-06-10 Thread Tom London
On Fri, Jun 10, 2011 at 11:19 AM, Bruno Wolff III br...@wolff.to wrote:
 The 3.0 kernels are not working for me. (A cpu lockup is reporting during
 boot.) I am wondering if things are broken for everyone where I should
 probably just wait for updates and try again, or if I should get a picture
 of the traceback and file a bug?
 --

Boots for me on Thinkpad X200 with SELinux enforcing.

gdm-greeter screen is scrambled, but if I blindly enter
login/password, gnome comes up just fine.

tom
-- 
Tom London
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Are 3.0 kernels working for anyone?

2011-06-10 Thread Jerry James
On Fri, Jun 10, 2011 at 12:19 PM, Bruno Wolff III br...@wolff.to wrote:
 The 3.0 kernels are not working for me. (A cpu lockup is reporting during
 boot.) I am wondering if things are broken for everyone where I should
 probably just wait for updates and try again, or if I should get a picture
 of the traceback and file a bug?

I've been using today's x86_64 Rawhide kernel with no problems.  I had
to attempt a boot 6 times before I finally got the i686 version off
the ground, though.  Twice udev segfaulted during boot, and I got some
kind of lockup (perhaps what you are seeing) on the other 3 attempts.
But the 6th time, it worked great.

Unlike Tom's experience, the gdm login screen looked fine for me on
both x86_64 and i686.
-- 
Jerry James
http://www.jamezone.org/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: systemd: please stop trying to take over the world :)

2011-06-10 Thread mike cloaked
On Fri, Jun 10, 2011 at 5:58 PM, Denys Vlasenko dvlas...@redhat.com wrote:
 On Fri, 2011-06-10 at 16:11 +0200, Michal Schmidt wrote:
 On 06/10/2011 03:59 PM, Steve Clark wrote:
  On 06/10/2011 09:36 AM, Michal Schmidt wrote:
  systemd does not take the system down when it crashes. It catches the
  signal, dumps core and freezes, but does not exit.
                          ^^^
  So you just end up with a froze system instead of a crashed system

 No, only systemd freezes itself. Other processes continue running.

 systemd-26/src/main.c::crash() is the function which does it.
 Assuming it will not recurse by crashing again, of course. It calls
 log_error and assert_se, which go into log_dispatch(), which logs to
 syslog, may try to write to klog, and whatnot... this doesn't look
 too robust to me.

 But anyway. Assuming it successfully froze. Does it help?
 Yes. How much? Well, it's better than instant oops which happens
 when PID 1 exits, but reaping of processes reparented
 to init will stop, which, for example, makes the hang from pid
 exhaustion just a question of time.

 Ultimately, this stems from the decision to make systemd
 to run as PID 1 process. Are there technical reasons for this?


Would be nice to see the systemd author join this discussion?
-- 
mike c
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Are 3.0 kernels working for anyone?

2011-06-10 Thread Tom London
On Fri, Jun 10, 2011 at 11:54 AM, Jerry James loganje...@gmail.com wrote:
 On Fri, Jun 10, 2011 at 12:19 PM, Bruno Wolff III br...@wolff.to wrote:
 The 3.0 kernels are not working for me. (A cpu lockup is reporting during
 boot.) I am wondering if things are broken for everyone where I should
 probably just wait for updates and try again, or if I should get a picture
 of the traceback and file a bug?

 I've been using today's x86_64 Rawhide kernel with no problems.  I had
 to attempt a boot 6 times before I finally got the i686 version off
 the ground, though.  Twice udev segfaulted during boot, and I got some
 kind of lockup (perhaps what you are seeing) on the other 3 attempts.
 But the 6th time, it worked great.

 Unlike Tom's experience, the gdm login screen looked fine for me on
 both x86_64 and i686.
 --
 Jerry James
 http://www.jamezone.org/

Didn't mention: exclusively using x86_64 version.

tom
-- 
Tom London
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Are 3.0 kernels working for anyone?

2011-06-10 Thread Clyde E. Kunkel
On 06/10/2011 02:19 PM, Bruno Wolff III wrote:
 The 3.0 kernels are not working for me. (A cpu lockup is reporting during
 boot.) I am wondering if things are broken for everyone where I should
 probably just wait for updates and try again, or if I should get a picture
 of the traceback and file a bug?

Couldn't tell you about lockups since if root is on anything with raid 
underlying, dracut drops to a shell.  You are on the bz:

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

Hopefully, someone with apply the patch provided in the bz.  I would if 
I knew how and had access.


-- 
Regards,
OldFart

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: F15 / VirtualBox

2011-06-10 Thread Richard W.M. Jones
On Fri, Jun 10, 2011 at 10:12:50AM -0500, Michael Cronenworth wrote:
 Richard W.M. Jones wrote:
  They are available, but I think you have to build them yourself from
  source.  All the information is here:
 
 This is not an argument for libvirt/kvm/qemu/spice but against.
 
 Here's some constructive advice:
 
 1. Give the Red Hat virtualization tools one, unique name and package it 
 under that name. Having a new name for every new feature isn't helping 
 your cause. Call it RHVM even. Anything is better than the current 
 situation and I'm sure a marketing wizard would love to tackle this.
 2. Make guest additions dead simple to install. Having to compile them 
 with a Windows DDK is not dead simple.
 3. Transparent network access. Having to setup bridges or manually edit 
 config files is a big turn off to some folks. I know virt-manager has a 
 GUI for some operations, but I still see editing config files a 
 recommended method in recent mailing list postings.
 4. Support USB 2.0+ in a easy-to-use way. Under VB, I can just click on 
 a device I want to use, while the VM is running, and use it. When I'm 
 done, I uncheck the device, again, while the VM is running, and it 
 disconnects from the VM and returns for use to my Fedora box.
 5. Exporting VMs must be a two-click process. Not a 9 command, terminal 
 operation. Importing VMs must be just as easy.

As they say, you get what you pay for.

Customers ask us to make the changes they want -- for server use and
scalability -- and KVM is absolutely the best in that area as a
result.  See many recent benchmarks.

Usability on single desktops is, well ... we do our best.

If you want excellent desktop usability, then organize a group and
make the work and patches happen.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: F15 / VirtualBox

2011-06-10 Thread Richard W.M. Jones
On Fri, Jun 10, 2011 at 02:13:39PM -0400, Neal Becker wrote:
 Just to followup, to setup bridged net on kvm I need to reboot my server.  
 That's a non-starter.

I would be very surprised if rebooting was really needed.  (But
conversely *not* very surprised if the instructions said you need to
reboot because explaining how to do it without that is harder ...)

In fact the instructions I'm reading say you need to restart the
network service (not strictly necessary either).

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: systemd: please stop trying to take over the world :)

2011-06-10 Thread Rahul Sundaram
On 06/11/2011 12:36 AM, mike cloaked wrote:
 Would be nice to see the systemd author join this discussion?

I am sure you can get answers when someone is off vacation.  However
what would be really nice is to redirect systemd discussions to its
upstream mailing list.  Fedora devel is hardly the best place for it. 

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Are 3.0 kernels working for anyone?

2011-06-10 Thread Richard W.M. Jones
On Fri, Jun 10, 2011 at 01:19:25PM -0500, Bruno Wolff III wrote:
 The 3.0 kernels are not working for me. (A cpu lockup is reporting during
 boot.) I am wondering if things are broken for everyone where I should
 probably just wait for updates and try again, or if I should get a picture
 of the traceback and file a bug?

Works very well for me, but:

- Make sure you're running kernel-3.0-0.rc2.git0.2.fc16 with the
ftrace bug fixed (thanks Kyle).

- Make sure you upgrade module-init-tools *before* installing the 3.0
kernel.

- Make sure you've got the latest udev.

- I'm only running them under KVM, not on baremetal.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: [FHS] helper scripts location

2011-06-10 Thread Haïkel Guémar
Le 10/06/2011 18:56, Toshio Kuratomi a écrit :

 I don't actually see this.  Could you point me to the quote and section?



/usr/libincludes object files, libraries, and internal binaries that
are not intended to be executed directly by users or shell scripts.
http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA


 Additionally, the GNU Coding standards explicitly prohibit this (to be clear
 the GNU coding standards are not definitive for Fedora like the FHS is at
 this time; I'm including the quotation to show what current best practices
 are in this regard):
 
 ‘libdir’
 The directory for object files and libraries of object code. Do not install
 executables here, they probably ought to go in ‘$(libexecdir)’ instead.
 

 At similar weight is the fact that some programs currently violate the GNU
 Coding Standard recommendation here.  However, I can't think of one of those
 off the top of my head that is a unix-y program so those may be more
 workaround than paradigm setters.

good to know

 Preference-wise, I would say $LIBEXECDIR; settable at build time to
 /usr/libexec on Fedora-style distros and /usr/lib on Debian-style distros is
 the best method here.  Since we're talking scripts (architecture
 independent), /usr/share may also make sense but I'm not a big fan of it.
 If you can find me the piece of FHS that explicitly allows shell scripts in
 /usr/lib I can figure out how that compares to using /usr/lib.


 -Toshio
+1

I spent some time yesterday talking with opensuse guys on irc, since
/usr/libexec has not been blessed by FHS, they won't move helpers from
/usr/lib which is FHS-compliant location.
I think that packaging guidelines should clarify this point, either we
enforce the use of /usr/libexec (and current packages should be fixed)
or we explicitely allow /usr/lib and/or /usr/share for helpers.

Personnally, i don't feel like burdening the reviewee with a non-FHS
compliant patch that has little chance to be upstreamed if it's not
mandatory.

H.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: F15 / VirtualBox

2011-06-10 Thread Michael Cronenworth
Richard W.M. Jones wrote:
 If you want excellent desktop usability, then organize a group and
 make the work and patches happen.

I knew this would be the response, but I do not hold it against you.

If anyone wants to hire me and pay me to do this full-time job's worth 
of work I'd be glad to. ;)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: [FHS] helper scripts location

2011-06-10 Thread Nicolas Mailhot

Le vendredi 10 juin 2011 à 21:23 +0200, Haïkel Guémar a écrit :

 I spent some time yesterday talking with opensuse guys on irc, since
 /usr/libexec has not been blessed by FHS, they won't move helpers from
 /usr/lib which is FHS-compliant location.
 I think that packaging guidelines should clarify this point, either we
 enforce the use of /usr/libexec (and current packages should be fixed)
 or we explicitely allow /usr/lib and/or /usr/share for helpers.

Or better, since the FHS  process has been re-started, people that feel
strongly about something not covered by the current FHS version should
just make the effort to push the changes they want in the next FHS
revision.

This way everyone else can just continue to require strict FHS
compliance and not bother with special not-really-documented exceptions


-- 
Nicolas Mailhot


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd memory usage

2011-06-10 Thread Adam Jackson
On 6/10/11 9:07 AM, Denys Vlasenko wrote:

 At the very least, I would like to see its memory consumption
 to go down substantially.

Let's try to turn this into something constructive.  I'll start with 
David Malcolm's rather nifty, if unpolished, 'heap' plugin for gdb:

https://fedorahosted.org/gdb-heap/wiki

Simply running the 'heap' command tells me that systemd is using 21M of 
malloc'd data, and that about 11M of it is entirely within allocations 
that are all 2064 bytes apiece.  Everything else, in comparison, is 
pretty insignificant:

Domain KindDetailCount  Allocated size
-  ---    ---  --
uncategorized 2064 bytes5,370  11,083,680
uncategorized   32 bytes   70,788   2,265,216
uncategorized 1072 bytes1,503   1,611,216
uncategorized   96 bytes   11,420   1,096,320
 C  string data 12,964 630,672
uncategorized  528 bytes1,067 563,376
uncategorized   528384 bytes1 528,384
uncategorized  272 bytes1,894 515,168
uncategorized   64 bytes6,342 405,888
uncategorized   48 bytes8,446 405,408
/* a bunch of stuff in between omitted */
uncategorized 2272 bytes1   2,272
uncategorized 1568 bytes1   1,568
uncategorized  800 bytes1 800
TOTAL  127,119  21,934,576

That's a pretty unusual size, 2064 bytes.  That works out to 2048 + 16, 
though, which are much more natural-sounding numbers.  A quick 
experiment with a demo program (allocate a 32-byte struct and then call 
pause()) shows that the 16 is actually the overhead from malloc itself:

Domain  KindDetail  Count  Allocated size
-      -  --
uncategorized48 bytes  1  48
 TOTAL  1  48

So now the problem is simply to find a 2048-sized allocation within 
systemd, or one of its libraries.  Anyone interested in a homework problem?

- ajax
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Are 3.0 kernels working for anyone?

2011-06-10 Thread Bruno Wolff III
On Fri, Jun 10, 2011 at 15:09:02 -0400,
  Clyde E. Kunkel clydekunkel7...@cox.net wrote:
 
 Couldn't tell you about lockups since if root is on anything with raid 
 underlying, dracut drops to a shell.  You are on the bz:
 
 https://bugzilla.redhat.com/show_bug.cgi?id=710646
 
 Hopefully, someone with apply the patch provided in the bz.  I would if 
 I knew how and had access.

I did a local build with the patch, so I get past that point. The person
who made the patch requested commit access to mdadm, but it hasn't been
approved yet. The lvm2 fix is already in rawhide. mdadm really should
have a co-maintainer, this isn't the first time an important update
has been delayed because the owner wasn't available.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Are 3.0 kernels working for anyone?

2011-06-10 Thread Bruno Wolff III
On Fri, Jun 10, 2011 at 20:17:46 +0100,
  Richard W.M. Jones rjo...@redhat.com wrote:
 
 Works very well for me, but:
 
 - Make sure you're running kernel-3.0-0.rc2.git0.2.fc16 with the
 ftrace bug fixed (thanks Kyle).

Done.

 - Make sure you upgrade module-init-tools *before* installing the 3.0
 kernel.

Done.

 - Make sure you've got the latest udev.

Done.

Looks like I need to spend some time capturing the error and filling out
a bug report.

Thank you everyone, for the feedback.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: systemd: please stop trying to take over the world :)

2011-06-10 Thread mike cloaked
On Fri, Jun 10, 2011 at 8:13 PM, Rahul Sundaram methe...@gmail.com wrote:
 On 06/11/2011 12:36 AM, mike cloaked wrote:
 Would be nice to see the systemd author join this discussion?

 I am sure you can get answers when someone is off vacation.  However
 what would be really nice is to redirect systemd discussions to its
 upstream mailing list.  Fedora devel is hardly the best place for it.

 Rahul

OK I guess we'll get more discussion when he comes back from his
holiday - sorry I was unaware of the vacation but thanks for
clarifying.

I guess that your reference to moving to upstream indicates that
systemd is now sufficiently established that discussion of problems is
an upstream issue for bug triage/fixing? I would imagine that the user
list may have useful exchanges too but that it would be important to
get any issues moved upstream from there too? The most important
outcome is that bugs are fixed so whatever route is best for that
(including bugzilla of course) users should add input to. Hence links
to upstream for systemd are made available so that the best exposure
to recourse to resolution is optimised?

-- 
mike c
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Are 3.0 kernels working for anyone?

2011-06-10 Thread Louis Lagendijk
On Fri, 2011-06-10 at 15:06 -0500, Bruno Wolff III wrote:
 On Fri, Jun 10, 2011 at 20:17:46 +0100,
   Richard W.M. Jones rjo...@redhat.com wrote:
  
  Works very well for me, but:
  
  - Make sure you're running kernel-3.0-0.rc2.git0.2.fc16 with the
  ftrace bug fixed (thanks Kyle).
 
 Done.
 
  - Make sure you upgrade module-init-tools *before* installing the 3.0
  kernel.
 
 Done.
 
  - Make sure you've got the latest udev.
 
 Done.
 
 Looks like I need to spend some time capturing the error and filling out
 a bug report.
 
 Thank you everyone, for the feedback.
I had problems too. I guess that is was something in the initramfs. I
ended up removing the 3.0 kernels and then re-install it (yum update).
That solved it for me

Louis

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: systemd: please stop trying to take over the world :)

2011-06-10 Thread mike cloaked
On Fri, Jun 10, 2011 at 9:44 PM, mike cloaked mike.cloa...@gmail.com wrote:

 I guess that your reference to moving to upstream indicates that
 systemd is now sufficiently established that discussion of problems is
 an upstream issue for bug triage/fixing? I would imagine that the user
 list may have useful exchanges too but that it would be important to
 get any issues moved upstream from there too? The most important
 outcome is that bugs are fixed so whatever route is best for that
 (including bugzilla of course) users should add input to. Hence links
 to upstream for systemd are made available so that the best exposure
 to recourse to resolution is optimised?


I also presume that by upstream you are referring to
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

-- 
mike c
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: [FHS] helper scripts location

2011-06-10 Thread Toshio Kuratomi
On Fri, Jun 10, 2011 at 09:23:54PM +0200, Haïkel Guémar wrote:
 Le 10/06/2011 18:56, Toshio Kuratomi a écrit :
 
  I don't actually see this.  Could you point me to the quote and section?
 
 
 
 /usr/libincludes object files, libraries, and internal binaries that
 are not intended to be executed directly by users or shell scripts.
 http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA
 
Ah -- in your original mesage you said that FHS explicitly blessed /usr/lib
as a place for shell scripts... which is not what this is saying.  However,
the description of internal binaries might fit the bill -- the FHS (and
Fedora's usage) of binaries is not always consistent.  Sometimes it is
equivalent to object files and other times it is equivalent to
executables.  If we interpret this as executable then I think it works.

Note that this portion of the FHS is in direct conflict with the GNU Coding
standards which explicitly says not to use libdir in this way :-(

 
  Additionally, the GNU Coding standards explicitly prohibit this (to be clear
  the GNU coding standards are not definitive for Fedora like the FHS is at
  this time; I'm including the quotation to show what current best practices
  are in this regard):
  
  ‘libdir’
  The directory for object files and libraries of object code. Do not install
  executables here, they probably ought to go in ‘$(libexecdir)’ instead.
  
 
  At similar weight is the fact that some programs currently violate the GNU
  Coding Standard recommendation here.  However, I can't think of one of those
  off the top of my head that is a unix-y program so those may be more
  workaround than paradigm setters.
 
 good to know
 
  Preference-wise, I would say $LIBEXECDIR; settable at build time to
  /usr/libexec on Fedora-style distros and /usr/lib on Debian-style distros is
  the best method here.  Since we're talking scripts (architecture
  independent), /usr/share may also make sense but I'm not a big fan of it.
  If you can find me the piece of FHS that explicitly allows shell scripts in
  /usr/lib I can figure out how that compares to using /usr/lib.
 
 
  -Toshio
 +1
 
 I spent some time yesterday talking with opensuse guys on irc, since
 /usr/libexec has not been blessed by FHS, they won't move helpers from
 /usr/lib which is FHS-compliant location.

Is this stuff a GNU configure compiled program?  Or does it have
a different build system?  (You could point me at the tarball/review request
and I could take a look).

 I think that packaging guidelines should clarify this point, either we
 enforce the use of /usr/libexec (and current packages should be fixed)
 or we explicitely allow /usr/lib and/or /usr/share for helpers.
 
 Personnally, i don't feel like burdening the reviewee with a non-FHS
 compliant patch that has little chance to be upstreamed if it's not
 mandatory.

I just reread the thread where we discussed the pros and cons of libexecdir
and here's the take aways for when and why to use libexecdir:

http://thread.gmane.org/gmane.linux.redhat.fedora.devel/25433/

1) Determine if the program cares about the wordsize of the helpers.
  * Are the helper programs mandatorily architecture independent or could
they be arch dependent (ex: It's only convenient to write them in shell,
the helpers could be written in C and compiled instead).
  * If it's only convenience, how likely is it that helpers would be written
in a compiled language?  Would upstream consider it a bug if someone
wrote a helper in a compiled language?
2.a) If the program does not care about the wordsize, then options are
 libexecdir or datadir.
  * Of the two, libexecdir is mandatory if architecture-specific helpers are
allowed.
  * libexecdir is likely better even if architecture-specific helpers are
not allowed as datadir is for data files and executable code is
something of a stretch to classify that way.
  * Finally, see the last bullet of 2.b) for what the ramifications of using
%{_libdir} are and whether that's acceptable in this specific case.
2.b) If the program does care about wordsize, then you need to use %_libdir
 which will either be /usr/lib or /usr/lib64 on Fedora.  The application
 (or config file) will need to be compiled/configured to know which path
 to use based on compilation (note that this may require a patch to
 upstream as well).
  * If the program does not care about wordsize but you put it into
%{_libdir} anyway, you force helpers in separate packages/subpackages to
be packaged arch-specific even though the only difference is the path
pointed to by  %{_libdir}.  This is a pain but it's something that can
be survived as long as people realize that they have to do this.  It
doesn't have as significant an impact if all of the helpers are in the
original package; helpers don't get added to by separate packages.

-Toshio


pgpejX83B5g0z.pgp
Description: PGP signature
-- 
devel mailing list

Re: rawhide missed an implicit dependency for #!python

2011-06-10 Thread Kevin Fenzi
On Fri, 10 Jun 2011 13:59:18 +0300
Panu Matilainen pmati...@laiskiainen.org wrote:

 On 06/10/2011 02:28 AM, Josh Stone wrote:
  On 06/02/2011 01:26 PM, Josh Stone wrote:
  Our dtrace script in systemtap-sdt-devel starts
  #!/usr/bin/python. Usually this leads to an implicit
  Requires: /usr/bin/python, but for some reason our rawhide build
  did not get this.  The F15, F14, and F13 builds from the same spec
  required python as expected.
  [...]
  Is this a bug?  Or must we now explicitly require python?
 
  An output change in file-5.07 appears to have broken find-requires:
  https://bugzilla.redhat.com/show_bug.cgi?id=712251
 
  And since file-5.07-2.fc15 is now in updates, I would expect this to
  cause even more problems going forward.
 
 Fixed now in rawhide rpm and an update for F15 is here:
 https://admin.fedoraproject.org/updates/rpm-4.9.0-9.fc15
 
 Please help testing to get this nasty regression fixed ASAP.
 
 ALL packages containing scripts which have been built while file-5.07 
 has been in rawhide (since May 11th)  F15 (in updates-testing since
 May 23rd) are affected and will have missing dependencies because of
 this, requiring rebuilds to correct the situation.
 
 Thanks Josh for reporting this, and also apologies for missing your 
 initial mail on the subject, reacting then would've saved a week's
 worth of broken builds :-/

Is there a way we can generate a list of builds affected? 
Is it everything? Or things that only have a specific type of requires?

kevin



signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd memory usage

2011-06-10 Thread Michal Schmidt
On Fri, 10 Jun 2011 15:55:14 -0400 Adam Jackson wrote:
 Domain KindDetailCount  Allocated size
 -  ---    ---  --
 uncategorized 2064 bytes5,370  11,083,680

Probably the SELinux file labelling database, all the regexes.
Related to https://bugzilla.redhat.com/show_bug.cgi?id=709014#c2

Michal
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: systemd: please stop trying to take over the world :)

2011-06-10 Thread Clyde E. Kunkel
On 06/10/2011 04:44 PM, mike cloaked wrote:
 On Fri, Jun 10, 2011 at 8:13 PM, Rahul Sundarammethe...@gmail.com  wrote:
 On 06/11/2011 12:36 AM, mike cloaked wrote:
 Would be nice to see the systemd author join this discussion?

 I am sure you can get answers when someone is off vacation.  However
 what would be really nice is to redirect systemd discussions to its
 upstream mailing list.  Fedora devel is hardly the best place for it.

 Rahul

 OK I guess we'll get more discussion when he comes back from his
 holiday - sorry I was unaware of the vacation but thanks for
 clarifying.

 I guess that your reference to moving to upstream indicates that
 systemd is now sufficiently established that discussion of problems is
 an upstream issue for bug triage/fixing? I would imagine that the user
 list may have useful exchanges too but that it would be important to
 get any issues moved upstream from there too? The most important
 outcome is that bugs are fixed so whatever route is best for that
 (including bugzilla of course) users should add input to. Hence links
 to upstream for systemd are made available so that the best exposure
 to recourse to resolution is optimised?


I hope discussions continue on Fedora lists as well.  systemd impacts 
lots of fedora users who just read Fedora lists.  I've subscribed to 
gnome, network manager, btrfs, virt, lvm, selinux, anaconda, kickstart, 
desktop, and etc.  Sure, folks subscribe to more lists than that, but 
when you can't spend much timre reading the lists, having discussions 
concentrated in your distro of choice's lists frees up precious time to 
actively participate in testing.  As a Fedora user and tester it is far 
easier to just peruse the Fedora lists.  Once systemd settles in and is 
no longer viewed with suspicion, then maybe add upstream for the rare issue.

Please don't be a wet blanket, folks, let the discussions continue here.

-- 
Regards,
OldFart

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: systemd memory usage

2011-06-10 Thread David Malcolm
On Fri, 2011-06-10 at 15:55 -0400, Adam Jackson wrote:
 On 6/10/11 9:07 AM, Denys Vlasenko wrote:
 
  At the very least, I would like to see its memory consumption
  to go down substantially.
 
 Let's try to turn this into something constructive.  I'll start with 
 David Malcolm's rather nifty, if unpolished, 'heap' plugin for gdb:
 
 https://fedorahosted.org/gdb-heap/wiki

Woot!   Fame at last!   :)

Various comments inline below...


 Simply running the 'heap' command tells me that systemd is using 21M of 
 malloc'd data, and that about 11M of it is entirely within allocations 
 that are all 2064 bytes apiece.  Everything else, in comparison, is 
 pretty insignificant:
 
 Domain KindDetailCount  Allocated size
 -  ---    ---  --
 uncategorized 2064 bytes5,370  11,083,680

[...snip...]

uncategorized means that gdb-heap doesn't know how to deal with bytes
in question.  If it's from a library, and you figure out what the above
is, we could add a categorizer for it.

  C  string data 12,964 630,672

...

 TOTAL  127,119  21,934,576


 That's a pretty unusual size, 2064 bytes.  That works out to 2048 + 16, 
 though, which are much more natural-sounding numbers.  A quick 
 experiment with a demo program (allocate a 32-byte struct and then call 
 pause()) shows that the 16 is actually the overhead from malloc itself:
 
 Domain  KindDetail  Count  Allocated size
 -      -  --
 uncategorized48 bytes  1  48
  TOTAL  1  48

Yes: IIRC, the size is actually the offset to the next chunk.  glibc's
malloc allocates two size_t fields at the top of each chunk.

 So now the problem is simply to find a 2048-sized allocation within 
 systemd, or one of its libraries.  Anyone interested in a homework problem?

gdb-heap has a search/querying feature:

If you run :
   (gdb) heap select size == 2048
it will try to show addresses and partial hexdumps of the relevant
buffers.  (I _think_ so, but you might need 2064 instead).

The addresses it reports are those of where the allocation begins (as
seen by the program) i.e. it does the offset for you.

Given an address, there's also a
   (gdb) hexdump ADDR
command, which you can use to scroll through memory.

If you stare at the hexdump you can sometimes figure out what the data
is.

If you think that an allocation is of some given type, you can also try
casting the data, e.g.:

   (gdb) print *(some_struct*)ADDR

and see if looks meaningful.

Hope this is helpful.
Dave

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: F15 / VirtualBox

2011-06-10 Thread Chris Jones

Quoting Thomas Sailer sai...@sailer.dynip.lugs.ch:

 Also, I have a strange card reader which I would love to use under some
 form of virtualisation, as the accompanying application only runs under
 very old versions of windows.

 The card reader has the misfeature that it requires firmware to be
 loaded by the PC. To get the firmware, it connects, waits about 4
 seconds, and if it doesn't get anything it disconnects and reconnects
 again. Now qemu/kvm is currently much too slow for this, until the host
 notices the USB device and hands it over to the guest, about 5-10sec
 pass.

 Tom

I'd suggest you purchase a new card reader. You do realize you can  
pick them up for around $10?
If I had a card reader with that much drama just to get it to operate,  
it'd be out the door in no time!


Cheers

Chris Jones


This message was sent using IMP, the Internet Messaging Program.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: F15 / VirtualBox

2011-06-10 Thread Chris Jones
Quoting Przemek Klosowski przemek.klosow...@nist.gov:

 Make it one command:

 yum install
 http://download.virtualbox.org/virtualbox/4.0.8/VirtualBox-4.0-4.0.8_71778_fedora15-1.x86_64.rpm

 (or VirtualBox-4.0-4.0.8_71778_fedora15-1.i686.rpm for 32-bit systems)


OMG, I am such a dick for not even thinking of that!
The problem is, I use Ubuntu/APT also, so sometimes I can confuse  
myself as to which system (yum/apt) does what.

Nice work.


Cheers

Chris Jones


This message was sent using IMP, the Internet Messaging Program.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: F15 / VirtualBox

2011-06-10 Thread Garrett Holmstrom
On Fri, Jun 10, 2011 at 12:11 PM, Richard W.M. Jones rjo...@redhat.com wrote:
 Customers ask us to make the changes they want -- for server use and
 scalability -- and KVM is absolutely the best in that area as a
 result.  See many recent benchmarks.

 Usability on single desktops is, well ... we do our best.

 If you want excellent desktop usability, then organize a group and
 make the work and patches happen.

Why would many prospective contributors choose to work on KVM's
desktop usability when VirtualBox's is already superior?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[no subject]

2011-06-10 Thread Sergio Belkin
Hi,

I've noted a difference between f15 and f14 on the first one
mentioned, running the following it fails:

./configure LDFLAGS=-no-install
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking how to print strings... printf
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/tmp/UpTools-8.5.4':
configure: error: C compiler cannot create executables
See `config.log' for more details


On config.log

you can see:

gcc version 4.6.0 20110530 (Red Hat 4.6.0-9) (GCC)
configure:3617: $? = 0
configure:3606: gcc -V 5
gcc: error: unrecognized option '-V'
gcc: fatal error: no input files
compilation terminated.
configure:3617: $? = 4
configure:3606: gcc -qversion 5
gcc: error: unrecognized option '-qversion'
gcc: fatal error: no input files
compilation terminated.
configure:3617: $? = 4
configure:3637: checking whether the C compiler works
configure:3659: gcc   -no-install conftest.c  5
gcc: error: unrecognized option '-no-install'
configure:3663: $? = 1
configure:3701: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME UpTools
| #define PACKAGE_TARNAME UpTools
| #define PACKAGE_VERSION 8.5.4
| #define PACKAGE_STRING UpTools 8.5.4
| #define PACKAGE_BUGREPORT bugs-upto...@palermo.edu
| #define PACKAGE_URL 
| #define PACKAGE UpTools
| #define VERSION 8.5.4
| /* end confdefs.h.  */
|
| int
| {
|
|   ;
|   return 0;
| }
configure:3705: error: in `/tmp/UpTools-8.5.4':
configure:3707: error: C compiler cannot create executables

The same script doesn't fail on F14.

Do you have any idea?

Thanks in advance!

--
--
Sergio Belkin  http://www.sergiobelkin.com
Watch More TV http://sebelk.blogspot.com
LPIC-2 Certified - http://www.lpi.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Different behaviour on gcc 4.6?

2011-06-10 Thread Sergio Belkin
Sorry, I was typing on a netbook :P and the mail it was sent without subject


-- 
--
Sergio Belkin  http://www.sergiobelkin.com
Watch More TV http://sebelk.blogspot.com
LPIC-2 Certified - http://www.lpi.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: systemd: please stop trying to take over the world :)

2011-06-10 Thread Genes MailLists
On 06/10/2011 03:13 PM, Rahul Sundaram wrote:


 what would be really nice is to redirect systemd discussions to its
 upstream mailing list.  Fedora devel is hardly the best place for it. 
 
 Rahul

  Beg to differ - rather vehemently too - politely but vehemently.

  systemd is only available in fedora[1] - we are the test pigs for
better or for worse - and there are most certainly bugs in fedora's systemd.

  Lets be blunt here - he pushed very very very hard on these very lists
to get systemd in - now its in F15 and there are problems - so no
punting please. Upstream and fedora are the same for systemd.

  Some bugs like sendmail failing to start have been there since
September 2010 ( almost 9 months ... ) - people are reporting the same
issue on F15 in the fedora lists  ... who is fixing this stuff ?

 e.g.

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


  Ok so he's on vacation - this is a very core part of the OS - who is
backing him up I wonder? Who else is on the project?

  Surely you're not saying there is no-one else working on systemd...
and when LP is away/busy nothing will get done ... otherwise I strongly
urge it be replaced by upstart asap.



 gene/


[1] Yes he spoke with another distro - but no-one is using it. So its a
fedora only project until its picked up somewhere else - which has not
happened yet.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: orphaning xine-lib, EOL'ing phonon-backend-xine

2011-06-10 Thread Kevin Kofler
Rex Dieter wrote:
 The labor of love that was maintaining xine-lib has passed, as it will no
 longer be a dependency in f16's kde stack in any form.  As such, I'm
 orphaning it.  Kevin Kofler has offered to take ownership, though I'd
 venture he'd welcome any comaintainer assistance offered.

FWIW, there's one third-party KDE-Platform-based application still using 
xine-lib for the foreseeable future: Kaffeine. That package was also 
orphaned, I picked it up too.

 In a similar vein, phonon-backend-xine has officially been deprecated and
 is no longer supported.  We'll be EOL'ing this one soon.

It's indeed time for that one to just go away, phonon-backend-gstreamer is 
now the better solution. I'm not going to attempt resurrecting phonon-
backend-xine unless upstream suddenly changes their mind about the 
recommended Phonon backend again and brings it back from the ashes (but 
xine-lib itself would need a sudden reinjection of life as well).

We've been doing the switch step by step:
* Fedora 9, 10 and 11 installed only phonon-backend-xine by default.
* Fedora 12, 13 and 14 installed both phonon-backend-xine and phonon-
backend-gstreamer by default and defaulted to phonon-backend-xine.
* Fedora 15 only installs phonon-backend-gstreamer by default. phonon-
backend-xine is still in the repository, but will not be used by default 
even when installed.
* Fedora 16 will only support phonon-backend-gstreamer.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: systemd: please stop trying to take over the world :)

2011-06-10 Thread Kevin Kofler
Denys Vlasenko wrote:
 Mem total:2035840 anon:431208 map:78924 free:419084
[snip]
 1 15384 11856 13664  1340 11752 0   132 /sbin/init

So this singleton process is taking 0.76% of your RAM. What the heck are you 
complaining about?

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Different behaviour on gcc 4.6?

2011-06-10 Thread Kevin Kofler
Sergio Belkin wrote:
 | int
 | {
 |
 |;
 |return 0;
 | }

This is not a valid C program. Maybe GCC 4.5 accepted this junk?! GCC 4.6 is 
right to error on it.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Are 3.0 kernels working for anyone?

2011-06-10 Thread John Dulaney

It was for me until this morning.  Virtual box killed it (beware of vb).
  -- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd: please stop trying to take over the world :)

2011-06-10 Thread Rahul Sundaram
On 06/11/2011 05:20 AM, Genes MailLists wrote:
   Lets be blunt here - he pushed very very very hard on these very lists
 to get systemd in - now its in F15 and there are problems - so no
 punting please. Upstream and fedora are the same for syste
 
That is a gross over simplification.  Fedora is just one of the many
distros integrating systemd and there are developers from other distros
including Novell involved in systemd and contributing to it.  If we
start discussing every project where Red Hat is heaving involved, that
list is long

 [1] Yes he spoke with another distro - but no-one is using it. So its a
 fedora only project until its picked up somewhere else - which has not
 happened yet.

That's not true.   Mandriva 2011 is already including it by default.  So
is MeeGo.   OpenSUSE has announced that it is using it by default in
their next release.  Not to mention other distros who have included it
in their repos.  It is far from a Fedora only project.   The proper
place for general discussions about systemd is

http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Only Fedora specific bugs should be discussed here. 

Rahul


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: F15 / VirtualBox

2011-06-10 Thread Rahul Sundaram
On 06/11/2011 05:35 AM, Garrett Holmstrom wrote:
 Why would many prospective contributors choose to work on KVM's
 desktop usability when VirtualBox's is already superior?

Because they like KVM and use it because of other advantages like
performance?  Because they disagree with handing copyright over to
Oracle or contributing code under permissive licenses?  They don't want
to use third party kernel modules?  There could be any number of reasons.

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Different behaviour on gcc 4.6?

2011-06-10 Thread Sergio Belkin
2011/6/10 Kevin Kofler kevin.kof...@chello.at:
 Sergio Belkin wrote:
 | int
 | {
 |
 |;
 |return 0;
 | }

 This is not a valid C program. Maybe GCC 4.5 accepted this junk?! GCC 4.6 is
 right to error on it.

        Kevin Kofler

 --

Thanks Kevin, but not so fast  ;)  !
 it was my fault, I've copied bad the snip, below is the right one,
and that is indeed a valid C program, please take a look  (I wonder if
LDFLAGS=-no-install is no more valid, perhaps someone may want to
test against some source) :


gcc version 4.6.0 20110530 (Red Hat 4.6.0-9) (GCC)
configure:3618: $? = 0
configure:3607: gcc -V 5
gcc: error: unrecognized option '-V'
gcc: fatal error: no input files
compilation terminated.
configure:3618: $? = 4
configure:3607: gcc -qversion 5
gcc: error: unrecognized option '-qversion'
gcc: fatal error: no input files
compilation terminated.
configure:3618: $? = 4
configure:3638: checking whether the C compiler works
configure:3660: gcc   -no-install conftest.c  5
gcc: error: unrecognized option '-no-install'
configure:3664: $? = 1
configure:3702: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME UpTools
| #define PACKAGE_TARNAME UpTools
| #define PACKAGE_VERSION 8.5.5
| #define PACKAGE_STRING UpTools 8.5.5
| #define PACKAGE_BUGREPORT bugs-upto...@palermo.edu
| #define PACKAGE_URL 
| #define PACKAGE UpTools
| #define VERSION 8.5.5
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:3707: error: in `/tmp/UpTools-8.5.5':
configure:3709: error: C compiler cannot create executables

End of snippet


-- 
--
Sergio Belkin  http://www.sergiobelkin.com
Watch More TV http://sebelk.blogspot.com
LPIC-2 Certified - http://www.lpi.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re:

2011-06-10 Thread Miloslav Trmač
Hello,
On Sat, Jun 11, 2011 at 2:06 AM, Sergio Belkin seb...@gmail.com wrote:
 ./configure LDFLAGS=-no-install
snip
 configure:3659: gcc   -no-install conftest.c  5
 gcc: error: unrecognized option '-no-install'

 Do you have any idea?

-no-install, which the command explicitly includes, is a libtool
option, but not a valid gcc option.  I don't know why it is necessary
to use -no-install, but if you do need it, you can probably patch
Makefile* to include it in such a way that the operation of
./configure is not disrupted.
Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re:

2011-06-10 Thread Sergio Belkin
2011/6/11 Miloslav Trmač m...@volny.cz:
 Hello,
 On Sat, Jun 11, 2011 at 2:06 AM, Sergio Belkin seb...@gmail.com wrote:
 ./configure LDFLAGS=-no-install
 snip
 configure:3659: gcc   -no-install conftest.c  5
 gcc: error: unrecognized option '-no-install'

 Do you have any idea?

 -no-install, which the command explicitly includes, is a libtool
 option, but not a valid gcc option.  I don't know why it is necessary
 to use -no-install, but if you do need it, you can probably patch
 Makefile* to include it in such a way that the operation of
 ./configure is not disrupted.
    Mirek
 --

I've found an example here:

It's useful if someone wants to avoid the wrappers generation (look at the end):

http://www.flameeyes.eu/autotools-mythbuster/libtool/wrappers.html

Perhaps ./configure LDFLAGS=-no-install is somewhat heterodox 

-- 
--
Sergio Belkin  http://www.sergiobelkin.com
Watch More TV http://sebelk.blogspot.com
LPIC-2 Certified - http://www.lpi.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

File Mojolicious-1.42.tar.gz uploaded to lookaside cache by yaneti

2011-06-10 Thread Yanko Kaneti
A file has been added to the lookaside cache for perl-Mojolicious:

5432fa78163e8726d7655292e2d8c4b2  Mojolicious-1.42.tar.gz
--
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-Mojolicious] Update from upstream 1.42

2011-06-10 Thread Yanko Kaneti
commit 035a578805022a3d1bb1c40d042682c519d3f944
Author: Yanko Kaneti yan...@declera.com
Date:   Fri Jun 10 09:27:00 2011 +0300

Update from upstream 1.42

 .gitignore|1 +
 perl-Mojolicious.spec |6 +-
 sources   |2 +-
 3 files changed, 7 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 5edffd5..13985fc 100644
--- a/.gitignore
+++ b/.gitignore
@@ -20,3 +20,4 @@ Mojolicious-0.26.tar.gz
 /Mojolicious-1.33.tar.gz
 /Mojolicious-1.34.tar.gz
 /Mojolicious-1.41.tar.gz
+/Mojolicious-1.42.tar.gz
diff --git a/perl-Mojolicious.spec b/perl-Mojolicious.spec
index 06807a5..da1207d 100644
--- a/perl-Mojolicious.spec
+++ b/perl-Mojolicious.spec
@@ -1,5 +1,5 @@
 Name:   perl-Mojolicious
-Version:1.41
+Version:1.42
 Release:1%{?dist}
 Summary:A next generation web framework for Perl
 License:Artistic 2.0
@@ -25,6 +25,7 @@ a new attempt at implementing this idea using state of the 
art technology.
 %prep
 %setup -q -n Mojolicious-%{version}
 mv README.pod lib/Mojolicious/
+chmod -x lib/Mojo/Exception.pm
 
 %build
 %{__perl} Makefile.PL INSTALLDIRS=vendor
@@ -51,6 +52,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Fri Jun 10 2011 Yanko Kaneti yan...@declera.com 1.42-1
+- Upstream update 1.42.
+
 * Fri Jun  3 2011 Yanko Kaneti yan...@declera.com 1.41-1
 - Latest from upstream - 1.41.
 
diff --git a/sources b/sources
index cb76a90..542268b 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-6c4c7b8197d2487ba59a292fda95566a  Mojolicious-1.41.tar.gz
+5432fa78163e8726d7655292e2d8c4b2  Mojolicious-1.42.tar.gz
--
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 696725] RPM doesn't create /var/run/amavisd

2011-06-10 Thread bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


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

--- Comment #8 from Paul Howarth p...@city-fan.org 2011-06-10 03:59:26 EDT ---
It's /etc/tmpfiles.d, not /etc/tmpfile.d; the conf files from there are
processed by systemd at boot time. The package should also include the required
directories itself so that they are created at package install time so that the
package can work immediately after installation without requiring a reboot.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- 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
https://admin.fedoraproject.org/mailman/listinfo/perl-devel


File Catalyst-Engine-PSGI-0.13.tar.gz uploaded to lookaside cache by mmaslano

2011-06-10 Thread Marcela Mašláňová
A file has been added to the lookaside cache for perl-Catalyst-Engine-PSGI:

4b48a53b1ecf5c236488de57c773e9f0  Catalyst-Engine-PSGI-0.13.tar.gz
--
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-Catalyst-Engine-PSGI] update to 0.13

2011-06-10 Thread Marcela Mašláňová
commit e44216ef301d49d672b39aa0c3128ea423fbdf8a
Author: Marcela Mašláňová mmasl...@redhat.com
Date:   Fri Jun 10 12:42:32 2011 +0200

update to 0.13

 .gitignore |1 +
 perl-Catalyst-Engine-PSGI.spec |6 --
 sources|2 +-
 3 files changed, 6 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 0b36637..e6523b3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
 /Catalyst-Engine-PSGI-0.12.tar.gz
+/Catalyst-Engine-PSGI-0.13.tar.gz
diff --git a/perl-Catalyst-Engine-PSGI.spec b/perl-Catalyst-Engine-PSGI.spec
index f1a6d2b..cd5bfd5 100644
--- a/perl-Catalyst-Engine-PSGI.spec
+++ b/perl-Catalyst-Engine-PSGI.spec
@@ -1,6 +1,6 @@
 Name:   perl-Catalyst-Engine-PSGI
 Summary:PSGI engine for Catalyst
-Version:0.12
+Version:0.13
 Release:1%{?dist}
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -80,12 +80,14 @@ find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null 
';'
 make test
 
 %files
-%defattr(-,root,root,-)
 %doc Changes README
 %{perl_vendorlib}/*
 %{_mandir}/man3/*.3*
 
 %changelog
+* Fri Jun 10 2011 Marcela Mašláňová mmasl...@redhat.com 0.13-1
+- update to 0.13
+
 * Tue Jan 11 2011 Marcela Mašláňová mmasl...@redhat.com 0.12-1
 - update to 0.12
 
diff --git a/sources b/sources
index 658e68b..b114c2d 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-6e4706232c64db53f4c572be7c33be88  Catalyst-Engine-PSGI-0.12.tar.gz
+4b48a53b1ecf5c236488de57c773e9f0  Catalyst-Engine-PSGI-0.13.tar.gz
--
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-NOCpulse-Utils] Perl 5.14 mass rebuild

2011-06-10 Thread Marcela Mašláňová
commit bcb4e29958ea0b9df73f1a95ec901c859900ee9c
Author: Marcela Mašláňová mmasl...@redhat.com
Date:   Fri Jun 10 13:33:35 2011 +0200

Perl 5.14 mass rebuild

 perl-NOCpulse-Utils.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-NOCpulse-Utils.spec b/perl-NOCpulse-Utils.spec
index 299ace6..ec6976a 100644
--- a/perl-NOCpulse-Utils.spec
+++ b/perl-NOCpulse-Utils.spec
@@ -1,6 +1,6 @@
 Name: perl-NOCpulse-Utils
 Version:  1.14.11
-Release:  7%{?dist}
+Release:  8%{?dist}
 Summary:  NOCpulse utility packages
 URL:  https://fedorahosted.org/spacewalk
 Source0:  
https://fedorahosted.org/releases/s/p/spacewalk/%{name}-%{version}.tar.gz
@@ -45,6 +45,9 @@ mkdir -p $RPM_BUILD_ROOT%{_mandir}/man3/
 rm -rf $RPM_BUILD_ROOT
 
 %changelog
+* Fri Jun 10 2011 Marcela Mašláňová mmasl...@redhat.com - 1.14.11-8
+- Perl 5.14 mass rebuild
+
 * Tue Feb 08 2011 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 1.14.11-7
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
 
--
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 712333] perl-Catalyst-Engine-PSGI-0.13 is available

2011-06-10 Thread bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


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

Marcela Mašláňová mmasl...@redhat.com changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
 Resolution||RAWHIDE
Last Closed||2011-06-10 07:36:11

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- 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
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-perlmenu] Perl 5.14 mass rebuild

2011-06-10 Thread Marcela Mašláňová
commit 1ee10445a080cf926b34ff0284ae3aa8643452ac
Author: Marcela Mašláňová mmasl...@redhat.com
Date:   Fri Jun 10 14:16:20 2011 +0200

Perl 5.14 mass rebuild

 perl-perlmenu.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-perlmenu.spec b/perl-perlmenu.spec
index 20e2cf6..225f243 100644
--- a/perl-perlmenu.spec
+++ b/perl-perlmenu.spec
@@ -1,6 +1,6 @@
 Name:   perl-perlmenu
 Version:4.0
-Release:13%{?dist}
+Release:14%{?dist}
 Summary:Perl library module for curses-based menus  data-entry 
templates
 
 Group:  Development/Libraries
@@ -43,6 +43,9 @@ rm -rf $RPM_BUILD_ROOT
 %{perl_vendorlib}/*
 
 %changelog
+* Fri Jun 10 2011 Marcela Mašláňová mmasl...@redhat.com - 4.0-14
+- Perl 5.14 mass rebuild
+
 * Wed Feb 09 2011 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 4.0-13
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
 
--
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 696725] RPM doesn't create /var/run/amavisd

2011-06-10 Thread bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


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

--- Comment #13 from Trever Adams night...@hotmail.com 2011-06-10 09:05:13 
EDT ---
Sorry, I thought I had the right permissions. Thank you for fixing it.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- 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
https://admin.fedoraproject.org/mailman/listinfo/perl-devel


[netcdf-perl] Perl 5.14 mass rebuild

2011-06-10 Thread Marcela Mašláňová
commit ea6c57a6baf64f272281d99ee07fc643c02dbe6e
Author: Marcela Mašláňová mmasl...@redhat.com
Date:   Fri Jun 10 16:06:22 2011 +0200

Perl 5.14 mass rebuild

 netcdf-perl.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/netcdf-perl.spec b/netcdf-perl.spec
index dd1e37f..0bd01cf 100644
--- a/netcdf-perl.spec
+++ b/netcdf-perl.spec
@@ -1,6 +1,6 @@
 Name:   netcdf-perl
 Version:1.2.4
-Release:7%{?dist}
+Release:8%{?dist}
 Summary:Perl extension module for scientific data access via the 
netCDF API
 
 Group:  Development/Libraries
@@ -71,6 +71,9 @@ rm -rf $RPM_BUILD_ROOT
 
 
 %changelog
+* Fri Jun 10 2011 Marcela Mašláňová mmasl...@redhat.com - 1.2.4-8
+- Perl 5.14 mass rebuild
+
 * Thu Mar 31 2011 Orion Poplawski or...@cora.nwra.com - 1.2.4-7
 - Rebuild for netcdf 4.1.2
 
--
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 709269] perl-SOAP-Lite provides bogus perl(LWP::Protocol)

2011-06-10 Thread bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


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

--- Comment #8 from Fedora Update System upda...@fedoraproject.org 2011-06-11 
00:27:10 EDT ---
perl-SOAP-Lite-0.712-5.fc14 has been pushed to the Fedora 14 stable repository.
 If problems still persist, please make note of it in this bug report.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- 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
https://admin.fedoraproject.org/mailman/listinfo/perl-devel


[Bug 707442] sqlsh's help needs IO::Scalar and Term::ReadLine::Gnu

2011-06-10 Thread bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


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

--- Comment #8 from Fedora Update System upda...@fedoraproject.org 2011-06-11 
00:31:10 EDT ---
perl-SQL-Shell-1.14-8.fc15 has been pushed to the Fedora 15 stable repository. 
If problems still persist, please make note of it in this bug report.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- 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
https://admin.fedoraproject.org/mailman/listinfo/perl-devel


[Bug 707442] sqlsh's help needs IO::Scalar and Term::ReadLine::Gnu

2011-06-10 Thread bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


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

Fedora Update System upda...@fedoraproject.org changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-SQL-Shell-1.14-6.fc14
 Resolution||ERRATA
Last Closed||2011-06-11 00:27:44

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- 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
https://admin.fedoraproject.org/mailman/listinfo/perl-devel


  1   2   >