Re: [gentoo-user] Preventing a package from being updated
Apparently, though unproven, at 05:13 on Saturday 23 October 2010, Allan Gottlieb did opine thusly: Now I have masked mesa-7.8.2 downgrading to 7.7.1, which necessitated a downgrade of xorg-server to 1.7.7-r1 (latest stable), which necessitated a downgrade of xinit to 1.2.1. Thus my emerges now generate msgs that updates to xorg-server and xinit are being skipped due to unsatisfied dependencies. Other than this, the emerges perform normally and the system runs well. I could mask the newer versions of xorg-server and xinit and possibly prevent the emerge messages, but I am leaning toward leaving it as it is. This way when mesa is updated (to a hopefully fixed version) everything should update automatically. Does that sound reasonable. Yes, that will work fine. You'll just have to tolerate those messages in the interim, but you know they are there and why. Nothing will break because of it. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] baselayout -- openrc ?
Neil Bothwick wrote: On Sat, 23 Oct 2010 02:50:26 +0200, Alan McKinnon wrote: You're mixing two different definitions of stable. Portage 2.2 is certainly reliable, but it is anything but stable with a new version coming out every day at the moment,. I'm waiting for tomorrow when my regularly scheduled portage update hits _rc100. Well, it hasn't happened yet. A day without a portage update, a rare thing these days. Maybe someone decided that Gentoo is not Debian and 99 release candidates should be enough for a bunch of python scripts. Or after 99 tries, they just can't do it right and should give up. lol Dale :-) :-)
Re: [gentoo-user] baselayout -- openrc ?
On Friday 22 October 2010 21:52:18 Dale wrote: I'm just hoping that when the switch comes, it is painless. It was for me - so much so that I wondered what all the fuss had been about. -- Rgds Peter. Linux Counter 5290, 1994-04-23.
Re: [gentoo-user] baselayout -- openrc ?
On Sat, Oct 23, 2010 at 02:48:58AM +0200, Alan McKinnon wrote:
Apparently, though unproven, at 23:50 on Friday 22 October 2010, Zeerak
Mustafa Waseem did opine thusly:
It's openrc-${PV}+1 - there's no question about that.
Until someone actually ponies up and commits something other than openrc
to the tree, it's gonna stay on openrc.
I think you misunderstand what ~arch means.
I'll gladly be explained, just in case I should have it wrong. :-)
What I meant however was that there has been talk of starting a migration
of ~arch users to devicekit when it is deemed ready. As far as I remember
no conclusion was brought to that discussion other than openrc being moved
inhouse and seeing how that went. So the ball is still in the air as far
as openrc and a replacement goes, to my understanding.
~arch is the collection of unstable ebuilds in portage; stuff that is good
enough for a release but not yet fully tested within a Gentoo system. With
enough successful feedback from users, it is marked stable and moves to
arch.
~arch is not experimental, stuff planned for the future, someone's wicked
overlay or anything else other than stable releases in a *gentoo* test phase,
i.e. it's not so much the software that's being tested but the ebuild.
snip
It seems I understood then, though it seems I haven't clearly portrayed my
understanding, but thanks for explaining anyway :)
devicekit stands very little chance of ever being the default. It depends on
dbus and expat. Remember hal and all the crap that came along with it? Gentoo
is not Ubuntu or Fedora, it is installable on anything from ARM phones to
IBM's gigantic hard iron. Why on earth would anyone mandate dbus to be
compulsory on a headless server for example?
If you want to know what the future holds for Gentoo, best not to listen much
to a bunch of dudes rambling on gentoo-dev and blogs. They're just talking,
and talk is cheap. If you want to know what the future holds for @system and
the toolchain, vapier is a good one to listen to. So's the council, GLEPs and
whatever happens in voting. The kong thread that's been mentioned in this
thread has a gem of a quote from vapier, something like:
People saw Roy moving away from Gentoo, and freaked out.
That's it, nothing more. Some dudes freaked out.
Besides, lookee here:
nazgul ~ # eix -e devicekit
* sys-apps/devicekit
Available versions: (~)003 {doc}
Homepage:http://www.freedesktop.org/wiki/Software/DeviceKit
Description: D-Bus abstraction for enumerating devices and
listening for device events using udev
nazgul ~ # eix -e dbus-glib
[I] dev-libs/dbus-glib
Available versions: 0.86 (~)0.88 {bash-completion debug doc static-libs
test}
Installed versions: 0.88(00:25:33 12/10/10)(bash-completion -debug -doc
-static-libs -test)
Homepage:http://dbus.freedesktop.org/
Description: D-Bus bindings for glib
nazgul ~ # eix systemd
No matches found.
devicekit has one version (003) and systemd doesn't even have an ebuild in
the
tree. That system is probably sitting about where openrc was when Roy had
gotten to 20% of where he eventually took it.
openrc works, it has three outstanding edge case blocker bugs. What possible
technical reason is there to go chasing butterflies down some totally
unproven
path?
In this case I'm completely with you. While there are nifty features in systemd
it is nothing that can't be achieved by other means and openrc really does work
brilliantly (for me) so I'm not exactly against systemd, I just don't see a
point in using it. Other than aligning with other distros, but then what's the
point of having different distributions if they all are alike :)
--
Zeerak Waseem
Re: [gentoo-user] baselayout -- openrc ?
On 22 October 2010 11:02, James wirel...@tampabay.rr.com wrote: Hello, Well here it seems that openrc is going ~arch http://forums.gentoo.org/viewtopic-t-688090.html So has it been decided that openrc is the way forward? Any caveats with openrc we should be aware of? Just to put in my two cents, which is largely a smaller general point and not related to the fairly informative discussion regarding openrc itself. Basically, any time I do a major update like this, I make a disk image styled backup. I run other backups more regularly (rsnapshot), but if something hits the fan on an update and I don't have the time, patience, or luck to fix it right away, then I just toss my system back to exactly how it was without fretting. These days it's either the first point (a matter of time right then) or just a comfort factor from my older days of doing large Gentoo updates and not knowing a lot of the basics of how to properly update. Anyway, systemrescuecd or even something simple like gparted live cd will have partimage which is a quick and easy tool for full backups. Just don't turn off the 2GB file size if you use the gzip option (something goes wrong that I forget now). Of course you can even use dd if you it's your style. I'm aware this strays slightly from the main question asked here, but I think that question was considered already by others. That being said, I too did the openrc migration a long ways back and it was fine. I also agree with the general sentiment that sticking with ARCH or ~ARCH makes more sense. But if you have some time right now to do updates and plan to be really busy in the near future, then that could be a reason to do such an update. ~daid
Re: [gentoo-user] Preventing a package from being updated
Don't worry about it. I'm not sure if portage-2.1.9.20 will deal with this automagically (I *think* it does these days and 2.2 definitely does) but if not just emerge -C shadow ; emerge -1 shadow then emerge -avuND world. No good technical reason for doing shadow first apart from getting it over and done with while you watch and confirm it works fine. Then do world and wander over to the kettle letting portage go on with doing it's thing unattended For my own comfort, on a case like this, if I didn't have the portage FEATURE buildpkg or buildsyspkg turned on, I'd make sure that was on and that I had a functional backup of shadow to install from binary, in case something went very wrong. But I tend to be extremely cautious in terms of how I maintain my system, and a lot of that caution is just paranoia. ~daid
Re: [gentoo-user] emerge depclean gcc
2010/10/21 Michael Hampicke gentoo-u...@hadt.biz: May I just unmerge my old gcc ? Is it save ? Yes it's save to unmerge your old gcc. You could also - using quickpkg - create a binary package of your old gcc before unmerging (for backup puropses). From the strictly Gentoo side of things, it's safe (following instructions already posted). However, for myself, I use tons of third party physics software, among other things. A lot of it is not very recent, and sometimes they are picky about which gcc compiles is (and sometimes I need a shell script to switch the gcc for execution of those programs and switch back afterward...joy!) So if you do a lot of compiling of external programs that are not as well maintained and updated, there's not a lot of reason to *unmerge* an old gcc. There are two reasons to actually remove gcc's in my opinion: revdep-rebuild wants to reinstall all of them, you need the disk space. I have 10 options under gcc-config. I'm not at all recommending this to everyone, but just making the point that, depending on what other things you have going on, it's a good idea to check any third party stuff, at the very least, before just removing it, since there's not much harm in keeping a few extra gccs around for rainy days. ~daid
Re: [gentoo-user] Preventing a package from being updated
Alan McKinnon alan.mckin...@gmail.com writes: Apparently, though unproven, at 05:13 on Saturday 23 October 2010, Allan Gottlieb did opine thusly: Now I have masked mesa-7.8.2 downgrading to 7.7.1, which necessitated a downgrade of xorg-server to 1.7.7-r1 (latest stable), which necessitated a downgrade of xinit to 1.2.1. Thus my emerges now generate msgs that updates to xorg-server and xinit are being skipped due to unsatisfied dependencies. Other than this, the emerges perform normally and the system runs well. I could mask the newer versions of xorg-server and xinit and possibly prevent the emerge messages, but I am leaning toward leaving it as it is. This way when mesa is updated (to a hopefully fixed version) everything should update automatically. Does that sound reasonable. Yes, that will work fine. You'll just have to tolerate those messages in the interim, but you know they are there and why. Nothing will break because of it. Thanks. allan
Re: [gentoo-user] Preventing a package from being updated
daid kahl daid...@gmail.com writes: Don't worry about it. I'm not sure if portage-2.1.9.20 will deal with this automagically (I *think* it does these days and 2.2 definitely does) but if not just emerge -C shadow ; emerge -1 shadow then emerge -avuND world. No good technical reason for doing shadow first apart from getting it over and done with while you watch and confirm it works fine. Then do world and wander over to the kettle letting portage go on with doing it's thing unattended For my own comfort, on a case like this, if I didn't have the portage FEATURE buildpkg or buildsyspkg turned on, I'd make sure that was on and that I had a functional backup of shadow to install from binary, in case something went very wrong. But I tend to be extremely cautious in terms of how I maintain my system, and a lot of that caution is just paranoia. Thanks for the advice. I do use quickpkg as well. allan
[gentoo-user] cruft after perl-cleaner --all
perl-cleaner could not deal with /usr/lib/perl5/vendor_perl/5.8.8/XML/SAX/ParserDetails.ini /usr/lib/perl5/5.8.8/i686-linux/Encode/ConfigLocal.pm I ran equery belongs and neither turned up. Should I just copy them away and remove them in a week if nothing turns up or are they known to be needed cruft. thanks, allan
Re: [gentoo-user] cruft after perl-cleaner --all
Allan Gottlieb schrieb am 23.10.2010 18:13: perl-cleaner could not deal with /usr/lib/perl5/vendor_perl/5.8.8/XML/SAX/ParserDetails.ini /usr/lib/perl5/5.8.8/i686-linux/Encode/ConfigLocal.pm I ran equery belongs and neither turned up. It is cruft! Some leftovers from perl-5.8.8. There should be new ones in the corresponding locations for perl-5.12.2 after upgrading and running perl-cleaner. /usr/lib/perl5/vendor_perl/5.12.2/XML/SAX/ParserDetails.ini /usr/lib/perl5/5.12.2/i686-linux/Encode/ConfigLocal.pm After the switch to a new perl version and successful run of perl-cleaner it should be safe to remove everything below /usr/lib/perl5 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl for older perl installations, except stuff belonging to packages which were not installed by the package manager or have been altered manually. -- Daniel Pielmeier signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] cruft after perl-cleaner --all
Daniel Pielmeier bil...@gentoo.org writes: Allan Gottlieb schrieb am 23.10.2010 18:13: perl-cleaner could not deal with /usr/lib/perl5/vendor_perl/5.8.8/XML/SAX/ParserDetails.ini /usr/lib/perl5/5.8.8/i686-linux/Encode/ConfigLocal.pm I ran equery belongs and neither turned up. It is cruft! Some leftovers from perl-5.8.8. There should be new ones in the corresponding locations for perl-5.12.2 after upgrading and running perl-cleaner. Indeed there were. /usr/lib/perl5/vendor_perl/5.12.2/XML/SAX/ParserDetails.ini /usr/lib/perl5/5.12.2/i686-linux/Encode/ConfigLocal.pm After the switch to a new perl version and successful run of perl-cleaner it should be safe to remove everything below /usr/lib/perl5 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl for older perl installations, except stuff belonging to packages which were not installed by the package manager or have been altered manually. Thank you allan
[gentoo-user] usb stick autodiscovery
Hello, On most of my kde workstations when I plug in a usb(memory)stick and popup screen appears Devices recently plugged in: On one kde system, this does not occur and I do not know what app/software to install or configure lsusb shows the device properly, just like the other system. None of the systems that work correctly use coldplug, all have the dbus flag set in make.conf. Any hints are most appreciated. James
Re: [gentoo-user] usb stick autodiscovery
Diff your make.conf and package.use files. Somethong is probably missing. On Oct 23, 2010 3:46 PM, James wirel...@tampabay.rr.com wrote: Hello, On most of my kde workstations when I plug in a usb(memory)stick and popup screen appears Devices recently plugged in: On one kde system, this does not occur and I do not know what app/software to install or configure lsusb shows the device properly, just like the other system. None of the systems that work correctly use coldplug, all have the dbus flag set in make.conf. Any hints are most appreciated. James
Re: [gentoo-user] cruft after perl-cleaner --all
Allan Gottlieb wrote: Daniel Pielmeierbil...@gentoo.org writes: Allan Gottlieb schrieb am 23.10.2010 18:13: perl-cleaner could not deal with /usr/lib/perl5/vendor_perl/5.8.8/XML/SAX/ParserDetails.ini /usr/lib/perl5/5.8.8/i686-linux/Encode/ConfigLocal.pm I ran equery belongs and neither turned up. It is cruft! Some leftovers from perl-5.8.8. There should be new ones in the corresponding locations for perl-5.12.2 after upgrading and running perl-cleaner. Indeed there were. /usr/lib/perl5/vendor_perl/5.12.2/XML/SAX/ParserDetails.ini /usr/lib/perl5/5.12.2/i686-linux/Encode/ConfigLocal.pm After the switch to a new perl version and successful run of perl-cleaner it should be safe to remove everything below /usr/lib/perl5 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl for older perl installations, except stuff belonging to packages which were not installed by the package manager or have been altered manually. Thank you allan Yep. I had one file left over that it printed out to. I ran equery b file/name to see if it belonged to anything and it didn't. A little rm did the trick. Is there a way to find cruft? Some script or something? My install is pretty old and I would guess there are a few left over files here and there. Dale :-) :-)
Re: [gentoo-user] usb stick autodiscovery
James wrote: Hello, On most of my kde workstations when I plug in a usb(memory)stick and popup screen appears Devices recently plugged in: On one kde system, this does not occur and I do not know what app/software to install or configure lsusb shows the device properly, just like the other system. None of the systems that work correctly use coldplug, all have the dbus flag set in make.conf. Any hints are most appreciated. James On mine, I had to add the device notifier widget to the panel. That is what does the little pop up here. Looks like one of your systems didn't add that by default, mine didn't either tho. Oh, the unmount/eject thingy don't work here. Do a sync command somewhere after copying files over to make sure it didn't cache them somewhere instead of writing them right then. Dale :-) :-)
Re: [gentoo-user] Re: usb stick autodiscovery
James wrote: Dalerdalek1967at gmail.com writes: Hello Dale, On mine, I had to add the device notifier widget to the panel. That is what does the little pop up here. Looks like one of your systems didn't add that by default, mine didn't either tho. Well device notifier is on the systems that work. somehow it got deleted off this system I missing the 'dolphin file manager' and the 'usb viewer' from the kde-4.4.2 H, somehow this looks strange What the best way to rebuild all of the kde packages on a (kde-meta) system? emerge kde-meta only rebuild the meta package itself Or should I just re_emerge a few selected packages? (PS, try this command 'lshal') just for grins.. James Well, I'm sure some guru has a better way to list all the KDE packages installed but I use this: qlist -I | grep kde I then take that list and create a set and just emerge the set. It worked a while back. r...@smoker / # lshal Dumping 129 device(s) from the Global Device List: I didn't know I had 129 devices in this rig. Sort of funny how much stuff it takes to make a puter run nowadays. Dale :-) :-)
[gentoo-user] Re: usb stick autodiscovery
Dale rdalek1967 at gmail.com writes: Hello Dale, On mine, I had to add the device notifier widget to the panel. That is what does the little pop up here. Looks like one of your systems didn't add that by default, mine didn't either tho. Well device notifier is on the systems that work. somehow it got deleted off this system I missing the 'dolphin file manager' and the 'usb viewer' from the kde-4.4.2 H, somehow this looks strange What the best way to rebuild all of the kde packages on a (kde-meta) system? emerge kde-meta only rebuild the meta package itself Or should I just re_emerge a few selected packages? (PS, try this command 'lshal') just for grins.. James
[gentoo-user] Re: usb stick autodiscovery
James wireless at tampabay.rr.com writes: What the heck, I'm rebuidling via: emerge -D $(qlist -IC kde-base/) ...we'll see in the morning how it works. James
