devel February 2014

devel@lists.fedoraproject.org

223 participants
212 discussions

Strange ssh / openldap linking problem
by Richard W.M. Jones 21 Mar '14

21 Mar '14

I'm not sure whether or not this is a bug, but it sure looks strange. $ rpm -qf /usr/bin/ssh openssh-clients-6.1p1-6.fc18.x86_64 $ ldd /usr/bin/ssh|grep ldap libldap-2.4.so.2 => /lib64/libldap-2.4.so.2 (0x00007fad274fc000) /usr/lib64/libldap-2.4.so.2 is a symbolic link to a symbolic link which passes through a -devel package. /usr/lib64/libldap-2.4.so.2 -> libldap.so # openldap-2.4.34-1.fc18 /usr/lib64/libldap.so -> libldap-2.4.so.2.9.0 # openldap-devel-2.4.34-1.fc18 /usr/lib64/libldap-2.4.so.2.9.0 is a real file # openldap-2.4.34-1.fc18 To cut a long story short, I fixed this by uninstalling openldap-devel and reinstalling it. Now there is no -devel package in the chain: $ ldd /usr/bin/ssh | grep ldap libldap-2.4.so.2 => /lib64/libldap-2.4.so.2 (0x00007fe8caf69000) /lib64/libldap-2.4.so.2 -> libldap-2.4.so.2.9.0 I'd like to understand how the original situation happened, because it broke a supermin-built appliance (RHBZ#954185). I assume ldconfig must have something to do with it. There is nothing unusual in the %scripts of openldap (it just runs ldconfig as you'd expect), nor is there any special openssh/openldap config file in /etc/ld.so.conf.d. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/

3 7

F21 System Wide Change: Ruby 2.1
by Jaroslav Reznik 17 Mar '14

17 Mar '14

= Proposed System Wide Change: Ruby 2.1 = https://fedoraproject.org/wiki/Changes/Ruby_2.1 Change owner(s): Vít Ondruch <vondruch(a)redhat.com> Ruby 2.1 is the latest stable version of Ruby, with major increases in speed, memory efficiency and reliability. With this major update from Ruby 2.0.0 in Fedora 20 to Ruby 2.1 in Fedora 21, alongside JRuby, Fedora becomes the superior Ruby development platform. == Detailed Description == Ruby 2.1 is upstream's new major release of Ruby. Notable changes are: * VM (method cache) * RGenGC * refinements * syntax changes ** Rational/Complex Literal ** def’s return value * Bignum use GMP * String#scrub * Socket.getifaddrs * RDoc 4.1.0 and RubyGems 2.2.0 * “literal”.freeze is now optimized * add Exception#cause * update libraries like BigDecimal, JSON, NKF and Rake * remove curses Please also note, that Ruby moved to semantic versioning since this version. Yet, it is source level backward compatible with Ruby 2.0.0, so your software will continue to work. == Scope == * Proposal owners: ** Update of Packaging Guidelines for Ruby packages. This needs to reflect recent changes introduced by recent version of RubyGems shipped with Ruby 2.1. ** Rebuilding of Ruby packages providing native extensions (i.e. packages which depends on libruby), including changes needed by updated packaging guidelines. * Other developers: N/A * Release engineering: ** Rebuilding of Ruby packages providing native extensions (i.e. packages which depends on libruby), including changes needed by updated packaging guidelines. * Policies and guidelines: ** Update of Packaging Guidelines for Ruby packages. This needs to reflect recent changes introduced by recent version of RubyGems shipped with Ruby 2.1. _______________________________________________ devel-announce mailing list devel-announce(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce

4 7

Java headless bugs
by Jerry James 17 Mar '14

17 Mar '14

I've got a few comments and questions about the recently filed bugs asking us to switch from Requires: java to Requires: java-headless. First, the bugs list some web pages to view for more information. Number two on that list is this: https://fedoraproject.org/wiki/Packaging:Java\#BuildRequires_and_Requires which has a really unfortunate backslash in it. People clicking on that link get a "sorry, no such page" message from the web server. It should have been this: https://fedoraproject.org/wiki/Packaging:Java#BuildRequires_and_Requires Second, the bugs talk about this as a proposed guidelines change, yet https://fedoraproject.org/wiki/Packaging:Java now talks about it. Doesn't that mean that this is an official guideline, not a proposed change to the official gudelines? Third, developers are offered two options in those bugs: (1) don't do anything and an automatic tool will make the change for you on or after March 17, or (2) make the change to java-headless yourself. I have one package for which I need a third option: tell the automated tool that this bug was filed in error, the package really doesn't work with java-headless, and don't touch the package. I realize that I can mark the bug as assigned and leave it open indefinitely, but I'd rather have some option for closing the bug, please. Slightly off-topic: fedora-review is telling packagers NOT to add "Requires: jpackage-utils" to javadoc subpackages because that is added automatically, but I see no mention of this on https://fedoraproject.org/wiki/Packaging:Java. Thanks, -- Jerry James http://www.jamezone.org/

6 13

exclude people from giving karma?
by Reindl Harald 10 Mar '14

10 Mar '14

https://admin.fedoraproject.org/updates/FEDORA-2014-2922/libreoffice-4.2.1.… how can people pretend "installation went smoothly, no issue detected during basic document manipulation" for packages which are not installable at all due dependencie problems?

13 42

Packages installing files to /etc/rpm
by Ville Skyttä 09 Mar '14

09 Mar '14

A number of packages install files to /etc/rpm in Rawhide; the proper place for macros.* is /usr/lib/rpm/macros.d for rpm >= 4.11. And no matter what the location, these files should not be marked as %config. Specfiles not targeting EL < 7 can simply replace %{_sysconfdir}/rpm with %{_rpmconfigdir}/macros.d and ones that wish to stay compatible with EL5 and 6 can do something like this to find the proper dir: %global macrosdir %(d=%{_rpmconfigdir}/macros.d; [ -d $d ] || d=%{_sysconfdir}/rpm; echo $d) List of affected packages follows (maintainer package comaintainers): bkabrda python3 amcnabb,bkabrda,mstuchli,tomspur bkabrda python bkabrda,dmalcolm,ivazquez,jsteffan,mstuchli,tomspur,tradej cicku ldc bioinfornatics deji mpich (none) dledford openmpi dajt,deji,orion epienbro mingw-filesystem ivanromanov,kalev,rjones erikos sugar-toolkit erikos,pbrobinson,sdz,tomeu erikos sugar-toolkit-gtk3 dsd,pbrobinson jakub prelink mjw jcapik octave alexlan,fkluknav,jussilehtola,mmahut,orion,rakesh jjames ffcall salimma jjames gap (none) jjames xemacs stevetraylen jnovy texlive pertusus,than jorton httpd hubbitus,jkaluza jorton php-pear remi,timj jorton php remi jplesnik perl corsepiu,cweyl,iarnell,jplesnik,kasal,perl-sig,ppisar,psabata,spot jussilehtola libint (none) jzeleny scl-utils bkabrda,jzeleny kanarip ruby bkabrda,jstribny,kanarip,mmorsi,mtasaka,skottler,tagoh,vondruch kanarip rubygems kanarip,mtasaka,skottler,stahnma,vondruch kwizart color-filesystem rhughes limb drupal7 asrob,pfrields,siwinski mmorsi jruby bkabrda,goldmann,vondruch mstuchli pypy tomspur msuchy rhn-client-tools mzazrive nim fontpackages fonts-sig,frixxon,tagoh orion hdf5 davidcl,pertusus patches nodejs-packaging humaton,jamielinux,mrunge,sgallagh patches nodejs-tap jamielinux peter erlang-rpm-macros erlang-sig petersen ghc-rpm-macros haskell-sig,petersen phracek emacs jgu,phracek pjones pesign (none) pmatilai redhat-rpm-config jcm,pmatilai ppisar perl-srpm-macros mmaslano,perl-sig rdieter ggz-base-libs (none) rdieter polkit-qt mbriza,rnovacek,than remi php-horde-Horde-Role nb rmattes ros-release (none) rombobeorn fedora-gnat-project-common (none) rstrode GConf2 walters s4504kr blender fcami,hobbes1069,kwizart,roma s4504kr gnustep-make s4504kr,salimma smani keyrings-filesystem (none) sochotni javapackages-tools java-sig,mizdebsk,msimacek,msrb spot generic-release bruno spot R salimma than sip kkofler,ltinkl,rdieter twaugh cups jpopelka

14 20

F20 Self Contained Change: Snapshot and Rollback Tool
by Jaroslav Reznik 07 Mar '14

07 Mar '14

= Proposed Self Contained Change: Snapshot and Rollback Tool = https://fedoraproject.org/wiki/Changes/Rollback Change owner(s): Stephen Gallagher <sgallagh(a)redhat.com>, Colin Walters <walters(a)redhat.com> With the advent of thinly-provisioned LVM pools, it has become possible for us to implement full-system LVM snapshotting for recording rollback points. We are planning to support this for yum updates and eventually fedup upgrades going forwards. This change request notes the addition of new tools provided by the roller-derby project to present an interface and a CLI for managing and initiating rollbacks. == Detailed description == The roller-derby project will be providing a library and a CLI for creating, labeling and managing LVM snapshots (plus non-LVM backups of /boot), oriented primarily towards rpm-managed data, but useful beyond that. The yum plugin "yum-plugin-fs-snapshot" will be updated to consume this library and save the system state in a compatible format. The roller-derby CLI tool will provide an interactive and scriptable interface for manipulating these snapshots and determining when to remove older ones. It will also allow the tagging of snapshots as "known-good", to be skipped when automatically-trimming for space. The roller-derby project will likely provide a small daemon to keep track of the available space in the LVM pool to proactively clean up snapshots before the system runs out of space. In order to prevent "loss" of data when rebooting into an snapshot, the roller-derby CLI will allow saving a snapshot of the current state before rolling back and will provide tools to allow mounting of that current state to recover changes that have occurred since the rollback point. == Scope == The scope of this project is the completion of the initial release of the roller-derby project and the inclusion of thinly-provisioned LVM as an option in the Anaconda installer [1]. Proposal owners: We need to complete the roller-derby project. Other than the Anaconda change referenced above, all dependencies are available in Fedora already. Other developers: OS Installer Support for LVM Thin Provisioning Release engineering: N/A (not a System Wide Change) Policies and guidelines: N/A (not a System Wide Change) [1] https://fedoraproject.org/wiki/Changes/InstallerLVMThinProvisioningSupport _______________________________________________ devel-announce mailing list devel-announce(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce

7 12

Sshd getting 'dyntransition' AVC's in SElinux enforcing mode
by Philip Prindeville 06 Mar '14

06 Mar '14

I’m seeing the following after an update (via yum) from F19 to F20: ---- time->Tue Dec 24 16:05:44 2013 type=SYSCALL msg=audit(1387926344.492:5867): arch=c000003e syscall=1 success=no exit=-13 a0=6 a1=7f4e5e7afbb0 a2=20 a3=7fff44c2c550 items=0 ppid=686 pid=693 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:init_t:s0 key=(null) type=AVC msg=audit(1387926344.492:5867): avc: denied { dyntransition } for pid=693 comm="sshd" scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:sshd_net_t:s0 tclass=process ---- time->Tue Dec 24 16:05:45 2013 type=SYSCALL msg=audit(1387926345.093:5883): arch=c000003e syscall=1 success=no exit=-13 a0=7 a1=7f4e5e7acef0 a2=2a a3=666e6f636e753a72 items=0 ppid=686 pid=706 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 ses=627 tty=(none) comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:init_t:s0 key=(null) type=AVC msg=audit(1387926345.093:5883): avc: denied { dyntransition } for pid=706 comm="sshd" scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0 tclass=process Is this a known issue? I’m running: selinux-policy-devel-3.12.1-106.fc20.noarch selinux-policy-targeted-3.12.1-106.fc20.noarch selinux-policy-doc-3.12.1-106.fc20.noarch selinux-policy-3.12.1-106.fc20.noarch openssh-clients-6.4p1-3.fc20.x86_64 openssh-6.4p1-3.fc20.x86_64 openssh-server-6.4p1-3.fc20.x86_64 Thanks, -Philip

4 5

Packages with missing %check
by Alexander Todorov 05 Mar '14

05 Mar '14

Hi guys, I have identified 551 packages on the Fedora 20 source DVD which are missing a %check section in their spec files but are very likely to have a test suite. See https://github.com/atodorov/fedora-scripts/blob/master/sample-data/fedora-2… For a few of them I already had bug open previously (will filter the list later when I run my scripts against latest Rawhide). I have the following questions: 1) Do we consider this a bug and if yes what priority do you give it? From last week discussions it looks like most people prefer to have tests executed in %check. 2) Last week Alexander Kurtakov brought up the issue of packages executing their test suite during build. How to detect such packages? OTOH we can have some false negatives (also see 3). 3) Another proposal (sorry don't remember who proposed it) was to have %check with a comment why the test suite is not executed (e.g. requires network) or why it is executed in %build. I support this as it makes it clear to the QA person what is happening. This comment can be later extended to explain why a particular package is missing test suite (e.g. man pages or packages containing data files). How about making %check a packaging requirement in all cases - run tests or add a comment explaining why not, how to run them (e.g. make test) or why there are no tests for this package. -- Alex

17 52

Re: default file system, was: Comparison to Workstation Technical Specification
by Chris Murphy 05 Mar '14

05 Mar '14

On Feb 26, 2014, at 8:13 AM, Michael Cronenworth <mike(a)cchtml.com> wrote: > Ext4 has its btrfs conversion tool. Changing from ext4 to XFS, for arguably negligible benefits for Workstations, will make it more difficult for Fedora users to transition to btrfs. It's an unlikely path because a.) by default we put ext4 on LVM; b.) the convert tool uses ext4 block size to set btrfs leaf size; c.) the convert tool doesn't set extref, although it easily could. The last two are a cake walk to change compared to the first. On Feb 26, 2014, at 8:20 AM, Josh Boyer <jwboyer(a)fedoraproject.org> wrote: > I agree switching from ext4 to XFS is likely not worthwhile. Whether Server WG goes with ext4 or XFS on LVM, it's worthwhile for Workstation WG to mimic it merely due to simplicity because then we don't need separate installers or composes. On Feb 26, 2014, at 8:24 AM, David Cantrell <dcantrell(a)redhat.com> wrote: > > I think filesystem variance across different Fedoras really impacts QA more > than us. We already support a lot of filesystems, but the real hit is the > QA test matrix. QA already tests the file system layouts being discussed. Perhaps the least tested is XFS on LVM only because the XFS test case doesn't specify LVM, so testers probably split and do some plain partition and some on LVM. If Server WG decides on XFS, it effectively increases the Automatic/Guided/easy/default installer path's "Partition Scheme" pop-up from four to five options, and that is a problem. Adamw and I are working on a proposal to reduce these options to one or two: i.e. a WG chosen product specific default, and maybe "one other" which is decided by Base WG or FESCo. Chris Murphy

19 57

F21 System Wide Change: System-wide crypto policy
by Jaroslav Reznik 05 Mar '14

05 Mar '14

= Proposed System Wide Change: System-wide crypto policy = https://fedoraproject.org/wiki/Changes/CryptoPolicy Change owner(s): Nikos Mavrogiannopoulos <nmav(a)redhat.com> Unify the crypto policies used by different applications and libraries. That is allow setting a consistent security level for crypto on all applications in a Fedora system. == Detailed Description == The idea is to have some predefined security levels such as LEVEL-80, LEVEL-128, LEVEL-256, or ENISA-LEGACY, ENISA-FUTURE, SUITEB-128, SUITEB-256. These will be the security levels that the administrator of the system will be able to configure by modifying /usr/lib/crypto-profiles/config /etc/crypto-profiles/config and being applied after executing update-crypto-profiles. (Note: it would be better to have a daemon that watches those files and runs update-crypto-profiles automatically) After that the administrator should be assured that any application that uses the system settings will follow a policy that adheres to the configured profile. Ideally setting a profile should be setting: * the acceptable TLS/SSL (and DTLS) versions * the acceptable ciphersuites and the preferred order * acceptable parameters in certificates and key exchange, i.e.: ** the minimum acceptable size of parameters (DH,ECDH,RSA,DSA,ECDSA) ** the acceptable elliptic curves (ECDH,ECDSA) ** the acceptable signature hash functions * other TLS options such as: ** safe renegotiation An idea of how this will be implemented is to have each Fedora application's configuration file or compilation option will set a system default option. That is for example for applications that use GnuTLS or OpenSSL a priority string or cipher named "SYSTEM". Then the shipped library will make sure that once the "SYSTEM" option is encountered the preconfigured system settings will be applied. The preconfigured settings for each SSL library will be auto-generated from the default profile in /etc/crypto-profiles/generated/$(libname)/config == Scope == There are changes required in GnuTLS, OpenSSL and NSS libraries. On a second phase non-SSL crypto libraries could use these settings. * Proposal owners: For GnuTLS and OpenSSL the "SYSTEM" cipher needs to be understood and behave as described. For NSS the NSS_SetDomesticPolicy() can be overloaded to behave as above. After that a mechanism to specify crypto policies for Fedora has to be devised, as well as the extraction to each libraries' settings. * Other developers: Packages that use SSL crypto libraries should, after the previous change is complete, start replacing the default cipher strings with SYSTEM. * Release engineering: This feature does not require coordination with release engineering. * Policies and guidelines: After the change is complete the packaging guidelines, should mention above replacing the default cipher strings with "SYSTEM". This of course need not affect programs that do not have a mechanism for setting ciphers/modes that is already in wide use (e.g., browsers). It mostly targets applications that use some reasonable (or unreasonable) defaults and the user/administrator has little control of them. _______________________________________________ devel-announce mailing list devel-announce(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce

11 23

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel February 2014