Re: [gentoo-user] [SOLVED] identical drives, different free space!
On Tuesday 18 May 2010 04:13:07 Bill Kenworthy wrote: As an alternative check out http-replicator - yes the clients do download to a local directory but that can be cleaned afterwards. It also allows download locally when you know you are taking the machine (laptop?) elsewhere. Yet another approach is to have an rsync server on your LAN. In my case it's the local server box (print, squid, mail etc). It's simple to set up and to use, and all the boxes on the LAN can operate in their own devious ways. -- Rgds Peter.
Re: [gentoo-user] [SOLVED] identical drives, different free space!
On Tue, 2010-05-18 at 10:12 +0100, Peter Humphrey wrote: On Tuesday 18 May 2010 04:13:07 Bill Kenworthy wrote: As an alternative check out http-replicator - yes the clients do download to a local directory but that can be cleaned afterwards. It also allows download locally when you know you are taking the machine (laptop?) elsewhere. Yet another approach is to have an rsync server on your LAN. In my case it's the local server box (print, squid, mail etc). It's simple to set up and to use, and all the boxes on the LAN can operate in their own devious ways. The advantage of http-replicator is that it is a caching proxy - if it isnt in the cache, it downloads it and then serves it out to one or more clients - rsync/FTP/wget/... can just share whats already there, not go get the file in the first place. BillK -- William Kenworthy bi...@iinet.net.au Home in Perth!
Re: [gentoo-user] [SOLVED] identical drives, different free space!
On Tue, 18 May 2010 18:19:06 +0800, William Kenworthy wrote: The advantage of http-replicator is that it is a caching proxy - if it isnt in the cache, it downloads it and then serves it out to one or more clients - rsync/FTP/wget/... can just share whats already there, not go get the file in the first place. What happens if the proxy is not available, such as when a laptop is away from home? With NFS, the DISTDIR share simply isn't mounted and files are downloaded to the local directory, there's no configuration switch needed when away from home. Caching the files locally does have its advantages, but for me the only computer that would benefit from it, my netbook, is the one with the least storage space to spare. -- Neil Bothwick I'm not opinionated, I'm just always right! signature.asc Description: PGP signature
Re: [gentoo-user] [SOLVED] identical drives, different free space!
On Tuesday 18 May 2010 11:19:06 William Kenworthy wrote: The advantage of http-replicator is that it is a caching proxy - if it isnt in the cache, it downloads it and then serves it out to one or more clients - rsync/FTP/wget/... can just share whats already there, not go get the file in the first place. My setup does exactly the same, since squid is running on the same box. -- Rgds Peter.
Re: [gentoo-user] [SOLVED] identical drives, different free space!
On Tue, 2010-05-18 at 11:30 +0100, Peter Humphrey wrote: On Tuesday 18 May 2010 11:19:06 William Kenworthy wrote: The advantage of http-replicator is that it is a caching proxy - if it isnt in the cache, it downloads it and then serves it out to one or more clients - rsync/FTP/wget/... can just share whats already there, not go get the file in the first place. My setup does exactly the same, since squid is running on the same box. How have you configured it? - I wouldn't have though squid suitable considering its designed for a different purpose and so regularly expires items in its cache (i.e., they will be available for a limited time before being cleaned.) If you extend max_age, then it becomes unsuitable as a regular web proxy/cache unless you are running multiple instances. There are posts saying that squid doesnt work well with portage but other than a high miss rate (possibly because the files expired?), no details are given. Squid also seems to store its files named something like /var/cache/squid/00/00/00B9 so its hard to get at them directly without having squid to serve them up while the http-replicator cache is just the raw files - same as distfiles in fact. see http://forums.gentoo.org/viewtopic.php?p=1138287#1138287 for details on http-replicator. BillK -- William Kenworthy bi...@iinet.net.au Home in Perth!
Re: [gentoo-user] emerge portage error
On 16/05/10 14:44, Alan McKinnon wrote:
On Sunday 16 May 2010 15:10:16 Simon wrote:
Hi,
Please help me to get rid of this error while emerging portage:
# emerge portage
[snip]
Yea gods, the youth of today. In my day, when I was a little whipper-snapper,
we actually read the ebuild. Why because? Because there was no-one else around
to do our looking by proxy for us!
So, in the interest of decomming the proxy in my head, herewith the magic
incantations to make your problem go Poof! and disappear:
Firstly, you have tools to help. equery, euse, and many more. Learn how to use
them, and use them.
Secondly, read the ebuild. portage does what the ebuild says so the master
reference to figure out why portage wants to do something is in the ebuild (or
eclasses that it inherits).
* bsddb module is out-of-date and no longer maintained inside
dev-lang/python. It has
* been additionally removed in Python 3. You should use external,
still maintained bsddb3
* module provided by dev-python/bsddb3 which supports both Python 2
and Python 3.
*
* ERROR: dev-lang/python-2.5.4-r4 failed.
* Call stack:
*ebuild.sh, line 49: Called pkg_setup
* python-2.5.4-r4.ebuild, line 64: Called built_with_use
'pkg_setup' 'pkg_setup'
*eutils.eclass, line 1862: Called die
* The specific snippet of code:
* die) die $PKG does not
actually support the $1 USE flag!;;
* The die message:
* sys-devel/gcc-4.1.2 does not actually support the libffi USE flag!
From the ebuild:
pkg_setup() {
if use berkdb; then
ewarn \bsddb\ module is out-of-date and no longer
maintained inside dev-lang/python. It has
ewarn been additionally removed in Python 3. You should use
external, still maintained \bsddb3\
ewarn module provided by dev-python/bsddb3 which supports
both Python 2 and Python 3.
fi
if built_with_use sys-devel/gcc libffi; then
die Reinstall sys-devel/gcc with \libffi\ USE flag
disabled
fi
}
So, to get rid of the bsddb ewarn, you need to remove that berkdb from USE.
And the build failure is staring you right there in the face. As we say here
at the tip of Africa, As dit 'n slang was, het dit jou gepik [If it were a
snake, it would have already bitten you].
You have USE=libffi which doesn't work. Remove it, sync the tree, rebuild
world. (your portage and gcc versions have updates available, even on stable)
How do i unsubscribe from the list? I love it, but i subscribed in error
and I cant seem to stop it!
Re: [gentoo-user] emerge portage error
On 18 May 2010 13:11, Barry Jibb barryjibbsausages...@gmail.com wrote:
On 16/05/10 14:44, Alan McKinnon wrote:
On Sunday 16 May 2010 15:10:16 Simon wrote:
Hi,
Please help me to get rid of this error while emerging portage:
# emerge portage
[snip]
Yea gods, the youth of today. In my day, when I was a little
whipper-snapper,
we actually read the ebuild. Why because? Because there was no-one else
around
to do our looking by proxy for us!
So, in the interest of decomming the proxy in my head, herewith the magic
incantations to make your problem go Poof! and disappear:
Firstly, you have tools to help. equery, euse, and many more. Learn how to
use
them, and use them.
Secondly, read the ebuild. portage does what the ebuild says so the master
reference to figure out why portage wants to do something is in the ebuild
(or
eclasses that it inherits).
* bsddb module is out-of-date and no longer maintained inside
dev-lang/python. It has
* been additionally removed in Python 3. You should use external,
still maintained bsddb3
* module provided by dev-python/bsddb3 which supports both Python 2
and Python 3.
*
* ERROR: dev-lang/python-2.5.4-r4 failed.
* Call stack:
* ebuild.sh, line 49: Called pkg_setup
* python-2.5.4-r4.ebuild, line 64: Called built_with_use
'pkg_setup' 'pkg_setup'
* eutils.eclass, line 1862: Called die
* The specific snippet of code:
* die) die $PKG does not
actually support the $1 USE flag!;;
* The die message:
* sys-devel/gcc-4.1.2 does not actually support the libffi USE flag!
From the ebuild:
pkg_setup() {
if use berkdb; then
ewarn \bsddb\ module is out-of-date and no longer
maintained inside dev-lang/python. It has
ewarn been additionally removed in Python 3. You should
use
external, still maintained \bsddb3\
ewarn module provided by dev-python/bsddb3 which supports
both Python 2 and Python 3.
fi
if built_with_use sys-devel/gcc libffi; then
die Reinstall sys-devel/gcc with \libffi\ USE flag
disabled
fi
}
So, to get rid of the bsddb ewarn, you need to remove that berkdb from
USE.
And the build failure is staring you right there in the face. As we say
here
at the tip of Africa, As dit 'n slang was, het dit jou gepik [If it were
a
snake, it would have already bitten you].
You have USE=libffi which doesn't work. Remove it, sync the tree,
rebuild
world. (your portage and gcc versions have updates available, even on
stable)
How do i unsubscribe from the list? I love it, but i subscribed in error and
I cant seem to stop it!
If you will be hijacking threads like this then you better unsubscribe
soon please!
Read the headers of this email message for instructions.
--
Regards,
Mick
[gentoo-user] Re: Kernel upgrade and now LUKS failure
On Monday 2010-05-17 11:14, Stefan G. Weichinger wrote: Am 16.05.2010 14:36, schrieb Jan Engelhardt: [Replying to http://thread.gmane.org/gmane.linux.gentoo.user/229533/focus=229542 ] Second, it's using echo without the -n parameter, thus implicitly inserting a newline into the key -- which is the cause for yoru observed mounting problems. Third, because you are passing the key via stdin into cryptsetup, it only uses the first line of whatever you pipe into it; whereas pam_mount uses the entire keyfile as it is supposed to be. [...] Jan, thanks for your suggestions. I created a new LUKS-volume and tried to avoid all the mentioned pitfalls (I used echo -n, avoided stdin etc.), but this didn't help here. To be sure, use openssl -d ... | hexdump -C to detect newlines in the key. The shell has far too many occasions where \n gets stripped or added.
[gentoo-user] Re: Kernel upgrade and now LUKS failure
Am 18.05.2010 15:05, schrieb Jan Engelhardt: On Monday 2010-05-17 11:14, Stefan G. Weichinger wrote: Am 16.05.2010 14:36, schrieb Jan Engelhardt: [Replying to http://thread.gmane.org/gmane.linux.gentoo.user/229533/focus=229542 ] Second, it's using echo without the -n parameter, thus implicitly inserting a newline into the key -- which is the cause for yoru observed mounting problems. Third, because you are passing the key via stdin into cryptsetup, it only uses the first line of whatever you pipe into it; whereas pam_mount uses the entire keyfile as it is supposed to be. [...] Jan, thanks for your suggestions. I created a new LUKS-volume and tried to avoid all the mentioned pitfalls (I used echo -n, avoided stdin etc.), but this didn't help here. To be sure, use openssl -d ... | hexdump -C to detect newlines in the key. The shell has far too many occasions where \n gets stripped or added. Thanks for the hint. Could you please show me an example how it should look like and what to look for? I get several lines of output, that seems bad ... ? Maybe I didn't get all the steps right, could be. Do you know any howto where it is done the right way? Thanks, Stefan
[gentoo-user] Re: Kernel upgrade and now LUKS failure
On Tuesday 2010-05-18 15:44, Stefan G. Weichinger wrote: To be sure, use openssl -d ... | hexdump -C to detect newlines in the key. The shell has far too many occasions where \n gets stripped or added. Thanks for the hint. Could you please show me an example how it should look like and what to look for? In case the key is a suboptimal ascii-only key, it looks like this. offsetbytes broken up visual represent. 35 34 28 5e 52 69 4c 22 3c 72 4c 35 35 27 70 32 |54(^RiLrL55'p2| 0010 39 59 48 21 3b 50 2e 25 52 6e 27 4f 4d 51 42 6b |9YH!;P.%Rn'OMQBk| 0020 34 43 38 76 4e 49 51 24 3f 5e 42 63 2f 6c 2d 76 |4C8vNIQ$?^Bc/l-v| 0030 34 7d 4d 6a 50 5c 41 3c 3f 70 76 67 22 57 21 6b |4}MjP\A?pvgW!k| 0040 77 78 5c 24 23 5e 2e 56 7a 56 24 5a 4f 7e 6a |wx\$#^.VzV$ZO~j| 004f If there were a newline, one of the bytes would be 0a. Do you know any howto where it is done the right way? The right and easy way is to just use the supplied pmt-ehd(8) tool, which works both interactively and non-interactively, depending on whether it's called with enough arguments or not, so there's something for everybody's flavor. It does not do LUKS yet as of pam_mount 2.2, though. Guess my todo list gets longer..
[gentoo-user] Re: Kernel upgrade and now LUKS failure
Am 18.05.2010 18:04, schrieb Jan Engelhardt: On Tuesday 2010-05-18 15:44, Stefan G. Weichinger wrote: To be sure, use openssl -d ... | hexdump -C to detect newlines in the key. The shell has far too many occasions where \n gets stripped or added. Thanks for the hint. Could you please show me an example how it should look like and what to look for? In case the key is a suboptimal ascii-only key, it looks like this. offsetbytes broken up visual represent. 35 34 28 5e 52 69 4c 22 3c 72 4c 35 35 27 70 32 |54(^RiLrL55'p2| 0010 39 59 48 21 3b 50 2e 25 52 6e 27 4f 4d 51 42 6b |9YH!;P.%Rn'OMQBk| 0020 34 43 38 76 4e 49 51 24 3f 5e 42 63 2f 6c 2d 76 |4C8vNIQ$?^Bc/l-v| 0030 34 7d 4d 6a 50 5c 41 3c 3f 70 76 67 22 57 21 6b |4}MjP\A?pvgW!k| 0040 77 78 5c 24 23 5e 2e 56 7a 56 24 5a 4f 7e 6a |wx\$#^.VzV$ZO~j| 004f If there were a newline, one of the bytes would be 0a. Will check ... Do you know any howto where it is done the right way? The right and easy way is to just use the supplied pmt-ehd(8) tool, which works both interactively and non-interactively, depending on whether it's called with enough arguments or not, so there's something for everybody's flavor. It does not do LUKS yet as of pam_mount 2.2, though. Guess my todo list gets longer.. :-) But given the fact that I store the key on the same hard-disk with the shadowed user-pw I could also leave that openssl-part straight away, correct?? seems the same level of (in)security to me ... thank you, Stefan
[gentoo-user] Re: Kernel upgrade and now LUKS failure
On Tuesday 2010-05-18 18:56, Stefan G. Weichinger wrote: Do you know any howto where it is done the right way? The right and easy way is to just use the supplied pmt-ehd(8) tool, which works both interactively and non-interactively, depending on whether it's called with enough arguments or not, so there's something for everybody's flavor. It does not do LUKS yet as of pam_mount 2.2, though. Guess my todo list gets longer.. :-) But given the fact that I store the key on the same hard-disk with the shadowed user-pw I could also leave that openssl-part straight away, correct?? seems the same level of (in)security to me ... Yes. The point of keyfiles is to be able to change the password on a volume. Without a keyfile, a crypto program would take the password, hash it somehow, and you get your AES key. Changing the password means having a different AES key, meaning decrypting the disk will yield a different result. In other words, changing the password would require at least reading the old data, reencrypting it and writing it again. Takes time. With a keyfile, you retain the same AES key all the time, and encrypt the AES key itself - reencrypting the AES key is quick, as it's only some xyz bits, not terabytes.
[gentoo-user] ATI HD5450
Hello Everyone, Well it's time to upgrade the video card in a few systems. I love the fanless cards so I'm sticking with that and ATI brand I'm looking at the ATI HD5450. Anyone got one of these running under gentoo? Got the 7.1 audio working out of the hdmi port? Any GPU usage or linux based dev kit info on the GPU side of the ATI cards is always of interest to me, too. Any information on this or similar ATI fanless cards is of keen interest to me. TIA, James
[gentoo-user] Re: Kernel upgrade and now LUKS failure
Am 18.05.2010 19:57, schrieb Jan Engelhardt: But given the fact that I store the key on the same hard-disk with the shadowed user-pw I could also leave that openssl-part straight away, correct?? seems the same level of (in)security to me ... Yes. The point of keyfiles is to be able to change the password on a volume. Without a keyfile, a crypto program would take the password, hash it somehow, and you get your AES key. Changing the password means having a different AES key, meaning decrypting the disk will yield a different result. In other words, changing the password would require at least reading the old data, reencrypting it and writing it again. Takes time. With a keyfile, you retain the same AES key all the time, and encrypt the AES key itself - reencrypting the AES key is quick, as it's only some xyz bits, not terabytes. Ok, I see. So my current setup with one disk only and SSL-generated keyfile does not add security but flexibility (being able to switch passwords more quickly). Do you see a way of getting this working with my current packages: pam_mount-2.1 sys-fs/cryptsetup-1.1.1_rc2 and LUKS ... ? As mentioned the old keyfile works with pam_mount-1.33, when I check the changelog at http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-auth/pam_mount/ChangeLog?view=markup this is a package from 10 Jan 2010, so maybe it wouldn't be too risky to just mask pam_mount-1.33 - On the other hand I would like to get that done right, sure. Any howto without pmt-ehd that would keep me safe from newlines etc (btw. there were NO newlines in that hexdump-output)? Thanks for your time, Stefan
Re: [gentoo-user] Re: Kernel upgrade and now LUKS failure
Am 18.05.2010 20:57, schrieb Stefan G. Weichinger: On the other hand I would like to get that done right, sure. Any howto without pmt-ehd that would keep me safe from newlines etc (btw. there were NO newlines in that hexdump-output)? Created a new encrypted LV and used --key-file=- as mentioned in: http://pam-mount.git.sourceforge.net/git/gitweb.cgi?p=pam-mount/pam-mount;a=blob;hb=master;f=doc/bugs.txt Still no success with 2.x ... I masked pam_mount-2.x again ... Stefan
Re: [gentoo-user] Re: Kernel upgrade and now LUKS failure
On Tue, May 18, 2010 at 08:57:58PM +0200, Stefan G. Weichinger wrote: Am 18.05.2010 19:57, schrieb Jan Engelhardt: Ok, I see. So my current setup with one disk only and SSL-generated keyfile does not add security but flexibility (being able to switch passwords more quickly). Keep the keyfile in a usb-stick if you can. Decrypting the hard disk will require both the usb-stick and the password, i.e. two factor authentication. -- Eray
Re: [gentoo-user] Re: Kernel upgrade and now LUKS failure
On Tuesday 2010-05-18 21:33, Stefan G. Weichinger wrote: Am 18.05.2010 20:57, schrieb Stefan G. Weichinger: On the other hand I would like to get that done right, sure. Any howto without pmt-ehd that would keep me safe from newlines etc (btw. there were NO newlines in that hexdump-output)? Created a new encrypted LV and used --key-file=- as mentioned in: http://pam-mount.git.sourceforge.net/git/gitweb.cgi?p=pam-mount/pam-mount;a=blob;hb=master;f=doc/bugs.txt Still no success with 2.x ... Debugging preexisting containers is hard (because people usually don't share that.) Since you are starting with a blank one, I would love to see your failing testcase -- i.e. sequence of shell commands to trigger the unanticipated behavior, such as the existing testcases in src/t-crypt: echo that | openssl whatever cryptsetup luksFoo,Format,Open that. mkfs cryptsetup luksClose mount.crypt -o [...] It does not need to follow t-crypt's style, just the sequence alone is good.
Re: [gentoo-user] Re: Kernel upgrade and now LUKS failure
Am 18.05.2010 22:06, schrieb Jan Engelhardt: On Tuesday 2010-05-18 21:33, Stefan G. Weichinger wrote: Am 18.05.2010 20:57, schrieb Stefan G. Weichinger: On the other hand I would like to get that done right, sure. Any howto without pmt-ehd that would keep me safe from newlines etc (btw. there were NO newlines in that hexdump-output)? Created a new encrypted LV and used --key-file=- as mentioned in: http://pam-mount.git.sourceforge.net/git/gitweb.cgi?p=pam-mount/pam-mount;a=blob;hb=master;f=doc/bugs.txt Still no success with 2.x ... Debugging preexisting containers is hard (because people usually don't share that.) Since you are starting with a blank one, I would love to see your failing testcase -- i.e. sequence of shell commands to trigger the unanticipated behavior, such as the existing testcases in src/t-crypt: echo that | openssl whatever cryptsetup luksFoo,Format,Open that. mkfs cryptsetup luksClose mount.crypt -o [...] It does not need to follow t-crypt's style, just the sequence alone is good. I saved my history, unfortunately only the last steps were kept, but I am able to reconstruct: The block-device is /dev/VG01/sgwcrypt ... #I tried a more complicated KEY KEY=`head -c 79 /dev/urandom` # avoid newline here echo -n $KEY | openssl aes-256-cbc /etc/security/super.key # format it, using --keyfile=- as mentioned in bugs ... openssl aes-256-cbc -d -in /etc/security/super.key | cryptsetup -v --key-file=- --cipher aes-cbc-plain --key-size 256 luksFormat /dev/VG01/sgwcrypt # open it openssl aes-256-cbc -d -in /etc/security/super.key | cryptsetup -v --key-file=- luksOpen /dev/VG01/sgwcrypt newhome # create fs on the open luks-volume mkfs.ext3 /dev/mapper/newhome # mount the new fs mount /dev/mapper/newhome /mnt/gschwind all this worked OK so far, but not with pam_mount. OK? Stefan
[gentoo-user] Cannot find entrance!
This is the first time I am dabbling with layman. So it is likely I have made some noob mistake, which I hope you can help me discover. I have installed layman-1.3.3 and then added the enlightenment overlay. I have also added the snapshot keywords for enlightenment: # ls -l /etc/portage/package.keywords/enlightenment.keywords lrwxrwxrwx 1 root root 64 May 18 21:28 /etc/portage/package.keywords/enlightenment.keywords - /var/lib/layman/enlightenment/scripts/package.keywords.snapshots entrance is unmasked in there: # cat /etc/portage/package.keywords/enlightenment.keywords | grep entrance x11-misc/entrance ~* However, although I can see enlightenment, I have no success with entrance: # emerge -upDv entrance These are the packages that would be merged, in order: Calculating dependencies... done! emerge: there are no ebuilds to satisfy entrance. What am I missing? Please ask for supporting info as you need it. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Kernel upgrade and now LUKS failure
yOn Tuesday 2010-05-18 22:17, Stefan G. Weichinger wrote: I saved my history, unfortunately only the last steps were kept, but I am able to reconstruct: The block-device is /dev/VG01/sgwcrypt ... #I tried a more complicated KEY KEY=`head -c 79 /dev/urandom` Well, I'm not going to blame you yet, but the shell is pretty binary-unsafe -- and you have just invoked that voodoo again. # head -c79 /dev/urandom t-crypt.ukey; \ hexdump -C t-crypt.ukey; \ KEY=$(cat t-crypt.ukey); \ echo -n $KEY | hexdump -C; \ echo -n $KEY | wc; a4 b2 c8 a0 4f c9 00 37 66 f3 0c 20 2d 5c 05 e7 |O..7f.. -\..| 0010 cd 5e 5d 00 5d e1 18 2a 1a 8b 2d 41 22 e7 66 0e |.^].]..*..-A.f.| 0020 b0 a3 1d 41 1e 23 1d 00 f8 b2 b2 bc 34 28 94 fe |...A.#..4(..| 0030 ba 0f 45 11 b5 c6 d8 a1 ca c2 ec 08 5e 48 d4 7f |..E.^H..| 0040 17 a8 75 af ef ef f1 7a 0f 2f bf 64 c2 3a 9c |..uz./.d.:.| 004f a4 b2 c8 a0 4f c9 37 66 f3 0c 20 2d 5c 05 e7 cd |O.7f.. -\...| 0010 5e 5d 5d e1 18 2a 1a 8b 2d 41 22 e7 66 0e b0 a3 |^]]..*..-A.f...| 0020 1d 41 1e 23 1d f8 b2 b2 bc 34 28 94 fe ba 0f 45 |.A.#.4(E| 0030 11 b5 c6 d8 a1 ca c2 ec 08 5e 48 d4 7f 17 a8 75 |.^Hu| 0040 af ef ef f1 7a 0f 2f bf 64 c2 3a 9c |z./.d.:.| 004c 0 2 76 So what was once 79 bytes has been reduced to 76 by means of the $() or backtick operator. Not a problem for the crypto utilities per se, but I wanted to point out that you are effectively only having a 76-long key here. The chance to get a key shorter than the requested 79 is 27%. # avoid newline here echo -n $KEY | openssl aes-256-cbc /etc/security/super.key # format it, using --keyfile=- as mentioned in bugs ... openssl aes-256-cbc -d -in /etc/security/super.key | cryptsetup -v --key-file=- --cipher aes-cbc-plain --key-size 256 luksFormat /dev/VG01/sgwcrypt # open it openssl aes-256-cbc -d -in /etc/security/super.key | cryptsetup -v --key-file=- luksOpen /dev/VG01/sgwcrypt newhome Turns out cryptsetup has yet another oddity. With LUKS, --key-file=- is moot. Instead [fkey is the unencrypted one] # cryptsetup luksFormat /dev/loop94 t-crypt.fkey \ cryptsetup --key-file=- luksOpen /dev/loop94 x94 t-crypt.fkey Key slot 0 unlocked. And you thought that doc/bugs.txt described all cryptsetup CLI oddities. *facepalm* ANYWAY. If I proceed with this luks container now, all succeeds: # mkfs.ext4 /dev/mapper/x94 mke2fs 1.41.9 (22-Aug-2009) ... # cryptsetup remove x94 First, let's see if raw passthrough works: # ./mount.crypt -vo keyfile=t-crypt.fkey,fsk_cipher=none /dev/loop94 /mnt command: 'readlink' '-fn' '/dev/loop94' command: 'readlink' '-fn' '/mnt' mount.crypt(crypto-dmc.c:144): Using _dev_loop94 as dmdevice name command: 'mount' '-n' '/dev/mapper/_dev_loop94' '/mnt' # df /mnt Filesystem 1K-blocks Used Available Use% Mounted on /dev/loop94 62465 5365 53875 10% /mnt # PMT_DEBUG_UMOUNT=1 ./umount.crypt /mnt Now the openssl-encrypted file: # ./mount.crypt -vo keyfile=t-crypt.key,fsk_cipher=aes-256-cbc,fsk_hash=md5 /dev/loop94 /mnt command: 'readlink' '-fn' '/dev/loop94' command: 'readlink' '-fn' '/mnt' Password: mount.crypt(crypto-dmc.c:144): Using _dev_loop94 as dmdevice name command: 'mount' '-n' '/dev/mapper/_dev_loop94' '/mnt' # df /mnt Filesystem 1K-blocks Used Available Use% Mounted on /dev/loop94 62465 5365 53875 10% /mnt Match?
Re: [gentoo-user] Re: Kernel upgrade and now LUKS failure
Am 18.05.2010 23:16, schrieb Jan Engelhardt: yOn Tuesday 2010-05-18 22:17, Stefan G. Weichinger wrote: I saved my history, unfortunately only the last steps were kept, but I am able to reconstruct: The block-device is /dev/VG01/sgwcrypt ... #I tried a more complicated KEY KEY=`head -c 79 /dev/urandom` Well, I'm not going to blame you yet, but the shell is pretty binary-unsafe -- and you have just invoked that voodoo again. # head -c79 /dev/urandom t-crypt.ukey; \ hexdump -C t-crypt.ukey; \ KEY=$(cat t-crypt.ukey); \ echo -n $KEY | hexdump -C; \ echo -n $KEY | wc; a4 b2 c8 a0 4f c9 00 37 66 f3 0c 20 2d 5c 05 e7 |O..7f.. -\..| 0010 cd 5e 5d 00 5d e1 18 2a 1a 8b 2d 41 22 e7 66 0e |.^].]..*..-A.f.| 0020 b0 a3 1d 41 1e 23 1d 00 f8 b2 b2 bc 34 28 94 fe |...A.#..4(..| 0030 ba 0f 45 11 b5 c6 d8 a1 ca c2 ec 08 5e 48 d4 7f |..E.^H..| 0040 17 a8 75 af ef ef f1 7a 0f 2f bf 64 c2 3a 9c |..uz./.d.:.| 004f a4 b2 c8 a0 4f c9 37 66 f3 0c 20 2d 5c 05 e7 cd |O.7f.. -\...| 0010 5e 5d 5d e1 18 2a 1a 8b 2d 41 22 e7 66 0e b0 a3 |^]]..*..-A.f...| 0020 1d 41 1e 23 1d f8 b2 b2 bc 34 28 94 fe ba 0f 45 |.A.#.4(E| 0030 11 b5 c6 d8 a1 ca c2 ec 08 5e 48 d4 7f 17 a8 75 |.^Hu| 0040 af ef ef f1 7a 0f 2f bf 64 c2 3a 9c |z./.d.:.| 004c 0 2 76 So what was once 79 bytes has been reduced to 76 by means of the $() or backtick operator. Not a problem for the crypto utilities per se, but I wanted to point out that you are effectively only having a 76-long key here. The chance to get a key shorter than the requested 79 is 27%. # avoid newline here echo -n $KEY | openssl aes-256-cbc /etc/security/super.key # format it, using --keyfile=- as mentioned in bugs ... openssl aes-256-cbc -d -in /etc/security/super.key | cryptsetup -v --key-file=- --cipher aes-cbc-plain --key-size 256 luksFormat /dev/VG01/sgwcrypt # open it openssl aes-256-cbc -d -in /etc/security/super.key | cryptsetup -v --key-file=- luksOpen /dev/VG01/sgwcrypt newhome Turns out cryptsetup has yet another oddity. With LUKS, --key-file=- is moot. Instead [fkey is the unencrypted one] # cryptsetup luksFormat /dev/loop94 t-crypt.fkey \ cryptsetup --key-file=- luksOpen /dev/loop94 x94 t-crypt.fkey Key slot 0 unlocked. And you thought that doc/bugs.txt described all cryptsetup CLI oddities. *facepalm* ANYWAY. If I proceed with this luks container now, all succeeds: # mkfs.ext4 /dev/mapper/x94 mke2fs 1.41.9 (22-Aug-2009) ... # cryptsetup remove x94 First, let's see if raw passthrough works: # ./mount.crypt -vo keyfile=t-crypt.fkey,fsk_cipher=none /dev/loop94 /mnt command: 'readlink' '-fn' '/dev/loop94' command: 'readlink' '-fn' '/mnt' mount.crypt(crypto-dmc.c:144): Using _dev_loop94 as dmdevice name command: 'mount' '-n' '/dev/mapper/_dev_loop94' '/mnt' # df /mnt Filesystem 1K-blocks Used Available Use% Mounted on /dev/loop94 62465 5365 53875 10% /mnt # PMT_DEBUG_UMOUNT=1 ./umount.crypt /mnt Now the openssl-encrypted file: # ./mount.crypt -vo keyfile=t-crypt.key,fsk_cipher=aes-256-cbc,fsk_hash=md5 /dev/loop94 /mnt command: 'readlink' '-fn' '/dev/loop94' command: 'readlink' '-fn' '/mnt' Password: mount.crypt(crypto-dmc.c:144): Using _dev_loop94 as dmdevice name command: 'mount' '-n' '/dev/mapper/_dev_loop94' '/mnt' # df /mnt Filesystem 1K-blocks Used Available Use% Mounted on /dev/loop94 62465 5365 53875 10% /mnt Match? Frankly: dunno ;-) Yes, I am able to follow and understand in general so far ... but ... Assuming that I am too stupid: Where is the how-to-do-it? So far the only thing I really understood You are doing it wrong. But where is the Do it this way and you are safe ? I wouldn't post here if I were competent enough to know all these details. Concerning encryption I am at the USER-level, you know for sure ;-) Just trying to feed back my problems to maybe detect bugs or my mistakes. Stefan
Re: [gentoo-user] Cannot find entrance!
On 5/19/10, Mick michaelkintz...@gmail.com wrote: This is the first time I am dabbling with layman. So it is likely I have made some noob mistake, which I hope you can help me discover. I have installed layman-1.3.3 and then added the enlightenment overlay. I have also added the snapshot keywords for enlightenment: # ls -l /etc/portage/package.keywords/enlightenment.keywords lrwxrwxrwx 1 root root 64 May 18 21:28 /etc/portage/package.keywords/enlightenment.keywords - /var/lib/layman/enlightenment/scripts/package.keywords.snapshots entrance is unmasked in there: # cat /etc/portage/package.keywords/enlightenment.keywords | grep entrance x11-misc/entrance ~* However, although I can see enlightenment, I have no success with entrance: # emerge -upDv entrance These are the packages that would be merged, in order: Calculating dependencies... done! emerge: there are no ebuilds to satisfy entrance. What am I missing? Please ask for supporting info as you need it. Are you sure you are sourcing the layman configuration in /etc/make.conf: source /var/lib/layman/make.conf -- Arttu V.
Re: [gentoo-user] Cannot find entrance!
On Tue, May 18, 2010 at 4:02 PM, Mick michaelkintz...@gmail.com wrote: This is the first time I am dabbling with layman. So it is likely I have made some noob mistake, which I hope you can help me discover. I have installed layman-1.3.3 and then added the enlightenment overlay. I have also added the snapshot keywords for enlightenment: # ls -l /etc/portage/package.keywords/enlightenment.keywords lrwxrwxrwx 1 root root 64 May 18 21:28 /etc/portage/package.keywords/enlightenment.keywords - /var/lib/layman/enlightenment/scripts/package.keywords.snapshots entrance is unmasked in there: # cat /etc/portage/package.keywords/enlightenment.keywords | grep entrance x11-misc/entrance ~* However, although I can see enlightenment, I have no success with entrance: # emerge -upDv entrance These are the packages that would be merged, in order: Calculating dependencies... done! emerge: there are no ebuilds to satisfy entrance. What am I missing? Please ask for supporting info as you need it. entrance no longer exists in the overlay, looks like it is gone for good: Changeset 372 Timestamp: 02/28/10 14:01:41 (3 months ago) Author: tommy Message: x11-misc/ entrance: Remove entrance: old and unmaintained, there is currently a rewrite from scratch planned, but no ETA
Re: [gentoo-user] Re: Kernel upgrade and now LUKS failure
On Tuesday 2010-05-18 23:49, Stefan G. Weichinger wrote: # ./mount.crypt -vo keyfile=t-crypt.key,fsk_cipher=aes-256-cbc,fsk_hash=md5 /dev/loop94 /mnt command: 'readlink' '-fn' '/dev/loop94' command: 'readlink' '-fn' '/mnt' Password: mount.crypt(crypto-dmc.c:144): Using _dev_loop94 as dmdevice name command: 'mount' '-n' '/dev/mapper/_dev_loop94' '/mnt' # df /mnt Filesystem 1K-blocks Used Available Use% Mounted on /dev/loop94 62465 5365 53875 10% /mnt Match? Frankly: dunno ;-) Yes, I am able to follow and understand in general so far ... but ... Right now it's more a case of let's do it and compare results than having to thoroughly understand when and where cryptsetup chops off a byte and pads another. That went fine, up to # mount the new fs mount /dev/mapper/newhome /mnt/gschwind all this worked OK so far, but not with pam_mount. OK? OK, but don't stop there. pam_mount really just ultimatively runs mount.crypt; and it tells you that it does by means of syslog (with enabled debug=1 of course). command: 'mount.crypt' '-ofsk And that is what you can run from shell, which eliminates pam_mount from the path and only leaves the usual suspects. Keep on it, marine! Assuming that I am too stupid: Where is the how-to-do-it? So far the only thing I really understood You are doing it wrong. But where is the Do it this way and you are safe ? http://archives.gentoo.org/gentoo-user/msg_e80d6e5a662b7595a2a8a70a0fa166dd.xml was basically it: pmt-ehd and you're safe. Short of the current ...missing feature though, mentioned in that same mail.
[gentoo-user] Re: ATI HD5450
On 05/18/2010 11:26 AM, James wrote: Hello Everyone, Well it's time to upgrade the video card in a few systems. I love the fanless cards so I'm sticking with that and ATI brand I'm looking at the ATI HD5450. Anyone got one of these running under gentoo? Got the 7.1 audio working out of the hdmi port? I'd like to know the answer too, as I'd like to support them. I have only nvidia graphics because I know their proprietary drivers work, at least. No idea about ATI yet. I see here that they don't mention the HD 5400 series at all: http://support.amd.com/us/Pages/drivers.aspx Seems like whenever I buy a product, the manufacturer never mentions the particular chip-set that I actually got. Maybe it's because I always buy the cheapest thing I can find ;)
[gentoo-user] NetworkManager SIGSEGV
After a recent upgrade, the NetworkManager daemon crashes (for me!). Thanks in advance to to those who are about to suggest that I use something else, but NM has features I use that nothing else provides :) The backtrace is HUGE, so there's obviously some loop going on somewhere, but according to my earlier problems with massive amounts of logging, I don't think this is the cause of the current seg fault. Can someone tell me what needs to be recompiled / downgraded to fix it? I've had no luck figuring it out so far! the innermost 10 frames are: #0 0xb794 in _IO_vfprintf_internal (s=0xbf80042c, format=0x80b38e4 WARN %s(): Trying to remove a non-existant call id.\n, ap=0xbf8009fc \\9\v\b\023좷ä\n\200¿¿\n\200¿\001) at vfprintf.c:197 #1 0xb79f12e2 in *__GI___vasprintf_chk (result_ptr=0xbf80053c, flags=1, format=0x80b38e4 WARN %s(): Trying to remove a non-existant call id.\n, args=0xbf8009fc \\9\v\b\023좷ä\n\200¿¿\n\200¿\001) at vasprintf_chk.c:68 #2 0xb7aebb4f in vasprintf (string=0xbf80053c, format=0x80b38e4 WARN %s(): Trying to remove a non-existant call id.\n, args=0xbf8009fc \\9\v\b\023좷ä\n\200¿¿\n\200¿\001) at /usr/include/bits/stdio2.h:199 #3 IA__g_vasprintf (string=0xbf80053c, format=0x80b38e4 WARN %s(): Trying to remove a non-existant call id.\n, args=0xbf8009fc \\9\v\b\023좷ä\n\200¿¿\n\200¿\001) at gprintf.c:315 #4 0xb7ad7a16 in IA__g_strdup_vprintf (format=0x80b38e4 WARN %s(): Trying to remove a non-existant call id.\n, args=0xbf8009fc \\9\v\b\023좷ä\n\200¿¿\n\200¿\001) at gstrfuncs.c:244 #5 0xb7abf3e0 in IA__g_logv (log_domain=value optimized out, log_level=G_LOG_LEVEL_WARNING, format=0x80b38e4 WARN %s(): Trying to remove a non-existant call id.\n, args1=0xbf8009fc \\9\v\b\023좷ä\n\200¿¿\n\200¿\001) at gmessages.c:516 #6 0xb7abf846 in IA__g_log (log_domain=0x0, log_level=G_LOG_LEVEL_WARNING, format=0x80b38e4 WARN %s(): Trying to remove a non-existant call id.\n) at gmessages.c:569 #7 0x0805e72c in nm_call_store_remove (store=0x80f8320, object=0x80f92e0, call_id=0x1) at nm-call-store.c:71 #8 0x0809f34a in nm_supplicant_info_destroy (user_data=0x80e3760) at nm-supplicant-interface.c:179 #9 0xb7c682f9 in d_pending_call_free (data=0x80d8388) at /var/tmp/portage/dev-libs/dbus-glib-0.86/work/dbus-glib-0.86/dbus/dbus-gproxy.c:1780 and most of this will repeat a few thousand times. and the outermost 10 frames are: #174513 0xb7bc6d76 in IA__g_signal_emit (instance=0x80d70b8, signal_id=8, detail=81) at gsignal.c:3037 #174514 0xb7c6d52d in dbus_g_proxy_emit_remote_signal (connection=0x80d5418, message=0x80d56d8, user_data=0x80d4878) at /var/tmp/portage/dev-libs/dbus-glib-0.86/work/dbus-glib-0.86/dbus/dbus-gproxy.c:1734 #174515 dbus_g_proxy_manager_filter (connection=0x80d5418, message=0x80d56d8, user_data=0x80d4878) at /var/tmp/portage/dev-libs/dbus-glib-0.86/work/dbus-glib-0.86/dbus/dbus-gproxy.c:1301 #174516 0xb7c31ecb in dbus_connection_dispatch (connection=0x80d5418) at dbus-connection.c:4451 #174517 0xb7c6360d in message_queue_dispatch (source=0x80d6d80, callback=0, user_data=0x0) at /var/tmp/portage/dev-libs/dbus-glib-0.86/work/dbus-glib-0.86/dbus/dbus-gmain.c:101 #174518 0xb7ab57b8 in g_main_dispatch (context=0x80d2e08) at gmain.c:1960 #174519 IA__g_main_context_dispatch (context=0x80d2e08) at gmain.c:2513 #174520 0xb7ab9050 in g_main_context_iterate (context=0x80d2e08, block=value optimized out, dispatch=1, self=0x80cc170) at gmain.c:2591 #174521 0xb7ab94bf in IA__g_main_loop_run (loop=0x80d2e98) at gmain.c:2799 #174522 0x0807f1ac in main (argc=1, argv=0xbfffee84) at NetworkManager.c:648 I've recompiled dbus, dbus-glib, networkmanager and a bunch of stuff, but to no avail. The last updates before it broke were: dev-libs/nspr-4.8.4-r1 dev-libs/libsigc++-2.2.7 dev-lang/swig-1.3.40-r1 dev-lang/orc-0.4.4 sci-libs/proj-4.7.0 media-libs/tiff-4.0.0_beta5 x11-libs/pixman-0.18.2 dev-perl/libwww-perl-5.836 sci-libs/libgeotiff-1.3.0_rc2-r1 net-dns/bind-tools-9.7.0_p1 sci-libs/gdal-1.7.1-r1 x11-proto/xproto-7.0.17 net-wireless/wpa_supplicant-0.7.2 sys-power/pm-utils-1.3.0-r3 media-fonts/urwvn-fonts-3.05 sys-auth/nss-mdns-0.10 dev-libs/totem-pl-parser-2.28.3 sys-fs/cryptsetup-1.1.1_rc2 sys-fs/udev-154 sci-geosciences/googleearth-5.1.3535.3218 gnome-base/librsvg-2.26.3 media-gfx/gtkam-0.1.17 x11-base/xorg-server-1.8.1 app-emulation/wine-1.1.44 sci-libs/libgeotiff-1.3.0_rc2-r1 sci-libs/gdal-1.7.1-r1 any ideas? thanks, -- Iain Buchanan iaindb at netspace dot net dot au Bombeck's Rule of Medicine: Never go to a doctor whose office plants have died.
Re: [gentoo-user] NetworkManager SIGSEGV
It was probably the wpa_supplicant update, see bug 320097 on bugs.gentoo.org. Just had this problem myself this morning, you can fix it by using the ebuild provided in the bug or by downgrading wpa_supplicant (which had 0.7.2 hardmasked today). Hope this helps! Chris Reffett On 05/18/2010 09:57 PM, Iain Buchanan wrote: After a recent upgrade, the NetworkManager daemon crashes (for me!). Thanks in advance to to those who are about to suggest that I use something else, but NM has features I use that nothing else provides :) The backtrace is HUGE, so there's obviously some loop going on somewhere, but according to my earlier problems with massive amounts of logging, I don't think this is the cause of the current seg fault. Can someone tell me what needs to be recompiled / downgraded to fix it? I've had no luck figuring it out so far! the innermost 10 frames are: #0 0xb794 in _IO_vfprintf_internal (s=0xbf80042c, format=0x80b38e4 WARN %s(): Trying to remove a non-existant call id.\n, ap=0xbf8009fc \\9\v\b\023좷ä\n\200¿¿\n\200¿\001) at vfprintf.c:197 #1 0xb79f12e2 in *__GI___vasprintf_chk (result_ptr=0xbf80053c, flags=1, format=0x80b38e4 WARN %s(): Trying to remove a non-existant call id.\n, args=0xbf8009fc \\9\v\b\023좷ä\n\200¿¿\n\200¿\001) at vasprintf_chk.c:68 #2 0xb7aebb4f in vasprintf (string=0xbf80053c, format=0x80b38e4 WARN %s(): Trying to remove a non-existant call id.\n, args=0xbf8009fc \\9\v\b\023좷ä\n\200¿¿\n\200¿\001) at /usr/include/bits/stdio2.h:199 #3 IA__g_vasprintf (string=0xbf80053c, format=0x80b38e4 WARN %s(): Trying to remove a non-existant call id.\n, args=0xbf8009fc \\9\v\b\023좷ä\n\200¿¿\n\200¿\001) at gprintf.c:315 #4 0xb7ad7a16 in IA__g_strdup_vprintf (format=0x80b38e4 WARN %s(): Trying to remove a non-existant call id.\n, args=0xbf8009fc \\9\v\b\023좷ä\n\200¿¿\n\200¿\001) at gstrfuncs.c:244 #5 0xb7abf3e0 in IA__g_logv (log_domain=value optimized out, log_level=G_LOG_LEVEL_WARNING, format=0x80b38e4 WARN %s(): Trying to remove a non-existant call id.\n, args1=0xbf8009fc \\9\v\b\023좷ä\n\200¿¿\n\200¿\001) at gmessages.c:516 #6 0xb7abf846 in IA__g_log (log_domain=0x0, log_level=G_LOG_LEVEL_WARNING, format=0x80b38e4 WARN %s(): Trying to remove a non-existant call id.\n) at gmessages.c:569 #7 0x0805e72c in nm_call_store_remove (store=0x80f8320, object=0x80f92e0, call_id=0x1) at nm-call-store.c:71 #8 0x0809f34a in nm_supplicant_info_destroy (user_data=0x80e3760) at nm-supplicant-interface.c:179 #9 0xb7c682f9 in d_pending_call_free (data=0x80d8388) at /var/tmp/portage/dev-libs/dbus-glib-0.86/work/dbus-glib-0.86/dbus/dbus-gproxy.c:1780 and most of this will repeat a few thousand times. and the outermost 10 frames are: #174513 0xb7bc6d76 in IA__g_signal_emit (instance=0x80d70b8, signal_id=8, detail=81) at gsignal.c:3037 #174514 0xb7c6d52d in dbus_g_proxy_emit_remote_signal (connection=0x80d5418, message=0x80d56d8, user_data=0x80d4878) at /var/tmp/portage/dev-libs/dbus-glib-0.86/work/dbus-glib-0.86/dbus/dbus-gproxy.c:1734 #174515 dbus_g_proxy_manager_filter (connection=0x80d5418, message=0x80d56d8, user_data=0x80d4878) at /var/tmp/portage/dev-libs/dbus-glib-0.86/work/dbus-glib-0.86/dbus/dbus-gproxy.c:1301 #174516 0xb7c31ecb in dbus_connection_dispatch (connection=0x80d5418) at dbus-connection.c:4451 #174517 0xb7c6360d in message_queue_dispatch (source=0x80d6d80, callback=0, user_data=0x0) at /var/tmp/portage/dev-libs/dbus-glib-0.86/work/dbus-glib-0.86/dbus/dbus-gmain.c:101 #174518 0xb7ab57b8 in g_main_dispatch (context=0x80d2e08) at gmain.c:1960 #174519 IA__g_main_context_dispatch (context=0x80d2e08) at gmain.c:2513 #174520 0xb7ab9050 in g_main_context_iterate (context=0x80d2e08, block=value optimized out, dispatch=1, self=0x80cc170) at gmain.c:2591 #174521 0xb7ab94bf in IA__g_main_loop_run (loop=0x80d2e98) at gmain.c:2799 #174522 0x0807f1ac in main (argc=1, argv=0xbfffee84) at NetworkManager.c:648 I've recompiled dbus, dbus-glib, networkmanager and a bunch of stuff, but to no avail. The last updates before it broke were: dev-libs/nspr-4.8.4-r1 dev-libs/libsigc++-2.2.7 dev-lang/swig-1.3.40-r1 dev-lang/orc-0.4.4 sci-libs/proj-4.7.0 media-libs/tiff-4.0.0_beta5 x11-libs/pixman-0.18.2 dev-perl/libwww-perl-5.836 sci-libs/libgeotiff-1.3.0_rc2-r1 net-dns/bind-tools-9.7.0_p1 sci-libs/gdal-1.7.1-r1 x11-proto/xproto-7.0.17 net-wireless/wpa_supplicant-0.7.2 sys-power/pm-utils-1.3.0-r3 media-fonts/urwvn-fonts-3.05 sys-auth/nss-mdns-0.10 dev-libs/totem-pl-parser-2.28.3 sys-fs/cryptsetup-1.1.1_rc2 sys-fs/udev-154 sci-geosciences/googleearth-5.1.3535.3218 gnome-base/librsvg-2.26.3 media-gfx/gtkam-0.1.17 x11-base/xorg-server-1.8.1 app-emulation/wine-1.1.44 sci-libs/libgeotiff-1.3.0_rc2-r1 sci-libs/gdal-1.7.1-r1 any ideas? thanks,
[gentoo-user] corefonts being depcleaned?
Hi, I updated a bit ago, it updated a few packages and while I was sitting here I thought I would run --depclean and see if anything needed cleaning. I got this list of packages: These are the packages that would be unmerged: media-fonts/corefonts selected: 1-r4 protected: none omitted: none app-misc/hal-cups-utils selected: 0.6.19 protected: none omitted: none app-arch/cabextract selected: 1.2-r1 protected: none omitted: none 'Selected' packages are slated for removal. 'Protected' and 'omitted' packages will not be removed. Packages installed: 978 Packages in world:117 Packages in system: 50 Required packages:975 Number to remove: 3 r...@smoker ~ # The corefonts is sort of odd. I thought that was a system package, or at least it was. Is this correct? I don't want to remove this unless something else has replaced it or something. Anybody else removed this with no ill effects? Thanks. Dale :-) :-)
[gentoo-user] Re: corefonts being depcleaned?
On 05/18/2010 07:10 PM, Dale wrote: Hi, I updated a bit ago, it updated a few packages and while I was sitting here I thought I would run --depclean and see if anything needed cleaning. I got this list of packages: These are the packages that would be unmerged: media-fonts/corefonts selected: 1-r4 protected: none omitted: none ... The corefonts is sort of odd. I thought that was a system package, or at least it was. Is this correct? I don't want to remove this unless something else has replaced it or something. Anybody else removed this with no ill effects? I updated about 16 hours ago and got no such pronouncement. The corefonts package has both the x86 and amd64 KEYWORDS (well, as of 16 hours ago) so I would be very slow to remove it. Some of my favorite fonts come from that package, even if it is from The Other Leading Operating System.
Re: [gentoo-user] NetworkManager SIGSEGV
On Tue, 2010-05-18 at 22:05 -0400, Chris Reffett wrote: It was probably the wpa_supplicant update, see bug 320097 on bugs.gentoo.org. spot on! I didn't see it because I was searching for NetworkManager bugs, not wpa_supplicant bugs :) thanks, -- Iain Buchanan iaindb at netspace dot net dot au Being a mime means never having to say you're sorry.
Re: [gentoo-user] Cannot find entrance!
On Wednesday 19 May 2010 00:22:03 Paul Hartman wrote: On Tue, May 18, 2010 at 4:02 PM, Mick michaelkintz...@gmail.com wrote: This is the first time I am dabbling with layman. So it is likely I have made some noob mistake, which I hope you can help me discover. I have installed layman-1.3.3 and then added the enlightenment overlay. I have also added the snapshot keywords for enlightenment: # ls -l /etc/portage/package.keywords/enlightenment.keywords lrwxrwxrwx 1 root root 64 May 18 21:28 /etc/portage/package.keywords/enlightenment.keywords - /var/lib/layman/enlightenment/scripts/package.keywords.snapshots entrance is unmasked in there: # cat /etc/portage/package.keywords/enlightenment.keywords | grep entrance x11-misc/entrance ~* However, although I can see enlightenment, I have no success with entrance: # emerge -upDv entrance These are the packages that would be merged, in order: Calculating dependencies... done! emerge: there are no ebuilds to satisfy entrance. What am I missing? Please ask for supporting info as you need it. entrance no longer exists in the overlay, looks like it is gone for good: Changeset 372 Timestamp: 02/28/10 14:01:41 (3 months ago) Author: tommy Message: x11-misc/ entrance: Remove entrance: old and unmaintained, there is currently a rewrite from scratch planned, but no ETA The enlightenment overlay is largely unmaintained, or not being updated much. You will get better results using the efl overlay, maintained at enlightenment.org by an e17 dev: http://svn.enlightenment.org/svn/e/trunk/packaging/gentoo There's details on the enlightenment wiki. If memory servers, it's in the Packaging page -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Cannot find entrance!
On Tuesday 18 May 2010 23:22:03 Paul Hartman wrote: On Tue, May 18, 2010 at 4:02 PM, Mick michaelkintz...@gmail.com wrote: This is the first time I am dabbling with layman. So it is likely I have made some noob mistake, which I hope you can help me discover. I have installed layman-1.3.3 and then added the enlightenment overlay. I have also added the snapshot keywords for enlightenment: # ls -l /etc/portage/package.keywords/enlightenment.keywords lrwxrwxrwx 1 root root 64 May 18 21:28 /etc/portage/package.keywords/enlightenment.keywords - /var/lib/layman/enlightenment/scripts/package.keywords.snapshots entrance is unmasked in there: # cat /etc/portage/package.keywords/enlightenment.keywords | grep entrance x11-misc/entrance ~* However, although I can see enlightenment, I have no success with entrance: # emerge -upDv entrance These are the packages that would be merged, in order: Calculating dependencies... done! emerge: there are no ebuilds to satisfy entrance. What am I missing? Please ask for supporting info as you need it. entrance no longer exists in the overlay, looks like it is gone for good: Changeset 372 Timestamp: 02/28/10 14:01:41 (3 months ago) Author: tommy Message: x11-misc/ entrance: Remove entrance: old and unmaintained, there is currently a rewrite from scratch planned, but no ETA :-( So, no Display Manager for enlightenment? How do people start it up - it seems odd to use e.g. the u xdm to do the job. PS. Where did you find this note about entrance being deprecated Paul? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
