RE: F21-beta issues with NetworkManager and tunX
Adam Williamson writes: > If you can pinpoint a fairly straightforward 'install, do X, and weird > thing Y happens' flow, I'd file a bug - probably against NetworkManager > indeed - with the instructions to reproduce. Thanks! I did a reinstall. And yes, NetworkManager attempts to manage the tun0 device created by OpenVPN. Here are my steps: - boot boot.iso - do absolute minimal install - login as root - yum install dnf - dnf install openvpn - nmcli the primary ethernet into a static configuration Here I encounter a weirdness, NetworkManager does not setup a default route. I manually add a default route, at which point another default route is immediately created with extra parameters "proto static metric 1024". So I delete the route I created, leaving the new one. Setup my openvpn, which creates a tun0 device and adds 0/1 and 128/1 routes by itself. However, a ip route reveals that the 0/1 route is missing. nmcli d status reports that tun0 is managed. Manually adding the 0/1 route does not stick. I close openvpn, and the tunnel. nmcli c show shows a new connection uuid for that tun0 connection. I nmcli c delete that connection. I nmcli n off, and then modify NetworkManager.conf adding no-auto-default=* and ignore-carrier=* and repeat. Same issue happens. I modify NetworkManager to add keyfile to the plugins, and a [keyfile] entry specifying tun0 as an unmanaged interface. This now gets me to the point where NetworkManager leaves tun0 alone (something I didn't have to do in F20) and my OpenVPN tunnel works. There in an issue that the reinstall process revealed. Note now, I am no longer removing ifcfg-enpXs0 and doing everything via nmcli, as opposed to before where I only used NetworkManager with the keyfile plugin and had my setup totally in system-connections. As I mentioned above, I no longer have a default route being set up. I don't know why. A full install to the gnome desktop reveals that when I login, absolutely no network icon appears in the top right, but when I add my default route (as mentioned above) a new default route is created with the exact same route and "proto static metric 1024" and immediately I see the network icon appear in the top right of my desktop. I have yet to migrate my the nmcli modified ifcfg-enpXs0 setup to my old keyfile-only setup, to see if that still causes issues with the default route, but at this point things are working, it's just that as I said, the takeaway is: NetworkManager in F21 tries to manage tunX devices, unless explicitly told not to, unlike F20. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Error: fedora-release-cloud conflicts with fedora-release-nonproduct-21-0.16.noarch
On Sat, 2014-11-22 at 21:35 +0100, poma wrote: > It seems to me that you are the only one who understands what is written > here. :) It seems to me that you can't possibly know that. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Error: fedora-release-cloud conflicts with fedora-release-nonproduct-21-0.16.noarch
On 22.11.2014 20:43, Adam Williamson wrote: > On Sat, 2014-11-22 at 20:19 +0100, Michael Schwendt wrote: >> On Sat, 22 Nov 2014 08:45:51 -0800, Adam Williamson wrote: >> I wonder whether an upgrade path from Fedora 20 could have been from fedora-release < 21 to a non-product release via a single well-defined Obsoletes instead of an arbitrary one? Why not discontinue the old fedora-release package in favour of introducing new $product specific release packages? >>> >>> Well, then you'd just have to duplicate a bunch of stuff between all the >>> product-specific packages, and it still doesn't solve this problem, >>> because anything that previously depended on fedora-release would now >>> have to depend on a virtual provide provided by any of the >>> fedora-release-(product) packages, which is...exactly what you're >>> complaining about. No? >> >> No. >> >> There would be only a single package that _replaces_ the fedora-release >> package via Obsoletes. Under the assumption that the given installation >> to be upgraded could be _anything_, sort of an unknown product or a >> non-product. >> >> You cannot upgrade that installation into a well-defined "product". You >> would need to remove anything that's not part of the new product, and if >> you don't do that, the upgrade bears the risk of running into conflicts >> (prompting the user or letting the depsolver try to be clever and likely >> need into fatal problems). > > If we wanted to do that we could have done it with the current design - > have fedora-release-nonproduct be the only package that obsoletes the > older fedora-release. Presumably it wasn't desired. > > The definition of a Product is not, at present, 'has these and only > exactly these packages installed', it's more 'has at least these > packages installed'. It's all still being figured out, but it was > considered reasonable to let people mark upgrading systems as a given > product. Though yes, there are obviously problems here, like if you > upgrade a system and mark it as 'Server' it won't necessarily get > rolekit as that's in the comps group not a dependency of the -release > package. > Yum as upgrade method may not be supported, but why do I get two fedora-release* packages for a fresh install of Fedora 21 Beta, too? >>> >>> Just sensible package splitting. All the Products are still, to some >>> extent, Fedora, and share a bunch of common 'release'-y information, >>> which is contained in fedora-release. The bits of 'release'-y >>> information that are specific to each Product are in the product >>> subpackage. >> >> Yet one could have _discontinued_ the old fedora-release package and >> moved its files into a _new_ and _non-conflicting_ *-common package. ;) > > What would have been the advantage? fedora-release doesn't conflict with > any of the product packages. The product packages conflict with each > other. I still don't see anywhere this design clearly improves on the > current one, they seem to be to be effectively identical. > It also surprises me that the "solution" that has been presented to FPC does not try to solve the conflicts at run-time. Why do the packages need to conflict? >>> >>> AIUI, this is because it was decided we don't want to try and >>> allow/support having 'multiple products installed'. >> >> Do you (or anyone else) know of a prominent place/thread where this >> design decision has been discussed? > > It was in one of the devel@ threads, I believe. They're long threads. > Why can't non-conflicting configuration files be installed into a foo.d directory with a switch to be toggled in a config file? >>> >>> The release stuff isn't just about configuration files, for a start - >>> some products at least started implementing package dependencies in >>> their -product subpackage, for instance, though that caused another >>> problem which I had some fun debugging. >> >> Which sounds like the wrong tool has been chosen for the job, *if* >> explicit (or even implicit) conflicts could not be avoided in the >> dependencies as opposed to a very few specific -product packages only. >> >> That is, fedora-release-product1 conflicting with fedora-release-product2, >> okay, two packages of the same type or purpose, but >> firewalld-config-standard conflicting with fedora-release-workstation? > > I'm not sure why it does that either. I'd think the conflict with > firewalld-config-workstation and firewalld-config-server would be > sufficient. > It seems to me that you are the only one who understands what is written here. :) -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Error: fedora-release-cloud conflicts with fedora-release-nonproduct-21-0.16.noarch
On Sat, 2014-11-22 at 20:19 +0100, Michael Schwendt wrote: > On Sat, 22 Nov 2014 08:45:51 -0800, Adam Williamson wrote: > > > > I wonder whether an upgrade path from Fedora 20 > > > could have been from fedora-release < 21 to a non-product release via a > > > single well-defined Obsoletes instead of an arbitrary one? Why not > > > discontinue > > > the old fedora-release package in favour of introducing new $product > > > specific release packages? > > > > Well, then you'd just have to duplicate a bunch of stuff between all the > > product-specific packages, and it still doesn't solve this problem, > > because anything that previously depended on fedora-release would now > > have to depend on a virtual provide provided by any of the > > fedora-release-(product) packages, which is...exactly what you're > > complaining about. No? > > No. > > There would be only a single package that _replaces_ the fedora-release > package via Obsoletes. Under the assumption that the given installation > to be upgraded could be _anything_, sort of an unknown product or a > non-product. > > You cannot upgrade that installation into a well-defined "product". You > would need to remove anything that's not part of the new product, and if > you don't do that, the upgrade bears the risk of running into conflicts > (prompting the user or letting the depsolver try to be clever and likely > need into fatal problems). If we wanted to do that we could have done it with the current design - have fedora-release-nonproduct be the only package that obsoletes the older fedora-release. Presumably it wasn't desired. The definition of a Product is not, at present, 'has these and only exactly these packages installed', it's more 'has at least these packages installed'. It's all still being figured out, but it was considered reasonable to let people mark upgrading systems as a given product. Though yes, there are obviously problems here, like if you upgrade a system and mark it as 'Server' it won't necessarily get rolekit as that's in the comps group not a dependency of the -release package. > > > Yum as upgrade method may not be supported, > > > but why do I get two fedora-release* packages for a fresh install of > > > Fedora 21 Beta, too? > > > > Just sensible package splitting. All the Products are still, to some > > extent, Fedora, and share a bunch of common 'release'-y information, > > which is contained in fedora-release. The bits of 'release'-y > > information that are specific to each Product are in the product > > subpackage. > > Yet one could have _discontinued_ the old fedora-release package and > moved its files into a _new_ and _non-conflicting_ *-common package. ;) What would have been the advantage? fedora-release doesn't conflict with any of the product packages. The product packages conflict with each other. I still don't see anywhere this design clearly improves on the current one, they seem to be to be effectively identical. > > > It also surprises me that the "solution" that has been presented to FPC > > > does not try to solve the conflicts at run-time. Why do the packages need > > > to conflict? > > > > AIUI, this is because it was decided we don't want to try and > > allow/support having 'multiple products installed'. > > Do you (or anyone else) know of a prominent place/thread where this > design decision has been discussed? It was in one of the devel@ threads, I believe. They're long threads. > > > Why can't non-conflicting configuration files be installed > > > into a foo.d directory with a switch to be toggled in a config file? > > > > The release stuff isn't just about configuration files, for a start - > > some products at least started implementing package dependencies in > > their -product subpackage, for instance, though that caused another > > problem which I had some fun debugging. > > Which sounds like the wrong tool has been chosen for the job, *if* > explicit (or even implicit) conflicts could not be avoided in the > dependencies as opposed to a very few specific -product packages only. > > That is, fedora-release-product1 conflicting with fedora-release-product2, > okay, two packages of the same type or purpose, but > firewalld-config-standard conflicting with fedora-release-workstation? I'm not sure why it does that either. I'd think the conflict with firewalld-config-workstation and firewalld-config-server would be sufficient. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Error: fedora-release-cloud conflicts with fedora-release-nonproduct-21-0.16.noarch
On Sat, 22 Nov 2014 08:45:51 -0800, Adam Williamson wrote: > > I wonder whether an upgrade path from Fedora 20 > > could have been from fedora-release < 21 to a non-product release via a > > single well-defined Obsoletes instead of an arbitrary one? Why not > > discontinue > > the old fedora-release package in favour of introducing new $product > > specific release packages? > > Well, then you'd just have to duplicate a bunch of stuff between all the > product-specific packages, and it still doesn't solve this problem, > because anything that previously depended on fedora-release would now > have to depend on a virtual provide provided by any of the > fedora-release-(product) packages, which is...exactly what you're > complaining about. No? No. There would be only a single package that _replaces_ the fedora-release package via Obsoletes. Under the assumption that the given installation to be upgraded could be _anything_, sort of an unknown product or a non-product. You cannot upgrade that installation into a well-defined "product". You would need to remove anything that's not part of the new product, and if you don't do that, the upgrade bears the risk of running into conflicts (prompting the user or letting the depsolver try to be clever and likely need into fatal problems). > > Yum as upgrade method may not be supported, > > but why do I get two fedora-release* packages for a fresh install of > > Fedora 21 Beta, too? > > Just sensible package splitting. All the Products are still, to some > extent, Fedora, and share a bunch of common 'release'-y information, > which is contained in fedora-release. The bits of 'release'-y > information that are specific to each Product are in the product > subpackage. Yet one could have _discontinued_ the old fedora-release package and moved its files into a _new_ and _non-conflicting_ *-common package. ;) > > It also surprises me that the "solution" that has been presented to FPC > > does not try to solve the conflicts at run-time. Why do the packages need > > to conflict? > > AIUI, this is because it was decided we don't want to try and > allow/support having 'multiple products installed'. Do you (or anyone else) know of a prominent place/thread where this design decision has been discussed? > > Why can't non-conflicting configuration files be installed > > into a foo.d directory with a switch to be toggled in a config file? > > The release stuff isn't just about configuration files, for a start - > some products at least started implementing package dependencies in > their -product subpackage, for instance, though that caused another > problem which I had some fun debugging. Which sounds like the wrong tool has been chosen for the job, *if* explicit (or even implicit) conflicts could not be avoided in the dependencies as opposed to a very few specific -product packages only. That is, fedora-release-product1 conflicting with fedora-release-product2, okay, two packages of the same type or purpose, but firewalld-config-standard conflicting with fedora-release-workstation? Those are troublesome conflicts. It's an attempt at trying to control what packages can be installed - something that isn't possible anyways (unless one points the products at a set of product-specific repos). > > True. I haven't found an explanation why the physical packages must > > conflict? And as above, why stuff like firewall configuration cannot be > > handled at the configuration level? Has this even be considered? > > I don't honestly recall the details of what was considered and what > wasn't, but I'll say this - most of the problems showed up as we went > along, this is one of those cases where it's really hard to think > through all the possible consequences in advance. I'd have been happier > if all this stuff had been in place by Alpha or earlier, and then we > would have more of a chance to revise/improve/fix it. Right now we're > pretty much stuck with seat-of-the-pants minimal fixes to the crap > that's in place. I'm not entirely happy with how the Product stuff was > handled either, but I don't want to crap on the people who tried their > best; I just wish it'd all been done earlier and with a more forgiving > schedule, so we had time to fix the inevitable problems as they > appeared, or change course on the design if it seemed like we were onto > a bad one. Thanks for explaining that, Adam. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
redwolfe a
http://ntkonstrukt.hu/dirdaw/rgzkmfkyiqkvvlohqrgokjqhhhppv.ulgnmzbuvenlsfvvoiqwfhcxmgeikisgpiwadq redwolfe -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Error: fedora-release-cloud conflicts with fedora-release-nonproduct-21-0.16.noarch
On Sat, 2014-11-22 at 13:01 +0100, Michael Schwendt wrote: > On Fri, 21 Nov 2014 10:07:32 -0800, Adam Williamson wrote: > > > Well, you're never supposed to be in a case where you're relying on yum > > to solve it without any hints, it's not really 'random'. > > Yum is known for pulling in "odd packages" for the case of a dependency > where "any provider suffices". Originally, it had been "shorted %name > wins", but even the developers on certain occasions told that it is not as > simple as that. Dunno what it's like nowadays. It has lead to breakage > several times, because behaviour changed, and users+packager could not > rely on a "yum install ..." to pull in a predictable set of packages. > > Anyway, one can read it is being worked on within DNF and/or RPM. Yes, I know that. What I'm saying is that you should rarely be in the case where yum is just trying to solve a requirement for 'system-release-product' without any other information. The intent is that in all the commonly-encountered cases where the dependency is encountered, the transaction will already include a specific product package, as I explained in quite a bit of detail in the initial post. > > On new installs > > you have to pick an environment group, and every environment group > > requires a specific product package (custom kickstarts that don't use > > one of the environment groups or explicitly specify a product package > > will wind up with the 'default' resolution, but that's a bit of a corner > > case). For upgrades, fedup requires you to pick one. > > This concept of "switching products" sounds strange with regard to > Upgrades from Fedora 20 or older. Before, users could install anything > (not "everything" because of too many conflicts : > http://smoogespace.blogspot.de/2011/05/doing-everything-install.html ) > which made the install result in something that does not closely resemble > one of the new products. If your install doesn't closely resemble any of the products, then it seems obvious to choose 'nonproduct' as your 'product' package on upgrade. > I wonder whether an upgrade path from Fedora 20 > could have been from fedora-release < 21 to a non-product release via a > single well-defined Obsoletes instead of an arbitrary one? Why not discontinue > the old fedora-release package in favour of introducing new $product > specific release packages? Well, then you'd just have to duplicate a bunch of stuff between all the product-specific packages, and it still doesn't solve this problem, because anything that previously depended on fedora-release would now have to depend on a virtual provide provided by any of the fedora-release-(product) packages, which is...exactly what you're complaining about. No? > Yum as upgrade method may not be supported, > but why do I get two fedora-release* packages for a fresh install of > Fedora 21 Beta, too? Just sensible package splitting. All the Products are still, to some extent, Fedora, and share a bunch of common 'release'-y information, which is contained in fedora-release. The bits of 'release'-y information that are specific to each Product are in the product subpackage. > It also surprises me that the "solution" that has been presented to FPC > does not try to solve the conflicts at run-time. Why do the packages need > to conflict? AIUI, this is because it was decided we don't want to try and allow/support having 'multiple products installed'. > Why can't non-conflicting configuration files be installed > into a foo.d directory with a switch to be toggled in a config file? The release stuff isn't just about configuration files, for a start - some products at least started implementing package dependencies in their -product subpackage, for instance, though that caused another problem which I had some fun debugging. > True. I haven't found an explanation why the physical packages must > conflict? And as above, why stuff like firewall configuration cannot be > handled at the configuration level? Has this even be considered? I don't honestly recall the details of what was considered and what wasn't, but I'll say this - most of the problems showed up as we went along, this is one of those cases where it's really hard to think through all the possible consequences in advance. I'd have been happier if all this stuff had been in place by Alpha or earlier, and then we would have more of a chance to revise/improve/fix it. Right now we're pretty much stuck with seat-of-the-pants minimal fixes to the crap that's in place. I'm not entirely happy with how the Product stuff was handled either, but I don't want to crap on the people who tried their best; I just wish it'd all been done earlier and with a more forgiving schedule, so we had time to fix the inevitable problems as they appeared, or change course on the design if it seemed like we were onto a bad one. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net ht
Fedora 20 updates-testing report
The following Fedora 20 Security updates need testing: Age URL 50 https://admin.fedoraproject.org/updates/FEDORA-2014-11969/krb5-1.11.5-16.fc20 8 https://admin.fedoraproject.org/updates/FEDORA-2014-14791/mariadb-galera-5.5.40-2.fc20 7 https://admin.fedoraproject.org/updates/FEDORA-2014-15108/mantis-1.2.17-4.fc20 7 https://admin.fedoraproject.org/updates/FEDORA-2014-14963/avr-binutils-2.24-3.fc20 7 https://admin.fedoraproject.org/updates/FEDORA-2014-15102/moodle-2.5.9-1.fc20 7 https://admin.fedoraproject.org/updates/FEDORA-2014-14833/arm-none-eabi-binutils-cs-2014.05.28-3.fc20 7 https://admin.fedoraproject.org/updates/FEDORA-2014-15130/kwebkitpart-1.3.4-5.fc20 4 https://admin.fedoraproject.org/updates/FEDORA-2014-15244/wireshark-1.10.11-1.fc20 4 https://admin.fedoraproject.org/updates/FEDORA-2014-15266/python-django14-1.4.16-1.fc20 2 https://admin.fedoraproject.org/updates/FEDORA-2014-15371/rubygem-actionpack-4.0.0-5.fc20 2 https://admin.fedoraproject.org/updates/FEDORA-2014-15393/lsyncd-2.1.4-4.fc20.1 2 https://admin.fedoraproject.org/updates/FEDORA-2014-15379/nodejs-0.10.33-1.fc20,libuv-0.10.29-1.fc20 2 https://admin.fedoraproject.org/updates/FEDORA-2014-15394/erlang-R16B-03.9.fc20 1 https://admin.fedoraproject.org/updates/FEDORA-2014-15464/python-eyed3-0.7.4-4.fc20 1 https://admin.fedoraproject.org/updates/FEDORA-2014-15489/rubygem-sprockets-2.8.2-5.fc20 0 https://admin.fedoraproject.org/updates/FEDORA-2014-15521/xen-4.3.3-5.fc20 0 https://admin.fedoraproject.org/updates/FEDORA-2014-15541/tcpdump-4.5.1-2.fc20 0 https://admin.fedoraproject.org/updates/FEDORA-2014-15519/drupal6-6.34-1.fc20 0 https://admin.fedoraproject.org/updates/FEDORA-2014-15528/drupal7-7.34-1.fc20 0 https://admin.fedoraproject.org/updates/FEDORA-2014-15538/phpMyAdmin-4.2.12-1.fc20 0 https://admin.fedoraproject.org/updates/FEDORA-2014-15532/kde-runtime-4.14.3-2.fc20 0 https://admin.fedoraproject.org/updates/FEDORA-2014-15507/wordpress-4.0.1-1.fc20 The following Fedora 20 Critical Path updates have yet to be approved: Age URL 8 https://admin.fedoraproject.org/updates/FEDORA-2014-15054/perl-Pod-Usage-1.64-2.fc20,perl-Pod-Checker-1.60-292.fc20 8 https://admin.fedoraproject.org/updates/FEDORA-2014-14798/device-mapper-persistent-data-0.4.1-2.fc20 8 https://admin.fedoraproject.org/updates/FEDORA-2014-14964/libtdb-1.3.1-1.fc20 8 https://admin.fedoraproject.org/updates/FEDORA-2014-14861/libpipeline-1.2.4-3.fc20 7 https://admin.fedoraproject.org/updates/FEDORA-2014-15120/dosfstools-3.0.27-1.fc20 4 https://admin.fedoraproject.org/updates/FEDORA-2014-15326/pycairo-1.10.0-1.fc20 0 https://admin.fedoraproject.org/updates/FEDORA-2014-15552/selinux-policy-3.12.1-195.fc20 0 https://admin.fedoraproject.org/updates/FEDORA-2014-15523/gdb-7.7.1-22.fc20 0 https://admin.fedoraproject.org/updates/FEDORA-2014-15533/ca-certificates-2014.2.1-1.5.fc20 0 https://admin.fedoraproject.org/updates/FEDORA-2014-15501/v4l-utils-1.6.0-2.fc20 The following builds have been pushed to Fedora 20 updates-testing ampr-ripd-1.13-1.fc20 ca-certificates-2014.2.1-1.5.fc20 clementine-1.2.3-2.fc20 dnf-langpacks-0.5.1-1.fc20 drupal6-6.34-1.fc20 drupal7-7.34-1.fc20 edg-mkgridmap-4.0.0-8.fc20 gdb-7.7.1-22.fc20 golang-github-emicklei-go-restful-0-0.1.gitad99b12.fc20 golang-github-vishvananda-netlink-0-0.1.git2187ba6.fc20 golang-github-vishvananda-netns-0-0.1.gite14a2d4.fc20 gr-rds-0-0.4.20141117gitff1ca15.fc20 kde-runtime-4.14.3-2.fc20 libechonest-2.3.0-1.fc20 lucene++-3.0.6-1.fc20 mate-themes-1.9.2-1.fc20 nano-2.3.2-5.fc20 nodejs-filelist-0.0.3-1.fc20 nodejs-json-localizer-0.0.2-1.fc20 openvpn-2.3.2-7.fc20 packagedb-cli-2.6-1.fc20 perl-Data-Munge-0.091-1.fc20 perl-File-ConfigDir-0.014-1.fc20 perl-HTML-Mason-1.56-1.fc20 perl-Net-SMTPS-0.04-1.fc20 perl-Sub-Exporter-ForMethods-0.100051-1.fc20 php-5.5.19-3.fc20 php-psr-http-message-0.5.1-1.fc20 php-symfony-2.5.7-1.fc20 phpMyAdmin-4.2.12-1.fc20 pidgin-2.10.10-3.fc20 privoxy-3.0.22-1.fc20 python-copr-1.54-1.fc20 python-docker-py-0.6.0-1.fc20 python-fedmsg-meta-fedora-infrastructure-0.3.6-1.fc20 qpid-dispatch-0.2-9.fc20 selinux-policy-3.12.1-195.fc20 tcpdump-4.5.1-2.fc20 tomahawk-0.8.2-1.fc20 tzdata-2014j-1.fc20 v4l-utils-1.6.0-2.fc20 vtun-3.0.3-10.fc20 websocketpp-0.4.0-2.fc20 wmx-8-1.fc20 wordpress-4.0.1-1.fc20 xen-4.3.3-5.fc20 xfce4-systemload-plugin-1.1.2-1.fc20 xscreensaver-5.32-1.fc20 Details about builds: ampr-ripd-1.13-1.fc20 (FEDORA-2014-15551) Routing daemon for the ampr network Update Information: This is new version
Fedora 19 updates-testing report
The following Fedora 19 Security updates need testing: Age URL 392 https://admin.fedoraproject.org/updates/FEDORA-2013-19963/openstack-glance-2013.1.4-1.fc19 204 https://admin.fedoraproject.org/updates/FEDORA-2014-5896/nrpe-2.15-2.fc19 155 https://admin.fedoraproject.org/updates/FEDORA-2014-7496/readline-6.2-8.fc19 72 https://admin.fedoraproject.org/updates/FEDORA-2014-10640/libreoffice-4.1.6.2-8.fc19 50 https://admin.fedoraproject.org/updates/FEDORA-2014-12057/krb5-1.11.3-29.fc19 36 https://admin.fedoraproject.org/updates/FEDORA-2014-13018/deluge-1.3.10-1.fc19 26 https://admin.fedoraproject.org/updates/FEDORA-2014-13551/wpa_supplicant-2.0-12.fc19 17 https://admin.fedoraproject.org/updates/FEDORA-2014-14237/claws-mail-plugins-3.11.1-1.fc19,claws-mail-3.11.1-2.fc19,libetpan-1.6-1.fc19 15 https://admin.fedoraproject.org/updates/FEDORA-2014-14359/curl-7.29.0-25.fc19 10 https://admin.fedoraproject.org/updates/FEDORA-2014-14738/gnutls-3.1.20-6.fc19 8 https://admin.fedoraproject.org/updates/FEDORA-2014-12407/sddm-0.10.0-2.fc19 7 https://admin.fedoraproject.org/updates/FEDORA-2014-15079/mantis-1.2.17-4.fc19 7 https://admin.fedoraproject.org/updates/FEDORA-2014-14874/arm-none-eabi-binutils-cs-2014.05.28-3.fc19 7 https://admin.fedoraproject.org/updates/FEDORA-2014-14838/avr-binutils-2.24-3.fc19 7 https://admin.fedoraproject.org/updates/FEDORA-2014-15124/kwebkitpart-1.3.4-5.fc19 5 https://admin.fedoraproject.org/updates/FEDORA-2014-15202/kernel-3.14.24-100.fc19 4 https://admin.fedoraproject.org/updates/FEDORA-2014-15248/kde-runtime-4.11.5-3.fc19 4 https://admin.fedoraproject.org/updates/FEDORA-2014-15307/python-django14-1.4.16-1.fc19 2 https://admin.fedoraproject.org/updates/FEDORA-2014-15373/lsyncd-2.1.4-4.fc19.1 2 https://admin.fedoraproject.org/updates/FEDORA-2014-15378/rubygem-actionpack-3.2.13-7.fc19 2 https://admin.fedoraproject.org/updates/FEDORA-2014-15390/nodejs-0.10.33-1.fc19,libuv-0.10.29-1.fc19 2 https://admin.fedoraproject.org/updates/FEDORA-2014-15405/wget-1.16-3.fc19 1 https://admin.fedoraproject.org/updates/FEDORA-2014-15466/rubygem-sprockets-2.8.2-4.fc19 1 https://admin.fedoraproject.org/updates/FEDORA-2014-15477/python-eyed3-0.7.4-4.fc19 1 https://admin.fedoraproject.org/updates/FEDORA-2014-15463/clamav-0.98.5-1.fc19 0 https://admin.fedoraproject.org/updates/FEDORA-2014-15526/wordpress-4.0.1-1.fc19 0 https://admin.fedoraproject.org/updates/FEDORA-2014-15503/xen-4.2.5-5.fc19 0 https://admin.fedoraproject.org/updates/FEDORA-2014-15549/tcpdump-4.4.0-4.fc19 0 https://admin.fedoraproject.org/updates/FEDORA-2014-15515/drupal6-6.34-1.fc19 0 https://admin.fedoraproject.org/updates/FEDORA-2014-15522/drupal7-7.34-1.fc19 0 https://admin.fedoraproject.org/updates/FEDORA-2014-15535/phpMyAdmin-4.2.12-1.fc19 The following Fedora 19 Critical Path updates have yet to be approved: Age URL 340 https://admin.fedoraproject.org/updates/FEDORA-2013-22326/fedora-bookmarks-15-5.fc19 266 https://admin.fedoraproject.org/updates/FEDORA-2014-3245/testdisk-6.14-2.fc19.1,ntfs-3g-2014.2.15-1.fc19 12 https://admin.fedoraproject.org/updates/FEDORA-2014-14516/pcre-8.32-11.fc19 12 https://admin.fedoraproject.org/updates/FEDORA-2014-14505/unzip-6.0-12.fc19 10 https://admin.fedoraproject.org/updates/FEDORA-2014-14738/gnutls-3.1.20-6.fc19 8 https://admin.fedoraproject.org/updates/FEDORA-2014-15032/man-db-2.6.3-9.fc19 8 https://admin.fedoraproject.org/updates/FEDORA-2014-15027/evolution-data-server-3.8.5-7.fc19 8 https://admin.fedoraproject.org/updates/FEDORA-2014-14807/device-mapper-persistent-data-0.4.1-2.fc19 8 https://admin.fedoraproject.org/updates/FEDORA-2014-14846/pciutils-3.3.0-1.fc19 5 https://admin.fedoraproject.org/updates/FEDORA-2014-15202/kernel-3.14.24-100.fc19 2 https://admin.fedoraproject.org/updates/FEDORA-2014-15392/kde-workspace-4.11.14-2.fc19 2 https://admin.fedoraproject.org/updates/FEDORA-2014-15377/gvfs-1.16.4-3.fc19 0 https://admin.fedoraproject.org/updates/FEDORA-2014-15506/ca-certificates-2014.2.1-1.5.fc19 The following builds have been pushed to Fedora 19 updates-testing amanda-3.3.3-7.fc19 ca-certificates-2014.2.1-1.5.fc19 drupal6-6.34-1.fc19 drupal7-7.34-1.fc19 edg-mkgridmap-4.0.0-8.fc19 mate-themes-1.9.2-1.fc19 packagedb-cli-2.6-1.fc19 perl-HTML-Mason-1.56-1.fc19 perl-Sub-Exporter-ForMethods-0.100051-1.fc19 php-5.5.19-3.fc19 phpMyAdmin-4.2.12-1.fc19 privoxy-3.0.22-1.fc19 python-copr-1.54-1.fc19 python-fedmsg-meta-fedora-infrastructure-0.3.6-1.fc19 qpid-dispatch-0.2-9.fc19 tcpdump-4.4.0-4.fc19 tzdata-2014j-1.fc19 wordpress-4.0.1-1.fc19 xen-4.2.5-5.fc19 Details about builds: amanda-3.3.3-7.fc19 (FEDORA-2014-15498) A network-capable tape backup soluti
Re: Error: fedora-release-cloud conflicts with fedora-release-nonproduct-21-0.16.noarch
On Fri, 21 Nov 2014 10:07:32 -0800, Adam Williamson wrote: > Well, you're never supposed to be in a case where you're relying on yum > to solve it without any hints, it's not really 'random'. Yum is known for pulling in "odd packages" for the case of a dependency where "any provider suffices". Originally, it had been "shorted %name wins", but even the developers on certain occasions told that it is not as simple as that. Dunno what it's like nowadays. It has lead to breakage several times, because behaviour changed, and users+packager could not rely on a "yum install ..." to pull in a predictable set of packages. Anyway, one can read it is being worked on within DNF and/or RPM. > On new installs > you have to pick an environment group, and every environment group > requires a specific product package (custom kickstarts that don't use > one of the environment groups or explicitly specify a product package > will wind up with the 'default' resolution, but that's a bit of a corner > case). For upgrades, fedup requires you to pick one. This concept of "switching products" sounds strange with regard to Upgrades from Fedora 20 or older. Before, users could install anything (not "everything" because of too many conflicts : http://smoogespace.blogspot.de/2011/05/doing-everything-install.html ) which made the install result in something that does not closely resemble one of the new products. I wonder whether an upgrade path from Fedora 20 could have been from fedora-release < 21 to a non-product release via a single well-defined Obsoletes instead of an arbitrary one? Why not discontinue the old fedora-release package in favour of introducing new $product specific release packages? Yum as upgrade method may not be supported, but why do I get two fedora-release* packages for a fresh install of Fedora 21 Beta, too? Sure, it's too late now. It just surprises me what has been come up with: https://fedorahosted.org/fpc/ticket/446 | Both yum and DNF have issues with handling Conflicts: at the | appropriate phase of dependency-checking. As a result, we need [...] which adds lots of explicit Conflicts, which are hard to handle. Adding more Conflicts is like "admitting defeat". https://fedorahosted.org/fpc/ticket/92 | Error: generic-release conflicts with fedora-release-14-1.noarch | | Proposal to relax Conflicts is rejected. It also surprises me that the "solution" that has been presented to FPC does not try to solve the conflicts at run-time. Why do the packages need to conflict? Why can't non-conflicting configuration files be installed into a foo.d directory with a switch to be toggled in a config file? > It's all very well to point at the problems and say it's bad, but no-one > came up with anything *better*. All the work on this Product stuff was > done in public, on devel@ and in bug reports and FESCo tickets and so > on. The people who did the work did the best they could; there are > various places where the result has issues, but it's a hard thing to do. Hard to comment on. I may have noticed threads such as https://lists.fedoraproject.org/pipermail/devel/2014-July/200972.html but missed the step where/when something was considered the way to go. > It's easy to just say it "should have been avoided", but it doesn't > really help anyone. If you have a concrete suggestion as to how to > implement the Product design without this problem, *that* would help (of > course, it would've helped more six months ago, when all this stuff > should really have been worked out). True. I haven't found an explanation why the physical packages must conflict? And as above, why stuff like firewall configuration cannot be handled at the configuration level? Has this even be considered? -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
F-21 Branched report: 20141122 changes
Compose started at Sat Nov 22 07:15:03 UTC 2014 Broken deps for armhfp -- [avro] avro-mapred-1.7.5-9.fc21.noarch requires hadoop-mapreduce avro-mapred-1.7.5-9.fc21.noarch requires hadoop-client [gearbox] gearbox-10.11-8.fc21.armv7hl requires libIceUtil.so.35 gearbox-10.11-8.fc21.armv7hl requires ice gearbox-devel-10.11-8.fc21.armv7hl requires ice-devel [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0 [openstack-nova] openstack-nova-compute-2014.1.2-1.fc21.noarch requires libvirt-daemon-xen [ostree] ostree-grub2-2014.11-1.fc21.armv7hl requires grub2 [spring-maps-default] spring-maps-default-0.1-12.fc21.noarch requires spring [syntastic] syntastic-d-3.5.0-1.fc21.noarch requires ldc Broken deps for i386 -- [gearbox] gearbox-10.11-8.fc21.i686 requires libIceUtil.so.35 gearbox-10.11-8.fc21.i686 requires ice gearbox-devel-10.11-8.fc21.i686 requires ice-devel [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0 Broken deps for x86_64 -- [gearbox] gearbox-10.11-8.fc21.i686 requires libIceUtil.so.35 gearbox-10.11-8.fc21.i686 requires ice gearbox-10.11-8.fc21.x86_64 requires libIceUtil.so.35()(64bit) gearbox-10.11-8.fc21.x86_64 requires ice gearbox-devel-10.11-8.fc21.i686 requires ice-devel gearbox-devel-10.11-8.fc21.x86_64 requires ice-devel [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0 Updated Packages: fedora-logos-21.0.5-1.fc21 -- * Wed Nov 19 2014 Tom Callaway - 21.0.5-1 - add fedora logo for background overlay - move anaconda logo files into hicolor (drop old "Fedora" dir) - add anaconda theme art for "no product", workstation, server, cloud Size change: 1296738 bytes fedora-release-21-1 --- * Tue Nov 18 2014 Dennis Gilmore - 21-1 - drop Require on system-release-product rhbz#1156198 - prep for f21 GA Size change: 155 bytes fedora-repos-21-1 - * Tue Nov 18 2014 Dennis Gilmore 21-1 - drop no longer needed fedora-repos-anaconda sup-package - disable updates-testing - turn on 7 day metadata expire for the fedora repo Size change: -32 bytes pulseaudio-5.0-25.fc21 -- * Fri Nov 14 2014 Rex Dieter 5.0-25 - pull in wtay bluez5/HSP fixes on top of stock pa-5.0 (#1045548) * Fri Nov 14 2014 Rex Dieter 5.0-11 - %pre: redo pulse-rt group fix Size change: 34068 bytes seahorse-3.14.0-3.fc21 -- * Thu Nov 20 2014 Kalev Lember - 3.14.0-3 - Fix SSH key generation (#1163660) Size change: 2548 bytes virt-manager-1.1.0-4.git310f6527.fc21 - * Sun Nov 16 2014 Cole Robinson - 1.1.0-4.git310f6527 - Fix crash when rebooting VMs after install (bz #1135546) - Fix dep on libosinfo (bz #1159370) - Fix PCI/USB hotplug (bz #1146297) Size change: 2673 bytes Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 6 Size of added packages: 0 (0 ) Size change of modified packages: 1336150 (1.3 M) Size of removed packages: 0 (0 ) Size change: 1336150 (1.3 M) Compose finished at Sat Nov 22 11:35:54 UTC 2014 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
rawhide report: 20141122 changes
Compose started at Sat Nov 22 05:15:03 UTC 2014 Broken deps for i386 -- [3Depict] 3Depict-0.0.16-3.fc22.i686 requires libmgl.so.7.2.0 [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [cab] cab-0.1.9-12.fc22.i686 requires cabal-dev [condor] condor-plumage-8.1.4-7.a1a7df5.fc22.i686 requires libmongoclient.so [dnssec-check] dnssec-check-1.14.0.1-4.fc20.i686 requires libval-threads.so.14 dnssec-check-1.14.0.1-4.fc20.i686 requires libsres.so.14 [glances] glances-2.1.2-2.fc22.noarch requires python-psutil >= 0:2.0.0 [nwchem] nwchem-openmpi-6.3.2-11.fc21.i686 requires libmpi_usempi.so.1 [python-selenium] python3-selenium-2.43.0-1.fc22.noarch requires python3-rdflib [shogun] shogun-doc-3.2.0.1-0.27.git20140804.96f3cf3.fc22.noarch requires shogun-data = 0:0.8.1-0.18.git20140804.48a1abb.fc22 [uwsgi] uwsgi-plugin-gridfs-2.0.7-2.fc22.i686 requires libmongoclient.so uwsgi-stats-pusher-mongodb-2.0.7-2.fc22.i686 requires libmongoclient.so [vfrnav] vfrnav-20140510-2.fc22.i686 requires libpolyclipping.so.16 vfrnav-utils-20140510-2.fc22.i686 requires libpolyclipping.so.16 Broken deps for x86_64 -- [3Depict] 3Depict-0.0.16-3.fc22.x86_64 requires libmgl.so.7.2.0()(64bit) [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [cab] cab-0.1.9-12.fc22.x86_64 requires cabal-dev [condor] condor-plumage-8.1.4-7.a1a7df5.fc22.x86_64 requires libmongoclient.so()(64bit) [dnssec-check] dnssec-check-1.14.0.1-4.fc20.x86_64 requires libval-threads.so.14()(64bit) dnssec-check-1.14.0.1-4.fc20.x86_64 requires libsres.so.14()(64bit) [glances] glances-2.1.2-2.fc22.noarch requires python-psutil >= 0:2.0.0 [nwchem] nwchem-openmpi-6.3.2-11.fc21.x86_64 requires libmpi_usempi.so.1()(64bit) [python-selenium] python3-selenium-2.43.0-1.fc22.noarch requires python3-rdflib [shogun] shogun-doc-3.2.0.1-0.27.git20140804.96f3cf3.fc22.noarch requires shogun-data = 0:0.8.1-0.18.git20140804.48a1abb.fc22 [uwsgi] uwsgi-plugin-gridfs-2.0.7-2.fc22.x86_64 requires libmongoclient.so()(64bit) uwsgi-stats-pusher-mongodb-2.0.7-2.fc22.x86_64 requires libmongoclient.so()(64bit) [vfrnav] vfrnav-20140510-2.fc22.i686 requires libpolyclipping.so.16 vfrnav-20140510-2.fc22.x86_64 requires libpolyclipping.so.16()(64bit) vfrnav-utils-20140510-2.fc22.x86_64 requires libpolyclipping.so.16()(64bit) Broken deps for armhfp -- [3Depict] 3Depict-0.0.16-3.fc22.armv7hl requires libmgl.so.7.2.0 [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [avro] avro-mapred-1.7.5-9.fc22.noarch requires hadoop-mapreduce avro-mapred-1.7.5-9.fc22.noarch requires hadoop-client [cab] cab-0.1.9-12.fc22.armv7hl requires cabal-dev [calamares] calamares-0-0.16.20141119git01c3244396f35.fc22.armv7hl requires grub2 [condor] condor-plumage-8.1.4-7.a1a7df5.fc22.armv7hl requires libmongoclient.so [dnssec-check] dnssec-check-1.14.0.1-4.fc20.armv7hl requires libval-threads.so.14 dnssec-check-1.14.0.1-4.fc20.armv7hl requires libsres.so.14 [glances] glances-2.1.2-2.fc22.noarch requires python-psutil >= 0:2.0.0 [ostree] ostree-grub2-2014.11-1.fc22.armv7hl requires grub2 [python-selenium] python3-selenium-2.43.0-1.fc22.noarch requires python3-rdflib [scirenderer] scirenderer-1.1.0-4.fc22.noarch requires jogl2 [shogun] shogun-doc-3.2.0.1-0.27.git20140804.96f3cf3.fc22.noarch requires shogun-data = 0:0.8.1-0.18.git20140804.48a1abb.fc22 [spring-maps-default] spring-maps-default-0.1-12.fc21.noarch requires spring [syntastic] syntastic-d-3.5.0-1.fc22.noarch requires ldc [uwsgi] uwsgi-plugin-gridfs-2.0.7-2.fc22.armv7hl requires libmongoclient.so uwsgi-stats-pusher-mongodb-2.0.7-2.fc22.armv7hl requires libmongoclient.so [vfrnav] vfrnav-20140510-2.fc22.armv7hl requires libpolyclipping.so.16 vfrnav-utils-20140510-2.fc22.armv7hl requires libpolyclipping.so.16 New package: golang-github-vishvananda-netlink-0-0.1.git2187ba6.fc22 Simple netlink library for go New package: golang-github-vishvananda-netns-0-0.1.gite14a2d4.fc22 Simple network namespace handling for go New package: python-cryptography-0.6.1-2.fc22 PyCA's cryptography library New package: timedatex-0.1-1.fc22 D-Bus service for system clock and RTC settings Updated Packages: amanda-3.3.6-9.fc22 --- * Fri Nov 21 2014 Petr Hracek - 3.3.6-9 - inlude unit files for systemd * Fri Nov 21 2014 Petr Hracek - 3.3.6-8 - add kamanda unit files (#1077642) Size change: 522 bytes ampr-
Bug 1118446 - wrong colour, instead of turquoise printing blue
Hi, still I can not print fotos with my Canon Pixma MP540 (F21 Final TC2, cups-gutenprint). Reason: Blue colours are printed not according to the fotos. This problem is reported and discussed in open Bug 1118446. Are there more printers showing similar problems, or is this only the problem of some Canon printers? Kind Regards -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
[Test-Announce] Fedora 21 Final Test Compose 3 (TC3) Available Now!
As per the Fedora 21 schedule [1], Fedora 21 Final Test Compose 3 (TC3) is now available for testing. Content information, including changes, can be found at https://fedorahosted.org/rel-eng/ticket/6031#comment:10 . Please see the following pages for download links (including delta ISOs) and testing instructions. Normally dl.fedoraproject.org should provide the fastest download, but download-ib01.fedoraproject.org is available as a mirror (with an approximately 1 hour lag) in case of trouble. To use it, just replace "dl" with "download-ib01" in the download URL. Installation: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test Base: https://fedoraproject.org/wiki/Test_Results:Current_Base_Test Workstation and Desktop: https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test Server: https://fedoraproject.org/wiki/Test_Results:Current_Server_Test Cloud: https://fedoraproject.org/wiki/Test_Results:Current_Cloud_Test Summary: https://fedoraproject.org/wiki/Test_Results:Current_Summary Ideally, all Alpha, Beta, and Final priority test cases for each of these test pages [2] should pass in order to meet the Final Release Criteria [3]. Help is available on #fedora-qa on irc.freenode.net [4], or on the test list [5]. Create Fedora 21 Final test compose (TC) and release candidate (RC) https://fedorahosted.org/rel-eng/ticket/6031 Current Blocker and Freeze Exception bugs: http://qa.fedoraproject.org/blockerbugs/current [1] http://fedorapeople.org/groups/schedule/f-21/f-21-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan [3] https://fedoraproject.org/wiki/Fedora_21_Final_Release_Criteria [4] irc://irc.freenode.net/fedora-qa [5] https://admin.fedoraproject.org/mailman/listinfo/test signature.asc Description: OpenPGP digital signature ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce-- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
