Re: [Mono-list] yum repo
LC wrote: > Is there a yum repo for CentOS? The repo file on the website is FC3 > and it is missing. I'm guessing that you're looking for Mono via yum. I don't know if the CentOS yum repo's host Mono - I wish they did so that I wouldn't have to be bothered with manual installation and updates. :) If this isn't related to Mono I recommend you pursue your Linux update issues at http://www.CentOS.org. You don't say if you're using v3 or v4. This is for v4 !! For CentOS your yum config info is in /etc/sysconfig/rhn/sources. If that file doesn't contain the following lines somewhere, add them: yum centos4-Base http://mirror.centos.org/centos/4/os/$ARCH/ yum centos4-Updates http://mirror.centos.org/centos/4/updates/$ARCH/ yum centos4-extras http://mirror.centos.org/centos/4/extras/$ARCH/ yum centos4-contrib http://mirror.centos.org/centos/4/contrib/$ARCH/ yum centos4-addons http://mirror.centos.org/centos/4/addons/$ARCH/ yum centos4-centosplus http://mirror.centos.org/centos/4/centosplus/$ARCH/ Be careful, see this recent issue: http://bugs.centos.org/view.php?id=1478 CentOS4 includes a new update process which will dynamically select a mirror based on your location. I believe this will be configured after you get your first update. HTH Tony ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] installing complete mono framework on CentOS 4.3
Igor wrote: > BTW: do you know how to search the e-mail archive without scrolling > manually through the subjects ? Go here: http://lists.ximian.com/pipermail/mono-list/ You can download all of the gzips and then use common search routines on your local file system. A smart download manager would help so you don't have to click all of those links. >> The most helpful suggestion posted here was to use the Installer: >> http://www.mono-project.com/Downloads >> Of course someone else said that this was problematic as well. I >> really should just use that until the RPM issues are gone... > > Do you mean 'rug' ? Sorry, I don't understand the question. If you mean Red Carpet, no. Check the link above for this: "Linux Installer for x86 (All distributions)" Read the InstallerInstructions page for more info. HTH Tony ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] installing complete mono framework on CentOS 4.3
Igor, I reported the same issue to this forum with v1.1.13 on 13-march-2006. Mono is trying to install SQLite v2.8 when other common packages are already up to v3.2. I have no idea how people are installing Mono on RHEL - certainly not from RPM, probably not from source, so is anyone running over RHEL (CentOS, WhiteBox Linux, etc)? The person who is doing the Mono builds for RH needs to test the RPM on a system with an assortment of common packages, like any of us would, and he'll see that it won't work. The most helpful suggestion posted here was to use the Installer: http://www.mono-project.com/Downloads Of course someone else said that this was problematic as well. I really should just use that until the RPM issues are gone... Last year I fell into RPM hell with Mono, trying to install from source and getting tons of dependency issues with Monodevelop, Monodoc, and others. After waiting a period for these issues to go away, I tried to install v1.1.13 and had similar issues. I haven't tried again since. Outside of trying to install once a year or so I don't know what else I can do here. Project contributors, this isn't a complaint. I really appreciate your efforts and talk about the project forums, my blog, with colleagues, etc.. But basic install stuff like this needs to be fixed or the project can't achieve "critical mass" as a compelling platform for development against hand-coded PHP, Perl, Java, etc. Regards and Thanks, Tony gnuplot post wrote: > Hi again, > > The game ( aka rpm hell ) is still not over. > > I am trying to install the rest of the packages needed for the > development: Gtk# 1 Development Tools and Gtk# 2 > > I am stuck ... AGAIN. > > [EMAIL PROTECTED] mono]# \rpm -iv * > error: Failed dependencies: > mono(Mono.Data.SqliteClient) = 1.0.5000.0 is needed by > monodevelop-0.11-0.novell.noarch > > So, we are back to the square one. Monodevelop needs sqlite. > > It seems to me that mono is not yet ready for the real production use. > If I can not install it > on RHEL 4 (aka CentOS 4.3) then I do not know what else I can say. > > DISCLAIMER: > I am NOT SW developer. I am just trying to help a hardcore MS WINDOWS > .NET developer > > He showed a real interest to port his applications from MS WINDOWS to > LINUX. He would like to have a development environment as comfortable > as possible. IDE is a part of the comfort zone. > His program is NOT a home/hobby project. It is a real production > project. To be more specific, a real LAB project. Our company has > 8000+ employees and I am doing my > best to show to as many people I can, the power of UNIX/LINUX. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Working with Files
Dallman, John wrote: > The security issues on this one are, well, large In addition to security concerns - Rather than a raw socket server with a custom protocol, etc, it would be far easier and less time consuming to create web services for authentication, execution of specific functions, etc.. (Encryption would probably be the same regardless of transport mechanisms) Do you have control over client and server? Will you be writing the client code too? Writing socket servers is fun and rewarding but only when someone isn't expecting you to do it with time constraints for a mission-critical app. :) ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Domain host considering hosting Mono
My RHEL-based host (now shifting from BSD) is quite large and supports thousands of domains. Based on a recent inquiry I made I understand they are now looking into hosting Mono for new and existing customers. Is there a document somewhere that targets this specific audience with information about the concerns for shared hosts? We have plenty of disk with this host - is the Linux Installer an option for individual installs? We don't have shell access so we'd need to do all command-line operations via remote/cron-executed scripts. Some dependencies and components would need to be removed, since for example, we don't need Gtk# on a system that's not serving thick-client apps, and they're running Apache and we wouldn't be able to run XSP. This could be a big opportunity for Mono to get some exposure with a major host. I'm just wondering how secure and stable it would be in this sort of environment. Does anyone build installers or RPMs that are oriented toward this focus audience? Thanks. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Duplicate emails from list
I wanted to close this old thread with a note that the mail duplicates were caused by a misconfigured filter on my side, and not related directly to this list at all. Thanks to all who responded. Peter Dennis Bartok wrote: > But the point Atsushi, I and other have made is that it is *only* you > receiving duplicates. Therefore I would assume it's script-foo on > your side that's causing you to receive duplicates. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Ftp Client Online
Herman Vega wrote: > Hi guys! > > it's possible make an software that i can upload files to any ftp > server but with nice local disk browser for locate local files (web > client)? ... like a two column local disk/remote disk software native > ftp client but this online (web interface), with features like drag & > drop from local disk to remote disk? > > the real problem is: how i can browse my local disk (in web client) to > upload files to remote ftp server? html input type file it's very > basic and ocx control it's not very nice to users. > > regards You're asking for a lot there. I can't offer a solution, only point to some similar work. Chris Richner, (aka Jerry Maguire aka Raccoom) has published a lot of material on populating treeviews using data providers which use the local drive, FTP, or other sources. It's really great work. See his website for the open source TreeViewFolderBrowser, and links to many articles: http://www.raccoom.net/ Be aware that some of his C# code is heavily Win32-specific at the moment. It is not drag-n-drop aware, completely plug-n-play, or even coded for Mono, but it's about as close as you're going to get to really well coded, object oriented code that should be a good exercise for porting to Mono ... and then you can post it somewhere for the rest of us to view and enhance your fine handiwork. Also note that his code is for thick-client, not thin - Chris has not written similar ASP.NET / webclient treeview code. The security issues with such a thing are horrific. Maybe you can learn from the code that exists and come up with something that satisfies your needs. HTH ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] glibc (?) error with Mono 1.1.14
I don't think that's a glibc error per-se, looks like it's that danged dependency on the old sqllite: > === Backtrace: = ... > /usr/lib/libsqlite3.so.0(sqlite3FreeX+0x21)[0xb3ac7e] ... > /usr/lib/libsqlite.so.0.8.6 001d-001d4000 rwxp 00046000 fd:00 I'm surprised, we were told that was a build issue. See these threads for related notes: http://lists.ximian.com/pipermail/mono-list/2006-March/030932.html http://lists.ximian.com/pipermail/mono-list/2006-April/031353.html -- Julien Sobrier wrote: > Hello, > I've compiled an application with Mono 1.1.14, and I'm trying to > execute > it on the same machine with the same Mono version. i get an error, > apparently related to glibc. I used the Mono installer on the Mono > website. > > ]$ mono bin/release/Application.exe > *** glibc detected *** mono: free(): invalid next size (fast): > 0x09470830 *** > === Backtrace: = > /lib/libc.so.6[0x9391e0] > /lib/libc.so.6(__libc_free+0x77)[0x93972b] > /usr/lib/libsqlite3.so.0(sqlite3FreeX+0x21)[0xb3ac7e] > /usr/lib/libsqlite3.so.0(sqlite3VdbeMemRelease+0x4b)[0xb4532b] > /usr/lib/libsqlite3.so.0[0xb3c1d5] > /usr/lib/libsqlite3.so.0(sqlite3VdbeExec+0x377)[0xb3c866] > /usr/lib/libsqlite3.so.0(sqlite3_step+0xee)[0xb424e2] > [0xd3a0e3] > [0xd39f61] > [0xd3976a] > [0xd39389] > [0xd39278] > [0xd380a5] > [0xd37cce] > [0xd37c95] > [0xd37982] > [0xb6d6b7] > [0xb6d611] > [0x89a7c3] > mono[0x813e070] > mono(mono_runtime_invoke+0x27)[0x80d7847] > mono(mono_runtime_exec_main+0x5c)[0x80d897c] > mono(mono_runtime_run_main+0x171)[0x80d85a1] > mono(strftime+0x1bae)[0x805c632] > mono(mono_main+0x841)[0x805d001] > mono(__fxstat64+0x137)[0x805b9eb] > /lib/libc.so.6(__libc_start_main+0xdf)[0x8ead7f] > mono(sinh+0x4d)[0x805b941] > === Memory map: > 00101000-00185000 r-xp fd:00 74121 > /usr/lib/libglib-2.0.so.0.600.6 > 00185000-0018a000 rwxp 00084000 fd:00 74121 > /usr/lib/libglib-2.0.so.0.600.6 > 0018a000-001d r-xp fd:00 75750 > /usr/lib/libsqlite.so.0.8.6 001d-001d4000 rwxp 00046000 fd:00 > 75750 /usr/lib/libsqlite.so.0.8.6 0037-00371000 --xp > 0037 00:00 0 00371000-00374000 rwxp 00371000 00:00 0 > 003ad000-003b5000 r-xp fd:00 5303289/lib/librt-2.3.6.so > 003b5000-003b6000 r-xp 7000 fd:00 5303289/lib/librt-2.3.6.so > 003b6000-003b7000 rwxp 8000 fd:00 5303289/lib/librt-2.3.6.so > 003b7000-003c1000 rwxp 003b7000 00:00 0 > 0068d000-0068e000 --xp 0068d000 00:00 0 > 0068e000-0078e000 rwxp 0068e000 00:00 0 > 00885000-00895000 rwxp 00885000 00:00 0 > 00899000-008a9000 rwxp 00899000 00:00 0 > 008b7000-008b8000 r-xp 008b7000 00:00 0 [vdso] > 008b8000-008d2000 r-xp fd:00 5303234/lib/ld-2.3.6.so > 008d2000-008d3000 r-xp 00019000 fd:00 5303234/lib/ld-2.3.6.so > 008d3000-008d4000 rwxp 0001a000 fd:00 5303234/lib/ld-2.3.6.so > 008d6000-009f9000 r-xp fd:00 5303235/lib/libc-2.3.6.so > 009f9000-009fb000 r-xp 00122000 fd:00 5303235/lib/libc-2.3.6.so > 009fb000-009fd000 rwxp 00124000 fd:00 5303235/lib/libc-2.3.6.so > 009fd000-009ff000 rwxp 009fd000 00:00 0 > 00a01000-00a24000 r-xp fd:00 5303243/lib/libm-2.3.6.so > 00a24000-00a25000 r-xp 00022000 fd:00 5303243/lib/libm-2.3.6.so > 00a25000-00a26000 rwxp 00023000 fd:00 5303243/lib/libm-2.3.6.so > 00a28000-00a2a000 r-xp fd:00 5303245/lib/libdl-2.3.6.so > 00a2a000-00a2b000 r-xp 1000 fd:00 5303245/lib/libdl-2.3.6.so > 00a2b000-00a2c000 rwxp 2000 fd:00 5303245/lib/libdl-2.3.6.so > 00a43000-00a51000 r-xp fd:00 5303251 > /lib/libpthread-2.3.6.so 00a51000-00a52000 r-xp d000 fd:00 > 5303251/lib/libpthread-2.3.6.so 00a52000-00a53000 rwxp e000 > fd:00 5303251/lib/libpthread-2.3.6.so 00a53000-00a55000 rwxp > 00a53000 00:00 0 00a7e000-00a87000 r-xp fd:00 5303283 > /lib/libnss_files-2.3.6.so 00a87000-00a88000 r-xp 8000 fd:00 > 5303283/lib/libnss_files-2.3.6.so 00a88000-00a89000 rwxp 9000 > fd:00 5303283/lib/libnss_files-2.3.6.so 00b05000-00b58000 r-xp > fd:00 81675 /usr/lib/libsqlite3.so.0.8.6 > 00b58000-00b5a000 rwxp 00052000 fd:00 81675 > /usr/lib/libsqlite3.so.0.8.6 > 00b6-00b7 rwxp 00b6 00:00 0 > 00bcf000-00bd8000 r-xp fd:00 5303253 > /lib/libgcc_s-4.0.2-20051126.so.1 > 00bd8000-00bd9000 rwxp 9000 fd:00 5303253 > /lib/libgcc_s-4.0.2-20051126.so.1 > 00be7000-00bf7000 rwxp 00be7000 00:00 0 > 00d37000-00d47000 rwxp 00d37000 00:00 0 > 00dbd000-00dc r-xp fd:00 81540 > /usr/lib/libgmodule-2.0.so.0.600.6 > 00dc-00dc1000 rwxp 2000 fd:00 81540 > /usr/lib/libgmodule-2.0.so.0.600.6 > 00de7000-00deb000 r-xp fd:00 81624 > /usr/lib/libgthread-2.0.so.0.600.6 > 00deb000-00dec000 rwxp 3000 fd:00 81624 > /usr/lib/libgthread-2.0.so.0.600.6 > 069bc000-069cd000 r-xp fd:00 5303270/lib/libnsl-2.3.6.so > 069cd000-069ce000 r-xp 0001 fd:00 5303270/lib/libnsl-2
RE: [Mono-list] Sqlite in Mono 1.1.14
Julien Sobrier wrote: > Hello, > since I switched from Mono 1.1.13.6 to 1.1.14, I get a lot more > SqliteBusyException in my application. I looked at the 1.1.14 > changelog, I did't see anything about Sqlite. > > Does any one knows if there was any change related to this in 1.1.14, > and if there is a work around? > I understood that the dependency on the older Sqlite was going to be removed in 1.1.14 but haven't tried it yet - there was a conflict in 1.1.13 with systems that had a current Sqlite preinstalled. I don't know if the issue was fixed without being documented or if no changes were made (since it was an RPM build issue maybe it wasn't documented as a Mono issue). Maybe this is a versioning or compatibility issue resulting when a newer Sqlite is in place but Mono expects the older code? Mostly clueless on this, sorry. Check forum posts from a couple months ago for more info. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Duplicate emails from list
Peter Dennis Bartok wrote: > If you got two copies of that message you have a problem on your > side. I keep complete archives and only one was sent through the list. > > From: Atsushi Eno <[EMAIL PROTECTED]> > Cc: mono-list@lists.ximian.com This is exactly the header that I was looking at. Thank you very much. I completely agree that the TO recipient "might" receive two copies depending on mailman and the recipient's MUA. It seems the consistent pattern is that I get two copies from the list whenever people here use the list address in the CC field, even when I am not in the TO field. Note to Atsushi: I do not expect people to change their behavior, I'm trying to understand what software in these many tiers is either duplicating mails or not removing dupes. I have just one more question in this diagnostic: Is anyone here receiving mail with MS Outlook 2003 and not getting dupes? If this is the case then my server is creating the dupes. If no one else is using Outlook (as would be expected with the bias of most OSS communities) then it's still possible that mailman is generating dupes and other people's MUAs are filtering them. Note however, that I am on the mailman-users list, obviously run using mailman, and I do not get dupes from them even when they CC the list. This is why I am so confused about why it's only this one list where this issue is manifested. I apologize to others who don't give a dang about my mail issues. I've been trying to ascertain if this was a general issue, bug in mailman, etc. Without this discussion I have no other way to perform a diagnosis. Thank you for your indulgence. Tony ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Duplicate emails from list
Atsushi Eno wrote: > It is technically difficult to agree with you. Can you exactly point > out which mails are sent to both To and Cc to the mailing lists? > If there are such ones, the evidence should lie in the message > headers. As far as I have ever recognized there is none as such. And > IF there are such people who tend to do that, the number I believe is > absolutely small. > > (Of course having To for the sender and Cc to the list is not > the case you claimed above. But if you meant it, it is simply > unacceptable as discussed before.) Atsushi, please check your sent bin for this post you sent to the list and the post you sent on april 24 to the thread titled "CultureInfo to it-IT". You did not CC the list in this one but you did on that one, and I received a dupe on that one. I get similar dupes when Miguel responds to posts since apparently he uses Reply-All. I've checked the Mailman list discussions, and this issue has been reported on and off for several years. Usually the problem is when a CC recipient matches the name of someone in the list. Mailman has a flag (set by default to On) which avoids sending dupes with the same message-id to the same recipient. I'm thinking that for v2.1.5 which is being used here, a new bug has crept in. I am checking with the Mailman-users list about this. Thanks again. Tony ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Re: Duplicate emails from list
I'm still getting occasional dupes on this list when people send TO the list and they _also_ CC the list. I do not get dupes when people just send TO the list. I'm on lots of lists like this and I don't see this anywhere else, including in the mono-docs-list, so I suspect it's the mail list software being used for mono-list plus some unique setting here. I would appreciate it if a list admin would check into this or forward this note to the mail list authors. I'll also ask people to only send TO _or_ CC the list, not both. I use macros to easily delete dupes before I go through my mail but it's a shame that I have to write and use a macro just for one list. Isn't anyone else seeing dupes from this list? If not, my next test will be to subscribe under a different address and see if that one gets dupes too. Thanks. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Spam to list
Can a mod please un-subscribe the slime balls that are spamming this list? ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Cannot install Mono 1.1.13.6 rpms on CentOS 4
I reported this exact issue to this list over a month ago. It's not a CentOS issue but I happen to use CentOS4 as well. The problem is with other Gnome desktop apps that use a current version of SQLite, which is installed by Yum/up2date, etc. The solution is NOT to force installation of a package that will break your other applications !! Someone said there was a packaging bug in 1.1.13 which should have been fixed to allow Mono to install in a neighborly fashion with other existing applications that use SQLite. I was hoping to see this in a later cut. Can someone verify that this has been fixed in the current 1.1.15? I'm wondering why Mono depends on SQLite anyway. Someone else suggested the "Linux Installer" to keep Mono completely separate from other packages, but then someone commented that the installer has its own set of problems. I wouldn't mind working with the installer if someone could document what the potential problems are that we might encounter. Thanks! --- From: Rubén D. Guíñez Gutiérrez I was the same problem. I installed sqlite with force flag. Nikki Locke wrote: I have CentOS 4, which I understand is based on RedHat Enterprise 4. It uses yum to install packages, and yum depends on sqlite, which comes in version 3.2.2-1. However, attempting to install the 1.1.13.6 rpms gives ... Error: Missing Dependency: libsqlite.so.0 is needed by package mono-data- sqlite libsqlite.so.0 is provided by sqlite-2.8.16-1.2.el4.rf.i386.rpm, but I can't install that, at is an older version than the one I have installed. Sqlite 3.2.2-1 provides libsqlite3.so.0, so that doesn't help either. Any suggestions what I can do here? ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Re: Duplicate emails from list
Thank you for the comments/suggestions. In response to some: - I'm certainly not subscribed twice, the headers in mail dupes are exactly the same. - Note again that mail being sent to the list by some people has both a TO and a CC to the list, so the list is getting mail dupes. This might explain why the list is simply echoing dupes, but I'd think Message-ID header would be different from subscriber to list, or list to public, so I suspect something else is going on. - Regarding my reference to "stupid forum software". I apologize if that ruffles some feathers, but my use of the word "stupid" wasn't flippant or in anger and was not intended to be impolite. (I'm very aware of the concept of netiquette but I also think people need to avoid being overly sensitive to benign words.) I meant forum/list software which is "unintelligent or non-intuitive" in the way it's processing data - I wasn't insulting the software or its authors. I've seen many situations where groups using OSS mail list processors would have the entire membership change the way they process email (reply-all vs reply), rather than change the code to do something logical (setting the Reply-To in a more intelligent manner): I don't reply-all when I'm responding to an individual so I see no practical reason to reply-all just because I'm responding to a list agent. Blaming this on an MUA is silly (probably another inflamatory word, sheesh), an MUA shouldn't process mail differently based on who is sending it any more than the user behind an MUA should have to know the secret handshake for how the list software expects to get responses. We should be the master of our tools, not conform to the limitations of the software we choose. I'm very surprised that people involved so heavily in OSS (this forum and many others) so easily accept anomalies like this as being normal. All that said. I will follow the link provided on the topic of Reply-All and go over prior forum postings on the topic. I will follow the accepted protocol and won't interrupt the group on this specific topic again. Because other people are not getting dupes like I am, I'm having a look at my own mail services. I started my inquiry with this list since this is the only list that I'm getting dupes from. Thanks for your responses. Robert Jordan robertj-at-gmx.net wrote: > Tony G wrote: >> Any idea why I get two of almost every email sent to this forum? >> What are people doing differently that sometimes causes only one >> mail to be generated for some posts and two mails for others? It >> looks like people have the habit of sending to >> mono-list@lists.ximian.com and then also CC >> mono-list@lists.ximian.com and [EMAIL PROTECTED] > > Check whether you've been subscribed multiple times. > >> >> I've also found the need to "reply all" is very irritating, and I >> suspect this is partially responsible for the above issue. If I >> just "reply", mail goes back to the person who posted a note because >> the mail list sets their address as the reply-to. If I hit "reply >> all" then I need to remove the individual before sending, since >> they're going to get the mail from the list anyway. Anyone else >> have a problem with this? I know some other forums do it the same >> way, but what a pain. The problem is stupid forum software that no >> one wants to change, nothing more or less. > > It's really hard to let your last sentence uncommented ... Try > next time to be more polite. > > This is a *mailing list*. It's common sense to configure it this way, > so try to cope with it. If you cannot, get a MUA that support > "Reply to list". > > Robert ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Duplicate emails from list
Any idea why I get two of almost every email sent to this forum? What are people doing differently that sometimes causes only one mail to be generated for some posts and two mails for others? It looks like people have the habit of sending to mono-list@lists.ximian.com and then also CC mono-list@lists.ximian.com and [EMAIL PROTECTED] I've also found the need to "reply all" is very irritating, and I suspect this is partially responsible for the above issue. If I just "reply", mail goes back to the person who posted a note because the mail list sets their address as the reply-to. If I hit "reply all" then I need to remove the individual before sending, since they're going to get the mail from the list anyway. Anyone else have a problem with this? I know some other forums do it the same way, but what a pain. The problem is stupid forum software that no one wants to change, nothing more or less. Thanks. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Installing Mono on Debian
Paolo Molaro wrote:
> On 03/24/06 Redefined Horizons wrote:
>> I'm realtively new to Linux and Mono, so please be
>> patient if I ask something obvious. :]
>>
>> I'd like to get Mono installed on my Debian Linux box.
>> I'm running the stable version of Debian Sarge. Should I
>> try to use a Debian package for Mono, or can I use the
>> installer provided here?:
>
> The binary installer should be used only if there is no
> mono packaged for your distribution (either officially or
> in semi-official repositories).
>
> lupus
Paolo, I must disagree. In a recent thread of mine here ("Dependency
issues with 1.1.13") I mentioned that the current Mono was built using an
old version of SQLite. A more recent version is installed with Python and
Gnome desktop utilities written in Gnome. This means the pre-built
packages won't install to a system with even the most basic distro
utilities installed. For those of us unfamiliar with doing a complete
build from source of all Mono-related packages, the only solution is to use
the installer to put all of the mono packages into a unique path - or to
uninstall anything else that happens to use Python, which is unreasonable.
This problem is bound to occur with almost every binary build of Mono since
it relies on other packages, and some of those are bound to be more or less
advanced than what each of us has in our existing systems. Less
sophisticated oftware packages with less rigorous dependencies aren't as
subject to these issues. Quite simply, this is DLL Hell for Linux.
I respectfully request that someone provide a clear set of documentation
that explains how to work around these issues : "How to install Mono when
installed packages are more or less up to date than current Mono
dependencies". Existing documentation found on the net is seriously out of
date and no longer helpful. I'm basically a Windows/.NET/C# guy with Linux
admin experience. I'm not a Linux C developer and not yet familiar with
building packages from source or hacking software as sophisticated as Mono
to conform to a unique environment, but I'm willing to learn everything
required using Mono as a learning project.
If Mono is to gain acceptance with a wider audience of people like myself,
there needs to be current and detailed installation documentation for us to
read. This is as much a marketing issue as technical. As a project that
is attempting to grab the imagination of a diversity of people, you (Mono
developers and corporate supporters) don't want newcomers to get weighed
down in the mechanics of installation and distro-specific syntax, but you
do want people to get started coding in Mono/C# ASAP. As I learn I'll be
happy to update existing docs, but for now it seems like I'll have to go
through the school of hard knocks first, or find some decent docs, so that
I can understand the process.
Anyway, for now, my advice to the OP and others is to use the Installer if
the distro-specific binary doesn't work for any reason.
Thanks and Regards.
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Dependency issues with 1.1.13
peter wrote: > Tony G wrote: > >> I'm coming at Mono from a Win32/.NET perspective so my questions >> about RPM versioning might be silly to some of you. This is the >> second time I've tried to install Mono. The first was many months >> ago and I got stuck in a web of dependencies. I'm trying again with >> v1.1.13 and just got stuck with similar issues. I'm not a Linux/RPM >> stud here, so please forgive me if there is an easy answer to what >> seems like dependency hell: >> >> > I don't know what anyone else will say, but from where I sit if you're > new to the Linux/RPM stuff you should use something like Red Carpet > that will sort all that stuff out for you. Let's assume I'm not new to this. What can be done to get Mono to cohabitate with other packages with different versions of dependent packages? > I guess the first thing you would have to do would be to reverse > anything you've done. Then you'd have to get Red Carpet or whatever, > set it up and go from there. > > The actual tool to use would depend on your distribution, I guess. I > use SuSE and Red Carpet works fine for me, but I don't know about > other distributions. > > HTH > Peter Thanks for the suggestion. I'm using CentOS 4.2 which is based on RHES. I've never used Red Carpet but if it gets around this issue I may try it. With RPM, Yum, up2date, and apt available, doesn't it seem like overkill to add yet another package manager to a system? I see there is a potential issue with Mono and Red Carpet anyway: <http://lists.ximian.com/pipermail/mono-list/2005-July/027754.html> The distributions.xml file was never updated for this distro, though I can understand the stock file can't be updated for every distro/release. It was also suggested that I just use the Linux Installer: http://www.mono-project.com/Downloads In the long term I'd really like to understand and address the problem rather than working around it. But to start working with Mono now, sure, I'll use the installer for both Linux and Win32. This will also help for quick deployment of anything I write. Thanks again. Tony ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Dependency issues with 1.1.13
Re-sending, it looks like my response didn't hit the list. Shawn Vose wrote: > I dont know if anyone has answered you already. RPM can be a bugger > some times. This is what I have done in the past. First find out what > is installed. > > rpm -qa | grep mono > > This should return a list of mono packages installed. The U option is > indicating that you already have the package installed. If you already > have an old copy laying around you might want to uninstall. That is a > book in itself just because you have created many dependencies, so > uninstall one at a time but this isnt necessary. I used the U option because that's what the install page suggested. http://www.mono-project.com/Getting_Mono Which BTW, is there only one page on the internet with info about installing Mono from RPM? Please point me to TFM on installation so I can R it. :) I know there are pages on installing from source - is that the way to get around this dependency/versioning issue? Since I'm not upgrading this brand new Linux install (CentOS4.2), I switched to "rpm -ivh". I did check "rpm -qa" and there are no mono components installed. > The reason you are getting these messages is because there is a > circular dependency. In this case it's not circular, just a chain of dependencies which may require me to uninstall stuff that's working. Again, the short of it is that Mono is using libsqlite.so.0 from SQLite 2.8 which has now been updated to libsqlite3.so.0 in SQLite 3.2 - and this 3.2 version is what's installed via Yum and other updates. It might be an easy thing to recompile Mono with the newer version, I just don't know how. As you see, I'm daring enough to use RPM rather than an installer, but the last time I tried to install Mono from source I was in the same dependency Hell that I'm finding now. I'm concerned that if I try to use the convenient installer it's just going to abort with the same versioning issue after having installed some of the packages, and then I might as well just reinstall my Linux box - which is pretty much the reason I gave up on Mono the first time. Maybe I should try to do this via Yum? I expect the same issues though. > Just rpm -Uvh every.single.rpm as one long ass > command and let rpm figure out which one to install. > for example > rpm -Uvh mono-basic.rpm mono-core.rpm sqllite.rpm etc.. Isn't using all of the package names in a long line the same as using *.rpm? (From an off-list e-mail exchange) Shawn Vose wrote: > so the sql lite is already installed for some other package? Yes, I checked the dependencies and SQLite is installed with python which is needed for some Gnome apps. They're all dependent and trying to uninstall will unravel a stream of packages. If the next version of Mono can be built with SQLite 3.2 then this one issue is fixed but I am guessing that this issue will constantly exist, as we can't expect Mono developers to patch up to the very latest libs every time they do a build. My real question for anyone out there is how can we install of the required libraries for Mono into a distro which already has libraries, and avoid the versioning issues? Can't we apply a different configure prefix to all required packages so that we load somewhere else? Am I missing something basic here? I have to think this is a problem that everyone who uses Linux experiences on a daily basis, do I need to write C code and compile from source to use this OS or this package? And of course the other issue is - once we install Mono does that mean we can't use all kinds of other packages? Man, does Linux need a GAC! > Hope this helps and keep the faith. The joy of linux is just this, you > always have the ability to really dig into it and learn something. I'm really willing to learn how this works and document the process so that others who follow will have a clue, but I don't want to bang my head against insurmountable issues, nor do I think it's realistic to expect people to completely uninstall some packages just to install others. Thanks! Tony ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Dependency issues with 1.1.13
I'm coming at Mono from a Win32/.NET perspective so my questions about RPM versioning might be silly to some of you. This is the second time I've tried to install Mono. The first was many months ago and I got stuck in a web of dependencies. I'm trying again with v1.1.13 and just got stuck with similar issues. I'm not a Linux/RPM stud here, so please forgive me if there is an easy answer to what seems like dependency hell: Before Installing Mono I tried to install SQLite: # rpm -Uvh sqlite-2.8.16-1.2.el4.rf.i386.rpm Response is: warning: sqlite-2.8.16-1.2.el4.rf.i386.rpm: V3 DSA signature: NOKEY, key ID 6b8d79e6 Error: Failed dependencies: libsqlite3.so.0 is needed by (installed) python-sqlite-1.1.6-1.i386 That error is pretty useless to me but the following returns something more helpful: # rpm -ivh sqlite-2.8.16-1.2.el4.rf.i386.rpm warning: sqlite-2.8.16-1.2.el4.rf.i386.rpm: V3 DSA signature: NOKEY, key ID 6b8d79e6 Preparing...# [100%] package sqlite-3.2.2-1 (which is newer than sqlite-2.8.16-1.2.el4.rf) is already installed OK, I understand that I can't install sql-2.8 because my system already has v3.2. Since I have the most recent version of that package, I tried to install Mono (from a directory that has all of the Mono 1.1 rpm's: # rpm -Uvh *.rpm error: Failed dependencies: libsqlite.so.0 is needed by mono-data-sqlite-1.1.13.4-0.novell.i586 So as I understand it: I have python-sqlite installed and it needs the newer "libsqlite3" which came from sqlite 3.2. So I can't install sqlite 2.8 because it has plain "libsqlite". Therefore I can't install mono because it relies on mono-data which relies on sqlite 2.8. And of course I can't install anything else that relies on mono. All because I already have python installed, which I only did install because I downloaded a couple "helpful" Gnome desktop apps. Do I need to uninstall my desktop apps, then uninstall python, then uninstall the new sqlite (and hope nothing else depends on it), just so I can install the mono package which is just 2 months old but obviously it relies on older libs? The larger a Linux project is, the more it relies on other packages. The chances are greater that some of those packages will be older and that they will conflict with a system that has recent updates. How much needs to be unravelled just to install a single package? How can we possibly deploy anything written with Mono if there is such a high chance of dependency conflicts on any given target system? I quess the real questions are: - What can I do to get Mono to use the updated SQLite? - And do we really need to go through this pain every time we install or update major packages like Mono? I can't wait until everything in Linux is installed into a GAC so we can avoid this versioning hell. :) Thank you very much !!! ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
