Re: F21 Self Contained Change: SDDM as the default KDE display manager instead of KDM
On 2014-04-14, Jaroslav Reznik jrez...@redhat.com wrote: = Proposed Self Contained Change: SDDM as the default KDE display manager instead of KDM = https://fedoraproject.org/wiki/Changes/SDDMinsteadOfKDM Is the SDDM mature enough to replace more-or-less working KDM? I ask because there has not been a release yet (the one year old 0.1.0 was just a payground snapshot). Even such fundamental thing like user authentication is unfinished (use `getpwent()` instead of reading from `/etc/passwd` https://github.com/sddm/sddm/issues/123). -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Taking ownership of ddclient
ddclient is currently orphaned in Fedora since 2013-10-21. If no one else steps up, I offer to take ownership as I use this program daily and already maintain a small number of packages for Fedora. Kind regards, Tilmann -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Problem while building with copr (failing for no apparent reason)
Hi, I am using copr to build another candidate for lyx-2.1 and the build fails for me with no message related with the failure: http://copr.fedoraproject.org/coprs/jamatos/lyx-21/builds/ The only file I get is in this case build-9287.log that is useless. I have built the package locally on mock I have no problems building it. Regards, -- José Abílio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: SDDM as the default KDE display manager instead of KDM
On 14 April 2014 14:40, Jaroslav Reznik jrez...@redhat.com wrote: = Proposed Self Contained Change: SDDM as the default KDE display manager instead of KDM = https://fedoraproject.org/wiki/Changes/SDDMinsteadOfKDM Change owner(s): Martin Briza mbr...@redhat.com KDE SIG Retire KDM as the default display manager of the KDE Fedora Spin in favor of SDDM. == Detailed Description == As described in many articles and discussions, KDM is nearing its end of life and it's time we decided upon the successor. I'm proposing to switch to SDDM, which is a new project that suits our needs perfectly despite its immaturity: As of July 2013, KDM's maintenance consists of bugfixes for the most painful bugs, consisting of only about 20 actual commits to the repository in last two years (excluding translation, themes and merges), adding many new features would require major changes to a lot of the code and there is no active maintainer. SDDM is written in C++11/Qt5 (compared to the bits of XDM in KDM), compilable against Qt4, supports QtQuick theming and its upstream is quite active. Compared to the current DM, KDM, it currently lacks a few features (such as XDMCP) but adds some other ones (QtQuick themes) or is currently adding them (Keyboard layout switching in the greeter). == Scope == * Proposal owners: ** Create sddm and sddm-kcm packages. ** Change kde-settings and the spin-kickstarts to provide SDDM package instead of KDM ** (eventually) exclude KDM from the kde-workspace package * Other developers: N/A (not a System Wide Change) * Release engineering: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) ___ Does scope need to include a specific plan to deal with this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1034414 since failure to login is worse than any bug in KDM? -- imalone http://ibmalone.blogspot.co.uk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Orphaning java-1.5.0-gcj
Ok the patch worked fine for building on my F20, which I did as a test, however it failed the build in rawhide. The only clue I can get is this: configure: WARNING: unable to include jni.h What's in the configure log file regarding this? This is solved now, AFAIK. The configure script had some custom code to detect Java version by parsing output of java -version, which didn't work because OpenJDK = 8 has slightly different output format. An analogous change was needed in javapackages: https://github.com/mizdebsk/javapackages/commit/494fea0 -- Mikolaj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: SDDM as the default KDE display manager instead of KDM
On Mon, 14 Apr 2014 16:45:25 +0200, Josh Boyer jwbo...@fedoraproject.org wrote: On Mon, Apr 14, 2014 at 9:40 AM, Jaroslav Reznik jrez...@redhat.com wrote: = Proposed Self Contained Change: SDDM as the default KDE display manager instead of KDM = https://fedoraproject.org/wiki/Changes/SDDMinsteadOfKDM Change owner(s): Martin Briza mbr...@redhat.com KDE SIG Retire KDM as the default display manager of the KDE Fedora Spin in favor of SDDM. snip == Scope == * Proposal owners: ** Create sddm and sddm-kcm packages. ** Change kde-settings and the spin-kickstarts to provide SDDM package instead of KDM ** (eventually) exclude KDM from the kde-workspace package Could you elaborate how this would impact using GDM to boot into a KDE session? From a packaging perspective, would KDE now Require SDDM or would it be possible to install it without having SDDM installed? josh KDE itself doesn't require a specific DM, any DM is fine. There is no impact on GDM. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Ruby193 in SCL
Dne 15.4.2014 02:07, T.C. Hollingsworth napsal(a): On Mon, Apr 14, 2014 at 7:16 AM, Jaroslav Reznik jrez...@redhat.com wrote: Rails depends on exact v8 version, which means v8 3.14 must have also their own SCL as part of the SCL. Stupid question: what in rails depends on v8 exactly? The only thing that Requires v8 in Fedora besides nodejs and mongodb is rubygem-therubyracer, and that FTBFS for the F20 mass rebuild and my recent v8/libicu mini-mass rebuild: http://koji.fedoraproject.org/koji/packageinfo?packageID=14305 I'm in touch with someone from IBM to get PPC support for v8/nodejs (which means no more random failures when nodejs packages get sent to EPEL PPC builders, yay!), which requires finally switching to gyp from scons (which has been deprecated for years now), and so far I've been ignoring ruby in my preliminary work [1] on this since it has been broken for other reasons. The other reasons were update of v8 from 3.13 to 3.14. Vít If you're going to continue to need rubygem-therubyracer, please fix it so I can make sure we don't break it. (Or at least rebuild it when the time comes. It probably still works in F20 since nothing changed v8-wise since F18, but I wouldn't be surprised if it's completely busted in rawhide right now.) Thanks, -T.C. [1] http://copr.fedoraproject.org/coprs/patches/v8-gyp/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: SDDM as the default KDE display manager instead of KDM
On Tue, 15 Apr 2014 08:14:11 +0200, Petr Pisar ppi...@redhat.com wrote: On 2014-04-14, Jaroslav Reznik jrez...@redhat.com wrote: = Proposed Self Contained Change: SDDM as the default KDE display manager instead of KDM = https://fedoraproject.org/wiki/Changes/SDDMinsteadOfKDM Is the SDDM mature enough to replace more-or-less working KDM? I ask because there has not been a release yet (the one year old 0.1.0 was just a payground snapshot). Even such fundamental thing like user authentication is unfinished (use `getpwent()` instead of reading from `/etc/passwd` https://github.com/sddm/sddm/issues/123). -- Petr Coincidentally, one patch for getpwent was merged today. The community around the project is becoming more active these days, we're considering options to replace the original author, that doesn't seem to have enough time for proper maintenance (despite coming back to live a few hours ago). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: SDDM as the default KDE display manager instead of KDM
On Tue, 15 Apr 2014 09:22:23 +0200, Ian Malone ibmal...@gmail.com wrote: On 14 April 2014 14:40, Jaroslav Reznik jrez...@redhat.com wrote: = Proposed Self Contained Change: SDDM as the default KDE display manager instead of KDM = https://fedoraproject.org/wiki/Changes/SDDMinsteadOfKDM Change owner(s): Martin Briza mbr...@redhat.com KDE SIG Retire KDM as the default display manager of the KDE Fedora Spin in favor of SDDM. == Detailed Description == As described in many articles and discussions, KDM is nearing its end of life and it's time we decided upon the successor. I'm proposing to switch to SDDM, which is a new project that suits our needs perfectly despite its immaturity: As of July 2013, KDM's maintenance consists of bugfixes for the most painful bugs, consisting of only about 20 actual commits to the repository in last two years (excluding translation, themes and merges), adding many new features would require major changes to a lot of the code and there is no active maintainer. SDDM is written in C++11/Qt5 (compared to the bits of XDM in KDM), compilable against Qt4, supports QtQuick theming and its upstream is quite active. Compared to the current DM, KDM, it currently lacks a few features (such as XDMCP) but adds some other ones (QtQuick themes) or is currently adding them (Keyboard layout switching in the greeter). == Scope == * Proposal owners: ** Create sddm and sddm-kcm packages. ** Change kde-settings and the spin-kickstarts to provide SDDM package instead of KDM ** (eventually) exclude KDM from the kde-workspace package * Other developers: N/A (not a System Wide Change) * Release engineering: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) ___ Does scope need to include a specific plan to deal with this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1034414 since failure to login is worse than any bug in KDM? I can add it, you're right this is an important task before we can ship the DM. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F21 Self Contained Change: 64bit ARM emulation on x86
= Proposed Self Contained Change: 64bit ARM emulation on x86 = https://fedoraproject.org/wiki/Changes/Virt_64bit_ARM_on_x86 Change owner(s): Cole Robinson crobi...@redhat.com Allow running 64bit ARM (AArch64) VMs on x86 hosts using standard the standard qemu and libvirt stack, as well as end user tools like virt-manager and virt- install. == Detailed Description == Work is quickly under way in upstream qemu to enable full AArch64 system emulation with qemu-system-aarch64. This 'Change' will track landing that work in Fedora 21, in addition to the higher level bits in libvirt and virt-manager to ensure it's all usable with standard tools. To be clear, this stuff is still in progress in upstream qemu and I'm not really involved with the development, so it's very much 'wait and see' to determine if the actual emulation bits will make it in time for Fedora 21. == Scope == * Proposal owners: 1. Wait and see if the qemu bits will land in time for Fedora 21. 2. Once that takes shape, figure out the remaining work to get libvirt/virt- manager to support it (shouldn't be anything too drastic) 3. Document it all ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F21 System Wide Change: Workstation: Disable firewall
= Proposed System Wide Change: Workstation: Disable firewall = https://fedoraproject.org/wiki/Changes/Workstation_Disable_Firewall Change owner(s): Matthias Clasen mcla...@redhat.com The firewalld service will not be enabled by default in the workstation product. == Detailed Description == The current level of integration into the desktop and applications does not justify enabling the firewalld service by default. Additionally, the set of zones that we currently expose is excessive and not user-friendly. Therefore, we will disable the firewall service while we are working on a more user- friendly way to deal with network-related privacy issues. It will of course still be possible to enable the firewall manually. == Scope == * Proposal owners/Other developers: Add a Workstation-specific service configuration (preset ?) to the firewalld package that disables firewalld for the Workstation product * Release engineering: No action required * Policies and guidelines: No action required ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Ruby193 in SCL
On 04/14/2014 10:17 PM, Bill Nottingham wrote: Jaroslav Reznik (jrez...@redhat.com) said: = Proposed System Wide Change: Ruby193 in SCL = https://fedoraproject.org/wiki/Changes/Ruby193_in_SCL Change owner(s): Marcela Mašláňová mmasl...@redhat.com Ruby 1.9.3 with Rails 3.2.8 is still commonly used by many projects. Let's provide Ruby and Rails in SCL even for Fedora. Rails depends on exact v8 version, which means v8 3.14 must have also their own SCL as part of the SCL. Is the intent to only provide SCL versions of the older ruby rails, or also the current versions (i.e., move to SCL as the rails delivery mechanism going forward)? Bill I'm doing one collection. If there is someone who want to donate his free time to do also new version, I'm fine with it, but I don't see any use-case right now. Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
Am 15.04.2014 11:01, schrieb Jaroslav Reznik: = Proposed System Wide Change: Workstation: Disable firewall = https://fedoraproject.org/wiki/Changes/Workstation_Disable_Firewall Change owner(s): Matthias Clasen mcla...@redhat.com The firewalld service will not be enabled by default in the workstation product. == Detailed Description == The current level of integration into the desktop and applications does not justify enabling the firewalld service by default. Additionally, the set of zones that we currently expose is excessive and not user-friendly. Therefore, we will disable the firewall service while we are working on a more user- friendly way to deal with network-related privacy issues. It will of course still be possible to enable the firewall manually. == Scope == * Proposal owners/Other developers: Add a Workstation-specific service configuration (preset ?) to the firewalld package that disables firewalld for the Workstation product * Release engineering: No action required * Policies and guidelines: No action required User Experience Applications that are using sharing protocols such as DAAP or UPnP will work out of the box, without the need to tweak or disable the firewall service seriously going the Apple way and back to where WiNXP before SP3 was? users running applications which opening a high port in the background like license checks and so on (as example ZendStudio) will be really thankful that as default these ports are open on the WAN honestly whoever proposes such a change has to understand that these days it is not uncommon to have diretly to the WAN exposed machines with no safety NAT/router between (UMTS/3G sticks, untrusted WLAN) independent of whatever product a new installed system has not to open any port by default - anybody proposing the opposite is careless and ignorant if it comes to security do we really want to go the way of dangerous defaults without at least two buttons secure defaults and i don't care due the installation? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Ruby193 in SCL
On 04/15/2014 12:05 AM, Ken Dreyer wrote: On Mon, Apr 14, 2014 at 2:17 PM, Bill Nottingham nott...@splat.cc wrote: Jaroslav Reznik (jrez...@redhat.com) said: = Proposed System Wide Change: Ruby193 in SCL = https://fedoraproject.org/wiki/Changes/Ruby193_in_SCL Change owner(s): Marcela Mašláňová mmasl...@redhat.com Ruby 1.9.3 with Rails 3.2.8 is still commonly used by many projects. Let's provide Ruby and Rails in SCL even for Fedora. Rails depends on exact v8 version, which means v8 3.14 must have also their own SCL as part of the SCL. Is the intent to only provide SCL versions of the older ruby rails, or also the current versions (i.e., move to SCL as the rails delivery mechanism going forward)? Personally I like the direction that Django is taking by shipping parallel-installable packages. I think this would be doable for Rails. /usr/bin/rails could be handled with alternatives. - Ken Thanks for recommendation, but I need to provide more than one gem. I know current content of collection is working together well (~60), so I'd like to keep those gems in their versions. Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
EPEL epel beta report: 20140415 changes
Compose started at Tue Apr 15 08:15:03 UTC 2014 Broken deps for x86_64 -- 2ping-2.0-2.el7.noarch requires perl(Digest::CRC) RemoteBox-1.7-1.el7.noarch requires rdesktop RemoteBox-1.7-1.el7.noarch requires perl-Gtk2 bodhi-server-0.9.8-2.el7.noarch requires python-simplemediawiki bodhi-server-0.9.8-2.el7.noarch requires python-fedora-turbogears caja-beesu-1.8.0-1.el7.x86_64 requires beesu 1:centerim-4.22.10-14.el7.x86_64 requires perl(Time::ParseDate) chm2pdf-0.9.1-13.el7.noarch requires htmldoc docker-registry-0.6.5-1.el7.noarch requires redis docker-registry-0.6.5-1.el7.noarch requires python-redis docker-registry-0.6.5-1.el7.noarch requires python-keystoneclient docker-registry-0.6.5-1.el7.noarch requires python-glanceclient docker-registry-0.6.5-1.el7.noarch requires python-backports-lzma globus-gram-job-manager-pbs-1.6-7.el7.x86_64 requires torque-client globus-gram-job-manager-sge-1.7-2.el7.x86_64 requires gridengine lxc-templates-0.9.0-3.el7.x86_64 requires dpkg lxc-templates-0.9.0-3.el7.x86_64 requires debootstrap lxc-templates-0.9.0-3.el7.x86_64 requires busybox mate-themes-1.8.1-0.1.git20140304.5a900ef.el7.noarch requires gtk2-engines mate-themes-1.8.1-0.1.git20140304.5a900ef.el7.noarch requires gtk-murrine-engine mcollective-common-2.4.1-1.el7.noarch requires rubygem(systemu) mcollective-common-2.4.1-1.el7.noarch requires rubygem(stomp) nf3d-0.8-2.el7.noarch requires python-visual openpgpkey-milter-0.3-1.el7.noarch requires python-pymilter openpgpkey-milter-0.3-1.el7.noarch requires python-gnupg php-phpseclib-crypt-aes-0.3.5-2.el7.noarch requires php-pear(phpseclib.sourceforge.net/Crypt_Rijndael) = 0:0.3.0 plowshare-0.9.4-0.46.20140112git.el7.noarch requires caca-utils python-bloom-0.5.4-1.el7.noarch requires python-vcstools = 0:0.1.22 python-bloom-0.5.4-1.el7.noarch requires python-rosdistro = 0:0.3.0 python-bloom-0.5.4-1.el7.noarch requires python-rosdep = 0:0.10.25 python-bloom-0.5.4-1.el7.noarch requires python-catkin_pkg = 0:0.1.14 python-tgcaptcha2-0.2.0-5.el7.noarch requires python-fedora-turbogears qt4pas-2.5-3.el7.x86_64 requires fpc-src rabbitvcs-core-0.16-1.el7.noarch requires python-dulwich rabbitvcs-core-0.16-1.el7.noarch requires pysvn rabbitvcs-nautilus-0.16-1.el7.x86_64 requires nautilus-python rabbitvcs-thunar-0.16-1.el7.x86_64 requires thunarx-python rabbitvcs-thunar-0.16-1.el7.x86_64 requires thunar ruby-openbabel-2.3.2-1.el7.x86_64 requires ruby(abi) = 0:1.9.1 rubygem-gssapi-1.1.2-3.el7.noarch requires rubygem(ffi) = 0:1.0.1 rubygem-mizuho-0.9.20-2.el7.noarch requires rubygem(sqlite3) rubygem-rspec-2.14.1-1.el7.noarch requires rubygem(rspec-mocks) = 0:2.14.1 rubygem-rspec-2.14.1-1.el7.noarch requires rubygem(rspec-expectations) = 0:2.14.1 rubygem-rspec-2.14.1-1.el7.noarch requires rubygem(rspec-core) = 0:2.14.1 rubygem-simplecov-0.7.1-8.el7.noarch requires rubygem(multi_json) = 0:1.0 rubygem-simplecov-html-0.7.1-3.el7.noarch requires ruby(abi) = 0:1.9.1 rubygem-term-ansicolor-1.2.2-3.el7.noarch requires rubygem(tins) 0:1 rubygem-term-ansicolor-1.2.2-3.el7.noarch requires rubygem(tins) = 0:0.8 spectrwm-2.5.0-1.el7.x86_64 requires xlockmore spectrwm-2.5.0-1.el7.x86_64 requires dmenu yum-axelget-1.0.4-1.20140414git90159ff.el7.noarch requires axel Broken deps for ppc64 -- 2ping-2.0-2.el7.noarch requires perl(Digest::CRC) RemoteBox-1.7-1.el7.noarch requires rdesktop RemoteBox-1.7-1.el7.noarch requires perl-Gtk2 bodhi-server-0.9.8-2.el7.noarch requires python-simplemediawiki bodhi-server-0.9.8-2.el7.noarch requires python-fedora-turbogears caja-beesu-1.8.0-1.el7.ppc64 requires beesu 1:centerim-4.22.10-14.el7.ppc64 requires perl(Time::ParseDate) chm2pdf-0.9.1-13.el7.noarch requires htmldoc cloud-init-0.7.2-8.el7.noarch requires python-requests cloud-init-0.7.2-8.el7.noarch requires dmidecode copr-cli-1.32-1.el7.noarch requires python-requests docker-registry-0.6.5-1.el7.noarch requires redis docker-registry-0.6.5-1.el7.noarch requires python-requests docker-registry-0.6.5-1.el7.noarch requires python-redis docker-registry-0.6.5-1.el7.noarch requires python-keystoneclient docker-registry-0.6.5-1.el7.noarch requires python-glanceclient docker-registry-0.6.5-1.el7.noarch requires python-backports-lzma fedmsg-0.7.7-1.el7.noarch requires python-requests fedora-dockerfiles-0-0.5.git122ef5d.el7.noarch requires
Re: F21 System Wide Change: Ruby193 in SCL
On 04/15/2014 02:07 AM, T.C. Hollingsworth wrote: On Mon, Apr 14, 2014 at 7:16 AM, Jaroslav Reznik jrez...@redhat.com wrote: Rails depends on exact v8 version, which means v8 3.14 must have also their own SCL as part of the SCL. Stupid question: what in rails depends on v8 exactly? The only thing that Requires v8 in Fedora besides nodejs and mongodb is rubygem-therubyracer, and that FTBFS for the F20 mass rebuild and my recent v8/libicu mini-mass rebuild: http://koji.fedoraproject.org/koji/packageinfo?packageID=14305 I'm in touch with someone from IBM to get PPC support for v8/nodejs (which means no more random failures when nodejs packages get sent to EPEL PPC builders, yay!), which requires finally switching to gyp from scons (which has been deprecated for years now), and so far I've been ignoring ruby in my preliminary work [1] on this since it has been broken for other reasons. If you're going to continue to need rubygem-therubyracer, please fix it so I can make sure we don't break it. (Or at least rebuild it when the time comes. It probably still works in F20 since nothing changed v8-wise since F18, but I wouldn't be surprised if it's completely busted in rawhide right now.) Thanks, -T.C. [1] http://copr.fedoraproject.org/coprs/patches/v8-gyp/ I need to look at this later. At the moment I'm trying to rebuild whole SCL in Copr ;-) When it's done I can figure out if I really need v8 in SCL, but as Vit pointed out the new version might be a problem. Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
On Tue, Apr 15, 2014 at 11:18 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 15.04.2014 11:01, schrieb Jaroslav Reznik: = Proposed System Wide Change: Workstation: Disable firewall = https://fedoraproject.org/wiki/Changes/Workstation_Disable_Firewall Change owner(s): Matthias Clasen mcla...@redhat.com The firewalld service will not be enabled by default in the workstation product. == Detailed Description == The current level of integration into the desktop and applications does not justify enabling the firewalld service by default. Additionally, the set of zones that we currently expose is excessive and not user-friendly. Therefore, we will disable the firewall service while we are working on a more user- friendly way to deal with network-related privacy issues. It will of course still be possible to enable the firewall manually. == Scope == * Proposal owners/Other developers: Add a Workstation-specific service configuration (preset ?) to the firewalld package that disables firewalld for the Workstation product * Release engineering: No action required * Policies and guidelines: No action required User Experience Applications that are using sharing protocols such as DAAP or UPnP will work out of the box, without the need to tweak or disable the firewall service seriously going the Apple way and back to where WiNXP before SP3 was? strawman. users running applications which opening a high port in the background like license checks and so on (as example ZendStudio) will be really thankful that as default these ports are open on the WAN Why does it listen on a port for license checks? It should just contact the server and not the other way. Besides no one is stopping you from enabling the firewall. honestly whoever proposes such a change has to understand that these days it is not uncommon to have diretly to the WAN exposed machines with no safety NAT/router between (UMTS/3G sticks, untrusted WLAN) independent of whatever product a new installed system has not to open any port by default I agree to that but the point is open by default. But if the user chooses to open it it share a file or whatever it should just work. - anybody proposing the opposite is careless and ignorant if it comes to security do we really want to go the way of dangerous defaults without ... dangerous ? So install the workstation package set. Boot it up. Disable the firewall. Which kind of vulnerabilities are able to find? Which ports are accessible? What can you do with them? at least two buttons secure defaults and i don't care due the installation? No that's dumb. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
On 4/15/14, Reindl Harald h.rei...@thelounge.net wrote: Am 15.04.2014 11:01, schrieb Jaroslav Reznik: = Proposed System Wide Change: Workstation: Disable firewall = https://fedoraproject.org/wiki/Changes/Workstation_Disable_Firewall Change owner(s): Matthias Clasen mcla...@redhat.com The firewalld service will not be enabled by default in the workstation product. == Detailed Description == The current level of integration into the desktop and applications does not justify enabling the firewalld service by default. [cut] Isn't the integration something which should be fixed rather than walked-around? It will of course still be possible to enable the firewall manually. Nope. There will be scenarios where a user will have exposed the new new machine before the firewall is enabled. seriously going the Apple way and back to where WiNXP before SP3 was? Actually, it will be worse. Users are expecting the firewall to be present, and breaking that assumption will create all sorts of problems. IN the old days, at least experienced users knew about the missing firewall and related problems. [cut] honestly whoever proposes such a change has to understand that these days it is not uncommon to have diretly to the WAN exposed machines with no safety NAT/router between (UMTS/3G sticks, untrusted WLAN) +1 If you really, really want to walk this path it might be better with some kind of post-install configuration step optionally disabling the firewall (with user dialog). This would at least make things visible, and not leave the system open from the beginning. But the proper solution is certainly to fix the application/firewall integration. --alec -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
Am 15.04.2014 11:32, schrieb drago01: On Tue, Apr 15, 2014 at 11:18 AM, Reindl Harald h.rei...@thelounge.net wrote: User Experience Applications that are using sharing protocols such as DAAP or UPnP will work out of the box, without the need to tweak or disable the firewall service seriously going the Apple way and back to where WiNXP before SP3 was? strawman no it's a fact, before SP3 WinXP had no firewall and MS learned users running applications which opening a high port in the background like license checks and so on (as example ZendStudio) will be really thankful that as default these ports are open on the WAN Why does it listen on a port for license checks? It should just contact the server and not the other way. it's hardly your business nor mine, fact is that you as os-vendor can not know what application is opening whatever ports and thats why you have to ship secure defaults Besides no one is stopping you from enabling the firewall did you really not learn anything from the past 10 years like new Windows setups where infected before you even had the chance to install the security updates or enable a firewall? it is not a point of *what i can do and do* it is a point what the ordinary 08/15 user does which assumes to have a by default secure system after install honestly whoever proposes such a change has to understand that these days it is not uncommon to have diretly to the WAN exposed machines with no safety NAT/router between (UMTS/3G sticks, untrusted WLAN) independent of whatever product a new installed system has not to open any port by default I agree to that but the point is open by default. But if the user chooses to open it it share a file or whatever it should just work. - anybody proposing the opposite is careless and ignorant if it comes to security do we really want to go the way of dangerous defaults without ... dangerous ? allow any random application to open a unprivlieged port which is reachable from outside is dangerous So install the workstation package set. Boot it up. Disable the firewall. Which kind of vulnerabilities are able to find? Which ports are accessible? What can you do with them? *we talk about a operating system* there is installed software later i do not know and you do not know what is running on the users machine at least two buttons secure defaults and i don't care due the installation? No that's dumb dumb is we can't handle security currently in a default install and so we disable it completly with other words like we will disable the firewall service while we are working on a more user-friendly way to deal with network-related privacy issues signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: appdata handling
On 14 April 2014 21:46, Richard Hughes hughsi...@gmail.com wrote: You are an early adopter; somewhat simpler now :) Okay, since this morning: createrepo_as --basename=test path/to/package.rpm sudo appstream-util install test.xml.gz test-icons.tar.gz I'll get a new appstream-glib release out at the end of the month and into F20/rawhide. Then I'll update the FAQ. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
Am 15.04.2014 11:32, schrieb drago01: do we really want to go the way of dangerous defaults without ... dangerous ? So install the workstation package set. Boot it up. Disable the firewall. Which kind of vulnerabilities are able to find? Which ports are accessible? Avahi at least What can you do with them? that will the time tell you after there where security flaws nobody expected before when it is too late - it is somehow pervert to argue that way and make proposals to weaken the default security exactly one week after Heartbleed what can you do with them if it comes to security is the wrong question - what can you not do with them and how do you prove that would be the right question not a single security flaw in the past yeas was expected and now instead learn of them we disable security layers? short ago it was proposed drop tcpwrapper from the distribution because there is a firewall and we should rely on a sinle layer of defense followed directly by oh and now let us disable that security layer in a default install to make it clear: myself is not affected by such things but it scares me because i have to fight as server-admin with the impact of dumb security decisions and the resulting botnets and yes you have to be very careful with but we are not vulerable like this and that because that's the first step to fall hard signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Agenda for Env-and-Stacks WG meeting (2014-04-15)
WG meeting will be at 12:00 UTC, 14:00 Central Europe, 8:00 Boston, 5:00 San Francisco, 21:00 Tokyo in #fedora-meeting on Freenode. == Topic == * really finish Open Questions https://fedoraproject.org/wiki/Env_and_Stacks/Playground_repository_%28draft%29#Open_Questions * plan tasks to split among developers Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server: test it right now and report bugs
On 12.4.2014 17:25, Reindl Harald wrote:
Am 12.04.2014 17:11, schrieb Paul Wouters:
On Sat, 12 Apr 2014, Reindl Harald wrote:
we should not do anything - because we don't have a clue about the
network of the enduser
We know and handle a lot more than you think already using unbound with
dnssec-trigger and VPNs. Why don't you give it a shot and give us some
feedback on how it works for you on your laptop?
because i stopped to use laptops years ago?
because i have way too complex dns setups for such magic?
because i don't touch NM in that life?
i speak in that thread as one who understands the pain of playing with
DNS and what happens if assumtions are made wrong
if the roadrunner has the VPN client directly on his machine, well
then he needs to make a decision:
They needs to make no decision, it has been automated already:
https://github.com/libreswan/libreswan/blob/master/programs/_updown.netkey/_updown.netkey.in
if [ -n $(pidof unbound) ]; then
echo updating local nameserver for ${PLUTO_PEER_DOMAIN_INFO} with
${PLUTO_PEER_DNS_INFO}
/usr/sbin/unbound-control forward_add ${PLUTO_PEER_DOMAIN_INFO}
${PLUTO_PEER_DNS_INFO}
/usr/sbin/unbound-control flush_zone ${PLUTO_PEER_DOMAIN_INFO}
/usr/sbin/unbound-control flush_requestlist
return 0
fi
and if you cross my street with a users machine give me a single button to
disable
that because you break my setups with that - no i can't explain internal
infrastructure
in the public but there has to be no local cache in my way
if a co-worker asks for a dns-record, tried to call the site already you have no
business to have a negative cache on the client while all 4 internal nameservers
where two are already caching-servers for external responses and used as
forwarder
for non-auth zones have already the answer
DNS1: cache
DNS2: cache
DNS3: auth for 600 zones
DNS4: auth for 600 zones
users asking DNS1 and DNS2
they are doing recursion
DNS3 and DNS4 are for public access from the internet to resolve customer
domains
It seems that this thread contains a lot of hand-waving about problems which
can theoretically happen.
I would like to move the discussion to more constructive stage - get your
hands dirty! :-)
Instructions for testing on Fedora 20+ are available on:
https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver#How_To_Test
Please, run dnssec-trigger and let exclamations like It can't possibly work!
apart. Send constructive bug reports instead.
E.g.
- My network has static configuration XYZ in /etc/sysconfig/... and it doesn't
work. unbound-control list_forwards shows empty list.
- I can't access my corporate mail server when I'm connected to VPN.
journalctl -f -u unbound.service shows this:
unbound[1062]: [1062:0] info: validation failure mail.corp.com. A IN: no
keys have a DS with algorithm RSASHA1 from 192.168.2.1 for key
dnssec-failed.org. while building chain of trust
etc. etc.
We need real data.
Thank you very much for your attention.
--
Petr^2 Spacek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Python 3 and mod_wsgi
On Mon, Apr 14, 2014 at 04:54:33PM -0400, Bohuslav Kabrda wrote: AFAIK you can't have 2 mod_wsgi's, each one compiled against a different Python major.minor, loaded by Apache at the same time for various reasons. So the best solution would IMO be to create python3-mod_wsgi (subpackage of mod_wsgi), that would conflict with mod_wsgi. It should be perfectly doable and it shouldn't break anything. CCing Matthias, the owner of mod_wsgi in Fedora - Matthias, what do you think? This is done in f21 already thanks to Jakub Dorňák (#1035876) - I guess we could backport to f20 without any problems. Regards, Joe -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F21 System Wide Change: Workstation: Enable Software Collections
= Proposed System Wide Change: Workstation: Enable Software Collections = https://fedoraproject.org/wiki/Changes/Workstation_Enable_Software_Collections Change owner(s): Matthias Clasen mcla...@redhat.com The Software Collections repositories will be enabled by default. == Detailed Description == The Workstation product is targeting developers, among others. Software collections are aiming to give developers easy access to the tools they need. == Scope == * Proposal owners: Include scl-utils in the Workstation package set * Other developers: The devassistant should integrate software collection functionality * Release engineering: No action required * Policies and guidelines: Allow the inclusion of the software collections repositories in Fedora products ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Spec files in Rawhide using ExclusiveArch: %{ocaml_arches}
On Tue, Apr 15, 2014 at 02:14:25PM +0300, Panu Matilainen wrote:
On 04/15/2014 01:26 PM, Richard W.M. Jones wrote:
NOTE: If you are in the CC of this email, then you don't need to do
anything. I will fix your package for you. However you
should still read the email.
Some OCaml spec files do the following:
ExclusiveArch: %{ocaml_arches}
This is always incorrect for several reasons:
(1) This macro is provided by redhat-rpm-config, and has the wrong
list of architectures.
(2) OCaml compiles on all architectures.
There may be some packages using this macro to mean I need the OCaml
native code compiler, which is still wrong, but I'm going to fix this
by adding the following macros to the RPM config:
%ocaml_native_compiler # all arches that support native compilation
%ocaml_natdynlink # all arches that support native dynamic linking
Not that it matters to me, but these names seem a bit inconsistent.
Why not %ocaml_native_dynlink to go with %ocaml_native_compiler? Its
not any longer :)
The feature upstream is called natdynlink, so I guess it's better to
keep the shorter name.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F21 Self Contained Change: libzhuyin
= Proposed Self Contained Change: libzhuyin = https://fedoraproject.org/wiki/Changes/libzhuyin Change owner(s): Peng Wu p...@redhat.com An new intelligent input method for Traditional Chinese (Taiwan) provided by libzhuyin using 3-grams to give better conversion than ibus-chewing with libchewing. == Detailed Description == This is a Traditional Chinese equivalent of libpinyin [1] and ibus-libpinyin [2] which replaced ibus-pinyin as default in Fedora 18. The libzhuyin project provides the core algorithms for intelligent sentence- based Chinese Zhuyin input methods, and is already packaged in Fedora. With the assistant of libzhuyin, the user can correctly input some words of Chinese sentence, and then libzhuyin try to figure out the rest of the inputting sentence for the user. == Scope == * Proposal owner: ** Develop the ibus-libzhuyin project in order for users to use libzhuyin backend. ** Package ibus-libzhuyin in Fedora ** Test, improve, and fix bugs ** Change default IME for Traditional Chinese (Taiwan) from ibus-chewing to ibus-libzhuyin. * Other Developers: N/A (Not a System Wide Change) * Release engineering: N/A (Not a System Wide Change) * Policies and guidelines: N/A (Not a System Wide Change) [1] https://fedoraproject.org/wiki/Features/libpinyin [2] https://fedoraproject.org/wiki/Features/ibus-libpinyin ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Enable Software Collections
On Tue, Apr 15, 2014 at 7:18 AM, Jaroslav Reznik jrez...@redhat.com wrote: = Proposed System Wide Change: Workstation: Enable Software Collections = https://fedoraproject.org/wiki/Changes/Workstation_Enable_Software_Collections Change owner(s): Matthias Clasen mcla...@redhat.com The Software Collections repositories will be enabled by default. I'm not sure this is really a system wide change. It only enables this on Workstation and it's only an inclusion of scl-utils in the package set. Seems fairly self-contained? It might depend on https://fedoraproject.org/wiki/Changes/SCL though. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Enable Software Collections
- Original Message - On Tue, Apr 15, 2014 at 7:18 AM, Jaroslav Reznik jrez...@redhat.com wrote: = Proposed System Wide Change: Workstation: Enable Software Collections = https://fedoraproject.org/wiki/Changes/Workstation_Enable_Software_Collections Change owner(s): Matthias Clasen mcla...@redhat.com The Software Collections repositories will be enabled by default. I'm not sure this is really a system wide change. It only enables this on Workstation and it's only an inclusion of scl-utils in the package set. Seems fairly self-contained? It might depend on https://fedoraproject.org/wiki/Changes/SCL though. As Workstation only, I'd tend to Self Contained too but as you pointed out, there's possible dependency on the SCL Change, and to give some sense to it, also on the Ruby 1.9.3 collection. Jaroslav josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Playground repository
Hi, sorry for being a bit late to the discussion. On Tue, 2014-04-08 at 12:23 -0500, Rex Dieter wrote: Adding repos definitely should not be taken lightly. Frankly, if 2 is really something worth doing, then perhaps also the (overly?) stringent policies need rethinking. The initial idea for the Playground repository came up as a frequently encountered need for something between the current Fedora's main repository and the COPRs. The former is comprised of very high-quality peer-review packages adhering to the Packaging Guidelines and the latter are just user-contributed RPMs which have almost no restrictions (besides being buildable by Copr and complying with the Fedora Licensing guidelines), so they could be of very high quality, very low quality or anything in between. I think this Change brings some cool new opportunities, where Fedora can research some new concepts and innovate: 1) This will be the first more generally-targeted repository that will came out entirely from Copr so we'll be able to see how Copr handles that. 2) Packages destined to the Playground repository will go through automatic testing/gating to ensure that they are up to some basic level of quality. As the tests will be automatic, they could also be repeated on every package update to provide some sort of continuous integration at the package level. If this proves to be successful, we could look at porting this to the main repository. 3) After the Playground sets off and we learn the process of spinning another repository, we could look at creating Playground++, a more stable Ring 2 repository around the main repository. 4) This could also spur some new thoughts on the current Packaging Guidelines and review process (e.g. Which parts are too strict? Which parts take the longest?), and as a consequence, help in improving it. Tadej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server: test it right now and report bugs
Hello Petr, On Tuesday, 15 April 2014 4:02 PM, Petr Spacek wrote: Instructions for testing on Fedora 20+ are available on: https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver#How_To_Test Please, run dnssec-trigger and let exclamations like It can't possibly work! apart. Send constructive bug reports instead. We need real data. Excellent! Thank you so much for doing this Petr. I was going to do the same. Summarise the discussion so far, list down the problem areas and invite users to report their problems. Having real first hand data and bug reports would be extremely effective in developing the NM plugins and integration with NM. I'll try both the configuration on my machine. Thank you! :) --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Spec files in Rawhide using ExclusiveArch: %{ocaml_arches}
Some OCaml spec files do the following:
ExclusiveArch: %{ocaml_arches}
This is always incorrect for several reasons:
Is %{ocaml_arches} used for anything?
In case not, maybe better to remove it?
Jens
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Enable Software Collections
On Tue, Apr 15, 2014 at 7:38 AM, Jaroslav Reznik jrez...@redhat.com wrote: - Original Message - On Tue, Apr 15, 2014 at 7:18 AM, Jaroslav Reznik jrez...@redhat.com wrote: = Proposed System Wide Change: Workstation: Enable Software Collections = https://fedoraproject.org/wiki/Changes/Workstation_Enable_Software_Collections Change owner(s): Matthias Clasen mcla...@redhat.com The Software Collections repositories will be enabled by default. I'm not sure this is really a system wide change. It only enables this on Workstation and it's only an inclusion of scl-utils in the package set. Seems fairly self-contained? It might depend on https://fedoraproject.org/wiki/Changes/SCL though. As Workstation only, I'd tend to Self Contained too but as you pointed out, there's possible dependency on the SCL Change, and to give some sense to it, also on the Ruby 1.9.3 collection. I missed the dependency on Ruby 1.9.3. Could you explain how including scl-utils depends on Ruby? josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Enable Software Collections
On Tue, Apr 15, 2014 at 2:20 PM, Josh Boyer jwbo...@fedoraproject.org wrote: On Tue, Apr 15, 2014 at 7:38 AM, Jaroslav Reznik jrez...@redhat.com wrote: - Original Message - On Tue, Apr 15, 2014 at 7:18 AM, Jaroslav Reznik jrez...@redhat.com wrote: = Proposed System Wide Change: Workstation: Enable Software Collections = https://fedoraproject.org/wiki/Changes/Workstation_Enable_Software_Collections Change owner(s): Matthias Clasen mcla...@redhat.com The Software Collections repositories will be enabled by default. I'm not sure this is really a system wide change. It only enables this on Workstation and it's only an inclusion of scl-utils in the package set. Seems fairly self-contained? It might depend on https://fedoraproject.org/wiki/Changes/SCL though. As Workstation only, I'd tend to Self Contained too but as you pointed out, there's possible dependency on the SCL Change, and to give some sense to it, also on the Ruby 1.9.3 collection. I missed the dependency on Ruby 1.9.3. Could you explain how including scl-utils depends on Ruby? He meant the opposite i.e the ruby scl depends on scl-utils. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Enable Software Collections
On Tue, Apr 15, 2014 at 8:23 AM, drago01 drag...@gmail.com wrote: On Tue, Apr 15, 2014 at 2:20 PM, Josh Boyer jwbo...@fedoraproject.org wrote: On Tue, Apr 15, 2014 at 7:38 AM, Jaroslav Reznik jrez...@redhat.com wrote: - Original Message - On Tue, Apr 15, 2014 at 7:18 AM, Jaroslav Reznik jrez...@redhat.com wrote: = Proposed System Wide Change: Workstation: Enable Software Collections = https://fedoraproject.org/wiki/Changes/Workstation_Enable_Software_Collections Change owner(s): Matthias Clasen mcla...@redhat.com The Software Collections repositories will be enabled by default. I'm not sure this is really a system wide change. It only enables this on Workstation and it's only an inclusion of scl-utils in the package set. Seems fairly self-contained? It might depend on https://fedoraproject.org/wiki/Changes/SCL though. As Workstation only, I'd tend to Self Contained too but as you pointed out, there's possible dependency on the SCL Change, and to give some sense to it, also on the Ruby 1.9.3 collection. I missed the dependency on Ruby 1.9.3. Could you explain how including scl-utils depends on Ruby? He meant the opposite i.e the ruby scl depends on scl-utils. Ah, yes. OK, thanks. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Enable Software Collections
On Tue, 2014-04-15 at 13:18 +0200, Jaroslav Reznik wrote: The Software Collections repositories will be enabled by default. * Policies and guidelines: Allow the inclusion of the software collections repositories in Fedora products Does the above refer to the repositories available at https://www.softwarecollections.org/en/? Tadej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Spec files in Rawhide using ExclusiveArch: %{ocaml_arches}
On Tue, Apr 15, 2014 at 08:19:11AM -0400, Jens Petersen wrote:
Some OCaml spec files do the following:
ExclusiveArch: %{ocaml_arches}
This is always incorrect for several reasons:
Is %{ocaml_arches} used for anything?
In case not, maybe better to remove it?
I've removed it completely. I'm updating the packages which
used this macro.
(Unfortunately my original email on this subject is stuck in a
moderator queue, so I've attached it here.)
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
---BeginMessage---
NOTE: If you are in the CC of this email, then you don't need to do
anything. I will fix your package for you. However you
should still read the email.
Some OCaml spec files do the following:
ExclusiveArch: %{ocaml_arches}
This is always incorrect for several reasons:
(1) This macro is provided by redhat-rpm-config, and has the wrong
list of architectures.
(2) OCaml compiles on all architectures.
There may be some packages using this macro to mean I need the OCaml
native code compiler, which is still wrong, but I'm going to fix this
by adding the following macros to the RPM config:
%ocaml_native_compiler # all arches that support native compilation
%ocaml_natdynlink # all arches that support native dynamic linking
So you could use this instead if you need the native compiler:
ExclusiveArch: %{ocaml_native_compiler}
The following packages appear to be affected, and I will fix them:
alt-ergo
apron
brltty
coq
frama-c
gappalib-coq
graphviz
js-of-ocaml
ocaml-camlp5
ocaml-facile
ocaml-lacaml
ocaml-lwt
ocaml-mlgmpidl
ocaml-ocamlgraph
ocaml-react
ocaml-sqlite
ocaml-zarith
virt-dmesg
whenjobs
why
why3
There may be others which I didn't spot which are affected.
Related bug: https://bugzilla.redhat.com/show_bug.cgi?id=1087794
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
---End Message---
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
On Tue, Apr 15, 2014 at 11:01:51AM +0200, Jaroslav Reznik wrote: = Proposed System Wide Change: Workstation: Disable firewall = https://fedoraproject.org/wiki/Changes/Workstation_Disable_Firewall Change owner(s): Matthias Clasen mcla...@redhat.com The firewalld service will not be enabled by default in the workstation product. == Detailed Description == The current level of integration into the desktop and applications does not justify enabling the firewalld service by default. Additionally, the set of zones that we currently expose is excessive and not user-friendly. Therefore, we will disable the firewall service while we are working on a more user- friendly way to deal with network-related privacy issues. What needs to be done to improve the firewall integration? Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
Whoa, the fact that the Firewall is on by default in Fedora (along with SELinux) is one of the reasons I choose Fedora over alternatives. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, Apr 15, 2014 at 5:01 AM, Jaroslav Reznik jrez...@redhat.com wrote: = Proposed System Wide Change: Workstation: Disable firewall = https://fedoraproject.org/wiki/Changes/Workstation_Disable_Firewall Change owner(s): Matthias Clasen mcla...@redhat.com The firewalld service will not be enabled by default in the workstation product. == Detailed Description == The current level of integration into the desktop and applications does not justify enabling the firewalld service by default. Additionally, the set of zones that we currently expose is excessive and not user-friendly. Therefore, we will disable the firewall service while we are working on a more user- friendly way to deal with network-related privacy issues. It will of course still be possible to enable the firewall manually. == Scope == * Proposal owners/Other developers: Add a Workstation-specific service configuration (preset ?) to the firewalld package that disables firewalld for the Workstation product * Release engineering: No action required * Policies and guidelines: No action required ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Python 3 and mod_wsgi
From: jor...@redhat.com Date: 04/15/2014 07:08 Subject: Re: Python 3 and mod_wsgi On Mon, Apr 14, 2014 at 04:54:33PM -0400, Bohuslav Kabrda wrote: AFAIK you can't have 2 mod_wsgi's, each one compiled against a different Python major.minor, loaded by Apache at the same time for various reasons. Makes sense. So the best solution would IMO be to create python3-mod_wsgi (subpackage of mod_wsgi), that would conflict with mod_wsgi. Seems reasonable. This is done in f21 already thanks to Jakub Dorňák (#1035876) - I guess we could backport to f20 without any problems. That would be extremely helpful here, especially given that f21 is still a ways off. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Enable Software Collections
HI On Tue, Apr 15, 2014 at 8:30 AM, Tadej Janež wrote: Does the above refer to the repositories available at https://www.softwarecollections.org/en/? Yes. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Spec files in Rawhide using ExclusiveArch: %{ocaml_arches}
On Tue, 15 Apr 2014 13:32:04 +0100
Richard W.M. Jones rjo...@redhat.com wrote:
On Tue, Apr 15, 2014 at 08:19:11AM -0400, Jens Petersen wrote:
Some OCaml spec files do the following:
ExclusiveArch: %{ocaml_arches}
This is always incorrect for several reasons:
Is %{ocaml_arches} used for anything?
In case not, maybe better to remove it?
I've removed it completely. I'm updating the packages which
used this macro.
(Unfortunately my original email on this subject is stuck in a
moderator queue, so I've attached it here.)
But do you still need to bootstrap ocaml on the non-native arches to
get the bytecode interpreted one? Or is simply a build? I'm asking
because s390x as you could guess :-)
Dan
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Spec files in Rawhide using ExclusiveArch: %{ocaml_arches}
On Tue, Apr 15, 2014 at 03:12:21PM +0200, Dan Horák wrote:
On Tue, 15 Apr 2014 13:32:04 +0100
Richard W.M. Jones rjo...@redhat.com wrote:
On Tue, Apr 15, 2014 at 08:19:11AM -0400, Jens Petersen wrote:
Some OCaml spec files do the following:
ExclusiveArch: %{ocaml_arches}
This is always incorrect for several reasons:
Is %{ocaml_arches} used for anything?
In case not, maybe better to remove it?
I've removed it completely. I'm updating the packages which
used this macro.
(Unfortunately my original email on this subject is stuck in a
moderator queue, so I've attached it here.)
But do you still need to bootstrap ocaml on the non-native arches to
get the bytecode interpreted one? Or is simply a build? I'm asking
because s390x as you could guess :-)
Just a straight build should work. If the build fail(s/ed) on s390x
can you point me to that, and I'll take a look.
I'd *really* love someone to write a s390x native backend! That would
complete the set.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: BerkeleyDB 6
Dne 11.4.2014 15:55, Florian Weimer napsal(a): On 04/11/2014 01:18 PM, Jaroslav Reznik wrote: = Proposed System Wide Change: BerkeleyDB 6 = https://fedoraproject.org/wiki/Changes/BerkeleyDB_6 Change owner(s): Jan Staněk jsta...@redhat.com Add BerkeleyDB v. 6, which changed license from previous releases (GPLv2+ to AGPLv3+), to Fedora while keeping the older version for packages which cannot use BerkeleyDB with the new license. Please correct the wiki page. The old license was Sleepycat (a short license with a relatively strong copyleft component), and not GPLv2+. We had a packaging bug in some Fedora versions which labeled the libdb license incorrectly, but this was fixed in Fedora 20. Wiki page corrected, thanks for pointing that out. -- Jan Stanek - Red Hat Associate Developer Engineer - Databases Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Spec files in Rawhide using ExclusiveArch: %{ocaml_arches}
On Tue, 15 Apr 2014 14:14:25 +0100
Richard W.M. Jones rjo...@redhat.com wrote:
On Tue, Apr 15, 2014 at 03:12:21PM +0200, Dan Horák wrote:
On Tue, 15 Apr 2014 13:32:04 +0100
Richard W.M. Jones rjo...@redhat.com wrote:
On Tue, Apr 15, 2014 at 08:19:11AM -0400, Jens Petersen wrote:
Some OCaml spec files do the following:
ExclusiveArch: %{ocaml_arches}
This is always incorrect for several reasons:
Is %{ocaml_arches} used for anything?
In case not, maybe better to remove it?
I've removed it completely. I'm updating the packages which
used this macro.
(Unfortunately my original email on this subject is stuck in a
moderator queue, so I've attached it here.)
But do you still need to bootstrap ocaml on the non-native arches to
get the bytecode interpreted one? Or is simply a build? I'm asking
because s390x as you could guess :-)
Just a straight build should work. If the build fail(s/ed) on s390x
can you point me to that, and I'll take a look.
fails on installed but unpackaged files, details were sent in private
mail
I'd *really* love someone to write a s390x native backend! That would
complete the set.
yeah, there is quite long list where s390(x) native backends are
missing :-( but from the ppc64le one it doesn't look that complex ...
Dan
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: BerkeleyDB 6
Dne 11.4.2014 14:57, Chris Adams napsal(a): Once upon a time, Jaroslav Reznik jrez...@redhat.com said: Add BerkeleyDB v. 6, which changed license from previous releases (GPLv2+ to AGPLv3+), to Fedora while keeping the older version for packages which cannot use BerkeleyDB with the new license. Have the packages that cannot use libdb-6 because of the license been identified? That probably needs to be confirmed before moving forward, due to libdb's symbols conflicting between versions if both get loaded. For example (don't think these have license issues, just picked them off the top of my head), if Apache linked with libdb-5 (because of license), and perl linked with libdb-6, mod_perl would be broken. If there are any conflicts because of the license incompatibility, then moving to libdb-6 may not be a good idea. I'm aware of that problem, and it should be addressed by introducing the symbol versioning (see [1], first bullet). The exact problem you are mentioning was encountered before ([2]), and similar problem was dealt with in [3]. I intend to follow that case. To answer your question, I've not yet identified the packages, but I will look into it (or you are welcome to :) ). [1] https://fedoraproject.org/wiki/Changes/BerkeleyDB_6#Scope [2] https://bugzilla.redhat.com/show_bug.cgi?id=768846 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1045013 -- Jan Stanek - Red Hat Associate Developer Engineer - Databases Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: The securetty file is empty by default
On Tue, 2014-04-15 at 13:48 +0930, William Brown wrote: On Mon, 2014-04-14 at 23:57 -0400, Simo Sorce wrote: On Tue, 2014-04-15 at 08:49 +0700, Michel Alexandre Salim wrote: On 04/14/2014 09:21 PM, Andrew Lutomirski wrote: On Mon, Apr 14, 2014 at 6:50 AM, Michel Alexandre Salim sali...@fedoraproject.org wrote: Apologies for being late to the discussion as well - just wanted to note that I've been running root-password-less configurations for some time (by using passwd -l to lock out the root account post-install), and later encountered this scenario whereby one of the disks failed fsck and I was dropped into a single-user mode login for maintenance, where I was prompted for... you get it, the root password. Resorted to rebooting and disabling fsck from grub, but how to handle fsck errors should probably be considered as part of this proposed change. You're not the only one: https://bugzilla.redhat.com/show_bug.cgi?id=1045574 https://bugzilla.redhat.com/show_bug.cgi?id=1087528 Well, the fastboot flag in Grub works as a workaround, my problem is different from those that lost their root password -- I intentionally didn't set one, and expected tasks that in the past required the use of the root password to be doable by the user account nominated to be administrators, whether through %wheel membership or pkcon or other means. but I don't think that this is really related to securetty. If the use of root account is to be further discouraged, I'm pointing out that workflows that currently require it have to be revised as well. I do not think it makes any sense to lock the root account. It is perfectly sane to discourage from using root for day to day operation and avoid or even disallow to login into the display manager with root. But disabling it has no useful purpose, you are just going to make another account all powerful to compensate, either by giving sudo powers or other similar mechanism, what you loose is the ability to properly recover a system. I am not saying you shouldn't be allowed to do passwd -l, but that should not be mandated by the system configuration, purely a choice of individual admins. Simo. -- Simo Sorce * Red Hat, Inc * New York If you could enter the rescue.target with a username/password instead of just enter the password for root I wouldn't mind a default locked root account. What user ? In most of my systems there is only root locally, every other user that can authenticate comes from LDAP which is not accessible at rescue time. Yes, you would have an account that would need at least ALL command access in sudo. For the rescue.target you could attempt to start sssd perhaps if you wanted to access network based accounts ... Why ? sssd may simply be the component at fault here. You also don't lose that ability to recover a system anyway. Because you can then use physical access and init=/bin/bash if you really got desperate. Sure if you have physical access everything is easier, on a colocated machine that has only serial line access though, that's hardly possible. I guess it's more to discourage the shared root password scenario than anything. Why should this be the distribution's task ? That's local policy, not our business, we need to allow such configurations, not mandate them. Really, in the same token, should root ssh be disabled by default? It may be allowed to login only via publickey/gssapi auth and not password auth I guess. But again this look more like admin policy than something the distribution should enforce by default, IMO. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
On 15 April 2014 14:35, Christopher ctubb...@apache.org wrote: Whoa, the fact that the Firewall is on by default in Fedora (along with SELinux) is one of the reasons I choose Fedora over alternatives. Same thing here, It was really surprising to see it as a proposed feature. How can it be that after years we are disabling the firewall by default? I personally find it a big, big step backwards. Instead of disabiling it, wouldn't be a better approach to have a more relaxed firewall policy for the workstation product that opens the additional ports for DAAP, UPnp, etc.? Regards, --Simone -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson). http://xkcd.com/229/ http://negativo17.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Spec files in Rawhide using ExclusiveArch: %{ocaml_arches}
On Tue, Apr 15, 2014 at 03:31:30PM +0200, Dan Horák wrote: fails on installed but unpackaged files, details were sent in private mail Thanks for the details. The -15 package currently building in primary Koji should fix this. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
On Tue, 2014-04-15 at 15:42 +0200, Simone Caronni wrote: On 15 April 2014 14:35, Christopher ctubb...@apache.org wrote: Whoa, the fact that the Firewall is on by default in Fedora (along with SELinux) is one of the reasons I choose Fedora over alternatives. Same thing here, It was really surprising to see it as a proposed feature. How can it be that after years we are disabling the firewall by default? I personally find it a big, big step backwards. Instead of disabiling it, wouldn't be a better approach to have a more relaxed firewall policy for the workstation product that opens the additional ports for DAAP, UPnp, etc.? Indeed, that would be a more reasonable approach. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
On Tue, 2014-04-15 at 14:35 +0200, Zbigniew Jędrzejewski-Szmek wrote: What needs to be done to improve the firewall integration? Zbyszek The rule in the Workstation technical spec is: A firewall in its default configuration may not interfere with the normal operation of programs installed by default. [1] There's a discussion on the desktop list beginning at [2] that has some brainstorming and explanation as to why this would be hard. [1] https://fedoraproject.org/wiki/Workstation/Technical_Specification#Firewall [2] https://lists.fedoraproject.org/pipermail/desktop/2014-February/009142.html signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Base] Base Design WG agenda meeting CANCELED for 18. Apr 2014 15:00 UTC on #fedora-meeting
Hi everyone. Just a quick heads up that there won't be a meeting on Friday this week as it's a holiday for many countries (Good Friday). Thanks regards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Manager Core Services| Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch pknir...@redhat.com Wankelstrasse 5 | Web: http://www.redhat.com/ D-70563 Stuttgart, Germany -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Broken dependencies: perl-Language-Expr
perl-Language-Expr has broken dependencies in the rawhide tree: On x86_64: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) Please resolve this as soon as possible. -- 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: F21 System Wide Change: Workstation: Disable firewall
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, Apr 15, 2014 at 11:01:51AM +0200, Jaroslav Reznik wrote: == Detailed Description == The current level of integration into the desktop and applications does not justify enabling the firewalld service by default. Additionally, the set of zones that we currently expose is excessive and not user-friendly. Therefore, we will disable the firewall service while we are working on a more user- friendly way to deal with network-related privacy issues. Will iptables will still be turned on and active the way it used to be? - -- Eric - -- Eric Sparks Christensen Fedora Project spa...@fedoraproject.org - spa...@redhat.com 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQGcBAEBCgAGBQJTTTwsAAoJEB/kgVGp2CYv2l8L/1aB6WVSQGo6RTZK2u22Ddbt CKFpAHvFkoztPTzBijzmauanJsEEReYDQuPg2Uk5x+pthtqOkAbXAZFmE9a1Xu9V DuUqlflsn8M+yZBOxqaiP7gLQL3q8FsboqkgUkRRLAs9B0eKQ3gToLhLZvKpHaxu 5n676ann4Gv4lSSodewakZ3Jk6zhSdza0ZVU0Q17mLY8iG82qlUY8Pz772txMi0D vsY3lcu6Fsm/TCBAqdFEE+Byosxdu5CLCLXroBz6CRTZoG5/jUPSvyACYx/rQGL+ AENCCVdBx/qFx1XgqhiICQ3LWxtQKIS6mDwo3C1o4whaBGIu8ZbqdLSf++9Bnoat WFr0SiAlMgNOVZ7AvLHXT/zgQGwv8PmlL3J4MBszdz2kkMGsgoYxhBiXWZVFXsJs nUpvhFMYIvWiwQSncJX8LkYTdHnfvg5rbFpmso81kA+i7i2Un7dE3IfhEZRZgWe5 HvHF8VsCGP790UrswmEMw2sUxLSCJuXlrCwBeauyxw== =z62u -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Broken dependencies: mojomojo
mojomojo has broken dependencies in the rawhide tree: On x86_64: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) On i386: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) On armhfp: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-Catalyst-Controller-HTML-FormFu
perl-Catalyst-Controller-HTML-FormFu has broken dependencies in the rawhide tree: On x86_64: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) On i386: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) On armhfp: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) Please resolve this as soon as possible. -- 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: F21 System Wide Change: Workstation: Disable firewall
Am 15.04.2014 15:59, schrieb Michael Catanzaro: On Tue, 2014-04-15 at 14:35 +0200, Zbigniew Jędrzejewski-Szmek wrote: What needs to be done to improve the firewall integration? Zbyszek The rule in the Workstation technical spec is: A firewall in its default configuration may not interfere with the normal operation of programs installed by default. [1] There's a discussion on the desktop list beginning at [2] that has some brainstorming and explanation as to why this would be hard. [1] https://fedoraproject.org/wiki/Workstation/Technical_Specification#Firewall [2] https://lists.fedoraproject.org/pipermail/desktop/2014-February/009142.html that is all fine, but throw away security because it stands in the way of comfort is a terrible step - security *always* will affect usability - you can't have both perfect, never but if you drop security for usability in 2014 after the last 3 years clearly showed that any application and library out there was multiple vulerable in unexpected ways you will not do a favour to your users and the possible damage to the project if it comes to mass security flaws in Fedora Workstation setups a few months after it's first release can never be repaired if i say never then i mean never having press articles with this and that happened because they dropped the firewall for more comfort leaves a bad taste for the future - and not only for the Workstation, also for other products and the distribution because it is a hint for a general attitude that security no longer counts - frankly that can even damage other distributions Linux goes the same way of unsecure defaults signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Meeting minute from Env-and-Stacks WG meeting (2014-04-15)
#fedora-meeting: Env and Stacks (2014-04-15) Meeting started by mmaslano at 12:01:12 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2014-04-15/env-and-stacks.2014-04-15-12.01.log.html . Meeting summary --- * init process (mmaslano, 12:01:30) * LINK: https://fedoraproject.org/wiki/Changes/Workstation_Enable_Software_Collections (jreznik, 12:10:17) * Playground repository (tjanez, 12:32:45) * LINK: https://github.com/fedora-haskell/common/blob/master/common.mk very low-tech :) (juhp, 13:53:18) * ACTION: hhorak will add an item to the playground open questions about deleting the packages/builds already introduced in playground and will send the summary of the irc discussion to the mailing list to continue (hhorak, 14:04:32) * We may follow the Workstation group's Proposed System Wide Change: Workstation: Enable Software Collections and discuss it on the devel list (hhorak, 14:12:48) * mirek-hm talked about dnf playground enable which would enable all copr repos in playground (hhorak, 14:15:59) * We talked about scenario that playground would be implemented by copr with playground flag + dnf plugin working with such corps. No voting done. No final decisions. (hhorak, 14:19:57) Meeting ended at 14:21:35 UTC. Action Items * hhorak will add an item to the playground open questions about deleting the packages/builds already introduced in playground and will send the summary of the irc discussion to the mailing list to continue Action Items, by person --- * hhorak * hhorak will add an item to the playground open questions about deleting the packages/builds already introduced in playground and will send the summary of the irc discussion to the mailing list to continue * **UNASSIGNED** * (none) People Present (lines said) --- * juhp (122) * mmaslano (66) * hhorak (47) * tjanez (43) * mirek-hm (26) * jreznik (13) * drago01 (6) * jwb (5) * zodbot (4) * Southern_Gentlem (4) * pkovar (2) * bkabrda (0) * samkottler (0) * abadger1999 (0) * drieden (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
- Original Message - From: Reindl Harald h.rei...@thelounge.net To: devel@lists.fedoraproject.org Sent: Tuesday, April 15, 2014 11:40:20 AM Subject: Re: F21 System Wide Change: Workstation: Disable firewall Am 15.04.2014 11:32, schrieb drago01: On Tue, Apr 15, 2014 at 11:18 AM, Reindl Harald h.rei...@thelounge.net wrote: allow any random application to open a unprivlieged port which is reachable from outside is dangerous We already allow that and have for a long while. Any application bothering to support the firewalld dbus interface can open any port they wish to. There was a long thread about this on the desktop mailing list, and I was not in the 'disable the firewall' camp in that discussion, but nobody in that thread or here have articulated how the firewall exactly enhance security in the situation where we at the same time need to allow each user to have any port they desire opened for traffic to make sure things like DLNA or Chromecast works. The thread discussing this ended up with mostly being a discussion if the firewall would be a useful way to help users from accidentally oversharing on a public network. Which is important and something we want to work on, but a lot less so than security issues. Christian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Spec files in Rawhide using ExclusiveArch: %{ocaml_arches}
NOTE: If you are in the CC of this email, then you don't need to do
anything. I will fix your package for you. However you
should still read the email.
Some OCaml spec files do the following:
ExclusiveArch: %{ocaml_arches}
This is always incorrect for several reasons:
(1) This macro is provided by redhat-rpm-config, and has the wrong
list of architectures.
(2) OCaml compiles on all architectures.
There may be some packages using this macro to mean I need the OCaml
native code compiler, which is still wrong, but I'm going to fix this
by adding the following macros to the RPM config:
%ocaml_native_compiler # all arches that support native compilation
%ocaml_natdynlink # all arches that support native dynamic linking
So you could use this instead if you need the native compiler:
ExclusiveArch: %{ocaml_native_compiler}
The following packages appear to be affected, and I will fix them:
alt-ergo
apron
brltty
coq
frama-c
gappalib-coq
graphviz
js-of-ocaml
ocaml-camlp5
ocaml-facile
ocaml-lacaml
ocaml-lwt
ocaml-mlgmpidl
ocaml-ocamlgraph
ocaml-react
ocaml-sqlite
ocaml-zarith
virt-dmesg
whenjobs
why
why3
There may be others which I didn't spot which are affected.
Related bug: https://bugzilla.redhat.com/show_bug.cgi?id=1087794
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Spec files in Rawhide using ExclusiveArch: %{ocaml_arches}
On 04/15/2014 01:26 PM, Richard W.M. Jones wrote:
NOTE: If you are in the CC of this email, then you don't need to do
anything. I will fix your package for you. However you
should still read the email.
Some OCaml spec files do the following:
ExclusiveArch: %{ocaml_arches}
This is always incorrect for several reasons:
(1) This macro is provided by redhat-rpm-config, and has the wrong
list of architectures.
(2) OCaml compiles on all architectures.
There may be some packages using this macro to mean I need the OCaml
native code compiler, which is still wrong, but I'm going to fix this
by adding the following macros to the RPM config:
%ocaml_native_compiler # all arches that support native compilation
%ocaml_natdynlink # all arches that support native dynamic linking
Not that it matters to me, but these names seem a bit inconsistent. Why
not %ocaml_native_dynlink to go with %ocaml_native_compiler? Its not any
longer :)
- Panu -
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1087903] New: perl-CSS-Minifier for EPEL 6 and 7
https://bugzilla.redhat.com/show_bug.cgi?id=1087903 Bug ID: 1087903 Summary: perl-CSS-Minifier for EPEL 6 and 7 Product: Fedora Version: rawhide Component: perl-CSS-Minifier Assignee: emman...@seyman.fr Reporter: xav...@bachelot.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, mmasl...@redhat.com, perl-de...@lists.fedoraproject.org, ppi...@redhat.com Hi, I'd need perl-CSS-Minifier in EPEL 6 and 7. Would you be ok to maintain theses branches ? If not, I can take care of them myself. Regards, Xavier -- 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=l8hu3REX7Ua=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
[Bug 1087904] New: perl-Text-Patch for EPEL 6 and 7
https://bugzilla.redhat.com/show_bug.cgi?id=1087904 Bug ID: 1087904 Summary: perl-Text-Patch for EPEL 6 and 7 Product: Fedora Version: rawhide Component: perl-Text-Patch Assignee: psab...@redhat.com Reporter: xav...@bachelot.org QA Contact: extras...@fedoraproject.org CC: perl-de...@lists.fedoraproject.org, ppi...@redhat.com, psab...@redhat.com Hi, I'd need perl-Text-Patch in EPEL 6 and 7. Would you be ok to maintain theses branches ? If not, I can take care of them myself. Regards, Xavier -- 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=TriO2ppZYha=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: Taskotron and Cloud Image tests
On Tue, 08 Apr 2014 13:51:10 +0200 Vitaly Kuznetsov vi...@redhat.com wrote: Hi Tim all, in Cloud WG we have 'Automatic Smoketests on Image Build' task: https://fedorahosted.org/cloud/ticket/38 AFAIK you have somehting similar among future Taskotron goals. It would be nice if we can collaborate here. By writing this message I just want to start the conversation :-) I'm all for collaboration. I do have some ideas on how things would work but the whole point of this is to make something that's useful - if that means deviating from what I originally had in mind, that's fine with me. For RHEL cloud image checks we have special tool called 'valid': https://github.com/RedHatQE/valid , it can be reused for Fedora as well. The questions are: how do you see the integration and how can someone (me?) work on this (non-existent atm) part of Taskotron. For now, I think that the best place to start would be to figure out what's missing from taskotron in order for the integration to happen. - would the cloud image startup be done by valid or in taskotron? - where would the cloud images be run? - what other image work would be done in the task? Our documentation is pretty much non-existent at the moment and I was hoping to get depcheck written as a task before writing too much of that in case we run into problems that require syntax changes to the yaml or interface changes to the python code. However, if you're looking to start soon, I can try to get some of the docs done sooner. In the meantime, there are a couple examples on how to interface with python code: - https://bitbucket.org/fedoraqa/task-examplebodhi - https://bitbucket.org/fedoraqa/task-examplelong - https://bitbucket.org/fedoraqa/task-rpmlint Outside of the python task work that would be needed to get valid working, there are a couple of things I can think of that would be likely be needed to do cloud image testing: - write a directive for finding and dealing with images * likely some combination of find the new image, upload it to a cloud system, launch the image with a given configuration - figure out how to record results * this should be pretty simple because I think cloud image results will be similar but not quite the same as package results. - determine what fedmsgs to trigger off of I can see two possible approaches: 1) 'Easy'. We create special type of task (sorry if I'm not that precise with terminology) which is being executed on static slave node which runs valid (in black-box mode) on newly uploaded image, grabs the result and returns it back. I suspect that this will be the best way to get started. The ephemeral client work you mention below is going to be a lot of work and there are a bunch of unknowns (use openstack or not, how isolated should the clients be etc.). If we want to have a shot at having some of the automated cloud tests done for f21, I think that starting with the easiest route would likely be best 2) 'Hard'. We work on 'ephemeral task clients' (term from http://tirfa.com/an-initial-idea-for-taskbot.html). The benefit here is that in that case we can run any test on a cloud VM. This approach will require some optimization from the very beginning, at least: 1. One VM should be user for multiple tests (so several dozens of image tests won't require several dozens of VMs created) 2. Tests should be able to 'control' VM (e.g. use cloud-specific features: attach device, reboot VM,...) - that can be workarounded by providing cloud credential inside the VM itself but that doesn't sound that attractive. I suspect that some variation on this is going to be a better solution in the long run but as I mentioned above, I think that there is little chance of getting it working in time to be useful for f21. With the easier option, there is a decent chance of getting something running in the not-too-distant future. Yesterday I've tried setting up Taskotron (according to http://roshi.fedorapeople.org/dexy-themed/) on 3 F20 VMs in EC2 and actually I've failed (some ansible playbooks are out-of-sync with some git repos, e.g. 'master playbook' is failing with 'stderr: cp: cannot stat '/home/qaadmin/trigger/jobtrigger.py': No such file or directory' in 'TASK: [copy fedmsg config]'. I totally understand these instructions and repos are rather proof-of-concept and can be slightly outdated but I want to ask about 'minimalistic one-host dev environment' setup anyway. Can 'Host' be eliminated from the setup completely and can we merge Master and Slave (in case we'll need it for 'cloud') on one host? That would help a lot. Yeah, that documentation is really out of date at this point. It was mostly written as a proof of concept and I've been holding off on updating it until the new playbooks are done (and they're starting to get close - you can see them in the 'rolerefactoring' branch) For a small setup, master and slave should be able to co-exist on the same machine. I know
File Try-Tiny-0.21.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Try-Tiny: 98049893c9ce161ba4d1393e00dc8bea Try-Tiny-0.21.tar.gz -- 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: F21 System Wide Change: BerkeleyDB 6
Dne 11.4.2014 16:59, Bill Nottingham napsal(a): Jaroslav Reznik (jrez...@redhat.com) said: == Scope == * Proposal owners: Create new set of packages and introduce proper versioning in order to not confuse the dynamic linker. Is this symbol versioning intended to be upstream? Ideally, yes, but given the upstream willingness to incorporate community-proposed changes, I fear that we may in fact introduce downstream symbol versioning. The fact is that in order to reliably provide both library versions, we *need* the symbol versioning - preferably upstream, but if it won't be possible, we will have to version downstream (or find another solution to this problem). I will contact the upstream about this. -- Jan Stanek - Red Hat Associate Developer Engineer - Databases Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
On Tue, 2014-04-15 at 10:28 -0400, Christian Schaller wrote: - Original Message - From: Reindl Harald h.rei...@thelounge.net To: devel@lists.fedoraproject.org Sent: Tuesday, April 15, 2014 11:40:20 AM Subject: Re: F21 System Wide Change: Workstation: Disable firewall Am 15.04.2014 11:32, schrieb drago01: On Tue, Apr 15, 2014 at 11:18 AM, Reindl Harald h.rei...@thelounge.net wrote: allow any random application to open a unprivlieged port which is reachable from outside is dangerous We already allow that and have for a long while. Any application bothering to support the firewalld dbus interface can open any port they wish to. There was a long thread about this on the desktop mailing list, and I was not in the 'disable the firewall' camp in that discussion, but nobody in that thread or here have articulated how the firewall exactly enhance security in the situation where we at the same time need to allow each user to have any port they desire opened for traffic to make sure things like DLNA or Chromecast works. The thread discussing this ended up with mostly being a discussion if the firewall would be a useful way to help users from accidentally oversharing on a public network. Which is important and something we want to work on, but a lot less so than security issues. There is plenty of prior art here. What you need is clearly different zones that the user can configure and associate to networks, with the default being that you trust nothing and everything is firewalled when you roam a new network. firewalld should grow a NetworkManager plugin so that configuration can be changed on the fly based on which network NM tells firewalld a specific interface is connected to. Applications need to be prevented from being able to arbitrarily open ports, that should be allowed only for a trusted zone. User intervention should be needed to mark a zone as trusted, in all other zones the user will have to select explicitly what applications are allowed. So the big work here is in the UI you need to build to present these configurations to the user. Until then you can present a very simplified UI that just has a big button/switch that turns everything from untrusted to trusted, with the default being untrusted of course. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
Am 15.04.2014 16:28, schrieb Christian Schaller: - Original Message - From: Reindl Harald h.rei...@thelounge.net To: devel@lists.fedoraproject.org Sent: Tuesday, April 15, 2014 11:40:20 AM Subject: Re: F21 System Wide Change: Workstation: Disable firewall Am 15.04.2014 11:32, schrieb drago01: On Tue, Apr 15, 2014 at 11:18 AM, Reindl Harald h.rei...@thelounge.net wrote: allow any random application to open a unprivlieged port which is reachable from outside is dangerous We already allow that and have for a long while. Any application bothering to support the firewalld dbus interface can open any port they wish to. that is bad enough *but now* we disable any firewall at all? seriously? There was a long thread about this on the desktop mailing list, and I was not in the 'disable the firewall' camp in that discussion, but nobody in that thread or here have articulated how the firewall exactly enhance security in the situation where we at the same time need to allow each user to have any port they desire opened for traffic to make sure things like DLNA or Chromecast works. that is pretty easy - defaults have to be closed anything and the user have to make a choice for, otherwise if there are cirtical security updates after a release you have *exactly* the same as WinXP SP2 try it out on a public reachable IP, you will not survive the time you need to apply the security updates because you are infected long before honestly if these days i would consider switch to linux and unsure which distribution the one proposing disable firewall by default would be the last one on the list signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Taskotron and Cloud Image tests
On Mon, 14 Apr 2014 17:01:49 +0200 Vitaly Kuznetsov vi...@redhat.com wrote: Vitaly Kuznetsov vi...@redhat.com writes: Hi Tim all, snip Yesterday I've tried setting up Taskotron (according to http://roshi.fedorapeople.org/dexy-themed/) on 3 F20 VMs in EC2 and actually I've failed (some ansible playbooks are out-of-sync with some git repos, e.g. 'master playbook' is failing with 'stderr: cp: cannot stat '/home/qaadmin/trigger/jobtrigger.py': No such file or directory' in 'TASK: [copy fedmsg config]'. I totally understand these instructions and repos are rather proof-of-concept and can be slightly outdated but I want to ask about 'minimalistic one-host dev environment' setup anyway. Can 'Host' be eliminated from the setup completely and can we merge Master and Slave (in case we'll need it for 'cloud') on one host? That would help a lot. I'm looking forward to hearing from you. Sorry to bug you again about this, am I completely out of sync with whatever is going on? I would really appreciate your comments.. Hey Vitaly, That tutorial I wrote is pretty out of date since most of the ansible playbooks have been heavily refactored. One of the things I'm going to be working on is updating the tutorial to reflect the changes. As for removing 'Host' from the setup - that could be done (AIUI, but I don't know what the value add would be. Tim would be in a better position to answer about consolidation between Host, Master and Slave. // Mike signature.asc Description: PGP signature ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
[perl-Try-Tiny] Update to 0.21
commit 306ac7adc756e03faa08f7857b657e127c84b7f3
Author: Paul Howarth p...@city-fan.org
Date: Tue Apr 15 15:39:28 2014 +0100
Update to 0.21
- New upstream release 0.21
- Also skip the test if Capture::Tiny is too old
(https://github.com/doy/try-tiny/issues/17)
perl-Try-Tiny.spec |8 +++-
sources|2 +-
2 files changed, 8 insertions(+), 2 deletions(-)
---
diff --git a/perl-Try-Tiny.spec b/perl-Try-Tiny.spec
index 0615658..7c4c7e1 100644
--- a/perl-Try-Tiny.spec
+++ b/perl-Try-Tiny.spec
@@ -3,7 +3,7 @@
Name: perl-Try-Tiny
Summary: Minimal try/catch with proper localization of $@
-Version: 0.20
+Version: 0.21
Release: 1%{?dist}
License: MIT
Group: Development/Libraries
@@ -13,6 +13,7 @@ Patch1: Try-Tiny-0.20-old-Test::More.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
BuildArch: noarch
# Module Build
+BuildRequires: perl
BuildRequires: perl(ExtUtils::MakeMaker) = 6.30
# Module
BuildRequires: perl(Carp)
@@ -78,6 +79,11 @@ rm -rf %{buildroot}
%{_mandir}/man3/Try::Tiny.3pm*
%changelog
+* Tue Apr 15 2014 Paul Howarth p...@city-fan.org - 0.21-1
+- Update to 0.21
+ - Also skip the test if Capture::Tiny is too old
+(https://github.com/doy/try-tiny/issues/17)
+
* Sat Mar 22 2014 Paul Howarth p...@city-fan.org - 0.20-1
- Update to 0.20
- Documentation updates
diff --git a/sources b/sources
index d44e633..a4e102d 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-ee9f0f29d4056fbb07f921255c4a5ccd Try-Tiny-0.20.tar.gz
+98049893c9ce161ba4d1393e00dc8bea Try-Tiny-0.21.tar.gz
--
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: F21 System Wide Change: Fedora 21 Boost 1.56 Uplift
It would be nice to get this done and merged back into rawhide _before_ any mass rebuild. rel-eng ticket to coordinate mass rebuild: https://fedorahosted.org/rel-eng/ticket/5877 kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Remote Journal Logging
On Mon, 2014-04-14 at 15:07 +0200, Jaroslav Reznik wrote: = Proposed Self Contained Change: Remote Journal Logging = The communication between the two daemons is done over standard HTTPS, following rather simple rules, so it is possible to create alternate implementations without much work. For example, curl can be easily used to upload journal entries from a text file containing entries in the export format. Basically, the data are sent in an HTTP POST to /upload with Content- Type: application/vnd.fdo.journal. When doing live forwarding, the size of the transfer cannot be known in advance, so Transfer-Encoding: chunked is used. All communication is encrypted, and the identity of both sides is verified by checking for appropriate signatures on the certificates. HTTP seem like a bad idea in terms of security, certificates are notoriously very hard to manage, even with the help of things like certmonger, and hard to properly validate in most libraries today. Let alone dealing with setting up a CA just for enabling remote logging (or otherwise painfully exchange fingerprints and white list certificates for each client-server pair. And please do not tell me this is deferred to the admin to figure out, because then it would mean this feature cannot seriously be used in normal setups. Is there any reason why a better custom protocol that can be secured using things like SASL or GSSAPI is not used ? Has it been considered ? What are the pros of using HTTP if all you are doing are POSTS to a hardcoded URL ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
On Tue, 2014-04-15 at 08:59 -0500, Michael Catanzaro wrote: On Tue, 2014-04-15 at 14:35 +0200, Zbigniew Jędrzejewski-Szmek wrote: What needs to be done to improve the firewall integration? Zbyszek The rule in the Workstation technical spec is: A firewall in its default configuration may not interfere with the normal operation of programs installed by default. [1] There's a discussion on the desktop list beginning at [2] that has some brainstorming and explanation as to why this would be hard. [1] https://fedoraproject.org/wiki/Workstation/Technical_Specification#Firewall [2] https://lists.fedoraproject.org/pipermail/desktop/2014-February/009142.html Ooh, I say ... firewall is hard, let's eat some popcorns and disable it ... The fact the problem is hard is no excuse to disable it by default. If the workstation WG feels hard about it I could see making it very easy to disable it, like Microsoft does, by having a settings item where you can click a button and turn it off. But disabling it by default is just a regression, and an irresponsible thing to do for machines that are regularly brought on insecure networks (all sorts of open wifi, and foreign LANs). Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: (A)Periodic Updates to Images
On Thu, 10 Apr 2014 16:19:37 +0200 Jaroslav Reznik jrez...@redhat.com wrote: ...snip... We need to be able to produce official updates to the Fedora Cloud images. Initially, we plan to release these updates monthly, but also need the ability to release an out-of-cycle update in the event of a severe security issue. ..snip... Might be good to specify better what a 'severe security issue' is. Perhaps Any update rated important or higher on the severity scale? https://access.redhat.com/site/security/updates/classification/ Also, is the expectation that we would keep all images around forever? Or only the general release and latest image would be kept available and the others would be removed or archived? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Ruby193 in SCL
Dne 15.4.2014 10:21, Vít Ondruch napsal(a): Dne 15.4.2014 02:07, T.C. Hollingsworth napsal(a): On Mon, Apr 14, 2014 at 7:16 AM, Jaroslav Reznik jrez...@redhat.com wrote: Rails depends on exact v8 version, which means v8 3.14 must have also their own SCL as part of the SCL. Stupid question: what in rails depends on v8 exactly? The only thing that Requires v8 in Fedora besides nodejs and mongodb is rubygem-therubyracer, and that FTBFS for the F20 mass rebuild and my recent v8/libicu mini-mass rebuild: http://koji.fedoraproject.org/koji/packageinfo?packageID=14305 I'm in touch with someone from IBM to get PPC support for v8/nodejs (which means no more random failures when nodejs packages get sent to EPEL PPC builders, yay!), which requires finally switching to gyp from scons (which has been deprecated for years now), and so far I've been ignoring ruby in my preliminary work [1] on this since it has been broken for other reasons. The other reasons were update of v8 from 3.13 to 3.14. Vít If you're going to continue to need rubygem-therubyracer, please fix it so I can make sure we don't break it. It is fixed in Rawhide now. Vít (Or at least rebuild it when the time comes. It probably still works in F20 since nothing changed v8-wise since F18, but I wouldn't be surprised if it's completely busted in rawhide right now.) Thanks, -T.C. [1] http://copr.fedoraproject.org/coprs/patches/v8-gyp/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Fedora 21 Make 4.0 Update
This might be another one to make sure and land and iron out any issues before a mass rebuild. https://fedorahosted.org/rel-eng/ticket/5877 kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Ruby193 in SCL
Dne 15.4.2014 17:14, Vít Ondruch napsal(a): Dne 15.4.2014 10:21, Vít Ondruch napsal(a): Dne 15.4.2014 02:07, T.C. Hollingsworth napsal(a): On Mon, Apr 14, 2014 at 7:16 AM, Jaroslav Reznik jrez...@redhat.com wrote: Rails depends on exact v8 version, which means v8 3.14 must have also their own SCL as part of the SCL. Stupid question: what in rails depends on v8 exactly? The only thing that Requires v8 in Fedora besides nodejs and mongodb is rubygem-therubyracer, and that FTBFS for the F20 mass rebuild and my recent v8/libicu mini-mass rebuild: http://koji.fedoraproject.org/koji/packageinfo?packageID=14305 I'm in touch with someone from IBM to get PPC support for v8/nodejs (which means no more random failures when nodejs packages get sent to EPEL PPC builders, yay!), which requires finally switching to gyp from scons (which has been deprecated for years now), and so far I've been ignoring ruby in my preliminary work [1] on this since it has been broken for other reasons. The other reasons were update of v8 from 3.13 to 3.14. Vít If you're going to continue to need rubygem-therubyracer, please fix it so I can make sure we don't break it. It is fixed in Rawhide now. Actually, in f21-ruby side-tag for now. Vít Vít (Or at least rebuild it when the time comes. It probably still works in F20 since nothing changed v8-wise since F18, but I wouldn't be surprised if it's completely busted in rawhide right now.) Thanks, -T.C. [1] http://copr.fedoraproject.org/coprs/patches/v8-gyp/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
On 04/15/2014 04:28 PM, Christian Schaller wrote: - Original Message - From: Reindl Harald h.rei...@thelounge.net To: devel@lists.fedoraproject.org Sent: Tuesday, April 15, 2014 11:40:20 AM Subject: Re: F21 System Wide Change: Workstation: Disable firewall Am 15.04.2014 11:32, schrieb drago01: On Tue, Apr 15, 2014 at 11:18 AM, Reindl Harald h.rei...@thelounge.net wrote: allow any random application to open a unprivlieged port which is reachable from outside is dangerous We already allow that and have for a long while. Any application bothering to support the firewalld dbus interface can open any port they wish to. Are you running your desktop as root or all your applications are authenticated? - I hope not. Only authenticated applications and services can modify the firewall. There was a long thread about this on the desktop mailing list, and I was not in the 'disable the firewall' camp in that discussion, but nobody in that thread or here have articulated how the firewall exactly enhance security in the situation where we at the same time need to allow each user to have any port they desire opened for traffic to make sure things like DLNA or Chromecast works. You can simply use different zones for the different connections you are using. Most likely you do not want to enable DLNA and Chromecast in a public internet cafe, but at home. So simple marking your home Wifi using the trusted zone is the trick to allow everything within this Wifi only. It is also possible to change the zone that is used for a connection. You can bind connections or interfaces to zones in ifcfg files and in NetworkManager - probably not in the gnome 3 UI, but in all other UI versions ... The thread discussing this ended up with mostly being a discussion if the firewall would be a useful way to help users from accidentally oversharing on a public network. Which is important and something we want to work on, but a lot less so than security issues. Christian Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Remote Journal Logging
To be clear here, all this is implemented in the two daemons right? When you say it uses https, thats natively done in the daemons, they don't need apache or some other https implementor in the way? Which ssl stack does this use? nss? openssl? gnutls? something else? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1087334] perl-Net-Twitter-4.01004 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1087334 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System upda...@fedoraproject.org --- Package perl-Net-Twitter-4.01004-1.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-Net-Twitter-4.01004-1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-5046/perl-Net-Twitter-4.01004-1.fc19 then log in and leave karma (feedback). -- 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=nd3lz37ILPa=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: F21 System Wide Change: Cockpit Management Console
...snip... Special Requests: Cockpit would like to request an additional 2-4 weeks on the Fedora 21 schedule to ensure completion of the core functionality. So, you want to push final release out to november? Or can you expand on what you mean by 'on the Fedora 21 schedule' ? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
On 04/15/2014 04:42 PM, Reindl Harald wrote: Am 15.04.2014 16:28, schrieb Christian Schaller: - Original Message - From: Reindl Harald h.rei...@thelounge.net To: devel@lists.fedoraproject.org Sent: Tuesday, April 15, 2014 11:40:20 AM Subject: Re: F21 System Wide Change: Workstation: Disable firewall Am 15.04.2014 11:32, schrieb drago01: On Tue, Apr 15, 2014 at 11:18 AM, Reindl Harald h.rei...@thelounge.net wrote: allow any random application to open a unprivlieged port which is reachable from outside is dangerous We already allow that and have for a long while. Any application bothering to support the firewalld dbus interface can open any port they wish to. that is bad enough *but now* we disable any firewall at all? seriously? Only authenticated applications can change firewall settings like for example open ports, ... There was a long thread about this on the desktop mailing list, and I was not in the 'disable the firewall' camp in that discussion, but nobody in that thread or here have articulated how the firewall exactly enhance security in the situation where we at the same time need to allow each user to have any port they desire opened for traffic to make sure things like DLNA or Chromecast works. that is pretty easy - defaults have to be closed anything and the user have to make a choice for, otherwise if there are cirtical security updates after a release you have *exactly* the same as WinXP SP2 try it out on a public reachable IP, you will not survive the time you need to apply the security updates because you are infected long before honestly if these days i would consider switch to linux and unsure which distribution the one proposing disable firewall by default would be the last one on the list -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Enable Software Collections
On 04/15/2014 02:37 PM, Rahul Sundaram wrote: HI On Tue, Apr 15, 2014 at 8:30 AM, Tadej Janež wrote: Does the above refer to the repositories available at https://www.softwarecollections.org/en/? Yes. So this change can be re-stated like Workstation product will have SCLs from www.softwarecollections.org enabled by default? If so or not, I'm probably missing concrete use cases. Do you need some particular collections for the Workstation product? Also please note that the list of SCLs available at https://www.softwarecollections.org can change in time. You may find better control about the collections using copr + playground combination. Regards, Honza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
users running applications which opening a high port in the background like license checks and so on (as example ZendStudio) will be really thankful that as default these ports are open on the WAN Why does it listen on a port for license checks? It should just contact the server and not the other way. Besides no one is stopping you from enabling the firewall. I'm going to jump into this thread here (I'm not purposely picking on this singular point). So when we have to think about security, the mindset needs to be secure by default. We shouldn't tell people they *can* enable the firewall, we tell them the can disable it. While I will agree that in a perfect world we shouldn't need a firewall, we don't live in a perfect world. Applications have bugs, they have default logins, they listen on ports they shouldn't, users have bad passwords, they have public shared folders, the list can go on for a very very long time. A firewall is an easy win here. Fedora needs to keep in mind is the safety of our users. We've lived up to this point with a firewall enabled. The solution is to fix the firewall, not disable it. If we just disable the firewall, what is our incentive to fix it? Please don't disable the firewall, it's almost certainly not the right decision, and I'm pretty sure we'll end up wishing we'd not disabled it sooner or later. Thanks. -- Josh Bressers / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
On Tue, Apr 15, 2014 at 7:42 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 15.04.2014 16:28, schrieb Christian Schaller: There was a long thread about this on the desktop mailing list, and I was not in the 'disable the firewall' camp in that discussion, but nobody in that thread or here have articulated how the firewall exactly enhance security in the situation where we at the same time need to allow each user to have any port they desire opened for traffic to make sure things like DLNA or Chromecast works. that is pretty easy - defaults have to be closed anything and the user have to make a choice for, otherwise if there are cirtical security updates after a release you have *exactly* the same as WinXP SP2 WinXP SP2 needed a firewall because MS didn't want to close ports 139 and 445 for real. So instead they hacked it up with a firewall. This meant that, if you had the firewall blocking those ports, you were okay, but if they were open (e.g. because you were at home), you were screwed. This is *not* a good thing. Can someone explain what threat is effectively mitigated by a firewall on a workstation machine? Here are some bad answers: - Being pwned via MS's notoriously insecure SMB stack? Not actually a problem for Fedora. - WebRTC, VOIP, etc. issues? These use NAT traversal techniques that are specifically designed to prevent your firewall from operating as intended. - DLNA / Chromecast / whatever: wouldn't it be a lot more sensible for these things to be off until specifically requested? Who actually uses a so-called zone UI correctly to configure them? How about having an API where things like DLNA can simply not run until you're connected to your home network? Also, having a firewall on exposes you to a huge attack surface in iptables, and it doesn't protect against attacks targeting the kernel's IP stack. I'm all for secure by default, but I'm not at all convinced that current desktop firewalls add any real security. --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
rpcbind is enabled by default, and gnome-boxes requires it
I don't know whether this should be a gnome-boxes bug, an rpcbind bug, or a FESCo ticket, or something else, so I'm asking here. rpcbind enables itself by default. This page says that it has a specific exception, so it's okay: https://fedoraproject.org/wiki/Starting_services_by_default I assume that the exception comes from the idea that server systems probably want it on if they've installed it. That may make sense in some contexts. Alas, libvirt-daemon-kvm requires libvirt-daemon-driver-storage, which requires nfs-utils, and nfs-utils requires rpcbind. gnome-boxes, in turn, requires libvirt-daemon-kvm, resulting in this: tcp0 0 0.0.0.0:111 0.0.0.0:* LISTEN 774/rpcbind tcp0 0 0.0.0.0:20048 0.0.0.0:* LISTEN 887/rpc.mountd tcp0 0 0.0.0.0:875 0.0.0.0:* LISTEN 930/rpc.rquotad *on my laptop* IMO this is bad. Should I file a FESCo ticket asking to revoke the rpcbind and nfs-utils exceptions? Should I file a bug against libvirt? --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Playground repository
...snip... Packages for the repository are built in COPR. The COPR owner can propose the repository as a whole for inclusion into the Playground repository by marking it as such in COPR. Repositories/packages successfully built and satisfying the Playground repository's Policies are copied into the Playgroud repository. The one Playground repository includes many Copr repositories. I'm a bit confused here. Is there another repo that all playground packages are copied to? Or are they just seperate copr repos? Ok, on further reading there is a seperate repo. This would be mirrored? How is is composed? Just a simple pull all packages from these copr's and createrepo? Will it support multilib, signing, drpms or updateinfo? I see mention that multilib isn't planned at first and that you want to use obs-signd to sign packages. Wouldn't it make sense to look at just using mash (which we use for all other composes). If you did that we could look at signing with sigul and you could get multilib/drpms/etc along for the ride? To avoid any potential confusion, we want to make it clear that the Playground repository will not host packages that have bad licenses, include proprietary software or include patented software. Might change this to all packages advertised in the playground must meet the same legal guidelines as packages in Fedora proper. Some software we ship does have patents, just ones that have patent grants attached. Can you expand on: The repository's repodata is continuously regenerated. All the builds in the COPR repositories that are selected to feed the Playground repository are composed once a day and pushed to the Playground repository and its mirrors. Is the repo composed once a day? Or everytime there is a new build? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Enable Software Collections
Are there plans to show SCL's in gnome-software as well, or is that drifting too far from 'applications' ? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
On Tue, Apr 15, 2014 at 11:40 AM, Andrew Lutomirski l...@mit.edu wrote: On Tue, Apr 15, 2014 at 7:42 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 15.04.2014 16:28, schrieb Christian Schaller: There was a long thread about this on the desktop mailing list, and I was not in the 'disable the firewall' camp in that discussion, but nobody in that thread or here have articulated how the firewall exactly enhance security in the situation where we at the same time need to allow each user to have any port they desire opened for traffic to make sure things like DLNA or Chromecast works. that is pretty easy - defaults have to be closed anything and the user have to make a choice for, otherwise if there are cirtical security updates after a release you have *exactly* the same as WinXP SP2 WinXP SP2 needed a firewall because MS didn't want to close ports 139 and 445 for real. So instead they hacked it up with a firewall. This meant that, if you had the firewall blocking those ports, you were okay, but if they were open (e.g. because you were at home), you were screwed. This is *not* a good thing. Can someone explain what threat is effectively mitigated by a firewall on a workstation machine? Here are some bad answers: - Being pwned via MS's notoriously insecure SMB stack? Not actually a problem for Fedora. - WebRTC, VOIP, etc. issues? These use NAT traversal techniques that are specifically designed to prevent your firewall from operating as intended. - DLNA / Chromecast / whatever: wouldn't it be a lot more sensible for these things to be off until specifically requested? Who actually uses a so-called zone UI correctly to configure them? How about having an API where things like DLNA can simply not run until you're connected to your home network? Also, having a firewall on exposes you to a huge attack surface in iptables, and it doesn't protect against attacks targeting the kernel's IP stack. I'm all for secure by default, but I'm not at all convinced that current desktop firewalls add any real security. Ideally, users would have complete knowledge of the behavior of every piece of software in their system that utilizes the network, in which case, they could very easily get by without a firewall. However, that is not a reasonable expectation. A firewall protects users with incomplete knowledge of their software. Example: user installs software X... but oops, they didn't realize it was going to listen on port Y but that's okay, because no firewall rule has been enabled to allow traffic on port Y, so the user is secure. Even worse: user installs software X, but which has no network features so the user feels safe, but oops, it depends on system service Y, which does open network ports, was previously disabled, but is now turned on by software X. Firewalls protect against this sort of incomplete user knowledge. What if software Y only enables the network periodically, to perform some maintenance function? Even a pedantic user checking netstat isn't necessarily going to notice network services listening on ports periodically. Then, of course, there's separation of responsibilities. A network admin at a company might care about firewall configuration, but permits actual workstation user might just run/install whatever software they like. I'm a bit surprised that a case must be made to demonstrate that firewalls provide real security, in 2014, but hopefully these examples provide some demonstration that they do add real security. (Note, I realize that in each of these cases, a firewall could be turned on after the fact. These examples are to show the value of firewalls, which is being questioned, not the value of having them turned on by default. That's a different argument.) --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: rpcbind is enabled by default, and gnome-boxes requires it
On Tue, 2014-04-15 at 08:47 -0700, Andrew Lutomirski wrote: I don't know whether this should be a gnome-boxes bug, an rpcbind bug, or a FESCo ticket, or something else, so I'm asking here. rpcbind enables itself by default. This page says that it has a specific exception, so it's okay: https://fedoraproject.org/wiki/Starting_services_by_default I assume that the exception comes from the idea that server systems probably want it on if they've installed it. That may make sense in some contexts. Alas, libvirt-daemon-kvm requires libvirt-daemon-driver-storage, which requires nfs-utils, and nfs-utils requires rpcbind. gnome-boxes, in turn, requires libvirt-daemon-kvm, resulting in this: tcp0 0 0.0.0.0:111 0.0.0.0:* LISTEN 774/rpcbind tcp0 0 0.0.0.0:20048 0.0.0.0:* LISTEN 887/rpc.mountd tcp0 0 0.0.0.0:875 0.0.0.0:* LISTEN 930/rpc.rquotad *on my laptop* IMO this is bad. Should I file a FESCo ticket asking to revoke the rpcbind and nfs-utils exceptions? Should I file a bug against libvirt? Shouldn't rpcbind be simply a dependency for nfs-server.service/nfs-secure-server.service and be started only if the nfs server is started ? I forgot if we need it for anything else. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: (A)Periodic Updates to Images
On Tue, Apr 15, 2014 at 09:07:47AM -0600, Kevin Fenzi wrote: Might be good to specify better what a 'severe security issue' is. Perhaps Any update rated important or higher on the severity scale? https://access.redhat.com/site/security/updates/classification/ Yeah, that needs to be worked out. If you think it needs to be worked out as part of the initial change proposal, I will try to get on doing that. I think it might be a little narrower than any important -- maybe any critical + any important likely to affect cloud users in common configurations. Off the top of my head, probably would not update for local DoS attacks (keeping in mind of course that yum update would be available.) Also, is the expectation that we would keep all images around forever? Or only the general release and latest image would be kept available and the others would be removed or archived? I think we would treat them like update RPMs on the mirrors -- older updates time out eventually. But good question that Fedora Infrastructure could help answer :). What *can* we keep? -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
On Tue, Apr 15, 2014 at 9:04 AM, Christopher ctubb...@apache.org wrote: On Tue, Apr 15, 2014 at 11:40 AM, Andrew Lutomirski l...@mit.edu wrote: On Tue, Apr 15, 2014 at 7:42 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 15.04.2014 16:28, schrieb Christian Schaller: There was a long thread about this on the desktop mailing list, and I was not in the 'disable the firewall' camp in that discussion, but nobody in that thread or here have articulated how the firewall exactly enhance security in the situation where we at the same time need to allow each user to have any port they desire opened for traffic to make sure things like DLNA or Chromecast works. that is pretty easy - defaults have to be closed anything and the user have to make a choice for, otherwise if there are cirtical security updates after a release you have *exactly* the same as WinXP SP2 WinXP SP2 needed a firewall because MS didn't want to close ports 139 and 445 for real. So instead they hacked it up with a firewall. This meant that, if you had the firewall blocking those ports, you were okay, but if they were open (e.g. because you were at home), you were screwed. This is *not* a good thing. Can someone explain what threat is effectively mitigated by a firewall on a workstation machine? Here are some bad answers: - Being pwned via MS's notoriously insecure SMB stack? Not actually a problem for Fedora. - WebRTC, VOIP, etc. issues? These use NAT traversal techniques that are specifically designed to prevent your firewall from operating as intended. - DLNA / Chromecast / whatever: wouldn't it be a lot more sensible for these things to be off until specifically requested? Who actually uses a so-called zone UI correctly to configure them? How about having an API where things like DLNA can simply not run until you're connected to your home network? Also, having a firewall on exposes you to a huge attack surface in iptables, and it doesn't protect against attacks targeting the kernel's IP stack. I'm all for secure by default, but I'm not at all convinced that current desktop firewalls add any real security. Ideally, users would have complete knowledge of the behavior of every piece of software in their system that utilizes the network, in which case, they could very easily get by without a firewall. However, that is not a reasonable expectation. A firewall protects users with incomplete knowledge of their software. Example: user installs software X... but oops, they didn't realize it was going to listen on port Y but that's okay, because no firewall rule has been enabled to allow traffic on port Y, so the user is secure. This sounds like a problem that should be separately fixed. Even in the current state of affairs, either software X doesn't support firewalld, in which case we have the problem that caused this change request in the first place, or it does support firewalld, in which case it's unlikely that there will be a benefit. Even worse: user installs software X, but which has no network features so the user feels safe, but oops, it depends on system service Y, which does open network ports, was previously disabled, but is now turned on by software X. Firewalls protect against this sort of incomplete user knowledge. What if software Y only enables the network periodically, to perform some maintenance function? Even a pedantic user checking netstat isn't necessarily going to notice network services listening on ports periodically. Arguably this should also be fixed by cleaning up all those network services. With firewalls, a service, system or otherwise, can be in one of three states: a) listening w/ firewall open, b) listening w/ firewall closed, c) and not listening. c is secure regardless. a is equally secure regardless. b is IMO just broken. Yes, a firewall can work around case b, at the cost of a lot of UI hassles and incomprehensible failures, but I think it's a crappy solution. I keep thinking that, if I had unlimited time, I'd write a totally different kind of firewall. It would allow some policy (userspace daemon or rules loaded into the kernel) to determine when programs can listen on what sockets and when connections can be accepted on those sockets. This avoids the attack surface of iptables, it will be faster, it can cause programs to actually report errors if you want them to, and it could be a lot easier to configure. Wouldn't it be great if, when you start some program that wants to listen globally, your system could prompt you and ask whether it was okay, even if that program didn't know about firewalld? Then, of course, there's separation of responsibilities. A network admin at a company might care about firewall configuration, but permits actual workstation user might just run/install whatever software they like. Fedora's default configuration will never solve that. I'm a bit surprised that a case must be made
Re: rpcbind is enabled by default, and gnome-boxes requires it
On Tue, Apr 15, 2014 at 9:07 AM, Simo Sorce s...@redhat.com wrote: On Tue, 2014-04-15 at 08:47 -0700, Andrew Lutomirski wrote: I don't know whether this should be a gnome-boxes bug, an rpcbind bug, or a FESCo ticket, or something else, so I'm asking here. rpcbind enables itself by default. This page says that it has a specific exception, so it's okay: https://fedoraproject.org/wiki/Starting_services_by_default I assume that the exception comes from the idea that server systems probably want it on if they've installed it. That may make sense in some contexts. Alas, libvirt-daemon-kvm requires libvirt-daemon-driver-storage, which requires nfs-utils, and nfs-utils requires rpcbind. gnome-boxes, in turn, requires libvirt-daemon-kvm, resulting in this: tcp0 0 0.0.0.0:111 0.0.0.0:* LISTEN 774/rpcbind tcp0 0 0.0.0.0:20048 0.0.0.0:* LISTEN 887/rpc.mountd tcp0 0 0.0.0.0:875 0.0.0.0:* LISTEN 930/rpc.rquotad *on my laptop* IMO this is bad. Should I file a FESCo ticket asking to revoke the rpcbind and nfs-utils exceptions? Should I file a bug against libvirt? Shouldn't rpcbind be simply a dependency for nfs-server.service/nfs-secure-server.service and be started only if the nfs server is started ? rpcbind has this script: postinstall scriptlet (using /bin/sh): if [ $1 -eq 1 ] ; then # Initial installation /bin/systemctl enable rpcbind.service /dev/null 21 || : fi nfs-utils has this script (excerpted): postinstall scriptlet (using /bin/sh): if [ $1 -eq 1 ]; then # Package install, /bin/systemctl enable nfs.target /dev/null 21 || : /bin/systemctl enable nfs-lock.service /dev/null 21 || : /bin/systemctl start nfs-lock.service /dev/null 21 || : nfs-utils is also pulled in by libvirt. Why is nfs special enough to deserve this kind of automatic enablement? I would argue that nfs requires so much manual configuration in order to do anything useful that requiring admins to turn it on would be just fine. --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: rpcbind is enabled by default, and gnome-boxes requires it
On Tue, Apr 15, 2014 at 09:16:29AM -0700, Andrew Lutomirski wrote: rpcbind has this script: postinstall scriptlet (using /bin/sh): if [ $1 -eq 1 ] ; then # Initial installation /bin/systemctl enable rpcbind.service /dev/null 21 || : fi nfs-utils has this script (excerpted): postinstall scriptlet (using /bin/sh): if [ $1 -eq 1 ]; then # Package install, /bin/systemctl enable nfs.target /dev/null 21 || : /bin/systemctl enable nfs-lock.service /dev/null 21 || : /bin/systemctl start nfs-lock.service /dev/null 21 || : nfs-utils is also pulled in by libvirt. Why is nfs special enough to deserve this kind of automatic enablement? I would argue that nfs requires so much manual configuration in order to do anything useful that requiring admins to turn it on would be just fine. It isn't special. It looks like it's using older RPM snippets. Current snippets act accordingly to system preset. Fedora default preset does not enable NFS. -- Tomasz .. oo o. oo o. .o .o o. o. oo o. .. Torcz.. .o .o .o .o oo oo .o .. .. oo oo o.o.o. .o .. o. o. o. o. o. o. oo .. .. o. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Spec files in Rawhide using ExclusiveArch: %{ocaml_arches}
On Tue, Apr 15, 2014 at 11:26:58AM +0100, Richard W.M. Jones wrote:
So you could use this instead if you need the native compiler:
ExclusiveArch: %{ocaml_native_compiler}
I should have said that if you have to do this, it's very likely to be
a bug. There are *very* few reasons why a package would work only
with the native compiler.
If you find a package that you think doesn't work on bytecode-only
platforms, ping me and I will take a look at it.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Python 3 and mod_wsgi
On Mon, Apr 14, 2014 at 04:54:33PM -0400, Bohuslav Kabrda wrote: ━━━ I naively ported my Django app to Python 3 and didn't realize WSGI was going to be an issue. I saw python3-django was available for Fedora 20 and thought I was all set until I saw in my httpd logs that python2.7 seems to be the assumed default for mod_wsgi. After reading the README and more, I see the writing on the wall: If you have multiple versions of Python installed and you are not using that which is the default, you may have to organise that the PATH inherited by the Apache application when run will result in Apache finding the alternate version. Alternatively, the WSGIPythonHome directive should be used to specify the exact location of the Python installation corresponding to the version of Python compiled against. If this is not done, the version of Python running within Apache may attempt to use the Python modules from the wrong version of Python. I take this to mean that merely fiddling with WSGIPythonHome alone will be insufficient and that I would need to recompile the package. Is that correct, or did I miss a Python3-specific mod_wsgi package or some other neater solution? If I am truly forced to recompile -- as reversing the Python 3 is really undesirable at this point -- is there any reason Fedora couldn't have two mod_wsgi packages (one for Python2 and another for Python3)? AFAIK you can't have 2 mod_wsgi's, each one compiled against a different Python major.minor, loaded by Apache at the same time for various reasons. So the best solution would IMO be to create python3-mod_wsgi (subpackage of mod_wsgi), that would conflict with mod_wsgi. It should be perfectly doable and it shouldn't break anything. CCing Matthias, the owner of mod_wsgi in Fedora - Matthias, what do you think? It's available in rawhide already and uses the conflicts that you outline: http://koji.fedoraproject.org/koji/buildinfo?buildID=493296 https://bugzilla.redhat.com/show_bug.cgi?id=1007002 However, conflicts aren't the correct strategy here. Instead, take a look at how the python26-mod_wsgi package is implemented for epel5. The two mod_wsgi packages should be parallel installable. But the apache config files should prevent both from being loaded into a single apache process. Here's the config file for the python26-mod_wsgi package as a example of this: # NOTE: By default python26-mod_python with not load if mod_wsgi is # installed and enabled. Only load if mod_python and mod_wsgi are not # already loaded. IfModule !wsgi_module LoadModule wsgi_module modules/python26-mod_wsgi.so /IfModule We should probably have a similar guard in the mod_wsgi config file as well. Then be sure that we consciously name the conf files so that we are promoting one of these as the default (because sort order will load one of them before the other) if both packages are installed. Having both packages be parallel installable makes it easier for people who are willing to configure apache to start two separate instances of apache. The two instances could each run a different version of mod_wsgi by adding the correct mod_wsgi config for each. Bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=1087943 -Toshio pgp04t4ERgkAq.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
I think you and I disagree that b is broken. In my mind b (listening w/firewall closed) is precisely what the firewall is designed to do... act as a failsafe in the event of an unexpected application listening when a user doesn't really know or want it to. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, Apr 15, 2014 at 12:13 PM, Andrew Lutomirski l...@mit.edu wrote: On Tue, Apr 15, 2014 at 9:04 AM, Christopher ctubb...@apache.org wrote: On Tue, Apr 15, 2014 at 11:40 AM, Andrew Lutomirski l...@mit.edu wrote: On Tue, Apr 15, 2014 at 7:42 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 15.04.2014 16:28, schrieb Christian Schaller: There was a long thread about this on the desktop mailing list, and I was not in the 'disable the firewall' camp in that discussion, but nobody in that thread or here have articulated how the firewall exactly enhance security in the situation where we at the same time need to allow each user to have any port they desire opened for traffic to make sure things like DLNA or Chromecast works. that is pretty easy - defaults have to be closed anything and the user have to make a choice for, otherwise if there are cirtical security updates after a release you have *exactly* the same as WinXP SP2 WinXP SP2 needed a firewall because MS didn't want to close ports 139 and 445 for real. So instead they hacked it up with a firewall. This meant that, if you had the firewall blocking those ports, you were okay, but if they were open (e.g. because you were at home), you were screwed. This is *not* a good thing. Can someone explain what threat is effectively mitigated by a firewall on a workstation machine? Here are some bad answers: - Being pwned via MS's notoriously insecure SMB stack? Not actually a problem for Fedora. - WebRTC, VOIP, etc. issues? These use NAT traversal techniques that are specifically designed to prevent your firewall from operating as intended. - DLNA / Chromecast / whatever: wouldn't it be a lot more sensible for these things to be off until specifically requested? Who actually uses a so-called zone UI correctly to configure them? How about having an API where things like DLNA can simply not run until you're connected to your home network? Also, having a firewall on exposes you to a huge attack surface in iptables, and it doesn't protect against attacks targeting the kernel's IP stack. I'm all for secure by default, but I'm not at all convinced that current desktop firewalls add any real security. Ideally, users would have complete knowledge of the behavior of every piece of software in their system that utilizes the network, in which case, they could very easily get by without a firewall. However, that is not a reasonable expectation. A firewall protects users with incomplete knowledge of their software. Example: user installs software X... but oops, they didn't realize it was going to listen on port Y but that's okay, because no firewall rule has been enabled to allow traffic on port Y, so the user is secure. This sounds like a problem that should be separately fixed. Even in the current state of affairs, either software X doesn't support firewalld, in which case we have the problem that caused this change request in the first place, or it does support firewalld, in which case it's unlikely that there will be a benefit. Even worse: user installs software X, but which has no network features so the user feels safe, but oops, it depends on system service Y, which does open network ports, was previously disabled, but is now turned on by software X. Firewalls protect against this sort of incomplete user knowledge. What if software Y only enables the network periodically, to perform some maintenance function? Even a pedantic user checking netstat isn't necessarily going to notice network services listening on ports periodically. Arguably this should also be fixed by cleaning up all those network services. With firewalls, a service, system or otherwise, can be in one of three states: a) listening w/ firewall open, b) listening w/ firewall closed, c) and not listening. c is secure regardless. a is equally secure regardless. b is IMO just broken. Yes, a firewall can work around case b, at the cost of a lot of UI hassles and incomprehensible failures, but I think it's a crappy solution. I keep thinking that, if I had unlimited time, I'd write a totally different kind of firewall. It would allow some policy (userspace daemon or rules loaded into the kernel) to determine when programs can listen on what sockets and when connections can be accepted on those sockets. This avoids the attack surface of iptables, it will be faster, it can cause programs to actually report errors if you want them to, and it could be a lot easier to configure. Wouldn't it be great if, when you start some program that wants to listen globally, your system could
Re: rpcbind is enabled by default, and gnome-boxes requires it
On Tue, 2014-04-15 at 09:16 -0700, Andrew Lutomirski wrote: On Tue, Apr 15, 2014 at 9:07 AM, Simo Sorce s...@redhat.com wrote: On Tue, 2014-04-15 at 08:47 -0700, Andrew Lutomirski wrote: I don't know whether this should be a gnome-boxes bug, an rpcbind bug, or a FESCo ticket, or something else, so I'm asking here. rpcbind enables itself by default. This page says that it has a specific exception, so it's okay: https://fedoraproject.org/wiki/Starting_services_by_default I assume that the exception comes from the idea that server systems probably want it on if they've installed it. That may make sense in some contexts. Alas, libvirt-daemon-kvm requires libvirt-daemon-driver-storage, which requires nfs-utils, and nfs-utils requires rpcbind. gnome-boxes, in turn, requires libvirt-daemon-kvm, resulting in this: tcp0 0 0.0.0.0:111 0.0.0.0:* LISTEN 774/rpcbind tcp0 0 0.0.0.0:20048 0.0.0.0:* LISTEN 887/rpc.mountd tcp0 0 0.0.0.0:875 0.0.0.0:* LISTEN 930/rpc.rquotad *on my laptop* IMO this is bad. Should I file a FESCo ticket asking to revoke the rpcbind and nfs-utils exceptions? Should I file a bug against libvirt? Shouldn't rpcbind be simply a dependency for nfs-server.service/nfs-secure-server.service and be started only if the nfs server is started ? rpcbind has this script: postinstall scriptlet (using /bin/sh): if [ $1 -eq 1 ] ; then # Initial installation /bin/systemctl enable rpcbind.service /dev/null 21 || : fi nfs-utils has this script (excerpted): postinstall scriptlet (using /bin/sh): if [ $1 -eq 1 ]; then # Package install, /bin/systemctl enable nfs.target /dev/null 21 || : /bin/systemctl enable nfs-lock.service /dev/null 21 || : /bin/systemctl start nfs-lock.service /dev/null 21 || : nfs-utils is also pulled in by libvirt. Why is nfs special enough to deserve this kind of automatic enablement? I would argue that nfs requires so much manual configuration in order to do anything useful that requiring admins to turn it on would be just fine. Probably remnants of a past where we did not have dependencies on sysv. I do not think these rules make sense anymore. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
On Tue, 2014-04-15 at 09:13 -0700, Andrew Lutomirski wrote: I keep thinking that, if I had unlimited time, I'd write a totally different kind of firewall. It would allow some policy (userspace daemon or rules loaded into the kernel) to determine when programs can listen on what sockets and when connections can be accepted on those sockets. This avoids the attack surface of iptables, it will be faster, it can cause programs to actually report errors if you want them to, and it could be a lot easier to configure. Wouldn't it be great if, when you start some program that wants to listen globally, your system could prompt you and ask whether it was okay, even if that program didn't know about firewalld? I think what you are describing could be probably realized with SELinux today, just with a special setroubleshoot frontend that catches the AVC when the service tries to listen and ask the user if he wants to allow it. However this would still not be completely sufficient as you completely lack any context about what network you are operating on. The firewall's purpose is to block access to local services on bad networks too, it is not a binary open/close equation when you have machines (laptops) that roam across a variety of networks. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
On 15.04.2014 11:40, Reindl Harald wrote: it is not a point of *what i can do and do* it is a point what the ordinary 08/15 user does which assumes to have a by default secure system after install Fedora is not for ordinary users. Fedora is for geeks and developers that like to experiment with a new software. Ordinary users use Windows and iOS (sometimes RHEL). Averedge Fedora user should be able to enable/disable firewall and justify if he needs such thing. So this decision about disabling fw be default is complitelly not important from security point of view. You can alway drop some iptables rules to your rc.local script. Mateusz Marzantowicz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
