Re: xorg-x11-xkbdata, xkbdata, xkeyboard-config and you
On Mon, Jun 1, 2009 at 11:38 AM, Seth Vidal wrote: > No problem from me- I just don't think we've had requests for this kind of > thing, yet - and we'll need to police it. It maybe one of those things that ends up being requested only after people know its there to be used. Or it might not catch on all. I'm not saying do the integration work with FAS yet, and make it clickity easy for people to track torrents. But maybe have the seedless tracker look into a specific directory in the people spaces for .torrent files to track. Like how the planet picks up your feed info. That might lower the bar enough to make people think about using it for things. For example...If the new version of pitivi that's under development now is as good as the blogs make it out to be. Come F12 we could be shipping a reasonably good video editer tool as part of the distro. A seedless tracker might be a great way to foster a secondary community of raw dv video content like interviews and FAD events and screencasts...with the goal of other people being able to edit it down into usable clips in pitivi and producing theora encoded content of reasonable size. Without putting an initial burden on Fedora infrastructure to make space for all the raw content. torrents may not be good for packages, but its great as a way to spread stupidly large dv video clips. Policing it is another can of worms entirely. I imagine, a simple don't be an ass honor code would apply similar to the cvs commit access. -jef"I'm looking forward to seeing the datamined nuggets richard wants to distributed. He's such a tease."spaleta -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: xorg-x11-xkbdata, xkbdata, xkeyboard-config and you
On Mon, 2009-06-01 at 09:20 -0400, Paul W. Frields wrote: > On Sun, May 31, 2009 at 05:54:21PM +0530, Rahul Sundaram wrote: > > On 05/31/2009 05:48 PM, Alexey Torkhov wrote: > > > On Sun, 2009-05-31 at 17:33 +0530, Rahul Sundaram wrote: > > >> On 05/31/2009 05:24 PM, Alexey Torkhov wrote: > > >>> On Sun, 2009-05-31 at 16:58 +0530, Rahul Sundaram wrote: > > >> > > >>> > > >>> Usage of trademark was granted to Russian Fedora by agreement between > > >>> Red Hat and other company that represent it here, AFAIK. > > >>> Max Spevack was on presentation on Russian Fedora launch. > > >> > > >> I don't see it recorded in > > >> > > >> https://fedoraproject.org/wiki/Trademark_licensees > > >> > > >> It doesn't fit the trademark guidelines either. While Red Hat can > > >> legally grant a license to anyone and doesn't have to abide by the > > >> guidelines, I would expect it to do so nevertheless. So why a special > > >> exception for "Russian Fedora"? > > > > > > I don't know the details of an agreement, ask legal team for that. > > > > I don't need to know the details of the agreement. If any such agreement > > exists, it should follow the trademark guidelines that Fedora set for > > rest of the community and not be given special exceptions. Can the > > Fedora Board look into this? > > I'm already doing so with Max Spevack. There was mentioned in thread in ambassadors list that it should be actually called "Russian Fedora Remix". And it is officially called that. Russian Fedora is just a slang. Sorry for bringing in incorrect information. But they still use slightly modified fedora-logos package. Could you clarify logo guidelines about that package. Is it possible to use it unmodified in remix? Or all fedora logos should be replaced with fedora remix logos? Using generic-logos package would not be solution here, as, I’m sure, they will want to leave as much fedora branding as possible, without striping all logos. Alexey -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: xorg-x11-xkbdata, xkbdata, xkeyboard-config and you
Mike A. Harris wrote: > Mike A. Harris wrote: >> This should resolve various keyboard quirks that have been reported >> in different components throughout FC5 testing, but may introduce >> a few new bugs too. Overall, since it is the only maintained >> xkbdata however, even if there are a few bumps, they'll be ironed >> out via modular package updates easily enough, unlike the situation >> we'd have if we shipped the X.Org xkbdata and let it rot. >> >> Hope your keyboards all do the happy dance now. > > Update: > > Some backward compatible options were disabled in the > xorg-x11-xkbdata-1.0.1-5 build which contains xkeyboard-config. > > This has caused some problems for various users, and has been > fixed in the 1.0.1-6 release. If you are experiencing any problems > with the 1.0.1-5 release, before filing a bug report in bugzilla, > please update to the -6 release, which can be found at: > > xorg-x11-xkbdata-1.0.1-6 is now available for download via ftp at the > following URL: ftp://people.redhat.com/mharris/testing/unstable > > After updating to -6, and restarting X, if you still have problems, > please search bugzilla to see if it has been reported already or not > (we get a lot of dupes for things like this, please help to limit > them), and if nobody's reported it yet, please file a new bug and > we'll go from there. > > Thanks again to all the people testing FC5 development! > > Thanks! That fixed no keyboard layouts showing up in kde control panel.
beagle backup (user_xattr)
How can we backup beagle data, including user_xattr? What happens if we don't restore user_xattr correctly? Will beagle re-create it?
Re: beagle backup (user_xattr)
Matthias Clasen wrote: > On Tue, 2006-03-07 at 10:59 -0500, Neal Becker wrote: >> How can we backup beagle data, including user_xattr? >> >> What happens if we don't restore user_xattr correctly? Will beagle >> re-create it? >> > > Beagle does not use extended attributes in FC5 (at least not by > default), it uses sqlite. So there should be no problem. > > Is this documented? How can I tell? If I look at beagle docs on the web, it tells me I really should mount with user_xattr, and that beagle will auto-detect this at runtime.
Re: rawhide report: 20060309 changes
same here
NM + caching-nameserver?
Is NM compatible with a local caching nameserver? It looks like the default NM setup is to set resolv.conf from dhcp. If I want to cache results locally, how can I do this?
python module loading broken on fedora?
I've been trying to track down a problem with python module loading for multarch (x86_64). I think we have a problem. The discussion so far is archived here: http://mail.python.org/pipermail/python-dev/2006-March/062462.html It seems that the system Fedora has setup here: http://fedoraproject.org/wiki/Packaging/Python is not really correct.
Re: Fedora LaTeX SIG?
Nicolas Mailhot wrote: > > > Le Jeu 11 juin 2009 16:47, Jonathan Underwood a écrit : >> >> 2009/6/11 Jussi Lehtola : > >>> Would anyone be interested in creating/joining a LaTeX SIG? >> >> Count me in. > > As I wrote before, people willing to improve TEX in Fedora are welcome > to use the Fonts SIG infrastructure (mailing lists, etc). The Fonts > SIG is a "text-related bits" SIG in practice anyway. > > There is a lot of stuff that needs to be fixed in Fedora TEX, not just > the LaTeX parts. > I'm interested. Migration to texlive was discussed here before. Died after nobody wanted to try to inspect licences of all the packages, IIRC. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
bodhi error
bodhi -C igraph-0.5.2-1.fc9 dist-f9-updates-candidate qct-1.7-3.fc9dist-f9-updates-candidate python-igraph-0.5.1-3.fc9dist-f9-updates-candidate libotf-0.9.8-1.fc9 dist-f9-updates-candidate igraph-0.5.2-1.fc10 dist-f10-updates-candidate qct-1.7-3.fc10 dist-f10-updates-candidate Traceback (most recent call last): File "/usr/bin/bodhi", line 322, in main() File "/usr/bin/bodhi", line 230, in main for build in bodhi.candidates(): File "/usr/lib/python2.6/site-packages/fedora/client/bodhi.py", line 193, in candidates for build in self.koji_session.listTagged(tag, latest=True): File "/usr/lib/python2.6/site-packages/koji/__init__.py", line 1255, in __call__ return self.__func(self.__name,args,opts) File "/usr/lib/python2.6/site-packages/koji/__init__.py", line 1501, in _callMethod raise err koji.GenericError: No such entry in table tag: dist-4E-epel-updates- candidate -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Brainstorming Session for Fedora Community 2.0 - Monday August 3, 2009 - 1500 UTC
The link https://admin.fedoraproject.org/community doesn't seem to work with konqueror. Just says 'loading' and nothing happens. Works in firefox. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Trouble with F11 build
Built on devel OK. Then I try to build for F11 and get http://koji.fedoraproject.org/koji/taskinfo?taskID=1575532 Complains about error: Bad source: /builddir/build/SOURCES/filelight_part.desktop.diff: No such file or directory But cvs says: File: filelight_part.desktop.diff Status: Up-to-date Working revision:1.1 Repository revision: 1.1 /cvs/pkgs/rpms/filelight/F-11/filelight_part.desktop.diff,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
sage idea
Not much progress has been made on sage. Perhaps this can help: http://code.google.com/p/spdproject/wiki/Installation -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: another spin of TeX Live 2009 packages
Error: Missing Dependency: tetex-fonts is needed by package a2ps-4.14-8.fc11.x86_64 (installed) Error: Missing Dependency: tetex >= 3.0 is needed by package jadetex-3.13-5.fc11.noarch (installed) Error: Missing Dependency: tetex is needed by package texinfo- tex-4.13a-2.fc11.x86_64 (installed) Error: Missing Dependency: libkpathsea.so.4()(64bit) is needed by package evince-dvi-2.26.2-1.fc11.x86_64 (installed) Suggestions? Jindrich Novy wrote: > Hi, > > first off, thanks many people who sent me RFE and bugfix > proposals. I've tried to fix most of them in the current package set > in the testing repository: > > rpm -i > http://jnovy.fedorapeople.org/texlive/texlive- release-2009-0.1.fc11.noarch.rpm > > If you use the older TeX Live 2009 packages, please reinstall them > completely: > > yum remove texlive > (and to be sure rm -rf /usr/share/texlive, due to ordering it could > leave some directories there) > yum clean all > yum install texlive > > The reason for it is the following list of improvements: > - binary packages do no more have the '.ARCH' postfix, the postfix > changed to '-bin' > - new font support add new 'fedora-fonts' packages which allows you to > use TeX Live 2009 fonts (TrueType and OpenType for now) in Fedora > - packages for TeX Live t1utils and psutils are no more built but > dependencies to existing utilities in Fedora are added > - kpathsea packages should now be correctly obsoleted. The > lcdf-typetools dep errors you might see installing > texlive-collection-fontutils is caused by the fact that > lcdf-typetools in Fedora is linked against kpathsea libraries and > TeX Live 2009 increases the soname so lcdf-typetools will work after > rebuilt with the new kpathsea > - fixed texlive-xetex conflict with older TL2007 packages > - added older tetex-latex, etc. provides for compatibility (you are > now able to install TL2009 together with R analysis package, etc.) > - new packages should automatically clear /var/lib/texmf in %post > scriptlets to avoid format incompatibilities > > I haven't added obsoletes to .ARCH packages to keep spes files > readable and because TL2009 packages are not yet imported. > > The spec format should be final now. Only some font formats can be > added or the Fedora font support updated for a bit. > > I will announce next repo updates here: > http://fedoraproject.org/wiki/Talk:Features/TeXLive > > Thanks, > Jindrich > -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Dragonfly Mail Agent
Michel S. wrote: > Hi all, > > With the recent discussion about removing sendmail from the base > install, has anyone taken a look at DMA? It appears to be designed with > exactly the same purpose in mind -- removing the dependency on a > desktop-oriented install on sendmail or postfix, while still allowing > cron et. al. to function fully. > > Perhaps not for F-12, but if we start looking at it now, it might be > well-tested enough to be considered for the next (or second next) > release afterwards. > > -- > Michel, wondering what F-12+1 will be numbered as! > > Sent to you by Michel S. via Google Reader: DMA updates via DragonFly > BSD Digest by Justin Sherrill on 8/29/09 > > DMA, the DragonFly Mail Agent, has been updated so that it can deliver > email from cron job output. DMA is a former Summer of Code project to > make a local-only mailer for DragonFly systems, so that larger mail > transfer agents (like Sendmail or Postfix) are not needed on a system > that isn’t designed to receive mail from external sources. There’s a > TODO list (click the gitweb link) if you’d like to contribute. > > Things you can do from here: > - Subscribe to DragonFly BSD Digest using Google Reader > - Get started using Google Reader to easily keep up with all your > favorite sites We already have ssmtp, esmtp. Is this something different? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: another spin of TeX Live 2009 packages
Jonathan Underwood wrote: > 2009/8/31 Patrice Dumas : >> Hello, >> >> I haven't followed closely the new packaging of texlive, so you should >> take my comments with caution... >> >> On Mon, Aug 31, 2009 at 01:15:21PM +0200, Jindrich Novy wrote: >>> >>> The new packages obsolete the ancient tetex stuff: >>> tetex-tex4ht >> >> I think that the stand-alone tex4ht could be better than the texlive one. >> It was updated many time a year in the past (but it may change). >> >>> tetex-elvevier >> >> In the past, the version in CTAN of this package used to lag a lot. I'd >> still advise taking the files from the web, especially since there is >> also the old style in the stand-alone package. >> >>> and these utilities: >>> dvipdfm >>> dvipdfmx >>> dvipng >>> xdvi >>> xdvipdfmx >> >> Haven't some of those an upstream different from texlive? > > They do - however I lean towards using ones that come from texlive > though, so we benefit from the integration work the TeXLive developers > do. Once we start down the road of packaging everything with another > upstream separately we get closer to basically developing out own TeX > distribution, and we don't have the manpower to do that. A purest > approach wouldn't consume the class files and packages from TeXLive > either, but would rather take the .dtx files etc from ctan. Clearly > this would be crazy. I think it's fair to regard TeXLive as upstream - > in most cases the other upstreams are more like development sandboxes. > > Jonathan (who presently maintains or comaintains most of those > packages at the mo). > IIRC xdvipdfmx is from texlive (but has not been updated for some time) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Possible package...
Nathanael D. Noblet wrote: > Hello everyone, >I've been looking at becoming a packager. I've yet to find software I > need that isn't in fedora yet. I just found one I think. > > http://code.google.com/p/wkhtmltopdf/ > > It is based off of qt4 and webkit. Small source files, cmake build > system. I can't find it in the repos anywhere. Would this be a good > first package? I'll be using this for a couple of projects to convert > html to pdf with much less hassle than ever before. > > Thoughts? > I wouldn't start by finding just any project to try your hand at packaging. Packaging requires some level of continuing commitment to support. I wouldn't do that unless you feel some personal desire to support that package. Instead, find something you are really interested in. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
conflict between libotf and openmpi
It seems both openmpi and libotf supply a %{_bindir}/otfdump. otf is
either:
OpenTypeFont (libotf)
or
OpenTraceFormat (openmpi)
I maintain libotf. I'm not sure how to address this.
My only interest in libotf is so emacs can use it. For that, it doesn't
need the binaries. Perhaps they could be put somewhere else?
I don't know how important otfdump is to openmpi, since I don't use it. My
guess is that in both libotf and openmpi, neither is critical to function,
but is a debug aid.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: conflict between libotf and openmpi
Jon Ciesla wrote:
> Neal Becker wrote:
>> It seems both openmpi and libotf supply a %{_bindir}/otfdump. otf is
>> either:
>>
>> OpenTypeFont (libotf)
>> or
>> OpenTraceFormat (openmpi)
>>
>> I maintain libotf. I'm not sure how to address this.
>>
>> My only interest in libotf is so emacs can use it. For that, it doesn't
>> need the binaries. Perhaps they could be put somewhere else?
>>
>> I don't know how important otfdump is to openmpi, since I don't use it.
>> My guess is that in both libotf and openmpi, neither is critical to
>> function, but is a debug aid.
>>
>>
> Are they the same? If so, my gut would be to use the one in libotf, if
> it's complete, maybe in a subpackage, and have openmpi remove it's own
> and Require it, sort of the way we handle bundled libraries.
>
> -J
>
They have nothing in common, just unfortunately the same name.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: conflict between libotf and openmpi
Which makes me wonder, how could this conflict have been avoided? Is there a tool that would check any new package to see if any object* in it would conflict with any existing package? If not, sounds like a good thing to have. * Here, object means filesystem object. I'm not sure if there are any other types of objects to worry about. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Script to detect conflicting files in PATH within a yum repo (was Re: conflict between libotf and openmpi)
Why not report all conflicts, instead of only those on your PATH? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Script to detect conflicting files in PATH within a yum repo (was Re: conflict between libotf and openmpi)
Jesse Keating wrote: > On Wed, 2009-09-16 at 20:08 -0400, Neal Becker wrote: >> Why not report all conflicts, instead of only those on your PATH? > > Because these aren't file level conflicts, as in they can both exist on > the filesystem at the same time and RPM won't care. However they can > lead to unexpected things due to PATH collision, if you type "foo" and > there are multiple "foo"'s in your path, are you sure you know which one > you'll get? > But the original problem was a file level conflict. Is it ever valid for 2 packages to own the same file? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Emacs package for Fedora 12
Sounds great, but unless gdb7 is already in rawhide, I'd guess it won't be released with F12. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: does fedora have anything requiring :mail rw access?
Michal Hlavinka wrote: > On Friday 09 October 2009 15:31:45 Michal Hlavinka wrote: > >> The most important question is: Is there anything that requires these >> files >> can be read and written by mail group? > > Well, I already know one, cyrus-imapd most probably requires mail rw. Is > there anything else? > The default exim config says: # This transport is used for local delivery to user mailboxes in traditional # BSD mailbox format. By default it will be run under the uid and gid of the # local user, and requires the sticky bit to be set on the /var/mail directory. # Some systems use the alternative approach of running mail deliveries under a # particular group instead of using the sticky bit. The commented options below # show how this can be done. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: does fedora have anything requiring :mail rw access?
Neal Becker wrote: > Michal Hlavinka wrote: > >> On Friday 09 October 2009 15:31:45 Michal Hlavinka wrote: >> >>> The most important question is: Is there anything that requires these >>> files >>> can be read and written by mail group? >> >> Well, I already know one, cyrus-imapd most probably requires mail rw. Is >> there anything else? >> > > The default exim config says: > > # This transport is used for local delivery to user mailboxes in > # traditional BSD mailbox format. By default it will be run under the uid > # and gid of the local user, and requires the sticky bit to be set on the > # /var/mail > directory. > # Some systems use the alternative approach of running mail deliveries > # under > a > # particular group instead of using the sticky bit. The commented options > below > # show how this can be done. > > I should have been clearer- the default exim config used the mail group method: local_delivery: driver = appendfile file = /var/mail/$local_part delivery_date_add envelope_to_add return_path_add group = mail mode = 0660 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Howto handle multilib conflict?
Just received: https://bugzilla.redhat.com/show_bug.cgi?id=528237 yum install libotf-devel.i586 libotf-devel.x86_64 yields: Transaction Check Error: file /usr/bin/libotf-config from install of libotf-devel-0.9.8-2.fc11.i586 conflicts with file from package libotf-devel-0.9.8-2.fc11.x86_64 file /usr/share/doc/libotf-devel-0.9.8/example/Makefile from install of libotf-devel-0.9.8-2.fc11.i586 conflicts with file from package libotf-devel-0.9.8-2.fc11.x86_64 What is the recommended way to resolve this? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Howto handle multilib conflict?
Jesse Keating wrote: > On Fri, 2009-10-09 at 16:13 -0700, Adam Williamson wrote: >> On Fri, 2009-10-09 at 18:56 -0400, Neal Becker wrote: >> > Just received: >> > https://bugzilla.redhat.com/show_bug.cgi?id=528237 >> > >> > yum install libotf-devel.i586 libotf-devel.x86_64 >> > >> > yields: >> > >> > Transaction Check Error: >> > file /usr/bin/libotf-config from install of >> > libotf-devel-0.9.8-2.fc11.i586 >> > conflicts with file from package libotf-devel-0.9.8-2.fc11.x86_64 >> > file /usr/share/doc/libotf-devel-0.9.8/example/Makefile from install >> > of >> > libotf-devel-0.9.8-2.fc11.i586 conflicts with file from package >> > libotf-devel-0.9.8-2.fc11.x86_64 >> > >> > What is the recommended way to resolve this? >> >> It's not to be considered a bug, AFAIK. We don't stipulate that >> development packages be installable side-by-side in this way, we only >> stipulate that for library packages where there's a need for it. There's >> no particular use case where you absolutely need both -devel packages >> installed at once. >> >> -- >> Adam Williamson >> Fedora QA Community Monkey >> IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org >> http://www.happyassassin.net >> > > Actually this is a bug. If the packages are offered in the same repo, > they should install together (barring explicit conflicts listed in the > spec file). Looks like the example makefile may be generated at build > time, or touched in someway so that it is different when on i686 and > x86_64. That should not happen, they should be the same. > Both /usr/bin/libotf-config and example/Makefile are autoconf-generated. Suggestions? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Howto handle multilib conflict?
Adam Williamson wrote: > On Fri, 2009-10-09 at 16:41 -0700, Toshio Kuratomi wrote: > >> > It's not to be considered a bug, AFAIK. We don't stipulate that >> > development packages be installable side-by-side in this way, we only >> > stipulate that for library packages where there's a need for it. >> > There's no particular use case where you absolutely need both -devel >> > packages installed at once. >> > >> I believe this is incorrect. devel packages are supposed to be multilib >> installable. There's two things that are two files that conflict above >> and there's two different fixes for each. > > I'm happy to be wrong :), but is this documented anywhere? That's why I > thought the opposite was the case, I couldn't find anything to this > effect in the packaging documentation when I was starting out. > > It seems like a lot of work for very little return if it is our policy, > especially fiddling around with *-config and the like executables, which > are far from uncommon...what's the use case for multilib -devel > packages? When is it actually useful to have both arches installed at > once for a -devel package? > Fortunately, it seems that this particular case (2 file conflicts) was pretty easy to fix (just remove the offending files). Looking at emacs-23.1, it appears to be using pkgconfig, and libotf already was installing a proper libotf.pc. I'm hoping /usr/bin/libotf-config isn't essential. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Howto handle multilib conflict?
I received the following from upstream. Anyone know the answer to the question (how do freetype-config, etc workaround this issue?) In article <200910092117.36851.ndbeck...@gmail.com>, Neal Becker writes: > I maintain libotf for Fedora. Thank you very much for that work! > We have received a bug report of a multilib > conflict, which occurs when installing development packages for both i586 and > x86_64. The problem is /usr/bin/libotf-config, which occurs in both packages > but is not identical. > My solution is to remove this file. I'm hoping it's not really needed. > libotf already has package-config support (which is multilib compatible > already), so if all apps use package-config there should be no problem. > Are there any apps that need /usr/bin/libotf-config to your knowledge? As far as I know, there's none. So, it's ok to remove libotf-config. But, why does libotf-config don't work with multilib? How do the other XXX-config programs (e.g. freetype-config, fribidi-config, gtk-config, ...) work with multilib? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Major reorganization of TeX Live packages
Jindrich Novy wrote: > Hi, > > I would like to announce couple of major changes in the TeX Live 2009 > repository. > Where? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Major reorganization of TeX Live packages
On F11 I get: kpathsea-2007-42.fc11.x86_64 from installed has depsolving problems --> Missing Dependency: texlive = 2007-42.fc11 is needed by package kpathsea-2007-42.fc11.x86_64 (installed) Error: Missing Dependency: texlive = 2007-42.fc11 is needed by package kpathsea-2007-42.fc11.x86_64 (installed) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Major reorganization of TeX Live packages
xelatex issue? I don't know much about xelatex, so maybe user error, but: xelatex python-intro.tex . warning: Configuration file texmf.cnf not found! Searched these directories: /usr/bin:/usr:/:/usr/bin/share/texmf-local/web2c:/usr/share/texmf- local/web2c://share/texmf-local/web2c:/usr/bin/texmf-local/web2c:/usr/texmf- local/web2c://texmf- local/web2c:/etc/texmf/web2c:/usr/local/share/texmf/web2c:/usr/share/texmf/web2c:/usr/share/texmf/web2c Trying to proceed... [2] [3] (./python-intro.aux) Output file removed. Why is it looking everywhere except the right place? I tried removing all .aux, .toc, etc. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
texlive 2009 - should set TEXMFCNF?
I wonder if texlive should include a /etc/profile.d package to set TEXMFCNF, so that other packages, such as xdvipdfmx will work? Or, should texlive just obsolete xdvipdfmx and include it's own version? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: texlive 2009 - should set TEXMFCNF?
Jindrich Novy wrote: > On Sun, Oct 25, 2009 at 03:05:34PM -0400, Neal Becker wrote: >> I wonder if texlive should include a /etc/profile.d package to set >> TEXMFCNF, >> so that other packages, such as xdvipdfmx will work? Or, should texlive >> just obsolete xdvipdfmx and include it's own version? > > I will try to fix it in the texmf.cnf kpathsea configuration file > directly in the new TL2009 update. > > Jindrich > Could you explain? Will you replace the current xdvipdfmx? The current will use kpathsea and will look for config in /usr/share/texmf. I was thinking either: 1) Replace the current xdvipdfmx with the one shipped with texlive or 2) Use /etc/profile.d to set TEXMFCNF -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: texlive 2009 - should set TEXMFCNF?
Jindrich Novy wrote: > On Tue, Oct 27, 2009 at 11:59:30AM -0400, Neal Becker wrote: >> Jindrich Novy wrote: >> >> > On Sun, Oct 25, 2009 at 03:05:34PM -0400, Neal Becker wrote: >> >> I wonder if texlive should include a /etc/profile.d package to set >> >> TEXMFCNF, >> >> so that other packages, such as xdvipdfmx will work? Or, should >> >> texlive just obsolete xdvipdfmx and include it's own version? >> > >> > I will try to fix it in the texmf.cnf kpathsea configuration file >> > directly in the new TL2009 update. >> > >> > Jindrich >> > >> Could you explain? > > The plan was to update the texmf.cnf to tell kpathsea to look for > files in the /usr/share/texmf tree prior to the main TL2009 tree. This > should make the utilities like xdvipdfmx work even though they are > linked against old kpathsea and expects configuration bits in > /usr/share/texmf. > >> Will you replace the current xdvipdfmx? > > Currently I'm trying to not to replace any package that has a separate > upstream and is already packaged separatelly in Fedora. > > Jindrich > I am maintainer for xdvipdfmx and would be perfectly happy if you adopt it. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: texlive 2009 - should set TEXMFCNF?
Neal Becker wrote: > Jindrich Novy wrote: > >> On Tue, Oct 27, 2009 at 11:59:30AM -0400, Neal Becker wrote: >>> Jindrich Novy wrote: >>> >>> > On Sun, Oct 25, 2009 at 03:05:34PM -0400, Neal Becker wrote: >>> >> I wonder if texlive should include a /etc/profile.d package to set >>> >> TEXMFCNF, >>> >> so that other packages, such as xdvipdfmx will work? Or, should >>> >> texlive just obsolete xdvipdfmx and include it's own version? >>> > >>> > I will try to fix it in the texmf.cnf kpathsea configuration file >>> > directly in the new TL2009 update. >>> > >>> > Jindrich >>> > >>> Could you explain? >> >> The plan was to update the texmf.cnf to tell kpathsea to look for >> files in the /usr/share/texmf tree prior to the main TL2009 tree. This >> should make the utilities like xdvipdfmx work even though they are >> linked against old kpathsea and expects configuration bits in >> /usr/share/texmf. >> >>> Will you replace the current xdvipdfmx? >> >> Currently I'm trying to not to replace any package that has a separate >> upstream and is already packaged separatelly in Fedora. >> >> Jindrich >> > I am maintainer for xdvipdfmx and would be perfectly happy if you adopt > it. > s/adopt/obsolete -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
texlive-2009 man & info
I'm trying texlive-2009 packages for f11. I see man and info pages get installed (not in standard system locations, but into texlive tree), but man and info search paths don't seem to be setup to find them. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
texlive-2009 breakage?
I had texlive* installed. After today's update, I no longer have any /usr/share/texlive directory! I'm guessing some install script removed it?? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
texlive-2009 tlmgr
tlmgr Can't locate TeXLive/TLPOBJ.pm in @INC (@INC contains: /usr/share/texlive/tlpkg /usr/local/lib64/perl5/site_perl/5.10.0/x86_64- linux-thread-multi /usr/local/lib/perl5/site_perl/5.10.0 /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl /usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi /usr/lib/perl5/5.10.0 /usr/lib/perl5/site_perl .) at /usr/bin/tlmgr line 36. BEGIN failed--compilation aborted at /usr/bin/tlmgr line 36. sure enough, /usr/share/texlive/tlpkg dir exists, but is empty. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCO ticket#270 - preupgrade and F-12
James Laska wrote: > On Thu, 2009-11-12 at 13:00 -0700, Linuxguy123 wrote: >> On Thu, 2009-11-12 at 14:56 -0500, James Laska wrote: >> > Greetings folks, >> > >> > After careful review by Will Woods around recently discovered problems >> > related to preupgrading to Fedora 12, I've filed ticket#270 >> > (https://fedorahosted.org/fesco/ticket/270) for discussion at the next >> > FESCO meeting. Please take a moment to read the details in the ticket. >> > >> > The high-level summary from Will ... >> > >> > preupgrade to F12 is basically not going to work for anyone >> > without significant manual workarounds, due to insufficient >> > disk space on /boot. >> >> How much disk space will one require on /boot to perform the update >> without work arounds ? > > From the ticket (see URL above). > > Here's the details. > The default /boot partition is 200MB, but there's some overhead: > Ext3/Ext4 overhead: 7MB > Reserved space: 10MB > F11 kernel: 8MB (at least - usually 3 kernels = 24MB) > GRUB/EFI files: 1MB > Total overhead: 26MB > > So there's 174MB of usable space maximum, and usually 158MB > available. > > preupgrade now requires at least 167MB free space on /boot: > F12 installer images: 143MB (8mb larger than F11!) > F12 kernel: 18MB (10mb larger than F11!) > RPM/anaconda tmpfiles: >=8MB (measured in stupid tests) > Total: 167MB (Was 149MB in F11 - no problem!) > >> Can gparted resize /boot ? > > There are definitely workarounds available, but none that meet the > criteria for preupgrade as an effortless upgrade option. > > Thanks, > James What if I have already a large /boot? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
texlive2009 f11 broken by today's update
Was working, but after today's update: pdflatex pll_freq_ramp.tex This is pdfTeX, Version 3.1415926-1.40.10 (Web2C 2009) kpathsea: Running mktexfmt pdflatex.fmt I can't find the format file `pdflatex.fmt'! -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: texlive2009 f11 broken by today's update
José Matos wrote: > On Friday 13 November 2009 00:38:21 Neal Becker wrote: >> Was working, but after today's update: >> pdflatex pll_freq_ramp.tex >> This is pdfTeX, Version 3.1415926-1.40.10 (Web2C 2009) >> >> kpathsea: Running mktexfmt pdflatex.fmt >> I can't find the format file `pdflatex.fmt'! > > I have been testing this on F-12 and sometimes update break with this same > error. The latest updates are working here. > > The symptom is that running fmtutil-sys --all as root returns nothing. > > I have still determine what causes this, and since the last update is > working I don't have an incentive to continue searching. :-) Very strange, I'm testing on 2 machines, both very similar. This happened on one, but not the other. I ran yum reinstall texlive*, and it's fixed. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
texlive 2009 f11 info conflict
Transaction Check Error: file /usr/share/info/dir from install of texlive-kpathsea- doc-2009-2.15842.fc12.noarch conflicts with file from package info-4.13a-4.fc11.x86_64 file /usr/share/info/kpathsea.info.gz from install of texlive-kpathsea- doc-2009-2.15842.fc12.noarch conflicts with file from package kpathsea-2007-46.fc11.x86_64 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 staged for mirrors, rawhide moving on soon
Jesse Keating wrote: > On Thu, 2009-11-12 at 16:09 -0800, H. Peter Anvin wrote: >> For heaven's sake, no! >> >> Don't you realize this means a ton of *users* will start to bog down the >> mirrors before the whole data set has propagated through the network? > > I'm not sure what you're expecting, but users will only be able to get > to the Everything tree, which is nearly 100% hardlinks into the > development/ tree. There are no isos, no install images, nothing but > rpms and repodata. They will not be able to get to the isos which are > behind locked dirs. > So, can I do preupgrade now (I have plenty of /boot)? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 staged for mirrors, rawhide moving on soon
Rahul Sundaram wrote: > On 11/14/2009 05:22 AM, Neal Becker wrote: >> Jesse Keating wrote: >> >>> On Thu, 2009-11-12 at 16:09 -0800, H. Peter Anvin wrote: >>>> For heaven's sake, no! >>>> >>>> Don't you realize this means a ton of *users* will start to bog down >>>> the mirrors before the whole data set has propagated through the >>>> network? >>> >>> I'm not sure what you're expecting, but users will only be able to get >>> to the Everything tree, which is nearly 100% hardlinks into the >>> development/ tree. There are no isos, no install images, nothing but >>> rpms and repodata. They will not be able to get to the isos which are >>> behind locked dirs. >>> >> >> So, can I do preupgrade now (I have plenty of /boot)? > > Yes. As always, having a backup of your data is a good thing. > > Rahul > Preupgrade is not showing f12, only choice is rawhide. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 staged for mirrors, rawhide moving on soon
Rahul Sundaram wrote:
> On 11/14/2009 07:40 PM, Neal Becker wrote:
>
>>>
>>
>> Preupgrade is not showing f12, only choice is rawhide.
>
> Yes but Rawhide is still Fedora 12 now. So you have a small window to
> upgrade.
>
> Rahul
>
Looks like it didn't work, only ran for a moment. Offers to reboot, but
didn't seem to download any packages:
sudo preupgrade
/usr/lib/python2.6/site-packages/yum/__init__.py:203: UserWarning: Use
.preconf instead of passing args to _getConfig
warnings.warn('Use .preconf instead of passing args to _getConfig')
Loaded plugins: blacklist, dellsysidplugin2, refresh-packagekit, whiteout
preupgrade (mirrorlist)
url:
http://mirrors.fedoraproject.org/mirrorlist?repo=rawhide&arch=$basearch
now: http://mirrors.fedoraproject.org/mirrorlist?repo=rawhide&arch=x86_64
preupgrade-rpmfusion-free-rawhide (mirrorlist)
url: http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-
rawhide&arch=x86_64
now: http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-
rawhide&arch=x86_64
preupgrade-rpmfusion-nonfree-rawhide (mirrorlist)
url: http://mirrors.rpmfusion.org/mirrorlist?repo=nonfree-fedora-
rawhide&arch=x86_64
now: http://mirrors.rpmfusion.org/mirrorlist?repo=nonfree-fedora-
rawhide&arch=x86_64
Fetched treeinfo from ftp://fedora.bu.edu/development/x86_64/os//.treeinfo
treeinfo timestamp: Tue Apr 7 06:29:33 2009
rpmfusion-nonfree-release-11.90-1.noarch from preupgrade-rpmfusion-nonfree-
rawhide has depsolving problems
--> Missing Dependency: system-release >= 11.90 is needed by package
rpmfusion-nonfree-release-11.90-1.noarch (preupgrade-rpmfusion-nonfree-
rawhide)
rpmfusion-free-release-11.90-1.noarch from preupgrade-rpmfusion-free-rawhide
has depsolving problems
--> Missing Dependency: system-release >= 11.90 is needed by package
rpmfusion-free-release-11.90-1.noarch (preupgrade-rpmfusion-free-rawhide)
Downloading 1.8MB
Available disk space for /var/cache/yum/preupgrade: 1.1TB
Upgrade requires 500.0MB
Available disk space for /usr: 1.1TB
Generating metadata for preupgrade repo
DEBUG /sbin/grubby --title="Upgrade to Rawhide" --remove-
kernel="/boot/upgrade/vmlinuz" --add-kernel="/boot/upgrade/vmlinuz" --
initrd="/boot/upgrade/initrd.img" --args="preupgrade
repo=hd::/var/cache/yum/preupgrade stage2=hd:UUID=9a7b4349-d278-4287-
b6a9-4c4949e97730:/upgrade/install.img ks=hd:UUID=9a7b4349-d278-4287-
b6a9-4c4949e97730:/upgrade/ks.cfg"
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
texlive 2009 texlive-Asana-Math conflict
--> Processing Dependency: texlive-Asana-Math = 2009 for package: texlive- collection-fontsextra-2009-2.13989.fc12.noarch ---> Package texlive-asana-math-fedora-fonts.noarch 0:2009-2.0.926.15878.fc12 set to be updated --> Finished Dependency Resolution texlive-collection-fontsextra-2009-2.13989.fc12.noarch from installed has depsolving problems --> Missing Dependency: texlive-Asana-Math = 2009 is needed by package texlive-collection-fontsextra-2009-2.13989.fc12.noarch (installed) Error: Missing Dependency: texlive-Asana-Math = 2009 is needed by package texlive-collection-fontsextra-2009-2.13989.fc12.noarch (installed) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
The tag mercurial-1_4-1_fc12 is already applied on a different branch
Seems I do this every time we have a new release. In F12: cvs tag -F -c mercurial-1_4-1_fc12 ERROR: The tag mercurial-1_4-1_fc12 is already applied on a different branch ERROR: You can not forcibly move tags between branches cvs tag: Pre-tag check failed cvs [tag aborted]: correct the above errors first! What are my choices to proceed? I already have built/are building 1.4.1 on F13 and F11. I don't want to have a different package number on F12. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
texlive 2009 massive dep problem today
Lots of errors like these: Error: Missing Dependency: libc.so.6(GLIBC_2.11)(64bit) is needed by package texlive-luatex-bin-2009-2.15878.fc12.x86_64 (texlive) Error: Missing Dependency: libpoppler.so.5()(64bit) is needed by package texlive-jadetex-bin-2009-2.15878.fc12.x86_64 (texlive) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: texlive 2009 texlive-Asana-Math conflict
Jindrich Novy wrote: > On Sun, Nov 15, 2009 at 07:37:54PM -0500, Neal Becker wrote: >> --> Processing Dependency: texlive-Asana-Math = 2009 for package: >> texlive- collection-fontsextra-2009-2.13989.fc12.noarch >> ---> Package texlive-asana-math-fedora-fonts.noarch >> 0:2009-2.0.926.15878.fc12 set to be updated >> --> Finished Dependency Resolution >> texlive-collection-fontsextra-2009-2.13989.fc12.noarch from installed has >> depsolving problems >> --> Missing Dependency: texlive-Asana-Math = 2009 is needed by package >> texlive-collection-fontsextra-2009-2.13989.fc12.noarch (installed) >> Error: Missing Dependency: texlive-Asana-Math = 2009 is needed by package >> texlive-collection-fontsextra-2009-2.13989.fc12.noarch (installed) >> > > Fixed. > texlive-Asana-Math-fedora-fonts-2009-2.0.926.15878.fc12.noarch from installed has depsolving problems --> Missing Dependency: texlive-Asana-Math = 2009 is needed by package texlive-Asana-Math-fedora-fonts-2009-2.0.926.15878.fc12.noarch (installed) texlive-collection-fontsextra-2009-2.13989.fc12.noarch from installed has depsolving problems --> Missing Dependency: texlive-Asana-Math = 2009 is needed by package texlive-collection-fontsextra-2009-2.13989.fc12.noarch (installed) Skip-broken could not solve problems Error: Missing Dependency: texlive-linearA = 2009 is needed by package texlive-collection-fontsextra-2009-2.13989.fc12.noarch (installed) Error: Missing Dependency: texlive-Asana-Math = 2009 is needed by package texlive-collection-fontsextra-2009-2.13989.fc12.noarch (installed) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: texlive 2009 massive dep problem today
Jindrich Novy wrote: > On Tue, Nov 17, 2009 at 06:53:25AM -0500, Neal Becker wrote: >> Lots of errors like these: >> >> Error: Missing Dependency: libc.so.6(GLIBC_2.11)(64bit) is needed by >> package texlive-luatex-bin-2009-2.15878.fc12.x86_64 (texlive) >> Error: Missing Dependency: libpoppler.so.5()(64bit) is needed by package >> texlive-jadetex-bin-2009-2.15878.fc12.x86_64 (texlive) >> >> > > This one looks serious. Are you using the f12/rawhide TL repo on a > rawhide system? If so, I need to separate the F12/rawhide repositories > because of the glibc change in rawhide. So F12 and rawhide binary packages > are no more compatible. > > Jindrich > No, that was just F11. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Can't seem to make tag
Something seems strange here with libotf. I want to push 0.9.9-3 for F12. I went into my F-12 subdir and did the usual make tag build ERROR: Tag libotf-0_9_9-3_fc12 has been already created. OK, I bumped the tag. cvs tag -c libotf-0_9_9-3_fc12_1 ERROR: Tag libotf-0_9_9-3_fc12_1 has been already created. That's strange. OK, bump tag again: cvs tag -c libotf-0_9_9-3_fc12_2 ERROR: Tag libotf-0_9_9-3_fc12_2 has been already created. Now I'm really confused. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FC11 packages 'newer' than FC12
I've been trying to fix libotf, but make tag is doing something really strange. Here is my previous post: Something seems strange here with libotf. I want to push 0.9.9-3 for F12. I went into my F-12 subdir and did the usual make tag build ERROR: Tag libotf-0_9_9-3_fc12 has been already created. OK, I bumped the tag. cvs tag -c libotf-0_9_9-3_fc12_1 ERROR: Tag libotf-0_9_9-3_fc12_1 has been already created. That's strange. OK, bump tag again: cvs tag -c libotf-0_9_9-3_fc12_2 ERROR: Tag libotf-0_9_9-3_fc12_2 has been already created. Now I'm really confused. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: abrt and bugzilla
I can't seem to get abrt to work at all. I suspect it's stuck on trying to get bz username password. I suspect it doesn't work correctly with kde. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
allow adding repos in preupdate?
I'd like to add my favorite repo. Possible? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: abrt and bugzilla
Jaroslav Reznik wrote: > On Friday 20 November 2009 12:29:34 Neal Becker wrote: >> I can't seem to get abrt to work at all. I suspect it's stuck on trying >> to >> get bz username password. I suspect it doesn't work correctly with kde. >> > >>From what I know it works correctly in KDE, even we have several KDE >>related > bugreports reported by Abrt. > > There are even plans for full KDE support and replacing Dr. Konqui. > > Jaroslav Doesn't work here at all. When I just tried to send a kernel bug report, it told me some settings weren't correct, and when I clicked on bugzilla and filled in username and password, I got: abrt-gui Our job for UUID 725650339 is done. Traceback (most recent call last): File "/usr/share/abrt/CCReporterDialog.py", line 113, in on_config_plugin_clicked plugin.save_settings() File "/usr/share/abrt/ABRTPlugin.py", line 100, in save_settings self.Settings.save(str(self.Name)) File "/usr/share/abrt/ABRTPlugin.py", line 51, in save self.conf.save(name, self) File "/usr/share/abrt/ConfBackend.py", line 68, in save True) gnomekeyring.DeniedError -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: abrt and bugzilla
Jiri Moskovcak wrote: > On 11/20/2009 12:54 PM, Neal Becker wrote: >> Jaroslav Reznik wrote: >> >>> On Friday 20 November 2009 12:29:34 Neal Becker wrote: >>>> I can't seem to get abrt to work at all. I suspect it's stuck on >>>> trying to >>>> get bz username password. I suspect it doesn't work correctly with >>>> kde. >>>> >>> >>> > From what I know it works correctly in KDE, even we have several KDE >>>> related >>> bugreports reported by Abrt. >>> >>> There are even plans for full KDE support and replacing Dr. Konqui. >>> >>> Jaroslav >> >> Doesn't work here at all. When I just tried to send a kernel bug report, >> it told me some settings weren't correct, and when I clicked on bugzilla >> and filled in username and password, I got: >> >> abrt-gui >> Our job for UUID 725650339 is done. >> Traceback (most recent call last): >>File "/usr/share/abrt/CCReporterDialog.py", line 113, in >> on_config_plugin_clicked >> plugin.save_settings() >>File "/usr/share/abrt/ABRTPlugin.py", line 100, in save_settings >> self.Settings.save(str(self.Name)) >>File "/usr/share/abrt/ABRTPlugin.py", line 51, in save >> self.conf.save(name, self) >>File "/usr/share/abrt/ConfBackend.py", line 68, in save >> True) >> gnomekeyring.DeniedError >> > ABRt dies trying to save/load you stored password if you gnome-keyring > authentication fails, this should be fixed in next update (abrt will > survive the g-k denial, but forget the password when you close it) which > I'm about to do right now. > > Jirka On kde, we shouldn't be using gnomekeyring, I would think. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
disallow broken push to updates?
Wouldn't it be a good idea to disallow a push to updates that has broken deps? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: abrt and bugzilla
Jiri Moskovcak wrote: > On 11/20/2009 01:15 PM, Jaroslav Reznik wrote: >> On Friday 20 November 2009 13:11:49 Jiri Moskovcak wrote: >>> On 11/20/2009 01:08 PM, Neal Becker wrote: >>>> Jiri Moskovcak wrote: >>>>> On 11/20/2009 12:54 PM, Neal Becker wrote: >>>>>> Jaroslav Reznik wrote: >>>>>>> On Friday 20 November 2009 12:29:34 Neal Becker wrote: >>>>>>>> I can't seem to get abrt to work at all. I suspect it's stuck on >>>>>>>> trying to >>>>>>>> get bz username password. I suspect it doesn't work correctly with >>>>>>>> kde. >>>>>>>> >>>>>>>> >>>>>>>> From what I know it works correctly in KDE, even we have several >>>>>>>> KDE >>>>>>>> related >>>>>>> >>>>>>> bugreports reported by Abrt. >>>>>>> >>>>>>> There are even plans for full KDE support and replacing Dr. Konqui. >>>>>>> >>>>>>> Jaroslav >>>>>> >>>>>> Doesn't work here at all. When I just tried to send a kernel bug >>>>>> report, it told me some settings weren't correct, and when I clicked >>>>>> on bugzilla and filled in username and password, I got: >>>>>> >>>>>> abrt-gui >>>>>> Our job for UUID 725650339 is done. >>>>>> Traceback (most recent call last): >>>>>> File "/usr/share/abrt/CCReporterDialog.py", line 113, in >>>>>> on_config_plugin_clicked >>>>>>plugin.save_settings() >>>>>> File "/usr/share/abrt/ABRTPlugin.py", line 100, in save_settings >>>>>>self.Settings.save(str(self.Name)) >>>>>> File "/usr/share/abrt/ABRTPlugin.py", line 51, in save >>>>>>self.conf.save(name, self) >>>>>> File "/usr/share/abrt/ConfBackend.py", line 68, in save >>>>>>True) >>>>>> gnomekeyring.DeniedError >>>>> >>>>> ABRt dies trying to save/load you stored password if you gnome-keyring >>>>> authentication fails, this should be fixed in next update (abrt will >>>>> survive the g-k denial, but forget the password when you close it) >>>>> which I'm about to do right now. >>>>> >>>>> Jirka >>>> >>>> On kde, we shouldn't be using gnomekeyring, I would think. >>> >>> Yes, I'm planning to write another config backend for kwalet, but didn't >>> find any usable API reference so far :( >> >> Have you tried that Python keyring library I sent you? It looks like >> there's support for both G-K and KWallet with same API. But in any case, >> feel free to ask anyone of us (KDE team) for help... >> > > I must have lost it somewhere in my mailbox :-/ Thanks for reminding me, > seems like kwalet and g-k use the same dbus interface, will add support > for this soon. > > Thanks, > J > >>> J. >>> >>> p.s: but according to the error you're seeing you have g-k running, just >>> the authentication failed. >>> >> What's strange too is I tried manually editing /etc/abrt/plugins/Bugzilla.conf, and filled in Login and Password, and it still says it's not configured write and prompts me, then hangs forever with the previous error if I try to fill it in with the gui. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFA] Font audit results for Fedora 12 (final)
What does this mean? I received one for libotf. Neither libotf, nor libotf-devel seem to ship any fonts. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
orphaning dblatex
I no longer wish to maintain dblatex. Any takers? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
abrt issues
Wondering about these odd messages: Dec 2 07:40:12 nbecker6 python: abrt: Pyhook: Detected unhandled exception in /tmp/hgtests.eYmApF/install/bin/hg Dec 2 07:40:12 nbecker6 abrtd: Directory 'pyhook-1259757612-30443' creation detected Dec 2 07:40:12 nbecker6 abrtd: Lock file '/var/cache/abrt/pyhook-1259757612-30443.lock' is locked by process 30445 Dec 2 07:40:12 nbecker6 python: abrt: Pyhook: Detected unhandled exception in /tmp/hgtests.eYmApF/install/bin/hg Dec 2 07:40:13 nbecker6 abrtd: Executable doesn't belong to any package Dec 2 07:40:13 nbecker6 abrtd: Corrupted or bad crash, deleting Dec 2 07:40:13 nbecker6 abrtd: Directory 'pyhook-1259757612-30446' creation detected Dec 2 07:40:13 nbecker6 abrtd: Executable doesn't belong to any package Dec 2 07:40:13 nbecker6 abrtd: Corrupted or bad crash, deleting Dec 2 07:45:56 nbecker6 python: abrt: Pyhook: Detected unhandled exception in dumb.py Dec 2 07:45:56 nbecker6 abrtd: Directory 'pyhook-1259757956-4737' creation detected Dec 2 07:45:56 nbecker6 abrtd: Lock file '/var/cache/abrt/pyhook-1259757956-4737.lock' is locked by process 4773 Dec 2 07:45:56 nbecker6 abrtd: Executable doesn't belong to any package Dec 2 07:45:56 nbecker6 abrtd: Corrupted or bad crash, deleting -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
abrt issue
I just got a crash in kde plasma. Traceback is not useful, because of missing debug pacakges. I'm told I can reload after 'installing the needed packages', but there is no clue what packages are needed. A bit of a mystery. It seems sometimes abrt will go ahead and download needed debuginfo packages, but other times (like today), it doesn't, and doesn't offer any clue what packages are missing. Either way, still not very user friendly. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: abrt issue
Jiri Moskovcak wrote: > On 12/09/2009 01:47 PM, Neal Becker wrote: >> I just got a crash in kde plasma. Traceback is not useful, because of >> missing debug pacakges. >> >> I'm told I can reload after 'installing the needed packages', but >> there is no clue what packages are needed. >> >> A bit of a mystery. It seems sometimes abrt will go ahead and download >> needed debuginfo packages, but other times (like today), it doesn't, and >> doesn't offer any clue what packages are missing. > > Weird, ABRT should tell you the exact package you should install > debuginfo for. I just tried that and abrt says this: > > Reporting disabled because the backtrace is unusable. > Please try to install debuginfo manually by using command: > *debuginfo-install python* > the use the Refresh button to regenerate the backtrace. > > Jirka Yes, I've gotten messages like this sometimes, and that's what I was looking for. But not today. Maybe related? Dec 9 07:50:11 localhost abrtd: New crash, saving Dec 9 07:50:11 localhost abrtd: Activation of plugin 'RunApp' was not successful: Plugin 'RunApp' is not registered -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: abrt issue
Jiri Moskovcak wrote: > On 12/09/2009 02:05 PM, Neal Becker wrote: >> Jiri Moskovcak wrote: >> >>> On 12/09/2009 01:47 PM, Neal Becker wrote: >>>> I just got a crash in kde plasma. Traceback is not useful, because of >>>> missing debug pacakges. >>>> >>>> I'm told I can reload after 'installing the needed packages', but >>>> there is no clue what packages are needed. >>>> >>>> A bit of a mystery. It seems sometimes abrt will go ahead and download >>>> needed debuginfo packages, but other times (like today), it doesn't, >>>> and doesn't offer any clue what packages are missing. >>> >>> Weird, ABRT should tell you the exact package you should install >>> debuginfo for. I just tried that and abrt says this: >>> >>> Reporting disabled because the backtrace is unusable. >>> Please try to install debuginfo manually by using command: >>> *debuginfo-install python* >>> the use the Refresh button to regenerate the backtrace. >>> >>> Jirka >> >> Yes, I've gotten messages like this sometimes, and that's what I was >> looking >> for. But not today. >> >> Maybe related? >> Dec 9 07:50:11 localhost abrtd: New crash, saving >> Dec 9 07:50:11 localhost abrtd: Activation of plugin 'RunApp' was not >> successful: Plugin 'RunApp' is not registered >> > > This shouldn't be related, but I'm wondering where did you get the line > "reload after 'installing the needed packages'" it doesn't come from > ABRT. This is not an exact quote, but it's what I got from abrt when I clicked on 'next'. I don't know what debuginfo package is needed. rpm -qa '*plasma*' doesn't give a good answer. Why isn't abrt telling me? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [ANNOUNCEMENT] Red Hat Bugzilla 3.4 Upgrade Public Beta 2
It doesn't work with konqueror. Neither did it's predecessor. It keeps asking for a password on every page. I am not doing anything with cookies. I have no problem with original bugzilla. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Mass rebuild for F13?
Jakub Jelinek wrote: > On Mon, Dec 21, 2009 at 05:19:20AM -0500, Andre Robatino wrote: >> Is there expected to be a mass rebuild for F13 - for example, to include >> GCC 4.5 (which will probably be released the first half of 2010, judging >> by past release dates)? > > I do not intend to jump to GCC 4.5 for F13, that would mean I and others > would have to spend almost all our time on that already by now, while > there is still a lot of work on GCC 4.4 bugfixing. > GCC 4.4-RH contains several GCC 4.5 new features backported, so I think we > can leave GCC 4.5 as a new feature to F14. > > Jakub > How could I learn what 4.5 features are backported? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
