Re: [gentoo-user] Broken localepurge
On Friday 20 March 2015 09:14:42 I wrote: On Thursday 19 March 2015 11:15:55 Fernando Rodriguez wrote: On Thursday, March 19, 2015 10:15:58 AM Peter Humphrey wrote: Meanwhile, does anyone here have a ready fix? Looks like Jan-Matthias does. You can just apply the patch directly to the localepurge script. patch /usr/bin/localepurge localepurge-0.5.4-fix_option_parsing.patch Yes, I saw that and downloaded it, then tried calling it from the ebuild. There are five other patches already, and I haven't yet found the right place in the sequence to add this one. Still working on it... I found the problem: the line count was wrong in the patch file. Once I'd fixed that, all was hunky-dory. I've submitted the corrected patch to the bug report. -- Rgds Peter.
Re: [gentoo-user] Broken localepurge
On Friday 20 March 2015 13:02:39 Fernando Rodriguez wrote: On Friday, March 20, 2015 10:33:29 AM Peter Humphrey wrote: I've submitted the corrected patch to the bug report. It applied cleanly for me. I tried it before replying. That's good - thanks. You will have seen that I asked for progress in getting a revision 3 out, but I think it'll be hampered by this: * QA Notice: This ebuild installs into paths that should be created at runtime. * To fix, simply do not install into these directories. Instead, your package * should create dirs on the fly at runtime as needed via init scripts/etc... * * var/cache * var/cache/localepurge * var/cache/localepurge/localelist I'll have to think some more about how to fix that. Should be simple enough if I can remember enough bash. -- Rgds Peter.
[gentoo-user] Re: Is this a bug in firefox-36.0?
On 03/19/2015 05:15 PM, »Q« wrote: The OCSP server experienced an internal error. (Error code: sec_error_ocsp_server_error) The page you are trying to view cannot be shown because the authenticity of the received data could not be verified. Why didn't you say so? ;) Enter about:config in the address bar, search for security.OCSP.require and toggle it to false, which is the default (Mozilla's shipped default, at least). Very interesting, thanks. Now that I have an expert's brain to pick :) maybe you can answer two more questions for me: I know I didn't change that flag myself, but something did. Do you know if firefox extensions/addons can change the items in about:config? Second, I fixed the problem once by rebooting my wireless router, but got the same error again early this morning -- which I fixed once again by rebooting my wireless router. This makes me worry that somebody out there in the evil internet might be changing the security settings of my router (which is owned by my ISP and has remotely updateable firmware). Thanks again.
[gentoo-user] Re: crossdev setup questions for distcc usage
Walter Dnes waltdnes at waltdnes.org writes:
PORTDIR_OVERLAY=/usr/local/portage ${PORTDIR_OVERLAY}
PORTDIR is deprecated, from my understanding as to the new
schemes for repos and the namespaces[1]. We're in a transition,
so this might be an excellent issue to flush out with the devs[2].
As soon as you (cross)compile with more than one
core, things that work and do not work seem to often be ambiguous
on the results. From what I've experienced over the years and read,
it may be best to keep the flag setting extremely conservative
and test your results before using more aggressively experimental
configurations. I have not done much of this since I built some
i586 (amdintel) binaries for minimized gentoo systems quite a few
years ago.
I'm interested in exactly what you are doing, plus extending the
cross compile to arm architectures and running on top of clusters
of gentoo systems; please continue to post back what you discover.
For this sort of (cluster compiling) experimentation, folks build custom
'frameworks' so you might have some luck adding 'framework' to your keyword
searches related to distributed compiling.
I have several old 586 and 686 based systems laying around,
so I can duplicate and verify your results if you like. Also, lots
of linux distros compile for target 386 binaries so they run everywhere; it
might be a good resources if you can find where one of those niche linux
distros describe how they cross compile for their periodic releases.
ZeroChaos (gentoo dev) releases i686 codes for pentoo, so that might be
another source of expertise you can use as a guide.[3]
hth,
James
[1] {gentoo-dev} Naming of repositories (3/14/15)
[2] https://wiki.gentoo.org/wiki/Project:Portage/Sync
[3] http://www.pentoo.ch/download/tools_list_i686_2014_0_RC3_5
Re: [gentoo-user] Re: unwanted cursor change
150316 Nikos Chantziaras wrote: On 16/03/15 03:58, Philip Webb wrote: Yesterday, I updated to gtk+-3.14.9 , which required installation of x11-themes/adwaita-icon-theme . This new unwanted pkg created a dir under /usr/share/cursors/xorg-x11 a symbolic link 'default-Adwaita', which changed my mouse cursor. Not liking the new cursor, I did some research, found the dir responsible, did 'mv default default-dft', restarted X restored the old cursor. This looks to me like a bug. Does anyone have comments before I file it ? I don't think any cursor package should be setting the default on its own. Looks like a bug. Most people don't notice, because they have a cursor theme set in the preferences of their desktop environment and thus the default symlink does nothing, but that doesn't mean it should be set by a package. I have submitted Bug # 543902 . -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
[gentoo-user] Re: Is this a bug in firefox-36.0?
On Fri, 20 Mar 2015 17:18:23 -0700 walt w41...@gmail.com wrote: On 03/19/2015 05:15 PM, »Q« wrote: The OCSP server experienced an internal error. (Error code: sec_error_ocsp_server_error) The page you are trying to view cannot be shown because the authenticity of the received data could not be verified. Why didn't you say so? ;) Enter about:config in the address bar, search for security.OCSP.require and toggle it to false, which is the default (Mozilla's shipped default, at least). Very interesting, thanks. Now that I have an expert's brain to pick :) maybe you can answer two more questions for me: I know I didn't change that flag myself, but something did. Do you know if firefox extensions/addons can change the items in about:config? I won't cop to being an expert! But yes, extensions can change settings, and AFAIK if/when that happens there is no way to tell what extension has done what to them. If an extension changed that particular setting, I'd guess it would be an extension meant to tighten security. Second, I fixed the problem once by rebooting my wireless router, but got the same error again early this morning -- which I fixed once again by rebooting my wireless router. This makes me worry that somebody out there in the evil internet might be changing the security settings of my router (which is owned by my ISP and has remotely updateable firmware). Sorry, I have no idea how to investigate that.
Re: [gentoo-user] Broken localepurge
On Friday, March 20, 2015 10:33:29 AM Peter Humphrey wrote: On Friday 20 March 2015 09:14:42 I wrote: On Thursday 19 March 2015 11:15:55 Fernando Rodriguez wrote: On Thursday, March 19, 2015 10:15:58 AM Peter Humphrey wrote: Meanwhile, does anyone here have a ready fix? Looks like Jan-Matthias does. You can just apply the patch directly to the localepurge script. patch /usr/bin/localepurge localepurge-0.5.4-fix_option_parsing.patch Yes, I saw that and downloaded it, then tried calling it from the ebuild. There are five other patches already, and I haven't yet found the right place in the sequence to add this one. Still working on it... I found the problem: the line count was wrong in the patch file. Once I'd fixed that, all was hunky-dory. I've submitted the corrected patch to the bug report. It applied cleanly for me. I tried it before replying. -- Fernando Rodriguez
Re: [gentoo-user] unable to compile kdelibs in arm chroot
On Friday, March 20, 2015 10:15:03 AM Michael Mair-Keimberger wrote: On Thu, Mar 19, 2015 at 04:44:55PM -0400, Fernando Rodriguez wrote: On Thursday, March 19, 2015 9:11:02 PM Michael Mair-Keimberger wrote: Hi List, For the last few weeks i was playing around with my newly acquired raspberry pi 2. While it was pretty easy to setup a working gentoo stage3 system i failed installing anything below the basic packages. Generally my idea was building the arm packages on any system and provide them as binary packages for other raspberry pi's (yeah, i already bought my second rpi :D) At first, my idea was to build all the packages directly on the rpi. (with /var/tmp /usr/portage on a external harddisk). However, the compile times are worse than i expected so i abandoned the idea. Next i've played around with crossdev. It sort of worked, but i never could finish compiling xorg-server. (or basic system packages) Even though i've started over and over with different settings, there were always packages which failed to compile thus doesn't let me finish xorg-server. I might look into it some other day but now i just wanted something working. Now i'm playing with using qemu-arm [1][2] in order to compile the packages inside a chroot. This is - so far - the most promising method building packages, even though the compile times are worse than with crossdev, but still better than directly on the rpi. So far i finally could compile xorg-server and also updated the whole system, which, at this point, wasn't much anyway. My next goal was kde. I've compiled about half of all packages which are required for kdebase-meta, but now i'm stuck at kdelibs and i have no idea what's wrong. The problem: The problem is, the compile doesn't fail - it just hangs/stops. At some point (which seems to be random - it can stop anywhere between 1% and 100% of the compile) the compile stops and does nothing. I've waited hours, but nothing happened. So far i tried lots of things, for example: * MAKEOPTS=-j1 and/or FEATURES=-sandbox * also tried without building binary packages (-buildpkg) * /var/tmp on tmpfs * using: ebuild /usr/portage/kde-base//kdelibsebuild compile * using python3.3 instead of default 2.7 * moved it on a different system and tried building it there (again with many different settings) Nothing worked, even though the build moved until 100% two times (-_-) I have no idea what the problem is. Even qtwebkit, which took way longer to compile (about 3 hours) compiled on the first try. (which should exclude temperate and/or resource problems) I also don't think it's a problem with a use flag as the build stops anywhere - i couldn't find a pattern. It seems to be completely random. Any ideas whats wrong or how to fix this? Any help would be much appreciated as i'm out of ideas :( Thx [1] https://www.gentoo.org/proj/en/base/embedded/handbook/?part=1chap=5 [2] http://wiki.gentoo.org/wiki/Crossdev_qemu-static-user-chroot One possibility is swap trashing (running so low in RAM that every instruction takes several swaps to execute), especially with /var/tmp on tmpfs! This can happen even if you don't have a swap partition. Try with either more RAM or /var/tmp on a physical filesystem. Usually /var/tmp is on the physical filesystem anyway. I've tried it just once or twice because i though about a performance problem. RAM shouldn't be a problem too as i'm having 16GB of RAM available. I would tell you to attach a debugger and see if you can tell why it's hanging but that may not be worth the trouble (since it'll be a child process that's hanging it'll be tricky to start qemu with the gdb stub just for that process). If you want to try it see: http://tinkering-is-fun.blogspot.com/2009/12/debugging-non-native-programs-with-qemu.html and search QEMU_GDB for the tricky part. Have you tried a different qemu version? -- Fernando Rodriguez
[gentoo-user] ntfs-3g: NTFS partition not recognised under Windows (solution for the archives)
Hi all, I just wanted to post this for the archives because I never found a solution from searching the internet (plenty of me too's, though). Perhaps this information will help somebody out there. I was having trouble with an NTFS formatted external HDD (USB 2.0, with an MBR). I was the primary user, and accessed it using ntfs3g. It used to work flawlessly under Windows, but stopped working at some point. Well, it turned out that *something* had set the partition type to 83 (Linux). Switching it back to type 7 (HPFS/NTFS/EXFAT) got it to work correctly under Windows again (without breaking Linux, of course)! This also alleviated my growing concerns with ntfs3g. I don't know for sure what the culprit was. I vaguely remember having the drive split 50/50 between NTFS and ext4 at some point, but got rid of ext4 again because ntfs3g seemed to behave well enough (or maybe for some other more concrete reason). Maybe GParted screwed up when writing the partition table and kept the 83 type from the ext4 partition? *shrug* Greetings -- Marc Joliet -- People who think they know everything really annoy those of us who know we don't - Bjarne Stroustrup pgpLYW0P3vlkV.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-user] Overlay for wickr
On Mon, Mar 16, 2015 at 08:49:18AM +0200, Matti Nykyri wrote:
On Mar 16, 2015, at 8:28, Mick michaelkintz...@gmail.com wrote:
I've looked at zugaina too and didn't find anything, hence I asked here.
I'll
file a bug at some point, unless anyone beats me to it.
Writing an ebuild to do the install is like 5 min job :) I'm now in a train
only with a phone, but when i get home i can write you one.
Just my opinion... I would never ever trust non open source encryption
software. Everyting published isn't true :)
Ok... No I'm happily back home after circling around the World ;)
Doing the ebuild was a bit more tricky... The program has bad bugs :(
The wickr executable is linked against icu-52, but in the archive the libraries
are libicui18n-53 - had to make symbolic link
Also the symboltable in wickr had to be altered.
And the ebuild:
- Clip ---
EAPI=5
inherit eutils
DESCRIPTION=Wickr Top-Secret Messenger
HOMEPAGE=https://www.wickr.com/downloads/;
SRC_URI=x86? ( http://mywickr.info/download.php?p=332 - ${P}_i386.deb )
amd64? ( http://mywickr.info/download.php?p=364 - ${P}_amd64.deb )
LICENCE=
SLOT=0
KEYWORDS=~amd64 ~x86
IUSE=x86 amd64
RDEPEND=sys-libs/glibc
sys-devel/gcc
sys-apps/util-linux
media-sound/pulseaudio
src_unpack() {
mkdir ${S}
cd ${S}
ar x ${DISTDIR}/${A}
}
src_install() {
cd ${D}
tar --same-owner --preserve-permissions -xof ${S}/data.tar.xz
if use x86 ; then
MY_OFFSET=332312
elif use amd64 ; then
MY_OFFSET=393763
fi
echo 3 | dd of=usr/bin/wickr bs=1 count=1 seek=${MY_OFFSET}
conv=notrunc
cd usr/lib/wickr
ln -s libicui18n.so.53 libicui18n.so.52
}
- Clip ---
After correcting those the software segfaults in libQt5core.so that is provided
in the archive... So you probably need Qt5 installed.
--
-Matti
Re: [gentoo-user] Broken localepurge
On Thursday 19 March 2015 11:15:55 Fernando Rodriguez wrote: On Thursday, March 19, 2015 10:15:58 AM Peter Humphrey wrote: Meanwhile, does anyone here have a ready fix? Looks like Jan-Matthias does. You can just apply the patch directly to the localepurge script. patch /usr/bin/localepurge localepurge-0.5.4-fix_option_parsing.patch Yes, I saw that and downloaded it, then tried calling it from the ebuild. There are five other patches already, and I haven't yet found the right place in the sequence to add this one. Still working on it... -- Rgds Peter.
Re: [gentoo-user] unable to compile kdelibs in arm chroot
On Thu, Mar 19, 2015 at 04:44:55PM -0400, Fernando Rodriguez wrote: On Thursday, March 19, 2015 9:11:02 PM Michael Mair-Keimberger wrote: Hi List, For the last few weeks i was playing around with my newly acquired raspberry pi 2. While it was pretty easy to setup a working gentoo stage3 system i failed installing anything below the basic packages. Generally my idea was building the arm packages on any system and provide them as binary packages for other raspberry pi's (yeah, i already bought my second rpi :D) At first, my idea was to build all the packages directly on the rpi. (with /var/tmp /usr/portage on a external harddisk). However, the compile times are worse than i expected so i abandoned the idea. Next i've played around with crossdev. It sort of worked, but i never could finish compiling xorg-server. (or basic system packages) Even though i've started over and over with different settings, there were always packages which failed to compile thus doesn't let me finish xorg-server. I might look into it some other day but now i just wanted something working. Now i'm playing with using qemu-arm [1][2] in order to compile the packages inside a chroot. This is - so far - the most promising method building packages, even though the compile times are worse than with crossdev, but still better than directly on the rpi. So far i finally could compile xorg-server and also updated the whole system, which, at this point, wasn't much anyway. My next goal was kde. I've compiled about half of all packages which are required for kdebase-meta, but now i'm stuck at kdelibs and i have no idea what's wrong. The problem: The problem is, the compile doesn't fail - it just hangs/stops. At some point (which seems to be random - it can stop anywhere between 1% and 100% of the compile) the compile stops and does nothing. I've waited hours, but nothing happened. So far i tried lots of things, for example: * MAKEOPTS=-j1 and/or FEATURES=-sandbox * also tried without building binary packages (-buildpkg) * /var/tmp on tmpfs * using: ebuild /usr/portage/kde-base//kdelibsebuild compile * using python3.3 instead of default 2.7 * moved it on a different system and tried building it there (again with many different settings) Nothing worked, even though the build moved until 100% two times (-_-) I have no idea what the problem is. Even qtwebkit, which took way longer to compile (about 3 hours) compiled on the first try. (which should exclude temperate and/or resource problems) I also don't think it's a problem with a use flag as the build stops anywhere - i couldn't find a pattern. It seems to be completely random. Any ideas whats wrong or how to fix this? Any help would be much appreciated as i'm out of ideas :( Thx [1] https://www.gentoo.org/proj/en/base/embedded/handbook/?part=1chap=5 [2] http://wiki.gentoo.org/wiki/Crossdev_qemu-static-user-chroot One possibility is swap trashing (running so low in RAM that every instruction takes several swaps to execute), especially with /var/tmp on tmpfs! This can happen even if you don't have a swap partition. Try with either more RAM or /var/tmp on a physical filesystem. Usually /var/tmp is on the physical filesystem anyway. I've tried it just once or twice because i though about a performance problem. RAM shouldn't be a problem too as i'm having 16GB of RAM available. -- Fernando Rodriguez -- greetings Michael signature.asc Description: Digital signature
