From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/2011-November/009946.html | 104 +++++++++++++++++++++++++++ 1 file changed, 104 insertions(+) create mode 100644 zarb-ml/mageia-dev/2011-November/009946.html (limited to 'zarb-ml/mageia-dev/2011-November/009946.html') diff --git a/zarb-ml/mageia-dev/2011-November/009946.html b/zarb-ml/mageia-dev/2011-November/009946.html new file mode 100644 index 000000000..0188ded7f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-November/009946.html @@ -0,0 +1,104 @@ + + + + [Mageia-dev] Teamviewer and X86_64 build . . . + + + + + + + + + +

[Mageia-dev] Teamviewer and X86_64 build . . .

+ Michel Catudal + michelcatudal at gmail.com +
+ Tue Nov 29 13:53:08 CET 2011 +

+
+ +
Le 29/11/2011 06:43, Donald Stewart a écrit :
+> An immidiate solution, albeit not really a sustainable one, is to add
+> the missing provides to our libxdamage package; however, doing this
+> opens the door to have package x providing n different version of libx
+> or binaryx so it could only really be used if we knew that there was a
+> chance that upstream, in this case teamviewer, are likely to fix there
+> requires to suit that Mageia ones so that we don't end up with package
+> x having hundreds of provides to support different requires from
+> closed source stuff....
+>
+> On a slightly off topic note: have the extra provides could help to
+> improve interoperability with say Fedora - ergo Red Hat, and seeing as
+> most commercial closed source binaries for GNU/Linux will be built
+> with Red Hat in mind, having provides that match Fedora's is probably
+> a good way to eliminate this problem.
+>
+> But, as said earlier, this isn't really something that we can do
+> sustainable so......
+>
+There is really no easy solution. This kind of make us slaves of RedHat and some of the bullshit they push at times.
+There is little choice in many cases. What could be done is some wrappers for some sort of Fedora compatibility if there is enough demand for a package that needs that. When there is a good alternative that does the same thing then I would be opposed to 
+suking up too much to those folks. The goal here is to make our users happy without compromising our principles too much.
+
+Here is an example I had to deal with to get an Atmel program that was designed for Fedora to install on Mandriva 2010.0
+
+elfutil split in different packages. I created one file that satisfied the Atmel installer. The package actually only had one text file  telling you that it was a bogus package to satisty the Atmel program.
+At one time a package had an X instead of an x in the name, aside from that it was the same thing (same version and all)
+
+I had the whole Atmel code working nicely on Mandriva 2010.0. When my hard disk crashed I didn't bother reinstalling because of the sound issues I had with Mandriva. I switched to Scientific Linux, I recently installed Mageia and found that I like it 
+better, French support is better for one thing.
+The only problem I see is my Atmel debugger no longer works, I am working on that. I allready have created the binutils and compiler with the latest Atmel patches. Perhaps running Fedora 12 in VirtualBox might be a good intermediate solution for debugging. 
+I could use windows XP I guess but I have enough of this at work. When I get home windows would be the last thing I would want to see.
+
+Michel
+
+-- 
+For OS/2 and Linux Software visit
+http://home.comcast.net/~mcatudal
+
+
+ + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1