Re: [gentoo-user] Unwelcomed non-native language support
2015-05-30 18:56 GMT+03:00 rhan...@gmx.de: On 30/05/15 16:56, gevisz wrote: 2015-05-30 15:02 GMT+03:00 gevisz gev...@gmail.com: So, I can update the system and see if the unneeded gettext package will be emerged again. :-) Yes, it was merged back. Why ... to keep an unneeded dependency in the portage tree? Because some package needs gettext. None of my two-fullscreen dependency packages really need it. You might check if upstream or the ebuild can be patched to make the dependency optional or search for alternatives. Good advice. :) I have to read the dev's manual first, I guess. Anyway, I was intended to do it someday, when I'll have some free time during the winter...
[gentoo-user] Re: Difficulties to acchieve a certain time period with fcron
Alan McKinnon alan.mckinnon at gmail.com writes: On 29/05/2015 18:12, Meino.Cramer at gmx.de wrote: I am makeing definetly something very wrong here...but I the logic seems to prevent me to do the rigth ting... *cron* are limited. You need advanced logic constructs to achieve what you want. Bash is most likely your easiest path. Sounds like a job for anacron. What you want to do is way outside what the various cron daemons were built to do. Here's how I would do it: Run a wrapper script once a day (you do not care when exactly). The wrapper script creates a state file every time it runs the job the says when it last ran. Each time the script starts, it checks this file and figures out itself if it needs to run now or not. All good advice. There are many example scripts about time triggering and counting days to then trigger your desired script. The construct to track elapsed time that I use, is just a simple accumulator. Once it is full then you trigger your script and zero out the accumulator and start it all over again There are many logic constructs that will do what your want. Just hack away! When my mesos work is ready for other, there is a fantastic replacement, call chronos [1] that will fit your needs nicely. Fortunately for embedded guys like yourself, you'll be able to keep your cluster 'live' on milliwatts of power on a small embedded board, then trigger relays or such to boot up other boxes, as the cluster (down to a minimal embedded board) ramps ups to server your needs. I'm making lots of progress; but the more I get working the more I discover that I need other codes and modules. Maybe you can run the aforementioned anacron on one of your arm boards, for now? Maybe if you wrote your script in Haskell [2], one of the really smart guys would help you debug and get it working (correctly?). Have Fun, James [1] http://nerds.airbnb.com/introducing-chronos/ [2] http://www.haskellforall.com/2015/01/use-haskell-for-shell-scripting.html
Re: [gentoo-user] Unwelcomed non-native language support
2015-05-30 18:54 GMT+03:00 Peter Humphrey pe...@prh.myzen.co.uk: On Saturday 30 May 2015 13:57:34 gevisz wrote: 2015-05-30 12:32 GMT+03:00 Marc Joliet mar...@gmx.de: Am Sat, 30 May 2015 11:36:28 +0300 schrieb gevisz gev...@gmail.com: [...] (Note: the word you are looking for is cache.) So, it is from French. [OT] Yes, along with a vast number of other common words in English; they came along with the Normans in 1066 and afterwards. Far more than from German or Dutch, and those are far more than from Spanish or Italian. [/OT] When I learned it in high school, this word was not in our vocabulary. :-) I strongly suspect that the application doing the translating doesn't even use gettext. May be, but I cannot think of a better explanation. Besides which, I'm surprised you're not getting crashes from applications not finding the gettext libraries, which points to them not actually using it. Nothing crashed so far and this, in my view, proves that should not be an obligatory dependency for any package in my wold file. You can use emerge --depclean -pv gettext to determine which do. $ emerge --depclean -pv gettext --- Couldn't find 'gettext' to depclean. No packages selected for removal by depclean However, running # equery depends gettext before forcefully unmerging the gettext package, I got the following response: * These packages depend on gettext: --8 I have gettext installed, and pretending to depclean it showed 77 packages depending on it. I see it's similar for you. So it seems to me that gettext is a false lead and that the root of your problem lies somewhere else. May be, but as I have already written it, I cannot think of a better explanation why started in a default profile Firefox uses non-English menu, but started in a new profile, it uses the English menu for the same youtube video on the same web-page. Have you tried a revdep-rebuild recently? It seems to me that you need gettext put back in, and maybe other things too. Yes, it was merged back on the today's system update. I have already complained about it.
Re: [gentoo-user] Difficulties to acchieve a certain time period with fcron
On Friday, May 29, 2015 18:12:52 meino.cra...@gmx.de wrote: What I want is, that fcron executes a script every 14 days. It does not matter, when to execute the script, since I cannot guarantee that my PC is running exactly at that time. I've got a similar cron I run for backups (daily rather than bi-weekly) but it looks like this: %nightly,bootrun,random * 2-4 CMD What this tells fcron is to run nightly (meaning only one run is allowed in an evening, run at boot if it hasn't run and I just booted in the period, and randomly select a time between 2:00 and 4:00. Works great for my needs and if one is missed it gets picked up at boot as it should. Hope that helps but if not there's more in the man page: http://fcron.free.fr/doc/en/fcrontab.5.html Regards, -- Alex Brandt Software Developer for Rackspace and Developer for Gentoo http://blog.alunduil.com
Re: [gentoo-user] Re: Difficulties to acchieve a certain time period with fcron
On Sat, 30 May 2015 16:42:37 + (UTC), James wrote: *cron* are limited. You need advanced logic constructs to achieve what you want. Bash is most likely your easiest path. If you're using systemd, timer units would do what you want. They are more complex to set up than cron, but far more flexible, -- Neil Bothwick A printer consists of three main parts: the case, the jammed paper tray and the blinking red light. pgpF7aNdGhFYd.pgp Description: OpenPGP digital signature
Re: [gentoo-user] General weirdness - a tale of woe.
On Saturday 30 May 2015 16:43:13 Peter Humphrey wrote: On Saturday 30 May 2015 12:49:51 Mick wrote: On my laptop which has stayed on Kmail-1 I have this: ---8 Have a look here for more details and warnings: https://wiki.gentoo.org/wiki/KDE/KDEPIM-4.7_upgrade Many thanks Mick - that's very helpful. I expect that sooner or later bitrot will catch up with Kmail-1 and it will stop working. I dread for this happening, but I will not move to Kmail-2 until then. I don't blame you, and I wish I hadn't either. I'll see if it's possible to go back. Well, it did look promising right up to the last gasp. I put those package.mask entries in, and I found I needed a couple of package.use entries as well, and then everything went suspiciously well. Portage downgraded several packages and recompiled several others, and I was ready to go. At this point I must put in a word of commendation for portage: it handled this major regression with aplomb throughout. That is one professional program. I created a new user (this is now really tedious), started KMail-1 and imported 14000-odd messages from the old KMail-2 - and in a fraction of the time that KMail-2 takes for the same task. Great! I thought. Then I found there was no inbox to copy its e-mails into, and I couldn't copy the folder because one existed already - I just couldn't see it. I think I remember it disappearing once or twice before in the days of KMail-1. Anyway, I couldn't see a way forward so I've reverted to the original KMail-2 pro tem. Maybe I'll have another go if I remember the way out of having no inbox. Anyway, thanks Mick for steering me the way I wanted to go. -- Rgds Peter
Re: [gentoo-user] Difficulties to acchieve a certain time period with fcron
On 29/05/2015 18:12, meino.cra...@gmx.de wrote: Hi, probably I have made a knot into my brain... What I want is, that fcron executes a script every 14 days. It does not matter, when to execute the script, since I cannot guarantee that my PC is running exactly at that time. I tried b(1),mailto(root) * * */14 * * /home/user/bin/script.sh Which works according to this: On the 28.th the script was executed every miinute... But: If I specivy anything for the minute/hour field, it means: Do execute the script exeactly THEN. And this in turn I dont want. Which places my thoughts again right at the beginning of the cyclus... I am makeing definetly something very wrong here...but I the logic seems to prevent me to do the rigth ting... Or I am currently struck with blindness?? Sounds like a job for anacron. What you want to do is way outside what the various cron daemons were built to do. Here's how I would do it: Run a wrapper script once a day (you do not care when exactly). The wrapper script creates a state file every time it runs the job the says when it last ran. Each time the script starts, it checks this file and figures out itself if it needs to run now or not. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] What is the definition of a gentoo binary package?
On 30/05/2015 03:48, walt wrote: gory details of many frustrating hours of fighting with one particular gentoo package have been snipped to eliminate uncouth language I think of a gentoo binary package (e.g. oracle-jdk-bin) as an ebuild that fetches a file from somewhere, then merely unpacks that file and sticks the results in /opt/whatever. My experience today with libreoffice-bin has broken my mental model of how a gentoo binary package behaves. While trying to debug some broken behavior in the (non-binary) localc spreadsheet app, I decided to install libreoffice-bin as an experiment. The libreoffice-bin package wanted to drag in dozens of other non-binary gentoo packages before it would install itself, and even caused a blocker between two different versions of poppler. (I said no because I thought the blocker would make the entire experiment fail in the end.) Any thoughts from you gentoo gurus would be most appreciated. binary package is a fuzzy definition. It's a package that can be compiled (i.e. not purely shell scripts) but for whatever reason that is not viable for a large enough number of users. So a precompiled version is made available, and this is what we call a binary. Example reasons could be license restrictions that forbid redistributing sources (eg nvidia-drivers), or the damn thing just takes too bloody long to build (libreoffice). Either way, a binary package still has to work in the larger Gentoo ecosystem. It still has deps, blockers, even devs who commit bugs. A completely self-contained package that can never interfere with another package is NOT part of the definition, and reading between the lines I think you might have a part of that thinking lurking around in your mental model. Binary packages are more prone to break stuff than non-binary packages when viewing as a group. A binary package from a vendor may require specific versions of deps, or require a dep be built with certain config options for example - this can so easily interfere with what you already have installed and your choice of USE. With source packages, we can often work around this easily and patch stuff. With binary packages we all too often cannot and are stuck. Add in the Gentoo attitude where binary packages are the evil step-child that only serve expediency and the devs mostly won't change things to accomodate binary packages, and what you ran into is actually quite common. If you want to use a binary package, be prepared to compromise and change your system to accommodate it, as the other way round is often unfeasible. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] What is the definition of a gentoo binary package?
On Fri, May 29, 2015 at 10:11 PM, Andrew Savchenko birc...@gentoo.org wrote: On Fri, 29 May 2015 18:48:55 -0700 walt wrote: The libreoffice-bin package wanted to drag in dozens of other non-binary gentoo packages before it would install itself, and even caused a blocker between two different versions of poppler. (I said no because I thought the blocker would make the entire experiment fail in the end.) It requires many other packages because it was compiled with specific versions of that packages. Of course that other packages will be source ebuilds mostly. You have blockers because your current system have different versions of some of that packages. These issues are usually solved either via slot installs or update of your currently installed system. Sometimes emerge -DNu @world may be needed. Just a bit more explanation... Binary distros, like Debian, typically solve this problem by using releases. In a release most packages have fixed versions, especially those which have many reverse dependencies, like core libraries. When Debian 9 is being prepared for release, somebody will decide that it will use poppler version 0.35 or whatever is in vogue at the time, and so on. Then all the maintainers will build all the packages that use it against poppler-0.35. This prevents the blocker situation that you're witnessing. If there is a later security patch, any fixes will be backported as needed so that they can stay with poppler-0.35 which prevents them from having to update dozens or hundreds of other packages in some kind of coordinated mini-release. Eventually a new release comes along, and they update all of their packages in lockstep to a new set of versions, so that they reach a new consistent depgraph. Of course, they can use the equivalent of slots as well, so for some libraries they may support more than one specific version, but it is still coordinated in this manner. With Gentoo we're spoiled by the ability to generally be able to install arbitrary pairings of package versions, since we build everything from source and emerge will link everything against whatever we're using. When we do change a key dependency, then a combination of slot-operator-deps, preserved-rebuild, and revdep-rebuild will rebuild everything that breaks. Of course, we're still limited by API-compatibility and feature use, which puts some constraints on what we can install. We're even more limited when braindead upstreams don't properly use SONAMEs and such, which creates blockers that can't be resolved using slots. However, in general we get a lot of flexibility, which lets us keep most packages closer to upstream and we don't have to packport fixes to poppler-0.35 for 3 years since we can just use poppler-0.36 instead, and so on. However, the moment you start installing packages that use precompiled dynamic binaries we become just like Debian, except we DON'T use releases and thus we don't guarantee tree-wide compatibility with a very specific version of every library. So, once you start installing these packages you're much more likely to run into blockers and other issues, especially if you have a fair number of them. They exist for convenience, but you'll never get the full Gentoo experience using them, and if you're really looking to use a lot of standardized binary packages for everything, well, you're probably better-off with a distro designed with that in mind (ie, basically everybody else). -- Rich
Re: [gentoo-user] Unwelcomed non-native language support
2015-05-29 23:33 GMT+03:00 gevisz gev...@gmail.com: 2015-05-29 21:45 GMT+03:00 gevisz gev...@gmail.com: 2015-05-29 19:36 GMT+03:00 Mick michaelkintz...@gmail.com: On Friday 29 May 2015 17:20:13 gevisz wrote: 2015-05-29 17:46 GMT+03:00 Mick michaelkintz...@gmail.com: Do you get anything unexpected when you run 'locale'? Nothing. (Thank you for your question.) I have just re-read the Gentoo Localization Guide (https://wiki.gentoo.org/wiki/Localization/Guide) and checked what I have in my /etc/env.d/02locale file: every possible option, except for LC_COLLATE and LC_ALL, is set to en_US.UTF-8. Here is its full content: LANG=en_US.UTF-8 LC_CTYPE=en_US.UTF-8 LC_NUMERIC=en_US.UTF-8 LC_TIME=en_US.UTF-8 LC_COLLATE=C LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 LC_PAPER=en_US.UTF-8 LC_NAME=en_US.UTF-8 LC_ADDRESS=en_US.UTF-8 LC_TELEPHONE=en_US.UTF-8 LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=en_US.UTF-8 You probably don't need all these. Mine are: LANG=en_GB.UTF-8 LC_TIME=POSIX LC_COLLATE=C The rest are inherited from $LANG. Here is what I get from $ locale LANG=en_US.UTF-8 LC_CTYPE=en_US.UTF-8 LC_NUMERIC=en_US.UTF-8 LC_TIME=en_US.UTF-8 LC_COLLATE=C LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 LC_PAPER=en_US.UTF-8 LC_NAME=en_US.UTF-8 LC_ADDRESS=en_US.UTF-8 LC_TELEPHONE=en_US.UTF-8 LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=en_US.UTF-8 LC_ALL= I am almost giving up on this issue. Hmm ... this is rather odd. Just in case, you don't have in addition any LANG or LC_* entries in your .bashrc? No. Looked there as well. Now, I am going to forcefully unmerge the gettext package. Will report the results later. Reporting: after forcefully unmerging the gettext package, shutting down the system and booting it anew, I still get the described above menu in Firefox in one of the easten-european languages. As I still had a suspicion that those non-Eglish entries in the Firefox menu remain because of some cash issues, I have just launched another instance of the Firefox browser using a separate profile. Well, in a separate profile, the Firefox menu is in English while in the default profile it is in a non-English language. So, it could be a cash issue: I have unmerged the gettext while running Firefox and so its substitutions could be left somewhere in cash... P.S. As I have already described it earlier, this issue with the Firefox menu is only related to the menu I get while right-clicking on a youtube video in Firefox. (All the other menus is in English, as desired.)
Re: [gentoo-user] General weirdness - a tale of woe.
On 29/05/2015 17:54, Mick wrote: On Friday 29 May 2015 16:28:57 Alan Grimes wrote: Mick wrote: On Friday 29 May 2015 10:36:37 Peter Humphrey wrote: I had two sets of problems: one in KDE which I might have nailed finally [1], and one at boot time in which /dev/md7 (RAID-1 with metadata 1.0) was not being started. [1]Whenever I've had KMail screw up I've created a new user and re-imported its 14,000 e-mails, and until this latest time I've copied the .mozilla directory from the old user to the new. This time I did not, and so far all looks rosy. I'm not counting any chickens yet though. Did you try deleting the akonadi database file(s) and restarting it instead of creating a new user? You will have to be patient, probably let it run overnight to asynchronously sync and re-index all your messages. What in god's name is that stupid database for anyway? Does it perform any useful function? Is there any tool that gives the user any measurable benefit that even justifies one one hundredth of the CPU and disk bandwidth consumed by this missfeature? I think you're preaching to the converted here. I don't think you'll find many advocates in this M/L who support the KDE4 desktop design decision as a sound architectural choice for your average Linux user. I think they were trying to market a desktop for the enterprise and were following Gnome's approach of semantic content searches. Other than the odd bug here and there I was perfectly happy with KDE3 and Kmail1 (still using with kde-base/kdepim-meta-4.4.11.1-r1). Akonadi was supposed to be a once-size-fits-all central store of all pim info (contacts, addresses, mails and all metadata about that) which any and all apps could use. The vision was that an enormous awesome ecosystem all buying into the OneGrandVision(tm) would spontaneously spring up, thereby validating the existence of akonadi itself due to a magic self-fulfilling prophecy. This did not happen. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] General weirdness - a tale of woe.
On Sat, 30 May 2015 00:20:51 +0100, Peter Humphrey wrote: He was talking about tying the e-mail client to a database, not about the KDE4 desktop, and I've protested at the same thing more than once, sometimes in vigorous terms. Made no difference of course, but then I'm just an insufficiently humble user. I can see the point in using a database to index mails for faster searching, but relying on it for the mail program to work is plain daft. -- Neil Bothwick Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning. -- Rich Cook pgpGJSh7UGOUP.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Unwelcomed non-native language support
On 30/05/15 11:36, gevisz wrote: P.S. As I have already described it earlier, this issue with the Firefox menu is only related to the menu I get while right-clicking on a youtube video in Firefox. (All the other menus is in English, as desired.) Have you checked the language settings at the bottom of the site? The menu you get is from the site and not from firefox.
Re: [gentoo-user] Unwelcomed non-native language support
2015-05-30 13:02 GMT+03:00 rhan...@gmx.de: On 30/05/15 11:36, gevisz wrote: P.S. As I have already described it earlier, this issue with the Firefox menu is only related to the menu I get while right-clicking on a youtube video in Firefox. (All the other menus is in English, as desired.) Have you checked the language settings at the bottom of the site? I do not know how to do that. The menu you get is from the site and not from firefox. Yes, but according to the link, provided by Marc, it contains gettext instruction for its translation according to the locale set on the local computer. I get this issue for all youtube videos, either on youtube or embedded into the html code on other web-sites: right-clicking the video brings the menu in a non-English language. (One of its entries in English is Get embedded code.) Moreover, if the menu is from the site and not from firefox, why I get it in English from the other instance of the Firefox run in the same environment?
Re: [gentoo-user] Unwelcomed non-native language support
2015-05-30 13:57 GMT+03:00 gevisz gev...@gmail.com: I strongly suspect that the application doing the translating doesn't even use gettext. May be, but I cannot think of a better explanation. Besides which, I'm surprised you're not getting crashes from applications not finding the gettext libraries, which points to them not actually using it. Nothing crashed so far and this, in my view, proves that should not be an obligatory dependency for any package in my wold file. Correction: Nothing crashed so far and this, in my view, proves that should not be an obligatory dependency *on gettext* for any package in my wold file.
Re: [gentoo-user] Unwelcomed non-native language support
Am Sat, 30 May 2015 13:57:34 +0300 schrieb gevisz gev...@gmail.com: This document shows how websites can localise their content: https://developer.mozilla.org/en-US/docs/Web_Localizability/Creating_localizable_web_applications. Thank you for the link. I will look at it in more detail later, but from the first look, the recommended localization method is using gettext. Yes, but they are referring to *server side* use of gettext, e.g., when generating a website using a template system, as is often done with Python or PHP or ... -- Marc Joliet -- People who think they know everything really annoy those of us who know we don't - Bjarne Stroustrup pgpm90In0LoIV.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-user] General weirdness - a tale of woe.
On Saturday 30 May 2015 00:20:51 Peter Humphrey wrote: Other than the odd bug here and there I was perfectly happy with KDE3 and Kmail1 (still using with kde-base/kdepim-meta-4.4.11.1-r1). I wonder if there's a way to go back to KMail-1 and import all my e-mails from KMail-2 archive files into it. Would you like to help me, Mick, with ebuilds etc? On my laptop which has stayed on Kmail-1 I have this: $ cat /etc/portage/package.mask =kde-base/akonadiconsole-4.5.50 =kde-base/akregator-4.5.50 =kde-base/blogilo-4.5.50 =kde-base/kabcclient-4.5.50 =kde-base/kaddressbook-4.5.50 =kde-base/kalarm-4.5.50 =kde-base/kdepim-common-libs-4.5.50 =kde-base/kdepim-icons-4.5.50 =kde-base/kdepim-l10n-4.5.50 =kde-base/kdepim-kresources-4.5.50 =kde-base/kdepim-meta-4.5.50 =kde-base/kdepim-strigi-analyzer-4.5.50 =kde-base/kdepim-runtime-4.5.50 =kde-base/kdepim-wizards-4.5.50 =kde-base/kjots-4.5.50 =kde-base/kleopatra-4.5.50 =kde-base/kmail-4.5.50 =kde-base/knode-4.5.50 =kde-base/knotes-4.5.50 =kde-base/konsolekalendar-4.5.50 =kde-base/kontact-4.5.50 =kde-base/korganizer-4.5.50 =kde-base/ktimetracker-4.5.50 I don't know if going back to Kmail-1 from Kmail-2 is a viable proposal. Some of the Kmail-1 packages have abi_x86_32 dependencies, so expect some rebuilding of e.g. sys-libs/readline-6.3_p8-r2 I performed it a number of times on an old laptop, which would not work with Kmail-2, but this was done some years ago. In each case I restored my Mail folder from back up and eventually gave up on Kmail-2. Have a look here for more details and warnings: https://wiki.gentoo.org/wiki/KDE/KDEPIM-4.7_upgrade I expect that sooner or later bitrot will catch up with Kmail-1 and it will stop working. I dread for this happening, but I will not move to Kmail-2 until then. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Unwelcomed non-native language support
Am Sat, 30 May 2015 14:59:12 +0300 schrieb gevisz gev...@gmail.com: 2015-05-30 14:31 GMT+03:00 rhan...@gmx.de: On 30/05/15 14:07, gevisz wrote: [...] No. It's about localizing web pages with gettext. gettext is on the server side. The server sets a locale for the session and then localizes your page accordingly via calls to gettext before you even get the page. Basically on your first visit yt tries to guess your locale based on several parameters. Mainly the Accept-Language http header (the thing in Settings-Content which you already found). It stores whatever your current setting is in your cookies and whenever you visit yt or have a video embedded in some site this cookie determines the language for yt content. Ok, thank you for explanation. If the localization is done on the server side, then cleaning the cookies should help and it indeed helped: the menu returned to its English view as soon as I deleted all my cookies from youtube. Moreover, if the menu is from the site and not from firefox, why I get it in English from the other instance of the Firefox run in the same environment? It probably uses the same cookies. Probably you meant the different cookies. [1] http://youtube.com Too late get your explanation about checking the yt language. Now, after deleting all youtube cookies, it is set to English as desired. Great that you got it to work :) . -- Marc Joliet -- People who think they know everything really annoy those of us who know we don't - Bjarne Stroustrup pgpSHEBmF9Mlc.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-user] Unwelcomed non-native language support
2015-05-30 12:32 GMT+03:00 Marc Joliet mar...@gmx.de: Am Sat, 30 May 2015 11:36:28 +0300 schrieb gevisz gev...@gmail.com: [...] As I still had a suspicion that those non-English entries in the Firefox menu remain because of some cash issues, I have just launched another instance of the Firefox browser using a separate profile. Well, in a separate profile, the Firefox menu is in English while in the default profile it is in a non-English language. So, it could be a cash issue: I have unmerged the gettext while running Firefox and so its substitutions could be left somewhere in cash... P.S. As I have already described it earlier, this issue with the Firefox menu is only related to the menu I get while right-clicking on a youtube video in Firefox. (All the other menus is in English, as desired.) (Note: the word you are looking for is cache.) So, it is from French. When I learned it in high school, this word was not in our vocabulary. :-) I strongly suspect that the application doing the translating doesn't even use gettext. May be, but I cannot think of a better explanation. Besides which, I'm surprised you're not getting crashes from applications not finding the gettext libraries, which points to them not actually using it. Nothing crashed so far and this, in my view, proves that should not be an obligatory dependency for any package in my wold file. You can use emerge --depclean -pv gettext to determine which do. $ emerge --depclean -pv gettext --- Couldn't find 'gettext' to depclean. No packages selected for removal by depclean However, running # equery depends gettext before forcefully unmerging the gettext package, I got the following response: * These packages depend on gettext: app-admin/abrt-2.0.12-r2 (=sys-devel/gettext-0.17) app-admin/gtkdiskfree-2.0.1-r1 (nls ? sys-devel/gettext) app-arch/tar-1.27.1-r2 (nls ? =sys-devel/gettext-0.10.35) app-cdr/brasero-3.12.0 (sys-devel/gettext) app-cdr/xfburn-0.5.2 (sys-devel/gettext) app-crypt/gcr-3.14.0 (sys-devel/gettext) app-crypt/gnupg-2.0.26-r3 (nls ? sys-devel/gettext) app-crypt/libsecret-0.18 (sys-devel/gettext) app-crypt/pinentry-0.9.0 (sys-devel/gettext) app-editors/gvim-7.4.273 (nls ? sys-devel/gettext) %%% Even gvim! And it definitely does not crash without gettext. app-editors/mousepad-0.3.0 (sys-devel/gettext) app-editors/vim-7.4.273 (nls ? sys-devel/gettext) app-emulation/wine-1.6.2 (nls ? sys-devel/gettext) (nls ? =sys-devel/gettext-0.18.3.2[abi_x86_32(-)]) app-i18n/enca-1.14-r2 (sys-devel/gettext) app-misc/mc-4.8.13 (nls ? sys-devel/gettext) app-misc/tracker-1.2.5 (=sys-devel/gettext-0.17) app-portage/eix-0.30.4 (nls ? sys-devel/gettext) app-text/aspell-0.60.6.1-r1 (nls ? sys-devel/gettext) app-text/dos2unix-6.0.6 (nls ? sys-devel/gettext) app-text/enscript-1.6.6 (nls ? sys-devel/gettext) app-text/evince-3.14.2 (sys-devel/gettext) app-text/gnome-doc-utils-0.20.10-r1 (sys-devel/gettext) app-text/hunspell-1.3.3 (sys-devel/gettext) app-text/iso-codes-3.57 (sys-devel/gettext) app-text/opensp-1.5.2-r3 (nls ? sys-devel/gettext) app-text/recode-3.6_p20-r1 (nls ? sys-devel/gettext) dev-lang/yasm-1.2.0-r1 (nls ? sys-devel/gettext) dev-libs/atk-2.14.0 (nls ? sys-devel/gettext) dev-libs/elfutils-0.158 (nls ? sys-devel/gettext) dev-libs/gjs-1.42.0 (sys-devel/gettext) dev-libs/glib-2.42.2 (=sys-devel/gettext-0.11) dev-libs/json-glib-1.0.2-r1 (=sys-devel/gettext-0.18) dev-libs/libcdio-0.92 (sys-devel/gettext) dev-libs/libcdio-paranoia-0.90_p1-r1 (sys-devel/gettext) dev-libs/libgpg-error-1.13 (nls ? sys-devel/gettext) dev-libs/libpwquality-1.2.4 (=sys-devel/gettext-0.18.2) dev-libs/libreport-2.0.13-r1 (=sys-devel/gettext-0.17) dev-libs/popt-1.16-r2 (nls ? sys-devel/gettext) dev-scheme/guile-1.8.8-r1 (sys-devel/gettext) dev-util/dialog-1.2.20150225 (nls ? sys-devel/gettext) dev-util/intltool-0.50.2-r1 (sys-devel/gettext) dev-util/kbuild-0.1.9998_pre20131130 (sys-devel/gettext) dev-vcs/git-2.3.6 (nls ? sys-devel/gettext) gnome-base/dconf-0.22.0 (sys-devel/gettext) gnome-base/gnome-desktop-3.14.2 (sys-devel/gettext) gnome-base/gnome-keyring-3.14.0 (sys-devel/gettext) gnome-base/gsettings-desktop-schemas-3.14.1 (sys-devel/gettext) gnome-base/libgnome-keyring-3.12.0 (sys-devel/gettext) gnome-base/nautilus-3.14.2-r1 (sys-devel/gettext) gnome-extra/polkit-gnome-0.105-r1 (sys-devel/gettext) gnome-extra/yelp-xsl-3.14.0 (sys-devel/gettext) media-gfx/dcraw-9.24.4 (nls ? sys-devel/gettext) media-gfx/exiv2-0.24-r1 (nls ? sys-devel/gettext) media-gfx/gimp-2.8.14 (=sys-devel/gettext-0.19) media-gfx/graphviz-2.26.3-r4 (nls ? =sys-devel/gettext-0.14.5) media-libs/clutter-1.20.0 (=sys-devel/gettext-0.17) media-libs/clutter-gtk-1.6.0 (=sys-devel/gettext-0.18) media-libs/cogl-1.18.2-r1 (sys-devel/gettext) media-libs/flac-1.3.1-r1 (!elibc_uclibc ? sys-devel/gettext) media-libs/gst-plugins-bad-0.10.23-r2 (nls ? =sys-devel/gettext-0.17) media-libs/gst-plugins-bad-1.4.5
Re: [gentoo-user] Unwelcomed non-native language support
On 30/05/15 14:07, gevisz wrote: I do not know how to do that. Go to [1], scroll to the bottom. There should be some settings for yt language. Yes, but according to the link, provided by Marc, it contains gettext instruction for its translation according to the locale set on the local computer. I get this issue for all youtube videos, either on youtube or embedded into the html code on other web-sites: right-clicking the video brings the menu in a non-English language. (One of its entries in English is Get embedded code.) No. It's about localizing web pages with gettext. gettext is on the server side. The server sets a locale for the session and then localizes your page accordingly via calls to gettext before you even get the page. Basically on your first visit yt tries to guess your locale based on several parameters. Mainly the Accept-Language http header (the thing in Settings-Content which you already found). It stores whatever your current setting is in your cookies and whenever you visit yt or have a video embedded in some site this cookie determines the language for yt content. Moreover, if the menu is from the site and not from firefox, why I get it in English from the other instance of the Firefox run in the same environment? It probably uses the same cookies. [1] http://youtube.com
Re: [gentoo-user] Unwelcomed non-native language support
2015-05-30 14:31 GMT+03:00 rhan...@gmx.de: On 30/05/15 14:07, gevisz wrote: I do not know how to do that. Go to [1], scroll to the bottom. There should be some settings for yt language. Yes, but according to the link, provided by Marc, it contains gettext instruction for its translation according to the locale set on the local computer. I get this issue for all youtube videos, either on youtube or embedded into the html code on other web-sites: right-clicking the video brings the menu in a non-English language. (One of its entries in English is Get embedded code.) No. It's about localizing web pages with gettext. gettext is on the server side. The server sets a locale for the session and then localizes your page accordingly via calls to gettext before you even get the page. Basically on your first visit yt tries to guess your locale based on several parameters. Mainly the Accept-Language http header (the thing in Settings-Content which you already found). It stores whatever your current setting is in your cookies and whenever you visit yt or have a video embedded in some site this cookie determines the language for yt content. Ok, thank you for explanation. If the localization is done on the server side, then cleaning the cookies should help and it indeed helped: the menu returned to its English view as soon as I deleted all my cookies from youtube. Moreover, if the menu is from the site and not from firefox, why I get it in English from the other instance of the Firefox run in the same environment? It probably uses the same cookies. Probably you meant the different cookies. [1] http://youtube.com Too late get your explanation about checking the yt language. Now, after deleting all youtube cookies, it is set to English as desired.
Re: [gentoo-user] Unwelcomed non-native language support
Am Sat, 30 May 2015 11:36:28 +0300 schrieb gevisz gev...@gmail.com: [...] As I still had a suspicion that those non-Eglish entries in the Firefox menu remain because of some cash issues, I have just launched another instance of the Firefox browser using a separate profile. Well, in a separate profile, the Firefox menu is in English while in the default profile it is in a non-English language. So, it could be a cash issue: I have unmerged the gettext while running Firefox and so its substitutions could be left somewhere in cash... P.S. As I have already described it earlier, this issue with the Firefox menu is only related to the menu I get while right-clicking on a youtube video in Firefox. (All the other menus is in English, as desired.) (Note: the word you are looking for is cache.) I strongly suspect that the application doing the translating doesn't even use gettext. Besides which, I'm surprised you're not getting crashes from applications not finding the gettext libraries, which points to them not actually using it. You can use emerge --depclean -pv gettext to determine which do. In my case, firefox does *not* show up, despite me using nls (neither does adobe-flash, in case you're using that). (I also thought that maybe firefox bundles gettext, but the only references I could find on developer.mozilla.org pertain to localising websites with php and the like, and not to firefox-internal technologies.) So it seems to me that gettext is a false lead and that the root of your problem lies somewhere else. This document shows how websites can localise their content: https://developer.mozilla.org/en-US/docs/Web_Localizability/Creating_localizable_web_applications. -- Marc Joliet -- People who think they know everything really annoy those of us who know we don't - Bjarne Stroustrup pgpi3ljYn6ySl.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-user] General weirdness - a tale of woe.
On Saturday 30 May 2015 09:53:23 Alan McKinnon wrote: Akonadi was supposed to be a once-size-fits-all central store of all pim info (contacts, addresses, mails and all metadata about that) which any and all apps could use. The vision was that an enormous awesome ecosystem all buying into the OneGrandVision(tm) would spontaneously spring up, thereby validating the existence of akonadi itself due to a magic self-fulfilling prophecy. This did not happen. Nor will it. It's long since time they had another think. -- Rgds Peter
Re: [gentoo-user] Unwelcomed non-native language support
2015-05-30 14:36 GMT+03:00 Marc Joliet mar...@gmx.de: Am Sat, 30 May 2015 13:57:34 +0300 schrieb gevisz gev...@gmail.com: This document shows how websites can localise their content: https://developer.mozilla.org/en-US/docs/Web_Localizability/Creating_localizable_web_applications. Thank you for the link. I will look at it in more detail later, but from the first look, the recommended localization method is using gettext. Yes, but they are referring to *server side* use of gettext, e.g., when generating a website using a template system, as is often done with Python or PHP or ... Ok, thank you for explanation about the server side localization. Now, after deleting all youtube cookies the issue is solved. :-) So, I can update the system and see if the unneeded gettext package will be emerged again. :-)
Re: [gentoo-user] Unwelcomed non-native language support
2015-05-30 15:02 GMT+03:00 gevisz gev...@gmail.com: So, I can update the system and see if the unneeded gettext package will be emerged again. :-) Yes, it was merged back. Why ... to keep an unneeded dependency in the portage tree?
Re: [gentoo-user] General weirdness - a tale of woe.
On Saturday 30 May 2015 12:49:51 Mick wrote: On my laptop which has stayed on Kmail-1 I have this: ---8 Have a look here for more details and warnings: https://wiki.gentoo.org/wiki/KDE/KDEPIM-4.7_upgrade Many thanks Mick - that's very helpful. I expect that sooner or later bitrot will catch up with Kmail-1 and it will stop working. I dread for this happening, but I will not move to Kmail-2 until then. I don't blame you, and I wish I hadn't either. I'll see if it's possible to go back. -- Rgds Peter
Re: [gentoo-user] Unwelcomed non-native language support
On Saturday 30 May 2015 13:57:34 gevisz wrote: 2015-05-30 12:32 GMT+03:00 Marc Joliet mar...@gmx.de: Am Sat, 30 May 2015 11:36:28 +0300 schrieb gevisz gev...@gmail.com: [...] (Note: the word you are looking for is cache.) So, it is from French. [OT] Yes, along with a vast number of other common words in English; they came along with the Normans in 1066 and afterwards. Far more than from German or Dutch, and those are far more than from Spanish or Italian. [/OT] When I learned it in high school, this word was not in our vocabulary. :-) I strongly suspect that the application doing the translating doesn't even use gettext. May be, but I cannot think of a better explanation. Besides which, I'm surprised you're not getting crashes from applications not finding the gettext libraries, which points to them not actually using it. Nothing crashed so far and this, in my view, proves that should not be an obligatory dependency for any package in my wold file. You can use emerge --depclean -pv gettext to determine which do. $ emerge --depclean -pv gettext --- Couldn't find 'gettext' to depclean. No packages selected for removal by depclean However, running # equery depends gettext before forcefully unmerging the gettext package, I got the following response: * These packages depend on gettext: --8 I have gettext installed, and pretending to depclean it showed 77 packages depending on it. I see it's similar for you. So it seems to me that gettext is a false lead and that the root of your problem lies somewhere else. May be, but as I have already written it, I cannot think of a better explanation why started in a default profile Firefox uses non-English menu, but started in a new profile, it uses the English menu for the same youtube video on the same web-page. Have you tried a revdep-rebuild recently? It seems to me that you need gettext put back in, and maybe other things too. -- Rgds Peter
Re: [gentoo-user] Unwelcomed non-native language support
On 30/05/15 16:56, gevisz wrote: 2015-05-30 15:02 GMT+03:00 gevisz gev...@gmail.com: So, I can update the system and see if the unneeded gettext package will be emerged again. :-) Yes, it was merged back. Why ... to keep an unneeded dependency in the portage tree? Because some package needs gettext. You might check if upstream or the ebuild can be patched to make the dependency optional or search for alternatives.
