devel November 2011

devel@lists.fedoraproject.org

268 participants
243 discussions

Changing kernel API / Breaking VirtualBox - update criteria violation?
by Till Maas 08 Dec '11

08 Dec '11

Hi, a recent kernel update[0] broke Fedora's ability to be a VirtualBox host, because asm/amd_iommu.h was removed. The removal of the file was noticed during testing, but it seems nobody noticed that this affects VirtualBox. Is this kind of change sanctioned by the current update criteria? Kind regards Till [0] https://admin.fedoraproject.org/updates/FEDORA-2011-15856/kernel-2.6.41.1-1…

24 67

Heads up: bumping libnl to v3 in rawhide/F17 soon
by Dan Williams 08 Dec '11

08 Dec '11

Hi, At some point here I'm going to bump libnl to version 3 in rawhide. The libnl 1.1 we use today is way out of date and we want version 3 for the enhanced capabilities like bonding, bridging, vlan, etc. This *does* mean an API break, so packages will need to be updated for libnl3. The majority of the changes are simply function renames and changed structure names. There's no porting guide that I'm aware of but I and others working on NetworkManager have spent time porting from libnl1.1 to libnl3 this cycle so we can point you in the right direction. Dan

6 10

Package segfaults when built with -O2 but not with -O0
by Paul Howarth 06 Dec '11

06 Dec '11

One of my packages, pptp, suffers occasional segfaults as reported in http://bugzilla.redhat.com/749455. However, whilst investigating this, it seems to be the case that simply rebuilding the package using no optimization (-O0) as opposed to the default -O2 is enough to stop this happening. This raises two questions (at least!): 1. Is it reasonable for me to flout the packaging guidelines by rebuilding with -O0 until this is resolved? 2. How to determine what the actual problem is, e.g. a problem with the way the code is written leading to unsafe optimizations, or a gcc bug? Paul.

7 20

Upgrading libpng: shall we move to 1.4.x or 1.5.x?
by Tom Lane 05 Dec '11

05 Dec '11

I have been looking into replacing Fedora's obsolete version of libpng (1.2.x release series) with something more modern. The possible choices are the 1.4.x and 1.5.x release series. The 1.5.x series adds some more features that 1.4.x did not have, but it also poses significantly more migration problems. The reason is that 1.5.x no longer exposes the contents of the library's internal "png_info" struct. Direct access to fields of png_info has been deprecated for a long time, in favor of using accessor functions, but up through 1.4 you can get away with it. I did test rebuilds in mock of all rawhide packages that are reported to be dependent on libpng. Out of 964 packages with dependencies on libpng, we have: Packages that rebuilt successfully with 1.5 658 Packages that FTBFS for non-libpng reasons 186 Packages that rebuilt with 1.4, but not 1.5 74 Packages that need help even with 1.4 46 (The non-libpng failures seem to mostly be due to the recent upgrade to glib 2.0. Some of those probably have libpng issues as well, but didn't get far enough in their builds to expose them.) About half of the "need help anyway" group may just need their BuildRequires to be rebuilt first --- it looked like they had no source-code dependency, but were just absorbing "-lpng12" from library link flags reported by other packages. I built each package independently rather than trying to chain the builds, so this wasn't catered for. The vast majority of the 74 packages that would need extra work if we move to libpng 1.5 are trying to access the png_info struct directly, and so would need patches to use the accessor functions instead. This is work that should be done and upstreamed anyway, but if we move to 1.4 we would not have to do it Right Now. It looks like it would be a fairly large amount of work, too --- I count 1164 "incomplete type" failures in the build logs for those packages, and it's quite likely there are more in source files that the build runs didn't get to. On the other hand, if we move to 1.4 there will not be any pressing reason for these fixes to get made, and so I'm not sure that we'll be any better off when we try to move to 1.5 later. Another point is that we'd have to build these same 964 packages over again if we plan a two-stage upgrade. Any opinions on which way to jump? In either case, as per the discussion at http://lists.fedoraproject.org/pipermail/devel/2011-October/157712.html I plan to provide the 1.2.x libpng shared library (and only the library, not its devel support files) in a libpng-compat subpackage for the time being. So existing programs that depend on 1.2.x will continue to work, but it won't be possible to rebuild a package that has source-level dependencies on 1.2.x until those are fixed. I think this is enough to avoid needing a special build tag for staging the rebuilds. regards, tom lane

11 19

2.6.41.2-1.fc15.x86_64: missing bridge support?
by Reindl Harald 05 Dec '11

05 Dec '11

is there something missing in recent F15-Kernels? i prepare this machine for play wireless-ap and what is much more worse currently in our company is running a openvpn-server with F14 using brdige-utils which should be upgraded soon to F15 [root@srv-rhsoft:~]$ /usr/sbin/brctl addbr br0 add bridge failed: Package not installed [root@srv-rhsoft:~]$ uname -r 2.6.41.2-1.fc15.x86_64 #1 SMP Tue Nov 22 08:56:55 UTC 2011 > http://edeca.net/articles/bridging/questions.html#braddbridgenotinstalled > Q: > I get the error "br_add_bridge: Package not installed" when trying to add a bridge, why is that? > > A: > This happens if you don't have bridging support compiled into your kernel, or the module isn't loaded. > Read the section about the host kernel.

5 6

pyvnc2swf and vnc2flv
by Jos Vos 04 Dec '11

04 Dec '11

Hi, I was looking for a tool to record X/VNC session in a movie and found pyvnc2swf. But looking at the project's home page, <http://www.unixuser.org/~euske/vnc2swf/index.html>, I see that the development has been superseded by its successor, vnc2flv, <http://www.unixuser.org/~euske/python/vnc2flv/index.html>, since 2 years. Maybe Fedora should upgrade to this new version for F17. -- -- Jos Vos <jos(a)xos.nl> -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204

3 2

A Glorious Vision of Our Shared Update Feedback Future (bodhi, karma, and proventesters, oh my)
by Adam Williamson 02 Dec '11

02 Dec '11

Hey, folks. So in the recent proven tester discussion, and in various other threads, I've oft stated that the limits of the current Bodhi karma system are a significant problem, and the planned Bodhi 2.0 karma system has to potentially to significantly improve our update testing process. But it occurred to me that I haven't really laid out why in much detail, and those who aren't as involved with the process as we in QA are might not have a really clear vision of why this is so important. So, I thought I'd lay it out in the form of a glorious vision of the future! Note: I have zero UI design skills. This UI as described would suck. But the idea is that there would be a decent UI which *represents all the described choices*. In the Great Bodhi Of The Future, for any given update, a tester will not simply have a comment box and a drop-down for -1, 0 or +1. They will see: * The list of test cases associated with the package, with a PASS / FAIL choice for each * Checkboxes for 'This update does / does not break critical path functionality' (with a link out to the critpath definition) * A checkbox for 'I installed this update and continued to use my system as normal and did not note any regressions' * Any custom choices the package maintainer opts to provide, via some kind of interface to Bodhi This is the kind of flexibility that would make karma massively more useful. The tighter definition of what feedback actually *means* provides far more information to the maintainer, and enables us to automate certain outcomes much more aggressively. For me, one the principal benefits of such a system would be that we could make the 'This update breaks critical path functionality' checkbox an absolutely red flashing light, wailing siren emergency button. I mean, you hit that thing and trucks roll from Fedora HQ, metaphorically speaking. It would have a confirmation page which clearly described the impact of asserting that an update broke critpath, so we could be confident that it didn't get falsely triggered very often. I'd suggest that: 1. Any update that is marked as 'critpath breaking' by a FAS-registered tester would be blocked from going any further in the update process without manual intervention (no autopushes at all) 2. Any update marked as 'critpath breaking' by a proven tester would be blocked from being pushed stable at all - automatically or manually - until the PT modified the feedback or it was overridden by someone with appropriately godlike powers (TBD, but probably not just the maintainer) 3. Any update marked as 'critpath breaking' should probably get announced on at least test-announce and/or devel-announce 4. Any update marked as 'critpath breaking' *after it has already been pushed* would similarly trigger a major response: notify maintainer very hard, notify lists, generally do stuff to make sure it gets immediate attention We would also obviously be able to offer maintainers more nuanced options for autopushing updates - require a certain number of passes on a certain set of test cases, for instance. To go a bit into the theory, the really nasty limitation of the current system is we simply have very little easily consumable indication of what the karma provided on an update *means*. A +1 can mean anything from 'I booted and nothing exploded' to 'I tested every line of this code, then did it backwards standing on my head'. A -1 can mean 'I booted this update and then my cat got sick, I think there's a connection!', 'this update breaks $REALLY OBSCURE FEATURE Z', or 'this update exploded my monitor'. We just _don't know_. You can get the information from comments, usually, but that's obviously a complete non-starter for any kind of programmatized or automated action based on the feedback. In particular, we currently can't do anything dramatic based on negative feedback because of the uncertainty around exactly what it means. We do have a few policies about when to file negative feedback, but even this only very slightly mitigates the problem - we can't say 'only file negative feedback if the update breaks critpath', that's just not feasible. So we can't identify the 'really really negative' feedback and respond appropriate drastically to it without causing lots of pain through false positives (or rather, false negatives...) With a more advanced feedback system we can identify the really big problems and be much more aggressive about handling them, without over-reacting to smaller problems. We could, correspondingly, be a bit less strict about how much *positive* feedback you need to push an update, if we can be a bit more confident that we'll definitely identify the really bad problems through negative feedback. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net

7 16

dracut waiting for background mdadm reconstruction to complete
by Daniel Drake 01 Dec '11

01 Dec '11

Hi, Just installing Fedora 16 on a new system. We set up a RAID1 with mdadm for /. On boot, we're finding that if there is a RAID inconsistency, dracut is waiting for mdadm reconstruction to complete before booting the system. This means that after a power outage or other condition that would cause a reconstruction to become necessary, we have to wait several hours for the system to come online again. My understanding is that this reconstruction is a background task, is there really a need for this to hold up boot? This behaviour comes from 0064-90mdraid-wait-for-md-devices-to-become-clean.patch in the dracut-013-19.fc16 package. Thanks Daniel

3 5

Self Introduction
by Troy Dawson 01 Dec '11

01 Dec '11

Hello, I've been creating rpm packages for Fermi Linux for over 10 years, and Scientific Linux 8 years, but I never had time to do anything for Fedora and EPEL. Now that I'm not with Scientific Linux, I've got the time. I'd like to help with the OpenShift client packages for Fedora and EPEL. So I'm going to sign up to be a co-maintainer for rubygem-rhc, and rubygem-json-pure (a new dependancy for rhc). Troy Dawson

3 3

rawhide java versioning issue?
by David Airlie 01 Dec '11

01 Dec '11

so I was trying to fix xorg-x11-docs, which uses fop which uses java, which means I've no idea. http://koji.fedoraproject.org/koji/taskinfo?taskID=3549524 The main error is below so I suspect the problem is that some apache/avalon framework jar file is build with the 1.7 jdk but the buildroot installed the 1.6 jdk. Should something have its dependency bumped? Dave. usr/bin/xmlto: line 316: local: can only be used in a function GEN fonts.ps /usr/bin/xmlto: line 316: local: can only be used in a function Making portrait pages on A4 paper (210mmx297mm) java virtual machine used: /usr/lib/jvm/jre/bin/java classpath used: /usr/share/java/commons-io.jar:/usr/share/java/batik-all.jar:/usr/share/java/avalon-framework-api.jar:/usr/share/java/avalon-framework-impl.jar:/usr/share/java/xmlgraphics-commons.jar:/usr/share/java/commons-logging.jar:/usr/share/java/fop.jar: main class used: org.apache.fop.cli.Main flags used: options used: arguments used: -fo /tmp/xmlto.1D9adG/fonts.proc -ps /builddir/build/BUILD/xorg-docs-1.6/general/fonts/fonts.ps Exception in thread "main" java.lang.UnsupportedClassVersionError: org/apache/avalon/framework/configuration/ConfigurationException : Unsupported major.minor version 51.0 at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:634) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:277) at java.net.URLClassLoader.access$000(URLClassLoader.java:73) at java.net.URLClassLoader$1.run(URLClassLoader.java:212) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:205) at java.lang.ClassLoader.loadClass(ClassLoader.java:321) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294) at java.lang.ClassLoader.loadClass(ClassLoader.java:266) at org.apache.fop.apps.FopFactory.<init>(FopFactory.java:153) at org.apache.fop.apps.FopFactory.newInstance(FopFactory.java:177) at org.apache.fop.cli.CommandLineOptions.<init>(CommandLineOptions.java:121) at org.apache.fop.cli.Main.startFOP(Main.java:157) at org.apache.fop.cli.Main.main(Main.java:204) make[2]: *** [fonts.ps] Error 1 make[2]: Leaving directory `/builddir/build/BUILD/xorg-docs-1.6/general/fonts' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/builddir/build/BUILD/xorg-docs-1.6/general'

3 4

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 November 2011