Re: Feature proposal: Extended Life Cycle Support
- John5342 john5...@googlemail.com wrote: Firstly, not all people turn the automatic upgrade on. Secondly, there are folks use rpm -hiv or build from srpm. In that case, they are more likely to spot the bugs. I am not talking about upgrades. I am talking about updates. Most people just run updates when packagekit (or similar) tells them to. In a proper release updates are released together. In Denture they will be updated out of order and from various different releases. As for people rebuilding from srpms etc they represent a minority and it is in any case irrelevant. What you said is true, but since what Denture is for unsupported released, which is unlikely getting any updated. Your case is not suitable for unsupported release. If what you said is completely true, I would not even bother to propose Denture. :-) What i said is plain and simple fact. The scenario i mentioned is one of several points of failure. I am not suggesting it is a problem with Denture itself but it is a problem with the real world. Thats just life. But the fact does not cover all packages, so that's why I need Denture, and take the risk. That's also life. :-) This isn't about whether Y-1.3 will be pulled in. If you do what the vast majority of users do then you will get the equivelant of yum update. Regardless of whether X-1.3 explicitly specifies Y-1.3. Y-1.3 will still be updated siply because there is a later version. When you update using Denture however you could easily end up with X-1.3 and Y-1.2 for any number of reasons. Yes I could hit the bump, so are the guys that using source build and other distribution which have not yet put Y-1.3 to their repos. So do other package managers. Tell me, why are you so sure that the current version packages don't break the system secretly and user and the package managers has no way of knowing until it is too late? If you read all i wrote then you will find that has been answered thoroughly already. I also states my justification why the packages should specify the exact depended versions. You have found the exceptions there. Try looking at some others. I see. What I mainly need Denture help is for end-user applications. I am not quite sure about using Denture for library or toolkit directly. I am sure even your dependency versions become stale. Taking your example of dvdauthor BuildRequires: libpng-devel BuildRequires: flex BuildRequires: bison BuildRequires: fribidi-devel BuildRequires: freetype-devel BuildRequires: GraphicsMagick-devel BuildRequires: autoconf automake gettext-devel In a single release you perhaps can be pretty sure that the versions in the build root are good enough to satisfy dvdauthor. If on the other hand you end up with a version of one of these packages from a previous release due to blacklisting then things may well start to break. Would you however insist that all of these are bugs? Mmm, BuildRequires: libdvdread-devel = 0.9.4-4 BuildRequires: libxml2-devel = 2.6.0 Without these, dvdauthor might break even within current release. You were saying that version is not important? :-) Nevertheless, you raise a valid point that version information is sometime unavailable or unreliable. But this can be overcome by a datafile that stores correct version. The result could be great but i can be pretty sure that the actually stability of a partially updated system is probably much worse than rawhide and people who are happy with that level of stability would ore than likely just prefer actual recent release For people who requires absolute stable, they can just use CentOS/ RHEL and totally ignore Denture. Denture is for the people that need to keep some critical packages, but wouldn't mind to take some risk. :-) I like the idea because the concept is great. The idea that you can run whatever version of whatever package you want and get the best of all worlds is a nice dream but unfortunately i also know that it is only a dream and in real life it simply can't work because the huge requirements that Denture would place on packaging just can't be done. Whatever is possibly the problem. Denture only eats what it can eat. :-) According to my experience, some of the dreams can come true. When i was working on my project i quickly realised that for the reasons i have been trying to explain (falling on deaf ears apparently). Please don't assume that I am not aware your concerns. Did you see my answers about them? I really wish you all the best. I really do. I would love to be surprised and see it work but i won't be holding my breath. Good luck! Thanks! -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
- John5342 john5...@googlemail.com wrote: 2009/7/8 Ding Yi Chen dc...@redhat.com: I don't think this has anything to do with motivation. You have an idea and on the face of it it sounds great but even the greatest ideas can be doomed by the details. If you don't believe me (or Kevin) then go for it and when you get to the details you will see exactly what we are talking about. We are simply trying to save you the time. You have good deed. But it does not help by simply saying everything break. As I do have some example to break your claim. :-) I would like to know, specifically, what packages did you tried and optionally, why did they fail? And if you develop ad-hoc logic (which i had too) which is required for it to come even close to working then who is going to maintain the data that drives this ad-hoc logic? If you think the users will then you are likely wrong because the same people who are capable of helping with this will find it less effort just to use the latest release and build some compatibility packages for the older stuff. If nobody is willing to provide sufficient data for the ad-hoc logic, then those packages should be black-listed. First of all that largely wouldnt be possible for your proposal. You also cant account for differences between releases (different releases can have the same version but entirely different features and dependencies). I actually encountered the dependency issue you stated. but I've solved that before, and I don't think it is impossible to convert my steps to code. Also minimum versions probably aren't enough. You would also need maximum versions to make your proposal work. I've consider that (thus the data file that keep the correct dependency), but thanks anyway. You may asked how this data file be generated. Well, at infant stage, it needs to be filled by the early adopters who crush into bugs. You are free to join the data file building. Don't use Denture if you are uncomfortable with that. You clearly don't know how many ways a package can fail. There are a lot of subtle advantages provided by the flow of updates during a release but Denture will be completely and utterly outside those comfortable walls. Package fails in old releases and current releases. But it's not end of world. Either file bug reports, fix it yourself, find alternative ones that do the same thing, or live with it. Given it's experimental nature, don't use Denture on the packages that is critical to your life, job or other thing you value much. Use Denture on the packages that, It's good to have, but can live without it. Perhaps that's why I haven't yet got bitten by extra bugs. If you really want a run down of some of the issues you will run into i can provide although i don't think the list is the place for them. Please mail me the issues that you encountered. Appreciated. I can also tell you the far simpler and more effective solution i came up with for your use case. It is also a frankly much more efficient use of the time. Instead create a program to generate side by side installable packages. Then you can use the latest release with all its features but your old programs that works better on an older Fedora has all the libs it needs to run. The whole concept is more efficient, easier to test, less likely to break systems, less dependent on the user, the type of user in your use case could deal with it more easily, etc and it also covers most of your use cases on your blog. I am interested in what you said, what do you mean side by side? -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
poll(), gdb, threads, alsa-lib, deadlock
I'd like another pair of eyes as what I see in a backtrace looks strange. The full backtrace is attached, two excerpts inline below. With Fedora 11 (and never before) I see deadlocks in Audacious occasionally. It's not too easy to reproduce, but starting something resource-hungry while playing ogg/mp3 makes the player hang up occasionally. Two threads enter poll(). One is the Gtk main-loop, the other one the ALSA plugin play-loop that uses alsa-lib. But why does thread #1 (the Gtk main-loop) switch to the same fds array address 0x319ff4 as thread #2? Originally, g_poll() was called with a different pointer 0x8a5fdd8. Why does the fds address change between g_poll() and poll() while the nfds and timeout args stay unchanged? What am I missing here? [Secondly, alsa-lib's snd_pcm_wait calls poll() with an infinite timeout, which looks dangerous. Obviously, one should only do that if there are certain guarantees, but apparently those aren't satisfied here.] Thread 2 (Thread 0xb35ffb70 (LWP 9678)): #0 0x00cd6416 in __kernel_vsyscall () #1 0x00280276 in *__GI___poll (fds=0x319ff4, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:87 #2 0x063b1215 in snd1_pcm_wait_nocheck (pcm=0xb362c9a0, timeout=-1) at pcm.c:2367 #3 0x063b1403 in snd_pcm_wait (pcm=0xfdfc, timeout=-1) at pcm.c:2338 #4 0x063b1592 in snd1_pcm_write_areas (pcm=0xb362c9a0, areas=0xb35fe9e0, offset=0, size=512, func=0x63bd6f0 snd_pcm_mmap_write_areas) at pcm.c:6646 Thread 1 (Thread 0xb7f3c930 (LWP 9671)): #0 0x00cd6416 in __kernel_vsyscall () #1 0x00280276 in *__GI___poll (fds=0x319ff4, nfds=3, timeout=9) at ../sysdeps/unix/sysv/linux/poll.c:87 #2 0x0070543b in IA__g_poll (fds=0x8a5fdd8, nfds=3, timeout=9) at gpoll.c:127 #3 0x006f81ab in g_main_context_poll (n_fds=value optimized out, fds=value optimized out, priority=value optimized out, timeout=value optimized out, context=value optimized out) at gmain.c:2768 (gdb) thread apply all bt Thread 7 (Thread 0xb7c26b70 (LWP 9672)): #0 0x00cd6416 in __kernel_vsyscall () #1 0x00d5b0d0 in do_sigwait (sig=value optimized out, set=value optimized out) at ../sysdeps/unix/sysv/linux/sigwait.c:63 #2 __sigwait (sig=value optimized out, set=value optimized out) at ../sysdeps/unix/sysv/linux/sigwait.c:100 #3 0x080655fc in gdk_window_show () at gdkwindow.c:3530 #4 0x0071f1bf in g_thread_create_proxy (data=0x8582d60) at gthread.c:635 #5 0x00d52935 in start_thread (arg=0xb7c26b70) at pthread_create.c:297 #6 0x0028a82e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 Thread 6 (Thread 0xb6858b70 (LWP 9673)): #0 0x00cd6416 in __kernel_vsyscall () #1 0x00d56fa5 in pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i486/pthread_cond_wait.S:122 #2 0x064945df in ?? () from /usr/lib/libjack.so.0 #3 0x00d52935 in start_thread (arg=0xb6858b70) at pthread_create.c:297 #4 0x0028a82e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 Thread 5 (Thread 0xb5da1b70 (LWP 9675)): #0 0x00cd6416 in __kernel_vsyscall () #1 0x00d56fa5 in pthread_cond_wait@@GLIBC_2.3.2 () ---Type return to continue, or q return to quit--- at ../nptl/sysdeps/unix/sysv/linux/i386/i486/pthread_cond_wait.S:122 #2 0x0034f434 in watchdog_func (data=0x0) at cuesheet.c:537 #3 0x0071f1bf in g_thread_create_proxy (data=0x86197e0) at gthread.c:635 #4 0x00d52935 in start_thread (arg=0xb5da1b70) at pthread_create.c:297 #5 0x0028a82e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 Thread 4 (Thread 0xb4f78b70 (LWP 9676)): #0 0x00cd6416 in __kernel_vsyscall () #1 0x00d56fa5 in pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i486/pthread_cond_wait.S:122 #2 0x0805e9a7 in gdk_window_show () at gdkwindow.c:3530 #3 0x0071f1bf in g_thread_create_proxy (data=0x85ab880) at gthread.c:635 #4 0x00d52935 in start_thread (arg=0xb4f78b70) at pthread_create.c:297 #5 0x0028a82e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 Thread 3 (Thread 0xb4198b70 (LWP 9677)): #0 0x00cd6416 in __kernel_vsyscall () #1 0x00d572d2 in pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i486/pthread_cond_timedwait.S:179 #2 0x00357f1e in g_cond_timed_wait_posix_impl (cond=0xfdfc, entered_mutex=0x1038d, abs_time=0xb41901e4) at gthread-posix.c:242 #3 0x0805b054 in gdk_window_show () at gdkwindow.c:3530 #4 0x00ec0aff in vorbis_play_loop (arg=value optimized out) at vorbis.c:400 ---Type return to continue, or q return to quit--- #5 0x0805c6ae in gdk_window_show () at gdkwindow.c:3530 #6 0x0071f1bf in g_thread_create_proxy (data=0x88aa018) at gthread.c:635 #7 0x00d52935 in start_thread (arg=0xb4198b70) at pthread_create.c:297 #8 0x0028a82e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 Thread 2 (Thread 0xb35ffb70 (LWP 9678)): #0 0x00cd6416 in __kernel_vsyscall () #1 0x00280276 in *__GI___poll (fds=0x319ff4, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:87
Re: an update to automake-1.11?
Sam Varshavchik wrote: Indeed. Here's an idea -- why don't you mass mail the maintainers of all the autotools-using projects you can find on Sourceforge, and be sure to tell them how much autotools suck, and how better CMake is. I'm sure they will appreciate your helpful suggestions. Hahaha… Do you have any SERIOUS suggestion on how to bring the deficiencies of the autotools to the attention of upstream maintainers? Of course spamming them won't cut it. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Sam Varshavchik wrote: Wrong, as usual. That's an ad hominem argument. Since each autoconf macro typically expands out to hundreds lines of shellcode, But those hundreds of lines of shellcode *CHANGE* with the autoconf and/or aclocal version! Even if upstream changes *nothing* in configure.ac, those lines *will* change whenever they use a different version of the autotools. For most upstreams, that will happen much more often than some actual change in configure.ac in the immediate context of what you're patching. with the autoconf macro's parameter embedded somewhere in the middle of all that stuff, were you to change a parameter to an autoconf macro in configure.ac, and upstream changes the parameter in the next line, your patch gets broken. Upstream is much less likely to change that parameter in the next line than to use a different version of autoconf. Chances are those context lines won't be touched for YEARS! It's just basic Statistics. Yes, tell me again how conflicting patches to neighboring lines in configure.ac works, while the equivalent two patches hundreds of lines apart in configure do not. You don't understand me, I'm telling you how patches to configure.ac in an area upstream is unlikely to touch any time soon work, while the equivalent patches in configure get fuzzed by unrelated changes introduced by a new autoconf used by upstream and break. Stuff like AC_PATH_PROG produces several dozens lines of canned shellcode, with the arguments to AC_PATH_PROG appearing once, in the middle of them. But those several dozens lines of canned shellcode CHANGE WITH THE AUTOCONF VERSION! Changing the parameter to AC_PATH_PROG, for example, does not change hundreds of lines of shellcode. No, but using the next point release of autoconf, even with no changes to configure.ac at all, does. Most programmers use fast-moving distros. Distros like Fedora, Debian testing/unstable, Gentoo (even masked packages sometimes) etc. There are even upstream developers using Rawhide! So the version of autoconf upstream is using will change extremely often. Much more often than a 5-line window in configure.ac. Your flawed assumption is that all upstreams are as conservative with autotools upgrades as you are. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Sam Varshavchik wrote: That's definitely a useful tip -- always ignore warnings. They are always completely meaningless. You don't need to worry about them. Quit the sarcasm. The thing is: this is how things work in the real world, whether it's a good idea or not. The autotools spit out tons of incomprehensible warnings (e.g. `foo' should be called before `bar', but both foo and bar are called by some canned snippets, not by your own code) for things which previous versions accepted just fine, it's no surprise that maintainers aren't motivated to fix them. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
Ding Yi Chen wrote: If X-1.3 does not specify Y-1.3 as dependency, I don't think yum update X will pull Y-1.3, even with the current version. Selective updates are not really tested in practice and tend not to work. You're expected to get ALL stable updates, not just one. The old RHL advisories made this clear: | Before applying this update, make sure all previously released errata | relevant to your system have been applied. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
Ding Yi Chen wrote: Tell Denture your constraint and it will build packages if it can; or reasons why it cannot build. The word build there is another big fail. Users DO NOT WANT to build their packages from source. If they did, they'd all be using Gentoo! Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ck-list-sessions shows active = false
On Mon, 06.07.09 09:54, darrell pfeifer (darrel...@gmail.com) wrote: Using rawhide and gdm-2.26.1-13.fc12.i586 when I do a ck-list-sessions I see Session4: unix-user = '500' realname = 'darrell pfeifer' seat = 'Seat5' session-type = '' active = FALSE x11-display = ':0' x11-display-device = '' display-device = '' remote-host-name = '' is-local = TRUE on-since = '2009-07-06T15:56:08.908744Z' login-session-id = '' Currently almost all my device-related functionality is not working (including pulseaudio, mounting usb sticks, starting virtual machines). In addition, polkit-gnome-authorization and polkit-gnome-authorization are crashing. Am I on the right track thinking that the problem is gdm related? We are currently in the process of moving the device ACL management from HAL to udev. This is not finished yet, at least for the PA case I know that that there is some work left to do to fix udev/ck to make things completely race-free. A temporary work-around for the PA case is to make yourself a member of the audio group which then gives you device access regardless if ACLs are set up and work correctly. This will break audio if you have multiple simultaneous session of different users. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
Ding Yi Chen wrote: - John5342 john5...@googlemail.com wrote: I am not talking about upgrades. I am talking about updates. Most people just run updates when packagekit (or similar) tells them to. In a proper release updates are released together. In Denture they will be updated out of order and from various different releases. As for people rebuilding from srpms etc they represent a minority and it is in any case irrelevant. What you said is true, but since what Denture is for unsupported released, which is unlikely getting any updated. Your case is not suitable for unsupported release. He was just explaining why packages tend not to have versioned dependencies in practice, and still work fine in supported Fedora releases. And you can't expect them to be fixed to support unsupported releases, those are unsupported for a reason. Yes I could hit the bump, so are the guys that using source build and other distribution which have not yet put Y-1.3 to their repos. Specfiles are per definition distribution-specific. But this can be overcome by a datafile that stores correct version. Good luck maintaining that monster file! Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: poll(), gdb, threads, alsa-lib, deadlock
On Wednesday, 08 July 2009 at 11:00, Michael Schwendt wrote: I'd like another pair of eyes as what I see in a backtrace looks strange. The full backtrace is attached, two excerpts inline below. With Fedora 11 (and never before) I see deadlocks in Audacious occasionally. It's not too easy to reproduce, but starting something resource-hungry while playing ogg/mp3 makes the player hang up occasionally. Actually, I see that on Fedora 10, too. Pressing pause and then play makes it return to normal again, for some time. Not sure if it's the same issue, because only the playback thread seems to hang (as if pause was pressed). Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu Faith manages. -- Delenn to Lennier in Babylon 5:Confessions and Lamentations -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
On Tue, Jul 07, 2009 at 06:05:47PM -0400, Sam Varshavchik wrote: If someone thinks that by patching configure.ac, instead of configure, one achieves tremendous savings in the frequency of needing to rebase one's patches, they're in a desperate need for a reality check. No, you are. Please find out how patch works. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Kevin Kofler writes: Sam Varshavchik wrote: Indeed. Here's an idea -- why don't you mass mail the maintainers of all the autotools-using projects you can find on Sourceforge, and be sure to tell them how much autotools suck, and how better CMake is. I'm sure they will appreciate your helpful suggestions. Hahaha… Do you have any SERIOUS suggestion on how to bring the deficiencies of the autotools to the attention of upstream maintainers? Of course spamming them won't cut it. What's wrong with what I suggested? If you truly believe that cmake is so much better, I'm sure that everyone would be glad to hear it. Go ahead, state your case. I'm the upstream for two packages in Fedora. Make your case. You can start with me. pgpiFHLTRq2JY.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: poll(), gdb, threads, alsa-lib, deadlock
On Wed, 8 Jul 2009 12:28:55 +0200, Dominik wrote: On Wednesday, 08 July 2009 at 11:00, Michael Schwendt wrote: I'd like another pair of eyes as what I see in a backtrace looks strange. The full backtrace is attached, two excerpts inline below. With Fedora 11 (and never before) I see deadlocks in Audacious occasionally. It's not too easy to reproduce, but starting something resource-hungry while playing ogg/mp3 makes the player hang up occasionally. Actually, I see that on Fedora 10, too. Do you remember when you ran into it for the first time? alsa-lib was upgraded for F10 at beginning of May, for example. [Perhaps I need to diff in that area.] On F11 I can downgrade audacious* to the packages before the first set of alsa patches, and the problem is reproducible. The upstream updates 2.0 and 2.1beta1 are not safe, since they contain new problems (and not the latest alsa plugin and even one or a few race conditions). Pressing pause and then play makes it return to normal again, for some time. Not sure if it's the same issue, because only the playback thread seems to hang (as if pause was pressed). Very likely it's related -- and yes, in one or two cases I could click stop, too, to end the deadlock. Multiple threads are used and communicate with eachother via glib2 conditions (GCond) and proper mutex locking. Wherever infinite timeouts are used when waiting for conditions and a key thread doesn't return from a syscall, other threads might wait endlessly, too. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Kevin Kofler writes: Sam Varshavchik wrote: Wrong, as usual. That's an ad hominem argument. Since each autoconf macro typically expands out to hundreds lines of shellcode, But those hundreds of lines of shellcode *CHANGE* with the autoconf and/or aclocal version! You're changing the topic. On this point, we're not talking about what happens when autoconf changes. Here, the original statement was that patches to configure.ac are less likely to be kicked out than configure, if configure.ac changes. I pointed out that this is completely absurd, and you have no idea how autoconf works. You have no answer, so you must now start talking about what happens when autoconf itself changes. with the autoconf macro's parameter embedded somewhere in the middle of all that stuff, were you to change a parameter to an autoconf macro in configure.ac, and upstream changes the parameter in the next line, your patch gets broken. Upstream is much less likely to change that parameter in the next line than to use a different version of autoconf. Do you have any data to back up this interesting notion -- that most changes to configure are due to autoconf version changes, rather than upstream making changes to configure.ac itself? I thought not. Yes, tell me again how conflicting patches to neighboring lines in configure.ac works, while the equivalent two patches hundreds of lines apart in configure do not. You don't understand me, I'm telling you how patches to configure.ac in an area upstream is unlikely to touch any time soon work, while the equivalent patches in configure get fuzzed by unrelated changes introduced by a new autoconf used by upstream and break. This is absurd. configure.ac changes due to natural evolution of the package far more often than autoconf itself changing. In fact, many actually loathe switching to a different version of autoconf, preferring to stay on the same version as long as possible. Stuff like AC_PATH_PROG produces several dozens lines of canned shellcode, with the arguments to AC_PATH_PROG appearing once, in the middle of them. But those several dozens lines of canned shellcode CHANGE WITH THE AUTOCONF VERSION! Which happens far less often than routine changes to configure.ac, as the package natural evolves over time. autoconf changes happens maybe once every other year or so. Most configure script change far more often than once every other year. This is a bogus argument. Changing the parameter to AC_PATH_PROG, for example, does not change hundreds of lines of shellcode. No, but using the next point release of autoconf, even with no changes to configure.ac at all, does. Most programmers use fast-moving distros. Distros like Fedora, Debian It would be trivial to pick a typical package, and look at intervening releases, years apart, and observe the major differences in configure.ac, yet, perhaps only one, if none, update to autoconf itself occuring in all the intervening releases. But, once I do that, you'll abandon this reasoning too, once you realize that it's a non-starter, and change the topic to something else. It'll probably be line number changes. pgpLl1IzIrr9G.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Richard W.M. Jones writes: On Tue, Jul 07, 2009 at 06:05:47PM -0400, Sam Varshavchik wrote: If someone thinks that by patching configure.ac, instead of configure, one achieves tremendous savings in the frequency of needing to rebase one's patches, they're in a desperate need for a reality check. No, you are. Please find out how patch works. I do. Which is why you cannot hold your end of the debate. pgpK2RTQZZHlX.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: poll(), gdb, threads, alsa-lib, deadlock
On Wed, 8 Jul 2009 13:16:56 +0200, me wrote: Actually, I see that on Fedora 10, too. Do you remember when you ran into it for the first time? alsa-lib was upgraded for F10 at beginning of May, for example. [Perhaps I need to diff in that area.] Hmmm, the alsa-lib diff between 1.0.19 and 1.0.20 is 36K short and actually touches the poll() stuff in snd_pcm_wait_nocheck(). -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: poll(), gdb, threads, alsa-lib, deadlock
On Wednesday, 08 July 2009 at 13:16, Michael Schwendt wrote: On Wed, 8 Jul 2009 12:28:55 +0200, Dominik wrote: On Wednesday, 08 July 2009 at 11:00, Michael Schwendt wrote: I'd like another pair of eyes as what I see in a backtrace looks strange. The full backtrace is attached, two excerpts inline below. With Fedora 11 (and never before) I see deadlocks in Audacious occasionally. It's not too easy to reproduce, but starting something resource-hungry while playing ogg/mp3 makes the player hang up occasionally. Actually, I see that on Fedora 10, too. Do you remember when you ran into it for the first time? alsa-lib was upgraded for F10 at beginning of May, for example. [Perhaps I need to diff in that area.] AFAIR I got the problem right from the beginning of using F10, but I installed it about a month or two after it came out and updated immediately after installation. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu Faith manages. -- Delenn to Lennier in Babylon 5:Confessions and Lamentations -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: No sound in rawhide
on., 17.06.2009 kl. 11.44 -0700, skrev Ray Van Dolson: On Wed, Jun 17, 2009 at 08:06:36AM -0800, Jeff Spaleta wrote: On Wed, Jun 17, 2009 at 7:25 AM, Ray Van Dolsonra...@bludgeon.org wrote: Hmm, I just always figured I was supposed to add myself to the audio group. So these files are supposed to be owned by my local user account when I log in eh? No... you should be added to the acl list associated to the device if you are the physical console user as per the authorization policy managed by PolicyKit. This it how it works from at least F10 onward. Mucking around with file ownership directly is old think. The system scripts associated with pam use to do that on user login and logout...but has been replaced with the more flexible solution involving acls that PolicyKit based hardware access authorization makes use of. for example on the F10 system I'm on right now: ls -la /dev/snd/seq crw-rw+ 1 root root 116, 3 2009-06-17 07:07 /dev/snd/seq getfacl /dev/dsp # file: dev/snd/seq # owner: root # group: root user::rw- user:myuser:rw- group::rw- mask::rw- other::--- I do not own the file in the traditional Unix permissions sense. But I am listed in the acl list with read write access. If your user is not in the acl list, something misfired in the area of the PolicyKit based authorization handling. Good to know. I've checked the acl list in the past and definitely wasn't a member. I'll have to remove myself from audio and see if I can track this down. Did you find anything? I'm still seeing this problem with rawhide as of today. Cheers Kjartan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: delaying an update
Christoph Höger on 07/08/2009 09:21 AM wrote: how do I do that? Since you have not submitted it for stable I do not see any problem. Don't do anything. :) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: noarch subpackages
On Wednesday 08 July 2009 08:59:43 am Rick L. Vinyard, Jr. wrote: What is the effect on non-Fedora and older distributions (pre F10) if I mark a subpackage (such as documentation) with BuildArch: noarch? the package will attempt to build as noarch only. you cant to it for F-9 and since F-9 is EOL in two days dont. for EL-4 and EL-5 you could probably if the BuildArch out Dennis signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: delaying an update
On Wednesday 08 July 2009 16:30:56 Michael Cronenworth wrote: Christoph Höger on 07/08/2009 09:21 AM wrote: how do I do that? I guess you can use Delete/Unpush/Revoke request or something like that in bodhi web interface. Since you have not submitted it for stable I do not see any problem. Don't do anything. :) I disagree. There are several users using packages from updates-testing. Letting them update to a package you know is broken is bad. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: delaying an update
On Wed, 2009-07-08 at 09:30 -0500, Michael Cronenworth wrote: Christoph Höger on 07/08/2009 09:21 AM wrote: how do I do that? Since you have not submitted it for stable I do not see any problem. Don't do anything. :) You might want to disable the automatic push to stable, though, in case the package gets too much karma.. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: noarch subpackages
On Wed, 8 Jul 2009 07:59:43 -0600, Jr. wrote:
What is the effect on non-Fedora and older distributions (pre F10) if I
mark a subpackage (such as documentation) with BuildArch: noarch?
You can evaluate the %fedora variable to use this new feature only
for Fedora = 10:
%if 0%{?fedora} 9
BuildArch: noarch
%endif
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: noarch subpackages
Michael Schwendt wrote:
On Wed, 8 Jul 2009 07:59:43 -0600, Jr. wrote:
What is the effect on non-Fedora and older distributions (pre F10) if I
mark a subpackage (such as documentation) with BuildArch: noarch?
You can evaluate the %fedora variable to use this new feature only
for Fedora = 10:
%if 0%{?fedora} 9
BuildArch: noarch
%endif
Excellent. That's what I was looking for.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: No sound in rawhide
also renamed file /etc/pulse/default.pa.rpmnew to /etc/pulse/default.pa On Wed, Jul 8, 2009 at 8:22 AM, Sachin asci...@gmail.com wrote: i added myself to the pulse-access and audio group .. On Wed, Jul 8, 2009 at 7:43 AM, Kjartan Maraas kmar...@broadpark.nowrote: on., 17.06.2009 kl. 11.44 -0700, skrev Ray Van Dolson: On Wed, Jun 17, 2009 at 08:06:36AM -0800, Jeff Spaleta wrote: On Wed, Jun 17, 2009 at 7:25 AM, Ray Van Dolsonra...@bludgeon.org wrote: Hmm, I just always figured I was supposed to add myself to the audio group. So these files are supposed to be owned by my local user account when I log in eh? No... you should be added to the acl list associated to the device if you are the physical console user as per the authorization policy managed by PolicyKit. This it how it works from at least F10 onward. Mucking around with file ownership directly is old think. The system scripts associated with pam use to do that on user login and logout...but has been replaced with the more flexible solution involving acls that PolicyKit based hardware access authorization makes use of. for example on the F10 system I'm on right now: ls -la /dev/snd/seq crw-rw+ 1 root root 116, 3 2009-06-17 07:07 /dev/snd/seq getfacl /dev/dsp # file: dev/snd/seq # owner: root # group: root user::rw- user:myuser:rw- group::rw- mask::rw- other::--- I do not own the file in the traditional Unix permissions sense. But I am listed in the acl list with read write access. If your user is not in the acl list, something misfired in the area of the PolicyKit based authorization handling. Good to know. I've checked the acl list in the past and definitely wasn't a member. I'll have to remove myself from audio and see if I can track this down. Did you find anything? I'm still seeing this problem with rawhide as of today. Cheers Kjartan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: delaying an update
Am Mittwoch, den 08.07.2009, 17:41 +0300 schrieb Jussi Lehtola: On Wed, 2009-07-08 at 09:30 -0500, Michael Cronenworth wrote: Christoph Höger on 07/08/2009 09:21 AM wrote: how do I do that? Since you have not submitted it for stable I do not see any problem. Don't do anything. :) You might want to disable the automatic push to stable, though, in case the package gets too much karma.. That's what I meant with delay. So how do I do that? signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
inotify and gnome authorization
Over the last few months I've had problems with the gnome authorization dialog failing, sometimes intermittently and sometimes consistently for long periods of time. The dialog I'm referring to is the one that pops up when root access is needed to run an application or control panel. Examples are System/Preferences/Authorizations, running the virtual machine manager, running lots of control panels from System/Administration/* It turns out that eventually polkit-gnome-manager is called. It uses inotify to put a watch on /etc/PolicyKit/PolicyKit.conf. In my case, placing the watch was failing, which meant no authorization. A workaround is to bump up the 8192 limit to something higher echo 16384 /proc/sys/fs/inotify/max_user_watches I'm still a bit mystified as to what is using all the watches. Before and after the echo lsof only reports less than 32 watches on my system. Other than lsof there don't appear to be an tools to show who is consuming the watches. If nobody has an suggestions, I may try systemtap. I'm not sure at this point that it makes sense to bump up the kernel default without knowing the current culprit. The bottom line: with policykit being used more heavily in rawhide, if you're getting strange intermittent permissions failures, try the workaround. darrell -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: inotify and gnome authorization
On Wed, 2009-07-08 at 08:30 -0700, darrell pfeifer wrote: The bottom line: with policykit being used more heavily in rawhide, if you're getting strange intermittent permissions failures, try the workaround. When you run out of inotify watches, many things will fail, not just PolicyKit. Likely culprits for eating the watches would be indexers like beagle or tracker. I used to have a systemtap script for monitoring inotify watch consumption, but I seem to have lost it... Matthias -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: noarch subpackages
Rick L. Vinyard, Jr. wrote:
Michael Schwendt wrote:
On Wed, 8 Jul 2009 07:59:43 -0600, Jr. wrote:
What is the effect on non-Fedora and older distributions (pre F10) if I
mark a subpackage (such as documentation) with BuildArch: noarch?
You can evaluate the %fedora variable to use this new feature only
for Fedora = 10:
%if 0%{?fedora} 9
BuildArch: noarch
%endif
Excellent. That's what I was looking for.
Except it should be:
%if 0%{?fedora} 9 || 0%{?rhel} 5
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Anybody know how to contact Axel Thimm (again)?
On 2009-07-08 12:30:30 PM, Jon Ciesla wrote: Is he not responding at axel.th...@atrpms.net? That's his bugzilla email addess, so that seems to be the case :-( Thanks, Ricky pgpYpzXyQeI8L.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Anybody know how to contact Axel Thimm (again)?
Ricky Zhou wrote: On 2009-07-08 12:30:30 PM, Jon Ciesla wrote: Is he not responding at axel.th...@atrpms.net? That's his bugzilla email addess, so that seems to be the case :-( Thanks, Ricky What about i...@fedoraproject.org? -- in your fear, speak only peace in your fear, seek only love -d. bowie -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
On Wed, Jul 08, 2009 at 07:17:38PM +0200, Kevin Kofler wrote: But, once I do that, you'll abandon this reasoning too, once you realize that it's a non-starter, and change the topic to something else. It'll probably be line number changes. Nonsense. I'm not being intentionally dishonest, please stop those unwarranted accusations! I think you both need to stop this ridiculous conversation. While I'm sure the merits of patching configure or configure.ac can and will be debated forever, you are not doing anything other than wasting each other's time. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Anybody know how to contact Axel Thimm (again)?
Sven Lankes wrote: On Wed, Jul 08, 2009 at 12:41:56PM -0500, Jon Ciesla wrote: Is he not responding at axel.th...@atrpms.net? That's his bugzilla email addess, so that seems to be the case :-( What about i...@fedoraproject.org? That is Andreas Thienemann - same initials, different person. facepalm Maybe I should try to sleep more than 1.5 hours tonight. :) -- in your fear, speak only peace in your fear, seek only love -d. bowie -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Anybody know how to contact Axel Thimm (again)?
Jon Ciesla (l...@jcomserv.net) said: Is he not responding at axel.th...@atrpms.net? That's his bugzilla email addess, so that seems to be the case :-( What about i...@fedoraproject.org? i...@fp.o is not Axel. ath...@fp.o just goes to the ATrpms.net e-mail address. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Anybody know how to contact Axel Thimm (again)?
there are alot of bug report's and patch's waiting for Axel.Thimm On Wed, Jul 8, 2009 at 2:51 PM, Bill Nottinghamnott...@redhat.com wrote: Jon Ciesla (l...@jcomserv.net) said: Is he not responding at axel.th...@atrpms.net? That's his bugzilla email addess, so that seems to be the case :-( What about i...@fedoraproject.org? i...@fp.o is not Axel. ath...@fp.o just goes to the ATrpms.net e-mail address. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Itamar Reis Peixoto e-mail/msn: ita...@ispbrasil.com.br sip: ita...@ispbrasil.com.br skype: itamarjp icq: 81053601 +55 11 4063 5033 +55 34 3221 8599 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Anybody know how to contact Axel Thimm (again)?
On 08/07/09 18:51, Bill Nottingham wrote: Jon Ciesla (l...@jcomserv.net) said: Is he not responding at axel.th...@atrpms.net? That's his bugzilla email addess, so that seems to be the case :-( What about i...@fedoraproject.org? i...@fp.o is not Axel. ath...@fp.o just goes to the ATrpms.net e-mail address. Bill Try a who is, it will give an extra addy. Frank -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
On 07/08/2009 01:44 PM, Josh Boyer wrote: On Wed, Jul 08, 2009 at 07:17:38PM +0200, Kevin Kofler wrote: But, once I do that, you'll abandon this reasoning too, once you realize that it's a non-starter, and change the topic to something else. It'll probably be line number changes. Nonsense. I'm not being intentionally dishonest, please stop those unwarranted accusations! I think you both need to stop this ridiculous conversation. While I'm sure the merits of patching configure or configure.ac can and will be debated forever, you are not doing anything other than wasting each other's time. I agree. Consider this an informal warning that you're both about to cross the line on being excellent to each other. ~spot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Can we import dia 0.97 in rawhide?
It's been released here: http://projects.gnome.org/dia/ -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
art of packaging: fluxbox-pulseaudio
# rpm -ql fluxbox-pulseaudio
/etc/fluxbox-pulseaudio
# ls -la /etc/fluxbox-pulseaudio
-rw-r--r-- 1 root root 0 2008-09-17 19:29 /etc/fluxbox-pulseaudio
# rpm -q --qf %{ARCH}\n fluxbox-pulseaudio
x86_64
... it means the package contains one empty file. Is it really normal
that we configure our system by yum install/remove? Really?
Karel
--
Karel Zak k...@redhat.com
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: art of packaging: fluxbox-pulseaudio
On Wed, 2009-07-08 at 20:44 +0200, Andreas Bierfert wrote: It is not only an empty file. It requires the necessary PA packages and triggers automatic PA loading on session starts. Please see [1] and [2] for some more background information. That subpackage should likely be noarch. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: art of packaging: fluxbox-pulseaudio
On Wed, 08 Jul 2009 11:50:18 -0700 Jesse Keating jkeat...@redhat.com wrote: On Wed, 2009-07-08 at 20:44 +0200, Andreas Bierfert wrote: It is not only an empty file. It requires the necessary PA packages and triggers automatic PA loading on session starts. Please see [1] and [2] for some more background information. That subpackage should likely be noarch. Just been thinking the same. Will be fixed asap. - Andreas -- Andreas Bierfert, M.Sc.| http://awbsworld.de | GPG: C58CF1CB andreas.bierf...@lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 6897 1721738| cell: +49 173 5803043| mail preferred signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: delaying an update
On Wed July 8 2009, Christoph Höger wrote: Am Mittwoch, den 08.07.2009, 17:41 +0300 schrieb Jussi Lehtola: On Wed, 2009-07-08 at 09:30 -0500, Michael Cronenworth wrote: Christoph Höger on 07/08/2009 09:21 AM wrote: how do I do that? Since you have not submitted it for stable I do not see any problem. Don't do anything. :) You might want to disable the automatic push to stable, though, in case the package gets too much karma.. That's what I meant with delay. So how do I do that? You can unselect it here: https://admin.fedoraproject.org/updates/edit/offlineimap-6.1.0-2.fc11 And revoke the push request here: https://admin.fedoraproject.org/updates/revoke/offlineimap-6.1.0-2.fc11 Regards Till signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Display Configuration test day summary
We've had the first 'Fit and Finish' test day on display configuration yesterday. I'd like to thank everybody who came by on irc and tested something, or filed a bug. If you could not make it, our test cases are still available here: https://fedoraproject.org/wiki/Test_Day:2009-07-07_Fit_and_Finish:Display_Configuration That page also contains the results of our yesterdays testing efforts, if you are interested. The good news is that we have already fixed some of the things that were found broken, and more fixes are on the way. Here is just one exemplary fix: * Tue Jul 07 2009 Adam Jackson a...@redhat.com 2.27.3-2 - gnome-desktop-2.27.3-edid-prop-name.patch: Adapt to RANDR 1.3's new name for the EDID output property. I'll post the date an topic for our next 'Fit and Finish' test day in the next few days. Matthias -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: delaying an update
Thanks. Did it. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Kevin Kofler writes: What he was talking about is that rediffing patches, i.e. making patches apply to a new upstream version (that's what rediffing means for us Fedora packagers), is more likely to break for configure.ac than for configure. And that's exactly what I said. Thank you for agreeing with me, that fixing configure is less likely to cause problems in the long run. Which happens far less often than routine changes to configure.ac, as the package natural evolves over time. autoconf changes happens maybe once every other year or so. Most configure script change far more often than once every other year. I don't know what upstreams you worked with. For the projects I worked on with Romain Liévin, he generally ran autoreconf with what was current on Debian unstable or testing that day and me with what was current on Fedora (stable updates) that day. The stuff would even ping-pong between the Debian Well, I don't know what those projects were, but here's a better known example. I just downloaded all available versions of the 2.4 branch of openldap, and greped their configure script. The results are: openldap-2.4.6/configure:# Generated by GNU Autoconf 2.59. openldap-2.4.7/configure:# Generated by GNU Autoconf 2.59. openldap-2.4.8/configure:# Generated by GNU Autoconf 2.59. openldap-2.4.9/configure:# Generated by GNU Autoconf 2.59. openldap-2.4.10/configure:# Generated by GNU Autoconf 2.59. openldap-2.4.11/configure:# Generated by GNU Autoconf 2.59. openldap-2.4.12/configure:# Generated by GNU Autoconf 2.59. openldap-2.4.13/configure:# Generated by GNU Autoconf 2.59. openldap-2.4.14/configure:# Generated by GNU Autoconf 2.61. openldap-2.4.15/configure:# Generated by GNU Autoconf 2.61. openldap-2.4.16/configure:# Generated by GNU Autoconf 2.61. Now, let's grep configure.in: openldap-2.4.6/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.7 2007/10/16 23:43:09 quanah Exp $ openldap-2.4.7/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.7 2007/10/16 23:43:09 quanah Exp $ openldap-2.4.8/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.9 2008/02/11 23:26:37 kurt Exp $ openldap-2.4.9/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.9 2008/02/11 23:26:37 kurt Exp $ openldap-2.4.10/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.9 2008/02/11 23:26:37 kurt Exp $ openldap-2.4.11/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.9 2008/02/11 23:26:37 kurt Exp $ openldap-2.4.12/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.14 2008/09/17 22:54:33 quanah Exp $ openldap-2.4.13/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.17 2008/11/21 01:26:24 quanah Exp $ openldap-2.4.14/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.22 2009/01/26 21:54:23 quanah Exp $ openldap-2.4.15/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.22 2009/01/26 21:54:23 quanah Exp $ openldap-2.4.16/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.22 2009/01/26 21:54:23 quanah Exp $ Over a span of nearly two years, openldap updated their autotools exactly once, while configure.in changed six times (with several additional intervening changes in-between consecutive releases). Which busy project would you like to repeat this experiment with? pgpnwz4eXNkq9.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Can we import dia 0.97 in rawhide?
On Wed, 2009-07-08 at 11:36 -0700, Conrad Meyer wrote: File a bug. Found one already filed here: https://bugzilla.redhat.com/show_bug.cgi?id=502870 -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sam Varshavchik wrote: snip Frankly, all of this would scare me away from the autotools. If all that can happen from patching a small file rather than a monster file... Forcing version x.y of some tool and then shipping the results of using said tool and then slapping the hands of those who try to move forward with a new version seems to me that something is wrong. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpVI30ACgkQiPi+MRHG3qTD8wCdEDKzia6Sig67u5TFuQGnDmSe xDEAoK+oUfvYZAHzuEb+Z4NbBdEcnuzK =Cuty -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Sam Varshavchik wrote: Kevin Kofler writes: What he was talking about is that rediffing patches, i.e. making patches apply to a new upstream version (that's what rediffing means for us Fedora packagers), is more likely to break for configure.ac than for configure. And that's exactly what I said. Thank you for agreeing with me, that fixing configure is less likely to cause problems in the long run. That's just because I made a mispaste. ;-) So let's try again: What he was talking about is that rediffing patches, i.e. making patches apply to a new upstream version (that's what rediffing means for us Fedora packagers), is more likely to break for configure than for configure.ac. (Check the actual citation if you don't believe me.) Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: readline update?
On Fri, 2009-07-03 at 12:27 +0200, Miroslav Lichvar wrote: devtodo-0.1.20-3.fc12 I maintain this package in Fedora. Just wrote the author asking for a clarification on licensing. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Kevin Kofler writes: Sam Varshavchik wrote: Kevin Kofler writes: What he was talking about is that rediffing patches, i.e. making patches apply to a new upstream version (that's what rediffing means for us Fedora packagers), is more likely to break for configure.ac than for configure. And that's exactly what I said. Thank you for agreeing with me, that fixing configure is less likely to cause problems in the long run. That's just because I made a mispaste. ;-) So let's try again: What he was talking about is that rediffing patches, i.e. making patches apply to a new upstream version (that's what rediffing means for us Fedora packagers), is more likely to break for configure than for configure.ac. And I already pointed out why this is not true, several times. Furthermore, one part of your argument is that it is supposedly true because most changes to configure are due to autoconf getting updated, rather than any actual changes to configure.ac. In my last message, rather than speculate I posted logs from a randomly chosen project, openldap, that showed that to be not the case. I don't really have enough spare time to try downloading all releases, over the course of two years, of one project after another, trying to cherry-pick my example. Openldap was the first one that came to mind. I am confident that I am right, on this topic, so it was fairly likely that openldap's tarballs would've proved my point. They did, and you ignored it. I invite you to find a counterexample, but I regret to inform you, finding one won't be easy. Your other argument is that a patch to configure is less likely to require manual rebasing after configure changes, rather than an equivalent one to configure.ac, because new versions of autotools end up generating major changes to configure. Well, I just showed that routine changes to configure.ac occur far more often than updated to autoconf. Furthermore, as I pointed out, changes to nearby lines in configure.ac result in corresponding changes to configure being hundreds of lines apart, therefore a change to configure.ac is going to require rebasing of any patches to nearby lines, while the equivalent change to configure (once again -- for those with a short attention span -- that's a real patch to configure, and not a change to configure.ac, a regenerated configure, and a diff against the original version of configure) will therefore still apply, at most with some fuzz, and can therefore be rebased automatically. Conclusion: given a patch to configure.ac, and a patch to configure, an update to autotools is far likely to require more work to maintain the configure patch, while an update to configure.ac will likely require more woth main the configure.ac. And, this is the most likely outcome given, as I pointed out in openldap's case, which you would like to ignore, happens far more often than autotools update. Case closed. pgpYgOhWTHr3Z.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: http://www.fsf.org/news/dont-depend-on-mono
On 07/07/2009 07:42 PM, Kevin Kofler wrote: RAND does not necessarily mean royalty-free Oh, I agree. The trick is nobody knows what those RAND terms are. Free, not free, something-we-never-dreamed-of, etc. Various folks (e.g. OSNews) have been attempting to get Microsoft to present them with a RAND license offer to clear this up. So, the legal theory is that since ECMA requires RAND license terms, and the spec is a published ECMA spec, and various people have been trying to get a RAND license offer for a while, that if Microsoft drags you before a magistrate charging that you didn't get a license, that licenses were not available and therefore implicitly not required would convince him that the prosecution is malicious and get the case tossed out on its ear. Whether the argument holds any water or not, I have no idea, it's just what I've heard from defenders. -Bill -- Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 http://www.bfccomputing.com/Cell: 603.252.2606 Twitter, etc.: bill_mcgonigle Page: 603.442.1833 Email, IM, VOIP: b...@bfccomputing.com Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
於 三，2009-07-08 於 11:37 +0200，Kevin Kofler 提到： Ding Yi Chen wrote: Tell Denture your constraint and it will build packages if it can; or reasons why it cannot build. The word build there is another big fail. Users DO NOT WANT to build their packages from source. If they did, they'd all be using Gentoo! Users with rpm building knowledge can build. Users came from FreeBSD and Gentoo are familar with build. Even those ex-Windows users, if there is good GUI that only require you to click on Next or Ok, they don't mind to build. *Sign*, well, How about following prompt: Denture will build the package for you, however, in order to do so, it will consume cpu time, disk space, network bandwidth, proceed? OK Cancel -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Sam Varshavchik wrote: In my last message, rather than speculate I posted logs from a randomly chosen project, openldap, that showed that to be not the case. That's one project. It doesn't prove any sort of a general trend. I invite you to find a counterexample, but I regret to inform you, finding one won't be easy. I already mentioned a bunch of counterexamples (all the stuff I worked on with Romain Liévin: tfdocgen, libticables2, libticonv, libtifiles2, libticalcs2, TiLP 2, TiEmu, TiLP GFM, TiEmu SkinEdit etc.). Well, I just showed that routine changes to configure.ac occur far more often than updated to autoconf. You just found one project which is extremely reluctant to upgrade their autoconf (and it's one of those projects still using the deprecated configure.in file name, that says pretty much everything). Conclusion: given a patch to configure.ac, and a patch to configure, an update to autotools is far likely to require more work to maintain the configure patch, while an update to configure.ac will likely require more woth main the configure.ac. And, this is the most likely outcome given, as I pointed out in openldap's case, which you would like to ignore, happens far more often than autotools update. I'm ignoring your example because it's one example against 9+ examples from me, plus Adam Jackson's packaging experiences which started this subthread. You just found the exception. Case closed. No, your argumentation is based on false premises. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Anybody know how to contact Axel Thimm (again)?
Frank Murphy wrote: On 08/07/09 18:51, Bill Nottingham wrote: Jon Ciesla (l...@jcomserv.net) said: Is he not responding at axel.th...@atrpms.net? That's his bugzilla email addess, so that seems to be the case :-( What about i...@fedoraproject.org? i...@fp.o is not Axel. ath...@fp.o just goes to the ATrpms.net e-mail address. Bill Try a who is, it will give an extra addy. Frank Axel just replied to something from the axel.th...@atrpms.net address on his own list today. Is it possible there is a routing issue or something? I will forward one of these mails to his mailing list perhaps he just isn't getting the messages. Brent -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
On 07/08/2009 08:58 PM, Kevin Kofler wrote: Sam Varshavchik wrote: Case closed. No, your argumentation is based on false premises. Perhaps I wasn't clear in my last post. You two need to take this offlist, or simply let this thread stop by agreeing to disagree. This is the last friendly warning I'm giving before triggering the hall monitor/moderation policies. ~spot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Partitioning error during install
I have a 500G Sata Drive that I have F11 installed on half of it, using 3 primary partitions (/boot, / and swap). Now, I want to run rawhide on the other half, via F11 and update to rawhide (which I understand is not exactly running smoothly), or install rawhide itself. But the problem I run into (no matter which I install), is when I get to the partition section. I go to add a partition - not as a primary (this should allow it to be an extended correct?) - and I get an error and can't proceed any longer. So either anaconda is having problems with this setup (due to the rewrite?), or I am doing something wrong causing it to crash. BTW, when I say as or not as a primary partition, I mean I am actually checking or not checking the make it a primary partition check box. Any ideas? -- Mike Chambers Madisonville, KY Fedora Project - Bugzapper, Tester, User, etc.. miketc...@fedoraproject.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Can we import dia 0.97 in rawhide?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yes, i am doing it. Bernie Innocenti wrote: It's been released here: http://projects.gnome.org/dia/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkpVSVoACgkQzHDc8tpb2uV75gCgnbQ197n8Xu0X+SwSyopcB1/j saEAn1QSz90pMk+wvPKcLNPy/TX6d26J =DB5Q -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Kevin Kofler writes: Sam Varshavchik wrote: In my last message, rather than speculate I posted logs from a randomly chosen project, openldap, that showed that to be not the case. That's one project. It doesn't prove any sort of a general trend. That's one more project's worth of data that you posted yourself. I invite you to find a counterexample, but I regret to inform you, finding one won't be easy. I already mentioned a bunch of counterexamples (all the stuff I worked on with Romain Liévin: tfdocgen, libticables2, libticonv, libtifiles2, libticalcs2, TiLP 2, TiEmu, TiLP GFM, TiEmu SkinEdit etc.). Rattling off a bunch of project names is a poor substitute for posting two years' worth of data. Why don't you grab the last one or two years' worth of these projects' releases, and see how many releases had updated configure.ac scripts, and how many releases were rebased to newer versions of autoconf. You know, like what I did, for openldap. But, I'm pretty sure I know what you'll expect to find. And you know the same thing, too. And which is why you don't want to do it. Well, I just showed that routine changes to configure.ac occur far more often than updated to autoconf. You just found one project which is extremely reluctant to upgrade their autoconf (and it's one of those projects still using the deprecated configure.in file name, that says pretty much everything). No, it means that there is absolutely no reason to rename a file, just for the heck of it. Whether it's configure.in or configure.ac, it's irrelevant. Or, perhaps, you'd like to explain the major difference between naming the source file for autoconf as configure.in, or configure.ac. And I didn't really do much of finding, as I said. It's one of the packages that I'm tracking on http://manpages.courier-mta.org which has the largest archive of historical releases. But, you're demanding to look at some project that uses configure.ac? Sure. Not that it makes one fig's worth of difference, of course, whether it's configure.in or configure.ac, but here you go: pcre. It's another one that I'm tracking. Upstream only has the last four releases available, but they also span about a year and a half chronologically, rougly the same time span as openldap: pcre-7.6/configure:# Generated by GNU Autoconf 2.61 for PCRE 7.6. pcre-7.7/configure:# Generated by GNU Autoconf 2.61 for PCRE 7.7. pcre-7.8/configure:# Generated by GNU Autoconf 2.61 for PCRE 7.8. pcre-7.9/configure:# Generated by GNU Autoconf 2.63 for PCRE 7.9. Looking at pcre's configure.acs, only pcre-7.8 had no substantive changes from the previous version, all the others contained very major changes. Looks like this one doesn't agree with your theory, too. So go ahead, and tell me again how that's still insufficient data for your liking (all the while offering zilch of hard data yourself, I note). I'll be happy to continue, as long as you like, but, you must understand, the hits will just keep on comin'. I also snuck a peek at the evolution of GnuTLS's toolchain. I guessed that it would be your best hope of salvaging some crumb of hard data that goes your way -- given that it's a GNU project and thus would be the most likely ones to always rebase to the latest-and-greatest autotools. Well, I looked at it, and would you like to see how GnuTLS's version history actually is? I'll be happy to post it. All you have to do is ask. Conclusion: given a patch to configure.ac, and a patch to configure, an update to autotools is far likely to require more work to maintain the configure patch, while an update to configure.ac will likely require more woth main the configure.ac. And, this is the most likely outcome given, as I pointed out in openldap's case, which you would like to ignore, happens far more often than autotools update. I'm ignoring your example because it's one example against 9+ examples from me, You did not post a single example. Rattling off names of packages is not the same thing as actually listing which version of autoconf generated each version, and how many original changes went into the corresponding configure.in (or configure.ac), thus giving you an actual look at what the rate of change is to configure.ac, versus the rate of change to the version of autotools that generated the configure script. Why don't you do that, and really prove how wrong I am? pgpEYVdID5iw6.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
fedora EPEL packages.
since now the people is able to build EPEL packages, why not ask to the people when it's request cvs branch's to maintain EPEL packages too ? -- Itamar Reis Peixoto e-mail/msn: ita...@ispbrasil.com.br sip: ita...@ispbrasil.com.br skype: itamarjp icq: 81053601 +55 11 4063 5033 +55 34 3221 8599 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora EPEL packages.
On Thu, 9 Jul 2009 02:15:54 -0300, Itamar wrote: since now the people is able to build EPEL packages, since now? The people have been able to build EPEL packages for a much longer time. The only thing that's new is that koji+bodhi can be used. why not ask to the people when it's request cvs branch's to maintain EPEL packages too ? They still decide for themselves whether they want to maintain a package for EPEL. I mean, EPEL is not a secret project. If a Fedora Packager has not heard about EPEL, [s]he probably doesn't use RHEL or CentOS either. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rpms/perl-Catalyst-Controller-HTML-FormFu/devel .cvsignore, 1.4, 1.5 perl-Catalyst-Controller-HTML-FormFu.spec, 1.4, 1.5 sources, 1.4, 1.5
Author: iarnell
Update of /cvs/pkgs/rpms/perl-Catalyst-Controller-HTML-FormFu/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv2124
Modified Files:
.cvsignore perl-Catalyst-Controller-HTML-FormFu.spec sources
Log Message:
* Wed Jul 08 2009 Iain Arnell iarn...@gmail.com 0.05000-1
- update to latest upstream version
- BR perl(namespace::autoclean)
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Catalyst-Controller-HTML-FormFu/devel/.cvsignore,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -p -r1.4 -r1.5
--- .cvsignore 22 Apr 2009 03:57:30 - 1.4
+++ .cvsignore 8 Jul 2009 06:06:40 - 1.5
@@ -1 +1 @@
-Catalyst-Controller-HTML-FormFu-0.04003.tar.gz
+Catalyst-Controller-HTML-FormFu-0.05000.tar.gz
Index: perl-Catalyst-Controller-HTML-FormFu.spec
===
RCS file:
/cvs/pkgs/rpms/perl-Catalyst-Controller-HTML-FormFu/devel/perl-Catalyst-Controller-HTML-FormFu.spec,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -p -r1.4 -r1.5
--- perl-Catalyst-Controller-HTML-FormFu.spec 22 Apr 2009 03:57:30 -
1.4
+++ perl-Catalyst-Controller-HTML-FormFu.spec 8 Jul 2009 06:06:41 -
1.5
@@ -1,5 +1,5 @@
Name: perl-Catalyst-Controller-HTML-FormFu
-Version:0.04003
+Version:0.05000
Release:1%{?dist}
Summary:HTML::FormFu controller for Catalyst
License:GPL+ or Artistic
@@ -21,6 +21,7 @@ BuildRequires: perl(ExtUtils::MakeMaker
BuildRequires: perl(HTML::FormFu) = 0.04001
BuildRequires: perl(Moose)
BuildRequires: perl(MRO::Compat)
+BuildRequires: perl(namespace::autoclean)
BuildRequires: perl(Regexp::Assemble)
BuildRequires: perl(Task::Weaken)
BuildRequires: perl(Template)
@@ -65,6 +66,10 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Wed Jul 08 2009 Iain Arnell iarn...@gmail.com 0.05000-1
+- update to latest upstream version
+- BR perl(namespace::autoclean)
+
* Wed Apr 22 2009 Iain Arnell iarn...@gmail.com 0.04003-1
- update to 0.04003
- BR perl(MRO::Compat)
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Catalyst-Controller-HTML-FormFu/devel/sources,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -p -r1.4 -r1.5
--- sources 22 Apr 2009 03:57:30 - 1.4
+++ sources 8 Jul 2009 06:06:41 - 1.5
@@ -1 +1 @@
-f6c88471ec3aa75a7714851ce661ad95
Catalyst-Controller-HTML-FormFu-0.04003.tar.gz
+ca0debf2fcd396fb4e0085c231033271
Catalyst-Controller-HTML-FormFu-0.05000.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 508496] Perl: symbol lookup error: .../Wx.so: undefined symbol: Perl_Guse_safe_putenv_ptr
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=508496 --- Comment #9 from Fedora Update System upda...@fedoraproject.org 2009-07-08 04:23:43 EDT --- perl-5.10.0-73.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/perl-5.10.0-73.fc10 -- 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 Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 508496] Perl: symbol lookup error: .../Wx.so: undefined symbol: Perl_Guse_safe_putenv_ptr
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=508496 --- Comment #10 from Fedora Update System upda...@fedoraproject.org 2009-07-08 04:23:54 EDT --- perl-5.10.0-73.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/perl-5.10.0-73.fc9 -- 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 Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 508496] Perl: symbol lookup error: .../Wx.so: undefined symbol: Perl_Guse_safe_putenv_ptr
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=508496 --- Comment #11 from Fedora Update System upda...@fedoraproject.org 2009-07-08 04:24:03 EDT --- perl-5.10.0-73.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/perl-5.10.0-73.fc11 -- 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 Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 510186] New: Perl-Curses needs to filter a development module: perl(ExtUtils::testlib)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: Perl-Curses needs to filter a development module: perl(ExtUtils::testlib) https://bugzilla.redhat.com/show_bug.cgi?id=510186 Summary: Perl-Curses needs to filter a development module: perl(ExtUtils::testlib) Product: Fedora Version: 11 Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: perl-Curses AssignedTo: garr...@usc.edu ReportedBy: kwiz...@gmail.com QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-list@redhat.com, garr...@usc.edu Classification: Fedora Description of problem: Perl-Curses needs to filter a development package: perl(ExtUtils::testlib) Version-Release number of selected component (if applicable): perl-Curses-1.20-4.fc11.i586 How reproducible: always Steps to Reproduce: on a New default install 1. yum install perl-Curses Actual results: Installation: perl-Curses Installation pour dépendance: perl-ExtUtils-MakeMaker perl-ExtUtils-ParseXS perl-Test-Harness perl-devel Expected results: Installation: perl-Curses without the developement dependencies bring by perl(ExtUtils::testlib) Additional info: -- 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 Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
