devel December 2010

devel@lists.stg.fedoraproject.org

212 participants
189 discussions

Deltarpm python3 build failure
by Jonathan Dieter 18 Jan '11

18 Jan '11

I noticed an announcement that Python3 has made some changes in how C modules are built. I now seem to be running into some problems building deltarpm for Rawhide and it seems to be tied into this. See http://koji.fedoraproject.org/koji/buildinfo?buildID=212117 for more details. Not sure if I need to change the Makefile to adjust for this, or just the spec. Some advice would be greatly appreciated. Jonathan

3 3

Heads-up: Audacious 2.4.2 hitting Rawhide
by Michael Schwendt 17 Jan '11

17 Jan '11

I'm building Audacious 2.4.2 in Rawhide, and once available in the koji build root, this will require rebuilds of the separate _plugin_ packages. The tools/apps linked with Audacious' core libraries are not affected: audtty conky 2.4.2 is the first maintenance release in the [supposed to be stable] 2.4 branch, but bumped the generic plugin API to version 17 nevertheless. Quite early in 2.4.x development actually. Plugins, if not rebuilt, would refuse to load. The rebuilds should be possible without problems. If run you into anything unexpected, feel free to contact me.

1 2

HEADS UP! Ohloh Fedora repositories
by Peter Lemenkov 11 Jan '11

11 Jan '11

Hello All! I'm currently in process of automatic enlisting of all ~10K Fedora Git repos at Ohloh. Right now roughly 7% of repositories were added and overall process will be finished in a 20-30 hours (it takes me about 5-10 seconds to properly add repository, and I don't want to speedup this process - to prevent Ohloh from accidental DoS). Just FYI. -- With best regards, Peter Lemenkov.

6 9

[HEADS-UP] MySQL 5.5 coming soon to rawhide
by Tom Lane 10 Jan '11

10 Jan '11

Since MySQL AB^W^WSun^WOracle has now declared the mysql 5.5.x release series to be GA status, I'm planning to push it into rawhide shortly to replace the 5.1.x series. Theoretically, this will go pretty smoothly. I'm aware of a couple of ABI-level issues: 1. libmysqlclient.so, which is linked into all manner of stuff, is supposed to be ABI-compatible with the previous releases. However, I got tired of the amount of visible churn in exported-symbols-you're- not-supposed-to-use. The new release will use a linker --version-script to hide everything except the documented API functions. This might break any apps that are relying on non-API functions. If so, I'm willing to consider on a case-by-case basis whether to add those symbols back to the ABI or fix the callers. 2. libmysqlclient_r.so is gone altogether; there's no need for it since the regular libmysqlclient.so library is supposed to be thread safe. AFAIK this will require rebuilding only the following packages: mysql++ mysql-connector-c++ nekovm qt-mysql For now I'll include a symlink libmysqlclient_r.so -> libmysqlclient.so, so that a simple rebuild with no source-code changes should be sufficient. Eventually we'll probably want to fix the source code to not refer to libmysqlclient_r, but that might take awhile if upstreams are worried about portability. There are also some SQL-level incompatibilities called out here: http://dev.mysql.com/doc/refman/5.5/en/upgrading-from-previous-series.html I'm not sure to what extent these may affect Fedora applications, but it seems like the easiest way to find out is to try them. Any objections? Anything people think should be tested before pushing? regards, tom lane

5 17

Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)
by Michał Piotrowski 06 Jan '11

06 Jan '11

Hi, W dniu 3 grudnia 2010 09:14 użytkownik Michał Piotrowski <mkkp4x4(a)gmail.com> napisał: [..] > What services are installed by default when installong form Live > GNOME/KDE/etc and DVD? Ok, let's ask the question differently - what services should be run by default to provide working system for desktop user? IMO ssh can be off by default and should be started only if user tries to connect over port 22. Do we really need to install iptables/ip6tables by default (it's in core group)? -- Best regards, Michal Sent from my iToaster

39 135

Fedora as semantic desktop (nautilus and tracker integration) ?
by Valent Turkovic 06 Jan '11

06 Jan '11

https://bugzilla.redhat.com/show_bug.cgi?id=501227 I'm writing to devel list just if anybody can say will there be any chance to get nautilus and tracker integration working? Is this on anybody's radar? Thanks, Valent. -- pratite me na twitteru - www.twitter.com/valentt blog: http://kernelreloaded.blog385.com linux, anime, spirituality, windsurf, wireless, ronjenje, pametne kuće, zwave registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic, MSN: valent.turkovic(a)hotmail.com

4 5

firewalld - A firewall daemon with D-BUS interface providing a dynamic firewall (test version)
by Thomas Woerner 06 Jan '11

06 Jan '11

Hello, as discussed some time ago, I worked on the proof of concept implementation of firewalld. FirewallD is a service daemon with a D-BUS interface that provides a dynamic managed firewall. For more information on firewalld, please have a look at: https://fedoraproject.org/wiki/FirewallD/ About this version: This is mostly the proof of concept implementation with some changes and is feature complete for F-15 as a firewalld preview version. It will not be enabled per default and will also not get installed per default. The system-config-firewall with static firewall model will still be the default firewall solution for Fedora 15. What this firewalld version can do: - It supports most of the firewall features system-config-firewall had, but there are three limitations: 1) custom firewall rule files (iptables save format) are not supported and most likely will never be, but there is support for custom rules (limited functionality). 2) sysctl changes for ip_forward are not done, yet. 3) There are no permanent firewall settings, this means that all settings are lost after a service restart or reboot. Permanent firewall settings will be added later on. - The firewall daemon manages the firewall dynamically. This means that changes are done without recreating the whole firewall. Also there is no need to reload all firewall modules anymore. Firewall helpers are loaded and unloaded if needed. - A simple tray applet (firewall-applet) shows the status of the public firewall and is makes it simple to enable and disable firewall services. The applet does not show firewall configuration settings done with the libvirt interface. - firewall-cmd is the command line client that makes it possible to enable, disable, query and list firewall features. firewall-cmd is also not able to show firewall settings of the libvirt interface. - There is an rule and chain interface for libvirt, but the PolicyKit policy is not in place, yet. What this version can not do (future features): - firewall-config, the firewall configuration utility, is not functional - System vs. User/Session configuration - Zone support - NetworkManager firewall rule support firewalld made it into a fedorahosted repo at: git://git.fedorahosted.org/git/firewalld.git The fedoraproject wiki page at https://fedoraproject.org/wiki/FirewallD/ exists and will get more updates soon. The feature request page for Fedora 15 is also up to date: https://fedoraproject.org/wiki/Features/DynamicFirewall#How_To_Test For test packages, please have a look at http://twoerner.fedorapeople.org/firewalld/ firewalld has a requirement for system-config-firewall-1.2.28. This version has checks for an active firewalld in the tools. Please have a look at http://koji.fedoraproject.org/koji/buildinfo?buildID=211013 for the Fedora 15 packages of this version. It is usable on fedora versions < 15. How To Test - Install firewalld and firewall-applet - Start the firewalld service - Start the tray applet firewall-applet - Use firewall-cmd to enable for example ssh: firewall-cmd --enable --service=ssh - Enable samba for 10 seconds: firewall-cmd --enable --service=samba --timeout=10 - Enable ipp-client: firewall-cmd --enable --service=ipp-client - Disable ipp-client: firewall-cmd --disable --service=ipp-client - To restore your static firewall with lokkit again simply use: lokkit --enabled You can also use the D-BUS interface directly. This is required for libvirt (and later on also NetworkManager). The D-BUS interface documentation is work in progress and will be added later on. Comments and additional information is highly welcome. Thanks in advance, Thomas -- Thomas Woerner Software Engineer Phone: +49-711-96437-310 Red Hat GmbH Fax : +49-711-96437-111 Hauptstaetterstr. 58 Email: Thomas Woerner <twoerner(a)redhat.com> D-70178 Stuttgart Web : http://www.redhat.de/

11 17

Package-specific test case and critical path test case project: drafts for review
by Adam Williamson 04 Jan '11

04 Jan '11

Hi, everyone. So, in the recent debate about the update process it again became clear that we were lacking a good process for providing package-specific test instructions, and particularly specific instructions for testing critical path functions. I've been working on a process for this, and now have two draft Wiki pages up for review which together describe it: https://fedoraproject.org/wiki/User:Adamwill/Draft_QA_SOP_test_case_creation https://fedoraproject.org/wiki/User:Adamwill/Draft_QA_SOP_package_test_plan… the first isn't particularly specific to this, but it was a prerequisite that I discovered was missing: it's a guide to test case creation in general, explaining the actual practical process of how you create a test case, and the best principles to consider in doing it. The second is what's really specific to this subject. It describes how to create a set of test cases for a particular package, and a proposed standardized categorization scheme which will allow us to denote test cases as being associated with specific packages, and also denote them as concerning critical path functionality. Given that mediawiki has a handy API which also allows you to deal with categories, this should make it easy to both manually and programmatically derive a list of test cases for a given package, and a list of *critical path* test cases for a given package. You can do this manually, but I also envision Bodhi and fedora-easy-karma utilizing the API so that when an update is pushed for a package for which test cases have been created under this system, they will link to those test cases; and when an update is pushed for a critical path package, they will be able to display separately (and more prominently, perhaps) the list of test cases relevant to the critical path functionality of the package. Comments, suggestions and rotten fruit welcome :) I'm particularly interested in feedback from package maintainers and QA contributors in whether you feel, just after reading these pages, that you'd be confident in going ahead and creating some test cases, or if there's stuff that's scary or badly explained or that you feel like something is missing and you wouldn't know where to start, etc. The trac ticket on this is probably valuable for background, explaining why some things in the proposal are the way they are: https://fedorahosted.org/fedora-qa/ticket/154 it also mentions one big current omission: dependencies. For instance, it would be very useful to be able to express 'when yum is updated, we should also run the PackageKit test plan' (because it's possible that a change in yum could be fine 'within itself', and all the yum test cases pass, but could break PackageKit). That's rather complex, though, especially with a Wiki-based system. If anyone has any bright ideas on how to achieve this, do chip in! Thanks. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net

3 13

F14 OOo deltarpms not being generated on releng2
by Jonathan Dieter 03 Jan '11

03 Jan '11

I'm not sure if there's a better list for this to go to, but there seems to be a problem generating deltarpms for F14 OOo (and a few other packages) on releng2. Specifically, the updates->updates deltarpms aren't being generated, while the GA->updates deltarpms are. When I checked the mash.out log for the 101202.1757 push, there are loads of error messages following the form of: Error genDeltaRPM for openoffice.org-langpack-pt_PT: exitcode was 256 - Reported Error: bad cpio archive The problem is that this error normally comes up when one of the rpms is corrupt, but manually running deltarpm between an rpm from the 101201.1909 push and the update from the 101202.1757 push results in a proper drpm and no errors. As far as I can see, this only affected the openoffice.org* and autocorr* packages in the 101202 push, and the rest of the packages in the push had all the proper deltarpms generated. I'm not sure where to go from here. Any ideas on how to track this down? Jonathan

2 2

Development repo contains *.fc15.i386.rpm packages
by Christoph Frieben 01 Jan '11

01 Jan '11

Some time ago, the Fedora default target for 32 bit Intel system moved from i386 (F10) via i586 (F11) to i686 (F12). Nevertheless, even the current development repo contains recent builds ending with *.fc15.i386.rpm. Is there a particular reason for these exceptions or has the build target been chosen incorrectly? ~CF

4 5

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 December 2010