Re: [gentoo-user] Re: ZFS formating

2013-11-04 Thread Douglas J Hunley
On Fri, Nov 1, 2013 at 11:29 AM, James wirel...@tampabay.rr.com wrote:

 livedvd-x86-amd64-32ul-20121221.iso
 Is what you are referring to?


yes



 I suggested using SystemRescue, because I had to clean up
 (hack extensively) on  Grub2 before the system would boot standalone.
 In that first Pentoo install, I use ext2 for /boot and ext4 for /


I don't use grub. I have an ext2 /boot and lilo on a md stripe :)



 If I use ZFS, /boot / and swap are all ZFS partitions, right?


they can be, but don't have to be. i've seen several people put swap onto a
zram device


-- 
Douglas J Hunley (doug.hun...@gmail.com)
Twitter: @hunleyd   Web:
douglasjhunley.com
G+: http://google.com/+DouglasHunley


[gentoo-user] GPT UUID fstab

2013-11-04 Thread James
Hello,

I'm having trouble getting a new install to boot. It's a recent Gigabit
mobo, which supports EFI. I looked at the bios and all looks fine but it
could be a misconfigure in the bios setting? 


It's a simple setup for now (/boot / and swap)  When using gparted, I
selected GPT but made sure the  boot flag was also set for the /boot
partition. I check the UUIDs using blkid


Here's the /etc/fstab (note shown here as 2 lines but single lines
in the fstab file):

  /dev/sda1  UUID=413ede34-4638-4c54-80a1-8de5343d8cfd  
  /boot  / ext2   defaults,noatime,nodiratime

  /dev/sda2 UUID=f85e16fb-76e3-4284-ab10-c0680ecc6b15  
  swap swap defaults 0 0

  /dev/sda3 UUID=4d847c6f-696c-4449-85ea-d985f1b3affb 
  / ext4 defaults,noatime,nodiratime

Any ideas where I went astray? Trying not to use the MBR
on this GPT EFI system with a single 2T drive.


Maybe somebody could post a simple GPT EFI UUID example fstab




Re: [gentoo-user] re: resolving blocked packages [media-video/ffmpeg-1.2:0]

2013-11-04 Thread Alexander Kapshuk
On 11/03/2013 02:27 AM, Daniel Campbell wrote:
 For starters, you should probably merge package.keywords into
 package.accept_keywords; the latter is the new standard name, though
 Portage will likely support the old names for a while. Just a heads-up
 on that.
Thanks for a heads-up. I did as you suggested.




Re: [gentoo-user] re: resolving blocked packages [media-video/ffmpeg-1.2:0]

2013-11-04 Thread Alexander Kapshuk
On 11/03/2013 11:42 AM, Peter Humphrey wrote:
 On Sunday 03 Nov 2013 07:40:12 Alexander Kapshuk wrote:

 What about skype? Does it have to be in the keywords file as well? From
 memory, I put it there as instructed on the gentoo wiki page.
 If you remove it, the next emerge world will tell you why it was in there :-)

 Don't worry - it won't let you make a mess of your system.

Thanks for the tip.

I thought I'd leave this one as is for the time being.

All the ebuilds available for skype seem to have ~x86 specified anyway.

box0=; pwd
/usr/portage/net-im/skype
box0=; grep KEYWORDS *.ebuild
skype-2.2.0.35-r99.ebuild:KEYWORDS=~amd64 ~x86
skype-4.0.0.8-r1.ebuild:KEYWORDS=~amd64 ~x86
skype-4.1.0.20.ebuild:KEYWORDS=~amd64 ~x86
skype-4.2.0.11-r1.ebuild:KEYWORDS=~amd64 ~x86
skype-4.2.0.11.ebuild:KEYWORDS=~amd64 ~x86




Re: [gentoo-user] re: resolving blocked packages [media-video/ffmpeg-1.2:0] [SOLVED]

2013-11-04 Thread Alexander Kapshuk
On 11/03/2013 10:26 AM, Alan McKinnon wrote:
 On 02/11/2013 21:06, Alexander Kapshuk wrote:
 The basic problem is a stable system with a bunch of unstable packages
 installed.

 The requested vlc version is ~arch, which wants a ~arch version of
 gnutls. This conflicts with other stable packages that want a stable
 version of gnutls.

 Mixing and matching arch and ~arch like this often causes unsolveable
 problems, especially with basic libs like gnutls used by lots of
 packages. In this specific case, I doubt very much that the problem is
 solveable. Either make the entire system ~arch or downgrade vlc to
 stable. Mixing is not recommended, not that it won't work (it often
 does), but because users so often run into these problems and devs
 usually will not help fix it. The user is thus totally on tehir own with
 this one.


 Ah, I wasn't aware that it wasn't a supported thing. Good points; the
 testing necessary to support mixed systems is more than any dev team
 could handle realistically. I mix and match, but only for a select few
 packages that simply don't have a stable version.

 Alex: In order to get ~arch vlc, you had to put vlc in your
 package.accept_keywords file. Try removing that to go back to the stable
 build and see if that corrects things. If not, then I agree with Alan
 and you should probably make the big decision of stable or testing.

 Thanks very much for your responses to my original query.

 What I did do prior to getting your responses was try and resolve the
 dependency conflict as shown below.

 (1). I added '=net-libs/gnutls-3.2.5 ~x86' and
 '=media-video/ffmpeg-1.2.4 ~x86' to package.accept_keywords:
 box0=; egrep 'gnutls|ffmpeg' /etc/portage/package.accept_keywords
 =net-libs/gnutls-3.2.5 ~x86
 =media-video/ffmpeg-1.2.4 ~x86
 (2). I then updated 'media-video/ffmpeg' to version
 'media-video/ffmpeg-1.2.4', like so:
 emerge --ask 'media-video/ffmpeg-1.0.7'
 !!! existing preserved libs:
 package: media-video/ffmpeg-1.2.4
  *  - /usr/lib/libavutil.so.51
  *  - /usr/lib/libavutil.so.51.73.101
  *  used by /usr/bin/mencoder (media-video/mplayer-1.1.1-r1)
  *  used by /usr/bin/mplayer (media-video/mplayer-1.1.1-r1)
  *  used by /usr/lib/vlc/plugins/codec/libavcodec_plugin.so
 (media-video/vlc-2.0.9)
  *  used by /usr/lib/vlc/plugins/demux/libavformat_plugin.so
 (media-video/vlc-2.0.9)
 Use emerge @preserved-rebuild to rebuild packages using these libraries
 (3). I then pulled in the other updates:
 emerge --ask --update --deep --with-bdeps=y --newuse world
 (4). Rebuilt the preserved libs as recorded in
 /var/lib/portage/preserved_libs_registry
 emerge --ask @preserved-rebuild

 So far, the whole system seems to be running OK.

 Yes, that is how it is done


 It did occur to me afterwards, like Alan and Daniel suggested, that
 mixing stable and unstable packages was not a good idea.

 The reason it's not a good idea usually is that you get these conflicts
 with dependencies. The software still runs and things still work but the
 user can cause themselves lots of extra hassle to make it work.

 Here, vlc depends on a gnutls version 3, which is a bit sad. I would
 hope the authors of vlc would support all current versions of gnutls.

 One option is to ask does your media player really require TLS
 support? Maybe it's just a nice feature and you can do without it, so
 add to package.use:

 media-video/vlc -gnutls

 It's something worth considering

 I put vlc ~x86 in package.keywords as instructed here,
 http://www.videolan.org/vlc/download-gentoo.html.
 box0=; cat /etc/portage/package.keywords
 media-video/vlc ~x86

 Turns out, it wasn't such a good idea after all.

 What would I have to do to downgrade vlc, gnutls and ffmpeg to the
 stable versions of the packages?
 I guess I'd have to remove their respective entries from
 /etc/portage/package.(accept)_keywords.
 box0=; cat /etc/portage/package.keywords
 media-video/vlc ~x86
 box0=; cat /etc/portage/package.accept_keywords
 =net-im/skype-4.2.0.11-r1 ~x86
 =sys-devel/gettext-0.18.3.1-r1 ~x86
 =net-libs/gnutls-3.2.5 ~x86
 =media-video/ffmpeg-1.2.4 ~x86

 How would I instruct emerge to do that properly?
 Just run emerge -avuND world and emerge will do all the necessary
 downgrades.

 Then run emerge -a --depclean to remove any slotted libs that might
 have been pulled in and are no longer needed (a simple emerge world does
 not deal with those)

 Or, you can try sidestep the issue and avoid gnutls completely as above.

 Yet another option is to request that gnutls be slotted so that you can
 have v2 and v3 at the same time and don't have to choose (openssl
 already works this way). You do this by opening a feature request bug at
 bugs.gentoo.org

Thanks very much for all your replies.

I did as suggested above. It all worked without any further ado.

Thanks to you all once again.




Re: [gentoo-user] GPT UUID fstab

2013-11-04 Thread J. Roeleveld
James wirel...@tampabay.rr.com wrote:
Hello,

I'm having trouble getting a new install to boot. It's a recent Gigabit
mobo, which supports EFI. I looked at the bios and all looks fine but
it
could be a misconfigure in the bios setting? 


It's a simple setup for now (/boot / and swap)  When using gparted, I
selected GPT but made sure the  boot flag was also set for the /boot
partition. I check the UUIDs using blkid


Here's the /etc/fstab (note shown here as 2 lines but single lines
in the fstab file):

  /dev/sda1  UUID=413ede34-4638-4c54-80a1-8de5343d8cfd  
  /boot  / ext2   defaults,noatime,nodiratime

  /dev/sda2 UUID=f85e16fb-76e3-4284-ab10-c0680ecc6b15  
  swap swap defaults 0 0

  /dev/sda3 UUID=4d847c6f-696c-4449-85ea-d985f1b3affb 
  / ext4 defaults,noatime,nodiratime

Any ideas where I went astray? Trying not to use the MBR
on this GPT EFI system with a single 2T drive.


Maybe somebody could post a simple GPT EFI UUID example fstab

Use either UUID or device in fstab, not both.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-user] re: resolving blocked packages [media-video/ffmpeg-1.2:0]

2013-11-04 Thread Mick
On Monday 04 Nov 2013 19:51:32 Alexander Kapshuk wrote:
 On 11/03/2013 02:27 AM, Daniel Campbell wrote:
  For starters, you should probably merge package.keywords into
  package.accept_keywords; the latter is the new standard name, though
  Portage will likely support the old names for a while. Just a heads-up
  on that.
 
 Thanks for a heads-up. I did as you suggested.

Is there going to be a portage news article on this, or did I miss it?
-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-user] re: resolving blocked packages [media-video/ffmpeg-1.2:0]

2013-11-04 Thread Alan McKinnon
On 05/11/2013 00:43, Mick wrote:
 On Monday 04 Nov 2013 19:51:32 Alexander Kapshuk wrote:
 On 11/03/2013 02:27 AM, Daniel Campbell wrote:
 For starters, you should probably merge package.keywords into
 package.accept_keywords; the latter is the new standard name, though
 Portage will likely support the old names for a while. Just a heads-up
 on that.

 Thanks for a heads-up. I did as you suggested.
 
 Is there going to be a portage news article on this, or did I miss it?
 


Seeing as it was about 2 or maybe 3 years ago, I'm sure you missed it :-)

-- 
Alan McKinnon
alan.mckin...@gmail.com




Re: [gentoo-user] re: resolving blocked packages [media-video/ffmpeg-1.2:0]

2013-11-04 Thread Dale
Alan McKinnon wrote:
 On 05/11/2013 00:43, Mick wrote:
 On Monday 04 Nov 2013 19:51:32 Alexander Kapshuk wrote:
 On 11/03/2013 02:27 AM, Daniel Campbell wrote:
 For starters, you should probably merge package.keywords into
 package.accept_keywords; the latter is the new standard name, though
 Portage will likely support the old names for a while. Just a heads-up
 on that.
 Thanks for a heads-up. I did as you suggested.
 Is there going to be a portage news article on this, or did I miss it?


 Seeing as it was about 2 or maybe 3 years ago, I'm sure you missed it :-)


+1.  I missed it too. 

Dale

:-)  :-) 

-- 
I am only responsible for what I said ... Not for what you understood or how 
you interpreted my words!




Re: [gentoo-user] re: resolving blocked packages [media-video/ffmpeg-1.2:0]

2013-11-04 Thread Bruce Hill
On Mon, Nov 04, 2013 at 10:43:07PM +, Mick wrote:
 On Monday 04 Nov 2013 19:51:32 Alexander Kapshuk wrote:
  On 11/03/2013 02:27 AM, Daniel Campbell wrote:
   For starters, you should probably merge package.keywords into
   package.accept_keywords; the latter is the new standard name, though
   Portage will likely support the old names for a while. Just a heads-up
   on that.
  
  Thanks for a heads-up. I did as you suggested.
 
 Is there going to be a portage news article on this, or did I miss it?

It wasn't two or three years ago...

mingdao@server ~ $ eselect news read 5
2012-09-09-make.conf-and-make.profile-move
  Title make.conf and make.profile move
  AuthorJorge Manuel B. S. Vicetto jmbsvice...@gentoo.org
  Posted2012-09-09
  Revision  1

Starting next week, new stages will have make.conf and make.profile
moved from /etc to /etc/portage. This is a change in the installation
defaults, that will only affect new installs so it doesn't affect
current systems.

Current users don't need to do anything. But if you want to follow the
preferred location, you may want to take the chance to move the files
in your system(s) to the new location.
-- 
Happy Penguin Computers   ')
126 Fenco Drive   ( \
Tupelo, MS 38801   ^^
supp...@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting



[gentoo-user] Re: resolving blocked packages [media-video/ffmpeg-1.2:0]

2013-11-04 Thread Nuno J. Silva (aka njsg)
On 2013-11-05, Bruce Hill da...@happypenguincomputers.com wrote:
 On Mon, Nov 04, 2013 at 10:43:07PM +, Mick wrote:
 On Monday 04 Nov 2013 19:51:32 Alexander Kapshuk wrote:
  On 11/03/2013 02:27 AM, Daniel Campbell wrote:
   For starters, you should probably merge package.keywords into
   package.accept_keywords; the latter is the new standard name, though
   Portage will likely support the old names for a while. Just a heads-up
   on that.
  
  Thanks for a heads-up. I did as you suggested.
 
 Is there going to be a portage news article on this, or did I miss it?

 It wasn't two or three years ago...

 mingdao@server ~ $ eselect news read 5
 2012-09-09-make.conf-and-make.profile-move
   Title make.conf and make.profile move
   AuthorJorge Manuel B. S. Vicetto 
 jmbsvice...@gentoo.org
   Posted2012-09-09
   Revision  1

 Starting next week, new stages will have make.conf and make.profile
 moved from /etc to /etc/portage. This is a change in the installation
 defaults, that will only affect new installs so it doesn't affect
 current systems.

 Current users don't need to do anything. But if you want to follow the
 preferred location, you may want to take the chance to move the files
 in your system(s) to the new location.

But that's about make.conf, not about package.keywords.

-- 
Nuno Silva (aka njsg)