[HEADS UP]Upgrading ghc-hslogger to 1.1.5 in rawhide
I will be updating ghc-hslogger to 1.1.5. -- Regards Lakshmi Narasimhan T V -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Memory requirements
Richard W.M. Jones redhat.com> writes: > 768 MB!!! > > When I want to stuff as many VMs onto a virtual machine as possible, > RAM usage really matters. Particularly since RAM is currently cheap > up to about 8 GB but becomes much more expensive above that (ie. up to > about 6 VMs with all the overhead). You can install a virtual guest using extra RAM (assuming your host has it) and then reduce it afterwards. AFAIK, the amount needed to run an already installed system is no greater than before. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT in Fedora 16
On Fri, Aug 26, 2011 at 10:04 PM, Lars Seipel wrote: > btw, I just installed F16 on an EFI machine and got Grub Legacy. Are there any > major problems with Grub 2's EFI support? >From a brief conversation I had earlier this week, yes there are. The plan is grub2 for BIOS based machines, grub for EFI in F16. There are EFI changes in grub that need to be ported to grub2 and that is an F17 target. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-16 Branched report: 20110827 changes
Compose started at Sat Aug 27 13:15:27 UTC 2011 Broken deps for x86_64 -- 389-ds-base-1.2.9.0-1.fc16.2.x86_64 requires libnetsnmpagent.so.25()(64bit) 389-ds-base-1.2.9.0-1.fc16.2.x86_64 requires libnetsnmpmibs.so.25()(64bit) 389-ds-base-1.2.9.0-1.fc16.2.x86_64 requires libnetsnmp.so.25()(64bit) OpenImageIO-0.10.1-2.fc15.i686 requires libboost_program_options-mt.so.1.46.0 OpenImageIO-0.10.1-2.fc15.i686 requires libboost_thread-mt.so.1.46.0 OpenImageIO-0.10.1-2.fc15.i686 requires libboost_python-mt.so.1.46.0 OpenImageIO-0.10.1-2.fc15.i686 requires libboost_system-mt.so.1.46.0 OpenImageIO-0.10.1-2.fc15.i686 requires libGLEW.so.1.5 OpenImageIO-0.10.1-2.fc15.i686 requires libboost_regex-mt.so.1.46.0 OpenImageIO-0.10.1-2.fc15.i686 requires libboost_filesystem-mt.so.1.46.0 OpenImageIO-0.10.1-2.fc15.x86_64 requires libboost_regex-mt.so.1.46.0()(64bit) OpenImageIO-0.10.1-2.fc15.x86_64 requires libboost_filesystem-mt.so.1.46.0()(64bit) OpenImageIO-0.10.1-2.fc15.x86_64 requires libboost_program_options-mt.so.1.46.0()(64bit) OpenImageIO-0.10.1-2.fc15.x86_64 requires libboost_system-mt.so.1.46.0()(64bit) OpenImageIO-0.10.1-2.fc15.x86_64 requires libGLEW.so.1.5()(64bit) OpenImageIO-0.10.1-2.fc15.x86_64 requires libboost_python-mt.so.1.46.0()(64bit) OpenImageIO-0.10.1-2.fc15.x86_64 requires libboost_thread-mt.so.1.46.0()(64bit) acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell) almanah-0.7.3-12.fc16.x86_64 requires libcamel-1.2.so.26()(64bit) almanah-0.7.3-12.fc16.x86_64 requires libedataserverui-3.0.so.0()(64bit) assogiate-0.2.1-5.fc15.x86_64 requires libgnomevfsmm-2.6.so.1()(64bit) bibletime-2.8.1-1.fc16.x86_64 requires libclucene.so.0()(64bit) cluster-snmp-0.18.7-1.fc16.x86_64 requires libnetsnmp.so.25()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires rvm-tools coda-server-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) comoonics-cdsl-py-0.2-18.noarch requires comoonics-base-py comoonics-cluster-py-0.1-24.noarch requires comoonics-base-py contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1 contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires libebook-1.2.so.10()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires gnome-python2-applet deskbar-applet-2.32.0-4.fc15.x86_64 requires libcamel-1.2.so.23()(64bit) dh-make-0.55-3.fc15.noarch requires debhelper emacs-spice-mode-1.2.25-5.fc15.noarch requires gwave emerillon-0.1.2-17.fc16.x86_64 requires libethos-ui-1.0.so.0()(64bit) emerillon-0.1.2-17.fc16.x86_64 requires libethos-1.0.so.0()(64bit) evolution-mapi-3.1.3-1.fc16.i686 requires libcamel-1.2.so.27 evolution-mapi-3.1.3-1.fc16.i686 requires libcamel-provider-1.2.so.27 evolution-mapi-3.1.3-1.fc16.x86_64 requires libcamel-provider-1.2.so.27()(64bit) evolution-mapi-3.1.3-1.fc16.x86_64 requires libcamel-1.2.so.27()(64bit) exaile-0.3.2.1-1.fc16.noarch requires hal fawkes-guis-0.4.2-4.fc16.i686 requires libgvc.so.5 fawkes-guis-0.4.2-4.fc16.i686 requires libcdt.so.4 fawkes-guis-0.4.2-4.fc16.i686 requires libgraph.so.4 fawkes-guis-0.4.2-4.fc16.x86_64 requires libgvc.so.5()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libcdt.so.4()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libgraph.so.4()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libboost_signals-mt.so.1.46.1()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libboost_thread-mt.so.1.46.1()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libgeos-3.2.1.so()(64bit) file-browser-applet-0.6.6-1.fc15.x86_64 requires libpanel-applet-2.so.0(
Re: Memory requirements (was: Re: Fedora 16 Alpha i386 does not install in VMWare)
> On Fri, Aug 26, 2011 at 06:47:37PM -0500, David Lehman wrote: >> On Fri, 2011-08-26 at 23:13 -0700, a...@clueserver.org wrote: >> > I have tried installing Fedora 16 alpha (i386 version) on VMWare >> player >> > and it dies starting up the installer. >> > >> > It also dies trying to install on my CTL 2GO pad. (Atom based tablet.) >> >> Same type of death as the vmware? >> >> > >> > Any ideas why? >> >> If you have less than 768M of memory you could have problems unpacking >> the initrd and/or starting the installer. > > 768 MB!!! > > When I want to stuff as many VMs onto a virtual machine as possible, > RAM usage really matters. Particularly since RAM is currently cheap > up to about 8 GB but becomes much more expensive above that (ie. up to > about 6 VMs with all the overhead). > > I can still run Debian VMs in 128 MB and do useful stuff with them > like light dynamic web serving. In both cases I had 2 gigs of ram. Should not be a memory issue. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Memory requirements
On Sat, Aug 27, 2011 at 08:08:20AM +, Andre Robatino wrote: > Richard W.M. Jones redhat.com> writes: > > > 768 MB!!! > > > > When I want to stuff as many VMs onto a virtual machine as possible, > > RAM usage really matters. Particularly since RAM is currently cheap > > up to about 8 GB but becomes much more expensive above that (ie. up to > > about 6 VMs with all the overhead). > > You can install a virtual guest using extra RAM (assuming your host has it) > and > then reduce it afterwards. AFAIK, the amount needed to run an already > installed > system is no greater than before. Why does it need so much to start with? It's just a graphical program that asks a few questions and then installs a few packages. Can't see why it would need such huge amounts of RAM. Rich. -- 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: Memory requirements (was: Re: Fedora 16 Alpha i386 does not install in VMWare)
On Sat, Aug 27, 2011 at 8:47 AM, Richard W.M. Jones wrote: > On Fri, Aug 26, 2011 at 06:47:37PM -0500, David Lehman wrote: >> On Fri, 2011-08-26 at 23:13 -0700, a...@clueserver.org wrote: >> > I have tried installing Fedora 16 alpha (i386 version) on VMWare player >> > and it dies starting up the installer. >> > >> > It also dies trying to install on my CTL 2GO pad. (Atom based tablet.) >> >> Same type of death as the vmware? >> >> > >> > Any ideas why? >> >> If you have less than 768M of memory you could have problems unpacking >> the initrd and/or starting the installer. > > 768 MB!!! > > When I want to stuff as many VMs onto a virtual machine as possible, > RAM usage really matters. Particularly since RAM is currently cheap > up to about 8 GB but becomes much more expensive above that OT: This does not seem to be the case ... I can buy 24GB for almost the same amount (~120€) I bought 6GB 3 years ago ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: NetworkManager, openswan and l2tp
On 08/26/2011 11:50 -0400, Dan Williams wrote: On Fri, 2011-08-26 at 11:50 -0400, Avesh Agarwal wrote: >> > On 08/26/2011 05:09 AM, Eberhard Schruefer wrote: >>> > > On 08/25/2011 13:57 -0500, Dan Williams wrote: >>> > > >>> > > On Thu, 2011-08-25 at 11:00 +0200, Eberhard Schruefer wrote: >> > Hello, >>> > > I need to connect to a site via l2tp/openswan. I can set up > > >>> openswan and >> > xl2tpd >> > manually and this works fine. However, bringing up the >> > connection > > >>> is not >> > very >> > comfortable and it would be much nicer to be able to use the >> > networkmanager-openswan >> > plugin. >> > Unfortunately, l2tp and other 'advanced settings' cannot be > > >>> selected from >> > networkmanager-connection-editor. A quick look at the source >> > code of >> > NetworkManager-openswan-1.7.0 shows that these options are > > >>> programmed, >> > but seem not to be available in Fedora 15. > >> Which openswan sources are you looking at? >>> > > I'm referring to the networkmanager-openswan plugin source written by >>> > > Alexander Dorokhov >>> > > (hosted on xelerance). It seems that everything necessary to be set >>> > > through the UI is there and >>> > > also the code for bringing up xl2tpd. However, it looks like that >>> > > openswan itself has to be >>> > > compiled with HAVE_STATSD. It would be great if we could all have that >>> > > in FEDORA! >> > HAVE_STATSD is disabled by openswan upstream by default. If the option >> > is enabled upstream in a future release,it will be in Fedora too. >> > Will these options eventually be set-able in Fedora? > >> It's probable they will be but it might take some work. AFAIK there > >> isn't yet an L2TP VPN plugin for NM though I've heard of people > working > >> on one. > >> >> > Would converting the glade file in >> > NetworkManager-openswan-1.7.0 to >> > gtkbuilder >> > and a recompile of networkmanager-openswan suffice? > >> As part of the NM 0.9 push we moved the existing NM-openvpn plugin > to > >> git.gnome.org and cleaned it up, including converting to GtkBuilder. > >> But that alone wouldn't magically make L2TP work unless the right > >> options were added to the UI. >>> > > I think to vaguely remember that these options were available in very >>> > > early releases of the openswan >>> > > networkmanager plugin, but disappeared in later versions. What was >>> > > reason for that? >> > The red hat implementation hosted at git.gnome.org never had L2TP >> > options, and so these option were never in Fedora. > Would be cool if we could add it though... TBH I'm not actually > familiar with how the layering works with L2TP, since I thought it was > more standalone like PPTP but just somehow better. My lack of knowledge > about L2TP could fill a barrel, simply because I haven't had time to > investigate. If others know more, by all means, help us out with > patches. > > Dan Is there any strong reason for not compiling the current openswan with HAVE_STATSD and making all options available that offers networkmanager-openswan-1.7.0? I think it would indeed be very cool! Eberhard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PokerTH orphaned
On Tue, Aug 2, 2011 at 12:32 PM, Ryan Rix wrote: > On Tue 2 August 2011 11:36:20 Hans de Goede wrote: >> Hi, >> >> On 08/01/2011 09:44 PM, Ryan Rix wrote: >> > On Mon 1 August 2011 19:43:37 Tomas Mraz wrote: >> >> On Mon, 2011-08-01 at 10:29 -0700, Ryan Rix wrote: >> >>> On Mon 1 August 2011 11:46:00 Jussi Lehtola wrote: >> Hi, >> >> >> I've just orphaned PokerTH, since I'm trying to free myself some >> time >> and I don't use it myself. >> >> PokerTH does not currently build on rawhide, since OpenSSL support >> has >> been dropped from GnuTLS a week ago (BZ #726697). Getting it to >> build >> again would then require building against OpenSSL (and asking >> upstream >> for a GPL license exception), or shipping a private copy of >> GnuTLS. >> >>> >> >>> I picked up rawhide through F-14. If I cant get this building, I'll >> >>> orphan it again in a week's time. >> >> >> >> Shipping a private copy of GnuTLS would have to get an exception I do >> >> not think such exception should/would be granted. I can only recommend >> >> you to look at the NSS OpenSSL compatibility support library and >> >> patching PokerTH to use it instead of the GnuTLS. >> > >> > I've talked to a few people about this now, including some folks at >> > PokerTH about it, and they're confused as to why this change is >> > happening in GnuTLS at all, and your comment in the bug report did not >> > seem to explain it to them; could you (or anyone) explain better why >> > OpenSSL support in gnutls is a Bad Thing? >> >> Ryan, have you read the initial description of: >> https://bugzilla.redhat.com/show_bug.cgi?id=460310 >> >> ? >> >> The problem is that gnutls's openssl compatibility uses the same symbol >> names as openssl itself thus polluting the dynamic linker symbol namespace. >> So if an application uses a library which is linked against openssl (for >> example ldap libs through pam) and uses gnutls-openssl then the ldap >> libraries will end up calling functions inside gnutls-openssl rather then >> inside openssl, since the gnutls-openssl symbols are already present in the >> dynamic linkers symbol namespace. This then goes boom big time, since the 2 >> are not ABI compatible. >> >> Since gnutls-openssl is not ABI compatible it should not be using the same >> function / variable names. >> >> Tomas has chosen to fix this problem by simply disabling the openssl compat >> part of gnutls (which as the above bug shows is broken by design) given that >> only 3 apps use this, this seems like a sane choice to me. >> >> The best way forward is probably to ask PokerTH upstream to add the >> standard openssl license exception boilerplate to their license, I did >> so successfully with gkrellm and switched to simply using the real openssl. > > Makes sense, thanks Hans. :) > > I actually talked to them, and they say that openssl is pulled in only for > linking libcurl, and that PokerTH itself is using gcrypt for the Big Stuff, so > it should be fairly easy to fix/work around. Had any luck with this, Ryan? (Asked the non-programmer guy who really likes using this package.) -- Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Memory requirements
On Sat, Aug 27, 2011 at 05:35:19PM +0100, Richard W.M. Jones wrote: > Why does it need so much to start with? Because the installer initrd contains the kitchen sink. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
retiring xfprint in f16/rawhide
I'm retiring xfprint from f16/rawhide. It's not at all useful (and hasn't been for a while), it has large deps (it uses a2ps), it's ugly and there are much better printer tools, and it's not had an upstream commit in over 2 years. If someone really really wants to revive it let me know, but I will do my best to discourage you. ;) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OpenBUGS program has a pre-compiled )S library from MS Windows. Any possibility to package it?
On 26 August 2011 19:50, Michael Ekstrand wrote: > On 08/26/2011 12:13 PM, Michael Ekstrand wrote: >> 3. cp-dev seems to not only use Black Box to bootstrap, but it also >> seems to use Black Box sources as a part of itself. I have not yet >> investigated whether this is true and, if true, how the relevant sources >> are licensed. > > BlackBox Component Builder's installation includes lots of source code > and is licensed under what looks like the Sleepycat license (BSD + > copyleft). > > So it looks like the build and packaging toolchain for OpenBUGS does > consist of open source software, but this software is built for Windows, > may depend on GUIs for launching and controlling the build, and has a > nontrivial bootstrap process. Perhaps JAGS is a better option for Fedora: http://en.wikipedia.org/wiki/Just_another_Gibbs_sampler "Its main advantage in comparison to the members of the original BUGS family (WinBUGS and OpenBUGS) is its platform independence. It is written in C++, while the BUGS family is written Component Pascal which is only available for Windows.[1][2] Therefore it is already part of many repositories of Linux distributions like Ubuntu. It can also be compiled as a 64-bits application on 64-bits platforms, thus making all the addressable space available to BUGS models." J. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
ghc-hslogger - License change from LGPLv2 to BSD
License of ghc-hslogger has changed from LGPLv2 to BSD. -- Regards Lakshmi Narasimhan T V -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
