Re: F14: after last updates, getting Eclipse out of memory errors
On 10:05:21 am Sunday, November 21, 2010 Marius Andreiana wrote: Hi, After getting latest updates (glibc and eclise), I started getting reproducible Eclipse out of memory errors (happens during AppEngine deploys). Haven't done any other changes to my env besides yum update. Should I file a bug? Just edit /etc/eclipse.ini and set the --launcher.XXMaxPermSize and -Xmx384m to something meaningful for you. JVM can allocate more memory than a predefined value which can be controlled by startup parameters. This is what we do in eclipse.ini but we can not set this to something really big because people can use eclipse for things that even require less than the current settings. Alexander Kurtakov !ENTRY org.eclipse.ui 4 4 2010-11-20 15:47:18.005 !MESSAGE An internal error has occurred. !STACK 0 java.lang.OutOfMemoryError: Java heap space at org.eclipse.jface.text.GapTextStore.allocate(GapTextStore.java:339) at org.eclipse.jface.text.GapTextStore.reallocate(GapTextStore.java:290) at org.eclipse.jface.text.GapTextStore.adjustGap(GapTextStore.java:223) at org.eclipse.jface.text.GapTextStore.replace(GapTextStore.java:196) at org.eclipse.jface.text.CopyOnWriteTextStore.replace(CopyOnWriteTextStore.ja va:158) at org.eclipse.jface.text.AbstractDocument.replace(AbstractDocument.java:1184) at org.eclipse.jface.text.AbstractDocument.replace(AbstractDocument.java:1210) at org.eclipse.ui.internal.console.ConsoleDocument.replace(ConsoleDocument.jav a:82) at org.eclipse.ui.internal.console.IOConsolePartitioner.processQueue(IOConsole Partitioner.java:572) at org.eclipse.ui.internal.console.IOConsolePartitioner$QueueProcessingJob.run InUIThread(IOConsolePartitioner.java:520) at org.eclipse.ui.progress.UIJob$1.run(UIJob.java:95) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:134 ) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3515) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3164) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2640) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2604) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2438) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:671) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332 ) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:664) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication .java:115) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java :196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication (EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseA ppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369 ) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179 ) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:5 7) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp l.java:43) at java.lang.reflect.Method.invoke(Method.java:616) !ENTRY org.eclipse.ui 4 4 2010-11-20 15:47:22.987 !MESSAGE An internal error has occurred. !STACK 0 java.lang.OutOfMemoryError: Java heap space at org.eclipse.jface.text.GapTextStore.allocate(GapTextStore.java:339) at org.eclipse.jface.text.GapTextStore.reallocate(GapTextStore.java:290) at org.eclipse.jface.text.GapTextStore.adjustGap(GapTextStore.java:223) at org.eclipse.jface.text.GapTextStore.replace(GapTextStore.java:196) at org.eclipse.jface.text.CopyOnWriteTextStore.replace(CopyOnWriteTextStore.ja va:158) at org.eclipse.jface.text.AbstractDocument.replace(AbstractDocument.java:1184) at org.eclipse.jface.text.AbstractDocument.replace(AbstractDocument.java:1210) at org.eclipse.ui.internal.console.ConsoleDocument.replace(ConsoleDocument.jav a:82) at org.eclipse.ui.internal.console.IOConsolePartitioner.processQueue(IOConsole Partitioner.java:572) at org.eclipse.ui.internal.console.IOConsolePartitioner$QueueProcessingJob.run InUIThread(IOConsolePartitioner.java:520) at org.eclipse.ui.progress.UIJob$1.run(UIJob.java:95) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:134 ) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3515) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3164) at org.eclipse.jface.window.Window.runEventLoop(Window.java:825) at org.eclipse.jface.window.Window.open(Window.java:801) at
Re: Updates Criteria Summary/Brainstorming
sön 2010-11-21 klockan 11:00 +0100 skrev Till Maas: I guess this can be somehow automated. E.g. change Bodhi to drop the karma requirements for packages that had e.g. two subsequent updates without any Bodhi feedback and re-enable it if they get feedback. That would be somewhat counter productive for the goal of actually having testers, as it discourages maintainers looking for testers as a way to improve their release process. Imho the main concerns about the updates criteria is actually confusion between autokarma requirements and minimal karma requirements. At least it was for me when last discussing the topic. The actual requirements isn't very high or unreasonable. What I'd like to see is * aggregated karma across the releases for the same package version. Should be quite sufficient to test most updates on one of the active releases. * autoqa trapping dependency errors and other install failure errors, disallowing push of a completely borked package, including changes in provides breaking other packages. * packages failing the above should only be pushed in a group when dependencies have been satisfied (done automatically once push has been requested for all of them), or after requesting an exception if a dependent package for some reason can't be updated. * better integration of releases in the push process, enabling package maintainers a view of the package status across the releases. * automatic enforcement on order of release, preventing a push or at minimum alerting the maintainer if an earlier version is in a later fedora release (including rawhide). In addition to this the whole concept about how to enable actual users to test packages in a reasonable manner need quite a bit of love to make testing scale. The model of updates-testing and test everything is simply a too high threshold for most users and scares away most, and manually searching for and applying selected updates with yum do not scale. I think something along this model would help greatly in that area: * Keep updates-testing repository model as-is * Give users an easy option to get notified via package-kit when there is updates to selected packages available in updates-testing, enabling the user to select just package x,y,z, selected package groups, or everything of the packages they have installed, and to select if the user wants testing updates to be automatically installed as part of the update process or only notified and requiring manual selection each time. * A new notification icon, reminding users when they have packages from updates-testing installed for which they have not yet given feedback. Packages should automatically disappear from this list when they have been pushed to updates. * Give users a easy way of downgrading to current non-testing release of a package, giving them confidence that they can easily recover should they find or suspect that the updates-testing package fails. This would also need blocking that package release from automatic update from updates-testing. All of this could be combined. E.g. packages with enough testers get test cases and need to fulfill stronger criteria. Packages with not so many testers get test cases and only need to fulfil that similar updates need to receive good karma on one Fedora release. Imho this should be more based on how critical the package is for system operation and quality of past updates than amount or activity of testers. I.e. if a borked update gets pushed out by the package maintainer then that will increase the testing requirement on future updates of the same package for a number of package pushes. Also it could be made easier for maintainers to identify problematic updates, e.g. by warning that the dependencies or provides of an update changed when the update is created. +1 Regards Henrik -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora release model (was Re: Plan for tomorrow's FESCo meeting (2010-11-17))
Hi, On 11/22/2010 12:59 AM, Adam Williamson wrote: On Sun, 2010-11-21 at 23:04 +0100, Kevin Kofler wrote: In short: Want higher-quality updates for previous releases? Then push version upgrades wherever possible (even and especially for libraries, as long as they're ABI-compatible or can be group-pushed with a small set of rebuilt reverse dependencies)! I don't agree with this at all. It's just abusing a stable release cycle to try and make it into something it isn't. I should probably clarify where I'm coming from on this, as my position is probably more nuanced than my mails so far would seem to suggest. I don't necessarily think Fedora works best as a project which does stable releases every six months and supports at least two of them at a time (and often three). As I've written elsewhere, I'd very much like to look into the possibility of changing that. snip It seems like what you want is actually not to have three releases at a time at all but to have one and update it constantly. And I actually rather suspect that would be a model that would work well for Fedora, and I'd like to look into adopting it. Interesting topic (much more so then flaming about the updates policy) I think that we can (and sort of do already) have both. The way I see it, is we have: rawhide (and for a part of the cycle Fedora #+1 testing) Fedora # Fedora #-1 Fedora #-2 Fedora #+1 is for people who want the bleeding edge Fedora # is for people who want the latest and greatest without too much bleeding Fedora #-1 is for people who want it relatively safe and slow Fedora #-2 Does not fit into this picture So taking for example the much much discussed KDE rebases. I think that doing a KDE rebase for Fedora #+1 is a no brainer, for Fedora # is fine as long as it is properly tested and for Fedora #-1 KDE should NOT be rebased. This also matches well with what the KDE people have been reporting, were they can get plenty of testing on Fedora # but all most none on Fedora #-1. I think that the few KDE users which remain on Fedora #-1, do so because they appreciate some stability, and thus should not get (a largely untested) KDE rebase. This is also how I in practice deal with must updates for packages I maintain I try to fix any serious bugs reported against Fedora # and am a lot more conservative when it comes to Fedora #-1. Note that Fedora #-2 does not fit into this view for things at all, Fedora #-2 is meant to allow people to skip a Fedora release. But in practice I think this works out badly, because a relatively new Fedora release like Fedora 14 tends to still have some rough edges and get lots of updates/churn (and thus possible regressions, despite our best effords). This is not at a good point in its cycle to upgrade to for people who like it stable (and sticking with 1 release for an entire year to me sounds like liking it stable). Where as the one which has already been out for 5-6 months (Fedora 13) has seen most rough edges polished away with updates, and the updates rate will have slowed. So maybe it is time we dropped the support duration for a release from 13 to 11 months, and make clear that people should not skip releases. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
fre 2010-11-05 klockan 12:53 + skrev Jóhann B. Guðmundsson: Reports came in Auto responce reply back to the reporter -- QA verified try to duplicate bug -- Bug set to maintainer -- Bug stayed like that until EOL You forgot Bug was actually fixed from upstream relase, but the maintainer overlooked the bugreport when doing the update as there is no integration between update process and bugzilla reminding maintainers there is open bug reports for their package. What I'd like to see as maintainer is: * A reminder about open bugs when making an update. * The ability to easily ping bug reports from an update request, asking for the bug to be retested on the update while in updates-testing. Similar to how confirmed bugs can be pinged but without directly linking those bugs as fixed by the update. * Enabling those who retest bugs as a result of this to add their bug as fixed by the update and positive karma on the update. * Filter karma assignments so testers don't give negative karma on the update if the update as such works but do not fix their bug (not explicitly listed as fixed by the update). Suggested method: * automatically list open bug reports as a comment in the update request template, notifying the maintainer about their presence. * A new update field where maintainer can populate for possibly fixed bugs. When the update is filed those bugzilla reports gets an update notice similar to that added on fixed bugs, but not otherwise included in automatic bug closing etc. * In the bugzilla notice there is a link to provide feedback on the update, automatically including the bug #. * New bug # field when providing update feedback, linking update feedback to relevan bugreports. * Slight adjustment of karma to provide choices Works for me, Problem still present and New problems seen * Works for me is a +1, and also adds the refereced bug as fixed by the update if not already in the list of fixed bugs. * Problem still present is a -1 if the bug is listed as fixed. Otherwise a +/-0. * Regression causing new problems is a -1, and requires a comment explaining the issue and explicit confirmation that the issue is not seen in earlier version. * All three choices automatically update any referenced bugzilla # with the status and comment, avoiding the need to use both tools to keep track of the bug status. Regards Henrik -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
On Saturday, November 20, 2010 23:35:43 Kevin Fenzi wrote: ok, I dug through the devel list for the last month or two and wrote down all the various ideas folks have come up with to change/improve things. Here (in no particular order) are the ideas and some notes from me on how we could enable them. Please feel free to add new (actual/concrete ideas or notes): * Just drop all the requirements/go back to before we had any updates criteria. I like this idea, but I'm pretty sure this won't happen. I don't like the bureaucracy you can see all around you. Fixing problems caused by individual failure (or individual's failure) with new policy/law does not make happy contributors/people. This is the exact behavior of Civil Aviation Authority in my country - after 50 years of no problems there is one a***ole that kills himself because of ignoring physics and self-preservation, as result all sane normal people have to do more paperwork and are more restricted. The only result is pilots are more and more fed up every year. And know what, there are still people willingly breaking the rules so it does not solve anything. Another comment: When I started to work for Fedora, I tried to do my best. You know, there are some comparisons of OSes and distributions. One of the comparisons being How many days OS was vulnerable (with known exploitable security bug). So when there was new CVE-- bug, I tried to fix it as fast as possible, because I wanted to make Fedora The Best Distro. But what happened after I fixed this bug? It took whole week before new build was tagged. Should I work hard if there is no visible result? I was disappointed. Now, packages are tagged quickly and reliably, great improvement (thanks to everyone who helped with this). But again, after things were better we have new policy that delays all bug fixes from being delivered quickly and I'm disappointed again. * Change FN-1 to just security and major bugfix This may be hard to enforce or figure out if something is a major bugfix. This idea would make users less happy, at least from what I see. I manage a few Fedora systems for my friends/relatives who have almost no IT knowledge nor they can use English. They don't care about open-source and other freedoms. They use Linux just because it's free and usable (they always compare it with m$ windoze they used before). In real world, bugs happen, they don't care too much about bugs in sw, if there is visible progress. If they found a bug, they complain to me and I file it in bugzilla. Once the bug is fixed, I report these wonderful news to them and they are really happy. But... remove the bug fix delivered to Fn-1 and they won't be happy, in fact they would think that Linux sucks. Restriction to most critical bugs only is not enough. And no, updating all machines every 6 months is too much disturbing (for them) and time consuming (for me). * allow packages with a %check section to go direct to stable %check can be simple, %check can be complex, but where would you draw the line? Also very limited number of GUI apps has %check (only guess) * setup a remote test env that people could use to test things. I don't think this would make significant difference. People don't test packages because they don't have time, they are lazy, they don't know how to test it or they are just consumers (not enough IT/english knowledge). * require testing only for packages where people have signed up to be testers this could help a little for some cases * Ask maintainers to provide test cases / test cases in wiki for each package? this could help, but it's not always possible to add these test cases. One example: imap server package - new bug that can corrupt mail folders in some circumstances. Maintainer updates package and sets 'type=bugfix' in bodhi, but not always it's possible to write down any test case. It's still a bug fix and it's better to be delivered sooner than wait if anyone out there get's his mail folders corrupted. Actual policy does not help proactivity. * reduced karma requirement on other releases when one has gone stable better than nothing :) Other concrete ideas? let maintainer decide, punish (enforce any policy) only those maintainers who breaks something, not all innocent group -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
lör 2010-11-06 klockan 14:08 +0100 skrev Till Maas: I have no problem to verify a bug when the maintainer is ready to fix it. But it is pretty annoying to verify it within a small time window regularly just to have it ignored till the next EOL date. Understood. And the same issue is also on maintainers in different manners. But I am sad to hear that you see bugs you reconfirm to a new release ignored for a full cycle again. The EOL bugzapper is really no more than a patch to a symptom (garbage collecting in bugzilla due to lack of attention of both maintainer and reporter) than a cure to the cause. Until a better model is found it's the best we have, but the goal should be get rid of the bug or push it forward to next release before EOL. Regards Henrik -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20101122 changes
Compose started at Mon Nov 22 08:15:03 UTC 2010 Broken deps for x86_64 -- beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0()(64bit) beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0(VER_1)(64bit) bognor-regis-0.6.11-1.fc15.i686 requires libnotify.so.1 bognor-regis-0.6.11-1.fc15.x86_64 requires libnotify.so.1()(64bit) db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0 dh-make-0.55-2.fc15.noarch requires debhelper eog-plugins-2.30.0-2.fc14.x86_64 requires libgdata.so.7()(64bit) gedit-vala-0.10.2-2.fc15.i686 requires libvala-0.10.so.0 gedit-vala-0.10.2-2.fc15.x86_64 requires libvala-0.10.so.0()(64bit) 1:gnome-games-extra-2.31.91.1-1.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gnome-gmail-notifier-0.10.1-1.fc14.x86_64 requires libnotify.so.1()(64bit) gnome-pilot-eds-2.32.0-1.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-burn.so.1()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-media.so.1()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevdocument.so.3()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevview.so.3()(64bit) gnome-python2-evolution-2.32.0-1.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) gnome-python2-totem-2.32.0-1.fc14.x86_64 requires libgnome-media-profiles.so.0()(64bit) gnome-rdp-0.2.3-6.fc12.x86_64 requires mono(Mono.Data.SqliteClient) = 0:2.0.0.0 gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-0.6.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-gtk-0.6.so.0()(64bit) gshutdown-0.2-6.fc12.x86_64 requires libnotify.so.1()(64bit) gsql-0.2.1-4.fc12.i686 requires libnotify.so.1 gsql-0.2.1-4.fc12.x86_64 requires libnotify.so.1()(64bit) gyachi-plugin-libnotify-1.2.10-3.fc14.x86_64 requires libnotify.so.1()(64bit) hornsey-1.5.2-0.3.fc15.x86_64 requires libnotify.so.1()(64bit) hornsey-1.5.2-0.3.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) ibus-fbterm-0.9.1-10.fc15.x86_64 requires libibus.so.2()(64bit) ibus-sunpinyin-2.0.2-2.fc15.x86_64 requires libibus.so.2()(64bit) intellij-idea-9.0.1.94.399-12.fc15.x86_64 requires commons-collections ircp-tray-0.7.4-1.fc14.x86_64 requires libnotify.so.1()(64bit) java-gnome-4.0.16-3.fc14.x86_64 requires libnotify.so.1()(64bit) libnotifymm-0.6.1-8.fc14.i686 requires libnotify.so.1 libnotifymm-0.6.1-8.fc14.x86_64 requires libnotify.so.1()(64bit) log4net-1.2.10-13.fc13.x86_64 requires mono(System) = 0:1.0.5000.0 log4net-1.2.10-13.fc13.x86_64 requires mono(System.Data) = 0:1.0.5000.0 log4net-1.2.10-13.fc13.x86_64 requires mono(mscorlib) = 0:1.0.5000.0 log4net-1.2.10-13.fc13.x86_64 requires mono(System.Xml) = 0:1.0.5000.0 log4net-1.2.10-13.fc13.x86_64 requires mono(System.Web) = 0:1.0.5000.0 mars-sim-2.84-6.fc14.noarch requires commons-collections meego-panel-devices-0.2.4-4.fc15.x86_64 requires libdevkit-power-gobject.so.1()(64bit) meego-panel-devices-0.2.4-4.fc15.x86_64 requires libnotify.so.1()(64bit) moblin-panel-status-0.1.21-6.fc14.x86_64 requires libsocialweb-client.so.1()(64bit) moblin-panel-status-0.1.21-6.fc14.x86_64 requires libchamplain-0.6.so.0()(64bit) moblin-panel-status-0.1.21-6.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(System.Drawing) = 0:1.0.5000.0 mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(System.Windows.Forms) = 0:1.0.5000.0 mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(System) = 0:1.0.5000.0 mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(mscorlib) = 0:1.0.5000.0 mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(System.Xml) = 0:1.0.5000.0 nagios-plugins-snmp-disk-proc-1.2-6.fc13.x86_64 requires libnetsnmp.so.20()(64bit) 1:nant-0.85-34.fc13.x86_64 requires mono(ICSharpCode.SharpZipLib) = 0:0.84.0.0 network-manager-netbook-1.7.1-0.1.fc14.x86_64 requires libnotify.so.1()(64bit) nntpgrab-gui-0.6.90-3.fc15.x86_64 requires libnotify.so.1()(64bit) padevchooser-0.9.4-0.11.svn20070925.fc13.x86_64 requires libnotify.so.1()(64bit) pcmanx-gtk2-0.3.9-6.20100618svn.fc14.i686 requires libnotify.so.1 pcmanx-gtk2-0.3.9-6.20100618svn.fc14.x86_64 requires libnotify.so.1()(64bit) pidgin-gfire-0.9.2-2.fc15.x86_64 requires libnotify.so.1()(64bit) qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit) spacewalk-backend-tools-1.2.74-2.fc15.noarch requires spacewalk-admin = 0:0.1.1-0
Re: Fixing the glibc adobe flash incompatibility
On 11/19/2010 09:41 PM, Matej Cepl wrote: Dne 19.11.2010 15:40, Przemek Klosowski napsal(a): - freeze glibc to avoid this bug ever (OK, maybe this one isn't serious) - fix glibc or the flash wrapper to accommodate the buggy clients - bug Adobe to fix the bug ASAP, do nothing in Fedora - refuse to use flash and work towards replacing it with Free software Install nspluginwrapper.x86_64, nspluginwrapper.i686, flash-plugin.i686, alsa-plugins-pulseaudio-1.0.22-1.fc13.x86_64, and alsa-plugins-pulseaudio-1.0.22-1.fc13.i686 with all required dependencies (yes, there is a lot of them, how much are you willing to sacrifice for your YouTube?). Restart Firefox and enjoy! Aside from actually working, flash-plugin.i686 (http://www.adobe.com/go/getflash and select Yum repository) is actually updated so you don't fall so fast victim to all nastiness on the web. 64bit one is IIRC not-upgraded so you can get your browser hosed. That's a good answer. I wonder how we can make sure that people do this. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On 11/22/2010 11:52 AM, Andrew Haley wrote: On 11/19/2010 09:41 PM, Matej Cepl wrote: Dne 19.11.2010 15:40, Przemek Klosowski napsal(a): - freeze glibc to avoid this bug ever (OK, maybe this one isn't serious) - fix glibc or the flash wrapper to accommodate the buggy clients - bug Adobe to fix the bug ASAP, do nothing in Fedora - refuse to use flash and work towards replacing it with Free software Install nspluginwrapper.x86_64, nspluginwrapper.i686, flash-plugin.i686, alsa-plugins-pulseaudio-1.0.22-1.fc13.x86_64, and alsa-plugins-pulseaudio-1.0.22-1.fc13.i686 with all required dependencies (yes, there is a lot of them, how much are you willing to sacrifice for your YouTube?). Restart Firefox and enjoy! Aside from actually working, flash-plugin.i686 (http://www.adobe.com/go/getflash and select Yum repository) is actually updated so you don't fall so fast victim to all nastiness on the web. 64bit one is IIRC not-upgraded so you can get your browser hosed. That's a good answer. I wonder how we can make sure that people do this. Andrew. With guides on for example: * fedoraproject.org * fedorasolved.org * fedoraforum.org * fedora project members blogs As there are a lot of good reasons not to run the 64-bit version at the moment, that makes complete sense. //M -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
fre 2010-11-05 klockan 21:37 +0100 skrev Michael Schwendt: Something is terribly wrong here, if reporter adjusts F12 - F13 - F14 over a period of N months in reply to the automated NEEDINFO requests and still doesn't get any response other than another automated one after six more months. Yes, if a maintainer do not react on a bug which the reporter actively have reproduced in the next Fedora release before that release as well is EOL then yes something is very wrong. This is something we as a project should pick up and make sure it does not happen, just as any other where reporter have provided feedback but maintainer do not respond in reasonable time. But it's really a separate issue from the bugzapper, just made more obviously visible in that context. Look in the archives. It's not the first time I've criticized what this bugzapping script does. It has stopped me from filing lots of issues, both with regard to packaging bugs as well as other problems, because I simply cannot handle the flood of NEEDINFO requests. Agreed, and mentioned some ideas how to mitigate that in another response in this thread. An alternative approach to what I suggested there would be to adjust the flood by starting to nag the reporter much earlier to retest on those reports where there is a newer version of the package available either as an update or in next release. Probably only based on package Version ignoring Release to avoid detecting mass rebuilds as new versions. Regards Henrik -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plan for tomorrow's FESCo meeting (2010-11-17)
On 21 November 2010 18:10, Adam Williamson awilliam redhat.com wrote: If I were a KDE user running F12 I'd feel very unsafe knowing someone was happily pushing updates of the entire environment who did not even have a running F12 machine. I am such a user and I have no such feeling :-) but thanks for asking. ...dex I use updates-testing so u dont have to -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plan for tomorrow's FESCo meeting (2010-11-17)
Adam Williamson wrote: But the fact remains that *right now*, this is what Fedora is. I think that it makes sense to commit to being whatever we are fully. Right now, we're a stable release distribution; we should work to make those releases properly stable, to actually be what we represent ourselves as being. If we follow your strategy of pushing as many updates as possible as aggressively as possible to all stable releases, we're not being a stable release distribution at all, we're just shipping three branches at a time which are all essentially rolling releases and have absolutely no guarantee of stability. It's the worst of all worlds: we get all the messy overheads of supporting three releases at a time, but none of the benefits you get from properly following a stable release model. Well, it's here that we disagree. For me, it's actually the best of both worlds: * as for the strict stable release model and unlike the rolling release model, you get to avoid those changes most likely to break your setup or require manual intervention by staying on the stable release, because maintainers should avoid pushing such disruptive changes to the stable release, * as for the rolling release model and unlike the strict stable release model, you benefit from incremental, backwards-compatible improvements as soon as upstream releases them, so in short, you get all the cool new stuff without the breakage. FWIW, in theory, this isn't even so different from the stable updates vision voted by the Board: they also define a set of disruptive update types which should not be pushed to stable releases; the big difference is that their idea of what's disruptive is VERY DIFFERENT from mine, and IMHO is throwing out the baby with the bathwater (it prevents even those updates that ARE wanted). In addition, I don't like the wording which essentially says don't push an upgrade unless there's a reason to, I believe we should say always push an upgrade unless there's a reason NOT to. It seems like what you want is actually not to have three releases at a time at all but to have one and update it constantly. And I actually rather suspect that would be a model that would work well for Fedora, and I'd like to look into adopting it. But it's *not* the model we have right now, and it doesn't strike me as a bad idea to try and abuse a stable release model by pushing admittedly unstable changes into the stable releases. A stable release into which we cheerily shove new versions of everything just for the hell of it really isn't a stable release, and it has no clear identity separation from the next or previous stable releases, and hence makes the whole idea of having releases rather pointless and just dead weight overhead. No, I don't actually want that. You're attacking a strawman. Stop putting words in my mouth! I DON'T want to get an upgrade such as the one from KDE 3 to 4, the one from Amarok 1 to 2, the one from KDevelop 3 to 4, the one from GNOME 2 to 3 etc. as a regular update! Those are what new releases are for! (And there's your clear identity separation.) Minor feature release upgrades such as from Amarok 2.2 to 2.3 (which DON'T have feature regressions, configuration incompatibilites etc.), on the other hand, are perfectly fine to push as an update, since they're clear improvements (and actually also fix bugs in addition to adding features). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Packages with wrong pom filenames
My recent work on Maven 3 showed that we have quite a few packages in tree that incorrectly use add_to_maven_depmap macro. That is especially true to installing pom files. Therefore I created additional rpmlint check[1] to verify correct placement of pom file as advertised in add_to_maven_depmap. I run this check on all rawhide packages and it came up with a list of 47 packages that have problems with this [2]. I will be filing bugs against these packages and going through them and fixing pom filenames as I go, but if you want to help out...fix them before I catch up :-) [1] http://rpmlint.zarb.org/cgi-bin/trac.cgi/ticket/193 [2] http://sochotni.fedorapeople.org/bad-pom-filename -- Stanislav Ochotnicky sochotni...@redhat.com Associate Software Engineer - Base Operating Systems Brno PGP: 71A1677C Red Hat Inc. http://cz.redhat.com signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The new Update Acceptance Criteria are broken
On Sun, Nov 21, 2010 at 11:39:14PM +0100, Kevin Kofler wrote: Let people use their brains. If they screw up, yell at them, and work on informing people in a better way so such mistakes don't happen again. Everyone makes mistakes. The idea is to provide an opportunity for people's mistakes to become obvious before they break things for large numbers of people. Our maintainers are human, so processes that depend on perfection are inappropriate. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Mojolicious-0.999941.tar.gz uploaded to lookaside cache by yaneti
A file has been added to the lookaside cache for perl-Mojolicious: 7c8d8ae8da9b1390084b9636622364c9 Mojolicious-0.41.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
[perl-Mojolicious] 0.999941 - Latest upstream release.
commit 8c023f661cbde546616eea5b5187b8e184b7819d
Author: Yanko Kaneti yan...@declera.com
Date: Mon Nov 22 15:53:17 2010 +0200
0.41 - Latest upstream release.
.gitignore|1 +
perl-Mojolicious.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e16ef69..d87ced3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,3 +5,4 @@ Mojolicious-0.26.tar.gz
/Mojolicious-0.36.tar.gz
/Mojolicious-0.38.tar.gz
/Mojolicious-0.40.tar.gz
+/Mojolicious-0.41.tar.gz
diff --git a/perl-Mojolicious.spec b/perl-Mojolicious.spec
index dc6fcf7..4f8ad2a 100644
--- a/perl-Mojolicious.spec
+++ b/perl-Mojolicious.spec
@@ -1,5 +1,5 @@
Name: perl-Mojolicious
-Version:0.40
+Version:0.41
Release:1%{?dist}
Summary:A next generation web framework for Perl
License:Artistic 2.0
@@ -50,6 +50,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Mon Nov 22 2010 Yanko Kaneti yan...@declera.com 0.41-1
+- Latest upstream release.
+
* Thu Nov 16 2010 Yanko Kaneti yan...@declera.com 0.40-1
- New upstream release. Turns off IPv6 support. Bugfixes.
diff --git a/sources b/sources
index 08b5600..292db07 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-5fc80b6f5aea7feda1971155fe211491 Mojolicious-0.40.tar.gz
+7c8d8ae8da9b1390084b9636622364c9 Mojolicious-0.41.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: updates-testing trainwreck.
On Sat, 2010-11-20 at 09:20 +1000, Brendan Jones wrote: Isn't there any way we can update the icon cache spec to add a checksum or something? Or is the corruption just wrong data, not bad data? I periodically get nm-applet crashes due to a bad icon cache that I'd rather not have to care about... As an aside, I have noticed nm-applet crashes when changing icon theme - will file a bug. Best file it under gtk2, or gtk3, because the Bluetooth applet (which just sets an icon to a status icon) crashes under those circumstances as well. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Mojolicious] Created tag perl-Mojolicious-0.999941-1.fc15
The lightweight tag 'perl-Mojolicious-0.41-1.fc15' was created pointing to: 8c023f6... 0.41 - Latest upstream release. -- 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: Fedora release model (was Re: Plan for tomorrow's FESCo meeting (2010-11-17))
On 11/22/2010 04:21 AM, Hans de Goede wrote: Hi, On 11/22/2010 12:59 AM, Adam Williamson wrote: It seems like what you want is actually not to have three releases at a time at all but to have one and update it constantly. And I actually rather suspect that would be a model that would work well for Fedora, and I'd like to look into adopting it. The way I see it, is we have: rawhide (and for a part of the cycle Fedora #+1 testing) Fedora # Fedora #-1 Fedora #-2 I agree with the idea of a rolling release model - however I think we need to tune it for our needs - I think of it more closely to the kernel development model but not the same - we have a distro not a kernel. (i) Stable - Fedora M.n (e.g. 14.0) What normal users run. (ii) Staging (or updates testing :-) Staging-Security. * This is the staging area for collections that are deemed worthy of rolling into stable after some wider testing. * Security updates should be in a separate security-staging repo. * Whenever we move a bunch of packages from staging to stable we raise the minor number to M.(n+1). Larger changes may require major number bump if deemed appropriate (e.g. systemd, kde 8.0, gnome 3 and occasionally a kernel update) * Maintainers required to test reasonably anything that hits staging - not on all platforms or in all configs but as many as they can reasonably. * We keep iso file of current major (M.n) and prior major for install purposes (M-1.x) (iii) Development - (aka rawhide) * These should be tested by pulling packages into current stable or staging - just as they would be after they get moved to staging. This is definitely not a separate install, but add-on packages to staging/stable. gene/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
Michal Hlavinka wrote: I like this idea, but I'm pretty sure this won't happen. I don't like the bureaucracy you can see all around you. Fixing problems caused by individual failure (or individual's failure) with new policy/law does not make happy contributors/people. This is the exact behavior of Civil Aviation Authority in my country - after 50 years of no problems there is one a***ole that kills himself because of ignoring physics and self-preservation, as result all sane normal people have to do more paperwork and are more restricted. The only result is pilots are more and more fed up every year. And know what, there are still people willingly breaking the rules so it does not solve anything. +1, so true (and sad). :-( (BTW, it's not just your country, they just get it dictated from the EU. It's the same all over Europe, and it's worse on the other side of the Atlantic.) Another comment: When I started to work for Fedora, I tried to do my best. You know, there are some comparisons of OSes and distributions. One of the comparisons being How many days OS was vulnerable (with known exploitable security bug). So when there was new CVE-- bug, I tried to fix it as fast as possible, because I wanted to make Fedora The Best Distro. But what happened after I fixed this bug? It took whole week before new build was tagged. Should I work hard if there is no visible result? I was disappointed. Now, packages are tagged quickly and reliably, great improvement (thanks to everyone who helped with this). But again, after things were better we have new policy that delays all bug fixes from being delivered quickly and I'm disappointed again. Indeed, these new PITA policies are very demotivating! This idea would make users less happy, at least from what I see. I manage a few Fedora systems for my friends/relatives who have almost no IT knowledge nor they can use English. They don't care about open-source and other freedoms. They use Linux just because it's free and usable (they always compare it with m$ windoze they used before). In real world, bugs happen, they don't care too much about bugs in sw, if there is visible progress. If they found a bug, they complain to me and I file it in bugzilla. Once the bug is fixed, I report these wonderful news to them and they are really happy. But... remove the bug fix delivered to Fn-1 and they won't be happy, in fact they would think that Linux sucks. Restriction to most critical bugs only is not enough. And no, updating all machines every 6 months is too much disturbing (for them) and time consuming (for me). Indeed. I think it's a big mistake to provide only second-class support for Fn-1. The assertion that that's what the people on Fn-1 want is just unfounded, based on a misunderstanding of why people use Fn-1. this could help, but it's not always possible to add these test cases. One example: imap server package - new bug that can corrupt mail folders in some circumstances. Maintainer updates package and sets 'type=bugfix' in bodhi, but not always it's possible to write down any test case. It's still a bug fix and it's better to be delivered sooner than wait if anyone out there get's his mail folders corrupted. Actual policy does not help proactivity. Right, and the big point there should be that a bug which can corrupt mail folders should be fixed IMMEDIATELY, i.e. with a direct stable push! ANY testing requirement there is a failure. Other concrete ideas? let maintainer decide, punish (enforce any policy) only those maintainers who breaks something, not all innocent group +1! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 652158] Use of :locked is deprecated
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=652158 --- Comment #9 from Vadym Chepkov chep...@yahoo.com 2010-11-22 10:08:50 EST --- :( rpm -qi mrtg Name: mrtg Relocations: (not relocatable) Version : 2.16.4Vendor: Fedora Project Release : 2.fc14Build Date: Mon 22 Nov 2010 09:25:08 AM EST Install Date: Mon 22 Nov 2010 09:46:31 AM EST Build Host: x86-02.phx2.fedoraproject.org Use of :locked is deprecated at /usr/share/perl5/Net/SNMP.pm line 588. Use of :locked is deprecated at /usr/share/perl5/Net/SNMP.pm line 655. Use of :locked is deprecated at /usr/share/perl5/Net/SNMP.pm line 708. Use of :locked is deprecated at /usr/share/perl5/Net/SNMP.pm line 764. Use of :locked is deprecated at /usr/share/perl5/Net/SNMP.pm line 869. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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: Plan for tomorrow's FESCo meeting (2010-11-17)
On Mon, 2010-11-22 at 14:13 +0100, Kevin Kofler wrote: I DON'T want to get an upgrade such as the one from KDE 3 to 4, the one from Amarok 1 to 2, the one from KDevelop 3 to 4, the one from GNOME 2 to 3 etc. as a regular update! Those are what new releases are for! (And there's your clear identity separation.) Minor feature release upgrades such as from Amarok 2.2 to 2.3 (which DON'T have feature regressions, configuration incompatibilites etc.), on the other hand, are perfectly fine to push as an update, since they're clear improvements (and actually also fix bugs in addition to adding features). well, thanks for clarifying. I guess as you say then, the issue is just defining what a potentially troublesome update is. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
On Mon, 2010-11-22 at 16:01 +0100, Kevin Kofler wrote: Right, and the big point there should be that a bug which can corrupt mail folders should be fixed IMMEDIATELY, i.e. with a direct stable push! ANY testing requirement there is a failure. How about testing that it doesn't corrupt mail folders even worse? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 649372] Dependency on perl-libwww-perl missing
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=649372 --- Comment #3 from Ian Chapman packa...@amiga-hardware.com 2010-11-22 11:24:26 EST --- Sorry, my wording was misleading. I didn't necessarily mean an explicit dependency on the package name, but an appropriate dependency which ultimately drags in perl-libwww-perl. For example: In these files: SOAP/Transport/HTTP.pm SOAP/Lite.pm you see: require LWP::UserAgent; which would imply a dependency on perl(LWP::UserAgent). The effect of it missing was that SOAP calls over HTTP wouldn't work until perl-libwww-perl was installed. If you'd like, I can write some very basic code to verify this and post it? -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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 652158] Use of :locked is deprecated
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=652158 --- Comment #11 from Harold Campbell hc...@muerte.net 2010-11-22 11:32:21 EST --- Updated mrtg looks good here. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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 649372] Dependency on perl-libwww-perl missing
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=649372 --- Comment #4 from Ian Chapman packa...@amiga-hardware.com 2010-11-22 11:37:43 EST --- Not that Fedora necessarily does the same thing as other distros but perl-libwww-perl is at least a dependency of perl-SOAP-Lite in OpenSUSE and Ubuntu. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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: Fedora 15, new and exciting plans
On Sat, Nov 20, 2010 at 09:49:42PM -0500, Kyle McMartin wrote: On Sun, Nov 21, 2010 at 03:33:56AM +0100, Kevin Kofler wrote: Me. And I'm already angry at having to manually modprobe floppy in rc.local: https://bugzilla.redhat.com/show_bug.cgi?id=567533 If you're angry about a minor inconvenience then I think you might want to seek counsel, but for what it's worth, I'm sorry I haven't gotten around to poking ACPI to see if there's a floppy connected. Hi Kevin, (and Bruno if you're watching) Please try this: https://koji.fedoraproject.org/koji/taskinfo?taskID=2614153 And let me know what the output is on your machine (it uses ACPI to query the _FDE table in firmware, so hopefully we can only bind to it if a floppy is connected.) Grepping for 'fde' and 'floppies' should give me in the info I need. regards, Kyle -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
Kevin Kofler wrote: Right, and the big point there should be that a bug which can corrupt mail folders should be fixed IMMEDIATELY, i.e. with a direct stable push! ANY testing requirement there is a failure. So you'll double, triple, ultra swear that this[1] will never happen again? [1] http://lists.fedoraproject.org/pipermail/announce/2008-December/002572.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Padre-0.74.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Padre: 714f398c6f5a09d0941e53e751267a6d Padre-0.74.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: [Guidelines Change] Changes to the Packaging Guidelines
On Friday 19 November 2010, Stanislav Ochotnicky wrote: Ville: The jpackage_script macro is great and we'll be adding it to the documentation. You are welcome to add it to [1], since I think you know most about it so a few lines describing how it works would be best. Done, https://fedoraproject.org/w/index.php?title=User:Akurtakov/JavaPackagingDraftUpdatediff=208612oldid=206492 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Padre] 0.74 bump
commit 7446a99d8b11d08dc4d5b059aacbcebb8972e0dc
Author: Petr Písař ppi...@redhat.com
Date: Mon Nov 22 17:58:56 2010 +0100
0.74 bump
.gitignore |1 +
perl-Padre.spec | 65 +++---
sources |2 +-
3 files changed, 58 insertions(+), 10 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 9022786..b9df241 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
Padre-0.64.tar.gz
/Padre-0.72.tar.gz
+/Padre-0.74.tar.gz
diff --git a/perl-Padre.spec b/perl-Padre.spec
index 1aad226..b938114 100644
--- a/perl-Padre.spec
+++ b/perl-Padre.spec
@@ -1,6 +1,9 @@
+# Disable X11 tests as there is annoying interactive warning at padre start.
+%global use_x11_tests 0
+
Name: perl-Padre
-Version:0.72
-Release:2%{?dist}
+Version:0.74
+Release:1%{?dist}
Summary:Perl Application Development and Refactoring Environment
License:GPL+ or Artistic
Group: Development/Libraries
@@ -55,7 +58,7 @@ BuildRequires: perl(IPC::Open2)
BuildRequires: perl(IPC::Open3)
BuildRequires: perl(List::MoreUtils) = 0.22
BuildRequires: perl(List::Util) = 1.18
-BuildRequires: perl(Locale::Msgfmt) = 0.14
+BuildRequires: perl(Locale::Msgfmt) = 0.15
BuildRequires: perl(LWP) = 5.815
BuildRequires: perl(Module::Build) = 0.3603
BuildRequires: perl(Module::CoreList)
@@ -96,6 +99,15 @@ BuildRequires: perl(YAML::Tiny) = 1.32
BuildRequires: perl(threads) = 1.71
BuildRequires: perl(threads::shared) = 1.33
BuildRequires: perl(version) = 0.80
+%if %{use_x11_tests}
+# X11 tests:
+BuildRequires: perl(App::Prove)
+# Parts of X Window System needed for tests to run:
+BuildRequires: xorg-x11-server-Xvfb
+BuildRequires: xorg-x11-xinit
+BuildRequires: font(:lang=en)
+%endif
+
Requires: perl(App::cpanminus) = 0.9923
Requires: perl(Class::Adapter) = 1.05
Requires: perl(Class::Unload) = 0.03
@@ -198,7 +210,8 @@ in a directory called .padre.
%prep
%setup -q -n Padre-%{version}
-chmod 755 share/examples/*
+find share/{examples,templates} -type f \( -name '*.pl' -o -name '*.t' \) \
+-exec chmod 755 {} +
%build
@@ -212,26 +225,60 @@ make pure_install DESTDIR=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
-# languages are in different format than find_lang expects
-#%%find_lang Padre-%%{version}/blib/lib/auto/share/dist/Padre/
+
+# languages are in different format than %%find_lang expects
+find ${RPM_BUILD_ROOT}%{perl_vendorlib}/auto/share/dist/Padre/locale/ \
+-type f -name '*.mo' | \
+sed 's|^'$RPM_BUILD_ROOT'||
+s|\(.*/\)\([^.]*\)\(\.mo\)$|%lang(\2) \1\2\3|' %{name}.lang
%{_fixperms} $RPM_BUILD_ROOT/*
+
%check
-make test
+%if %{use_x11_tests}
+xinit /usr/bin/make -s test -- /usr/bin/Xvfb :666 |tee testing.TAP
+prove --exec cat testing.TAP
+%else
+make test
+%endif
+
%clean
rm -rf $RPM_BUILD_ROOT
-%files
+%files -f %{name}.lang
%defattr(-,root,root,-)
%doc Artistic Changes COPYING padre.yml README
-%{perl_vendorlib}/*
+# To omit %%{perl_vendorlib}/auto/share/dist/Padre/locale/* pulled by -f option
+%dir %{perl_vendorlib}/auto
+%dir %{perl_vendorlib}/auto/share
+%dir %{perl_vendorlib}/auto/share/dist
+%dir %{perl_vendorlib}/auto/share/dist/Padre
+ %{perl_vendorlib}/auto/share/dist/Padre/doc
+ %{perl_vendorlib}/auto/share/dist/Padre/examples
+ %{perl_vendorlib}/auto/share/dist/Padre/icons
+ %{perl_vendorlib}/auto/share/dist/Padre/languages
+%dir %{perl_vendorlib}/auto/share/dist/Padre/locale
+ %{perl_vendorlib}/auto/share/dist/Padre/padre-splash*
+ %{perl_vendorlib}/auto/share/dist/Padre/ppm
+ %{perl_vendorlib}/auto/share/dist/Padre/README.txt
+ %{perl_vendorlib}/auto/share/dist/Padre/styles
+ %{perl_vendorlib}/auto/share/dist/Padre/templates
+ %{perl_vendorlib}/auto/share/dist/Padre/timeline
+%{perl_vendorlib}/Padre*
%{_mandir}/man3/*
%{_bindir}/padre
%changelog
+* Fri Nov 19 2010 Petr Pisar ppi...@redhat.com - 0.74-1
+- 1.74 bump
+- Fix templates file permission
+- Mark translation files with %%lang macro
+- Provide X11 server to run X11 tests (disable the tests for now as there is a
+ bug preventing automation).
+
* Mon Oct 11 2010 Marcela Mašláňpvá mmasl...@redhat.com 0.72-2
- apply fix of spec from 633737
diff --git a/sources b/sources
index 9e43805..5406ac9 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-d187654500fd819a70f8e82052d93db4 Padre-0.72.tar.gz
+714f398c6f5a09d0941e53e751267a6d Padre-0.74.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: Updates Criteria Summary/Brainstorming
On Mon, Nov 22, 2010 at 10:49:38AM -0600, Michael Cronenworth wrote: Kevin Kofler wrote: Right, and the big point there should be that a bug which can corrupt mail folders should be fixed IMMEDIATELY, i.e. with a direct stable push! ANY testing requirement there is a failure. So you'll double, triple, ultra swear that this[1] will never happen again? [1] http://lists.fedoraproject.org/pipermail/announce/2008-December/002572.html As though swearing it will never happen is even possible to deliver? Not all software is created equal, some depends on others, some is depended on by *many* others and that's just an unfortunate side effect of the game we play. Software is hard - Knuth There are going to be errors that need fixing, nothing is bullet proof and to think we're going to be able to pull off perfection at all times is just not realistic. -AdamM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
On Mon, Nov 22, 2010 at 09:57:40AM +0100, Henrik Nordström wrote: sön 2010-11-21 klockan 11:00 +0100 skrev Till Maas: I guess this can be somehow automated. E.g. change Bodhi to drop the karma requirements for packages that had e.g. two subsequent updates without any Bodhi feedback and re-enable it if they get feedback. That would be somewhat counter productive for the goal of actually having testers, as it discourages maintainers looking for testers as a way to improve their release process. I do not see how this discourages maintainers. I do not know of any package maintainer that stated that he did not want his updates tested. This would at least encourage people that want better tested updates to commit into testing them. The current problem is not that package maintainers do not want their packages tested, but that updates are delayed without any visible testing. Regards Till pgp18vmm1Pm2D.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
* Adam Miller [22/11/2010 18:03] : As though swearing it will never happen is even possible to deliver? I believe that's Michael's whole point. The whole 'push directly to stable' arguement rests heavily on the principle that an update is always better (from a QA standpoint) than whatever it's replacing. The problem is that there's no way to guarantee this, essentielly because it isn't true. Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 654771] perl-Padre-0.74 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=654771 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Padre-0.74-1.fc15 Resolution||RAWHIDE Last Closed||2010-11-22 12:09:35 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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: Updates Criteria Summary/Brainstorming
On Mon, 2010-11-22 at 18:09 +0100, Emmanuel Seyman wrote: * Adam Miller [22/11/2010 18:03] : As though swearing it will never happen is even possible to deliver? I believe that's Michael's whole point. The whole 'push directly to stable' arguement rests heavily on the principle that an update is always better (from a QA standpoint) than whatever it's replacing. The problem is that there's no way to guarantee this, essentielly because it isn't true. I believe Kevin would say his position is that the update is better than what's there already *sufficiently often* that allowing unrestricted updates is a net benefit (the question is whether an occasional bad update is a worse problem than some updates being delayed for a week or longer in the case of untested critpath updates). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The new Update Acceptance Criteria are broken
On Sun, Nov 21, 2010 at 09:59:42PM -0600, Bruno Wolff III wrote: On Sun, Nov 21, 2010 at 10:35:31 +0100, Till Maas opensou...@till.name wrote: IMHO it is pretty unlikely that people use updates-testing but do not care about posting feedback to Bodhi. I usually notice only when something breaks, not when it keeps working. You can very easy report that you have installed some update, used it and it did not break. This is afaik enough to justify +1 karma. With fedora-easy-karma this takes only a very short time, therefore this is not a very good excuse for the lack of karma in Bodhi. Regards Till pgpp9gYa43QOC.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The new Update Acceptance Criteria are broken
On 11/20/2010 06:02 PM, Adam Williamson wrote: That's not what I'm talking about. There have been multiple instances where updates have been pushed that were *completely broken*: they could not work at all, in any fashion, for anyone. It doesn't happen a lot, but it happens; enough to prove that not all maintainers test updates before pushing them. Just to provide some examples, here are the bugzilla entries for a package that didn't even start up (https://bugzilla.redhat.com/show_bug.cgi?id=591213), and another one for a package that crashed on a first elementary operation (https://bugzilla.redhat.com/show_bug.cgi?id=454045) FYI, I fixed the latter, and the former is still there in Fedora 14. Hopefully AutoQA will solve many of those problems, if we can come up with test cases and a method to check elementary GUI operation. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
Henrik Nordström wrote: * Slight adjustment of karma to provide choices Works for me, Problem still present and New problems seen * Works for me is a +1, and also adds the refereced bug as fixed by the update if not already in the list of fixed bugs. * Problem still present is a -1 if the bug is listed as fixed. Otherwise a +/-0. * Regression causing new problems is a -1, and requires a comment explaining the issue and explicit confirmation that the issue is not seen in earlier version. That should work for bugfix updates, but updates that don't fix bugs will never get any positive karma. You might argue that no update should be done if there are no bugs to fix, but what about bugfixes where the bugs have been reported upstream but not in Red Hat's Bugzilla? I also think there should be separate choices for still works for me and fixes my problem. Fixes my problem would be what you called works for me, while still works for me would be for testers who had no problem before and don't see any regressions. Björn Persson signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
On Sun, Nov 21, 2010 at 10:36:48PM -0600, Garrett Holmstrom wrote: On 11/21/2010 17:51, Björn Persson wrote: Andre Robatino wrote: My feeling is that it would be better for Bodhi to always require a login. Even Bugzilla does that. I suspect that a lot of people who give anonymous karma don't realize that it doesn't count, and would have created an account if they did. And using an account allows people to build a reputation, which is useful in case Bodhi is ever besieged by malicious comments and is forced to disable some accounts, or disable anonymous comments completely. Having a single account for all of Fedora including Bugzilla ought to help somewhat. Anyone who has taken the trouble of reporting a bug could then easily give karma in Bodhi. Separate accounts seems like an unnecessary obstacle to me. +1, though something tells me making it happen would take nothing short of a heroic effort. There's one easy but deeply flawed way to do this -- automatically create a usern...@fedoraproject.org bugzilla account for the user with the password used in FAS. Deeply flawed in this case because the passwords can get out of sync, we're creating accounts when people sometimes want to use a different address in bugzilla and fas, etc. We don't control RH bugzilla so changing bugzilla to be able to use fas to login would be problematic. -Toshio pgphv2IBisyQD.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
On Mon, Nov 22, 2010 at 09:15:17AM -0800, Adam Williamson wrote: On Mon, 2010-11-22 at 18:09 +0100, Emmanuel Seyman wrote: The whole 'push directly to stable' arguement rests heavily on the principle that an update is always better (from a QA standpoint) than whatever it's replacing. The problem is that there's no way to guarantee this, essentielly because it isn't true. I believe Kevin would say his position is that the update is better than what's there already *sufficiently often* that allowing unrestricted updates is a net benefit (the question is whether an occasional bad update is a worse problem than some updates being delayed for a week or longer in the case of untested critpath updates). It is not some update that is delayed, but one that fixes a very bad bug like e.g. a remote code execution vulnerability. And the worst update is afaik that people had to use the command line to update instead of being able to use packagekit or kpackagekit. Regards Till pgp0acY83pfr3.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora release model (was Re: Plan for tomorrow's FESCo meeting (2010-11-17))
On 11/22/2010 09:44 AM, Genes MailLists wrote: repo. * Whenever we move a bunch of packages from staging to stable we raise the minor number to M.(n+1). Larger changes may require major number bump if deemed appropriate (e.g. systemd, kde 8.0, gnome 3 and occasionally a kernel update) Need in addition - * Any major version increase must be verified to be installable from the ISO. * A major version should be imposed every 6 months if it has not for some reason. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The new Update Acceptance Criteria are broken
On Sat, Nov 20, 2010 at 02:09:47PM -0800, Adam Williamson wrote: I do. I don't believe all maintainers do. It's pretty hard to explain why updates that completely prevent the app in question from working, or Btw. this is not a problem that might happen with updates, but also happens with initial critical path packages, e.g. afaics system-config-keyboard cannot be used in Fedora 14: https://bugzilla.redhat.com/show_bug.cgi?id=646041 (If it can be use, please tell me how.) Regards Till pgpz0AHFsGEU9.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora release model (was Re: Plan for tomorrow's FESCo meeting (2010-11-17))
On Mon, 2010-11-22 at 13:23 -0500, Genes MailLists wrote: * A major version should be imposed every 6 months if it has not for some reason. Why? Your idea of tying version bumps to actual changes in the product rather than an arbitrary timeline is an interesting one, but then having a backstop forced version bump every six months even if there is no relevant change completely undercuts the idea. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The new Update Acceptance Criteria are broken
On Mon, 2010-11-22 at 19:29 +0100, Till Maas wrote: On Sat, Nov 20, 2010 at 02:09:47PM -0800, Adam Williamson wrote: I do. I don't believe all maintainers do. It's pretty hard to explain why updates that completely prevent the app in question from working, or Btw. this is not a problem that might happen with updates, but also happens with initial critical path packages, e.g. afaics system-config-keyboard cannot be used in Fedora 14: https://bugzilla.redhat.com/show_bug.cgi?id=646041 (If it can be use, please tell me how.) yeah, I know about that one; it didn't make the cut as a release blocker because it's not actually present on the KDE or GNOME desktops (they have their own keyboard config tools). But it's a head-slapper indeed. I don't know if anyone's actually figured out what the bug is there yet. I *think* it's a case of some underlying change pulling the rug out from under s-c-k, but not sure. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora release model (was Re: Plan for tomorrow's FESCo meeting (2010-11-17))
On 11/22/2010 01:35 PM, Adam Williamson wrote: On Mon, 2010-11-22 at 13:23 -0500, Genes MailLists wrote: * A major version should be imposed every 6 months if it has not for some reason. Why? Your idea of tying version bumps to actual changes in the product rather than an arbitrary timeline is an interesting one, but then having a backstop forced version bump every six months even if there is no relevant change completely undercuts the idea. Good point ... was thinking it was a way to ensure anaconda keeps pace but you're right ... it should follow the actual changes ... Do you have any suggestions how to manage ensuring that each ISO snapshot has a working anaconda ? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File File-Path-Tiny-0.1.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-File-Path-Tiny: 3a2ac2277304b6a1c017f24c8327f55a File-Path-Tiny-0.1.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
[perl-File-Path-Tiny] initial import
commit fc3b917413bc4f25cbd08d6b7884c8271e8849f1
Author: Iain Arnell iarn...@gmail.com
Date: Mon Nov 22 19:50:30 2010 +0100
initial import
.gitignore |1 +
perl-File-Path-Tiny.spec | 48 ++
sources |1 +
3 files changed, 50 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..1854de2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/File-Path-Tiny-0.1.tar.gz
diff --git a/perl-File-Path-Tiny.spec b/perl-File-Path-Tiny.spec
new file mode 100644
index 000..94f934e
--- /dev/null
+++ b/perl-File-Path-Tiny.spec
@@ -0,0 +1,48 @@
+Name: perl-File-Path-Tiny
+Version:0.1
+Release:1%{?dist}
+Summary:Recursive versions of mkdir() and rmdir() without as much
overhead as File::Path
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/File-Path-Tiny/
+Source0:
http://www.cpan.org/authors/id/D/DM/DMUEY/File-Path-Tiny-%{version}.tar.gz
+BuildArch: noarch
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(Test::Pod)
+BuildRequires: perl(Test::Pod::Coverage)
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+
+%{?perl_default_filter}
+
+%description
+The goal here is simply to provide recursive versions of mkdir() and
+rmdir() with as little code and overhead as possible.
+
+%prep
+%setup -q -n File-Path-Tiny-%{version}
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+make pure_install DESTDIR=%{buildroot}
+
+find %{buildroot} -type f -name .packlist -exec rm -f {} \;
+find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null \;
+
+%{_fixperms} %{buildroot}/*
+
+%check
+make test
+
+%files
+%defattr(-,root,root,-)
+%doc Changes README
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Sun Nov 14 2010 Iain Arnell iarn...@gmail.com 0.1-1
+- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index e69de29..e83afa4 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+3a2ac2277304b6a1c017f24c8327f55a File-Path-Tiny-0.1.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
[perl-File-Path-Tiny/f14/master] initial import
Summary of changes: fc3b917... initial import (*) (*) This commit already existed in another branch; no separate mail sent -- 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
[perl-File-Path-Tiny/f13/master] initial import
Summary of changes: fc3b917... initial import (*) (*) This commit already existed in another branch; no separate mail sent -- 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
[perl-File-Path-Tiny/el6/master] initial import
Summary of changes: fc3b917... initial import (*) (*) This commit already existed in another branch; no separate mail sent -- 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
[perl-File-Path-Tiny/el5/master] initial import
Summary of changes: fc3b917... initial import (*) (*) This commit already existed in another branch; no separate mail sent -- 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: Fedora release model (was Re: Plan for tomorrow's FESCo meeting (2010-11-17))
On Mon, 2010-11-22 at 13:47 -0500, Genes MailLists wrote: On 11/22/2010 01:35 PM, Adam Williamson wrote: On Mon, 2010-11-22 at 13:23 -0500, Genes MailLists wrote: * A major version should be imposed every 6 months if it has not for some reason. Why? Your idea of tying version bumps to actual changes in the product rather than an arbitrary timeline is an interesting one, but then having a backstop forced version bump every six months even if there is no relevant change completely undercuts the idea. Good point ... was thinking it was a way to ensure anaconda keeps pace but you're right ... it should follow the actual changes ... Do you have any suggestions how to manage ensuring that each ISO snapshot has a working anaconda ? This is the kind of thing automated testing would help a lot with; we already have some automated testing of anaconda in place, but it doesn't cover many paths, only the most basic - essentially it 'clicks through' anaconda with a very basic hardware setup and checks it can complete. right now the only way to do it would be to run the automated testing as often as possible to catch basic breakage, and the manual installation validation test suite (done by the qa group members) on each ISO snapshot. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora release model (was Re: Plan for tomorrow's FESCo meeting (2010-11-17))
On 11/22/2010 01:59 PM, Adam Williamson wrote: Do you have any suggestions how to manage ensuring that each ISO snapshot has a working anaconda ? This is the kind of thing automated testing would help a lot with; we already have some automated testing of anaconda in place, but it doesn't cover many paths, only the most basic - essentially it 'clicks through' anaconda with a very basic hardware setup and checks it can complete. right now the only way to do it would be to run the automated testing as often as possible to catch basic breakage, and the manual installation validation test suite (done by the qa group members) on each ISO snapshot. Perhaps this can be helped by putting the staging area into a short term freeze prior to things going to stable and make the ISO snapshot available at that time (or maybe it should be rebuilt nightly as well do you think?) That would give a chance for auto-qa as you described as well as normal testers who may want to test a clean install from the snapshot. gene/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The new Update Acceptance Criteria are broken
On Mon, Nov 22, 2010 at 10:43:21AM -0800, Adam Williamson wrote: On Mon, 2010-11-22 at 19:29 +0100, Till Maas wrote: On Sat, Nov 20, 2010 at 02:09:47PM -0800, Adam Williamson wrote: I do. I don't believe all maintainers do. It's pretty hard to explain why updates that completely prevent the app in question from working, or Btw. this is not a problem that might happen with updates, but also happens with initial critical path packages, e.g. afaics system-config-keyboard cannot be used in Fedora 14: https://bugzilla.redhat.com/show_bug.cgi?id=646041 (If it can be use, please tell me how.) yeah, I know about that one; it didn't make the cut as a release blocker because it's not actually present on the KDE or GNOME desktops (they have their own keyboard config tools). But it's a head-slapper indeed. I It is available on both live images, though. And it is a kind of strange reasoning to label it as critical path, but not require that it works at all. don't know if anyone's actually figured out what the bug is there yet. I *think* it's a case of some underlying change pulling the rug out from under s-c-k, but not sure. There is a patch attached to the bug, but I do not know, whether it helps. Regards Till pgpRFHnvKSwM7.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora release model (was Re: Plan for tomorrow's FESCo meeting (2010-11-17))
On Mon, Nov 22, 2010 at 08:18:04AM -0800, Adam Williamson wrote: On Mon, 2010-11-22 at 10:21 +0100, Hans de Goede wrote: The way I see it, is we have: rawhide (and for a part of the cycle Fedora #+1 testing) Fedora # Fedora #-1 Fedora #-2 Fedora #+1 is for people who want the bleeding edge Fedora # is for people who want the latest and greatest without too much bleeding Fedora #-1 is for people who want it relatively safe and slow Fedora #-2 Does not fit into this picture Quite a few people take this view, but I'm not sure it's entirely reliable. As I see it there may well be those who use the system as you suggest - they upgrade every six months but to the *last* release, not the current one, so they're always running F#-1 - but I'm fairly sure there's also those who actually use the current lifecycle system for its stated purpose, which isn't to allow you to constantly run one version out of date, but to run each version for up to twelve months. So they ran F8, then F10, then F12, then F14 - skipping 9, 11 and 13 so they only have to deal with the pain of an update every 12 months. To these types of users, it doesn't necessarily make sense to treat a -1 release differently from a 'current' release. Note that by and large I agree with the combination of Hans's post (what I wishfully would like Fedora's update policy to be) and yours (that currently to various different people it's one of what Hans posts or an opportunity to skip a release or a no-big-updates-once-released all around). I'd just like to point out in response to this paragraph that a few people have posted that they appreciate both an initial rolling release style and a 13 month release cycle. They said that they install a Fedora for testing purposes when it first comes out and enjoy the rapid pace of bugfixes as they test the software in their environment. Then, the update pace slows down at about the same time their ready to push things out to the machines in their env. I think there's likely better ways that they could achieve this if we were optimizing for this, though. -Toshio pgpBu5vZcWUjk.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora release model (was Re: Plan for tomorrow's FESCo meeting (2010-11-17))
On 11/22/2010 11:18 AM, Toshio Kuratomi wrote: They said that they install a Fedora for testing purposes when it first comes out and enjoy the rapid pace of bugfixes as they test the software in their environment. Then, the update pace slows down at about the same time their ready to push things out to the machines in their env. I think there's likely better ways that they could achieve this if we were optimizing for this, though. This sounds like install the newly Branched release (AKA Alpha), which has rapid updates, but should slow down once it goes GOLD, and then be slow and stable for the next 13 months after that. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
Kevin Fenzi wrote: Other concrete ideas? Quite frankly, I do not care for any of the ideas you mentioned. Here's some of my own: * Reduce quarantine time from 7 days to 3 days Reasoning: Mirror syncing. I'm not going to actively seek out and install 30 packages from koji every single day. I'd rather do a yum update and catch everything in updates-testing because those are what are needing testing. Mirrors typically need 24 hours to sync so 3 days will actually allow 2 days of testing. One day for me to install and an extra day just in case I don't update that day (weekend, etc). This just fits my needs though, so feel free to tell us why 7 days was chosen. * Allow direct-to-stable If Signed-off bodhi checkbox (web) or command option (tui) is provided by the maintainer certifying that the maintainer believes the update will work. The check should default to off, and always off, to require human intervention. If the update fails to work then the maintainer should be punished. Said punishment should be written up (yay another policy) and might consist of losing the ability to push direct-to-stable or loss of package ownership. I would prefer this option to be *retroactive* in that the old offenders (dbus, firefox, thunderbird, PackageKit, etc.) already lose their option to be d-t-s. You might put in a clause to allow a time-out period where packages could be allowed to be d-t-s again. In retrospect, having direct-to-stable be opt-out, instead of opt-in as it is now, might cool the waters for some of the more noisy maintainers. I'd be happy with this as a compromise to be a protection feature and still allow liberal Fedora updating. * Implement fedora-qa meta-package -Installs fedora-easy-karma for karma through TUI. -Installs PackageKit plugin to give karma through the gnome-packagekit GUI. (Nothing exists yet, but I'm gonna get started on one soon) -Auto-enable updates-testing. -Provide a program to generate AutoQA scripts (in the future?) This could be a checkbox in anaconda during the software selection. If we want to make QA a serious feature of Fedora it needs more exposure! Making QA easier and highly advertised would only help our cause. Leave everything else as it is. There are only a handful of complainers. Fedora, for the most part, has become update error free. Yes, there are still kinks in the process. Let's iron them out. Also, once AutoQA starts churning against our packages then more of this becomes moot. Let's not forget about it. Once we have enough manpower some of the other ideas about creating tester groups might be feasible but as it is today they would be more harmful than helpful to implement. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 655982] New: perl-CPAN-Checksums-2.07 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-CPAN-Checksums-2.07 is available https://bugzilla.redhat.com/show_bug.cgi?id=655982 Summary: perl-CPAN-Checksums-2.07 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: ASSIGNED Keywords: FutureFeature, Triaged Severity: medium Priority: low Component: perl-CPAN-Checksums AssignedTo: mmasl...@redhat.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com Classification: Fedora Latest upstream release: 2.07 Current version in Fedora Rawhide: 2.06 URL: http://search.cpan.org/dist/CPAN-Checksums/ Please consult the package update guidelines before you issue an update to a stable branch: https://fedoraproject.org/wiki/Package_update_guidelines More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_Release_Monitoring -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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 655985] New: perl-PAR-Packer-1.008 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-PAR-Packer-1.008 is available https://bugzilla.redhat.com/show_bug.cgi?id=655985 Summary: perl-PAR-Packer-1.008 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: ASSIGNED Keywords: FutureFeature, Triaged Severity: medium Priority: low Component: perl-PAR-Packer AssignedTo: mmasl...@redhat.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com Classification: Fedora Latest upstream release: 1.008 Current version in Fedora Rawhide: 1.007 URL: http://search.cpan.org/dist/PAR-Packer/ Please consult the package update guidelines before you issue an update to a stable branch: https://fedoraproject.org/wiki/Package_update_guidelines More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_Release_Monitoring -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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 655986] New: perl-PPIx-EditorTools-0.11 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-PPIx-EditorTools-0.11 is available https://bugzilla.redhat.com/show_bug.cgi?id=655986 Summary: perl-PPIx-EditorTools-0.11 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: ASSIGNED Keywords: FutureFeature, Triaged Severity: medium Priority: low Component: perl-PPIx-EditorTools AssignedTo: mmasl...@redhat.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com Classification: Fedora Latest upstream release: 0.11 Current version in Fedora Rawhide: 0.10 URL: http://search.cpan.org/dist/PPIx-EditorTools/ Please consult the package update guidelines before you issue an update to a stable branch: https://fedoraproject.org/wiki/Package_update_guidelines More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_Release_Monitoring -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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: Updates Criteria Summary/Brainstorming
On 11/22/2010 11:42 AM, Michael Cronenworth wrote: * Allow direct-to-stable If Signed-off bodhi checkbox (web) or command option (tui) is provided by the maintainer certifying that the maintainer believes the update will work. The check should default to off, and always off, to require human intervention. If the update fails to work then the maintainer should be punished. Said punishment should be written up (yay another policy) and might consist of losing the ability to push direct-to-stable or loss of package ownership. I would prefer this option to be *retroactive* in that the old offenders (dbus, firefox, thunderbird, PackageKit, etc.) already lose their option to be d-t-s. You might put in a clause to allow a time-out period where packages could be allowed to be d-t-s again. In retrospect, having direct-to-stable be opt-out, instead of opt-in as it is now, might cool the waters for some of the more noisy maintainers. I'd be happy with this as a compromise to be a protection feature and still allow liberal Fedora updating. You should clarify this. It is possible for an update to go direct to stable. If it gets sufficient karma between the time the update is submitted (when people on bugs will get a ping) and when the next releng push occurs (onceish a week dayish), the update will by-pass updates-testing and go directly to stable. For an update with an autopush karma level of 1, that could easily happen, particularly if it's an update to fix something people actively care about (read filed a bug about) It sounds like what you're asking for is the ability to have a 0 karma autopush limit. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
On 11/22/2010 11:56 AM, Michael Cronenworth wrote: It was my understanding of reading the complaints that this is what they [complainers] desire - a reversal of what we require now (3 karma and/or proventester if critpath). Critpath requires +1 proven tester and +1 anybody. Total of +2. Non crit-path requires a minimum of +1 anybody or a 7 day timeout I do believe. I do not believe we require +3 anywhere. We /default/ the karma autopush level at +3/-3, but that's just a suggestion. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
Jesse Keating wrote: Critpath requires +1 proven tester and +1 anybody. Total of +2. Non crit-path requires a minimum of +1 anybody or a 7 day timeout I do believe. I do not believe we require +3 anywhere. We/default/ the karma autopush level at +3/-3, but that's just a suggestion. Argh. Yes. Thanks for correcting me. I'm on autopilot. There's too much time to think and not enough time to work. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
On Mon, 2010-11-22 at 12:02 -0800, Jesse Keating wrote: On 11/22/2010 11:56 AM, Michael Cronenworth wrote: It was my understanding of reading the complaints that this is what they [complainers] desire - a reversal of what we require now (3 karma and/or proventester if critpath). Critpath requires +1 proven tester and +1 anybody. Total of +2. Non crit-path requires a minimum of +1 anybody or a 7 day timeout I do believe. I do not believe we require +3 anywhere. We /default/ the karma autopush level at +3/-3, but that's just a suggestion. we should probably change it to +2 or even +1. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
pdftk requires tomcat5?
Sizewise this didn't end up being an awful cost for me, but why on earth would this happen? Installing: pdftk x86_64 1.41-27.fc14 fedora 76 k Installing for dependencies: bouncycastlex86_64 1.45-1.fc13fedora 3.3 M bouncycastle-mail x86_64 1.45-1.fc13fedora 517 k bouncycastle-tspx86_64 1.45-1.fc13fedora 105 k itext x86_64 2.1.7-6.fc13 fedora 3.0 M javamailx86_64 1.4.3-2.fc13 fedora 925 k tomcat5-jsp-2.0-api noarch 5.5.27-7.4.fc12fedora 73 k tomcat5-servlet-2.4-api noarch 5.5.27-7.4.fc12fedora 114 k --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pdftk requires tomcat5?
On Mon, Nov 22, 2010 at 3:11 PM, Casey Dahlin wrote: Sizewise this didn't end up being an awful cost for me, but why on earth would this happen? Installing: pdftk x86_64 1.41-27.fc14 fedora 76 k Installing for dependencies: bouncycastle x86_64 1.45-1.fc13 fedora 3.3 M bouncycastle-mail x86_64 1.45-1.fc13 fedora 517 k bouncycastle-tsp x86_64 1.45-1.fc13 fedora 105 k itext x86_64 2.1.7-6.fc13 fedora 3.0 M javamail x86_64 1.4.3-2.fc13 fedora 925 k tomcat5-jsp-2.0-api noarch 5.5.27-7.4.fc12 fedora 73 k tomcat5-servlet-2.4-api noarch 5.5.27-7.4.fc12 fedora 114 k --CJD A little bugzilla search might help https://bugzilla.redhat.com/show_bug.cgi?id=650390 I just typed pdftk in the quick search box on bugzilla and hit enter. Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pdftk requires tomcat5?
On Mon, Nov 22, 2010 at 03:19:35PM -0500, Orcan Ogetbil wrote: On Mon, Nov 22, 2010 at 3:11 PM, Casey Dahlin wrote: Sizewise this didn't end up being an awful cost for me, but why on earth would this happen? Installing: pdftk x86_64 1.41-27.fc14 fedora 76 k Installing for dependencies: bouncycastle x86_64 1.45-1.fc13 fedora 3.3 M bouncycastle-mail x86_64 1.45-1.fc13 fedora 517 k bouncycastle-tsp x86_64 1.45-1.fc13 fedora 105 k itext x86_64 2.1.7-6.fc13 fedora 3.0 M javamail x86_64 1.4.3-2.fc13 fedora 925 k tomcat5-jsp-2.0-api noarch 5.5.27-7.4.fc12 fedora 73 k tomcat5-servlet-2.4-api noarch 5.5.27-7.4.fc12 fedora 114 k --CJD A little bugzilla search might help https://bugzilla.redhat.com/show_bug.cgi?id=650390 I just typed pdftk in the quick search box on bugzilla and hit enter. Somehow didn't think to check BZ for this sort of problem. Thanks for pointing that out though. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora release model (was Re: Plan for tomorrow's FESCo meeting (2010-11-17))
On Mon, Nov 22, 2010 at 8:15 PM, mike cloaked mike.cloa...@gmail.com wrote: On Mon, Nov 22, 2010 at 6:59 PM, Adam Williamson awill...@redhat.com wrote: Good point ... was thinking it was a way to ensure anaconda keeps pace but you're right ... it should follow the actual changes ... Do you have any suggestions how to manage ensuring that each ISO snapshot has a working anaconda ? During the runup period to F14 release I published a method for taking an iso and replacing the anaconda in the iso - which can then be used for a test install. This is detailed in a posting around a month before f14 GA if you want to check it out. This would certainly be a way to test anaconda with all other components unchanged but it does need a current iso to be built on the current package set. My original post is at http://lists.fedoraproject.org/pipermail/test/2010-October/094752.html if you are interested. -- mike c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
Here's the latest list of ideas culled from this thread. Note: these are NOT my ideas, I am just gathering them up so fesco can discuss them. Feel free to add more concrete ideas, or let me know if I missed one you had posted. If folks could avoid me too or posts that contain no new information it would be easier for me to gather the actual ideas. ;) I've split things into General, Security, Critpath and non security/critpath to help organize them. Keep the ideas coming... General: * Just drop all the requirements/go back to before we had any updates criteria. * back off current setup until autoqa is ready, see what we want to do after that lands. * Change FN-1 to just security and major bugfix. Nothing else allowed. * allow packages with a %check section to go direct to stable. * setup a remote test env that people could use to test things. * require testing only for packages where people have signed up to be testers. * Ask maintainers to provide test cases / test cases in wiki for each package * have a way to get interested testers notified on bodhi updates for packages they care about. * reduced karma requirement on other releases when one has gone stable * aggregated karma across the releases for the same package version. * PK updates-testing integration of some kind. * allow anon karma to count. * setup fedora-qa package or group to more easily bring up more testers. Security updates: * allow security updates to go direct to stable * ask QA to commit to testing security updates * allow timeout for security updates before going to stable. Critpath updates: * allow critpath timeout for going to stable. Non critpath/security: * reduce timeout for non critpath from 7 to 3 days. * change default autokarma to 2 or 1. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plan for tomorrow's FESCo meeting (2010-11-17)
On Sun, Nov 21, 2010 at 1:54 PM, Kevin Kofler kevin.kof...@chello.at wrote: Adam Williamson wrote: How do you expect to be able to maintain an entire desktop environment on a distribution you don't even have installed? I have some sympathy for the 'fifty people said it works on F14, it probably works on F12 too' argument, but for a *small, leaf* package, not for an entire desktop environment! If I were a KDE user running F12 I'd feel very unsafe knowing someone was happily pushing updates of the entire environment who did not even have a running F12 machine. I've sometimes actually done testing on older releases out of sheer laziness to upgrade to a newer one (see also me testing that F13 KDE 4.5.3 upgrade), but with all this bullying of Want current software? Upgrade your Fedora!, with previous supported releases getting only second-class upgrade support, that's going to stop soon (in fact, I'll probably upgrade my machines to F14 before the end of the month). (Pretty much everyone else in KDE SIG always runs the latest Fedora. I'm almost the only one left on F13.) So by limiting the kind of support previous releases get, you're actually INCREASING the risk of untested updates, by making it unattractive for your developers to run those releases. So they stay in updates-testing until someone does actually test them. We all know that the longer that updates wait in updates-testing the more likely the world will stop spinning. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Please Help Test 389 Directory Server 1.2.7
389-ds-base-1.2.7 is now in Testing. This release adds some new features and fixes many bugs. Please help us test. The sooner we can get this release tested, the sooner we can push it to Stable and make it generally available. Installation yum install 389-ds --enablerepo=updates-testing # or for EPEL yum install 389-ds --enablerepo=epel-testing setup-ds-admin.pl Upgrade yum upgrade --enablerepo=updates-testing 389-ds-base 389-admin # or for EPEL yum upgrade --enablerepo=epel-testing 389-ds-base 389-admin setup-ds-admin.pl -u How to Give Feedback The best way to provide feedback is via the Fedora Update system. Each update is broken down by package and platform. For example, if you are using Fedora 12, and you have successfully installed or upgraded all of the packages, and the console and etc. works, then go to the links below for Fedora 12 and provide feedback. * 389-ds-base-1.2.7 ** EL-5 - https://admin.fedoraproject.org/updates/389-ds-base-1.2.7-1.el5 ** Fedora 12 - https://admin.fedoraproject.org/updates/389-ds-base-1.2.7-1.fc12 ** Fedora 13 - https://admin.fedoraproject.org/updates/389-ds-base-1.2.7-1.fc13 ** Fedora 14 - https://admin.fedoraproject.org/updates/389-ds-base-1.2.7-1.fc14 scroll down to the bottom of the page, and click on the Add a comment link * select one of the Works for me or Does not work radio buttons, add text, and click on the Add Comment button If you are using a build on another platform, just send us an email to 389-us...@lists.fedoraproject.org Reporting Bugs If you find a bug, or would like to see a new feature, you can enter it here - https://bugzilla.redhat.com/enter_bug.cgi?product=389 More Information * Release Notes - http://port389.org/wiki/Release_Notes * Install_Guide - http://port389.org/wiki/Install_Guide * Download - http://port389.org/wiki/Download ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plan for tomorrow's FESCo meeting (2010-11-17)
On Mon, Nov 22, 2010 at 12:31:05PM -0800, Mike Fedyk wrote: So they stay in updates-testing until someone does actually test them. We all know that the longer that updates wait in updates-testing the more likely the world will stop spinning. It is totally annoying and time consuming to hit fixed bugs again, just because the update has not been pushed from testing to stable. I cannot really imagine that I am the only one experiencing this ever and ever again. E.g. just today when I wanted to debug f-e-k on the F14 test machine provided for package maintainers, ipython did not work at all, because it required an X server. The bug was already reported and fixed, but the update only in testing. Regards Till pgp6ha9vsbZl4.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plan for tomorrow's FESCo meeting (2010-11-17)
On Mon, 22 Nov 2010 21:47:59 +0100 Till Maas opensou...@till.name wrote: It is totally annoying and time consuming to hit fixed bugs again, just because the update has not been pushed from testing to stable. I cannot really imagine that I am the only one experiencing this ever and ever again. E.g. just today when I wanted to debug f-e-k on the F14 test machine provided for package maintainers, ipython did not work at all, because it required an X server. The bug was already reported and fixed, but the update only in testing. You mean the f14-test.scrye.com machine? oops. I meant to have updates-testing enabled on all those, and indeed it is except for that instance. ;( Enabled it there. should be up to date in a bit. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
Adam Williamson awill...@redhat.com writes: On Mon, 2010-11-22 at 12:02 -0800, Jesse Keating wrote: Critpath requires +1 proven tester and +1 anybody. Total of +2. Non crit-path requires a minimum of +1 anybody or a 7 day timeout I do believe. I do not believe we require +3 anywhere. We /default/ the karma autopush level at +3/-3, but that's just a suggestion. we should probably change it to +2 or even +1. Yeah. Or at least document that the maintainer is allowed to reduce it; that's entirely unclear given the current policy and bodhi UI. As things stand, there is a clear expectation embodied in the default behavior that you should be able to get +3 karma. The fundamental complaint (at least as I've been making it) is that that's unrealistic given the actual available testing manpower. It's not undesirable; it'd be great if that actually did happen. But it's just not going to happen, most of the time for most packages. (And yeah, if we allow +1 autopush, we should definitely expect -1 is sufficient to unpush. Maybe bodhi should restrict the combination of those two settings, rather than either one alone?) regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
Toshio Kuratomi wrote: On Sun, Nov 21, 2010 at 10:36:48PM -0600, Garrett Holmstrom wrote: On 11/21/2010 17:51, Björn Persson wrote: Andre Robatino wrote: My feeling is that it would be better for Bodhi to always require a login. Even Bugzilla does that. I suspect that a lot of people who give anonymous karma don't realize that it doesn't count, and would have created an account if they did. And using an account allows people to build a reputation, which is useful in case Bodhi is ever besieged by malicious comments and is forced to disable some accounts, or disable anonymous comments completely. Having a single account for all of Fedora including Bugzilla ought to help somewhat. Anyone who has taken the trouble of reporting a bug could then easily give karma in Bodhi. Separate accounts seems like an unnecessary obstacle to me. +1, though something tells me making it happen would take nothing short of a heroic effort. There's one easy but deeply flawed way to do this -- automatically create a usern...@fedoraproject.org bugzilla account for the user with the password used in FAS. Deeply flawed in this case because the passwords can get out of sync, we're creating accounts when people sometimes want to use a different address in bugzilla and fas, etc. Hmm, but it says here that we should use the same address in Bugzilla and FAS: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers We don't control RH bugzilla so changing bugzilla to be able to use fas to login would be problematic. That solution seems backwards anyway. I think most new contributors probably report bugs long before they become packagers, so they need Bugzilla accounts before they need FAS accounts. How about changing Bodhi to allow login with either a FAS account or a Bugzilla account? Would that be difficult to do? Björn Persson signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
On Mon, Nov 22, 2010 at 12:02:49PM -0800, Jesse Keating wrote: On 11/22/2010 11:56 AM, Michael Cronenworth wrote: It was my understanding of reading the complaints that this is what they [complainers] desire - a reversal of what we require now (3 karma and/or proventester if critpath). Critpath requires +1 proven tester and +1 anybody. Total of +2. Non crit-path requires a minimum of +1 anybody or a 7 day timeout I do believe. I do not believe we require +3 anywhere. We /default/ the karma autopush level at +3/-3, but that's just a suggestion. Afaik there is currently no distinction between the requirement for non crit-path updates and the karma autopush level. Therefore by default non critpath updates require +3 karma, unless this has been changed since the beginning for the update criteria enforcement. Regards Till pgpBsS8Oztt2X.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
On Mon, 2010-11-22 at 16:39 -0500, Tom Lane wrote: Adam Williamson awill...@redhat.com writes: On Mon, 2010-11-22 at 12:02 -0800, Jesse Keating wrote: Critpath requires +1 proven tester and +1 anybody. Total of +2. Non crit-path requires a minimum of +1 anybody or a 7 day timeout I do believe. I do not believe we require +3 anywhere. We /default/ the karma autopush level at +3/-3, but that's just a suggestion. we should probably change it to +2 or even +1. Yeah. Or at least document that the maintainer is allowed to reduce it; that's entirely unclear given the current policy and bodhi UI. The bodhi 2.0 solution is to decouple autopush and acceptance: they really shouldn't be paired, I think it's just an unintended consequence of the current code. You should be able to set +1 threshold for acceptance allowing the maintainer to then push manually, and +3 for autopush, for instance. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 632176] perl-Log-Log4perl-1.31 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=632176 --- Comment #7 from Fedora Update System upda...@fedoraproject.org 2010-11-22 17:20:02 EST --- perl-Log-Log4perl-1.30-1.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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 632176] perl-Log-Log4perl-1.31 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=632176 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-Log-Log4perl-1.30-1.fc ||14 Resolution||ERRATA Last Closed||2010-11-22 17:20:06 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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: Plan for tomorrow's FESCo meeting (2010-11-17)
On 11/22/10 12:47 PM, Till Maas wrote: On Mon, Nov 22, 2010 at 12:31:05PM -0800, Mike Fedyk wrote: So they stay in updates-testing until someone does actually test them. We all know that the longer that updates wait in updates-testing the more likely the world will stop spinning. It is totally annoying and time consuming to hit fixed bugs again, just because the update has not been pushed from testing to stable. I cannot really imagine that I am the only one experiencing this ever and ever again. E.g. just today when I wanted to debug f-e-k on the F14 test machine provided for package maintainers, ipython did not work at all, because it required an X server. The bug was already reported and fixed, but the update only in testing. Regards Till Did you test the update, and provide the karma? -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
On 11/22/10 1:50 PM, Till Maas wrote: On Mon, Nov 22, 2010 at 12:02:49PM -0800, Jesse Keating wrote: On 11/22/2010 11:56 AM, Michael Cronenworth wrote: It was my understanding of reading the complaints that this is what they [complainers] desire - a reversal of what we require now (3 karma and/or proventester if critpath). Critpath requires +1 proven tester and +1 anybody. Total of +2. Non crit-path requires a minimum of +1 anybody or a 7 day timeout I do believe. I do not believe we require +3 anywhere. We /default/ the karma autopush level at +3/-3, but that's just a suggestion. Afaik there is currently no distinction between the requirement for non crit-path updates and the karma autopush level. Therefore by default non critpath updates require +3 karma, unless this has been changed since the beginning for the update criteria enforcement. Regards Till I swear I've been able to set karma levels at 1 for non-critpath updates. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
On Mon, Nov 22, 2010 at 7:01 AM, Kevin Kofler kevin.kof...@chello.at wrote: Michal Hlavinka wrote: this could help, but it's not always possible to add these test cases. One example: imap server package - new bug that can corrupt mail folders in some circumstances. Maintainer updates package and sets 'type=bugfix' in bodhi, but not always it's possible to write down any test case. It's still a bug fix and it's better to be delivered sooner than wait if anyone out there get's his mail folders corrupted. Actual policy does not help proactivity. Right, and the big point there should be that a bug which can corrupt mail folders should be fixed IMMEDIATELY, i.e. with a direct stable push! ANY testing requirement there is a failure. Install package from updates-testing, then +1 to karma after it works for you with your tests and normal workload. Simple. No need to foist possibly broken software on everyone. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
On Mon, Nov 22, 2010 at 9:04 AM, Till Maas opensou...@till.name wrote: On Mon, Nov 22, 2010 at 09:57:40AM +0100, Henrik Nordström wrote: sön 2010-11-21 klockan 11:00 +0100 skrev Till Maas: I guess this can be somehow automated. E.g. change Bodhi to drop the karma requirements for packages that had e.g. two subsequent updates without any Bodhi feedback and re-enable it if they get feedback. That would be somewhat counter productive for the goal of actually having testers, as it discourages maintainers looking for testers as a way to improve their release process. I do not see how this discourages maintainers. I do not know of any package maintainer that stated that he did not want his updates tested. This would at least encourage people that want better tested updates to commit into testing them. The current problem is not that package maintainers do not want their packages tested, but that updates are delayed without any visible testing. The result is that if you have several updates without any karma points (positive or negative) in bohdi, your updates get out faster. Once someone does start giving it karma (again, positive or negative) your update is not subject to getting more karma points in order to hit the updates repo. Thus you punish the maintainer by giving testing their packages. It may work better if karma enforcement only comes into effect if negative karma is given to an update. This still builds a reactive system instead of a preventative system. An only reactive system will not help prevent bad updates from getting out in the first place. That said, adding a reactive component to a preventative system would be a good thing. If a maintainer releases one package that puts regressions into the stable updates repo, then the minimum karma doubles on all of their packages doubles for 2 months or something like that. So feel free to push directly to stable as often as you want, but once you introduce one regression, you have to satisfy 10 karma on every package you update. The second time, you have to satisfy 20 karma on every package you update and so on. Simply because we can't trust that maintainer anymore. Really, allowing regressions to make it to stable is so costly simply because it has to be fixed several magnitudes more times than if it is caught by people actually testing packages before they're released to the masses. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Board, FESCo FAmSCo Elections - Voting Information
Greetings, The elections for the Fedora Board, Fedora Engineering Steering Committee (FESCo), and the Fedora Ambassadors Steering Committee (FAmSCo) began at UTC on 20th November 2010, and are scheduled to run until 23:59 UTC on 28th November 2010. (Please refer to a UTC time zone converter, such as http://www.timeanddate.com/worldclock/converter.html if you are unsure of your time zone's relation to UTC.) All groups have chosen to use the Range Voting method (http://en.wikipedia.org/wiki/Range_voting). Ballots may be cast on the Fedora Elections System at https://admin.fedoraproject.org/voting. If this is the first time you've used the voting system, please refer to the Fedora Elections Guide, currently located at http://pfrields.fedorapeople.org/documents/elections-guide. To read more about the candidates, please refer to each group's nomination pages: * FAmSCo: http://fedoraproject.org/wiki/FAmSCo_election_2010_nominations * Fedora Project Board: http://fedoraproject.org/wiki/Board/Elections/Nominations * FESCo: http://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations For more general information about the election, as well as finding links for reading candidate answers to questionnaires and IRC town hall transcripts, please refer to http://fedoraproject.org/wiki/Elections. Please remember to cast your vote! Thanks, Robyn ___ 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
Re: Plan for tomorrow's FESCo meeting (2010-11-17)
On Mon, 22 Nov 2010 14:32:04 -0800 Jesse Keating wrote: On 11/22/10 12:47 PM, Till Maas wrote: On Mon, Nov 22, 2010 at 12:31:05PM -0800, Mike Fedyk wrote: So they stay in updates-testing until someone does actually test them. We all know that the longer that updates wait in updates-testing the more likely the world will stop spinning. It is totally annoying and time consuming to hit fixed bugs again, just because the update has not been pushed from testing to stable. I cannot really imagine that I am the only one experiencing this ever and ever again. E.g. just today when I wanted to debug f-e-k on the F14 test machine provided for package maintainers, ipython did not work at all, because it required an X server. The bug was already reported and fixed, but the update only in testing. Regards Till Did you test the update, and provide the karma? Yes, it was his karma, that pushed it to stable now :-) Thanks Till! -Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plan for tomorrow's FESCo meeting (2010-11-17)
On Sun, Nov 21, 2010 at 11:11 PM, Jan Kratochvil wrote: It is already complicated enough to push a patch for Fedora. One has to find the right unused Patch number, add %patch, git add it, bump Revision, create a %changelog entry with the BZ number, run Koji build, run Bodhi, copy the %changelog entry and BZ number into Bodhi and ... No. This has been stated many times on this list. The specfile changelog reflects the changes to the specfile. The bodhi changelog reflects the changes to the software. And this is what the user sees on his PackageKit client. So it needs to be the user-friendly changelog, not the development notes. Please don't put specfile changelog entries into bodhi. Thank you, Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Mon, 2010-11-15 at 15:44 +, Matthew Garrett wrote: On Fri, Nov 12, 2010 at 09:35:54AM -0700, Kevin Fenzi wrote: * Can we finally remove hal? (xfce4.8 shouldn't need it anymore with any luck). Not without a pile of X changes, which themselves are blocking on upstream kernel changes that I've submitted but which haven't been merged. For brightness? For GNOME at least, this is worked around in: http://git.gnome.org/browse/gnome-power-manager/tree/src/gpm-backlight-helper.c though a cleaner fix would certainly be appreciated. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Mon, 2010-11-15 at 10:23 -0500, Nathaniel McCallum wrote: On 11/15/2010 10:11 AM, Adam Jackson wrote: On Fri, 2010-11-12 at 09:35 -0700, Kevin Fenzi wrote: * Can we finally remove hal? (xfce4.8 shouldn't need it anymore with any luck). Only 30 packages left requiring it, according to repoquery. smolt's probably the most interesting one to fix, if anyone's looking for a project. For the curious, the 30 packages (in rawhide) are: And gnome-lirc-properties as well. Which, it seems, wouldn't have worked if installed from a minimal installation. Oops. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The new Update Acceptance Criteria are broken
On Sat, Nov 20, 2010 at 6:16 PM, Kevin Kofler kevin.kof...@chello.at wrote: But one of the main points of this subthread is that that waiting period is way too long for some urgent fixes (security fixes, regression fixes etc.). If it's really a regression, then you will have interested users who will test from updates-testing and provide karma. Security karma should come from the security team. Also security updates should not have any other changes mixed in. If it makes other changes take longer to get to stable (because the update after the security update needs the security update as well as the other updates that were queued up prior to the security update), well that's just how it is. So you have these package versions: foo-2 foo-2.1 foo-3 foo-2 is vulnerable to the exploit. foo-2.1 is and update that does not contain any changes except what is required to close the vulnerability. foo-3 has changes from foo-2.1 as well as the other updates that were planned. The idea is that you stop everything, make the security update based on the latest stable package, and then submit the update for testing (by the security team?). then you continue with your normal packaging workflow. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Mon, Nov 22, 2010 at 11:39:29 -0500, Kyle McMartin k...@mcmartin.ca wrote: Hi Kevin, (and Bruno if you're watching) Please try this: https://koji.fedoraproject.org/koji/taskinfo?taskID=2614153 I've been running that kernel for a couple of days on one machine with floppies. (I am go to switch to -62 tonight.) Two other machines I have with floppies are running rawhide. One is essentially the same as the one I with get the info from shortly. The other is significantly different. And let me know what the output is on your machine (it uses ACPI to query the _FDE table in firmware, so hopefully we can only bind to it if a floppy is connected.) Grepping for 'fde' and 'floppies' should give me in the info I need. I'm going to start by assuming you want us to look at dmesg output. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Mon, Nov 22, 2010 at 11:39:29 -0500, Kyle McMartin k...@mcmartin.ca wrote: On Sat, Nov 20, 2010 at 09:49:42PM -0500, Kyle McMartin wrote: And let me know what the output is on your machine (it uses ACPI to query the _FDE table in firmware, so hopefully we can only bind to it if a floppy is connected.) Grepping for 'fde' and 'floppies' should give me in the info I need. I didn't find either string in messages or dmesg output. My machines are all from around 2003, in case more recent ACPI support is needed. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Mon, Nov 22, 2010 at 08:00:55PM -0600, Bruno Wolff III wrote: https://koji.fedoraproject.org/koji/taskinfo?taskID=2614153 I've been running that kernel for a couple of days on one machine with floppies. (I am go to switch to -62 tonight.) Two other machines I have with floppies are running rawhide. One is essentially the same as the one I with get the info from shortly. The other is significantly different. Unlikely, given I only built it on Sunday night... It's a scratch build with a patch included. (Yes, the messages would be in dmesg.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Mon, Nov 22, 2010 at 21:24:41 -0500, Kyle McMartin k...@mcmartin.ca wrote: On Mon, Nov 22, 2010 at 08:00:55PM -0600, Bruno Wolff III wrote: https://koji.fedoraproject.org/koji/taskinfo?taskID=2614153 I've been running that kernel for a couple of days on one machine with floppies. (I am go to switch to -62 tonight.) Two other machines I have with floppies are running rawhide. One is essentially the same as the one I with get the info from shortly. The other is significantly different. Unlikely, given I only built it on Sunday night... It's a scratch build with a patch included. (Yes, the messages would be in dmesg.) I saw a -61 and assumed it was the same build. I was going to double check. Things are taking me longer to do here as I am having some annoying video problems with rawhide. It takes a long time to switch work spaces and some times raising windows is also takes a long time. Anyway, I'll try it out on one machine in a little bit. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Mon, Nov 22, 2010 at 21:24:41 -0500, Kyle McMartin k...@mcmartin.ca wrote: (Yes, the messages would be in dmesg.) [2.691809] acpi_fde: failed to evaluate _FDE [2.692151] Floppy drive(s): fd0 is 1.44M [2.724514] floppy: loaded /dev/fd0 was created. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Mon, Nov 22, 2010 at 21:16:40 -0600, Bruno Wolff III br...@wolff.to wrote: On Mon, Nov 22, 2010 at 21:24:41 -0500, Kyle McMartin k...@mcmartin.ca wrote: (Yes, the messages would be in dmesg.) [2.691809] acpi_fde: failed to evaluate _FDE [2.692151] Floppy drive(s): fd0 is 1.44M [2.724514] floppy: loaded /dev/fd0 was created. I switched to the -62 kernel and /dev/fd0 was NOT created. (I wanted to make sure I hadn't put something on that machine to make the floppy available at boot.) So the patch looks good from the perspective of people who have floppies. I think I can test it on a machine that doesn't have a floppy drive tomorrow. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Mon, Nov 22, 2010 at 09:32:09PM -0600, Bruno Wolff III wrote: [2.691809] acpi_fde: failed to evaluate _FDE [2.692151] Floppy drive(s): fd0 is 1.44M [2.724514] floppy: loaded /dev/fd0 was created. Yeah, it falls back to the ordinary probing if anything fails. Can you send me (privately if you want, or fpaste) the dmesg of the machine? --Kyle I switched to the -62 kernel and /dev/fd0 was NOT created. (I wanted to make sure I hadn't put something on that machine to make the floppy available at boot.) So the patch looks good from the perspective of people who have floppies. I think I can test it on a machine that doesn't have a floppy drive tomorrow. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The new Update Acceptance Criteria are broken
Mike Fedyk píše v Po 22. 11. 2010 v 18:03 -0800: Also security updates should not have any other changes mixed in. In the early days of Fedora, it was explicitly decided that (contra Debian) maintainers are not required to backport patches and that rebases (fixing a bug by updating to a new upstream release) are the most expected kind of update. It seems the consensus on this decision is not as strong as it used to be, nevertheless - with the number of package maintainers that admit they can't fix bugs in their packages on their own, is overturning this policy even possible? Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for a good Radix tree (Patricia) library in fedora
On 11/16/10 9:02 PM, Kevin Kofler wrote: Philip Prindeville wrote: Not sure if the threading support is needed or not... plus it might mean that it package only works on Linux (and not Win32, which Perl requires be supported). From the site: threads and synchronization: cprops provides a pthread-like api. On unix platforms these calls are mapped directly to pthread functions. On windows the win32 api is used to emulate pthread-like behavior. Kevin Kofler Problem is that the trie support in libcprops is string (dictionary) oriented and doesn't handle arbitrary bitstrings. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The new Update Acceptance Criteria are broken
On 11/23/2010 05:51 AM, Miloslav Trmač wrote: Mike Fedyk píše v Po 22. 11. 2010 v 18:03 -0800: Also security updates should not have any other changes mixed in. In the early days of Fedora, it was explicitly decided that (contra Debian) maintainers are not required to backport patches and that rebases (fixing a bug by updating to a new upstream release) are the most expected kind of update. It seems the consensus on this decision is not as strong as it used to be, nevertheless - with the number of package maintainers that admit they can't fix bugs in their packages on their own, is overturning this policy even possible? I am not sure if I understand you correctly. IMO, the real problem is not backports vs. upgrading to fix bugs, it's bugs not getting fixed in Fedora, for a variety of reasons. Therefore, I consider trying to apply any such simple policy to be impossible and naive. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
