Re: [gentoo-user] Emerge is teh FAIL ! ! ! ! !

[Alex Corkwell]

I encountered something similar to this myself a bit ago.
Apparently, GCC 5.3 has a bug in how it works with the stack alignment
in some cases, which causes compiling wine to fail halfway through [1].
I believe that that is the check for that bug.

If you have GCC 5.3, you may want to consider moving back to 5.2 until
the patch makes it into 5.4.
Or you can download the patch [1] and add it to /etc/portage/patches, if you
know how.

Alternatively, you can just mask the 1.9.* versions of wine for now.

That is, assuming that you are using GCC 5.3.
If not, ignore this.


[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69140


On Mon, Mar 14, 2016 at 01:53:44PM -0400, Alan Grimes wrote:
> No, skipfirst only works when it actually tries to compile something.
> Here it is failing in some strange pre-compile stage. I don't know why
> it has to be so anal about this, The normal solution would be to log the
> error, drop the two packages that were affected, and then compile the
> rest...
> 
> but no.
> 
> I had to uninstall wine and winetricks, now about 80% of my packages are
> compiling... I'm probably going to end up with another lengthy list of
> miserable fail
> 
> 
> Franz Fellner wrote:
> > man emerge
> > search for "skipfirst" and "keep-going"
> > It also seems you did not post the actual error or log. At least the
> > snipped you posted does not make any sense.
> >
> > 2016-03-14 16:12 GMT+01:00 Alan Grimes  > >:
> >
> > In order to press ahead, I had to drop ktorrent and digikam, both
> > packages that I consider high priority. =\
> >
> >
> > I thought that would finally get me going...
> >
> >
> > Oh what a fool I was...
> >
> > #
> >
> > >>> Running pre-merge checks for kde-plasma/plasma-workspace-5.5.5-r2
> > >>> Running pre-merge checks for kde-plasma/kdeplasma-addons-5.5.5
> > >>> Running pre-merge checks for kde-plasma/khotkeys-5.5.5
> > >>> Running pre-merge checks for kde-plasma/powerdevil-5.5.5
> > >>> Running pre-merge checks for kde-plasma/kmenuedit-5.5.5
> > >>> Running pre-merge checks for kde-plasma/plasma-desktop-5.5.5
> > >>> Running pre-merge checks for dev-lang/mono-4.2.2.30
> >  * Determining the location of the kernel source code
> >  * Found kernel source directory:
> >  * /usr/src/linux
> >  * Found kernel object directory:
> >  * /lib/modules/4.4.0/build
> >  * Found sources for kernel version:
> >  * 4.4.0
> >  * Checking for suitable kernel configuration
> > options...
> > [ ok ]
> >
> >  * Messages for package app-emulation/wine-1.9.5:
> >
> >  * ERROR: app-emulation/wine-1.9.5::gentoo failed (pretend phase):
> >  *   (no error message)
> >  *
> >  * Call stack:
> >  *   ebuild.sh, line 133:  Called pkg_pretend
> >  *   wine-1.9.5.ebuild, line 206:  Called wine_build_environment_check
> >  *   wine-1.9.5.ebuild, line 179:  Called die
> >  * The specific snippet of code:
> >  *  $(tc-getCC) -O2 "${FILESDIR}"/pr69140.c -o
> > "${T}"/pr69140 || die
> >  *
> >  * If you need support, post the output of `emerge --info
> > '=app-emulation/wine-1.9.5::gentoo'`,
> >  * the complete build log and the output of `emerge -pqv
> > '=app-emulation/wine-1.9.5::gentoo'`.
> >  * The complete build log is located at
> > '/var/tmp/portage/app-emulation/wine-1.9.5/temp/build.log'.
> >  * The ebuild environment file is located at
> > '/var/tmp/portage/app-emulation/wine-1.9.5/temp/die.env'.
> >  * Working directory: '/usr/lib64/python3.4/site-packages'
> >  * S: '/var/tmp/portage/app-emulation/wine-1.9.5/work/wine-1.9.5'
> > tortoise ~ #
> >
> > 
> >
> > So this one stupid leaf package is killing my ENTIRE update???
> >
> > I guess I'd better pray to Bill Gates that he won't fuck up my
> > Windows 7
> > HTPC by shoving win x down my throat or otherwise I won't be able to
> > even try to play the several games I have that are windows only. =\
> >
> > --
> > IQ is a measure of how stupid you feel.
> >
> > Powers are not rights.
> >
> >
> >
> 
> 
> -- 
> IQ is a measure of how stupid you feel.
> 
> Powers are not rights.
> 
> 


signature.asc
Description: PGP signature

Re: [gentoo-user] Full system encryption on Gentoo

[Alex Corkwell]

On Wed, Dec 30, 2015 at 07:34:52AM +1000, Hans wrote:
> Hi,
> 
> Is it possible to fully encrypt a Gentoo system as can be done with 
> Fedora, Suse, Arch Linux, Debian and Ubunto without using a unencrypted 
> USB boot stick or unencrypted /boot partition?
> 
> If yes, where can I find instructions that really work on a BIOS only 
> box without UEFI, EFI, systemd using EXT4 file system?
> 
> Hans

I can confirm that it's entirely possible, as I've managed to do it with
my laptop.
I don't remember exactly how I did everything, but here are the main
points of my setup.

Each of the three disks in my laptop is set up with GPT partitions
(although it should work fine with plain old DOS-style partitions).

If you use GPT with BIOS, make sure you leave room for (and create) the
GRUB boot partition (which GRUB stores the stage 2 part of the
bootloader in, since the first stage is limited to only a few hundred
bytes by BIOS standards).
Use 4MiB, just to be safe (a couple MiB is cheap, anyway).
You can read about how to get it set up just right here:


Each disk has a LUKS partition.
GRUB2 supports both AES and Serpent (I have partitions of both)
encryption with LUKS, though I recommend AES.

If you look around on the Gentoo wiki, or around online, you can
probably find how to set up the encrypted partitions.
What I did was:

cryptsetup luksFormat -v -c aes-xts-plain64 -h sha512 -y -s 512 \
--use-random -i 4000 /dev/sda2

This sets the encryption and key derivation algorithms and key size to
pretty secure settings.
The 4000 is the number of milliseconds used to compute the encryption
key from your passphrase.
Feel free to increase/decrease as you like.
You can always change it later (you can add and remove encryption
passphrases from the partition with varying derivation times).

Your partitions will be decrypted at boot, but while setting this all
up, decrypt the partition manually with:

cryptsetup luksOpen /dev/sda2 luks-system

This will ask for your passphrase, and open the partition as
/dev/mapper/luks-system.
If you have multiple disks like I do, just open them all and give them
different names.

On top of LUKS, I've got LVM, because it's all shiny and I like to
resize my partitions every few days without rebooting.
If you're not familiar with it, I recommend reading around in the wiki a
little.

Set up your opened encrypted partitions for LVM (as physical volumes
(PVs)) by running:

pvcreate /dev/mapper/luks-system

If you have multiple disks, run that for each partition.

Now, create a volume group to hold all of your partitions by running:

vgcreate sys_vg /dev/mapper/luks-system [...]

If you have any other disks, add them to the end of that command.
"sys_vg" will be the name of your volume group.
You can use pretty much anything, but I recommend suffixing it with
"_vg" so you're not risking collisions with other stuff in "/dev".
I like to use "HOSTNAME_vg" for mine.

(You may need to run `vgchange -a y` to get your system to load the new
volume group now; I don't quite remember.)

Now, create your partitions (logical volumes (LVs)) with:

lvcreate -L 8GiB -n rootfs sys_vg

Replace "8GiB" with whatever partition size you want, and "rootfs" with
whatever you want to name that partition.
I recommend avoiding '-' in the partition name (and volume group name),
as it sometimes escapes them (?) by turning them into "--", but only in
some places.

The LVs will be in /dev/YOUR_VOLUME_GROUP_NAME.
So, for example, the above will create "/dev/sys_vg/rootfs" as your
logical volume.

At the very least, you'll want a boot partition, a swap partition, and a
root partition.

Try to leave them smaller, rather than using up all of the free space.
With LVM, you can grow filesystems (at least, EXT4 and such) online
(that is, without unmounting and/or rebooting).

(That's because LVM maps blocks between the partition that software
sees, and the (encrypted) PVs.
So, logical volumes don't necessarily need to be contiguous, or even on
the same disk.
LVM takes care of that transparently.)

Leave room in case you want to change your partitioning later, or give a
virtual machine its own LV or something.

Format your filesystems just like in the Gentoo Handbook:

mkfs.ext4 -L rootfs /dev/sys_vg/rootfs
mkfs.ext4 -L boot /dev/sys_vg/boot
mkswap -L swap /dev/sys_vg/swap

Then, mount them just like in the Gentoo Handbook and add them to your
fstab.
(Obviously, use /dev/sys_vg/* instead of /dev/sd?* when mounting.)

All of that is a pretty standard LVM/LUKS setup (except for /boot on
LVM/LUKS).

Now, when you compile your kernel, make sure to enable all of the device
mapper, LVM, and encryption features you need.
If you're not sure what you need, poke around on the Gentoo wiki pages
for LVM and/or LUKS.
You can compile them as either modules or built-in (I use modules),
since you'll need an initramfs anyway.

For your initramfs, I 

Re: [gentoo-user] CD ripper that generates song titles?

[Alex Corkwell]

On Wed, Aug 26, 2015 at 04:06:10PM -0400, Walter Dnes wrote:
   I went to the CNE (Canadian National Exhibition) yesterday and
 indulged in a buying spree of 18 CD sets of my fave music (basically
 anything pop/rock/country pre-Beatles).  I now have over 20 CDs that I
 want to rip to flac eventually.  I dread the gruntwork in renaming
 tracks like track01.cdda.wav, etc.  What Gentoo ebuilds are there for
 stuff that'll get ahold of track titles?  Is it in the form of metadata
 on the CD?

I personally like using morituri [1] for ripping my CDs.
It's a little bit slower than some, but very accurate (I believe it
compares several reads, just to make sure there were no errors).
It's not available in the main portage tree, but it's in the dev-zero
overlay as media-sound/morituri.

It can rip to flac (with optional cue files) and works from the
terminal, if you prefer that.
Additionally, it can adjust for drive read offsets when writing files,
and is one of the few Linux things I've found which check the rips
against AccurateRip.

What's particularly nice about it is that it uses what little metadata
and such it can get from the CD to look it up in MusicBrainz and add in
the title, artist, etc.
It also uses this to name the files according to album, artist, song
title, etc.
The template it uses to name the files and directories is relatively
configurable, as well.

If you need more configurable tagging, cover art downloading, and such,
then look into Picard [2], which is in the main portage tree as
media-sound/picard.
It uses MusicBrainz [3] to get a whole bunch of metadata, tags, cover
art, and other stuff, and can rename files much more flexibly than
morituri.

This is especially nice in combination with morituri, since morituri
saves the MusicBrainz ID into the metadata of the ripped files.
Normally, Picard looks files up by either the available metadata, or by
the acoustic fingerprint.
Since the MusicBrainz ID is already there, it immediately knows which
album it is (although it may have the wrong release if you want to be
that precise).

The only caveats with Picard that I know of are that it's GUI only, it
can't embed full size cover art if the image is above some large
resolution, and I think that submitting extra fingerprints requires you
to register with AcoustID [4].
Also, it's not an actual ripper.
It just works on the metadata and tags of flac, mp3, and maybe a few
other types.

I personally like to rip with morituri, then polish the tagging and get
the cover art with Picard.

[1] http://thomas.apestaart.org/morituri/trac/wiki
[2] https://picard.musicbrainz.org/
[3] https://musicbrainz.org/
[4] https://acoustid.org/


signature.asc
Description: PGP signature

Re: [gentoo-user] portage summary logs not rotated any more

[Alex Corkwell]

On Sun, Apr 05, 2015 at 06:31:43PM +0300, Alexander Kapshuk wrote:
 On Sun, Apr 5, 2015 at 5:36 PM, Mick michaelkintz...@gmail.com wrote:
 
 On Sunday 05 Apr 2015 14:19:16 Alexander Kapshuk wrote:
  On Sun, Apr 5, 2015 at 10:50 AM, Mick michaelkintz...@gmail.com wrote:
  An observation I've made, is that my log rotation seems to have effected
  all other logs in /var/log as well. It seems to have stopped working
 around
  January this year.
 
  ls -lt /var/log/messages*
  -rw--- 1 root root 9986127 Apr  5 16:10 /var/log/messages
  -rw--- 1 root root  173843 Jan 12 10:20 
 /var/log/messages-20150112.gz
  -rw--- 1 root root  277867 Jan  4 22:00 
 /var/log/messages-20150104.gz
  -rw--- 1 root root  132157 Dec 28 20:30 
 /var/log/messages-20141228.gz
  -rw--- 1 root root  142911 Dec 22 19:30 
 /var/log/messages-20141222.gz
 
 It seems to me that logrotate stopped rotating your logs back in Jan.  Did
 you
 change something in its configuration back then?
 
 This is what I have in /etc/cron.daily/logrotate:
 
 #!/bin/sh
 
 /usr/sbin/logrotate /etc/logrotate.conf
 EXITVALUE=$?
 if [ $EXITVALUE != 0 ]; then
     /usr/bin/logger -t logrotate ALERT exited abnormally with 
 [$EXITVALUE]
 
 fi
 exit 0
 =
 I then went ahead and ran logrotate by hand, which resulted in the following
 output:
 
 /usr/sbin/logrotate /etc/logrotate.conf
 501 Not authorised --- Reply not authenticated
 501 Not authorised --- Reply not authenticated
 # echo $?
 0
 
 I guess I have to figure out what the error message shown below is all about:
 501 Not authorised --- Reply not authenticated
 
 

I don't know about the 501 Not authorised, but I remember having a
similar issue with logrotate not running beginning around the same time
(the last rotated log was the week of 20141221). I can't remember
exactly what I did, but I believe around then Gentoo (and my system)
switched from vixie-cron to cronie as default. If I remember correctly,
it was anacron that caused the problem.

Take a look at these lines from the default (at least, on my system) for
/etc/crontab:

# check scripts in cron.hourly, cron.daily, cron.weekly and cron.monthly
# if anacron is not present
59  *  * * *root[ ! -x /etc/cron.hourly/0anacron ]  rm -f
/var/spool/cron/lastrun/cron.hourly
9  3  * * * root[ ! -x /etc/cron.hourly/0anacron ]  rm -f
/var/spool/cron/lastrun/cron.daily
19 4  * * 6 root[ ! -x /etc/cron.hourly/0anacron ]  rm -f
/var/spool/cron/lastrun/cron.weekly
29 5  1 * * root[ ! -x /etc/cron.hourly/0anacron ]  rm -f
/var/spool/cron/lastrun/cron.monthly
*/10  *  * * *  root[ ! -x /etc/cron.hourly/0anacron ]  { test -x
/usr/sbin/run-crons  /usr/sbin/run-crons ; }

Essentially, cron.{hourly,daily,weekly,monthly} only get run if
/etc/cron.hourly/0anacron is not executable. On my system, if I remember
correctly, /etc/cron.hourly/0anacron had the executable bit set after I
emerged cronie, but I never set up anacron. I don't know if it properly
runs all the cron.* scripts regularly by default, but after a quick
chmod -x /etc/cron.hourly/0anacron logrotate returned to running
regularly.

I really don't know what's going on with the 501, but I hope that helps
with getting it to run regularly (at least, unless you actually know how
to use anacron, in which you probably know whether or not this makes
some sense).


signature.asc
Description: PGP signature