Hi,
Just a heads up, in case anyone else decides (against all sanity) to try using Skype, *and* get a webcam working, on 64-bit Fedora 17, you get stymied by:
Skype being only released in 32 bit Skype wanting video for Linux 1 Fedora 17 uses video for Linux 2 Web pages offering advice for Mint and Ubuntu
So, yum install libv4l-(whatever).i686. In my case, today, that was:
yum install libv4l-0.8.8-2.fc17.i686
Make yourself a script to launch skype with a compatibility library
#!/bin/bash # # force preloading of a 32 bit video for linux 1 # compatibility library for video for linux 2
LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so skype
Use that to start up Skype, instead of its own menu item. No doubt you could put that command line into a desktop launcher, with out the bin bash shebang. And my comments aren't needed, they're just so I don't have to remember why I use that script.
And you're, now, related to Bob.
Tested with: skype-4.0.0.8-fc16.i586 libv4l-0.8.8-2.fc17.i686
NB: If you simply name your launch script "skype", and put it in your file search path, I don't know whether it's safe to launch Skype in the script with a one-word "skype" command. It might go around in circles. You could change my sample launch script to use the full path to skype, instead. i.e. LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so /usr/bin/skype
Anyone care to try this and confirm that it works for more than just me?
Prior to this, I just got a black screen in Skype, instead of my webcam (which does work, if tested in VLC). I have noticed that I needed to toggle the webcam off and on a few times, in Skype, before it came to life. So you might want to test that, too. Toggle on/off, wait a moment, do the opposite.
On Sunday, 21. October 2012. 19.21.02 Tim wrote:
+ACMAIQ-/bin/bash +ACM +ACM force preloading of a 32 bit video for linux 1 +ACM compatibility library for video for linux 2
LD+AF8-PRELOAD+AD0-/usr/lib/libv4l/v4l1compat.so skype
What is this +A stuff?
-- +AFs-tim+AEA-localhost +AH4AXQAk uname -rsvp Linux 3.6.2-4.fc17.x86+AF8-64 +ACM-1 SMP Wed Oct 17 02:43:21 UTC 2012 x86+AF8-64
And in your signature too?!
Best, :-) Marko
On 22/10/12 07:06, Marko Vojinovic wrote:
On Sunday, 21. October 2012. 19.21.02 Tim wrote:
+ACMAIQ-/bin/bash +ACM +ACM force preloading of a 32 bit video for linux 1 +ACM compatibility library for video for linux 2 LD+AF8-PRELOAD+AD0-/usr/lib/libv4l/v4l1compat.so skypeWhat is this +A stuff?
I see no +A* stuff, This is Hash symbol, in sig it is prompt (dollar sign) there is something wrong with the way your system deciphers characters.
On 10/22/2012 02:21 PM, Frank Murphy wrote:
On 22/10/12 07:06, Marko Vojinovic wrote:
On Sunday, 21. October 2012. 19.21.02 Tim wrote:
+ACMAIQ-/bin/bash +ACM +ACM force preloading of a 32 bit video for linux 1 +ACM compatibility library for video for linux 2 LD+AF8-PRELOAD+AD0-/usr/lib/libv4l/v4l1compat.so skypeWhat is this +A stuff?
I see no +A* stuff, This is Hash symbol, in sig it is prompt (dollar sign) there is something wrong with the way your system deciphers characters.
Neither do I....in the inbox. Yet, if I "forward" the message in TBird I get what Marko sees in the newly formed message.... Interesting...
On 10/22/2012 02:53 PM, Ed Greshko wrote:
Neither do I....in the inbox. Yet, if I "forward" the message in TBird I get what Marko sees in the newly formed message.... Interesting...
Should have checked.... But if I view "message source" in TBird I also see...
+ACMAIQ-/bin/bash +ACM +ACM force preloading of a 32 bit video for linux 1 +ACM compatibility library for video for linux 2
On 22/10/12 07:55, Ed Greshko wrote:
On 10/22/2012 02:53 PM, Ed Greshko wrote:
Neither do I....in the inbox. Yet, if I "forward" the message in TBird I get what Marko sees in the newly formed message.... Interesting...
Should have checked.... But if I view "message source" in TBird I also see...
+ACMAIQ-/bin/bash +ACM +ACM force preloading of a 32 bit video for linux 1 +ACM compatibility library for video for linux 2
In TB (Earlbird 17*) In the inbox looks as it should, message source looks as per your follow up.
On 22 October 2012 07:21, Frank Murphy frankly3d@gmail.com wrote:
On 22/10/12 07:06, Marko Vojinovic wrote:
On Sunday, 21. October 2012. 19.21.02 Tim wrote:
+ACMAIQ-/bin/bash +ACM +ACM force preloading of a 32 bit video for linux 1 +ACM compatibility library for video for linux 2 LD+AF8-PRELOAD+AD0-/usr/lib/libv4l/v4l1compat.so skypeWhat is this +A stuff?
I see no +A* stuff, This is Hash symbol, in sig it is prompt (dollar sign) there is something wrong with the way your system deciphers characters.
Tim's email is UTF-7. Marko seems to be using gmail but getting plain text. The original looks okay on my gmail, maybe try changing the gmail display language to English? Or use the 'message text garbled' drop-down option for the messahe.
On 10/22/2012 02:54 PM, Ian Malone wrote:
On 22 October 2012 07:21, Frank Murphy frankly3d@gmail.com wrote:
On 22/10/12 07:06, Marko Vojinovic wrote:
On Sunday, 21. October 2012. 19.21.02 Tim wrote:
+ACMAIQ-/bin/bash +ACM +ACM force preloading of a 32 bit video for linux 1 +ACM compatibility library for video for linux 2 LD+AF8-PRELOAD+AD0-/usr/lib/libv4l/v4l1compat.so skypeWhat is this +A stuff?
I see no +A* stuff, This is Hash symbol, in sig it is prompt (dollar sign) there is something wrong with the way your system deciphers characters.
Tim's email is UTF-7. Marko seems to be using gmail but getting plain text. The original looks okay on my gmail, maybe try changing the gmail display language to English? Or use the 'message text garbled' drop-down option for the messahe.
Yep, that'll explain it....
After saving the original email I ran....
iconv -f UTF-7 -t UTF-8 Howto.eml and it came out "correct".
I don't think it is very common to see UTF-7.
On 10/22/2012 03:04 PM, Ed Greshko wrote:
I don't think it is very common to see UTF-7.
FWIW.... Contained within http://www.imc.org/imcr-010.html
It should be noted that the Unicode Standard also defines the UTF-7 charset, which was intended for Internet mail. However, MIME is quite capable of carrying UTF-8, and UTF-8 is expected to be used in many protocols, not just Internet mail. Fortunately, very few vendors implemented UTF-7, and its use is strongly discouraged in Internet mail.
Ed Greshko:
I don't think it is very common to see UTF-7.
FWIW.... Contained within http://www.imc.org/imcr-010.html
It should be noted that the Unicode Standard also defines the UTF-7 charset, which was intended for Internet mail. However, MIME is quite capable of carrying UTF-8, and UTF-8 is expected to be used in many protocols, not just Internet mail. Fortunately, very few vendors implemented UTF-7, and its use is strongly discouraged in Internet mail.
Discouraged by who? It's supposedly *the* answer to email, to stop allegedly helpful mail services transcoding 8 bit mail on the way through, just because it thinks 8-bit mail is a bad idea (plenty of people have wacky views on that, too), whether that 8-bit is UTF-8 or anything else that's 8-bit text.
My own experiments with pushing mail through various external servers has shown plenty of annoyingly helpful servers transcoding UTF-8 plain text into base64 encoded, or even quoted-printable, both of which are a pain in various ways. Whereas they left UTF-7 alone.
Anyway, any modern mail software (server or client) which screws up UTF-7, as in the original responder's reply, is seriously broken.
And I feel similarly for software which foolishly go about transcoding mail. If I get a mail in an encoding that the client doesn't automatically handle, I can opt to try viewing it with a forced selection of different encoding types. It's hard to do that if a transcoder has taken a format and mangled it, instead of just passing it through.
On 10/22/2012 04:11 PM, Tim wrote:
Ed Greshko:
I don't think it is very common to see UTF-7.
FWIW.... Contained within http://www.imc.org/imcr-010.html
It should be noted that the Unicode Standard also defines the UTF-7 charset, which was intended for Internet mail. However, MIME is quite capable of carrying UTF-8, and UTF-8 is expected to be used in many protocols, not just Internet mail. Fortunately, very few vendors implemented UTF-7, and its use is strongly discouraged in Internet mail.
Discouraged by who? It's supposedly *the* answer to email, to stop allegedly helpful mail services transcoding 8 bit mail on the way through, just because it thinks 8-bit mail is a bad idea (plenty of people have wacky views on that, too), whether that 8-bit is UTF-8 or anything else that's 8-bit text.
My own experiments with pushing mail through various external servers has shown plenty of annoyingly helpful servers transcoding UTF-8 plain text into base64 encoded, or even quoted-printable, both of which are a pain in various ways. Whereas they left UTF-7 alone.
Anyway, any modern mail software (server or client) which screws up UTF-7, as in the original responder's reply, is seriously broken.
And I feel similarly for software which foolishly go about transcoding mail. If I get a mail in an encoding that the client doesn't automatically handle, I can opt to try viewing it with a forced selection of different encoding types. It's hard to do that if a transcoder has taken a format and mangled it, instead of just passing it through.
Whatever.... UFT-7 isn't widely used.... But if you want to use it go ahead. Must be an Australian thing.... :-) :-)
On 10/22/2012 04:19 PM, Ed Greshko wrote:
Whatever.... UFT-7 isn't widely used.... But if you want to use it go ahead. Must be an Australian thing.... :-) :-)
Besides, while the servers may leave the text "alone" they are by no means any better than quoted printable since UTF-7 does its own encoding. So.....
When you wrote *the* it appears in the actual message source as +ACo-the+ACo. Not very human friendly. So you're just trading off "crap" for "crap".
It is my opinion which I'm not asking you to agree with.
On 22/10/12 09:24, Ed Greshko wrote:
Besides, while the servers may leave the text "alone" they are by no means any better than quoted printable since UTF-7 does its own encoding. So.....
When you wrote *the* it appears in the actual message source as +ACo-the+ACo. Not very human friendly. So you're just trading off "crap" for "crap".
It is my opinion which I'm not asking you to agree with.
On the end of Tim's reply TB "message source" has this, so maybe it's a TB artifact? Message itself is fine in TB-inbox.
--===============1646450951936019464== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline
LS0gCnVzZXJzIG1haWxpbmcgbGlzdAp1c2Vyc0BsaXN0cy5mZWRvcmFwcm9qZWN0Lm9yZwpUbyB1 bnN1YnNjcmliZSBvciBjaGFuZ2Ugc3Vic2NyaXB0aW9uIG9wdGlvbnM6Cmh0dHBzOi8vYWRtaW4u ZmVkb3JhcHJvamVjdC5vcmcvbWFpbG1hbi9saXN0aW5mby91c2VycwpHdWlkZWxpbmVzOiBodHRw Oi8vZmVkb3JhcHJvamVjdC5vcmcvd2lraS9NYWlsaW5nX2xpc3RfZ3VpZGVsaW5lcwpIYXZlIGEg cXVlc3Rpb24/IEFzayBhd2F5OiBodHRwOi8vYXNrLmZlZG9yYXByb2plY3Qub3JnCg==
--===============1646450951936019464==--
On 10/22/2012 04:29 PM, Frank Murphy wrote:
On 22/10/12 09:24, Ed Greshko wrote:
Besides, while the servers may leave the text "alone" they are by no means any better than quoted printable since UTF-7 does its own encoding. So.....
When you wrote *the* it appears in the actual message source as +ACo-the+ACo. Not very human friendly. So you're just trading off "crap" for "crap".
It is my opinion which I'm not asking you to agree with.
On the end of Tim's reply TB "message source" has this, so maybe it's a TB artifact? Message itself is fine in TB-inbox.
--===============1646450951936019464== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline
LS0gCnVzZXJzIG1haWxpbmcgbGlzdAp1c2Vyc0BsaXN0cy5mZWRvcmFwcm9qZWN0Lm9yZwpUbyB1 bnN1YnNjcmliZSBvciBjaGFuZ2Ugc3Vic2NyaXB0aW9uIG9wdGlvbnM6Cmh0dHBzOi8vYWRtaW4u ZmVkb3JhcHJvamVjdC5vcmcvbWFpbG1hbi9saXN0aW5mby91c2VycwpHdWlkZWxpbmVzOiBodHRw Oi8vZmVkb3JhcHJvamVjdC5vcmcvd2lraS9NYWlsaW5nX2xpc3RfZ3VpZGVsaW5lcwpIYXZlIGEg cXVlc3Rpb24/IEFzayBhd2F5OiBodHRwOi8vYXNrLmZlZG9yYXByb2plY3Qub3JnCg==
--===============1646450951936019464==--
That just decodes to the "signature" which the list appends. namely....
users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
That's all....
Am 22.10.2012 10:19, schrieb Ed Greshko:
Whatever.... UFT-7 isn't widely used.... But if you want to use it go ahead. Must be an Australian thing.... :-) :-)
special chars in imap folder names as example are UTF-7 you learn this by implement a dbmail-web-backend :-) http://php.net/manual/en/function.imap-utf7-decode.php
also notice http://en.wikipedia.org/wiki/UTF-7
On 10/22/2012 04:24 PM, Reindl Harald wrote:
Am 22.10.2012 10:19, schrieb Ed Greshko:
Whatever.... UFT-7 isn't widely used.... But if you want to use it go ahead. Must be an Australian thing.... :-) :-)
special chars in imap folder names as example are UTF-7 you learn this by implement a dbmail-web-backend :-) http://php.net/manual/en/function.imap-utf7-decode.php
also notice http://en.wikipedia.org/wiki/UTF-7
Actually, the mailbox names use a modified version of UTF-7. See RFC 3501. Note the areas where problems with using unmodified UTF-7 is discussed.
My statement was in regards to "email" messages. Still you get a "crap" vs. "crap" trade-off as shown in another message. I see many people whining about the message bodies being encoded in base64 or Q-P. It just doesn't bother me since I've been dealing with that for over 10 years here in Asia and I've got a toolbox that makes life a breeze.
Am 22.10.2012 11:08, schrieb Ed Greshko:
My statement was in regards to "email" messages. Still you get a "crap" vs. "crap" trade-off as shown in another message. I see many people whining about the message bodies being encoded in base64 or Q-P. It just doesn't bother me
well, compare the size of plaintext with base64
1,4M 2012-10-22 11:15 test.base64 1,0M 2012-10-22 11:14 test.txt
have fun on low bandwidth and with IMAp quotas......
On 10/22/2012 05:16 PM, Reindl Harald wrote:
Am 22.10.2012 11:08, schrieb Ed Greshko:
My statement was in regards to "email" messages. Still you get a "crap" vs. "crap" trade-off as shown in another message. I see many people whining about the message bodies being encoded in base64 or Q-P. It just doesn't bother me
well, compare the size of plaintext with base64
1,4M 2012-10-22 11:15 test.base64 1,0M 2012-10-22 11:14 test.txt
have fun on low bandwidth and with IMAp quotas......
Another "strike" against using UTF-7 in emails to this list is that the messages "lose" information in the archives...
http://lists.fedoraproject.org/pipermail/users/2012-October/425826.html
Now, you tell me how someone trying to get information out of the archives is supposed to grok ...
Make yourself a script to launch skype with a compatibility library
+ACMAIQ-/bin/bash +ACM +ACM force preloading of a 32 bit video for linux 1 +ACM compatibility library for video for linux 2
LD+AF8-PRELOAD+AD0-/usr/lib/libv4l/v4l1compat.so skype
CRAP....
Am 22.10.2012 11:20, schrieb Ed Greshko:
On 10/22/2012 05:16 PM, Reindl Harald wrote:
Am 22.10.2012 11:08, schrieb Ed Greshko:
My statement was in regards to "email" messages. Still you get a "crap" vs. "crap" trade-off as shown in another message. I see many people whining about the message bodies being encoded in base64 or Q-P. It just doesn't bother me
well, compare the size of plaintext with base64
1,4M 2012-10-22 11:15 test.base64 1,0M 2012-10-22 11:14 test.txt
have fun on low bandwidth and with IMAp quotas......
Another "strike" against using UTF-7 in emails to this list is that the messages "lose" information in the archives...
http://lists.fedoraproject.org/pipermail/users/2012-October/425826.html
Now, you tell me how someone trying to get information out of the archives is supposed to grok ...
no, something MANGELED the message this is a bug in whatever piece of software did it
the argumentation that somewhere is a bug is a reason to change standards is broken - the bug has to be fixed not a valid encoding
On 10/22/2012 05:25 PM, Reindl Harald wrote:
Am 22.10.2012 11:20, schrieb Ed Greshko:
On 10/22/2012 05:16 PM, Reindl Harald wrote:
Am 22.10.2012 11:08, schrieb Ed Greshko:
My statement was in regards to "email" messages. Still you get a "crap" vs. "crap" trade-off as shown in another message. I see many people whining about the message bodies being encoded in base64 or Q-P. It just doesn't bother me
well, compare the size of plaintext with base64
1,4M 2012-10-22 11:15 test.base64 1,0M 2012-10-22 11:14 test.txt
have fun on low bandwidth and with IMAp quotas......
Another "strike" against using UTF-7 in emails to this list is that the messages "lose" information in the archives...
http://lists.fedoraproject.org/pipermail/users/2012-October/425826.html
Now, you tell me how someone trying to get information out of the archives is supposed to grok ...
no, something MANGELED the message this is a bug in whatever piece of software did it
the argumentation that somewhere is a bug is a reason to change standards is broken - the bug has to be fixed not a valid encoding
It isn't mangled. It is stored as UTF-7.
[egreshko@meimei ~]$ echo "+ACMAIQ-/bin/bash" | iconv -f utf7 -t utf8 #!/bin/bash
Now, you can either argue that the list server software needs to be "fixed" or "configured" to do the transformation so you can continue to use your UTF-7..... Or you can be a "good citizen" and use UTF-8....at least until the problem that you're going to bugzilla is fixed.
On Mon, 2012-10-22 at 17:33 +0800, Ed Greshko wrote:
you can either argue that the list server software needs to be "fixed" or "configured" to do the transformation so you can continue to use your UTF-7..... Or you can be a "good citizen" and use UTF-8....at least until the problem that you're going to bugzilla is fixed.
I would argue that HTML archives need to transcode incoming text into what ever the website servers the archives out, or that each archived email in a page needs to be served with the appropriate headers for the content that it's serving. The former would be the easiest, particularly as all page content needs to be the same (message, and all the frippery around it that makes an email in an webpage with links, and things). It is wrong to serve webpages that are supposedly encoded in one scheme, but actually in another.
If the complaint is about users wanting to text scrape their own mail spools, then they need to use tools which scrape the data in the encoding that it actually is stored in. Either a multi-encoding-capable tool is required (since mail can come in any form), or the local mail needs to be written to the scheme the user wants to use.
Personally I have no great desire to have to use UTF-7, it was just picked as a choice that was supposed to be a good one. Since this has become a debacle, I've changed it. But they should all "just work" in modern clients, though they will fail when users start forcing an encoding type in their reader, regardless of actual content type. The actual source code behind them shouldn't be a problem.
By the way, in this thread, see a series of messages by Ed Greshko, but with quotes from Reindl Harald that don't seem to be on the list. Yet there's, semi-obviously, been a discussion. Is this private replies being made public, or another of those strange list moderations?
On 10/22/2012 06:30 PM, Tim wrote:
By the way, in this thread, see a series of messages by Ed Greshko, but with quotes from Reindl Harald that don't seem to be on the list. Yet there's, semi-obviously, been a discussion. Is this private replies being made public, or another of those strange list moderations?
He is moderated. He sent to the list and Cc: me. I am not a fan of getting Cc: so I replied to all and removed him from the To:.
Am 22.10.2012 12:30, schrieb Tim:
By the way, in this thread, see a series of messages by Ed Greshko, but with quotes from Reindl Harald that don't seem to be on the list. Yet there's, semi-obviously, been a discussion. Is this private replies being made public, or another of those strange list moderations?
it is still the moderation where an excuse happended last week from the moderators for not release message without changing anything in the behavior after that......
so i am stil forced to use "reply all" to give answers any sense by push them in a timely manner to the question and hope some reply will push parts also to the list
Tim:
Discouraged by who? It's supposedly *the* answer to email
Ed Greshko:
Whatever....
Jerk...
UFT-7 isn't widely used.... But if you want to use it go ahead.
You said it's discouraged. I've never seen any such comment. Where do you find that advice?
On 10/22/2012 06:18 PM, Tim wrote:
Tim:
Discouraged by who? It's supposedly *the* answer to email
Ed Greshko:
Whatever....
Jerk...
Hummm.... Reduced to name calling. I thought that beneath you. :-)
UFT-7 isn't widely used.... But if you want to use it go ahead.
You said it's discouraged. I've never seen any such comment. Where do you find that advice?
I already gave you the link..... Contained within http://www.imc.org/imcr-010.html
Even though it is outdated....
FWIW, a stronger reason to not use UTF-7 is, as I've mentioned, is that it doesn't show up well in the archives. It is stored as direct UTF-7 and can't be read with ease. The web page is flagged at UTF-8 and even in Firefox you can't change the character set since that isn't one of the selectable options.
On Monday, 22. October 2012. 7.54.01 Ian Malone wrote:
Tim's email is UTF-7. Marko seems to be using gmail but getting plain text. The original looks okay on my gmail, maybe try changing the gmail display language to English? Or use the 'message text garbled' drop-down option for the messahe.
Umm, I'm using KMail to view messages, and I avoid looking at gmail's webmail interface as much as possible... ;-)
KMail, however, does not offer UTF-7 as an encoding option.
Best, :-) Marko
Marko Vojinovic wrote:
On Sunday, 21. October 2012. 19.21.02 Tim wrote:
+ACMAIQ-/bin/bash +ACM +ACM force preloading of a 32 bit video for linux 1 +ACM compatibility library for video for linux 2 LD+AF8-PRELOAD+AD0-/usr/lib/libv4l/v4l1compat.so skypeWhat is this +A stuff?
Seems to be some form of protection when a line starts with a # (that's a pound or hash sign) something translates it to an international symbol, +A followed by a multi-character code meaningful to someone.
+ACM This line started with four characters, plus, A, C, M.
On 21 October 2012 09:51, Tim ignored_mailbox@yahoo.com.au wrote:
Hi,
Just a heads up, in case anyone else decides (against all sanity) to try using Skype, *and* get a webcam working, on 64-bit Fedora 17, you get stymied by:
Skype being only released in 32 bit Skype wanting video for Linux 1 Fedora 17 uses video for Linux 2 Web pages offering advice for Mint and Ubuntu
So, yum install libv4l-(whatever).i686. In my case, today, that was:
yum install libv4l-0.8.8-2.fc17.i686
Make yourself a script to launch skype with a compatibility library
#!/bin/bash # # force preloading of a 32 bit video for linux 1 # compatibility library for video for linux 2
LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so skype
Okay, using the 'static' version (it's dynamically linked, but it seems some libraries must have been statically linked) on F16 I can get by *without* libv4l.i686 installed (trying to remove the x86_64 version for completeness would result in removing about half my system). On F16 libtiff.so.4 is needed but not available, a symlink to version 3 seems to work. Tried: skype_static-2.2.0.35 skype_staticQT-4.0.0.8 Both show the webcam okay with a logitech C720.
-
Bill Davidsen -
Ed Greshko -
Frank Murphy -
Ian Malone -
Marko Vojinovic -
Reindl Harald -
Tim