Minimal install diff from F16 to F19 (TC6)

[Adam Williamson]

As it may be interesting and I have the data on hand, here's the package
diff between a minimal install of F16 and a minimal install of F19. F16
has 203 packages (I think it's really 202 but I somehow got an extra one
into my test), F19 TC6 has 238.

--- 16min.txt   2013-06-19 09:06:52.075305098 -0700
+++ 19tc6_min.txt   2013-06-20 00:09:20.725960756 -0700
@@ -1,48 +1,47 @@
 acl
-attr
 audit
 audit-libs
 authconfig
+avahi
+avahi-autoipd
+avahi-libs
 basesystem
 bash
 bind-libs-lite
 bind-license
 biosdevname
-bzip2
 bzip2-libs
 ca-certificates
-checkpolicy
 chkconfig
 coreutils
-coreutils-libs
 cpio
 cracklib
 cracklib-dicts
 cronie
 cronie-anacron
 crontabs
-cryptsetup-luks-libs
+cryptsetup-libs
 curl
 cyrus-sasl
 cyrus-sasl-lib
-dash
-db4
-db4-utils
 dbus
+dbus-glib
 dbus-libs
+dbus-python
 device-mapper
 device-mapper-event
 device-mapper-event-libs
 device-mapper-libs
+device-mapper-persistent-data
 dhclient
 dhcp-common
 dhcp-libs
 diffutils
-dmraid
-dmraid-events
+dnsmasq
 dracut
 e2fsprogs
 e2fsprogs-libs
+ebtables
 elfutils-libelf
 expat
 fedora-logos
@@ -53,8 +52,8 @@
 findutils
 fipscheck
 fipscheck-lib
+firewalld
 freetype
-gamin
 gawk
 gdbm
 gettext
@@ -64,26 +63,35 @@
 glibc-common
 gmp
 gnupg2
+gnutls
+gobject-introspection
 gpgme
-gpg-pubkey
 grep
+groff-base
 grub2
+grub2-tools
 grubby
 gzip
+hardlink
 hesiod
 hostname
 hwdata
 info
 initscripts
 iproute
+iprutils
 iptables
 iputils
+json-c
 kbd
 kbd-misc
 kernel
 keyutils-libs
+kmod
+kmod-libs
 kpartx
 krb5-libs
+less
 libacl
 libassuan
 libattr
@@ -93,28 +101,43 @@
 libcom_err
 libcroco
 libcurl
+libdaemon
 libdb
+libdb-utils
 libdrm
+libedit
+libee
+libestr
 libffi
 libgcc
 libgcrypt
 libgomp
 libgpg-error
+libgudev1
 libidn
+liblognorm
+libmicrohttpd
 libmount
+libnl3
+libpcap
 libpciaccess
+libpipeline
+libpwquality
 libselinux
+libselinux-python
 libselinux-utils
 libsemanage
 libsepol
 libss
 libssh2
 libstdc++
-libudev
+libsysfs
+libtasn1
 libunistring
 libuser
 libutempter
 libuuid
+libverto
 libxml2
 linux-atm-libs
 linux-firmware
@@ -122,29 +145,35 @@
 lua
 lvm2
 lvm2-libs
-m4
-mingetty
-module-init-tools
+make
+man-db
+mozjs17
 ncurses
 ncurses-base
 ncurses-libs
-net-tools
-netxen-firmware
+nettle
+NetworkManager
+NetworkManager-glib
 newt
 newt-python
 nspr
 nss
-nss-myhostname
 nss-softokn
 nss-softokn-freebl
 nss-sysinit
+nss-tools
 nss-util
 openldap
 openssh
+openssh-clients
 openssh-server
 openssl
+openssl-libs
 os-prober
+p11-kit
+p11-kit-trust
 pam
+parted
 passwd
 pciutils-libs
 pcre
@@ -154,17 +183,26 @@
 plymouth-core-libs
 plymouth-scripts
 policycoreutils
+polkit
+polkit-pkla-compat
 popt
+ppp
 procmail
-procps
-psmisc
+procps-ng
 pth
+pygobject3-base
 pygpgme
+pyliblzma
 python
+python-decorator
 python-iniparse
 python-libs
 python-pycurl
+python-slip
+python-slip-dbus
 python-urlgrabber
+pyxattr
+qrencode-libs
 readline
 rootfiles
 rpm
@@ -176,28 +214,26 @@
 selinux-policy
 selinux-policy-targeted
 sendmail
-setserial
 setup
-sgpio
 shadow-utils
 shared-mime-info
 slang
 sqlite
 sudo
-system-config-firewall-base
 systemd
+systemd-libs
 systemd-sysv
-systemd-units
 sysvinit-tools
-tar
 tcp_wrappers-libs
 tzdata
-udev
 ustr
 util-linux
 vim-minimal
 which
+wpa_supplicant
+xz
 xz-libs
 yum
 yum-metadata-parser
 zlib
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

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

Re: Fatal PCIe error 928 on KVM GPU Passthrough

[Mario Ceresa]

Thanks Lars, I'll do as you suggest!

Best,

Mario


On 19 June 2013 23:35, Lars Seipel  wrote:

> On Wed, Jun 19, 2013 at 04:42:30PM +0200, Mario Ceresa wrote:
> > does anybody know if it is currently possible to do GPU passthrough in
> kvm?
>
> You might want to ask that on the Fedora virt list[1] or on upstream
> libvirt's users list[2]. The chances for getting good answers should be
> much higher there.
>
> [1] https://admin.fedoraproject.org/mailman/listinfo/virt
> [2] http://libvirt.org/contact.html
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Fedora 19 - Feature PHP 5.5 done !

[Remi Collet]

https://fedoraproject.org/wiki/Features/Php55

I just create the update to PHP 5.5.0 final.

https://admin.fedoraproject.org/updates/php-5.5.0-1.fc19

Very very short before F19 release !


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

Re: Fedora 19 - Feature PHP 5.5 done !

[Michał Piotrowski]

Hi,

Thank you very much! It's a great feature :)


2013/6/20 Remi Collet 

> https://fedoraproject.org/wiki/Features/Php55
>
> I just create the update to PHP 5.5.0 final.
>
> https://admin.fedoraproject.org/updates/php-5.5.0-1.fc19
>
> Very very short before F19 release !
>
>
> Remi.
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel




-- 
Best regards,
Michal

http://eventhorizon.pl/
https://getactive.pl/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Self Introduction

[Marcin Dulak]

Hi,

Marcin Dulak: working with RedHat/Fedora systems for 6 years, and a 
Linux user for about 10.

Here is my fist package: https://bugzilla.redhat.com/show_bug.cgi?id=973084

I have packaged several software for internal use, mostly python and 
science oriented:

https://build.opensuse.org/project/show?project=home%3Adtufys

I'm interested in getting some of these packages into Fedora and EPEL 
(if needed),

and becoming co-maintainer of other packages, especially non-python ones,
so can learn a bit about other parts of Fedora.

Best regards,

Marcin







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

Re: Minimal install diff from F16 to F19 (TC6)

[Harald Hoyer]

On 06/20/2013 09:21 AM, Adam Williamson wrote:
> As it may be interesting and I have the data on hand, here's the package
> diff between a minimal install of F16 and a minimal install of F19. F16
> has 203 packages (I think it's really 202 but I somehow got an extra one
> into my test), F19 TC6 has 238.
> 

Hmm, some suspicious candidates.

json-c?

$ rpm -q --whatrequires json-c
no package requires json-c


make for package: 1:openssl-1.0.1e-4.fc19.x86_64


Hmm, why does NetworkManager have a hard requirement for these?
avahi-autoipd
ppp
dnsmasq

And why is NetworkManager and firewalld in the minimal install?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Remi Collet]

Le 20/06/2013 11:52, Harald Hoyer a écrit :
> $ rpm -q --whatrequires json-c
> no package requires json-c

Probably should try

$ rpm -q --whatrequires \
  "libjson.so.0()(64bit)" \
  "libjson-c.so.2()(64bit)"

=> pulseaudio, abrt, libreport, ...

Remi.

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

Re: Minimal install diff from F16 to F19 (TC6)

[Harald Hoyer]

On 06/20/2013 11:59 AM, Remi Collet wrote:
> Le 20/06/2013 11:52, Harald Hoyer a écrit :
>> $ rpm -q --whatrequires json-c
>> no package requires json-c
> 
> Probably should try
> 
> $ rpm -q --whatrequires \
>   "libjson.so.0()(64bit)" \
>   "libjson-c.so.2()(64bit)"
> 
> => pulseaudio, abrt, libreport, ...
> 
> Remi.
> 

Doh.. yes, sorry.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Harald Hoyer]

On 06/20/2013 11:59 AM, Remi Collet wrote:
> Le 20/06/2013 11:52, Harald Hoyer a écrit :
>> $ rpm -q --whatrequires json-c
>> no package requires json-c
> 
> Probably should try
> 
> $ rpm -q --whatrequires \
>   "libjson.so.0()(64bit)" \
>   "libjson-c.so.2()(64bit)"
> 
> => pulseaudio, abrt, libreport, ...
> 
> Remi.
> 

This cries for the compile option "-Wl,--as-needed"

$ ldd /usr/lib64/pulse-3.0/modules/module-bluetooth-policy.so
linux-vdso.so.1 =>  (0x7fff0c3f1000)
libpulsecore-3.0.so => /lib64/libpulsecore-3.0.so (0x7f990c91e000)
libltdl.so.7 => /lib64/libltdl.so.7 (0x7f990c713000)
libsamplerate.so.0 => /lib64/libsamplerate.so.0 (0x7f990c3a7000)
libspeexdsp.so.1 => /lib64/libspeexdsp.so.1 (0x7f990c194000)
liborc-0.4.so.0 => /lib64/liborc-0.4.so.0 (0x7f990bf11000)
libtdb.so.1 => /lib64/libtdb.so.1 (0x7f990bcff000)
libpulse.so.0 => /lib64/libpulse.so.0 (0x7f990bab5000)
libjson.so.0 => /lib64/libjson.so.0 (0x7f990b8b2000)
libpulsecommon-3.0.so => /usr/lib64/pulseaudio/libpulsecommon-3.0.so
(0x7f990b64a000)
libX11-xcb.so.1 => /lib64/libX11-xcb.so.1 (0x7f990b448000)
libX11.so.6 => /lib64/libX11.so.6 (0x7f990b10c000)
libxcb.so.1 => /lib64/libxcb.so.1 (0x7f990aeee000)
libICE.so.6 => /lib64/libICE.so.6 (0x7f990acd2000)
libSM.so.6 => /lib64/libSM.so.6 (0x7f990aac9000)
libXtst.so.6 => /lib64/libXtst.so.6 (0x7f990a8c3000)
libwrap.so.0 => /lib64/libwrap.so.0 (0x7f990a6b8000)
libsndfile.so.1 => /lib64/libsndfile.so.1 (0x7f990a458000)
libasyncns.so.0 => /lib64/libasyncns.so.0 (0x7f990a252000)
libdbus-1.so.3 => /lib64/libdbus-1.so.3 (0x7f990a00c000)
libcap.so.2 => /lib64/libcap.so.2 (0x7f9909e06000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x7f9909bea000)
librt.so.1 => /lib64/librt.so.1 (0x7f99099e2000)
libdl.so.2 => /lib64/libdl.so.2 (0x7f99097dd000)
libm.so.6 => /lib64/libm.so.6 (0x7f99094db000)
libc.so.6 => /lib64/libc.so.6 (0x7f990911b000)
/lib64/ld-linux-x86-64.so.2 (0x00374460)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f9908f04000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x7f9908ccd000)
libjson-c.so.2 => /lib64/libjson-c.so.2 (0x7f9908ac1000)
libXau.so.6 => /lib64/libXau.so.6 (0x7f99088bd000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x7f99086b7000)
libXext.so.6 => /lib64/libXext.so.6 (0x7f99084a5000)
libXi.so.6 => /lib64/libXi.so.6 (0x7f9908295000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x7f990807b000)
libgsm.so.1 => /lib64/libgsm.so.1 (0x7f9907e6f000)
libFLAC.so.8 => /lib64/libFLAC.so.8 (0x7f9907c2b000)
libvorbisenc.so.2 => /lib64/libvorbisenc.so.2 (0x7f990775b000)
libvorbis.so.0 => /lib64/libvorbis.so.0 (0x7f990752d000)
libogg.so.0 => /lib64/libogg.so.0 (0x7f9907326000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x7f990710b000)
libattr.so.1 => /lib64/libattr.so.1 (0x7f9906f06000)
libfreebl3.so => /lib64/libfreebl3.so (0x7f9906c99000)



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

Re: Minimal install diff from F16 to F19 (TC6)

[Remi Collet]

Le 20/06/2013 12:18, Harald Hoyer a écrit :
> On 06/20/2013 11:59 AM, Remi Collet wrote:
>> Le 20/06/2013 11:52, Harald Hoyer a écrit :
>>> $ rpm -q --whatrequires json-c
>>> no package requires json-c
>>
>> Probably should try
>>
>> $ rpm -q --whatrequires \
>>   "libjson.so.0()(64bit)" \
>>   "libjson-c.so.2()(64bit)"
>>
>> => pulseaudio, abrt, libreport, ...
>>
>> Remi.
>>
> 
> This cries for the compile option "-Wl,--as-needed"

I think I have explain that when updated to 0.11.

libjson.so is just a artefact to allow applications build with it to
continue to work.

libjson-c.so is the correct library
(renamed by upstream because of name conflicts with other projects).

So, if an application is link with -ljson it will fail and need a fix.

As usually, correct way is to use pkg-config output

$ pkg-config --cflags json-c
-I/usr/include/json-c

$ pkg-config --libs json-c
-ljson-c

And, for compatibility, to avoid to much problem

$ pkg-config --libs json
-ljson-c


Notice : this layer will be dropped in the future.

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

Re: Fedora 19 - Feature PHP 5.5 done !

[Remi Collet]

Freeze exception required for this update.
https://bugzilla.redhat.com/976306


Remi.

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

Re: rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)

[Ben Boeckel]

On Mon, 17 Jun, 2013 at 15:29:39 GMT, Michael Schwendt wrote:
> One problem with that is, one cannot "blindly" run autoreconf -fi and
> expect it to be 100% compatible with the multitude of Autotools' based
> projects. Typically one will need to update the configure script, m4
> macros as well as Makefile.{am,in} templates. And if one doesn't verify
> the build framework, one can miss files where regenerating them drops
> stuff (as one example, config.h.in files where someone has inserted
> stuff the wrong way).

There are also those rare upstreams which run autoreconf once, commit
the generated files, then make "minor" changes to configure and friends
directly. Running autoreconf on these projects is bound to fail and
upstream might be unhappy moving "back" to editing the .in and .ac files
directly.

--Ben

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

RE: rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)

[Jonathan Masters]

Indeed. This was a concern I raised when we first began the bootstrap. Blindly 
rerunning autoreconf in every case is a really bad idea. But doing it in a 
discretionary way, allowing the package maintainer to influence what happens 
(they in theory know whether this will work for their package and their 
upstream) is good.

Sent from my Android phone using TouchDown (www.nitrodesk.com)


-Original Message-
From: Ben Boeckel [maths...@gmail.com]
Received: Thursday, 20 Jun 2013, 7:53
To: devel@lists.fedoraproject.org
Subject: Re: rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not 
support aarch64 in f19 and rawhide bug #925276)


On Mon, 17 Jun, 2013 at 15:29:39 GMT, Michael Schwendt wrote:
> One problem with that is, one cannot "blindly" run autoreconf -fi and
> expect it to be 100% compatible with the multitude of Autotools' based
> projects. Typically one will need to update the configure script, m4
> macros as well as Makefile.{am,in} templates. And if one doesn't verify
> the build framework, one can miss files where regenerating them drops
> stuff (as one example, config.h.in files where someone has inserted
> stuff the wrong way).

There are also those rare upstreams which run autoreconf once, commit
the generated files, then make "minor" changes to configure and friends
directly. Running autoreconf on these projects is bound to fail and
upstream might be unhappy moving "back" to editing the .in and .ac files
directly.

--Ben

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

F-19 Branched report: 20130620 changes

[Fedora Branched Report]

Compose started at Thu Jun 20 09:15:02 UTC 2013

Broken deps for x86_64
--
[avgtime]
avgtime-0-0.5.git20120724.fc19.x86_64 requires 
libphobos-ldc.so.60()(64bit)
[derelict]
derelict-ogg-3-13.20130516gitd8aa11d.fc19.i686 requires ogg
derelict-ogg-3-13.20130516gitd8aa11d.fc19.i686 requires OGG
derelict-ogg-3-13.20130516gitd8aa11d.fc19.x86_64 requires ogg
derelict-ogg-3-13.20130516gitd8aa11d.fc19.x86_64 requires OGG
derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.i686 requires ogg
derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.i686 requires OGG
derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires ogg
derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires OGG
derelict-pq-3-13.20130516gitd8aa11d.fc19.i686 requires pq
derelict-pq-3-13.20130516gitd8aa11d.fc19.i686 requires PQ
derelict-pq-3-13.20130516gitd8aa11d.fc19.x86_64 requires pq
derelict-pq-3-13.20130516gitd8aa11d.fc19.x86_64 requires PQ
derelict-pq-devel-3-13.20130516gitd8aa11d.fc19.i686 requires pq
derelict-pq-devel-3-13.20130516gitd8aa11d.fc19.i686 requires PQ
derelict-pq-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires pq
derelict-pq-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires PQ
derelict-tcod-3-13.20130516gitd8aa11d.fc19.i686 requires tcod
derelict-tcod-3-13.20130516gitd8aa11d.fc19.i686 requires TCOD
derelict-tcod-3-13.20130516gitd8aa11d.fc19.x86_64 requires tcod
derelict-tcod-3-13.20130516gitd8aa11d.fc19.x86_64 requires TCOD
derelict-tcod-devel-3-13.20130516gitd8aa11d.fc19.i686 requires tcod
derelict-tcod-devel-3-13.20130516gitd8aa11d.fc19.i686 requires TCOD
derelict-tcod-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires tcod
derelict-tcod-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires TCOD
[dragonegg]
dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19
[dsqlite]
dsqlite-1.0-4.fc19.i686 requires libphobos-ldc.so.60
dsqlite-1.0-4.fc19.x86_64 requires libphobos-ldc.so.60()(64bit)
[dustmite]
dustmite-1-8.20121031git1fb3ac4.fc18.x86_64 requires 
libphobos-ldc.so.60()(64bit)
[freeipa]
freeipa-server-strict-3.2.1-1.fc19.x86_64 requires pki-ca = 0:10.0.2
freeipa-server-strict-3.2.1-1.fc19.x86_64 requires 389-ds-base = 
0:1.3.1.0
[gl3n]
gl3n-0.20120813-4.fc19.i686 requires libphobos-ldc.so.60
gl3n-0.20120813-4.fc19.x86_64 requires libphobos-ldc.so.60()(64bit)
[gooddata-cl]
gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java
[kawa]
1:kawa-1.11-5.fc19.x86_64 requires servlet25
[koji]
koji-vm-1.8.0-1.fc19.noarch requires python-virtinst
[libkolab]
php-kolab-0.4.1-3.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64
php-kolab-0.4.1-3.fc19.x86_64 requires php(api) = 0:20100412-x86-64
[nodejs-tilelive]
nodejs-tilelive-4.4.3-2.fc19.noarch requires npm(optimist) < 0:0.4
[openbox]
gdm-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel
gnome-panel-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires 
gnome-panel
[ovirt-engine]
ovirt-engine-notification-service-3.1.0-1.fc19.noarch requires 
classpathx-mail
[ovirt-guest-agent]
ovirt-guest-agent-gdm-plugin-1.0.6-6.fc19.x86_64 requires 
libgdmsimplegreeter.so.1()(64bit)
[perl-Bio-ASN1-EntrezGene]
perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires 
perl(Bio::Index::AbstractSeq)
[perl-Bio-SamTools]
perl-Bio-SamTools-1.35-2.fc19.x86_64 requires 
perl(Bio::SeqFeature::Lite)
perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq)
[python-TraitsBackendQt]
python-TraitsBackendQt-3.5.0-5.fc19.noarch requires python-TraitsGUI
[scala]
scala-2.9.2-2.fc19.noarch requires osgi(org.scala-ide.scala.library)
[spacewalk-web]
spacewalk-dobby-1.9.22-2.fc19.noarch requires perl(Spacewalk::Setup)
[tango]
tango-2-12.20120821git7b92443.fc19.i686 requires libphobos-ldc.so.60
tango-2-12.20120821git7b92443.fc19.x86_64 requires 
libphobos-ldc.so.60()(64bit)
[zarafa]
php-mapi-7.0.13-1.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64
php-mapi-7.0.13-1.fc19.x86_64 requires php(api) = 0:20100412-x86-64



Broken deps for i386
--
[avgtime]
avgtime-0-0.5.git20120724.fc19.i686 requires libphobos-ldc.so.60
[derelict]
derelict-ogg-3-13.20130516gitd8aa11d.fc19.i686 requires ogg
derelict-ogg-3-13.20130516gitd8aa11d.fc19.i686 requires OGG
derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.i686 requires ogg
derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.i686 requires OGG
derelict-pq-3-13.20130516gitd8aa11d.fc19.i686 requires pq
derelict-pq-3-13.20130516gitd8aa11d.fc19.i686 requires PQ
der

Getting rid of systemd-sysv-convert?

[Lennart Poettering]

Heya!

When systemd was first adopted by Fedora a requirement mandated by FESCO
(or was it FPC?) was that the script "systemd-sysv-convert" (which I
wrote) should be added which is supposed to save the old runlevel
configuration of sysv scripts before we replace them with systemd units.

Now we are starting work on F20, I do wonder if we can get rid of this
thing? The script is currently part of the systemd source package (but
installed in its own systemd-sysv package), and the packaging guidelines
suggest making use of this script in all RPMs that are converted, also
adding a requires(post) dependency on systemd-sysv to those:

https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Packages_migrating_to_a_systemd_unit_file_from_a_SysV_initscript

I'd really like to get rid of this thing (I thought it was a bad idea
from day 1 when we added it). I have the strong suspicion that nobody
ever made use of this functionality (how I know that? since runlevels
don't map that easily to systemd targets the job it does is not very
good but we nonetheless never got a single bug report about it...). I
figure next to zero of our users even knew about its existence...

What I really hate about the script is that it indirectly adds a Python
dependency to all packages making use of it. This really sucks for
minimal container setups where you really don't want Python to be pulled
in just for this reason. This then results in bugs like this one:

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

Anyway, I think it's a bad idea to have this, it has more drawbacks then
benefits, it is pretty much unused, and the majority of packages are
converted since a while anyway.

So, anyone still insists on keeping this around? If not I will file a
bug against FPC to drop any mention of the tool and remove it from the
systemd RPMs, and everything will get smaller and simpler and unicorns
and butterflies will reign!

(If don't get many replies to this mail, then I'd be a really happy man,
since for me that'd kinda be proof that really nobody cares about this
tool...)

Thanks,

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Getting rid of systemd-sysv-convert?

[Miloslav Trmač]

On Thu, Jun 20, 2013 at 3:18 PM, Lennart Poettering
 wrote:
> When systemd was first adopted by Fedora a requirement mandated by FESCO
> (or was it FPC?) was that the script "systemd-sysv-convert" (which I
> wrote) should be added which is supposed to save the old runlevel
> configuration of sysv scripts before we replace them with systemd units.

> it is pretty much unused

The policy for the FPC to decide, let me just add some data:
> $ repoquery --whatrequires systemd-sysv --qf '%{name}' |sort -u|wc -l
> 186
including packages like avahi.
 Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[389-devel] revised: please review: Ticket 47329 - Improve slapi_back_transaction_begin() return code when transactions are not available

[Mark Reynolds]

Revised fix based off of Rich and Ludwig's comments

https://fedorahosted.org/389/ticket/47329

https://fedorahosted.org/389/attachment/ticket/47329/0001-Ticket-47329-Improve-slapi_back_transaction_begin-re.patch 



--
Mark Reynolds
Red Hat, Inc
mreyno...@redhat.com

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

Re: Getting rid of systemd-sysv-convert?

[Jon Ciesla]

On Thu, Jun 20, 2013 at 8:42 AM, Miloslav Trmač  wrote:

> On Thu, Jun 20, 2013 at 3:18 PM, Lennart Poettering
>  wrote:
> > When systemd was first adopted by Fedora a requirement mandated by FESCO
> > (or was it FPC?) was that the script "systemd-sysv-convert" (which I
> > wrote) should be added which is supposed to save the old runlevel
> > configuration of sysv scripts before we replace them with systemd units.
> 
> > it is pretty much unused
>
> The policy for the FPC to decide, let me just add some data:
> > $ repoquery --whatrequires systemd-sysv --qf '%{name}' |sort -u|wc -l
> > 186
> including packages like avahi.
>  Mirek
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel


As much as I'd like to see it go, I don't think we should until we're a lot
farther along the SysV->systemd migration path, just as a practical
matter.  I don't think removing this tool now will help us travel farther
along it.  There are other obstacles, to be sure, but I think anything we
can keep in place to facilitate migration is a good thing.

-J

-- 
http://cecinestpasunefromage.wordpress.com/

in your fear, seek only peace
in your fear, seek only love

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

Re: Getting rid of systemd-sysv-convert?

[Jóhann B. Guðmundsson]

On 06/20/2013 01:42 PM, Miloslav Trmač wrote:

On Thu, Jun 20, 2013 at 3:18 PM, Lennart Poettering
 wrote:

When systemd was first adopted by Fedora a requirement mandated by FESCO
(or was it FPC?) was that the script "systemd-sysv-convert" (which I
wrote) should be added which is supposed to save the old runlevel
configuration of sysv scripts before we replace them with systemd units.



it is pretty much unused

The policy for the FPC to decide, let me just add some data:

$ repoquery --whatrequires systemd-sysv --qf '%{name}' |sort -u|wc -l
186

including packages like avahi.
  Mirek


Just for reference we are speaking of this [1] in relevant spec files 
and that section at least can be entirely removed for components that 
got migrated 
( since the those legacy sysv scripst should be EOL by now)

JBG

1. 
http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Packages_migrating_to_a_systemd_unit_file_from_a_SysV_initscript

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

Re: rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)

[Alec Leamas]

On 2013-06-20 14:19, Jonathan Masters wrote:

Indeed. This was a concern I raised when we first began the bootstrap. Blindly 
rerunning autoreconf in every case is a really bad idea. But doing it in a 
discretionary way, allowing the package maintainer to influence what happens 
(they in theory know whether this will work for their package and their 
upstream) is good.

Sent from my Android phone using TouchDown (www.nitrodesk.com)


-Original Message-
From: Ben Boeckel [maths...@gmail.com]
Received: Thursday, 20 Jun 2013, 7:53
To: devel@lists.fedoraproject.org
Subject: Re: rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not 
support aarch64 in f19 and rawhide bug #925276)


On Mon, 17 Jun, 2013 at 15:29:39 GMT, Michael Schwendt wrote:

One problem with that is, one cannot "blindly" run autoreconf -fi and
expect it to be 100% compatible with the multitude of Autotools' based
projects. Typically one will need to update the configure script, m4
macros as well as Makefile.{am,in} templates. And if one doesn't verify
the build framework, one can miss files where regenerating them drops
stuff (as one example, config.h.in files where someone has inserted
stuff the wrong way).

There are also those rare upstreams which run autoreconf once, commit
the generated files, then make "minor" changes to configure and friends
directly. Running autoreconf on these projects is bound to fail and
upstream might be unhappy moving "back" to editing the .in and .ac files
directly.

--Ben



Hm... it actually seems that there is a lot of common ground here, and 
quite different from what a newbie  will find if googling [1]. Yes, it's 
an old draft, but in a sense it't the most official document found, I guess.


We have at least three cases?
- Ben's case: projects running auto(re)conf once, then committing and 
maintaining the generated files (and some years later, in desperation, 
goes for cmake...)
- Projects which intitially had a working autotools setup which have 
become more or less unusable in a modern environment.
- Projects which have a well maintained, working autotools setup - here 
it's natural to run autoreconf as part of the build.


Seems that we all agree that the last situation is the preferred one. In 
the other scenarios, it might make make sense to try to help upstream to 
update the obsolete configure.in/ac and Makefile.am. Or it just might 
not, and it's better to use the generated fiels.


This should really be a fpc ticket before we lose everything. However, 
my fpc quota has expired... ;)


--alec

[1] https://fedoraproject.org/wiki/PackagingDrafts/AutoConf
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Getting rid of systemd-sysv-convert?

[Jóhann B. Guðmundsson]

On 06/20/2013 01:48 PM, Jon Ciesla wrote:


As much as I'd like to see it go, I don't think we should until we're 
a lot farther along the SysV->systemd migration path, just as a 
practical matter.  I don't think removing this tool now will help us 
travel farther along it.  There are other obstacles, to be sure, but I 
think anything we can keep in place to facilitate migration is a good 
thing.


We are far enough down that path for F20.

Requires(post): systemd-sysv
%triggerun

And that migration script and requirement is so utterly broken because 
our users still need to "enable" the relevant service/daemon manually.


Personally I never understood why fpc/fesco required this or what they 
had expected our user base suppose to do with that information.


To me it's as equal useless decition as to continue to ship legacy sys v 
initscript once they have been migrate which I probably will have to 
wind up having to cleanup after them as well.
( fortunately for me there are like only 20 packages out of those ca 600 
that do so )


JBG

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

Re: Getting rid of systemd-sysv-convert?

[Christopher Meng]

Hmm...

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

Re: Fatal PCIe error 928 on KVM GPU Passthrough

[Don Dutile]

On 06/20/2013 03:27 AM, Mario Ceresa wrote:

Thanks Lars, I'll do as you suggest!

Best,

Mario


On 19 June 2013 23:35, Lars Seipel mailto:lars.sei...@gmail.com>> wrote:

On Wed, Jun 19, 2013 at 04:42:30PM +0200, Mario Ceresa wrote:
 > does anybody know if it is currently possible to do GPU passthrough in 
kvm?


No.  it's being worked upstream by Alex Williamson.


You might want to ask that on the Fedora virt list[1] or on upstream
libvirt's users list[2]. The chances for getting good answers should be
much higher there.

[1] https://admin.fedoraproject.org/mailman/listinfo/virt
[2] http://libvirt.org/contact.html






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

Re: Minimal install diff from F16 to F19 (TC6)

[Matthew Miller]

On Thu, Jun 20, 2013 at 11:52:54AM +0200, Harald Hoyer wrote:
> And why is NetworkManager and firewalld in the minimal install?

We are on track to replace the "legacy" network and firewall init scripts
with these. It's a slow track, but that's the direction.

Overall, I'm in favor of having a single code path for network and firewall
configuration. As I understand from the NetworkManager developers, a mode
where NetworkManager does the basic configuration in the initramfs and then
goes away is in development. If that can also hand-off to a simple dhcp
client, I think we're in pretty good shape for the simple case.

Here's my RFE https://bugzilla.redhat.com/show_bug.cgi?id=863515

Firewalld needs a *lot* more work in this area. Here's _that_ RFE:
https://bugzilla.redhat.com/show_bug.cgi?id=876683

As discussed before the F18 release, firewalld was initially proposed as a
"default" for F18, but actually crept in as mandatory, since Anaconda uses
it. One can remove it after the install, or in kickstart post.

And you're absolutely right to focus in this, as these two packages are
definitely the cause of most of the growth in minimal, and pull in most of
the odd stuff that doesn't feel like it belongs at that level. So, in
addition to the above, reducing/splitting the dependencies would be
valuable.


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Getting rid of systemd-sysv-convert?

[Lennart Poettering]

On Thu, 20.06.13 15:42, Miloslav Trmač (m...@volny.cz) wrote:

> On Thu, Jun 20, 2013 at 3:18 PM, Lennart Poettering
>  wrote:
> > When systemd was first adopted by Fedora a requirement mandated by FESCO
> > (or was it FPC?) was that the script "systemd-sysv-convert" (which I
> > wrote) should be added which is supposed to save the old runlevel
> > configuration of sysv scripts before we replace them with systemd units.
> 
> > it is pretty much unused
> 
> The policy for the FPC to decide, let me just add some data:
> > $ repoquery --whatrequires systemd-sysv --qf '%{name}' |sort -u|wc -l
> > 186
> including packages like avahi.
>  Mirek

Yeah, it's used by packages, but not by people. i.e. package use it to
store away the old runlevel info, but no humans actually ever then make
use of it, is what I say. 

And regarding the usage by packages: the policy states that the tool
needs to be invoked with a suffix of "2>&1 >/dev/null || :" (Unix can be
so descriptive!) which means simply removing the tool would make these
lines NOPs -- as long as we keep some package providing systemd-sysv in
place. Or we could even symlink the tool to /bin/true or so in case
people are afraid that some scriplets dropped the "2>&1 > /dev/null ||
:" bit.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Getting rid of systemd-sysv-convert?

[Lennart Poettering]

On Thu, 20.06.13 08:48, Jon Ciesla (limburg...@gmail.com) wrote:

> On Thu, Jun 20, 2013 at 8:42 AM, Miloslav Trmač  wrote:
> 
> > On Thu, Jun 20, 2013 at 3:18 PM, Lennart Poettering
> >  wrote:
> > > When systemd was first adopted by Fedora a requirement mandated by FESCO
> > > (or was it FPC?) was that the script "systemd-sysv-convert" (which I
> > > wrote) should be added which is supposed to save the old runlevel
> > > configuration of sysv scripts before we replace them with systemd units.
> > 
> > > it is pretty much unused
> >
> > The policy for the FPC to decide, let me just add some data:
> > > $ repoquery --whatrequires systemd-sysv --qf '%{name}' |sort -u|wc -l
> > > 186
> > including packages like avahi.
> >  Mirek
> 
> 
> As much as I'd like to see it go, I don't think we should until we're a lot
> farther along the SysV->systemd migration path, just as a practical
> matter.  I don't think removing this tool now will help us travel farther
> along it.  There are other obstacles, to be sure, but I think anything we
> can keep in place to facilitate migration is a good thing.

Well, to turn this around: what benefit does the systemd-sysv-convert
tool bring regarding the migration path? I don't see any. (note that
this tool is -- despite its name -- not a tool that wil convert sysv
scripts to systemd units. Not at all. It's supposed to record in which
runlevels a service was enabled before the migration for reference by
the admin later on (this is stored in the file
/var/lib/systemd/sysv-convert/database).

If we drop this now then the migration certainly becomes a bit easier,
since the scriptlets become much shorter, and easier for people to
understand -- and who likes rpm triggers anyway?

Note that systemd-sysv-convert is a tool that is supposed to be useful
for admins, not for packagers or developers. And I simply don't see that
admins accepted that tool and ever made use of it. 

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Matthew Miller]

On Thu, Jun 20, 2013 at 05:08:48PM +0200, Reindl Harald wrote:
> > We are on track to replace the "legacy" network and firewall init scripts
> > with these. It's a slow track, but that's the direction
> *do not* remove iptables.service for a lot od reason explained
> often enough as well as NM is utterly useless on servers and
> workstations with several *static* configured NIC's

Well, like I just said, it's a slow track. I certainly am vigorously opposed
to removing it before the replacement has the same functionality and
reliability.


-- 
Matthew Miller   mat...@mattdm.org  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Getting rid of systemd-sysv-convert?

[Reindl Harald]

Am 20.06.2013 16:02, schrieb Christopher Meng:
> Hmm...
> 
> Subversion uses it...

why does *anything* still use sysv-init stuff and packages
whichare not converted simply not dropped to wake up the
maintainer which does *clearly* not his work?

it is very poor push F15 out with a halfbaken systemd with
neraly no systemd-units and years later allow packages still
not follow the distribution standard

F15->F16->F17->F18->F19->f20
these are *5 releases* and F15/F16 "features" are stoll not done

i say it again: it should have been prohibited ever ship
services with sysv-units from F15 and F15 as long delayed
as all packages are converted or unresponsive ones dropped



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

Re: Minimal install diff from F16 to F19 (TC6)

[Reindl Harald]

Am 20.06.2013 17:01, schrieb Matthew Miller:
> On Thu, Jun 20, 2013 at 11:52:54AM +0200, Harald Hoyer wrote:
>> And why is NetworkManager and firewalld in the minimal install?
> 
> We are on track to replace the "legacy" network and firewall init scripts
> with these. It's a slow track, but that's the direction

*do not* remove iptables.service for a lot od reason explained
often enough as well as NM is utterly useless on servers and
workstations with several *static* configured NIC's



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

Re: Broken BioPerl dependencies...

[Daniel Newkirk]

Can I offer to maintain it then? Who would I need to email to make that happen?

Daniel

Daniel Newkirk
Graduate Student
Yokomori Lab, Xie Lab
Dept. of Biological Chemistry, UCI

tel: 949-824-2158
email: dnewk...@uci.edu

--
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: Minimal install diff from F16 to F19 (TC6)

[Michael Cronenworth]

On 06/20/2013 10:37 AM, Matthew Miller wrote:
> Well, like I just said, it's a slow track. I certainly am vigorously opposed
> to removing it before the replacement has the same functionality and
> reliability.

... and resource usage. Having Python fully loaded for a firewall isn't
my first choice.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Test-Announce] TC6 cloud images available in EC2 and for download

[Matthew Miller]

Fedora 19 Test Candidate 6 cloud images are now available from:

  https://dl.fedoraproject.org/pub/alt/stage/19-TC6/Images/

in either qcow2 or raw.xz format. You should be able to use Glance in
OpenStack to just import the qcow2 images directly and go.

They're also in Amazon EC2 in the US East region;

  ami-93c3b2fa for x86_64
  ami-17c2b37e for i386

Thanks to Dennis Gilmore in Fedora Release Engineering for the extra work to
make this happen.

The images are configured with "fedora" as the default user with
passwordless sudo. You can change this behavior by passing different
configuration data via the user-data in either OpenStack or EC2. For
example, to allow direct root login and to suppress the creation of the
'fedora' user, use

#cloud-config
users:
disable_root: 0

(The first line is identifying the userdata type, not a comment.)



-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
___
cloud mailing list
cl...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-Perl-Critic] BR: perl(Fatal) for the test suite

[Paul Howarth]

commit bcc9c8d75b847340927b6609ad7c84d12b8eac60
Author: Paul Howarth 
Date:   Thu Jun 20 18:41:08 2013 +0100

BR: perl(Fatal) for the test suite

 perl-Perl-Critic.spec |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)
---
diff --git a/perl-Perl-Critic.spec b/perl-Perl-Critic.spec
index 0cf065b..35992e2 100644
--- a/perl-Perl-Critic.spec
+++ b/perl-Perl-Critic.spec
@@ -1,6 +1,6 @@
 Name:  perl-Perl-Critic
 Version:   1.118
-Release:   3%{?dist}
+Release:   4%{?dist}
 Summary:   Critique Perl source code for best-practices
 Group: Development/Libraries
 License:   GPL+ or Artistic
@@ -58,6 +58,7 @@ BuildRequires:perl(Readonly::XS)
 BuildRequires: perl(Term::ANSIColor) >= 2.02
 
 # Main test suite
+BuildRequires: perl(Fatal)
 BuildRequires: perl(File::Spec::Functions)
 BuildRequires: perl(Test::Deep)
 BuildRequires: perl(Test::Memory::Cycle)
@@ -148,6 +149,9 @@ LC_ALL=en_US ./Build %{!?perl_bootstrap:author}test
 %{_mandir}/man3/Test::Perl::Critic::Policy.3pm*
 
 %changelog
+* Thu Jun 20 2013 Paul Howarth  - 1.118-4
+- BR: perl(Fatal) for the test suite
+
 * Thu Feb 14 2013 Fedora Release Engineering  
- 1.118-3
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_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

Re: Minimal install diff from F16 to F19 (TC6)

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/20/2013 11:08 AM, Reindl Harald wrote:
> 
> 
> Am 20.06.2013 17:01, schrieb Matthew Miller:
>> On Thu, Jun 20, 2013 at 11:52:54AM +0200, Harald Hoyer wrote:
>>> And why is NetworkManager and firewalld in the minimal
>>> install?
>> 
>> We are on track to replace the "legacy" network and firewall init
>> scripts with these. It's a slow track, but that's the direction
> 
> *do not* remove iptables.service for a lot od reason explained 
> often enough as well as NM is utterly useless on servers and 
> workstations with several *static* configured NIC's
> 

Mind if I ask why you think this way about NetworkManager? The NM
currently shipping in Fedora 19 has full support for managing static
NICs, as well as bonding, bridging and VLAN support for enterprise
use-cases.

NetworkManager has historically been perceived as a desktop/laptop
tool but in its current incarnation it should be usable for all but
the most esoteric enterprise workloads.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlHDQ18ACgkQeiVVYja6o6Me0wCeNYAGhOf1YSn+x9nlBVqNWewF
t9oAn2u80JWIyr/PV3jL5H6LLfXMFQC5
=UPum
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-Perl-Critic] Created tag perl-Perl-Critic-1.118-4.fc20

[Paul Howarth]

The lightweight tag 'perl-Perl-Critic-1.118-4.fc20' was created pointing to:

 bcc9c8d... BR: perl(Fatal) for the test suite
--
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: Minimal install diff from F16 to F19 (TC6)

[Eric Smith]

Does NM in F19 support statically assigning multiple subnets to the
same physical interface, WITHOUT using VLANs?  I often need that on
server machines, and wasn't able to figure out any way to do it with
NM on F17, but I haven't yet tried it on F19.

With the old-style network configuration, it was easy to manually
configure this by creating /etc/sysconfig/network-scripts/eth3:
config files.  Also, it was very easy to automate creating and
removing them, while I have yet to be successful scripting changes to
NM configurations, though probably I'm overlooking some simple way of
doing that.

Previously it has seemed that the old-style network configuration was
more robust than NM, though not as user-friendly. However, I know that
NM has been getting more robust over time, so that may no longer be
true.

Eric


On Thu, Jun 20, 2013 at 12:01 PM, Stephen Gallagher  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 06/20/2013 11:08 AM, Reindl Harald wrote:
>>
>>
>> Am 20.06.2013 17:01, schrieb Matthew Miller:
>>> On Thu, Jun 20, 2013 at 11:52:54AM +0200, Harald Hoyer wrote:
 And why is NetworkManager and firewalld in the minimal
 install?
>>>
>>> We are on track to replace the "legacy" network and firewall init
>>> scripts with these. It's a slow track, but that's the direction
>>
>> *do not* remove iptables.service for a lot od reason explained
>> often enough as well as NM is utterly useless on servers and
>> workstations with several *static* configured NIC's
>>
>
> Mind if I ask why you think this way about NetworkManager? The NM
> currently shipping in Fedora 19 has full support for managing static
> NICs, as well as bonding, bridging and VLAN support for enterprise
> use-cases.
>
> NetworkManager has historically been perceived as a desktop/laptop
> tool but in its current incarnation it should be usable for all but
> the most esoteric enterprise workloads.
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlHDQ18ACgkQeiVVYja6o6Me0wCeNYAGhOf1YSn+x9nlBVqNWewF
> t9oAn2u80JWIyr/PV3jL5H6LLfXMFQC5
> =UPum
> -END PGP SIGNATURE-
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Chris Adams]

Once upon a time, Stephen Gallagher  said:
> Mind if I ask why you think this way about NetworkManager? The NM
> currently shipping in Fedora 19 has full support for managing static
> NICs, as well as bonding, bridging and VLAN support for enterprise
> use-cases.

I think most "traditional" system admins see a running NM daemon as an
additional point of failure in a static network.  If my server's network
setup is static, I don't want a daemon running attempting to "manage"
it.  If it has a bug, gets misconfigured, etc., it might do something to
screw up an otherwise working setup.

I understand that some servers/setups may be able to take advantage of
NM functionality, but assuming that all servers _need_ NM is too much.
This is all IMHO of course.

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

Re: Minimal install diff from F16 to F19 (TC6)

[Chris Adams]

Once upon a time, Eric Smith  said:
> Does NM in F19 support statically assigning multiple subnets to the
> same physical interface, WITHOUT using VLANs?  I often need that on
> server machines, and wasn't able to figure out any way to do it with
> NM on F17, but I haven't yet tried it on F19.

Also, does NM do the "bulk"-style IP alias adding?  The old-style
network service can handle a "range" file for adding addresses that is
much easier to config/manage than adding 400 individual IP addresses.
-- 
Chris Adams 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Tomasz Torcz]

On Thu, Jun 20, 2013 at 12:13:54PM -0600, Eric Smith wrote:
> Does NM in F19 support statically assigning multiple subnets to the
> same physical interface, WITHOUT using VLANs?  I often need that on
> server machines, and wasn't able to figure out any way to do it with
> NM on F17, but I haven't yet tried it on F19.

  I think it does, since few releases. If you use proper syntax:
# grep IPADDRn /usr/share/doc/initscripts-9.47/sysconfig.txt
(note the ‘n‘)

> With the old-style network configuration, it was easy to manually
> configure this by creating /etc/sysconfig/network-scripts/eth3:

  That's an old style aliases, not multiple addresses for one interface.

-- 
Tomasz Torcz   72->|   80->|
xmpp: zdzich...@chrome.pl  72->|   80->|

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

Re: Minimal install diff from F16 to F19 (TC6)

[Colin Walters]

On Thu, 2013-06-20 at 13:15 -0500, Chris Adams wrote:

> I think most "traditional" system admins see a running NM daemon as an
> additional point of failure in a static network.  If my server's network
> setup is static, I don't want a daemon running attempting to "manage"
> it.  If it has a bug, gets misconfigured, etc., it might do something to
> screw up an otherwise working setup.

Yes, it's just not easy to do without creating race conditions.  Various
other components use NetworkManager as an API, and if just called exit()
arbitrarily it'd introduce the problems described here:

https://bugs.freedesktop.org/show_bug.cgi?id=11454

This point has been raised repeatedly, the developers are aware that
it'd be nicer for NM to not show up in "ps" in these situations, but the
reason it's not done is it's nontrivial and there are a lot of other
things in the priority queue.

> I understand that some servers/setups may be able to take advantage of
> NM functionality, but assuming that all servers _need_ NM is too much.
> This is all IMHO of course.

It's not about "all", but about having a plan, executing on it and
staying on top of major regressions.  There's been a fair amount of
continual improvement, and stuff like the revamped nmcli should help a
lot.



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

[Bug 976544] New: perl-HTTP-Tiny-0.032 is available

[bugzilla]

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

Bug ID: 976544
   Summary: perl-HTTP-Tiny-0.032 is available
   Product: Fedora
   Version: rawhide
 Component: perl-HTTP-Tiny
  Keywords: FutureFeature, Triaged
  Severity: unspecified
  Priority: unspecified
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-de...@lists.fedoraproject.org, ppi...@redhat.com

Latest upstream release: 0.032
Current version/release in Fedora Rawhide: 0.031-1.fc20
URL: http://search.cpan.org/dist/HTTP-Tiny/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=RWL0TTInZb&a=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Minimal install diff from F16 to F19 (TC6)

[Colin Walters]

On Thu, 2013-06-20 at 12:13 -0600, Eric Smith wrote:
> Does NM in F19 support statically assigning multiple subnets to the
> same physical interface, WITHOUT using VLANs?

Yes.  You can easily do this in the GNOME Control center, just try it.
Click "Manual", and then the "+" will allow adding multiple IPv4 (or
IPv6) addresses to a single interface.

> With the old-style network configuration, it was easy to manually
> configure this by creating /etc/sysconfig/network-scripts/eth3:
> config files. 

As Tomaz mentions that's the legacy way; what NM writes into the
network-scripts when you do the above is the modern way.

>  Also, it was very easy to automate creating and
> removing them, while I have yet to be successful scripting changes to
> NM configurations, though probably I'm overlooking some simple way of
> doing that.

The new nmcli will help here...could possibly land in a post-release
update.  But if you look at what NM writes for the above you can see how
it works:

HWADDR=52:54:00:98:A4:04
TYPE=Ethernet
BOOTPROTO=none
IPADDR0=10.76.76.76
PREFIX0=24
GATEWAY0=10.0.0.1
IPADDR1=10.42.42.42
PREFIX1=24
GATEWAY1=10.42.42.1
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes
IPV6_FAILURE_FATAL=no
NAME="Wired connection 2"
UUID=f5480bfe-f4df-4cc9-ab7d-ccb778a6727a
ONBOOT=yes




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

Re: Minimal install diff from F16 to F19 (TC6)

[Bill Nottingham]

Chris Adams (li...@cmadams.net) said: 
> Once upon a time, Eric Smith  said:
> > Does NM in F19 support statically assigning multiple subnets to the
> > same physical interface, WITHOUT using VLANs?  I often need that on
> > server machines, and wasn't able to figure out any way to do it with
> > NM on F17, but I haven't yet tried it on F19.
> 
> Also, does NM do the "bulk"-style IP alias adding?  The old-style
> network service can handle a "range" file for adding addresses that is
> much easier to config/manage than adding 400 individual IP addresses.

No, it does not support that at this time. Also note that (if I'm
remembering right) NM adds all aliases as secondary IP addresses, not as
':x' style additional devices.

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

Re: Minimal install diff from F16 to F19 (TC6)

[Matthew Miller]

On Thu, Jun 20, 2013 at 01:15:37PM -0500, Chris Adams wrote:
> > Mind if I ask why you think this way about NetworkManager? The NM
> > currently shipping in Fedora 19 has full support for managing static
> > NICs, as well as bonding, bridging and VLAN support for enterprise
> > use-cases.
> I think most "traditional" system admins see a running NM daemon as an
> additional point of failure in a static network.  If my server's network
> setup is static, I don't want a daemon running attempting to "manage"
> it.  If it has a bug, gets misconfigured, etc., it might do something to
> screw up an otherwise working setup.

Hence, the RFE -- a mode which sets up the above, and then goes away.

There are significant advantages to having a single code path for network
configuration on the system -- easier support, simpler documenation, easier
administration between multiple systems, easier development of new
distribution features overall. But the condition you give is very important
too -- that's why the "traditional" system is still there in parallel right
now.



-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Dan Williams]

On Thu, 2013-06-20 at 12:13 -0600, Eric Smith wrote:
> Does NM in F19 support statically assigning multiple subnets to the
> same physical interface, WITHOUT using VLANs?  I often need that on
> server machines, and wasn't able to figure out any way to do it with
> NM on F17, but I haven't yet tried it on F19.

It's supported that for 4 or 5 years.  You don't need aliases at all,
you just add more IP addresses to your ifcfg file and NM applies them to
the interface.

ADDRESS2=10.0.0.1
PREFIX2=8
ADDRESS3=4.5.6.7
PREFIX3=29

> With the old-style network configuration, it was easy to manually
> configure this by creating /etc/sysconfig/network-scripts/eth3:
> config files.  Also, it was very easy to automate creating and
> removing them, while I have yet to be successful scripting changes to
> NM configurations, though probably I'm overlooking some simple way of
> doing that.

Aliases came about because the kernel APIs (and ifconfig) couldn't
handle multiple addresses on a single interface.  That hasn't been the
case for like 8 or 10 years though, since netlink happened, and thus you
can add as many as you want via NM or /sbin/ip or whatever.  Aliases
haven't been required for years.

> Previously it has seemed that the old-style network configuration was
> more robust than NM, though not as user-friendly. However, I know that
> NM has been getting more robust over time, so that may no longer be
> true.

We want NM to be *capable* of working on servers with static
configuration, and we want NM not to do anything surprising in these
setups.  Whether an admin chooses to leave NM enabled or not is up to
them, but we hope to add enough value that many *will* leave it enabled,
either for remote administration, or a consistent interface to configure
networking on the machine instead of 10 different tools, or an
easier-to-use CLI than /sbin/ip + vi/emacs + config files, or whatever.
That's where we're going.

I did some screencast demos for some of these features and posted them
to the Fedora NM wiki pages if you're interested in see where we're
going:

https://fedoraproject.org/wiki/Tools/NetworkManager#Servers

Dan

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

Re: Minimal install diff from F16 to F19 (TC6)

[Chris Adams]

Once upon a time, Bill Nottingham  said:
> No, it does not support that at this time. Also note that (if I'm
> remembering right) NM adds all aliases as secondary IP addresses, not as
> ':x' style additional devices.

I prefer the "modern" secondaries vs. the old-style eth0:123, although I
have run into vendor software (such as the Plesk web hosting control
panel) that can't handle it.  I expect if that was the "one true way" in
some future version of RHEL, they'd adapt.

For anybody doing shared web hosting, bulk IP address configuration
(however they end up configured) is a must though.  I certainly don't
want to have to add a /24 one address at a time.

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

Re: Minimal install diff from F16 to F19 (TC6)

[Chris Adams]

Once upon a time, Matthew Miller  said:
> Hence, the RFE -- a mode which sets up the above, and then goes away.

I had not seen that mode (or a request for it).  That would be nice.  In
a perfect world (hah!), replacing "ifup" and "ifdown" with scripts that
just make the appropriate "nmcli" (or whatever) calls would be awesome,
as long as NM supports all the old functionality.

> There are significant advantages to having a single code path for network
> configuration on the system -- easier support, simpler documenation, easier
> administration between multiple systems, easier development of new
> distribution features overall. But the condition you give is very important
> too -- that's why the "traditional" system is still there in parallel right
> now.

That would be cool; I understand reducing methods reduces support
overhead.  Please don't take my email as throwing stones; I was trying
to _not_ do that, just point out why in some situations sysadmins
sometimes avoid NM.

I understand that the old-style network scripts are a maze of twisty
little passages, all different, and trying to replace all the
functionality that people use is not trivial.
-- 
Chris Adams 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Dan Williams]

On Thu, 2013-06-20 at 13:59 -0500, Chris Adams wrote:
> Once upon a time, Bill Nottingham  said:
> > No, it does not support that at this time. Also note that (if I'm
> > remembering right) NM adds all aliases as secondary IP addresses, not as
> > ':x' style additional devices.
> 
> I prefer the "modern" secondaries vs. the old-style eth0:123, although I
> have run into vendor software (such as the Plesk web hosting control
> panel) that can't handle it.  I expect if that was the "one true way" in
> some future version of RHEL, they'd adapt.
> 
> For anybody doing shared web hosting, bulk IP address configuration
> (however they end up configured) is a must though.  I certainly don't
> want to have to add a /24 one address at a time.

This is great feedback to have and something that NM should add support
for.  I've filed https://bugzilla.gnome.org/show_bug.cgi?id=702773 for
it.

Dan

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

Re: Minimal install diff from F16 to F19 (TC6)

[Dan Williams]

On Thu, 2013-06-20 at 14:06 -0500, Chris Adams wrote:
> Once upon a time, Matthew Miller  said:
> > Hence, the RFE -- a mode which sets up the above, and then goes away.
> 
> I had not seen that mode (or a request for it).  That would be nice.  In
> a perfect world (hah!), replacing "ifup" and "ifdown" with scripts that
> just make the appropriate "nmcli" (or whatever) calls would be awesome,
> as long as NM supports all the old functionality.

nmcli doesn't work unless NM is running, since it talks to NM to do
stuff, so it would be incompatible with NM setting things up and
quitting.

> > There are significant advantages to having a single code path for network
> > configuration on the system -- easier support, simpler documenation, easier
> > administration between multiple systems, easier development of new
> > distribution features overall. But the condition you give is very important
> > too -- that's why the "traditional" system is still there in parallel right
> > now.
> 
> That would be cool; I understand reducing methods reduces support
> overhead.  Please don't take my email as throwing stones; I was trying
> to _not_ do that, just point out why in some situations sysadmins
> sometimes avoid NM.

And we'd love to understand those situations and see what we can do to
make sysadmins happier with NM.  Including things like cooperating with
changes made to interfaces underneath NM, server-type config options
(locking connections via interface name, manual config updates instead
of watching files, not creating default DHCP connections for ethernet
interfaces, etc).

Dan

> I understand that the old-style network scripts are a maze of twisty
> little passages, all different, and trying to replace all the
> functionality that people use is not trivial.
> -- 
> Chris Adams 


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

Re: Minimal install diff from F16 to F19 (TC6)

[Pavel Simerda]

> From: "Chris Adams" 
> I prefer the "modern" secondaries vs. the old-style eth0:123, although I
> have run into vendor software (such as the Plesk web hosting control
> panel) that can't handle it.  I expect if that was the "one true way" in
> some future version of RHEL, they'd adapt.

AFAIK with the current kernels, the only difference between aliased and 
non-aliased secondary addresses is Netlink's 'label' attribute. If you want to 
add an address that would be seen through the alias API, you just need to 
assign it a label. With libnl3 (used by NetworkManager), this is a matter of 
computing it and assigning it via rtnl_link_set_label(). Currently we don't do 
that, as this for us this is unnecessary overhead, and as there is no known 
demand for it and also because the new-style multiple address API have been 
available for years.

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

Re: Minimal install diff from F16 to F19 (TC6)

[Reindl Harald]

Am 20.06.2013 20:01, schrieb Stephen Gallagher:
>> *do not* remove iptables.service for a lot od reason explained 
>> often enough as well as NM is utterly useless on servers and 
>> workstations with several *static* configured NIC's
> 
> 
> Mind if I ask why you think this way about NetworkManager? The NM
> currently shipping in Fedora 19 has full support for managing static
> NICs, as well as bonding, bridging and VLAN support for enterprise
> use-cases.
> 
> NetworkManager has historically been perceived as a desktop/laptop
> tool but in its current incarnation it should be usable for all but
> the most esoteric enterprise workloads

because i do *not* need it?
becuase i maintain around 30 fedora machines
because they are all wroking perfect

because it is utterly useless to have a long living process
for static basic configurations running




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

Re: Minimal install diff from F16 to F19 (TC6)

[Reindl Harald]

Am 20.06.2013 17:37, schrieb Matthew Miller:
> On Thu, Jun 20, 2013 at 05:08:48PM +0200, Reindl Harald wrote:
>>> We are on track to replace the "legacy" network and firewall init scripts
>>> with these. It's a slow track, but that's the direction
>> *do not* remove iptables.service for a lot od reason explained
>> often enough as well as NM is utterly useless on servers and
>> workstations with several *static* configured NIC's
> 
> Well, like I just said, it's a slow track. I certainly am vigorously opposed
> to removing it before the replacement has the same functionality and
> reliability

NM does not need to have functionality on servers, the opposite is true
firewalld does not need to have functionality on servers, the opposite is true

especially in case of iptables.service in fact firewalld doe snothing
else than write iptables-rules, they are written on thousands of machines
in large and over years maintained SHELL-SCRIPTS often *distributed*
over 10, 20, 30 machines with $HOSTNAME conditions

you do not need to replace this, hence iptables.service does nothing
else than load the this way written rules at startup



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

Re: Minimal install diff from F16 to F19 (TC6)

[Reindl Harald]

Am 20.06.2013 20:55, schrieb Matthew Miller:
> On Thu, Jun 20, 2013 at 01:15:37PM -0500, Chris Adams wrote:
>>> Mind if I ask why you think this way about NetworkManager? The NM
>>> currently shipping in Fedora 19 has full support for managing static
>>> NICs, as well as bonding, bridging and VLAN support for enterprise
>>> use-cases.
>> I think most "traditional" system admins see a running NM daemon as an
>> additional point of failure in a static network.  If my server's network
>> setup is static, I don't want a daemon running attempting to "manage"
>> it.  If it has a bug, gets misconfigured, etc., it might do something to
>> screw up an otherwise working setup.
> 
> Hence, the RFE -- a mode which sets up the above, and then goes away.
> 
> There are significant advantages to having a single code path for network
> configuration on the system -- easier support, simpler documenation, easier
> administration between multiple systems, easier development of new
> distribution features overall

this is simply the wrong road

why do we have multiple desktops?
why do we have a ton of text-editors?
why do we have different mail-programs?
why do we have differnet web-browsers?

because they are useful in different ways as well as configs
working since decades for network-setup and firewalling




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

Re: Minimal install diff from F16 to F19 (TC6)

[Kevin Fenzi]

On Thu, 20 Jun 2013 21:59:16 +0200
Reindl Harald  wrote:

> because i do *not* need it?
> becuase i maintain around 30 fedora machines
> because they are all wroking perfect

Thats great that that is your use case. 

Keep in mind that this list is talking about development of Fedora for
ALL the people who use it. Try and think beyond your own use cases to
what might be useful to others? 
 
> because it is utterly useless to have a long living process
> for static basic configurations running

Thus the reason for the mentioned RFE on a one-time mode that
configures and exits. 

kevin



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

Re: Minimal install diff from F16 to F19 (TC6)

[Reindl Harald]

Am 20.06.2013 22:14, schrieb Kevin Fenzi:
> On Thu, 20 Jun 2013 21:59:16 +0200
> Reindl Harald  wrote:
> 
>> because i do *not* need it?
>> becuase i maintain around 30 fedora machines
>> because they are all wroking perfect
> 
> Thats great that that is your use case. 
> 
> Keep in mind that this list is talking about development of Fedora for
> ALL the people who use it. Try and think beyond your own use cases to
> what might be useful to others? 

*where* did i say anything against others usecases?

i *only* defent the attitude "We are on track to *replace* the "legacy"
network and firewall init scripts with these", not more and not less



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

Re: Fatal PCIe error 928 on KVM GPU Passthrough

[Mario Ceresa]

Thanks Don, for your answer. How can I follow progress in this area? Is
there a mailing list, or a wiki page for that?

@Lars: I'll try the preview repo nonetheless and report the result tomorrow.

With best regards,

Mario


On 20 June 2013 16:39, Don Dutile  wrote:

> On 06/20/2013 03:27 AM, Mario Ceresa wrote:
>
>> Thanks Lars, I'll do as you suggest!
>>
>> Best,
>>
>> Mario
>>
>>
>> On 19 June 2013 23:35, Lars Seipel > lars.sei...@gmail.com>**> wrote:
>>
>> On Wed, Jun 19, 2013 at 04:42:30PM +0200, Mario Ceresa wrote:
>>  > does anybody know if it is currently possible to do GPU
>> passthrough in kvm?
>>
>>  No.  it's being worked upstream by Alex Williamson.
>
>
>  You might want to ask that on the Fedora virt list[1] or on upstream
>> libvirt's users list[2]. The chances for getting good answers should
>> be
>> much higher there.
>>
>> [1] 
>> https://admin.fedoraproject.**org/mailman/listinfo/virt
>> [2] http://libvirt.org/contact.**html
>>
>>
>>
>>
>>
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Getting rid of systemd-sysv-convert?

[Matthew Miller]

On Thu, Jun 20, 2013 at 04:17:13PM +0200, Reindl Harald wrote:
> why does *anything* still use sysv-init stuff and packages
> whichare not converted simply not dropped to wake up the
> maintainer which does *clearly* not his work?

Like. /etc/init.d/network?


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Getting rid of systemd-sysv-convert?

[Reindl Harald]

Am 20.06.2013 23:13, schrieb Matthew Miller:
> On Thu, Jun 20, 2013 at 04:17:13PM +0200, Reindl Harald wrote:
>> why does *anything* still use sysv-init stuff and packages
>> whichare not converted simply not dropped to wake up the
>> maintainer which does *clearly* not his work?
> 
> Like. /etc/init.d/network?

yes - why was such a basic service *not* a systemd-unit
at the F15 release-day?

in my understanding of develop quality software this
would not have happened and systemd at all not be
shipped as replacement until the rest of the distribution
is ready

in the meantime things are *much better* and systemd itself
has also improved a lot - but how F15/F16 in context of
systemd was released is a sign of poor or absent QA or
marketing took over becauuse "we must be first, ever"



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

Re: Getting rid of systemd-sysv-convert?

[Eric Smith]

On Thu, Jun 20, 2013 at 3:27 PM, Reindl Harald  wrote:
> yes - why was such a basic service *not* a systemd-unit
> at the F15 release-day?
>
> in my understanding of develop quality software this
> would not have happened and systemd at all not be
> shipped as replacement until the rest of the distribution
> is ready

That's one development model.  Another is to do a more gradual
transition, instead of a sharp cliff.  We could debate the relative
merits of the two models until the cows come home, but it's a moot
point as the gradual transition is what was chosen.

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

Re: Getting rid of systemd-sysv-convert?

[Jef Spaleta]

On Thu, Jun 20, 2013 at 1:43 PM, Eric Smith  wrote:
> That's one development model.  Another is to do a more gradual
> transition, instead of a sharp cliff.  We could debate the relative
> merits of the two models until the cows come home, but it's a moot
> point as the gradual transition is what was chosen.

If I provide proof that my cows have already made it home safely...
would that be sufficient to forestall further discussion along these
line?

-jef"also if you require photographic proof involving a beaten dead
horse...that can be arranged as well"spaleta
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Getting rid of systemd-sysv-convert?

[Bill Nottingham]

Reindl Harald (h.rei...@thelounge.net) said: 
> yes - why was such a basic service *not* a systemd-unit
> at the F15 release-day?

Because it's not a service in the traditional sense at all. To
move it to systemd requires one of:

- adding a minimum wrapper that just execs the same pile of shell, which
  gains you conversion for conversion's sake
- building a generator that creates ifup@.service entries which
  are then pulled into a network.target or similar... which then means
  that you get a *vastly* different service profile for the network
  script than when using NM, and is a large new paradigm for a service
  that's not the default.

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

Re: Getting rid of systemd-sysv-convert?

[Reindl Harald]

Am 21.06.2013 01:05, schrieb Bill Nottingham:
> Reindl Harald (h.rei...@thelounge.net) said: 
>> yes - why was such a basic service *not* a systemd-unit
>> at the F15 release-day?
> 
> Because it's not a service in the traditional sense at all. To
> move it to systemd requires one of:
> 
> - adding a minimum wrapper that just execs the same pile of shell, which
>   gains you conversion for conversion's sake
> - building a generator that creates ifup@.service entries which
>   are then pulled into a network.target or similar... which then means
>   that you get a *vastly* different service profile for the network
>   script than when using NM, and is a large new paradigm for a service
>   that's not the default

nobody says any of this

/etc/init.d/ should be empty, with wrappers or not, on a
distribution switching to systemd - period



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

Re: Minimal install diff from F16 to F19 (TC6)

[Adam Williamson]

On Thu, 2013-06-20 at 14:06 -0500, Chris Adams wrote:
> Once upon a time, Matthew Miller  said:
> > Hence, the RFE -- a mode which sets up the above, and then goes away.
> 
> I had not seen that mode (or a request for it).  

Matthew's post about it was precisely what kicked off this sub-thread. I
wonder if there is a theorem covering the topic of the minimum number of
messages required in a thread before one is posted which is clearly
unaware of the first one. =)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

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

Re: A need for build triggers & automatic rebuilds

[Adam Williamson]

On Wed, 2013-06-19 at 10:00 -0600, Eric Smith wrote:
> On Wed, Jun 19, 2013 at 4:23 AM, Nicolas Mailhot
>  wrote:
> > You don't need a special trigger. You need your requirements to match the
> > constraints declared at the rpm level, then incompatibilities will be
> > caught at this level by normal distro tooling.
> 
> How does that work?  A pointer to the docs is fine; My own search
> apparently hasn't turned up the right stuff.

I'm not sure I'd concur with Nicolas that our mechanisms in this area
are entirely sufficient.

If you set up your RPM dependencies to match the actual code
dependencies, then when someone submits an update for one of the
dependencies that breaks the chain, the 'depcheck' AutoQA test ought to
fail, and I think the 'updates-testing report' mail sent to this list
should highlight the issue. But neither of those are 'enforced'
mechanisms: neither would prevent the update being pushed anyway. They
are both advisory. So it would still certainly be the case that this
could wind up out of sync.

Also, putting on my Update Nerd hat for a moment, our current setup not
only *doesn't encourage* coherent Bodhi updates, it more or less
*actively discourages* them. It's very difficult for packagers to edit
each other's updates - even provenpackagers - though pp's can edit
anyone's spec file at the drop of a hat. So if someone else submits an
update for one of Eclipse's dependencies which requires Eclipse to be
updated too, it's very unlikely that the Eclipse maintainers will be
able to do a new Eclipse build and edit it into the same update. Even
though that's how it's supposed to be: updates are supposed to be
internally consistent. If A depends on B, then when B is updated in a
way that breaks A, the Bodhi update should contain builds of both A and
B. There should not be separate Bodhi updates for A and B. But it is
actually very difficult to make this happen, given the way our
permissions system and Bodhi currently work. You have to really
carefully arrange things and have a very high degree of co-operation
between the packagers of A and B: basically, you have to make sure
someone has the necessary rights to be able to submit updates for both A
and B, and no-one else ever submits updates for B, or else even that
person can't fix things. It kind of stinks.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

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

Re: Getting rid of systemd-sysv-convert?

[Adam Williamson]

On Thu, 2013-06-20 at 16:17 +0200, Reindl Harald wrote:

> i say it again:

Please, please, don't.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

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

Re: Getting rid of systemd-sysv-convert?

[Adam Williamson]

On Thu, 2013-06-20 at 23:27 +0200, Reindl Harald wrote:

> but how F15/F16 in context of
> systemd was released is a sign of poor or absent QA

Ahem. It is absolutely not QA's job to dictate strategic decisions. The
project as a whole decided that a gradual conversion from sysv to
systemd was the appropriate path. It would be entirely inappropriate for
QA to attempt to declare 'we don't care about the appropriate
decision-making processes, we are going to declare by fiat that unless
100% of sysv services are converted to systemd, Fedora 15 fails QA'.
That would be entirely unreasonable.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

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

Re: Minimal install diff from F16 to F19 (TC6)

[Chris Adams]

Once upon a time, Adam Williamson  said:
> Matthew's post about it was precisely what kicked off this sub-thread. I
> wonder if there is a theorem covering the topic of the minimum number of
> messages required in a thread before one is posted which is clearly
> unaware of the first one. =)

D'oh!  That's what I get for reading too fast.
-- 
Chris Adams 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: A need for build triggers & automatic rebuilds

[Krzysztof Daniel]

On Wed, 2013-06-19 at 12:23 +0200, Nicolas Mailhot wrote:
> Le Mer 19 juin 2013 10:07, Krzysztof Daniel a écrit :
> > Hello everyone,
> 
> > I'd like to be able to define a build trigger for Eclipse, so when a
> > "vital" dependency changes, Eclipse is rebuild, BR/R are updated, and a
> > bodhi update is performed. And I get a notification :-).
> >
> > Is there a way to do so?
> 
> You don't need a special trigger. You need your requirements to match the
> constraints declared at the rpm level, then incompatibilities will be
> caught at this level by normal distro tooling.
> 
> Regards,
> 
> -- 
> Nicolas Mailhot
> 

Not really. I can set up BR/R in two ways: 
(greater or equal) or exact match.

The problem with greater or equal is that Eclipse internally reads a
bundle manifest, and records a version, which sometimes can change after
plain rebuild (because a timestamp is added).

Plain Eclipse example:

Eclipse requires jetty, and it symlinks a jetty bundles.
 org.eclipse.jetty.http_9.0.3.v20130506.jar
-> /usr/share/java/jetty/jetty-http.jar

OSGI records that there is a file
org.eclipse.jetty.http_9.0.3.v20130506.jar that holds a plugin with
version 9.0.3.v20130506. That version goes at the build time in a couple
of places (including metabundle).

If jetty is rebuilt, and it changes let's say to 9.0.4 (minor update),
Eclipse metadata gets out of sync. Eclipse sees a jar
org.eclipse.jetty.http_9.0.3.v20130506.jar, but version inside the
manifest is 9.0.4. Since at the build time Eclipse used 9.0.3, a lot of
meta bundles will not be resolved.

At this point I can only rebuild Eclipse (yes, the build works even if
Eclipse is not working).

Exact match can't be used at all, because if jetty is updated, then it
will be impossible to install Eclipse.

-- 
Krzysztof Daniel 
Red Hat

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