devel November 2014

devel@lists.fedoraproject.org

213 participants
219 discussions

upcoming libtool rebase (2.4.2 ~> 2.4.3)
by Pavel Raiskup 09 Jan '15

09 Jan '15

Libtool upstream was able to cut the new release! I'll rebase the Rawhide package probably by the end of the next week or so, if there are no objections. Upstream maintainer calls this update fearless :) and that it needs a bit of luck [1] (asking for possible downstream cooperation); however after cutting F21 from rawhide we have probably good time for this rebase (the update should be more like bugfix anyway). There are some known incompatibilities; see the official announcement [2]. There is also scratch build for testing [3]. [1] http://osdir.com/ml/libtool-gnu/2014-10/msg00011.html [2] http://lists.gnu.org/archive/html/autotools-announce/2014-10/msg00000.html [3] http://koji.fedoraproject.org/koji/taskinfo?taskID=7975615 Regards, Pavel

3 5

Re: Migration to Zanata
by David Cantrell 05 Jan '15

05 Jan '15

On Wed, Nov 26, 2014 at 03:13:59PM +1000, Noriko Mizumoto wrote: > Hi Fedora developers > > Having the consensus with FESCo [1], we FLP (aka translation team) have > started the process of migration to new fedora.zanata.org instance from > Transifex [2]. First all translators started to migrate in November 2014 > (still going on). > > Now it is time to migrate all projects. This is expected to start after > F21 GA. For the owners of the projects, there are two options to choose > for the migration below. > > One: Delegate us to implement migration > If this option is chosen, partially automated migration will be > performed by Zanata team. Once it completes, then the owner visits new > place and confirms everything intact (Some manual adjustment may be > required). > > Two: Manual migration > If this option is chosen, the owner performs all the migration process > by his/her self. Please advise the estimated completion date. > > I have attached the list of all the target projects below. If any > package is missing and it should be added into the list, please let me know. > > Could all Fedora developers please go through the list and advise which > option is preferred for your project, so that we will be able to > schedule them? For option One, we need to know current > maintainer's/owner's contact. > > Package Name Group > Anaconda main > Blivet main > Firstboot main > initial-setup main > pykickstart main > python-meh main > system-config-kickstart main These are all installer team projects. What are we required to do with the move to Zanata? -- David Cantrell <dcantrell(a)redhat.com> Manager, Installer Engineering Team Red Hat, Inc. | Westford, MA | EST5EDT

2 1

Abotu setting 'PermitRootLogin=no' in sshd_config
by P J P 24 Dec '14

24 Dec '14

Hello, Sshd(8) daemon by default allows remote users to login as root. 1. Is that really necessary? 2. Lot of users use their systems as root, without even creating a non-root user. Such practices need to be discouraged, not allowing remote root login could be useful in that. Does it make sense to disable remote root login by default? If so, do we need to just report it to the maintainer or it would be treated as a feature? --- Regards -Prasad http://feedmug.com

26 51

PackageKit refresh(?) is wiping out local repositories and changing owner to root
by Sandro Mani 11 Dec '14

11 Dec '14

Hi, Today it happened a handful of times that my local rpm repository got wiped out (except for the repodata folder), and owner/group changed to root/root (including the repodata folder). After playing around a bit, I noticed that a $ pkcon refresh will consistently wipe out my local repository [1]. Putting an audit watch on an rpm on the repo will actually confirm that PackageKit removed the file, see below [2]. However, the odd thing is that PackageKit was last updated Nov 18 on my system, and also downgrading to PackageKit-1.0.1-1.fc22 from Oct 21 does not help, so I'm wondering whether it is really PackageKit who is responsible. Updates of yesterday and today do not really seem to be of any relevance. Anyone else seeing this? Any ideas how to debug this? Thanks, Sandro -------------------------------- [1] If it matters, repo file is $ cat /etc/yum.repos.d/local.repo [local] name=Local baseurl=file:///home/sandro/rpmbuild/repo enabled=1 gpgcheck=0 metadata_expire=0 [local-source] name=Local - Source baseurl=file:///home/sandro/rpmbuild/SRPMS enabled=0 metadata_expire=0 gpgcheck=0 -------------------------------- [2] $ sudo ausearch -f /home/sandro/rpmbuild/repo/mingw32-qtspell-0.4.0-1.fc22.noarch.rpm -i ---- type=CONFIG_CHANGE msg=audit(30.11.2014 01:15:48.332:497) : auid=unset ses=unset op="updated rules" path=/home/sandro/rpmbuild/repo/mingw32-qtspell-0.4.0-1.fc22.noarch.rpm key=repo list=exit res=yes ---- type=PROCTITLE msg=audit(30.11.2014 01:15:48.332:498) : proctitle=/usr/libexec/packagekitd type=PATH msg=audit(30.11.2014 01:15:48.332:498) : item=1 name=/home/sandro/rpmbuild/repo/mingw32-qtspell-0.4.0-1.fc22.noarch.rpm inode=5505054 dev=08:03 mode=file,664 ouid=sandro ogid=sandro rdev=00:00 obj=unconfined_u:object_r:user_home_t:s0 nametype=DELETE type=PATH msg=audit(30.11.2014 01:15:48.332:498) : item=0 name=/home/sandro/rpmbuild/repo/ inode=5513217 dev=08:03 mode=dir,775 ouid=sandro ogid=sandro rdev=00:00 obj=unconfined_u:object_r:user_home_t:s0 nametype=PARENT type=CWD msg=audit(30.11.2014 01:15:48.332:498) : cwd=/ type=SYSCALL msg=audit(30.11.2014 01:15:48.332:498) : arch=x86_64 syscall=unlink success=yes exit=0 a0=0x7fd7401f88e0 a1=0xffffffff a2=0x7fd7401f8801 a3=0x7fd763e53970 items=2 ppid=1 pid=1902 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=PK-Backend exe=/usr/libexec/packagekitd (deleted) subj=system_u:system_r:rpm_t:s0 key=repo

4 6

update on ca-certificates, introducing the ca-legacy utility
by Kai Engert 02 Dec '14

02 Dec '14

Resending this as a new thread, for increased visibility. As explained in the older thread, the Mozilla project has started to remove CA certificates that contain weak keys. Those removals cause issues with software based on OpenSSL, and software based on older versions of GnuTLS. (A short description of the issue can be found in tracker bug https://bugzilla.redhat.com/show_bug.cgi?id=1166614 - I intend to file a ticket against OpenSSL shortly.) For Fedora, we have decided to keep the legacy CA certificates included and trusted by default, in order to avoid compatibility issues, until we get functional updates to OpenSSL. I'm documenting the changes on top of the Mozilla CA list at: https://fedoraproject.org/wiki/CA-Certificates However, we want to provide users/administrators with the ability to change the default, by configuring the ca-certificates to strictly follow the trust decisions made by Mozilla, thereby accepting the compatibility issues (e.g. untrusted TLS connections, if certificates of affected server configurations cannot be validated). The above has been implemented for Fedora 21, it looks like it will be included as part of the Fedora 21 release: ca-certificates-2014.2.1-1.5.fc21.noarch Using the new ca-legacy utility, it is possible to disable trust for the legacy CA certificates as a systemwide configuration, by executing this command as root: ca-legacy disable The configuration will be remembered in /etc/pki/ca-trust/ca-legacy.conf and will be used on future package upgrades, when additional certificates are moved to the legacy state. If required, it's possible to undo the configuration and revert to the current default, using: ca-legacy enable The current configuration can be shown using: ca-legacy check Regarding Fedora 19 and Fedora 20: On F19/F20, GnuTLS is also affected by the breakage, when disabling trust for the legacy CAs, because GnuTLS has been enhanced in Fedora 21 and later, only. Updated packages for F19 and F20, that provide the update to version 2.1 of the ca-certificates list, and which also include the new ca-legacy utility and configuration mechanism, have been pushed to updates-testing: https://admin.fedoraproject.org/updates/ca-certificates-2014.2.1-1.5.fc19 https://admin.fedoraproject.org/updates/ca-certificates-2014.2.1-1.5.fc20 Kai

1 1

Entire process's environment attached to bugzillas by ABRT
by Jakub Filak 02 Dec '14

02 Dec '14

Hello, As you might know ABRT attaches 'environ' file to its Bugzilla bugs. The file contains a full copy of /proc/[pid]/environ. Even though ABRT highlights black-listed words and encourages users to review the data before submitting them, it may happen that the reporter misses something and publishes his secrete data in 'environ' file. Do you find 'environ' attachment valuable or is ABRT just publishing personal information? Regards, Jakub

7 16

Fedora 21 Final RC1 dual boot
by Christopher 01 Dec '14

01 Dec '14

Hi all, I was testing installing Fedora 21 Final RC1 in the free space on a GPT drive with Windows 8.1 (Lenovo Z40). I'm installing from a USB stick made from the ISO. Every time I click "Begin Installation" in Anaconda, it locks up at the screen where I'm supposed to be able to enter the root password and create a user account. The message at the bottom is something like "Initializing setup configuration" (sorry, I can't recall the exact words). I can't click on anything in Anaconda, but I can switch to a terminal and "kill -9 <pid of anaconda>" to drop me back to the Live desktop. I do not get the same problem if I delete all the existing partitions on the drive and install only Fedora. That proceeds fine. The problem only seems to exist if I try to install alongside Windows. My question is: how might I go about troubleshooting this? -- Christopher L Tubbs II http://gravatar.com/ctubbsii

4 5

How many developers Fedora has
by Ali AlipourR 01 Dec '14

01 Dec '14

Hi Is there any statistics about How many developers Fedora has? Thanks

9 8

timedatex replacing systemd-timedated for NTP packages
by Miroslav Lichvar 01 Dec '14

01 Dec '14

This is about bug #1136905 [1], discussed previously on the systemd list [2] and also on our desktop list [3]. The issue is that systemd-timedated now supports only systemd-timesyncd for NTP and ignores other NTP services installed on the system. It doesn't know that chronyd or ntpd is enabled (usually by system-config-date after the installation) and switching NTP in timedate clients such as timedatectl and GNOME control center is broken. If we want to have this working correctly with chronyd/ntpd, at this point it seems the only reasonable option is to replace systemd-timedated. timedatex is a new implementation of the timedate interface that was recently added to Fedora. It reads the list of NTP units from a directory as systemd-timedated used to do. When installed, systemd will start it for the timedate bus name instead of systemd-timedated. The timedate clients should work as expected, please report bugs if not. One suggestion was to install it as a dependency of the NTP packages. Is this a good idea? Should this first go through the Fedora change process or at least be documented somewhere? [1] https://bugzilla.redhat.com/show_bug.cgi?id=1136905 [2] http://lists.freedesktop.org/archives/systemd-devel/2014-August/022367.html [3] http://lists.fedoraproject.org/pipermail/desktop/2014-September/010749.html -- Miroslav Lichvar

11 21

systemd.timer: Get next start time from unit being run?
by Richard Shaw 30 Nov '14

30 Nov '14

I've got a TV schedule grabber script that needs to be run on a more or less daily basis. That would be good enough, but the script suggests a next start time in it's output when it completes. If I can figure out a way to pull that time from the script, is there a way to pass that to systemd? Thanks, Richard

4 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel November 2014