summaryrefslogtreecommitdiffstats
path: root/zarb-ml/mageia-dev/attachments/20130306/2813cb80
diff options
context:
space:
mode:
authorNicolas Vigier <boklm@mageia.org>2013-04-14 13:46:12 +0000
committerNicolas Vigier <boklm@mageia.org>2013-04-14 13:46:12 +0000
commit1be510f9529cb082f802408b472a77d074b394c0 (patch)
treeb175f9d5fcb107576dabc768e7bd04d4a3e491a0 /zarb-ml/mageia-dev/attachments/20130306/2813cb80
parentfa5098cf210b23ab4f419913e28af7b1b07dafb2 (diff)
downloadarchives-master.tar
archives-master.tar.gz
archives-master.tar.bz2
archives-master.tar.xz
archives-master.zip
Add zarb MLs html archivesHEADmaster
Diffstat (limited to 'zarb-ml/mageia-dev/attachments/20130306/2813cb80')
-rw-r--r--zarb-ml/mageia-dev/attachments/20130306/2813cb80/attachment-0001.html37
-rw-r--r--zarb-ml/mageia-dev/attachments/20130306/2813cb80/attachment.html37
2 files changed, 74 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/attachments/20130306/2813cb80/attachment-0001.html b/zarb-ml/mageia-dev/attachments/20130306/2813cb80/attachment-0001.html
new file mode 100644
index 000000000..74ed32880
--- /dev/null
+++ b/zarb-ml/mageia-dev/attachments/20130306/2813cb80/attachment-0001.html
@@ -0,0 +1,37 @@
+<br><br><div class="gmail_quote">On Wed, Mar 6, 2013 at 8:44 AM, Guillaume Rousse <span dir="ltr">&lt;<a href="mailto:guillomovitch@gmail.com" target="_blank">guillomovitch@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+
+Le 06/03/2013 00:50, Reinout van Schouwen a écrit :<div><div class="h5"><br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+Hi all,<br>
+<br>
+The Dutch tax service makes life difficult for (64-bit) Mageia users<br>
+because the tax filing program expects the i586 versions of libxext6 and<br>
+libsm6 to be around.<br>
+<br>
+The tax service claim on their web site that Ubuntu 12.x and Linux Mint<br>
+13 are supported. Could it be that they have these libraries<br>
+preinstalled on 64 bit platforms?<br>
+<br>
+Would it be possible to provide some kind of stub package that downloads<br>
+the program with the required dependencies, like Arch does? (<br>
+<a href="https://aur.archlinux.org/packages/belastingdienst-ib2012/" target="_blank">https://aur.archlinux.org/<u></u>packages/belastingdienst-<u></u>ib2012/</a> )<br>
+</blockquote></div></div>
+Most binary-only i586 programs expects additional 32 bits libraires dependencies: skype, for instance. On a pure 64 bits systems, these libraries won&#39;t be installed, and they won&#39;t even be available directly, as long as 32 bits additional package sources are not configured...<br>
+
+</blockquote><div><br></div><div>I think we configure the 32 bits media by default</div><div>Having a 32 bits package installing this app and having the proper dependencies would make sense</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+
+
+<br>
+I&#39;m effraid than endlessly adding 32bits dependencies on our 64 bits packages, such as we did with pulseaudio for skype case, or adding &#39;stub&#39; packages here, won&#39;t scale indefinitly to match every piece of softwares we can&#39;t distribute ourselves. First, they are exceptions to our &#39;self-containment&#39; package sources policy... Second, dependencies won&#39;t adress the package source configuration issue.<br>
+
+
+<br>
+So, what about adressing end users intelligence, and document all those issues on a central &#39;compatibility&#39; page on our wiki, instead of relying on such kind of hacks ?<span class="HOEnZb"><font color="#888888"><br>
+
+
+<br>
+-- <br>
+BOFH excuse #155:<br>
+<br>
+Dumb terminal<br>
+</font></span></blockquote></div><br>
diff --git a/zarb-ml/mageia-dev/attachments/20130306/2813cb80/attachment.html b/zarb-ml/mageia-dev/attachments/20130306/2813cb80/attachment.html
new file mode 100644
index 000000000..74ed32880
--- /dev/null
+++ b/zarb-ml/mageia-dev/attachments/20130306/2813cb80/attachment.html
@@ -0,0 +1,37 @@
+<br><br><div class="gmail_quote">On Wed, Mar 6, 2013 at 8:44 AM, Guillaume Rousse <span dir="ltr">&lt;<a href="mailto:guillomovitch@gmail.com" target="_blank">guillomovitch@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+
+Le 06/03/2013 00:50, Reinout van Schouwen a écrit :<div><div class="h5"><br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+Hi all,<br>
+<br>
+The Dutch tax service makes life difficult for (64-bit) Mageia users<br>
+because the tax filing program expects the i586 versions of libxext6 and<br>
+libsm6 to be around.<br>
+<br>
+The tax service claim on their web site that Ubuntu 12.x and Linux Mint<br>
+13 are supported. Could it be that they have these libraries<br>
+preinstalled on 64 bit platforms?<br>
+<br>
+Would it be possible to provide some kind of stub package that downloads<br>
+the program with the required dependencies, like Arch does? (<br>
+<a href="https://aur.archlinux.org/packages/belastingdienst-ib2012/" target="_blank">https://aur.archlinux.org/<u></u>packages/belastingdienst-<u></u>ib2012/</a> )<br>
+</blockquote></div></div>
+Most binary-only i586 programs expects additional 32 bits libraires dependencies: skype, for instance. On a pure 64 bits systems, these libraries won&#39;t be installed, and they won&#39;t even be available directly, as long as 32 bits additional package sources are not configured...<br>
+
+</blockquote><div><br></div><div>I think we configure the 32 bits media by default</div><div>Having a 32 bits package installing this app and having the proper dependencies would make sense</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+
+
+<br>
+I&#39;m effraid than endlessly adding 32bits dependencies on our 64 bits packages, such as we did with pulseaudio for skype case, or adding &#39;stub&#39; packages here, won&#39;t scale indefinitly to match every piece of softwares we can&#39;t distribute ourselves. First, they are exceptions to our &#39;self-containment&#39; package sources policy... Second, dependencies won&#39;t adress the package source configuration issue.<br>
+
+
+<br>
+So, what about adressing end users intelligence, and document all those issues on a central &#39;compatibility&#39; page on our wiki, instead of relying on such kind of hacks ?<span class="HOEnZb"><font color="#888888"><br>
+
+
+<br>
+-- <br>
+BOFH excuse #155:<br>
+<br>
+Dumb terminal<br>
+</font></span></blockquote></div><br>