Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Sat, 2 Oct 2010 20:56:21 -0400, you wrote: >Fedora is just going to end up having a million repos for all the >software that will not be updated for six months. And that makes us >look silly. Windows doesn't have repositories for users who want the >latest firefox, they just download it and install it. How exactly is the Windows experience different? Windows - explicity download from mozilla (aka repository) and install. Your example Fedora - download from special Firefox repository and install Seems the same to me. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Does anybody know how to contact David Zeuthen (festival maintainer)?
On Sat, 2010-10-02 at 20:45 +0330, Hedayat Vatankhah wrote: > Hi, > Considering the fact that the maintainer is not responsible for a long > time, I'd like to ask if anybody knows how to contact David Zeuthen?! > Festival seems to be unmaintained for more than a year. But it has many > commiters which might decide to become its maintainer. You can reach David by sending him mail (dav...@redhat.com) or finding him on irc (davidz on GimpNet). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Arithmetic coding in Fedora libjpeg (bug #639531)
Björn Persson wrote: > It's well known around the Internet that to achieve compatibility you > should be conservative in what you send and liberal in what you accept. > Applied to JPEG: Use only Huffman coding when encoding – except maybe if > you know that all recipients can handle arithmetic coding – but support > both encodings when decoding. +1 I can see not adding the support to the ENCODING portion, also because that appears to imply an ABI change (extra flag), but the DECODING portion of the patch should be merged. The patch against the original libjpeg libjpeg-turbo is derived from should probably work, it might not be "turbo"-optimized, but given how rare those files are, that shouldn't be a problem. It's still better to be able to decode the files slowly than not at all. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Sat, Oct 02, 2010 at 08:56:21PM -0400, Brandon Lozza wrote: > I'm not a developer at all. I'm a hardened power user and I got sick > and tired of not having the latest version of a particular application > and that led me to Fedora Linux. I'm a quick learner and these > disruptive changes often work out increasing my productivity. I > understand this profile doesn't fit everyone but Fedora will end up > losing the more advanced end users in its effort to grab more of the > less advanced end users who are fearful of change and/or gave up their > pursuit of knowledge. It turns out to be remarkably difficult to develop software for Fedora if a moderate part of the week ends up being spent wondering why something that previously worked no longer works. This isn't about "less advanced end users". It's about providing stability in order to provide an operating system that people can actually use without. > Fedora is just going to end up having a million repos for all the > software that will not be updated for six months. And that makes us > look silly. Windows doesn't have repositories for users who want the > latest firefox, they just download it and install it. No bullshit > required. Software distribution mechanisms are an entirely separate issue from a distribution's (effectively required) update policy. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Arithmetic coding in Fedora libjpeg (bug #639531)
On Sat, Oct 2, 2010 at 1:34 PM, Paul F. Johnson wrote: > Hi, > >> "You shall not create images with arithmetic coding" is like saying "You >> shall not create images of the flying sphagetti monster." It's not up to >> Fedora to make this choice for me. > > It is though - you have chosen to use Fedora therefore have to live with > the decisions the Fedora legal people (I'm assuming they said no to > arithmetic coding) have said goes. The relevant patent expired last year. I believe the SUN OMS team had researched this extensively as they were using the JPEG arithmetic coder in their aggressively researched royalty free video codec design. If someone doing legal research on this needs more information, you can contact me offlist and I can connect you with people who have researched this topic and may be willing to provide some useful pointers. 2010/10/2 Björn Persson : > It's well known around the Internet that to achieve compatibility you should > be conservative in what you send and liberal in what you accept. Applied to > JPEG: Use only Huffman coding when encoding – except maybe if you know that > all > recipients can handle arithmetic coding – but support both encodings when > decoding. Absolutely. This is an excellent argument and I think is sufficient to justify the inclusion alone. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Fri, Oct 1, 2010 at 2:23 PM, Gerald Henriksen wrote: > Look, I realise you are passionate about KDE, and want the best KDE > experience in Fedora. But most people are not developers, they > instead are using their desktop environment of choice to get regular, > everyday things done with office software, web browsers, email, and > sometime even custom software. They want predictability, which means > only having to make changes to how they do things when they are > prepared for the changes, which occurs when they upgrade Fedora. Thus > the best KDE experience you can give them is one of stability, where > KDE helps them do their work instead of being work. I'm not a developer at all. I'm a hardened power user and I got sick and tired of not having the latest version of a particular application and that led me to Fedora Linux. I'm a quick learner and these disruptive changes often work out increasing my productivity. I understand this profile doesn't fit everyone but Fedora will end up losing the more advanced end users in its effort to grab more of the less advanced end users who are fearful of change and/or gave up their pursuit of knowledge. Fedora is just going to end up having a million repos for all the software that will not be updated for six months. And that makes us look silly. Windows doesn't have repositories for users who want the latest firefox, they just download it and install it. No bullshit required. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Does anybody know how to contact David Zeuthen (festival maintainer)?
On Sat, Oct 02, 2010 at 08:45:38PM +0330, Hedayat Vatankhah wrote: > Hi, > Considering the fact that the maintainer is not responsible for a long > time, I'd like to ask if anybody knows how to contact David Zeuthen?! > Festival seems to be unmaintained for more than a year. But it has many > commiters which might decide to become its maintainer. I wish I had time to work on it. :( -- Matthew Miller Senior Systems Architect -- Instructional & Research Computing Services Harvard School of Engineering & Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LibreOffice
On Sat, 2010-10-02 at 15:21 +0100, Paul F. Johnson wrote: > Hi, > > Given the fun which looks to be happening over OOo due to Oracle, are > there any plans to drop OOo and move over to LibreOffice (which looks to > be at version 3.2.999 - pretty much the same as OOo currently is at). > The full release version is penned in for Christmas (or there abouts). > > I have no problems helping package this behemoth! > > TTFN > > Paul I'll say one thing for LibreOffice, there's certainly no shortage of interest in it. Cheers -- Chris Jones PHOTO RESOLUTIONS - Photo - Graphic - Web ABN: 98 317 740 240 E: chrisjo...@comcen.com.au W: http://photoresolutions.freehostia.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need proventester karma for firstboot-1.113-4.fc14 (was: Re: bodhi v0.7.9 deployed)
I think the moral of this story is that the input to the process is fallible. Shit always happens. Automated systems that filter or delay the 'happening' should be backed up by statistics to show that they help... Otherwise, when they filter and delay attempts to fix problems by people who are trying to help, they will just cause frustration. -Cam On Fri, Oct 1, 2010 at 11:56 PM, Matthew Garrett wrote: > On Sat, Oct 02, 2010 at 12:45:14AM +0200, Kevin Kofler wrote: >> Matthew Garrett wrote: >> > "Some packages were pushed to stable before they should have been, >> > therefore we need to make it easier to push packages to stable"? >> >> Yes! Sure, this sounds paradoxical, but my premise is that NO MATTER how >> strict you make the requirement for pushes to stable, there will ALWAYS be >> the possibility that "sh*t happens" and thus a need to be able to rush out >> fixes to stable as quickly as possible. > > And my premise is that we should be making harder for shit to happen, > and the cases where it *does* should be examined carefully to determine > the best way forwards. "Force this untested package into stable" isn't > the best way to do things. > > -- > Matthew Garrett | mj...@srcf.ucam.org > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LibreOffice
On Sat, 2010-10-02 at 22:14 +0530, Ankur Sinha wrote: > On Sat, 2010-10-02 at 15:21 +0100, Paul F. Johnson wrote: > > I have no problems helping package this behemoth! > > +1 : I can help out too. Given that the Fedora OOo maintainer [1] is in the steering committee of the new Document Foundation [2], I wouldn't worry about the move. ;) [1] https://admin.fedoraproject.org/pkgdb/acls/name/openoffice.org [2] http://www.documentfoundation.org/foundation/ -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Arithmetic coding in Fedora libjpeg (bug #639531)
Tom Lane wrote: > I believe that they'd be best advised to say "no", because at this point > one of JPEG's principal attractions is near-universal compatibility. > Throwing A/C into the mix will throw that away, for what really is a > very marginal gain in compression efficiency. It's well known around the Internet that to achieve compatibility you should be conservative in what you send and liberal in what you accept. Applied to JPEG: Use only Huffman coding when encoding – except maybe if you know that all recipients can handle arithmetic coding – but support both encodings when decoding. Björn Persson signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Arithmetic coding in Fedora libjpeg (bug #639531)
Kevin Fenzi writes: > On Sat, 2 Oct 2010 22:53:53 +0530 > Mukund Sivaraman wrote: >> Arithmetic coding in Fedora libjpeg (bug #639531) > My thoughts: > - We should not be making this change in stable releases even if > otherwise like the idea. It could well cause issues and problems with > a fragile library used by a lot of things. Don't worry, there's exactly 0 chance of that. > - In f14+ we are not using libjpeg. We are using libjpeg-turbo. See: > http://fedoraproject.org/wiki/Features/libjpeg-turbo Yes. So actually the OP is pestering the wrong person; he should be trying to convice the libjpeg-turbo maintainers to expend work on this. I believe that they'd be best advised to say "no", because at this point one of JPEG's principal attractions is near-universal compatibility. Throwing A/C into the mix will throw that away, for what really is a very marginal gain in compression efficiency. If you want a new not-compatible-with-anything image format, you may as well adopt JPEG 2000, or some other format that's less than 20 years old. The A/C option to original JPEG is something that missed its chance because of patents. Resurrecting it from the dead now is just an exercise in misplaced priorities. But having said that, it's not my decision to make; it's the libjpeg-turbo authors' decision whether to expend effort in that direction. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Arithmetic coding in Fedora libjpeg (bug #639531)
Peter Lemenkov wrote: > Just for the record, AFAIK there are only two countries which allows > software patents - USA and South Korea. That's not the whole story. The situation is quite weird in countries that have signed the European Patent Convention. The convention and the national laws all state clearly that computer programs are not patentable, and yet software patents are granted on a daily basis, justified with some irrational reasoning that makes sense only to mentally deranged patent lawyers and some gullible politicians. Tens of thousands of these illegal patents have been granted. Several years ago the patent lobby attempted to push through an EU directive to legalize software patents. The directive was eventally dropped after years of massive campaigning for and against, but that only means that the granting of illegal patents continues as before. Such a patent might not hold up in court if it were contested by a good lawyer and the judge had some basic understanding of how computers work, but that doesn't make the patents harmless. Due to the high cost and the uncertain outcome of a patent lawsuit, small companies often have no choice but to pay the license fees. Björn Persson signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Arithmetic coding in Fedora libjpeg (bug #639531)
On Sat, 2 Oct 2010 22:53:53 +0530 Mukund Sivaraman wrote: > Arithmetic coding in Fedora libjpeg (bug #639531) ...snip long thing... My thoughts: - We should not be making this change in stable releases even if otherwise like the idea. It could well cause issues and problems with a fragile library used by a lot of things. - In f14+ we are not using libjpeg. We are using libjpeg-turbo. See: http://fedoraproject.org/wiki/Features/libjpeg-turbo So, any request to enable this support should be filed there and looked at from it's perspective. Do they have support? Does it cause any issues? Does upstream enable it? - For the legal side, make your (new libjpeg-turbo) bug block FE_LEGAL so it can be looked at. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Arithmetic coding in Fedora libjpeg (bug #639531)
Hi, > > Remember, Fedora is not just for use in your country - there are piles > > of countries it's used in, each with their own insane patent > > regulations. The fedora stance is that if it offends, it's out. > > Just for the record, AFAIK there are only two countries which allows > software patents - USA and South Korea. Yep - and it's the US which has some of the more insane ones (and therefore has to be the most careful over). I wonder how long it will be before Apple's current insane one over backing up to a local repository will be allowed to stand - effectively it means you can't burn to a CD! Paul -- Vertraue mir, ich weiss, was ich mache... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Arithmetic coding in Fedora libjpeg (bug #639531)
2010/10/2 Paul F. Johnson : > Remember, Fedora is not just for use in your country - there are piles > of countries it's used in, each with their own insane patent > regulations. The fedora stance is that if it offends, it's out. Just for the record, AFAIK there are only two countries which allows software patents - USA and South Korea. -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Arithmetic coding in Fedora libjpeg (bug #639531)
Hi, > "You shall not create images with arithmetic coding" is like saying "You > shall not create images of the flying sphagetti monster." It's not up to > Fedora to make this choice for me. It is though - you have chosen to use Fedora therefore have to live with the decisions the Fedora legal people (I'm assuming they said no to arithmetic coding) have said goes. Remember, Fedora is not just for use in your country - there are piles of countries it's used in, each with their own insane patent regulations. The fedora stance is that if it offends, it's out. If you want a prime example, look at either DeCSS or mp3 support. Plenty of distros have it, but they're both out of Fedora. Doesn't matter that in the authenticity of the mp3 patent is still in doubt, Fedora plays it safe. rpmfusion may supply DeCSS and mp3 support, but they're not part of Fedora. This may be one avenue to look at - see if rpmfusion can supply an add-on package for this. Paul -- Vertraue mir, ich weiss, was ich mache... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Arithmetic coding in Fedora libjpeg (bug #639531)
Arithmetic coding in Fedora libjpeg (bug #639531) I want libjpeg packages in future Fedora distributions to support reading arithmetic coded JPEG files. Huffman coding and arithmetic are two different bit coding methods that are available in the JPEG standard. Huffman is simpler to implement than arithmetic coding and historically hasn't suffered from software patents. Arithmetic coding (as used in JPEG) had been covered by software patents, but these patents have now apparently expired. [Fedora legal could check this.] The vast majority of JPEG files so far used Huffman coding because of the software patents issue. libjpeg version 7 (one of the forks of the old IJG software) and newer enable support for arithmetic coding by default. With older versions of libjpeg (such as the ones bundled by Fedora up to release 13), support can be added in the form of a patch. No application code modifications are required. (I'm not sure if it's ABI compatible though, but on a re-reading of the libjpeg headers, it might well be.) Arithmetic coding is in every case a superior bit coding method than Huffman, because arithmetic coding doesn't use an integral number of bits to represent codes like Huffman does. So JPEG files created with arithmetic coding are always smaller than those created with Huffman coding. Software such as jpegtran (as distributed with libjpeg 7 and above) can losslessly convert Huffman coded images to arithmetic coded and vice versa. The lossy behavior of JPEG does not happen at this (bit coding) layer of the format. The libjpeg package maintainer seems to be satisfied in closing the bug rather than providing a good rationale for doing so. But I will be the devil's advocate myself. You see, .jpg files are assumed to be an ubiquitous file format. They _just work_ everywhere. If you have a .jpg file, it is understood you aren't going to have problems when using it. But arithmetic coded files do not open everywhere. In fact, they rarely work in most applications, devices, etc. today, because pretty much everyone is using an old libjpeg with no support for it due to the historical software patents issue. As an example, in the context of GIMP creating such files, there were some comments that people would start losing faith in JPEG if they see incompatibilites, that such files are crippled JPEGs [sic], that people who use devices such as digital photo frames will suffer, that I should instead blog about free software and the evils of software patents, that this option should never be available in a dialog to the end-user, etc. * Fedora is not the only software that creates JPEG files. The nearest first implementation of a .jpg file creator program is cjpeg which is a part of libjpeg (the fork at ijg.org), and even that allows creating arithmetic coded files now. It would be arrogance to think that just because Fedora creates these files, the world of JPEG is going to suffer. Or that if Fedora doesn't do it, nobody else would. * The situation with arithmetic coding in the context of incompatibility with existing embedded decoders is just like H.264 and profiles. The iPhone for example does not play all kinds of H.264 files (it supports only the baseline profile). But MPEG content creation software does allow you to create files that use baseline as well as other profiles. It doesn't say "Hey, you the user are pretty stupid, so I'm not just turning this option off, but I'm not making it available to you." It would be arrogance to not provide an option to the end-user, just because I think the user may not know what he/she is doing. * Due to the patents issue, we had to assume that Huffman was the only bit coding method of this standard, whereas it isn't so. Arithmetic coding has been in the standard all these umpteen years, and some people used it. There was always the odd JPEG content that used arithmetic coding and which still complied with the standards. These are not broken JPEGs. Also quoting from the bug: > In any case, there are practical and political reasons not to encourage the > spread of the arithmetic-coding variant of JPEG. It's not compatible with > most > implementations and it doesn't offer enough benefit to be worth creating an > enormous compatibility problem. So even if the code existed I would resist > turning it on. I think the author of libjpeg 8 has made a very serious error > by adding support for it. I have replied on the bug about it. Some of the text in my initial bug description is incorrect, and I have corrected it in this email. It is not upto Fedora to make political decisions when there is no good reason for it. This goes against the values of free software. "You shall not create images with arithmetic coding" is like saying "You shall not create images of the flying sphagetti monster." It's not up to Fedora to make this choice for me. As libjpeg is a shared library on the system, if it can support arithmetic coding, i
Does anybody know how to contact David Zeuthen (festival maintainer)?
Hi, Considering the fact that the maintainer is not responsible for a long time, I'd like to ask if anybody knows how to contact David Zeuthen?! Festival seems to be unmaintained for more than a year. But it has many commiters which might decide to become its maintainer. Thanks, Hedayat On ۱۰/۱۰/۰۲ 08:37, Hedayat Vatankhah wrote: > > > On ۱۰/۱۰/۰۲ 03:55, Chen Lei wrote: >> 2010/10/2 Hedayat Vatankhah: >>> Hi, >>> There has been no response from the maintainer since 2009-06-24 as is >>> clear in [1]. Also, the package has not been updated since then. I >>> wonder what should I do now (?) >>> >>> Thanks, >>> Hedayat >>> >>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=507966 >>> -- >> See >> http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers >> >> Chen Lei > Thanks. > > Well, I've checked pkgdb, and apparently there are many people with > commit access on festival. Also, it seems that David maintains many > packages, so he is probably not completely unresponsive! > I wonder what should be done in this case?! > > Thanks, > Hedayat > > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LibreOffice
On Sat, 2010-10-02 at 15:21 +0100, Paul F. Johnson wrote: > I have no problems helping package this behemoth! +1 : I can help out too. -- Thanks! Regards, Ankur https://fedoraproject.org/wiki/User:Ankursinha "FranciscoD" -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F14 libgdl 2.31.x broken
On Sat, 02 Oct 2010 07:08:56 -0700, Jim wrote: > > https://admin.fedoraproject.org/updates/libgdl-2.31.3-1.fc14 > Anjuta is broken on F14. I don't know if any other apps in the F14 repo > use libgdl. $ repoquery --whatrequires 'libgdl-1.so.3' anjuta-1:2.31.90.0-1.fc14.i686 gnome-python2-gdl-0:2.25.3-23.fc14.i686 gtranslator-0:1.9.11-3.fc14.i686 libgdl-devel-0:2.31.3-1.fc14.i686 solang-0:0.4.1-9.fc14.i686 valide-0:0.6.1-0.22.20103003svn511.fc14.i686 And "repoquery --whatrequires libgdl --alldeps" doesn't add more than libgdl itself. > I'm not familiar with the internal workings of libgdl, > however I use libgdl for a couple of my own applications. I think I can > tell whether or not the problem is my own application. > > The upstream bug report I referenced before includes a response from the > Anjuta/libgdl developer, "Anyway, gdl 2.31.x is broken and gnome-2-32 > will ship gdl 2.30.x.". I'm inclined to trust the upstream developer if > he says his app is broken. Well, not responding to bugzilla tickets, sometimes it's a packager's way to signal "I don't have time for this and would appreciate if somebody else took over". Dunno whether that is the case for libgdl in Fedora though, but given your interest in libgdl, it would make sense to get involved in the Fedora package maintenance somehow. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101002 changes - Broken deps - libmemcached
Le 02/10/2010 14:53, Rawhide Report a écrit : > Broken deps for x86_64 > -- > gearmand-0.13-2.fc14.x86_64 requires libmemcached.so.5()(64bit) > opensips-memcached-1.6.3-2.fc15.x86_64 requires > libmemcached.so.5()(64bit) > php-pecl-memcached-1.0.2-1.fc14.x86_64 requires > libmemcached.so.5()(64bit) > libmemcached-0.44-2.fc15 > > * Sat Oct 02 2010 Remi Collet - 0.44-2 > - enable SASL support > > * Fri Oct 01 2010 Remi Collet - 0.44-1 > - update to 0.44 > - add soname version in %file to detect change I still have issue with with version, so please don't rebuild against 0.44-2 as I will push ASAP a new build (waiting for upstream feedbacks) http://lists.libmemcached.org/pipermail/libmemcached-discuss/2010-October/002207.html http://lists.libmemcached.org/pipermail/libmemcached-discuss/2010-October/002208.html Regards Remi. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-14 Branched report: 20101002 changes
Compose started at Sat Oct 2 13:15:18 UTC 2010 Broken deps for x86_64 -- almanah-0.7.3-3.fc14.x86_64 requires libedataserverui-1.2.so.10()(64bit) antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 evolution-couchdb-0.4.92-1.fc14.x86_64 requires libedata-book-1.2.so.2()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-1.2.so.17()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libgtkhtml-editor.so.0()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libebook-1.2.so.9()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-provider-1.2.so.17()(64bit) frysk-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-devel-0.4-26.fc14.i386 requires libgtkjava-2.8.so frysk-devel-0.4-26.fc14.i386 requires libglibjava-0.2.so frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10 frysk-devel-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-devel-0.4-26.fc14.x86_64 requires libglibjava-0.2.so()(64bit) frysk-devel-0.4-26.fc14.x86_64 requires libgtkjava-2.8.so()(64bit) frysk-gnome-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-gnome-0.4-26.fc14.x86_64 requires libglibjava-0.2.so()(64bit) frysk-gnome-0.4-26.fc14.x86_64 requires libgtkjava-2.8.so()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-gtk-0.4.so.0()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-0.4.so.0()(64bit) intellij-idea-9.0.1.94.399-11.fc14.x86_64 requires jna-examples jana-0.4.5-0.7.20100520gitacd72f2.fc14.i686 requires libedataserverui-1.2.so.10 jana-0.4.5-0.7.20100520gitacd72f2.fc14.x86_64 requires libedataserverui-1.2.so.10()(64bit) libgconf-java-2.12.4-15.fc14.i686 requires libgtkjava-2.8.so libgconf-java-2.12.4-15.fc14.i686 requires libgtkjni-2.8.so libgconf-java-2.12.4-15.fc14.i686 requires libglibjni-0.2.so libgconf-java-2.12.4-15.fc14.i686 requires libglibjava-0.2.so libgconf-java-2.12.4-15.fc14.x86_64 requires libglibjni-0.2.so()(64bit) libgconf-java-2.12.4-15.fc14.x86_64 requires libgtkjni-2.8.so()(64bit) libgconf-java-2.12.4-15.fc14.x86_64 requires libglibjava-0.2.so()(64bit) libgconf-java-2.12.4-15.fc14.x86_64 requires libgtkjava-2.8.so()(64bit) mail-notification-evolution-plugin-5.4-22.fc14.x86_64 requires libcamel-1.2.so.18()(64bit) mail-notification-evolution-plugin-5.4-22.fc14.x86_64 requires libcamel-provider-1.2.so.18()(64bit) mingw32-OpenSceneGraph-2.8.2-4.fc14.noarch requires mingw32(libpng-3.dll) ovirt-server-0.100-4.fc12.noarch requires qpidd ovirt-server-0.100-4.fc12.noarch requires qpidc php-pecl-imagick-3.0.0-7.fc14.x86_64 requires libMagickWand.so.3()(64bit) php-pecl-imagick-3.0.0-7.fc14.x86_64 requires libMagickCore.so.3()(64bit) planner-eds-0.14.4-25.fc14.x86_64 requires libcamel-1.2.so.18()(64bit) planner-eds-0.14.4-25.fc14.x86_64 requires libedata-cal-1.2.so.8()(64bit) planner-eds-0.14.4-25.fc14.x86_64 requires libcamel-provider-1.2.so.18()(64bit) qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit) spacewalk-certs-tools-1.1.1-2.1.fc14.noarch requires spacewalk-backend-libs >= 0:0.8.28 valide-0.6.1-0.22.20103003svn511.fc14.i686 requires libvala.so.0 valide-0.6.1-0.22.20103003svn511.fc14.x86_64 requires libvala.so.0()(64bit) wfut-1.1.0-8.fc12.x86_64 requires libgcj.so.10()(64bit) Broken deps for i386 -- almanah-0.7.3-3.fc14.i686 requires libedataserverui-1.2.so.10 antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 evolution-couchdb-0.4.92-1.fc14.i686 requires libcamel-provider-1.2.so.17 evolution-couchdb-0.4.92-1.fc14.i686 requires libebook-1.2.so.9 evolution-couchdb-0.4.92-1.fc14.i686 requires libgtkhtml-editor.so.0 evolution-couchdb-0.4.92-1.fc14.i686 requires libedata-book-1.2.so.2 evolution-couchdb-0.4.92-1.fc14.i686 requires libcamel-1.2.so.17 frysk-0.4-26.fc14.i386 requires libgcj.so.10 frysk-devel-0.4-26.fc14.i386 requires libgtkjava-2.8.so frysk-devel-0.4-26.fc14.i386 requires libglibjava-0.2.so frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10 frysk-gnome-0.4-26.fc14.i386 requires libgtkjava-2.8.so frysk-gnome-0.4-26.fc14.i386 requires libglibjava-0.2.so frysk-gnome-0.4-26.fc14.i386 requires libgcj.so.10 gpx-viewer-0.1.2-2.fc14.i686 requires libchamplain-gtk-0.4.so.0 gpx-viewer-0.1.2-2.fc14.i686 requires libchamplain-0.4.so.0 intellij-idea-9.0.1.94.399-11.fc14.i686 requires jna-examples jana-0.4.5-0.7.20100520gitacd72f2.fc14.i686 requires libedataserverui-1.2.so.10 libgconf-java
LibreOffice
Hi, Given the fun which looks to be happening over OOo due to Oracle, are there any plans to drop OOo and move over to LibreOffice (which looks to be at version 3.2.999 - pretty much the same as OOo currently is at). The full release version is penned in for Christmas (or there abouts). I have no problems helping package this behemoth! TTFN Paul -- Vertraue mir, ich weiss, was ich mache... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F14 libgdl 2.31.x broken
On Sat, 2010-10-02 at 10:12 +0200, Michael Schwendt wrote: > On Fri, 01 Oct 2010 17:44:05 -0700, Jim wrote: > > > Any application that uses libgdl on F14 segfaults on startup. > > Any? That would mean it would have been easy to test whether the update > works at all, but either it has been marked stable without any testing > or at a time when it worked: > https://admin.fedoraproject.org/updates/libgdl-2.31.3-1.fc14 Yes, any application that uses libgdl segfaults with the same error on my F14 system. This is not limited to software from the F14 repo, but also self compiled applications that worked fine previously on F13. The above version also has the same problem. > > There's a package related RFE in bugzilla which is unanswered since June. > The package is assigned to only one person: > https://admin.fedoraproject.org/pkgdb/acls/name/libgdl > > If a downgrade (with an Epoch bump) is the only way forward, it would > still be good to have the current packager comment on that. Or somebody > who is familiar enough with libgdl and would also show interest in > joining Fedora's group of packagers in order to help with libgdl and > related packages. A downgrade for F14 to 2.30.x, however rawhide(F15) probably needs to move to 2.90.x. Which is the GTK3 branch of libgdl. Anjuta is broken on F14. I don't know if any other apps in the F14 repo use libgdl. I'm not familiar with the internal workings of libgdl, however I use libgdl for a couple of my own applications. I think I can tell whether or not the problem is my own application. The upstream bug report I referenced before includes a response from the Anjuta/libgdl developer, "Anyway, gdl 2.31.x is broken and gnome-2-32 will ship gdl 2.30.x.". I'm inclined to trust the upstream developer if he says his app is broken. Regards, Jim H -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20101002 changes
Compose started at Sat Oct 2 08:15:42 UTC 2010 Broken deps for x86_64 -- almanah-0.7.3-3.fc14.x86_64 requires libedataserverui-1.2.so.10()(64bit) antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 banshee-community-extensions-1.7.4-2.fc15.x86_64 requires mono(Banshee.Widgets) = 0:1.7.0.0 banshee-community-extensions-1.7.4-2.fc15.x86_64 requires mono(Hyena) = 0:1.7.0.0 banshee-community-extensions-1.7.4-2.fc15.x86_64 requires mono(Hyena.Gui) = 0:1.7.0.0 banshee-community-extensions-1.7.4-2.fc15.x86_64 requires mono(Banshee.Services) = 0:1.7.0.0 banshee-community-extensions-1.7.4-2.fc15.x86_64 requires mono(Banshee.NowPlaying) = 0:1.7.0.0 banshee-community-extensions-1.7.4-2.fc15.x86_64 requires mono(Banshee.Core) = 0:1.7.0.0 banshee-community-extensions-1.7.4-2.fc15.x86_64 requires mono(Hyena.Data.Sqlite) = 0:1.7.0.0 banshee-community-extensions-1.7.4-2.fc15.x86_64 requires mono(Banshee.ThickClient) = 0:1.7.0.0 clutter-gst-devel-1.2.0-1.fc15.i686 requires pkgconfig(clutter-1.0) < 0:1.3.0 clutter-gst-devel-1.2.0-1.fc15.x86_64 requires pkgconfig(clutter-1.0) < 0:1.3.0 gambas2-gb-pdf-2.21.0-3.fc15.x86_64 requires libpoppler.so.7()(64bit) gearmand-0.13-2.fc14.x86_64 requires libmemcached.so.5()(64bit) 2:gimp-2.6.10-5.fc15.x86_64 requires libpoppler.so.7()(64bit) 2:gimp-2.6.10-5.fc15.x86_64 requires libpoppler-glib.so.5()(64bit) gloobus-preview-0.4.1-7.fc14.x86_64 requires libpoppler.so.7()(64bit) gloobus-preview-0.4.1-7.fc14.x86_64 requires libpoppler-glib.so.5()(64bit) 1:gnome-games-extra-2.31.91.1-1.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gnome-python2-brasero-2.31.1-7.fc14.x86_64 requires libbrasero-burn.so.1()(64bit) gnome-python2-brasero-2.31.1-7.fc14.x86_64 requires libbrasero-media.so.1()(64bit) gnome-python2-totem-2.31.1-7.fc14.x86_64 requires libgnome-media-profiles.so.0()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-gtk-0.4.so.0()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-0.4.so.0()(64bit) hornsey-1.5.2-0.3.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) inkscape-0.48.0-4.fc15.x86_64 requires libpoppler.so.7()(64bit) inkscape-view-0.48.0-4.fc15.x86_64 requires libpoppler.so.7()(64bit) kdebase-workspace-python-applet-4.5.2-1.fc15.x86_64 requires PyKDE4 >= 0:4.5.2 libextractor-plugins-pdf-0.6.2-1500.fc15.x86_64 requires libpoppler.so.7()(64bit) mingw32-OpenSceneGraph-2.8.2-4.fc14.noarch requires mingw32(libpng-3.dll) moblin-panel-status-0.1.21-5.fc14.x86_64 requires libsocialweb-client.so.1()(64bit) moblin-panel-status-0.1.21-5.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) moblin-panel-status-0.1.21-5.fc14.x86_64 requires libchamplain-0.6.so.0()(64bit) opensips-memcached-1.6.3-2.fc15.x86_64 requires libmemcached.so.5()(64bit) pdf2djvu-0.7.3-4.fc14.x86_64 requires libpoppler.so.7()(64bit) php-pecl-memcached-1.0.2-1.fc14.x86_64 requires libmemcached.so.5()(64bit) pypoppler-0.12.1-4.fc14.x86_64 requires libpoppler.so.7()(64bit) pypoppler-0.12.1-4.fc14.x86_64 requires libpoppler-glib.so.5()(64bit) qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit) referencer-1.1.6-6.fc15.x86_64 requires libpoppler.so.7()(64bit) referencer-1.1.6-6.fc15.x86_64 requires libpoppler-glib.so.5()(64bit) spacewalk-certs-tools-1.1.1-2.1.fc15.noarch requires spacewalk-backend-libs >= 0:0.8.28 totem-2.90.5-5.fc15.i686 requires libpeasui-1.0.so.0 totem-2.90.5-5.fc15.x86_64 requires libpeasui-1.0.so.0()(64bit) tracker-0.8.17-2.fc15.i686 requires libpoppler.so.7 tracker-0.8.17-2.fc15.i686 requires libpoppler-glib.so.5 tracker-0.8.17-2.fc15.x86_64 requires libpoppler-glib.so.5()(64bit) tracker-0.8.17-2.fc15.x86_64 requires libpoppler.so.7()(64bit) xournal-0.4.5-6.fc14.x86_64 requires libpoppler.so.7()(64bit) xournal-0.4.5-6.fc14.x86_64 requires libpoppler-glib.so.5()(64bit) zathura-0.0.8.1-6.fc15.x86_64 requires libpoppler.so.7()(64bit) zathura-0.0.8.1-6.fc15.x86_64 requires libpoppler-glib.so.5()(64bit) Broken deps for i386 -- almanah-0.7.3-3.fc14.i686 requires libedataserverui-1.2.so.10 antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 banshee-community-extensions-1.7.4-2.fc15.i686 requires mono(Banshee.Widgets) = 0:1.7.0.0 banshee-community-extensions-1.7.4-2.fc15.i686 requires mono(Hyena.Gui) = 0:1.7.0.0 banshee-community-extensions-1.7.4-2.fc15.i686 requires mono(Bansh
Re: No response from festival-speechtools maintainer since 2009-6-24
2010/10/2 Hedayat Vatankhah : > Hi, > There has been no response from the maintainer since 2009-06-24 as is > clear in [1]. Also, the package has not been updated since then. I > wonder what should I do now (?) > > Thanks, > Hedayat > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=507966 > -- See http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
No response from festival-speechtools maintainer since 2009-6-24
Hi, There has been no response from the maintainer since 2009-06-24 as is clear in [1]. Also, the package has not been updated since then. I wonder what should I do now (?) Thanks, Hedayat [1] https://bugzilla.redhat.com/show_bug.cgi?id=507966 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: "Command not found" misfeature
On Sat, Oct 02, 2010 at 11:40:50AM +0200, Michael Schwendt wrote: > On Sat, 2 Oct 2010 09:51:31 +0100, Richard wrote: > > > > > F14 seems to have acquired a misfeature where if you mistype a command > > or a command is not found, it prints "Command not found." then pauses > > for some time, then (sometimes, not always) displays some sort of > > error[1]. > > > > How do I permanently disable this behaviour? > > > > Rich. > > > > [1] I think it was a yum or PackageKit error. However I don't get > > that error any longer, just a long pause instead. > > It's the "PackageKit-command-not-found" package. Thanks - removed it. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is this (broken keyboard layouts) a Fedora 14 Blocker bug?!
/*Nicolas Mailhot */ wrote on 10/02/2010 10:12:25 AM +0350: Le samedi 02 octobre 2010 à 01:52 +0330, Hedayat Vatankhah a écrit : In brief, this bug will cause some keyboard layouts to be broken in F14, which IMHO should not go in Fedora 14 Final. I wonder if it can be qualified as a blocker bug. [1] https://bugzilla.redhat.com/show_bug.cgi?id=638244 [2] https://bugs.freedesktop.org/show_bug.cgi?id=30548 [3] https://bugs.freedesktop.org/show_bug.cgi?id=30549 I suppose [4] is the same https://bugzilla.redhat.com/show_bug.cgi?id=617959 Maybe. But in my case, no characters are emitted at all in those cases. I've tried some other layouts and in my tests, any characters defined using its unicode hex code has stopped working. It is even not shown in the gnome's layout preview. Thanks, Hedayat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is this (broken keyboard layouts) a Fedora 14 Blocker bug?!
Hi, /*Parag N(पराग़) */ wrote on 10/02/2010 11:59:03 AM +0350: Hi, On Sat, Oct 2, 2010 at 3:52 AM, Hedayat Vatankhah wrote: �Hi, I've tried testing Fedora 14 Beta (RC3, but updated), and soon I come across this bug[1]. I could discover the initial cause and propose a fix (which, after reporting to freedesktop bugzilla, I found that is already fixed in xkbconfig git (but still should be pushed to F14)). Then, I came across another bug (which is detailed in the end of [1], and is followed at [2] and [3]) which will affect a number of keyboard layouts in F14. In brief, this bug will cause some keyboard layouts to be broken in F14, which IMHO should not go in Fedora 14 Final. I wonder if it can be qualified as a blocker bug. Thanks, Hedayat [1]https://bugzilla.redhat.com/show_bug.cgi?id=638244 [2]https://bugs.freedesktop.org/show_bug.cgi?id=30548 [3]https://bugs.freedesktop.org/show_bug.cgi?id=30549 - I think xkeyboard-config-2.0 has already got some(or all the reported) bugs fixed. I too got some problems in 1.9 build and reported upstream [1]. I am too waiting for 2.0 to be built in F14. Its already built for F15 and working fine. I have sent a mail to xkeyboard-config package owner to build it soon in F14 so that we can have this new build go through bodhi process and reach to stable(GA) repository. Parag. [1]https://bugs.freedesktop.org/show_bug.cgi?id=30233 Thanks for the notice. I've noticed this bug yesterday but I'm not sure if this is the same problem. If you can test 2.0 release, would you please try pressing "d" key after enabling the "ir" layout to see if it prints any characters? (This key is defined using unicode hex characters rather than corresponding character name. But notice that this has been changed in git yesterday, so git source will work. But in 2.0, it is defined using character's unicode hex code). Thanks, Hedayat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Getting more info about updates on headless server
This: > yum install yum-security or possibly this: > ...there is also a changelog plugin/command is what I'm after. I'm going to have a look at those. Thanks James! (Thanks to Przemek and Seth, too - but I want information about all currently-available updates, not just a particular one.) Rich -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: "Command not found" misfeature
On 2 October 2010 09:51, Richard W.M. Jones wrote: > ..., then (sometimes, not always) displays some sort of > error[1]. Yes, it's fixed upstream, apologies. There's a new release on Monday which will be pushed to F14. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: "Command not found" misfeature
On Sat, 2 Oct 2010 09:51:31 +0100 Richard W.M. Jones wrote: > F14 seems to have acquired a misfeature where if you mistype a command > or a command is not found, it prints "Command not found." then pauses > for some time, then (sometimes, not always) displays some sort of > error[1]. > > How do I permanently disable this behaviour? Remove PackageKit-command-not-found. It's not new in F-14. It's been the default since F-12: http://fedoraproject.org/wiki/Features/PackageKitCommandNotFound Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: "Command not found" misfeature
On Sat, 2 Oct 2010 09:51:31 +0100, Richard wrote: > > F14 seems to have acquired a misfeature where if you mistype a command > or a command is not found, it prints "Command not found." then pauses > for some time, then (sometimes, not always) displays some sort of > error[1]. > > How do I permanently disable this behaviour? > > Rich. > > [1] I think it was a yum or PackageKit error. However I don't get > that error any longer, just a long pause instead. It's the "PackageKit-command-not-found" package. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ssh agent issue
On Fri, Oct 01, 2010 at 01:04:40PM -0800, Jeff Spaleta wrote: > On Fri, Oct 1, 2010 at 12:44 PM, Mike McLean wrote: > > https://bugzilla.redhat.com/show_bug.cgi?id=626209 > > Reported against F13, but I've encountered it in F14 Beta. > > > > Seems like more folks ought to be impacted by this bug that seem to > > be, so I wonder what is going on here. Do less folks use ssh-add that > > I imagine, or is some factor limiting this bug? > > I'm not seeing this on my F13 systems and I use ssh all the time. > First I've heard of the problem. > I've commented on the bug report. It looks like a gnome keyring daemon > initilization problem..but not one I'm experiencing and I use ssh in a > terminal every day with agent functionality just fine. Possibly a dupe of: https://bugzilla.redhat.com/show_bug.cgi?id=638637 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firewall settings unworkable
On Sat, Oct 02, 2010 at 02:17:49AM +0200, Dennis J. wrote: [...] I asked Dan Berrange to join this thread since he's most knowledgable about the exact problem and requirements from the libvirt side. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
"Command not found" misfeature
F14 seems to have acquired a misfeature where if you mistype a command or a command is not found, it prints "Command not found." then pauses for some time, then (sometimes, not always) displays some sort of error[1]. How do I permanently disable this behaviour? Rich. [1] I think it was a yum or PackageKit error. However I don't get that error any longer, just a long pause instead. -- Richard Jones, Virtualization Group, Red Hat http://people.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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ssh agent issue
On Fri, 1 Oct 2010, Mike McLean wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=626209 > Reported against F13, but I've encountered it in F14 Beta. > > Seems like more folks ought to be impacted by this bug that seem to > be, so I wonder what is going on here. Do less folks use ssh-add that > I imagine, or is some factor limiting this bug? I saw this issue a couple of days ago, logs saying stuff like: Sep 30 17:15:00 turre gnome-session[8602]: WARNING: Application 'gnome-keyring-pkcs11.desktop' failed to register before timeout Sep 30 17:15:00 turre gnome-session[8602]: WARNING: Application 'gnome-keyring-gpg.desktop' failed to register before timeout Sep 30 17:15:00 turre gnome-session[8602]: WARNING: Application 'gnome-keyring-secrets.desktop' failed to register before timeout Sep 30 17:15:00 turre gnome-session[8602]: WARNING: Application 'gnome-keyring-ssh.desktop' failed to register before timeout Then an update involving various 2.32 versions of gnome packages and a reboot later the problem disappeared, so I just shrugged it off. I seem to recall some components getting updated to 2.32 in an earlier update (when things broke) so /maybe/ it was some gnome 2.31 vs 2.32 component mismatch. Dunno. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is this (broken keyboard layouts) a Fedora 14 Blocker bug?!
Hi, On Sat, Oct 2, 2010 at 3:52 AM, Hedayat Vatankhah wrote: > Hi, > I've tried testing Fedora 14 Beta (RC3, but updated), and soon I come > across this bug[1]. I could discover the initial cause and propose a fix > (which, after reporting to freedesktop bugzilla, I found that is already > fixed in xkbconfig git (but still should be pushed to F14)). Then, I > came across another bug (which is detailed in the end of [1], and is > followed at [2] and [3]) which will affect a number of keyboard layouts > in F14. > In brief, this bug will cause some keyboard layouts to be broken in F14, > which IMHO should not go in Fedora 14 Final. > I wonder if it can be qualified as a blocker bug. > > Thanks, > Hedayat > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=638244 > [2] https://bugs.freedesktop.org/show_bug.cgi?id=30548 > [3] https://bugs.freedesktop.org/show_bug.cgi?id=30549 > - I think xkeyboard-config-2.0 has already got some(or all the reported) bugs fixed. I too got some problems in 1.9 build and reported upstream [1]. I am too waiting for 2.0 to be built in F14. Its already built for F15 and working fine. I have sent a mail to xkeyboard-config package owner to build it soon in F14 so that we can have this new build go through bodhi process and reach to stable(GA) repository. Parag. [1] https://bugs.freedesktop.org/show_bug.cgi?id=30233 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F14 libgdl 2.31.x broken
On Fri, 01 Oct 2010 17:44:05 -0700, Jim wrote: > Any application that uses libgdl on F14 segfaults on startup. Any? That would mean it would have been easy to test whether the update works at all, but either it has been marked stable without any testing or at a time when it worked: https://admin.fedoraproject.org/updates/libgdl-2.31.3-1.fc14 > Quoting from an upstream bug report filed against Anjuta for the same > issue I'm seeing on F14 > > "Anyway, gdl 2.31.x is broken and gnome-2-32 will ship gdl 2.30.x. > > Actually the gdl 2.31.x was superseeded with gdl 2.90.x which will ship > with GNOME 3.0 and uses gtk+-3.0 but won't work with anjuta yet as we > don't use gtk+-3.0. > > So please use gdl 2.30.x for now." > > > I filed a Fedora bug report over two weeks ago, but have had no response > from the Fedora maintainer for libgdl. If someone else has the time, can > we please get this issue fixed. > > Upstream Anjuta bug report I found about the same issue. > https://bugzilla.gnome.org/show_bug.cgi?id=627463 > > Fedora bug I filed against libgdl. > https://bugzilla.redhat.com/show_bug.cgi?id=635333 There's a package related RFE in bugzilla which is unanswered since June. The package is assigned to only one person: https://admin.fedoraproject.org/pkgdb/acls/name/libgdl If a downgrade (with an Epoch bump) is the only way forward, it would still be good to have the current packager comment on that. Or somebody who is familiar enough with libgdl and would also show interest in joining Fedora's group of packagers in order to help with libgdl and related packages. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
