Re: [gentoo-user] masking asterisk 11
On Tuesday 21 Apr 2015 06:36:58 Florian Gamböck wrote: Hi Joseph, I don't see any lower version of asterisk-11 in the tree, so if you don't have an overlay that specifically provides the version you are looking for, portage has no other choice than to select the masked one. And it infact DOES take your mask into account, note the # in the emerge output, it just can't figure out an alternative for you. Greetings --Flo Add the old version ebuild in your local overlay before you try to emerge it again. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] Re: gcc-5.0 ?
Neil Bothwick neil at digimed.co.uk writes: On Tue, 21 Apr 2015 17:09:37 + (UTC), james wrote: Also, I have not found a gcc-5.0 or gcc-5.1 in an overlay (yet), eix -R -e gcc shows several options, the mpst recent of which appears to be 5.0.0_alpha20150322 from the toolchain overlay. Wow, I never tried the -R option. Very Very cool! I was really hoping for 5.1; maybe the name of a dev on the edge? How do you tell if a ~ is actually based on the nightlies, 5.1 or is just old ebuild with the . extension somebody never got around to renaming or deleting? Look at [4] chromiumos layman/chromiumos and tell me (edumacate me?) James
Re: [gentoo-user] stable java virtuals require unstable java packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am Dienstag, 21. April 2015, 15:37:34 schrieb gottl...@nyu.edu: On Tue, Apr 21 2015, Florian Gamböck wrote: Am 21.04.2015 um 07:42 schrieb Alan McKinnon: It's either a bug in virtual/jdk-1.7 ebuild or more likely, stable request for icedtead-bin-7 is lagging behind. You are right, the stable request is still going on: https://bugs.gentoo.org/show_bug.cgi?id=546902 Obviously the virtual got stableized a bit too fast. I was going to ask about this too. I noticed that the virtual/jdk-1.7 actually gives a choice of jdk's. One of them dev-java/oracle-jdk-bin does have a stable 1.7 version (indeed also a stable 1.8). I am not anxious to switch oracle-*. allan This is a typical problem with virtuals. A virtual can (by definition) be stable as soon as one of its providers is stable. Which one does not matter, and stabilization can be pretty much automatic and be done by any dev. So, after oracle-* went stable the virtual went stable too. Now portage is trying to upgrade it and can only resolve that by either keywording icedtea-bin or switching to oracle. Which solution it ends up with differs between portage versions, I suspect... This should be improved, obviously, but it's not a trivial issue. My personal advice (without knowing the packages in detail)- if you dont want to switch to oracle, just accept the keywording suggestion from portage and give the suggested ~arch icedtea-bin a try. Don't worry too much about mixing stable and testing (as long as it's only for a few packages). - -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0 iQJ8BAEBCgBmBQJVNpkzXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0RkJDMzI0NjNBOTIwMDY5MTQ2NkMzNDBF MTM4NkZEN0VGNEI1Nzc5AAoJEOE4b9fvS1d5C/YP/RYqNB+w+ZyK39oclbNGHSS+ mJPx1uPkYn1JR09WWkH0rpxERu0vOHxTVqntar1PRxF3/tJ7XBXhEbfa7S/Ezo+x wQi+2rNfNzaeDFIkFR/VMyu8GK/zP1zLGedVXtbWGsThiOGVjgylNxihKKtRqqFd RrF5NKJJ8ZqU940dVuZHcj8IPGZG2hWut/xKckDUYKcCwx+EhiOlBznF+qu62wnb yPDYCTIRhhRfyB7vOW0IJnqtLbCXdEHTS5Ip2N9R3cGrJiwYZMXcM+uZQoL1fpkQ x7nkthV1KzCvPsO5VsANpS1F2D1fblRHwXUAeyNmmCc1VzMgKn5d2L3uJQbxopMA IQVKWiIYb2rG+4n6i7JFqOA0MKwh0tAoNpYiYG4BaVQW+72ydx1R1zFzMX9eYav9 d4UakgUuAp2Se902PGDaM9sdiq4gcR3Ox2tM4CGr9+DFTzr/umF92OHEGMverK12 +TeozP4vloOJ0I+p3Z89BNe4CHnv71MtlM74NEq14MmSEdABek0WFOXvBkJB6ZFR zKPD2upcdxuaMYqJNTUGBL0uDQkfDdVIEtWcXapUGc0OL9lh8OCa/PPy0pZO5JmQ XdqOVjaPO2mryI4UT5J8sp4mM1zmOIHIe820Tjg72ZxzJ5iwgcHooHz1r+Cd5Yt1 PT4vFCCPaMksuhY5B4QR =x6Fh -END PGP SIGNATURE-
Re: [gentoo-user] abi_x86_32 FLAG
On Tue, Apr 21, 2015 at 2:14 PM, Heiko Baums li...@baums-on-web.de wrote: Am 21.04.2015 um 20:06 schrieb Mike Gilbert: On Mon, Apr 20, 2015 at 7:51 PM, Heiko Baums li...@baums-on-web.de wrote: Am 21.04.2015 um 01:27 schrieb Mike Gilbert: Better yet, upgrade to grub:2 already. Why? As long as grub legacy is working there's no need to upgrade. I'm still running grub legacy, too. In this context, because you can build it without having any 32-bit libs installed. That's what grub-static is for. So why would I upgrade to grub:2 if grub:0 is still working? You don't have to, other than avoiding stuff like this, or for the additional features. While all the guides seem to be written around grub2-mkconfig you can still use grub the old way and just create your own config file. Grub2 is more flexible in terms of supported filesystems and such - which is helpful if you're using lvm, mdadm, btrfs, and so on. However, I don't think it accepts the old config file syntax so there is some effort required to migrate. You'll of course want a rescue boot device (but I'd say that applies whether you're migrating or not). I started out with a grub1-like approach and ended up moving to the grub2 style. I just install my kernels with make install and then let grub2-mkconfig set up my config files. The only issue I found is that if you're playing with git kernels it doesn't always order the versioning right (a.b.c+ isn't a.b.c and things like this). However, you can add your own rules to get entries auto-created which can be helpful. -- Rich
Re: [gentoo-user] abi_x86_32 FLAG
On Tue, Apr 21, 2015 at 2:14 PM, Heiko Baums li...@baums-on-web.de wrote: Am 21.04.2015 um 20:06 schrieb Mike Gilbert: On Mon, Apr 20, 2015 at 7:51 PM, Heiko Baums li...@baums-on-web.de wrote: Am 21.04.2015 um 01:27 schrieb Mike Gilbert: Better yet, upgrade to grub:2 already. Why? As long as grub legacy is working there's no need to upgrade. I'm still running grub legacy, too. In this context, because you can build it without having any 32-bit libs installed. That's what grub-static is for. So why would I upgrade to grub:2 if grub:0 is still working? Maybe because you don't like running static binaries that were built on somebody else's system. I'm just suggesting grub:2 as an alternative.
[gentoo-user] Re: gcc-5.0 ?
Neil Bothwick neil at digimed.co.uk writes: eix -R -e gcc shows several options, the mpst recent of which appears to be 5.0.0_alpha20150322 from the toolchain overlay. Interesting situation. I have about half a dozen overlays set up via layman. Zugaina does not cleanly sync for me: snip Reading category 167|167 (100%) Finished [6] 'zugaina' /var/lib/layman/zugaina (cache: parse|ebuild*#metadata-md5#metadata-assign#assign) Reading category 69|167 ( 41%): games-simulation .. * ERROR: games-simulation/secondlife-1.22.1_rc::zugaina failed (depend phase): * EAPI=0 is not supported * * Call stack: * ebuild.sh, line 584: Called source '/var/lib/layman/zugaina/games-simulation/secondlife/secondlife-1.22.1_rc.ebuild' end_snip 1. How do I skip the games portion of zugaina overlays ? 2.' eix -R -e gcc' yeilds: [1] AstroFloyd layman/AstroFloyd [2] OSSDL layman/OSSDL [3] ROKO__ layman/ROKO__ [4] chromiumos layman/chromiumos [5] dlang layman/dlang [6] embedded-cross layman/embedded-cross [7] funtoo-overlay layman/funtoo-overlay [8] gentoo-arm layman/gentoo-arm [9] heroxbd layman/heroxbd [10] maggu2810-overlay layman/maggu2810-overlay [11] sabayon-distro layman/sabayon-distro [12] sekh layman/sekh Do our overlay lists matchup completely? Does the -R always check the latest, or is their some updating syntax to ensure the remotes are updated? James
Re: [gentoo-user] abi_x86_32 FLAG
On Mon, Apr 20, 2015 at 7:51 PM, Heiko Baums li...@baums-on-web.de wrote: Am 21.04.2015 um 01:27 schrieb Mike Gilbert: Better yet, upgrade to grub:2 already. Why? As long as grub legacy is working there's no need to upgrade. I'm still running grub legacy, too. In this context, because you can build it without having any 32-bit libs installed.
Re: [gentoo-user] abi_x86_32 FLAG
Am 21.04.2015 um 20:06 schrieb Mike Gilbert: On Mon, Apr 20, 2015 at 7:51 PM, Heiko Baums li...@baums-on-web.de wrote: Am 21.04.2015 um 01:27 schrieb Mike Gilbert: Better yet, upgrade to grub:2 already. Why? As long as grub legacy is working there's no need to upgrade. I'm still running grub legacy, too. In this context, because you can build it without having any 32-bit libs installed. That's what grub-static is for. So why would I upgrade to grub:2 if grub:0 is still working?
Re: [gentoo-user] stable java virtuals require unstable java packages
On Tue, Apr 21, 2015 at 8:42 AM, Alan McKinnon alan.mckin...@gmail.com wrote: On 21/04/2015 07:28, Alexander Kapshuk wrote: Is it normal for a stable virtual to require an unstable package? No, that is definitely not how virtuals should work. It's either a bug in virtual/jdk-1.7 ebuild or more likely, stable request for icedtead-bin-7 is lagging behind. I know the java team is badly understaffed, lots of mentions on -dev, so maybe log a stable request but against icedtea-bin-7 Running 'emerge -auND' generates the following output on my system: Calculating dependencies ... done! [ebuild NS ~] dev-java/icedtea-bin-7.2.5.3 [6.1.13.5] USE=X alsa cups nsplugin -cjk -doc -examples (-selinux) -source -webstart [ebuild NS] virtual/jdk-1.7.0 [1.6.0-r2] [ebuild NS] virtual/jre-1.7.0 [1.6.0-r1] [ebuild U ~] dev-java/icedtea-web-1.5.1-r1 [1.4.2] USE=icedtea7%* -tagsoup% The following keyword changes are necessary to proceed: (see package.accept_keywords in the portage(5) man page for more details) # required by virtual/jdk-1.7.0::gentoo # required by virtual/jre-1.7.0::gentoo # required by sys-libs/db-4.8.30-r2::gentoo[java] # required by dev-libs/redland-1.0.16::gentoo[berkdb] # required by app-office/libreoffice-4.4.1.2::gentoo # required by @selected # required by @world (argument) =dev-java/icedtea-bin-7.2.5.3 ~x86 # required by dev-java/icedtea-bin-7.2.5.3::gentoo[nsplugin] # required by virtual/jdk-1.7.0::gentoo # required by virtual/jre-1.7.0::gentoo # required by sys-libs/db-4.8.30-r2::gentoo[java] # required by dev-libs/redland-1.0.16::gentoo[berkdb] # required by app-office/libreoffice-4.4.1.2::gentoo # required by @selected # required by @world (argument) =dev-java/icedtea-web-1.5.1-r1 ~x86 /usr/portage/virtual/jre/jre-1.7.0.ebuild:12 =virtual/jdk-1.7.0* /usr/portage/virtual/jdk/jdk-1.7.0.ebuild:12,13 =dev-java/icedtea-bin-7* =dev-java/icedtea-7* Thanks. -- Alan McKinnon alan.mckin...@gmail.com Understood. Thanks.
[gentoo-user] A bash-based CPU governor/speed-control utility
Thanks to everybody who answered my questions; I've got it working. This mailing list seems to reject emails with executable attachments, so I had to convert it to a .txt file before attaching the script to this post. Instructions for making it runnable... 1) gunzip or zcat the attachment to extract cpugov.txt 2) rename it to cpugov 3) insert the line... #!/bin/bash ...as the first line at the top of the file 4) chmod 755 cpugov 5) move it to /usr/local/bin or other appropriate subdirectory The script understands 2 options... cpugov list cpugov set The list option can be run by an ordinary user. It lists available options. The set option needs to write to /sys pseudo-file space, and therefore requires root or su/sudo permissions. It lists available options, and waits for you to enter a number and hit ENTER to select that option. If the current governor is userspace, available speeds will be listed as well. If you don't see speeds listed, you need to first... cpugov set ...and select the number corresponding to userspace. Then run cpugov again. I don't see a major need for specific speed selection, but I included it for completeness. The governors should handle your needs as follows... * powersave - runs CPUs at slowest speeds for longest battery life * performance - runs CPUs at maximum speeds. Work gets done faster but the battery discharges faster, too. * conservative - this is the recommended governor. It gradually adjusts speeds to match workload For completeness, the remaining 2 governors are... * ondemand - similar to conservative, but reacts faster. * userspace - you're in charge. You get to pick-n-choose the speeds you want when you want them. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications cpugov.txt.gz Description: Binary data
Re: [gentoo-user] gcc-5.0 ?
On Tue, 21 Apr 2015 17:09:37 + (UTC), james wrote: Also, I have not found a gcc-5.0 or gcc-5.1 in an overlay (yet), eix -R -e gcc shows several options, the mpst recent of which appears to be 5.0.0_alpha20150322 from the toolchain overlay. -- Neil Bothwick Hard work has a future payoff. Laziness pays off NOW! pgp1psdUlNgkV.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: gcc-5.0 ?
On Tue, 21 Apr 2015 19:09:19 + (UTC), james wrote: Do our overlay lists matchup completely? Does the -R always check the latest, or is their some updating syntax to ensure the remotes are updated? eix-remote update -- Neil Bothwick Physics is like sex: sure, it may give some practical results, but that's not why we do it.Richard Feynman pgpXPnTWXtajG.pgp Description: OpenPGP digital signature
Re: [gentoo-user] cryptsetup wont use aes-xts:plain64
Finally! Am 2015-04-18 12:27, schrieb Marko Weber | 8000: hello list, i try to crypt a partition with cryptsetup. Yes, in Kernel i had all need things i think. CONFIG_CRYPTO=y CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_ALGAPI2=y CONFIG_CRYPTO_AEAD=m CONFIG_CRYPTO_AEAD2=y CONFIG_CRYPTO_BLKCIPHER=y CONFIG_CRYPTO_BLKCIPHER2=y CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_HASH2=y CONFIG_CRYPTO_RNG=m CONFIG_CRYPTO_RNG2=y CONFIG_CRYPTO_PCOMP=m CONFIG_CRYPTO_PCOMP2=y CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_MANAGER2=y CONFIG_CRYPTO_USER=m # CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set CONFIG_CRYPTO_GF128MUL=m CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_PCRYPT=m CONFIG_CRYPTO_WORKQUEUE=y CONFIG_CRYPTO_CRYPTD=m CONFIG_CRYPTO_MCRYPTD=m CONFIG_CRYPTO_AUTHENC=m CONFIG_CRYPTO_TEST=m CONFIG_CRYPTO_ABLK_HELPER=m CONFIG_CRYPTO_GLUE_HELPER_X86=m CONFIG_CRYPTO_CCM=m CONFIG_CRYPTO_GCM=m CONFIG_CRYPTO_SEQIV=m CONFIG_CRYPTO_CBC=y CONFIG_CRYPTO_CTR=m CONFIG_CRYPTO_CTS=m CONFIG_CRYPTO_ECB=m CONFIG_CRYPTO_LRW=m CONFIG_CRYPTO_PCBC=m CONFIG_CRYPTO_XTS=m CONFIG_CRYPTO_CMAC=m CONFIG_CRYPTO_HMAC=m CONFIG_CRYPTO_XCBC=m CONFIG_CRYPTO_VMAC=m CONFIG_CRYPTO_CRC32C=y CONFIG_CRYPTO_CRC32C_INTEL=m CONFIG_CRYPTO_CRC32=m CONFIG_CRYPTO_CRC32_PCLMUL=m CONFIG_CRYPTO_CRCT10DIF=y CONFIG_CRYPTO_CRCT10DIF_PCLMUL=m CONFIG_CRYPTO_GHASH=m CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=y CONFIG_CRYPTO_MICHAEL_MIC=m CONFIG_CRYPTO_RMD128=m CONFIG_CRYPTO_RMD160=m CONFIG_CRYPTO_RMD256=m CONFIG_CRYPTO_RMD320=m CONFIG_CRYPTO_SHA1=m CONFIG_CRYPTO_SHA1_SSSE3=m CONFIG_CRYPTO_SHA256_SSSE3=m CONFIG_CRYPTO_SHA512_SSSE3=m CONFIG_CRYPTO_SHA1_MB=m CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_TGR192=m CONFIG_CRYPTO_WP512=m CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL=m CONFIG_CRYPTO_AES=y CONFIG_CRYPTO_AES_X86_64=m CONFIG_CRYPTO_AES_NI_INTEL=m CONFIG_CRYPTO_ANUBIS=m CONFIG_CRYPTO_ARC4=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_BLOWFISH_COMMON=m CONFIG_CRYPTO_BLOWFISH_X86_64=m CONFIG_CRYPTO_CAMELLIA=m CONFIG_CRYPTO_CAMELLIA_X86_64=m CONFIG_CRYPTO_CAMELLIA_AESNI_AVX_X86_64=m CONFIG_CRYPTO_CAMELLIA_AESNI_AVX2_X86_64=m CONFIG_CRYPTO_CAST_COMMON=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST5_AVX_X86_64=m CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_CAST6_AVX_X86_64=m CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_DES3_EDE_X86_64=m CONFIG_CRYPTO_FCRYPT=m CONFIG_CRYPTO_KHAZAD=m CONFIG_CRYPTO_SALSA20=m CONFIG_CRYPTO_SALSA20_X86_64=m CONFIG_CRYPTO_SEED=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_SERPENT_SSE2_X86_64=m CONFIG_CRYPTO_SERPENT_AVX_X86_64=m CONFIG_CRYPTO_SERPENT_AVX2_X86_64=m CONFIG_CRYPTO_TEA=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_TWOFISH_COMMON=m CONFIG_CRYPTO_TWOFISH_X86_64=m CONFIG_CRYPTO_TWOFISH_X86_64_3WAY=m CONFIG_CRYPTO_TWOFISH_AVX_X86_64=m CONFIG_CRYPTO_DEFLATE=m CONFIG_CRYPTO_ZLIB=m CONFIG_CRYPTO_LZO=m CONFIG_CRYPTO_LZ4=m CONFIG_CRYPTO_LZ4HC=m CONFIG_CRYPTO_ANSI_CPRNG=m CONFIG_CRYPTO_DRBG_MENU=m CONFIG_CRYPTO_DRBG_HMAC=y # CONFIG_CRYPTO_DRBG_HASH is not set # CONFIG_CRYPTO_DRBG_CTR is not set CONFIG_CRYPTO_DRBG=m CONFIG_CRYPTO_USER_API=m CONFIG_CRYPTO_USER_API_HASH=m CONFIG_CRYPTO_USER_API_SKCIPHER=m CONFIG_CRYPTO_HASH_INFO=y # CONFIG_CRYPTO_HW is not set but when i try to use cryptsetup i get this: # cryptsetup -c aes-xts:plain64 -y -s 256 luksFormat /dev/mapper/VolGroup01-media2 WARNING! This will overwrite data on /dev/mapper/VolGroup01-media2 irrevocably. Are you sure? (Type uppercase yes): YES Enter passphrase: Verify passphrase: device-mapper: reload ioctl on failed: Invalid argument Failed to setup dm-crypt key mapping for device /dev/mapper/VolGroup01-media2. Check that kernel supports aes-xts:plain64 cipher (check syslog for more info). Any ideas? i built cryptsetup with this useflags: nls openssl python udev urandom cryptsetup --help shows me i am able to use the options Default compiled-in device cipher parameters: loop-AES: aes, Key 256 bits plain: aes-cbc-essiv:sha256, Key: 256 bits, Password hashing: ripemd160 LUKS1: aes-xts-plain64, Key: 256 bits, LUKS header hashing: sha1, RNG: /dev/random any help / ideas or knowledge welcome. best regards marko i got it working! cryptsetup -c aes-xts-plain -h sha256 -y -s 256 luksFormat /dev/mapper/VolGroup01-media2 But on writing a testfile of 4G with i get 22,9 Mb/sec. Is there a cipher/hash/keysize which alloows me a bit more write performance? marko
Re: [gentoo-user] Questions about cpu frequency utils scripting
for core in /sys/devices/system/cpu/cpu[0-9]*/ -- Emanuele Rusconi
Re: [gentoo-user] abi_x86_32 FLAG
On Mon, 20 Apr 2015 18:36:52 -0700, Daniel Frey wrote: Better yet, upgrade to grub:2 already. I only use grub2 on machines with EFI, and in my house that's only two... I can't stand how it tries to add things automatically. It actually got so annoying that I created a manual boot entry that is symlinked to the kernel I want to run. It was easier than trying to fight it all the time. GRUB2 doesn't add anything automatically, you have to run grub2-mkconfig to generate automatic entries. If you want to run that but not generate the automatic entries, chmod -x /etc/grub.d/10_linux. On the other hand, if you want to kee things simple on a UEFI box, remove GRUB altogether and use Gummiboot. I use GRUB on BIOS systems and Gummiboot on UEFI ones. The version of GRUB is whatever was current at the tome the system was set up. I never saw a reason to change a working system from legacy to GRUB2. That may be different now, but I retired the last of my legacy GRUB boxes earlier this month. -- Neil Bothwick Two rights don't make a wrong, they make an airplane. pgpCYTtxRaxn9.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Questions about cpu frequency utils scripting
On Tue, Apr 21, 2015 at 06:42:35AM -0400, Alec Ten Harmsel wrote for core in `ls /sys/devices/system/cpu/ | egrep cpu[0-9]+` This works great on my desktop with 12 cores. Can you please check whether Emanuele's solution works on your system? for core in /sys/devices/system/cpu/cpu[0-9]*/ I prefer simpler solutions. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] stable java virtuals require unstable java packages
On Tue, Apr 21 2015, Florian Gamböck wrote: Am 21.04.2015 um 07:42 schrieb Alan McKinnon: It's either a bug in virtual/jdk-1.7 ebuild or more likely, stable request for icedtead-bin-7 is lagging behind. You are right, the stable request is still going on: https://bugs.gentoo.org/show_bug.cgi?id=546902 Obviously the virtual got stableized a bit too fast. I was going to ask about this too. I noticed that the virtual/jdk-1.7 actually gives a choice of jdk's. One of them dev-java/oracle-jdk-bin does have a stable 1.7 version (indeed also a stable 1.8). I am not anxious to switch oracle-*. allan
[gentoo-user] Re: abi_x86_32 FLAG
On 2015-04-20, Mike Gilbert flop...@gentoo.org wrote: On Mon, Apr 20, 2015 at 6:47 PM, Heiko Baums li...@baums-on-web.de wrote: Am 21.04.2015 um 00:22 schrieb Joseph: I'm trying to update one of my amd64 (I use XFCE) and there are lot of package that require use flag: abi_x86_32 Which package is forcing new: abi_x86_32 flag? sys-boot/grub-0.97-r14 x11-drivers/nvidia-drivers Replace sys-boot/grub-0.97-r14 by sys-boot/grub-static-0.97-r12. Better yet, upgrade to grub:2 already. Grub only requires 32-bit ncurses. The rest is for acroread (which is a 32-bit app). -- Grant Edwards grant.b.edwardsYow! Are you still an at ALCOHOLIC? gmail.com
Re: [gentoo-user] stable java virtuals require unstable java packages
On 21/04/2015 20:54, Alexander Kapshuk wrote: On Tue, Apr 21, 2015 at 8:42 AM, Alan McKinnon alan.mckin...@gmail.com mailto:alan.mckin...@gmail.com wrote: On 21/04/2015 07:28, Alexander Kapshuk wrote: Is it normal for a stable virtual to require an unstable package? No, that is definitely not how virtuals should work. It's either a bug in virtual/jdk-1.7 ebuild or more likely, stable request for icedtead-bin-7 is lagging behind. I know the java team is badly understaffed, lots of mentions on -dev, so maybe log a stable request but against icedtea-bin-7 Running 'emerge -auND' generates the following output on my system: Calculating dependencies ... done! [ebuild NS ~] dev-java/icedtea-bin-7.2.5.3 [6.1.13.5] USE=X alsa cups nsplugin -cjk -doc -examples (-selinux) -source -webstart [ebuild NS] virtual/jdk-1.7.0 [1.6.0-r2] [ebuild NS] virtual/jre-1.7.0 [1.6.0-r1] [ebuild U ~] dev-java/icedtea-web-1.5.1-r1 [1.4.2] USE=icedtea7%* -tagsoup% The following keyword changes are necessary to proceed: (see package.accept_keywords in the portage(5) man page for more details) # required by virtual/jdk-1.7.0::gentoo # required by virtual/jre-1.7.0::gentoo # required by sys-libs/db-4.8.30-r2::gentoo[java] # required by dev-libs/redland-1.0.16::gentoo[berkdb] # required by app-office/libreoffice-4.4.1.2::gentoo # required by @selected # required by @world (argument) =dev-java/icedtea-bin-7.2.5.3 ~x86 # required by dev-java/icedtea-bin-7.2.5.3::gentoo[nsplugin] # required by virtual/jdk-1.7.0::gentoo # required by virtual/jre-1.7.0::gentoo # required by sys-libs/db-4.8.30-r2::gentoo[java] # required by dev-libs/redland-1.0.16::gentoo[berkdb] # required by app-office/libreoffice-4.4.1.2::gentoo # required by @selected # required by @world (argument) =dev-java/icedtea-web-1.5.1-r1 ~x86 /usr/portage/virtual/jre/jre-1.7.0.ebuild:12 =virtual/jdk-1.7.0* /usr/portage/virtual/jdk/jdk-1.7.0.ebuild:12,13 =dev-java/icedtea-bin-7* =dev-java/icedtea-7* Thanks. -- Alan McKinnon alan.mckin...@gmail.com mailto:alan.mckin...@gmail.com Understood. Thanks. Turns out the virtual is working as designed - see Andreas's post above I recall now a discussion on -dev about this ages ago, and a consensus emerged then to keep things as they currently are (changing it requires much effort and has all manner of effects on the tree). The actual rule is: A virtual can (by definition) be stable as soon as one of its providers is stable. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] cryptsetup wont use aes-xts:plain64
AES cipher algo (AES-NI) is the fastest if you have the necessary hardware. Twofish cipher algo (x86_64, 3-way parallel) is a close second, but will slow access down slightly. Serpent is also usably fast. CONFIG_CRYPTO_AES_NI_INTEL = ~200mb/s (limited by disk in my case) CONFIG_CRYPTO_TWOFISH_X86_64_3WAY = ~130mb/s `cryptsetup --cipher {twofish,aes}-xts-plain64 --key-size 512 --hash sha512 --iter-time 5000`
Re: [gentoo-user] abi_x86_32 FLAG
Am 21.04.2015 um 03:14 schrieb Joseph: I don't think grub is asking for it. I know it does, because grub-0.97 is 32 bit only software, and the package sys-boot/grub-0.97-r14 compiles grub from the sources with dynamic linking. So it needs 32 bit dependencies (packages with USE=abi_x86_32) incl. sys-devel/gcc. If you don't want to have any abi_x86_32 dependencies being installed on your system you need to replace sys-boot/grub-0.97-r14 by sys-boot/grub-static-0.97-r12, because this package contains the grub binary with static linking. The binary of sys-boot/grub-static again is precompiled by the sys-boot/grub-0.97-r14 ebuild with USE=static. So sys-boot/grub-static doesn't need any 32 bit dependencies (packages with USE=abi_x86_32).
Re: [gentoo-user] abi_x86_32 FLAG
Am 21.04.2015 um 03:30 schrieb cov...@ccs.covici.com: I was looking to my world update and I saw that none of my emul-linux packages will be removed and there are some packages which depend on them such as nvidia-drivers and the C compiler! So any reason to do anything, or just let portage sort things out as the packages remove their dependencies on emul-linux? It's actually explained in the news you can read with `eselect news read`. The short version: You need to first uninstall all emul-linux-x86* packages manually by running: # emerge -C emul-linux-x86* Then you need to do a world update which will tell you which packages will need USE=abi_x86_32.
Re: [gentoo-user] Questions about cpu frequency utils scripting
On 04/20/2015 09:05 PM, Walter Dnes wrote: Another item I'm missing is wildcarding directories in bash. The selected values are applied to the CPUs in a loop that goes like so... for core in /sys/devices/system/cpu/cpu[0-9]/ do echo ${governor[${choiceminus}]} ${core}cpufreq/scaling_governor echo -n CPU ${core:27:1} set to cat ${core}cpufreq/scaling_governor done for core in `ls /sys/devices/system/cpu/ | egrep cpu[0-9]+` This works great on my desktop with 12 cores. Alec
Re: [gentoo-user] cryptsetup wont use aes-xts:plain64
Am 21.04.2015 um 11:21 schrieb Marko Weber | 8000: Finally! ... i got it working! cryptsetup -c aes-xts-plain -h sha256 -y -s 256 luksFormat /dev/mapper/VolGroup01-media2 But on writing a testfile of 4G with i get 22,9 Mb/sec. Is there a cipher/hash/keysize which alloows me a bit more write performance? I don't know if it helps you with the write performance, but you can also use aes-xts-plain64 instead of aes-xts-plain. # cryptsetup -c aes-xts-plain64 -h sha256 -y -s 256 luksFormat /dev/mapper/VolGroup01-media2
Re: [gentoo-user] abi_x86_32 FLAG
On Tuesday 21 April 2015 12:38:40 Heiko Baums wrote: Am 21.04.2015 um 03:14 schrieb Joseph: I don't think grub is asking for it. I know it does, because grub-0.97 is 32 bit only software, and the package sys-boot/grub-0.97-r14 compiles grub from the sources with dynamic linking. So it needs 32 bit dependencies (packages with USE=abi_x86_32) incl. sys-devel/gcc. Not here, it doesn't. # grep abi /etc/portage/* /etc/portage/package.use:sys-libs/gpm abi_x86_32 /etc/portage/package.use:sys-libs/ncurses abi_x86_32 # grep grub /etc/portage/* /etc/portage/package.mask:=sys-boot/grub-2.00 # eix -Ic grub [I] sys-boot/grub (0.97-r14{tbz2}@20/04/15): GNU GRUB boot loader # eselect profile list ...8 [6] default/linux/amd64/13.0/desktop/kde * ...8 If you don't want to have any abi_x86_32 dependencies being installed on your system you need to replace sys-boot/grub-0.97-r14 [with] sys-boot/grub-static-0.97-r12, because this package contains the grub binary with static linking. I haven't used grub-static here for ... oh, several years at least. -- Rgds Peter
Re: [gentoo-user] apache and the -D parameter
On 04/20/2015 07:18 PM, Bill Kenworthy wrote: as expected, no difference :( strace doesnt show anything useful - its reading the config files including 70-mod_wsgi.conf but doesnt show anything else. BillK The only other thing I can think of would be to delete and re-type the -D line in /etc/conf.d/apache2 and the IfDefine line in the apache config. Maybe there's a non-printing space or something else evil in there. The unstable apache-2.4 lets you Define variables within the config files and not just on the command-line. If this is important, that might get you up and running at the expense of satisfying your curiosity. Some day we might replace all the -D stuff with Define anyway (https://bugs.gentoo.org/show_bug.cgi?id=532710).
Re: [gentoo-user] Questions about cpu frequency utils scripting
On 04/21/15 11:24, Walter Dnes wrote: On Tue, Apr 21, 2015 at 06:42:35AM -0400, Alec Ten Harmsel wrote for core in `ls /sys/devices/system/cpu/ | egrep cpu[0-9]+` This works great on my desktop with 12 cores. Can you please check whether Emanuele's solution works on your system? for core in /sys/devices/system/cpu/cpu[0-9]*/ I prefer simpler solutions. That does work. I tested it this morning and it didn't work, but forgot that I'm using zsh. Works fine with bash. Alec
Re: [gentoo-user] Questions about cpu frequency utils scripting
On Mon, Apr 20, 2015 at 9:05 PM, Walter Dnes waltd...@waltdnes.org wrote: It seems like many of the cpu speed/governor switcher utilities in /usr/portage/sys-power don't work due to being too old. sys-power/cpupower is probably the best option in the portage tree. It's sources are maintained in the kernel source tree.
[gentoo-user] gcc-5.0 ?
Hello, I need access to the latest gcc compiler for some experimental work with some GPU enabled coding. [1,2] So using this latest gcc compiler just for compiling some fancy new cluster codes using RDMA, is liable (probably ?) to be a wee bit tricky. Now, assuming I find an overlay somewhere, how do I go about ensuring it is slotted and only used with specific syntax just for a few codes and nothing on my general portage tree? Also, I have not found a gcc-5.0 or gcc-5.1 in an overlay (yet), but I did find this gcc- by zorry[3]. It does not look to be gcc-5.x but I am as yet uncertain on that. Any discussion or suggestions how to best get access to gcc-5.x is most appreciated; as is methods to using it (control it) limited to just a few codes. James [1] https://gcc.gnu.org/wiki/OpenACC [2] https://gcc.gnu.org/gcc-5/changes.html#offload under: OpenMP 4.0 specification [3] http://gpo.zugaina.org/sys-devel/gcc