Re: abrt + X Error = zillions of duplicate bug reports?
On Tuesday 24 November 2009 22:49:53 Matěj Cepl wrote:
Dne 24.11.2009 22:37, Adam Williamson napsal(a):
We came up with several possible courses of action. First, we
acknowledge that abrt team is working on improving duplicate detection,
but Matej noted that this is intrinsically hard work and abrt will
likely never be able to eliminate or even come close to eliminating
duplicate reporting.
What's the technical limitation to coming close here? It seems likely
that there will be some edge cases, but I would think that the majority
of cases aren't all that exceptional, and are fundamentally
straightforward to work out.
Don't ask me, I am just a humble bug triager (putting abrt developer on
CC of this message). What I can say is that even though I can see abrt
devs work hard to eliminate duplicates, they don't succeed much.
Apparently eliminating duplicates of bugs from beasts like Firefox or
OpenOffice is excessively hard.
Afaik, there are several projects with some crash/exception handling on top of
the stack. This makes it more difficult to find out where something actually
crashed. I think solution to this is more plugins/individual configurations.
Something like /etc/abrt/conf.d/package_name.conf
with package_name.conf content something like this (of course with better
format ;) :
refuseif()
{
IF backtrace contains adobe flash THEN RefuseReporting(This crash is caused
by proprietary blob, we can't fix it. Try to contact adobe);
ELSE IF
return OK;
}
cropbacktrace()
{
remove packagename's crash handler from top of the backtrace
}
And abrt will call these methods if they are defined.
Just my 2 cents
Michal
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Answers from the Candidate Questionnaire now in the Wiki (Was: Candidate Questionnaire status)
Hi Me again ;-) Thorsten Leemhuis wrote on 24.11.2009 08:44: Thorsten Leemhuis wrote on 17.11.2009 20:47: On 17.11.2009 07:54, Thorsten Leemhuis wrote: Thorsten Leemhuis wrote on 11.11.2009 22:30: As you may have heard already, several seats of the Fedora Board, FESCo, and FAMSCO are up for election soon(¹). Right now we are in the nomination period, which will be followed by a Candidate Questionnaire. [...] Deadline for answers: 20091124-06:00 UTC [...] Quick status update: I sent the questions to 23 people and 19 of them replied with the answers. I didn't get any replies to the questions (or my reminder mail from Sunday evening) from * Rodrigo Padula de Oliveira (RodrigoPadula) * Max Spevack (spevack) * Scott Seiersen (sseiersen) * Will Woods (wwoods) Max sent a apology, but the other remained silent afaics. I hope to find time to work through the answers later today (in something like 12 hours from now) and publish them afterwards. Compiled a wiki page with the answers and gave the nominees 12 hours to check the results. A few bugs were found and fixed, but I think everything is fine now. So the answers are now free for public consumption on this page: https://fedoraproject.org/wiki/Elections/F13_Questionnaire CU knurd P.S.: Just to make things clear 6 month early: next time somebody else has to handle the questionnaire. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 x86 DVD images
Jesse Keating jkeating at redhat.com writes: [...] The base arch of the family is i386, just like we call the ppc spin ppc even though it only supports a subset of the ppc family, ditto sparc, arm, etc... the problem is that the install and live ISOs are using different naming formats, the install is using i386 while the live is using i686. That's really confusing. Paolo -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFA] Your [PACKAGE_NAME] did not pass QA
Le mercredi 25 novembre 2009 à 01:11 +0100, Matěj Cepl a écrit : I think you didn't get the message ... you are very welcome (well, I guess, you are) to fix packaging of those fonts (see bugs at http://is.gd/52X4m). If you say, that somebody else should do the work (I was looking at it whether I could help there, but my estimate was something like a week of full time work), then let that somebody else to decide whether it makes sense. Thanks Matěj To sum up the situation: 1. The long-deprecated core fonts ecosystem is composed of users, some code xorg side, and a large pile of font files this code accesses 2. The xorg code at at least one built-in backup font to use it are not going away 3. The large pile of core fonts, OTOH, is in bitrotting packages that didn't see real maintenance for a long time (were bitrotting way before the Fedora Core handover and were never cleaned up since). They still regularly fail and cause crashes that make a bad rep to Fedora fonts. 4. Some people like me and Matěj have been spending or were planning to spend some time trying to fix this. Not because we use this stuff, but because of some misplaced sense of duty. It is not fun stuff at all, however, and anything that helps reducing the enveloppe to fix is welcome news. 5. The real users of this stuff never contributed a bit to this maintenance, avoid answering questions when people ask something about it, refused to write packaging guidelines to help others do this work for them when (repeatedly) invited to, and react in a very hostile manner when they get a single mail asking them to make some effort to stop using this stuff (either patching it out, convincing their upstream to do this change, or finding another non-core-fonts-using alternative to package in Fedora, there are many possible solutions). They were *not* asked to help cleaning up the font packages themselves, because, after all this years of no action, it's pretty clear none of them want to. In other words, they collectively expect someone else to do the ugly, boring, and time-consuming work on the stuff they use, and BTW this someone else should shut up about it and not remind them they behave like parasites (let's call things by their real name). Given all this, I'm not motivated a lot to contribute to this work anymore (if I end up doing it it's because I promised people like Matěj help, not because I feel like helping core fonts users anymore. If Matěj and others do their part I'll help them but that's all). So I suppose the only remaining course of action is to: A. investigate if it's possible for a core fonts client to make sure it only accesses the built-in backup core font. B. if not investigate it it's possible to write a small proxy lib with a core-fonts-like api that do not let an app select any font but the built-in backup core font C. if A. or B. are true, orphan all the core font packages in Fedora, and give their current users the choice of : a. drop their core font use b. make sure they only access the built-in backup core font (possibly, writing B themselves) c. actually pick up the maintenance of the core fonts packages they use, starting with writing (and getting approved) clear guidelines how they should be packaged, then passing each of the core fonts packages they need through a thorough Fedora review (not let anyone re-import them in their current awful state, then sit up doing nothing about it) In others words, go through the orphan route that was suggested by others in this thread. (RHEL will of course make its own choices) -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: abrt + X Error = zillions of duplicate bug reports?
Hi Adam, please see below. On 11/24/2009 08:15 PM, Adam Williamson wrote: On Sun, 2009-11-22 at 19:21 +0100, Martin Sourada wrote: So, since I've already received 3 separate bug reports caused by BadIDChoice X Error in subtitleeditor [1][2][3] (haven't had enough time to debug and try to fix it yet though) by abrt, I wonder if there is any room for duplicity detection improvement in these cases, or if we are doomed to zillions of duplicates in rhbz? (btw. otherwise abrt is awesome, IMHO the bugreports from abrt are much more useful than before :-) We discussed this issue at the Bugzappers meeting today. BZ would like to register that the high level of duplicates reported by abrt is a significant issue for triage work. We're not sure we can sustainably triage some major components (e.g. Firefox) if the current situation continues. We came up with several possible courses of action. First, we acknowledge that abrt team is working on improving duplicate detection, but Matej noted that this is intrinsically hard work and abrt will likely never be able to eliminate or even come close to eliminating duplicate reporting. The algorithm for duplicate detection in the currently released version of ABRT is very rudimentary: it removes only the most obvious duplicates in simple programs. As far as I know it does not work for applications with variable number of threads (e.g. Firefox). Fortunately now we have a new algorithm for duplicate detection which handles all the cases in a significantly better way. Most of the code is written, but it needs some testing before releasing. I guess it will take two weeks or so to finish it, and to make sure it works well. An important attribute of the new algorithm is that it errs on the side of false duplicates. So it will much more often say some bug is a duplicate of another bug, even if sometimes it is not the case. It should make abrt bug flow sustainable, and than we can slowly improve the detection mechanism to be more accurate. Second, we wondered if abrt team might be able to assist in running any improved duplicate detection mechanisms over already-reported bugs in Bugzilla retrospectively. We will follow up with them about that. Third, we agreed to look at methods used in GNOME and other Bugzillas to cope with high levels of duplicate reporting from automated tools, such as extracting significant sections of tracebacks as bug comments to make manual duplicate detection faster and easier. Good idea. Finally, we considered - and rather approved of - the proposal that's been floated on this list (and was floating in the meeting by Will Woods) to consider using the mechanism used by the kernel developers for kernel oopses: instead of being reported direct to Bugzilla, these are reported to an intermediate site (kerneloops.org) and can be promoted from there to Bugzilla if appropriate. Will is planning to work on this idea after finishing up some AutoQA work, and will talk to abrt team about it and see if they are interested in helping. He would welcome contact from anyone else who's interested in helping with that, too. When the duplicate detection works, it would be a loss to not have the crashes directly in Bugzilla. I often see that the crashes reported by ABRT are located in the code and fixed. If we fail to deliver better detection, then some intermediate site is certainly better target for thousands of duplicates than Bugzilla. I would propose to create some intermediate site as a target for users who are not experienced enough to create an account in Bugzilla and to respond to questions, or they simply do not care. Then, it would be possible for them to report almost automatically, and we could get a lot of backtraces and support data that is currently lost. However, this must be thought out (security issue with backtraces). That's all, really - I just took an action item to pass on our thoughts about this :) Best regards, Karel -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFA] Your [PACKAGE_NAME] did not pass QA
Le mercredi 25 novembre 2009 à 10:03 +0100, Nicolas Mailhot a écrit : A. investigate if it's possible for a core fonts client to make sure it only accesses the built-in backup core font. B. if not investigate it it's possible to write a small proxy lib with a core-fonts-like api that do not let an app select any font but the built-in backup core font Or even simpler, define a magic font name the core fonts system never resolves to anything else than the built-in font. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFC] unified i386/x86_64 install media.
On Wed, Nov 25, 2009 at 09:38, Nicu Buculei nicu_fed...@nicubunu.ro wrote: Instead of this I would pretty much like to have the normal install DVD being full (4GB, instead of 3.0-3.3GB as now), so when installing a computer I have more content on local media and less stuff to get from online sources, resulting in a shorter time until the computer is fully usable. +1 There is a big problem for people of almost all small cities in Ukraine to download a DVD or get software from internet. Internet access is a dialup/gprs. Fedora respins with additional software (like http://russianfedora.ru/) is more popular among them. People usually exchange DVDs among themselves. -- With best regards, Nikolay Ulyanitsky http://www.lystor.org.ua -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: abrt + X Error = zillions of duplicate bug reports?
On Mon, 2009-11-23 at 10:52 -0500, Adam Jackson wrote: On Sun, 2009-11-22 at 19:21 +0100, Martin Sourada wrote: So, since I've already received 3 separate bug reports caused by BadIDChoice X Error in subtitleeditor [1][2][3] (haven't had enough time to debug and try to fix it yet though) by abrt, I wonder if there is any room for duplicity detection improvement in these cases, or if we are doomed to zillions of duplicates in rhbz? (btw. otherwise abrt is awesome, IMHO the bugreports from abrt are much more useful than before :-) I know this is non-obvious, but: BadIDChoice or BadImplementation X errors are _always_ bugs in libX11 or the server itself, respectively. Please reassign BadIDChoice bugs to libX11. Thanks for the info. Bug 538382 reassigned to libX11. Martin 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: [RFC] unified i386/x86_64 install media.
On 11/25/2009 08:38 AM, Nicu Buculei wrote: Instead of this I would pretty much like to have the normal install DVD being full (4GB, instead of 3.0-3.3GB as now), so when installing a computer I have more content on local media and less stuff to get from online sources, resulting in a shorter time until the computer is fully usable. You might want an Everything spin ;-) -- Jeroen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFC] unified i386/x86_64 install media.
On 11/25/2009 03:26 AM, Seth Vidal wrote: On Tue, 24 Nov 2009, Matthew Miller wrote: So would this mean one disk with two repositories on it, or is everything mashed together all in one repository? it'd be easy to have two sets of repodata in two different dirs pointing to the same set of pkgs. On 11/25/2009 07:28 AM, Jesse Keating wrote: Two repos, but with hardlinks. I doubt ISO9660 can deal with hardlinks, but I have to admit I've never really tried (I did try once and gave up pretty quickly I recall). Also, the way I understand this works, you can just include x86_64 packages in the one repository... When the system boots 32-bit (kernel, userland, etc, using syslinux 3.72+ ifcpu64.c32 which I have not yet been able to get to work yet) the x86_64 packages won't show up in the available packages, 'cause of how YUM does something with a list of compatArchs, right? -- Jeroen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Bug in python?
Hi, while I was investigating an offlineimap bug, the following happened quite often: File /usr/lib64/python2.6/threading.py, line 497, in __bootstrap self.__bootstrap_inner() File /usr/lib64/python2.6/threading.py, line 575, in __bootstrap_inner self.__stop() File /usr/lib64/python2.6/threading.py, line 586, in __stop self.__block.notify_all() File /usr/lib64/python2.6/threading.py, line 289, in notifyAll self.notify(len(self.__waiters)) File /usr/lib64/python2.6/threading.py, line 277, in notify self._note(%s.notify(): no waiters, self) File /usr/lib64/python2.6/threading.py, line 68, in _note current_thread().name, format) File /usr/lib64/python2.6/threading.py, line 808, in currentThread return _DummyThread() File /usr/lib64/python2.6/threading.py, line 788, in __init__ self._Thread__started.set() File /usr/lib64/python2.6/threading.py, line 378, in set self.__cond.notify_all() File /usr/lib64/python2.6/threading.py, line 289, in notifyAll self.notify(len(self.__waiters)) File /usr/lib64/python2.6/threading.py, line 277, in notify self._note(%s.notify(): no waiters, self) File /usr/lib64/python2.6/threading.py, line 68, in _note current_thread().name, format) File /usr/lib64/python2.6/threading.py, line 808, in currentThread return _DummyThread() File /usr/lib64/python2.6/threading.py, line 788, in __init__ self._Thread__started.set() File /usr/lib64/python2.6/threading.py, line 378, in set self.__cond.notify_all() File /usr/lib64/python2.6/threading.py, line 289, in notifyAll self.notify(len(self.__waiters)) File /usr/lib64/python2.6/threading.py, line 277, in notify self._note(%s.notify(): no waiters, self) File /usr/lib64/python2.6/threading.py, line 68, in _note current_thread().name, format) File /usr/lib64/python2.6/threading.py, line 808, in currentThread return _DummyThread() File /usr/lib64/python2.6/threading.py, line 788, in __init__ self._Thread__started.set() File /usr/lib64/python2.6/threading.py, line 378, in set self.__cond.notify_all() File /usr/lib64/python2.6/threading.py, line 289, in notifyAll Looks to me like calling _DummyThread() every time and then printing a debug output is a bad idea, right? 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: [RFC] unified i386/x86_64 install media.
On 11/25/2009 01:13 PM, Jeroen van Meeuwen wrote: On 11/25/2009 08:38 AM, Nicu Buculei wrote: Instead of this I would pretty much like to have the normal install DVD being full (4GB, instead of 3.0-3.3GB as now), so when installing a computer I have more content on local media and less stuff to get from online sources, resulting in a shorter time until the computer is fully usable. You might want an Everything spin ;-) ... or an install using a local copy of Everything on local network or machine-local filesystem [1] It's what I had been using when I only had low bandwidth access[1]. Ralf [1] I live in a DSL white spot ;-) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Extremely Unstable
On Tue, 2009-11-24 at 21:08 -0500, brad longo wrote: I just installed Fedora 12, to replace Fedora 11, and I have some bugs but I'm not sure where to file them. Please help me get these into bugzilla as they are urgent. 1. Fedora 12 crashes frequently and makes it almost unusable for me. It seems to crash whenever I try to edit/change sound preferences. When I do this I get logged out and then have to log back in. I can repeat this at any time by going to go System-Preferences-Sound. 2. Editing preferences for certain programs causes me to be logged out but this is random and I haven't found a way to repeat it. 3. Changes to keyboard shortcuts are not saved. I tried mapping Alt+T as the shortcut for the terminal and it does not work. Have you also updated your system since the install to make sure you any included fixes/updates that didn't make it to final release? -- Mike Chambers Madisonville, KY Best lil town on Earth! -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFC] unified i386/x86_64 install media.
Once upon a time, Jeff Garzik jgar...@pobox.com said: On 11/25/2009 01:32 AM, Jesse Keating wrote: Look closer. It is only a small subset of the i686 content in the x86_64 repo for multilib purposes. That's merely a space issue, not any failure to or absence of mash No, it isn't just an issue of space. You don't want to present all of the i386 repo to x86_64 installs, as a lot of the packages would result in conflicts. Only a subset of i686 packages can coexist with x86_64 packages. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 install stops at screen switch (language select)
On Tue, Nov 24, 2009 at 07:18:27PM +0100, Jos Vos wrote: OK, installing with nomodeset xdriver=intel vga=ask seems to work (chosen VESA 1024x768) and is busy now. I'll reopen my old bug and report more tomorrow. OK, I tried several installs and tried to minimize what has to be done and it already works when adding nomodeset, without any additional xdriver or vga options. After that, booting the system and starting X works too (without any xorg.conf), but switching consoles only works when I have added some vga setting (I use vga=792) to the grub kernel parameter list. The nomodeset is also in this list (added by anaconda). Also, for the graphical boot screen the vga=... setting is needed too. Will also log this information in the ticket. -- --Jos Vos j...@xos.nl --X/OS Experts in Open Systems BV | Phone: +31 20 6938364 --Amsterdam, The Netherlands| Fax: +31 20 6948204 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: example content
2009/11/23 Matthias Clasen mcla...@redhat.com: Hey, one change we are planning to make to the desktop spin in F13 is to go from targeting a cd to targeting a 1g usb stick. That will give us enough breathing room to include not only OpenOffice, but also some example content on the spin. We've wanted to do that for a long time, but the cd size restriction have prohibited that. The example content is meant to serve several purposes: - Be informative and/or pleasant - Allow users to try the included apps - Showcase content that has been produced with open source apps - Make the desktop spin more useful, e.g. to ambassadors Examples that might fit some of these categories are: - Suitably licensed music or movie trailers (big buck bunny has been mentioned already) - Spreadsheets or documents that contain interesting facts about Fedora or open source - the 1-page release notes pdf that was debuted for F12 The purpose of this mail is to solicit proposals for content that might fit into these categories. Please send your proposals to fedora-desktop-list or just reply. Thanks! Matthias Will all this magical content be in one easily-removable package? ;-) -- Mat Booth -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFC] unified i386/x86_64 install media.
On Wed, 2009-11-25 at 13:18 +0100, Jeroen van Meeuwen wrote: On 11/25/2009 03:26 AM, Seth Vidal wrote: On Tue, 24 Nov 2009, Matthew Miller wrote: So would this mean one disk with two repositories on it, or is everything mashed together all in one repository? it'd be easy to have two sets of repodata in two different dirs pointing to the same set of pkgs. On 11/25/2009 07:28 AM, Jesse Keating wrote: Two repos, but with hardlinks. I doubt ISO9660 can deal with hardlinks, but I have to admit I've never really tried (I did try once and gave up pretty quickly I recall). Also, the way I understand this works, you can just include x86_64 packages in the one repository... You can but that will break x86_64, because i386 will need i386 packages that x86_64 must not have as multilib. As Seth said, you can have one giant directory of packages and just different repodata pointing to subsets. As Jesse said you could also use hardlinks/symlinks in the x86_64 repo. Or you could even create three repos. i386, x86_64 and i386-common (not that I think that will be better than the other two options). -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.25 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Answers from the Candidate Questionnaire now in the Wiki (Was: Candidate Questionnaire status)
On Wed, Nov 25, 2009 at 2:02 AM, Thorsten Leemhuis fed...@leemhuis.info wrote: So the answers are now free for public consumption on this page: https://fedoraproject.org/wiki/Elections/F13_Questionnaire CU knurd P.S.: Just to make things clear 6 month early: next time somebody else has to handle the questionnaire. knurd I just want to thank you again for all your work on this. I understand it is a burden to candidates and a lot of work for you to collect and organize the answers but it sure makes for some interesting reading. For those who don't personally know the candidates you have made a big contribution to the recent elections. John -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Issues with vsftpd on Fedora 12
LDAP is enabled on my server for authentication. I would like to use vsftpd on that server, but there is a very big delay during authentication and I am wondering if this is not an issue with vsftpd software. It seems that even if I log in as anonymous user, vsftpd tries to access LDAP server. On my server, I see these error logs during authentication: Nov 24 15:52:44 localhost vsftpd[25813]: nss_ldap: failed to bind to LDAP server ldap://10.1.1.5/: Can't contact LDAP server Nov 24 15:52:44 localhost vsftpd[25813]: nss_ldap: reconnecting to LDAP server (sleeping 8 seconds)... After a delay of more than a minute, vsftpd will authorize anonymous user, but this very long delay is causing me a lot of grief. What is even more surprising is that I ran tcpdump to see the vsftpd communication to the LDAP server, but the LDAP server never receives any packets from my Fedora 12 server. It looks like vsftpd thinks it needs to contact the server, but never does. What is also surprising is that I can ssh to that server and ssh is configured to use the LDAP server. So, the LDAP server is reachable from that server. Not sure how to troubleshoot this issue or if I am the only one with this problem. Martin -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rawhide report: 20091125 changes
Compose started at Wed Nov 25 08:15:11 UTC 2009 Broken deps for i386 -- Miro-2.5.3-2.fc13.i686 requires gecko-libs = 0:1.9.1.5 ScientificPython-2.8-6.fc11.i586 requires libnetcdf.so.4 anjal-0.1.0-1.fc13.i686 requires libevolution-mail-shared.so.0 anjal-0.1.0-1.fc13.i686 requires libefilterbar.so.0 bind-dyndb-ldap-0.1.0-0.3.a1.fc12.i686 requires libdns.so.50 blacs-mpich2-1.1-33.fc12.i686 requires libmpich.so.1.1 blam-1.8.5-20.fc13.i686 requires gecko-libs = 0:1.9.1.5 cdo-1.0.8-6.fc12.i686 requires libnetcdf.so.4 cluster-snmp-0.16.1-2.fc12.i686 requires libnetsnmp.so.15 collectd-snmp-4.6.5-1.fc12.i686 requires libnetsnmp.so.15 digikam-1.0.0-0.9.beta6.fc12.i686 requires libkdcraw.so.7 digikam-1.0.0-0.9.beta6.fc12.i686 requires libkexiv2.so.7 digikam-1.0.0-0.9.beta6.fc12.i686 requires libkipi.so.6 digikam-libs-1.0.0-0.9.beta6.fc12.i686 requires libkdcraw.so.7 digikam-libs-1.0.0-0.9.beta6.fc12.i686 requires libkexiv2.so.7 digikam-libs-1.0.0-0.9.beta6.fc12.i686 requires libkipi.so.6 dnsperf-1.0.1.0-12.fc12.i686 requires libdns.so.50 dnsperf-1.0.1.0-12.fc12.i686 requires libisc.so.50 dnsperf-1.0.1.0-12.fc12.i686 requires libbind9.so.50 dnsperf-1.0.1.0-12.fc12.i686 requires libisccfg.so.50 evolution-exchange-2.28.0-1.fc12.i686 requires libexchange-storage-1.2.so.3 galeon-2.0.7-19.fc13.i686 requires gecko-libs = 0:1.9.1.5 gnome-python2-gtkmozembed-2.25.3-13.fc13.i686 requires gecko-libs = 0:1.9.1.5 gnome-web-photo-0.9-3.fc13.i686 requires gecko-libs = 0:1.9.1.5 grads-1.9b4-28.fc12.i686 requires libnetcdf.so.4 gtranslator-1.9.6-2.fc13.i686 requires libsvn_fs_base-1.so.0 hulahop-0.6.0-2.fc12.i686 requires xulrunner-python hulahop-0.6.0-2.fc12.i686 requires libpyxpcom.so ifstat-1.1-12.fc12.i686 requires libnetsnmp.so.15 inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python jaxodraw-latex-2.0.1-3.fc13.noarch requires tex(texmf) kdebase-workspace-python-applet-4.3.75-0.1.svn1048496.fc13.i686 requires PyKDE4 = 0:4.3.75 7:kdenetwork-4.3.3-6.fc13.i686 requires libkdewebkit.so.1 6:kdeutils-devel-4.3.75-0.2.svn1048496.fc13.i686 requires kdelibs4-devel(x86-32) = 0:4.3.75 kipi-plugins-0.8.0-1.fc12.i686 requires libkexiv2.so.7 kipi-plugins-0.8.0-1.fc12.i686 requires libkdcraw.so.7 kipi-plugins-0.8.0-1.fc12.i686 requires libkipi.so.6 kipi-plugins-libs-0.8.0-1.fc12.i686 requires libkdcraw.so.7 kipi-plugins-libs-0.8.0-1.fc12.i686 requires libkexiv2.so.7 kipi-plugins-libs-0.8.0-1.fc12.i686 requires libkipi.so.6 3:koffice-krita-2.1.0-1.fc13.i686 requires libkdcraw.so.7 1:koffice-langpack-ca-2.1.0-1.fc13.noarch requires koffice-langpack = 0:2.1.0-1.fc13 1:koffice-langpack-da-2.1.0-1.fc13.noarch requires koffice-langpack = 0:2.1.0-1.fc13 1:koffice-langpack-de-2.1.0-1.fc13.noarch requires koffice-langpack = 0:2.1.0-1.fc13 1:koffice-langpack-el-2.1.0-1.fc13.noarch requires koffice-langpack = 0:2.1.0-1.fc13 1:koffice-langpack-en_GB-2.1.0-1.fc13.noarch requires koffice-langpack = 0:2.1.0-1.fc13 1:koffice-langpack-es-2.1.0-1.fc13.noarch requires koffice-langpack = 0:2.1.0-1.fc13 1:koffice-langpack-et-2.1.0-1.fc13.noarch requires koffice-langpack = 0:2.1.0-1.fc13 1:koffice-langpack-fr-2.1.0-1.fc13.noarch requires koffice-langpack = 0:2.1.0-1.fc13 1:koffice-langpack-fy-2.1.0-1.fc13.noarch requires koffice-langpack = 0:2.1.0-1.fc13 1:koffice-langpack-gl-2.1.0-1.fc13.noarch requires koffice-langpack = 0:2.1.0-1.fc13 1:koffice-langpack-hne-2.1.0-1.fc13.noarch requires koffice-langpack = 0:2.1.0-1.fc13 1:koffice-langpack-it-2.1.0-1.fc13.noarch requires koffice-langpack = 0:2.1.0-1.fc13 1:koffice-langpack-ja-2.1.0-1.fc13.noarch requires koffice-langpack = 0:2.1.0-1.fc13 1:koffice-langpack-kk-2.1.0-1.fc13.noarch requires koffice-langpack = 0:2.1.0-1.fc13 1:koffice-langpack-nb-2.1.0-1.fc13.noarch requires koffice-langpack = 0:2.1.0-1.fc13 1:koffice-langpack-nds-2.1.0-1.fc13.noarch requires koffice-langpack = 0:2.1.0-1.fc13 1:koffice-langpack-nl-2.1.0-1.fc13.noarch requires koffice-langpack = 0:2.1.0-1.fc13 1:koffice-langpack-pl-2.1.0-1.fc13.noarch requires koffice-langpack = 0:2.1.0-1.fc13 1:koffice-langpack-pt-2.1.0-1.fc13.noarch requires koffice-langpack = 0:2.1.0-1.fc13 1:koffice-langpack-pt_BR-2.1.0-1.fc13.noarch requires koffice-langpack = 0:2.1.0-1.fc13 1:koffice-langpack-sv-2.1.0-1.fc13.noarch requires koffice-langpack = 0:2.1.0-1.fc13 1:koffice-langpack-tr-2.1.0-1.fc13.noarch requires koffice-langpack = 0:2.1.0-1.fc13
Re: [RFC] unified i386/x86_64 install media.
On Nov 24, 2009, at 22:49, Jeff Garzik jgar...@pobox.com wrote: On 11/25/2009 01:32 AM, Jesse Keating wrote: On Nov 24, 2009, at 19:30, Jeff Garzik jgar...@pobox.com wrote: On 11/24/2009 09:58 PM, Matthew Miller wrote: On Tue, Nov 24, 2009 at 09:19:22PM -0500, Jeff Garzik wrote: So would this mean one disk with two repositories on it, or is everything mashed together all in one repository? The current x86-64 has both 32-bit and 64-bit mashed together, so that sort of configuration would be more of the same. Well, it's currently only half-mashed. In Fedora 12, the i686 and x86-64 rpms are in the same directory, on the x86-64 DVD ISO. That's sufficiently mashed for my purposes, but whatever... :) Look closer. It is only a small subset of the i686 content in the x86_64 repo for multilib purposes. That's merely a space issue, not any failure to or absence of mash Jeff Wow. Ok let me be clear here. The 32 bit packages you see are specifically selected to fulfill a multilib role. We cannot put every package in as there would be lots of conflicts in the packages that are nit suitable for multilib. Please stop making assumptions about our compose process and strategy which you clearly don't understand. -- Jes -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: example content
Will all this magical content be in one easily-removable package? ;-) maybe we need something like fedora-logos and generic-logos ie. fedora-samples and generic-samples (for easy trademark re-branding) they both may provide system-samples or desktop-samples (other spins could have kde-desktop-samples and desktop-common-samples) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Extremely Unstable
I reinstalled Fedora, and also checked the cd I installed from to see if that would fix the problem. I believe the issues I had previously may have been caused by putting /home on its own lvm, which I did not do when I reinstalled. I wanted to do this so I could install future releases without having to erase the home folder. Unfortunately, I don't have the time continue to reinstall Fedora over and over to confirm that putting /home on its own lvm is the source of the issue, but maybe someone else can replicate this? Before reinstalling, the programs that crashed when I tried to edit their preferences were all of the ones I tried: Thunderbird, Empathy, and Mozilla. The automatic bug reporting tool crashed the system when trying to report some of the bugs too. The system was fully update when I was experiencing the crashes. Reinstalling solved all of my problems except one. Keyboard shortcuts are still not saved. However, this issue is trivial compared to the frequent crashes I was experiencing before. Brad. On 11/25/2009 09:00 AM, Mike Chambers wrote: On Tue, 2009-11-24 at 21:08 -0500, brad longo wrote: I just installed Fedora 12, to replace Fedora 11, and I have some bugs but I'm not sure where to file them. Please help me get these into bugzilla as they are urgent. 1. Fedora 12 crashes frequently and makes it almost unusable for me. It seems to crash whenever I try to edit/change sound preferences. When I do this I get logged out and then have to log back in. I can repeat this at any time by going to go System-Preferences-Sound. 2. Editing preferences for certain programs causes me to be logged out but this is random and I haven't found a way to repeat it. 3. Changes to keyboard shortcuts are not saved. I tried mapping Alt+T as the shortcut for the terminal and it does not work. Have you also updated your system since the install to make sure you any included fixes/updates that didn't make it to final release? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Extremely Unstable
Brad Longo wrote: I reinstalled Fedora, and also checked the cd I installed from to see if that would fix the problem. I believe the issues I had previously may have been caused by putting /home on its own lvm, which I did not do when I reinstalled. I wanted to do this so I could install future releases without having to erase the home folder. Unfortunately, I don't have the time continue to reinstall Fedora over and over to confirm that putting /home on its own lvm is the source of the issue, but maybe someone else can replicate this? I'd be awfully surprised if this were the root cause. The suggestion to run the failing application from a console, and look for errors on the console and the X log, sounds like the best plan of attack to me. Before reinstalling, the programs that crashed when I tried to edit their preferences were all of the ones I tried: Thunderbird, Empathy, and Mozilla. The automatic bug reporting tool crashed the system when trying to report some of the bugs too. The system was fully update when I was experiencing the crashes. Reinstalling solved all of my problems except one. Keyboard shortcuts are still not saved. However, this issue is trivial compared to the frequent crashes I was experiencing before. oh, ok. Hm, odd. -Eric Brad. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Extremely Unstable
On 11/25/2009 11:13 AM, Eric Sandeen wrote: Brad Longo wrote: I reinstalled Fedora, and also checked the cd I installed from to see if that would fix the problem. I believe the issues I had previously may have been caused by putting /home on its own lvm, which I did not do when I reinstalled. I wanted to do this so I could install future releases without having to erase the home folder. Unfortunately, I don't have the time continue to reinstall Fedora over and over to confirm that putting /home on its own lvm is the source of the issue, but maybe someone else can replicate this? I'd be awfully surprised if this were the root cause. The suggestion to run the failing application from a console, and look for errors on the console and the X log, sounds like the best plan of attack to me. Before reinstalling, the programs that crashed when I tried to edit their preferences were all of the ones I tried: Thunderbird, Empathy, and Mozilla. The automatic bug reporting tool crashed the system when trying to report some of the bugs too. The system was fully update when I was experiencing the crashes. Reinstalling solved all of my problems except one. Keyboard shortcuts are still not saved. However, this issue is trivial compared to the frequent crashes I was experiencing before. oh, ok. Hm, odd. -Eric I just got keyboard shortcuts to work by enabling compiz. Compiz was disabled by default. Brad. Brad. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Answers from the Candidate Questionnaire now in the Wiki (Was: Candidate Questionnaire status)
inode0 (ino...@gmail.com) said: So the answers are now free for public consumption on this page: https://fedoraproject.org/wiki/Elections/F13_Questionnaire I just want to thank you again for all your work on this. I understand it is a burden to candidates and a lot of work for you to collect and organize the answers but it sure makes for some interesting reading. For those who don't personally know the candidates you have made a big contribution to the recent elections. Agreed; thanks for all the hard work here! Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Final F-10 updates push
Hi All, Fedora 10 will go EOL on December 17th. The final day for updates to be submitted will be December 14th. Please make sure any final updates you want pushed to the F10 repos are submitted by this date. Thanks, josh ___ Fedora-devel-announce mailing list fedora-devel-annou...@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
crazy Xrandr/XOrg automatic display configuration.
I assumed, via the release notes, that the new Xorg operates in extend-desktop mode by default. However, I'm not sure. When I hook up a running Fedora laptop to a projector, my desktop is extended. Very nice. When I hook up the same projector and then -boot- my Fedora laptop, I am set to mirrored-mode by default at startup. Does anyone else have this? Why are there two different external display behaviors? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: crazy Xrandr/XOrg automatic display configuration.
On Wed, 2009-11-25 at 12:33 -0500, Jud Craft wrote: I assumed, via the release notes, that the new Xorg operates in extend-desktop mode by default. However, I'm not sure. When I hook up a running Fedora laptop to a projector, my desktop is extended. Very nice. When I hook up the same projector and then -boot- my Fedora laptop, I am set to mirrored-mode by default at startup. Does anyone else have this? Why are there two different external display behaviors? The latter is probably due to your BIOS... Have you tried plugging the external projector when you're in GRUB and not before cold starting? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: crazy Xrandr/XOrg automatic display configuration.
On Wed, 2009-11-25 at 12:33 -0500, Jud Craft wrote: I assumed, via the release notes, that the new Xorg operates in extend-desktop mode by default. However, I'm not sure. When I hook up a running Fedora laptop to a projector, my desktop is extended. Very nice. When I hook up the same projector and then -boot- my Fedora laptop, I am set to mirrored-mode by default at startup. Does anyone else have this? Why are there two different external display behaviors? This is intentional. Plymouth is rendering the same boot animation on all heads; not sure we can do much better. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Extremely Unstable
On 11/24/2009 07:08 PM, brad longo wrote: I just installed Fedora 12, to replace Fedora 11, and I have some bugs but I'm not sure where to file them. Please help me get these into bugzilla as they are urgent. 1. Fedora 12 crashes frequently and makes it almost unusable for me. This really isn't the proper mailling list, but try kernels (and *) from updates-testing, seem to have fixed a intermittent lockup on my machine. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: abrt + X Error = zillions of duplicate bug reports?
On Wed, 2009-11-25 at 10:20 +0100, Karel Klic wrote: We came up with several possible courses of action. First, we acknowledge that abrt team is working on improving duplicate detection, but Matej noted that this is intrinsically hard work and abrt will likely never be able to eliminate or even come close to eliminating duplicate reporting. The algorithm for duplicate detection in the currently released version of ABRT is very rudimentary: it removes only the most obvious duplicates in simple programs. As far as I know it does not work for applications with variable number of threads (e.g. Firefox). Fortunately now we have a new algorithm for duplicate detection which handles all the cases in a significantly better way. Most of the code is written, but it needs some testing before releasing. I guess it will take two weeks or so to finish it, and to make sure it works well. An important attribute of the new algorithm is that it errs on the side of false duplicates. So it will much more often say some bug is a duplicate of another bug, even if sometimes it is not the case. It should make abrt bug flow sustainable, and than we can slowly improve the detection mechanism to be more accurate. Second, we wondered if abrt team might be able to assist in running any improved duplicate detection mechanisms over already-reported bugs in Bugzilla retrospectively. We will follow up with them about that. When the duplicate detection works, it would be a loss to not have the crashes directly in Bugzilla. I often see that the crashes reported by ABRT are located in the code and fixed. If we fail to deliver better detection, then some intermediate site is certainly better target for thousands of duplicates than Bugzilla. I would propose to create some intermediate site as a target for users who are not experienced enough to create an account in Bugzilla and to respond to questions, or they simply do not care. Then, it would be possible for them to report almost automatically, and we could get a lot of backtraces and support data that is currently lost. However, this must be thought out (security issue with backtraces). Thanks, Karel. If you think you'll be able to manage a level of duplicate detection which keeps things workable for triaging, that's great news and would certainly make the whole situation simpler :). I think we'd be willing to wait on that and see how it goes. I was working from Matej's suggestion in the meeting that he'd talked to you (abrt team) already and was sure that a high enough level of duplicate detection was hard/impossible; if that's not the case, obviously it changes things. What do you think of the idea of running the improved duplicate detection logic over existing abrt bug reports in Bugzilla? Would that be feasible, perhaps with some help from the Bugzilla maintainer? Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: crazy Xrandr/XOrg automatic display configuration.
On Wed, Nov 25, 2009 at 12:48 PM, Matthias Clasen wrote: This is intentional. Plymouth is rendering the same boot animation on all heads; not sure we can do much better. Oh, I don't mind that at all. That's awesome. I understand that clone mode is excellent for Plymouth. But after Fedora logs in, couldn't GNOME/Xorg set an extended desktop? Since that does seem to be the endorsed behavior. Surely letting Plymouth use clone mode doesn't mean the desktop session can't expand the desktop after login? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: crazy Xrandr/XOrg automatic display configuration.
On Wed, 2009-11-25 at 13:00 -0500, Jud Craft wrote: On Wed, Nov 25, 2009 at 12:48 PM, Matthias Clasen wrote: This is intentional. Plymouth is rendering the same boot animation on all heads; not sure we can do much better. Oh, I don't mind that at all. That's awesome. I understand that clone mode is excellent for Plymouth. But after Fedora logs in, couldn't GNOME/Xorg set an extended desktop? Since that does seem to be the endorsed behavior. Surely letting Plymouth use clone mode doesn't mean the desktop session can't expand the desktop after login? Oh, I misunderstood. Yeah, it should remember the previous configuration you had with this combination of outputs. This information is stored in ~/.config/monitors.xml. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: crazy Xrandr/XOrg automatic display configuration.
Oh, I misunderstood. Yeah, it should remember the previous configuration you had with this combination of outputs. This information is stored in ~/.config/monitors.xml. Right. I guess what I'm saying is...it doesn't seem to. The very first time I booted my laptop with this (800x600) projector, it defaulted to clone mode in session. I left the room and restarted my laptop. When I returned, plugging the monitor in live resulted in an extended desktop (very cool). I then restarted my laptop and let it boot fresh with the monitor plugged in. The desktop session started in clone mode again. I have a completely-different-in-every-way giant widescreen monitor at home, so I don't think Display Settings is mixing up the external display configurations. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
memset bugs.
There's some obvious bugs below in a bunch of packages. The 2nd and 3rd arguments to memset calls are the wrong way around. I found these after grepping through a make prep'd devel/ tree. 15 hits out of 100G of source code isn't that bad, but we can do better! Dave Checking ./afflib/afflib-3.5.2/lib/s3_glue.cpp Found memset with swapped arguments. 303:memset(b64str,sizeof(b64str),0); Checking ./afflib/afflib-3.5.2/lib/vnode_s3.cpp Found memset with swapped arguments. 205:memset(segname,segname_len,0); Checking ./afflib/afflib-3.5.2/lib/crypto.cpp Found memset with swapped arguments. 975:memset(decrypted,total_encrypted_bytes,0); // overwrite our temp buffer Checking ./panoglview/panoglview-0.2.2/src/panocanvas.cpp Found memset with swapped arguments. 160: memset(tmp,m_maxsize*m_maxsize,0); Checking ./condor/condor-7.2.4/src/condor_c++_util/read_user_log_state.cpp Found memset with swapped arguments. 497:memset( istate-m_base_path, sizeof(istate-m_base_path), 0 ); Checking ./milkytracker/milkytracker-0.90.80/src/milkyplay/LoaderPSM.cpp Found memset with swapped arguments. 999:memset(packed,size-4+5,0); Checking ./sim/sim/sim/sockfactory.cpp Found memset with swapped arguments. 546:memset(addr, sizeof(addr), 0); Checking ./commoncpp2/commoncpp2-1.7.3/src/thread.cpp Found memset with swapped arguments. 525:memset(act, sizeof(act), 0); Checking ./commoncpp2/commoncpp2-1.7.3/src/socket.cpp Found memset with swapped arguments. 1571: memset(group, sizeof(group), 0); Checking ./celestia/celestia-1.5.1/src/celestia/winmain.cpp Found memset with swapped arguments. 2181:memset(info, sizeof(info), 0); Checking ./scummvm/scummvm-0.13.1/engines/tinsel/scene.cpp Found memset with swapped arguments. 132:memset(tempStruc, sizeof(SCENE_STRUC), 0); Checking ./aqsis/aqsis-1.6.0/tools/displays/sdcWin32/d_sdcWin32.cpp Found memset with swapped arguments. 250:memset(g_Data, sizeof(AppData), 0); Checking ./aqsis/aqsis-1.6.0/tools/displays/sdcBMP/d_sdcBMP.cpp Found memset with swapped arguments. 172:memset(g_Data, sizeof(AppData), 0); Checking ./arm4/arm4-0.8.2/src/libarm4db/berkeleydb/BerkeleyDB_report.cpp Found memset with swapped arguments. 1603: memset (summary_ptr, sizeof (*summary_ptr), 0); Checking ./arm4/arm4-0.8.2/src/libarm4db/Arm4dbDaemonSharedMemory.cpp Found memset with swapped arguments. 558:memset (stats_ptr, sizeof (*stats_ptr), 0); -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: crazy Xrandr/XOrg automatic display configuration.
On Wed, Nov 25, 2009 at 9:13 AM, Jud Craft craft...@gmail.com wrote: Oh, I misunderstood. Yeah, it should remember the previous configuration you had with this combination of outputs. This information is stored in ~/.config/monitors.xml. Right. I guess what I'm saying is...it doesn't seem to. At this point, wouldn't it be most constructive to reveal what the contents of that file so we all have a baseline expectation as to what should be happening? For example when you get a cloned setup do you see a cloneyes/clone line in that file? And is that ling gone if you get an extended setup? It would be good to see how the monitors.xml file is changing between your cloned versus extended scenarios for that projector hardware. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: crazy Xrandr/XOrg automatic display configuration.
On Wed, 2009-11-25 at 13:13 -0500, Jud Craft wrote: Oh, I misunderstood. Yeah, it should remember the previous configuration you had with this combination of outputs. This information is stored in ~/.config/monitors.xml. Right. I guess what I'm saying is...it doesn't seem to. The very first time I booted my laptop with this (800x600) projector, it defaulted to clone mode in session. I left the room and restarted my laptop. When I returned, plugging the monitor in live resulted in an extended desktop (very cool). I then restarted my laptop and let it boot fresh with the monitor plugged in. The desktop session started in clone mode again. I have a completely-different-in-every-way giant widescreen monitor at home, so I don't think Display Settings is mixing up the external display configurations. Did you read Bastien's suggestion about the BIOS? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: memset bugs.
On Wed, Nov 25, 2009 at 01:43:13PM -0500, Dave Jones wrote: There's some obvious bugs below in a bunch of packages. The 2nd and 3rd arguments to memset calls are the wrong way around. I found these after grepping through a make prep'd devel/ tree. 15 hits out of 100G of source code isn't that bad, but we can do better! glibc headers warn about this (when -D_FORTIFY_SOURCE=2), so a faster way would be just grep through all packages' build.log files (preferrably on the box where they are stored to avoid downloading it all). Jakub -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: crazy Xrandr/XOrg automatic display configuration.
On Wed, 2009-11-25 at 13:13 -0500, Jud Craft wrote: Oh, I misunderstood. Yeah, it should remember the previous configuration you had with this combination of outputs. This information is stored in ~/.config/monitors.xml. Right. I guess what I'm saying is...it doesn't seem to. The very first time I booted my laptop with this (800x600) projector, it defaulted to clone mode in session. I left the room and restarted my laptop. When I returned, plugging the monitor in live resulted in an extended desktop (very cool). I then restarted my laptop and let it boot fresh with the monitor plugged in. The desktop session started in clone mode again. I have a completely-different-in-every-way giant widescreen monitor at home, so I don't think Display Settings is mixing up the external display configurations. https://bugzilla.gnome.org/show_bug.cgi?id=572876 might be related. It has some discussion about ~/.config/monitors.xml.backup. I don't have a multi-monitor setup at hand over the long weekend, so I can't investigate further atm. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: crazy Xrandr/XOrg automatic display configuration.
Please pardon my answering everyone in one email. To Adam: I have not used my BIOS. The Intel 965 card on my Toshiba laptop has no BIOS options. I can't even change the default scaling from full-panel to off. It's really sad. The OS has to do everything in this laptop, since the BIOS doesn't have an option. The Windows drivers had a tool that let me set panel-only, but it only worked after I booted into Windows. Linux has no such driver-management tool as far as I know. To Jeff: Thank you for replying. I tried going through my monitors.xml file, and there is not a single lt;clonegt;yeslt;/clonegt; line. Every config (including for the 800x600 projector) sets clone to no. I tried the projector multiple times in multiple boots last night, so I don't think this was a monitors.xml, specifically after using extended mode and rebooting my laptop, and I still got clone mode. To Matthias: thanks for the tip, but I don't have a monitors.xml.backup file. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: crazy Xrandr/XOrg automatic display configuration.
lt;clonegt;yeslt;/clonegt; line. Every config (including for the 800x600 projector) sets clone to no. Sorry for the bad escape code. I meant there are no cloneyes/clone lines at all. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: crazy Xrandr/XOrg automatic display configuration.
On Wed, Nov 25, 2009 at 10:28 AM, Jud Craft craft...@gmail.com wrote: To Matthias: thanks for the tip, but I don't have a monitors.xml.backup file. From reading the bug... I think if you copy monitors.xml to monitors.xml.backup I think you'll see a difference. From the bug comments it seems monitors.xml isn't being read but if montors.xml.backup exists its always read. Looks like a real upstream bug. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: crazy Xrandr/XOrg automatic display configuration.
On Wed, 2009-11-25 at 14:28 -0500, Jud Craft wrote: Please pardon my answering everyone in one email. To Adam: I have not used my BIOS. The Intel 965 card on my Toshiba laptop has no BIOS options. I can't even change the default scaling from full-panel to off. It's really sad. so, um, you didn't read it, then. =) he simply suggested connecting the external monitor at grub stage rather than having it plugged in at BIOS stage, to see if that made a difference. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: crazy Xrandr/XOrg automatic display configuration.
On Wed, Nov 25, 2009 at 2:37 PM, Adam Williamson wrote: so, um, you didn't read it, then. =) he simply suggested connecting the external monitor at grub stage rather than having it plugged in at BIOS stage, to see if that made a difference. Oh, curses! Right, sorry about that. When I go back to school after thanksgiving I'll try this. On Wed, Nov 25, 2009 at 2:31 PM, Jeff Spaleta wrote: From reading the bug... I think if you copy monitors.xml to monitors.xml.backup I think you'll see a difference. From the bug comments it seems monitors.xml isn't being read but if montors.xml.backup exists its always read. Looks like a real upstream bug. I'll try that. But, that upstream bug looks stalled. I guess if this is the problem, it's the end of the line for now. As I can barely use GCC, let alone GDB. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: review request - rasmol, Molecular Graphics Visualization Tool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 the short version is that at a minimum you should stick an icon with the same name as the binary, extension / file format .png, in /usr/share/icons/hicolor/48x48/apps . That did not work for me, but if I put the converted .png icon in /usr/share/icons it works nicely. ...that sounds like you shouldn't ship a menu entry at all, to me. As you say, it would be rather pointless. But I dunno if there's a policy requirement that you should anyway. It turns out to be trivial to have the desktop file launch the program from within a gnome-terminal Terminal=true which does exactly what I want. Updated spec file at http://www.five-ten-sg.com/rasmol.spec incorporating many changes from Terje Rosten. Thanks! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFLDY2XL6j7milTFsERAvl5AJ9SJ8jnJKREKu+4bTb80M10xyDc0ACfSPBx UesByI6zjfSVUkajqSUMU3I= =p/K6 -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: heads-up: Oracle db-4.8.24 in rawhide
On Tue, 2009-11-24 at 14:44 +0100, Jindrich Novy wrote: Hi, this is a short announce that there is a new db4 in rawhide for a while now. Please modify your package accordingly and consider rebuild. Please *do* rebuild as soon as possible because if something links against your library which is linked to the old db4 and then also links to something is linked to the new db4 then its link-order pot-luck which db4 gets pulled in first and the symbols of the second db4 will be overridden by the first one, so stuff will simply break. i.e. OOo (until today) ends up linked to both db4's due to dependencies to will break on loading a doc from the command line, but not if opened from the menus. C. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: review request - rasmol, Molecular Graphics Visualization Tool
On Wed, 2009-11-25 at 12:04 -0800, Carl Byington wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
the short version is that at a minimum you should stick an icon with
the
same name as the binary, extension / file format .png,
in /usr/share/icons/hicolor/48x48/apps .
That did not work for me, but if I put the converted .png icon in
/usr/share/icons it works nicely.
That's the 'old' system and really shouldn't be used. What you probably
missed is the bit I missed from my original email - when using the new
system you need to add these snippets:
%post
touch --no-create %{_datadir}/icons/hicolor /dev/null || :
%postun
if [ $1 -eq 0 ] ; then
touch --no-create %{_datadir}/icons/hicolor /dev/null
gtk-update-icon-cache %{_datadir}/icons/hicolor /dev/null || :
fi
%posttrans
gtk-update-icon-cache %{_datadir}/icons/hicolor /dev/null || :
to the spec. Otherwise the icon cache doesn't get updated so the icon
won't be available.
...that sounds like you shouldn't ship a menu entry at all, to me. As
you say, it would be rather pointless. But I dunno if there's a policy
requirement that you should anyway.
It turns out to be trivial to have the desktop file launch the program
from within a gnome-terminal
Terminal=true
which does exactly what I want.
ah, I see. I misunderstood you as suggesting that you need to pipe data
to rasmol at startup to make it useful, obviously that's not the case :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: memset bugs.
On Wed, Nov 25, 2009 at 01:58:38PM -0500, Jakub Jelinek wrote: On Wed, Nov 25, 2009 at 01:43:13PM -0500, Dave Jones wrote: There's some obvious bugs below in a bunch of packages. The 2nd and 3rd arguments to memset calls are the wrong way around. I found these after grepping through a make prep'd devel/ tree. 15 hits out of 100G of source code isn't that bad, but we can do better! glibc headers warn about this (when -D_FORTIFY_SOURCE=2), so a faster way would be just grep through all packages' build.log files (preferrably on the box where they are stored to avoid downloading it all). Can we make it fail the build instead of warning ? A zero sized memset is always a bug. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: abrt + X Error = zillions of duplicate bug reports?
On 11/25/2009 09:02 AM, Michal Hlavinka wrote:
On Tuesday 24 November 2009 22:49:53 Matěj Cepl wrote:
Dne 24.11.2009 22:37, Adam Williamson napsal(a):
We came up with several possible courses of action. First, we
acknowledge that abrt team is working on improving duplicate detection,
but Matej noted that this is intrinsically hard work and abrt will
likely never be able to eliminate or even come close to eliminating
duplicate reporting.
What's the technical limitation to coming close here? It seems likely
that there will be some edge cases, but I would think that the majority
of cases aren't all that exceptional, and are fundamentally
straightforward to work out.
Don't ask me, I am just a humble bug triager (putting abrt developer on
CC of this message). What I can say is that even though I can see abrt
devs work hard to eliminate duplicates, they don't succeed much.
Apparently eliminating duplicates of bugs from beasts like Firefox or
OpenOffice is excessively hard.
Afaik, there are several projects with some crash/exception handling on top of
the stack. This makes it more difficult to find out where something actually
crashed. I think solution to this is more plugins/individual configurations.
Something like /etc/abrt/conf.d/package_name.conf
withpackage_name.conf content something like this (of course with better
format ;) :
refuseif()
{
IF backtrace contains adobe flash THEN RefuseReporting(This crash is caused
by proprietary blob, we can't fix it. Try to contact adobe);
ELSE IF
return OK;
}
cropbacktrace()
{
removepackagename's crash handler from top of the backtrace
}
And abrt will call these methods if they are defined.
Just my 2 cents
Something like this is planned for the new dupechecker - it will allow
maintainers or triagers (or anyone) to write simple rules (scripts) to
detect duplicates based on their experiences. It's not possible for us
(ABRT team) to know every single program and write the duplicity checker
for it. Btw, every package maintainer can write his own plugin (it's
really simple) to analyze the stacktrace and detect dupes in his
application as the maintainer knows the code better than we do and knows
what to look for.
Jirka
attachment: jmoskovc.vcf--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: abrt + X Error = zillions of duplicate bug reports?
Dne 25.11.2009 10:20, Karel Klic napsal(a): Good idea. https://bugzilla.redhat.com/show_bug.cgi?id=541442 Matěj -- http://www.ceplovi.cz/matej/, Jabber: mceplatceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC Ask yourself whether you’ve really obtained fullness of the Holy Spirit, follwed by gifts needed for your service. -- Francis MacNutt -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: review request - rasmol, Molecular Graphics Visualization Tool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 2009-11-25 at 12:17 -0800, Adam Williamson wrote: That's the 'old' system and really shouldn't be used. What you probably missed is the bit I missed from my original email - when using the new system you need to add these snippets: Thanks! That works nicely. New spec file at: http://www.five-ten-sg.com/rasmol.spec -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFLDbvJL6j7milTFsERAsDTAJ9i1w8aCeQaC1oH3sng27lFl6kdeQCdFq+y WFaVS7FIu8jFXnO864vaSpc= =TrHD -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
JBoss in Fedora
Is there anybody interested in helping port JPackage's JBoss to Fedora 13: https://fedoraproject.org/wiki/JBoss I understand there is an ongoing work to include JBoss AS 5.1 in JPackage.org. Where can we get this SRPMS to begin porting? Greetings, -- Ricardo Argüello -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: memset bugs.
On 11/25/2009 02:03 PM, Dave Jones wrote:
On Wed, Nov 25, 2009 at 01:58:38PM -0500, Jakub Jelinek wrote:
glibc headers warn about this (when -D_FORTIFY_SOURCE=2), so a faster way
would be just grep through all packages' build.log files (preferrably on
the
box where they are stored to avoid downloading it all).
Can we make it fail the build instead of warning ?
A zero sized memset is always a bug.
No, memset(,,0) is not always a bug. A null region is not automatically a bug.
Here is one example:
struct Foo {
long x;
char hole[8 - sizeof(long)];
} foo;
memset(foo.hole, 0, sizeof(foo.hole));
On a LP64-bit machine such as x86_64, this is memset(foo.hole, 0, 0),
which is *NOT* a bug.
Perhaps the best that can be expected is for the compiler to warn
if _builtin_memset has a third argument which is known to be a compile-time
constant zero. But such a warning must be optional, for there are
legitimate use cases. Also, if the second argument to _builtin_memset
is a compile-time constant which cannot be represented in one byte
(considering both signed and unsigned cases) then another optional warning
may be appropriate.
--
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: memset bugs.
John Reiser jrei...@bitwagon.com writes: On 11/25/2009 02:03 PM, Dave Jones wrote: A zero sized memset is always a bug. No, memset(,,0) is not always a bug. I think it's reasonably safe to assume that a *literal constant* zero in the third argument is a bug. Whether the header macros can distinguish that from compile-time-constant expressions is an interesting question, but if they can, +1 for throwing an error. regards, tom lane -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFC] unified i386/x86_64 install media.
On 11/25/2009 03:39 PM, James Antill wrote: On Wed, 2009-11-25 at 13:18 +0100, Jeroen van Meeuwen wrote: Also, the way I understand this works, you can just include x86_64 packages in the one repository... You can but that will break x86_64, because i386 will need i386 packages that x86_64 must not have as multilib. I understand that, I think, but, if you start out saying you're x86_64, why or how does it ever come to selecting the i?86 version of a package over the x86_64 version of a package? I'm just assuming YUM takes x86_64 over i?86 any time (best match arch or something), unless specifically told otherwise? As Seth said, you can have one giant directory of packages and just different repodata pointing to subsets. Yeah, I know. Sounds perfectly feasible. Yet $me curious. As Jesse said you could also use hardlinks/symlinks in the x86_64 repo. Or you could even create three repos. i386, x86_64 and i386-common (not that I think that will be better than the other two options). And noarch, and noarch! ;-) -- Jeroen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
File Format-Human-Bytes-0.04.tar.gz uploaded to lookaside cache by mmaslano
File Format-Human-Bytes-0.04.tar.gz for package perl-Format-Human-Bytes has been uploaded to the lookaside cache with md5sum d29701e4f1ac0914d11fb10bfbb5350a by mmaslano -- 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
File DBD-SQLite-1.27.tar.gz uploaded to lookaside cache by kasal
File DBD-SQLite-1.27.tar.gz for package perl-DBD-SQLite has been uploaded to the lookaside cache with md5sum aef159ec069efecdb0929126dbf4 by kasal -- 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
rpms/perl-DBD-SQLite/devel .cvsignore, 1.8, 1.9 perl-DBD-SQLite.spec, 1.31, 1.32 sources, 1.8, 1.9
Author: kasal
Update of /cvs/extras/rpms/perl-DBD-SQLite/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv22469
Modified Files:
.cvsignore perl-DBD-SQLite.spec sources
Log Message:
new upstream version
Index: .cvsignore
===
RCS file: /cvs/extras/rpms/perl-DBD-SQLite/devel/.cvsignore,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -p -r1.8 -r1.9
--- .cvsignore 29 May 2009 07:40:48 - 1.8
+++ .cvsignore 25 Nov 2009 11:28:27 - 1.9
@@ -1 +1 @@
-DBD-SQLite-1.25.tar.gz
+DBD-SQLite-1.27.tar.gz
Index: perl-DBD-SQLite.spec
===
RCS file: /cvs/extras/rpms/perl-DBD-SQLite/devel/perl-DBD-SQLite.spec,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -p -r1.31 -r1.32
--- perl-DBD-SQLite.spec12 Sep 2009 04:19:03 - 1.31
+++ perl-DBD-SQLite.spec25 Nov 2009 11:28:27 - 1.32
@@ -1,6 +1,6 @@
Name: perl-DBD-SQLite
-Version:1.25
-Release:4%{?dist}
+Version:1.27
+Release:1%{?dist}
Summary:Self Contained RDBMS in a DBI Driver
Group: Development/Libraries
@@ -33,7 +33,6 @@ DBD::SQLite includes the entire thing in
a fast transaction capable RDBMS working for your perl project you simply have
to install this module, and nothing else.
-As of version 1.09 it can use the external SQLite library (= 3.1.3).
%prep
%setup -q -n DBD-SQLite-%{version}
@@ -46,14 +45,13 @@ make %{?_smp_mflags} OPTIMIZE=$RPM_OPT_
%install
rm -rf $RPM_BUILD_ROOT
make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
-find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
-find $RPM_BUILD_ROOT -type f -name '*.bs' -a -size 0 -exec rm -f {} ';'
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null ';'
+find $RPM_BUILD_ROOT -type f \( -name .packlist -o \
+ -name '*.bs' -size 0 \) -exec rm -f {} ';'
+find $RPM_BUILD_ROOT -depth -type d -empty -exec rmdir {} ';'
%{_fixperms} $RPM_BUILD_ROOT/*
%check
-# These tests are failing on x86_64, FIXME.
make test
@@ -70,6 +68,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Wed Nov 25 2009 Stepan Kasal ska...@redhat.com 1.27-1
+- new upstream version
+
* Fri Sep 11 2009 Chris Weyl cw...@alumni.drew.edu - 1.25-4
- Filtering errant private provides
Index: sources
===
RCS file: /cvs/extras/rpms/perl-DBD-SQLite/devel/sources,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -p -r1.8 -r1.9
--- sources 29 May 2009 07:40:48 - 1.8
+++ sources 25 Nov 2009 11:28:27 - 1.9
@@ -1 +1 @@
-3bc9c8f141cb6c9256ea6dbcddbb9fe7 DBD-SQLite-1.25.tar.gz
+aef159ec069efecdb0929126dbf4 DBD-SQLite-1.27.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 540864] perl-DBD-SQLite-1.27 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=540864 Stepan Kasal ska...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Resolution||RAWHIDE --- Comment #1 from Stepan Kasal ska...@redhat.com 2009-11-25 06:29:28 EDT --- Done. -- 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
rpms/perl-Class-Adapter/devel .cvsignore, 1.2, 1.3 perl-Class-Adapter.spec, 1.3, 1.4 sources, 1.2, 1.3
Author: kasal
Update of /cvs/extras/rpms/perl-Class-Adapter/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv24514
Modified Files:
.cvsignore perl-Class-Adapter.spec sources
Log Message:
- new upstream version
Index: .cvsignore
===
RCS file: /cvs/extras/rpms/perl-Class-Adapter/devel/.cvsignore,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- .cvsignore 4 Nov 2008 07:20:19 - 1.2
+++ .cvsignore 25 Nov 2009 11:39:02 - 1.3
@@ -1 +1 @@
-Class-Adapter-1.05.tar.gz
+Class-Adapter-1.06.tar.gz
Index: perl-Class-Adapter.spec
===
RCS file: /cvs/extras/rpms/perl-Class-Adapter/devel/perl-Class-Adapter.spec,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- perl-Class-Adapter.spec 26 Jul 2009 04:21:03 - 1.3
+++ perl-Class-Adapter.spec 25 Nov 2009 11:39:03 - 1.4
@@ -1,6 +1,6 @@
Name: perl-Class-Adapter
-Version:1.05
-Release:3%{?dist}
+Version:1.06
+Release:1%{?dist}
Summary:Perl implementation of the Adapter Design Pattern
License:GPL+ or Artistic
Group: Development/Libraries
@@ -30,7 +30,7 @@ rm -rf $RPM_BUILD_ROOT
make pure_install PERL_INSTALL_ROOT=$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 \;
+find $RPM_BUILD_ROOT -depth -type d -empty -exec rmdir {} \;
%{_fixperms} $RPM_BUILD_ROOT/*
@@ -47,6 +47,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Wed Nov 25 2009 Stepan Kasal ska...@redhat.com - 1.06-1
+- new upstream version
+
* Sat Jul 25 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.05-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
Index: sources
===
RCS file: /cvs/extras/rpms/perl-Class-Adapter/devel/sources,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- sources 4 Nov 2008 07:20:24 - 1.2
+++ sources 25 Nov 2009 11:39:03 - 1.3
@@ -1 +1 @@
-39b4b06a30b770ae5a7ee42dccdf143e Class-Adapter-1.05.tar.gz
+4387100387da4fdc6c4095b03df1d7c3 Class-Adapter-1.06.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 540862] perl-Class-Adapter-1.06 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=540862 Stepan Kasal ska...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED CC||ska...@redhat.com AssignedTo|mmasl...@redhat.com |ska...@redhat.com Resolution||RAWHIDE --- Comment #1 from Stepan Kasal ska...@redhat.com 2009-11-25 06:51:28 EDT --- Done. -- 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
rpms/perl-Perl-Critic/devel perl-Perl-Critic.spec,1.23,1.24
Author: kasal
Update of /cvs/extras/rpms/perl-Perl-Critic/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv29010
Modified Files:
perl-Perl-Critic.spec
Log Message:
- use the new filtering macros (verified that the resulting provides
and requires are the same)
- add version to perl(PPI) require (#541020)
Index: perl-Perl-Critic.spec
===
RCS file: /cvs/extras/rpms/perl-Perl-Critic/devel/perl-Perl-Critic.spec,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -p -r1.23 -r1.24
--- perl-Perl-Critic.spec 7 Oct 2009 17:00:41 - 1.23
+++ perl-Perl-Critic.spec 25 Nov 2009 13:59:21 - 1.24
@@ -1,6 +1,6 @@
Name: perl-Perl-Critic
Version:1.105
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Critique Perl source code for best-practices
Group: Development/Libraries
@@ -17,10 +17,15 @@ BuildRequires: perl(Config::Tiny) = 2
BuildRequires: perl(File::HomeDir)
BuildRequires: perl(IO::String)
BuildRequires: perl(List::MoreUtils)
+BuildRequires: perl(String::Format) = 1.13
+
BuildRequires: perl(Module::Pluggable) = 3.1
+Requires: perl(Module::Pluggable) = 3.1
BuildRequires: perl(PPI) = 1.205
-BuildRequires: perl(String::Format) = 1.13
+Requires: perl(PPI) = 1.205
BuildRequires: perl(Perl::Tidy)
+Requires(hint): perl(Perl::Tidy)
+
BuildRequires: perl(Test::Memory::Cycle)
BuildRequires: perl(Readonly) = 1.03
BuildRequires: perl(Exception::Class) = 1.23
@@ -36,9 +41,6 @@ BuildRequires: perl(Test::Spelling)
BuildRequires: perl(Test::Pod)
BuildRequires: perl(Test::Pod::Coverage)
-Requires: perl(Module::Pluggable) = 3.1
-Requires(hint): perl(Perl::Tidy)
-
### auto-added brs!
BuildRequires: perl(strict)
BuildRequires: perl(Scalar::Util)
@@ -65,10 +67,8 @@ BuildRequires: perl(Pod::Select)
BuildRequires: perl(English)
# don't provide private Perl libs
-%global _use_internal_dependency_generator 0
-%global __deploop() while read FILE; do /usr/lib/rpm/rpmdeps -%{1} ${FILE};
done | /bin/sort -u
-%global __find_provides /bin/sh -c %{__grep} -v '%_docdir' | %{__grep} -v
'%{perl_vendorarch}/.*\\.so$' | %{__deploop P}
-%global __find_requires /bin/sh -c %{__grep} -v '%_docdir' | %{__deploop R}
+%{?perl_default_filter}
+
%description
Perl::Critic is an extensible framework for creating and applying coding
@@ -119,6 +119,11 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Wed Nov 25 2009 Stepan Kasal ska...@redhat.com - 1.105-2
+- use the new filtering macros (verified that the resulting provides
+ and requires are the same)
+- add version to perl(PPI) require (#541020)
+
* Wed Oct 7 2009 Stepan Kasal ska...@redhat.com - 1.105-1
- new upstream version
- update build requires
--
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 541020] Missing version from dependency on perl-PPI
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=541020 Stepan Kasal ska...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED CC||ska...@redhat.com Resolution||RAWHIDE --- Comment #1 from Stepan Kasal ska...@redhat.com 2009-11-25 09:00:20 EDT --- Fixed in perl-Perl-Critic-1.105-2 -- 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 540340] [patch] Update Finance::Quote to fix ASX quotes
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=540340 --- Comment #5 from Fedora Update System upda...@fedoraproject.org 2009-11-25 10:33:27 EDT --- perl-Finance-Quote-1.17-1.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update perl-Finance-Quote'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-12193 -- 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 519712] flags argument of $pool-refresh() undocumented
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=519712 Subhendu Ghosh sgh...@redhat.com changed: What|Removed |Added QAContact||qe-baseos-secur...@redhat.c ||om -- 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
