Re: [gentoo-user] Preventing a package from being updated
Apparently, though unproven, at 02:26 on Monday 25 October 2010, Allan Gottlieb did opine thusly: Alan McKinnon alan.mckin...@gmail.com writes: Just because you're paranoid doesn't mean they're NOT out to get you :-) Or in this case, it doesn't mean it's not justified. I now have buildpkg enabled for @system - everything else I can re-run emerge to fix. Does this mean for portage -2.1.9.22 you advocate FEATURES=buildsyspkg in make.conf? If so is that the correct line or do we need FEATURES=buildsyspkg sandbox I find the man page wording a little unclear and its warning about an error serious. You're adding extra stuff into the mix and confusing the issue. Forget about sandbox in the context of this thread, just take whatever you have in FEATURES and add buildsyspkg to it. That's it, nothing more, nothing less. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Preventing a package from being updated
Apparently, though unproven, at 04:36 on Monday 25 October 2010, Dale did opine thusly: Then again, Alan knows Gentoo pretty well and may know that he doesn't need sandbox. Once for fun I build a gentoo system in VirtualBox and left sandbox out by accident. The results were ... awful. Bad stuff happened. It was so bad I forgot all the details and started over. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Preventing a package from being updated
On Mon, Oct 25, 2010 at 5:36 AM, Dale rdalek1...@gmail.com wrote: FEATURES= buildpkg sandbox fixpackages parallel-fetch --keep-going I thought --keep-going goes into EMERGE_DEFAULT_OPTS, no? -- Fatih
Re: [gentoo-user] Preventing a package from being updated
On 10/25/2010 01:24 AM, Alan McKinnon wrote: Apparently, though unproven, at 04:36 on Monday 25 October 2010, Dale did opine thusly: Then again, Alan knows Gentoo pretty well and may know that he doesn't need sandbox. Once for fun I build a gentoo system in VirtualBox and left sandbox out by accident. Where did you leave it out? Or do you mean you took it out with a -sandbox? The results were ... awful. Bad stuff happened. It was so bad I forgot all the details and started over.
Re: [gentoo-user] Preventing a package from being updated
Apparently, though unproven, at 15:09 on Monday 25 October 2010, Bill Longman did opine thusly: On 10/25/2010 01:24 AM, Alan McKinnon wrote: Apparently, though unproven, at 04:36 on Monday 25 October 2010, Dale did opine thusly: Then again, Alan knows Gentoo pretty well and may know that he doesn't need sandbox. Once for fun I build a gentoo system in VirtualBox and left sandbox out by accident. Where did you leave it out? Or do you mean you took it out with a -sandbox? Yes, I took it out with -sandbox. I was being pathetic that day and attempted a pathetic solution. The results were ... pathetic too ! -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Preventing a package from being updated
Alan McKinnon alan.mckin...@gmail.com writes: Apparently, though unproven, at 02:26 on Monday 25 October 2010, Allan Gottlieb did opine thusly: Alan McKinnon alan.mckin...@gmail.com writes: Just because you're paranoid doesn't mean they're NOT out to get you :-) Or in this case, it doesn't mean it's not justified. I now have buildpkg enabled for @system - everything else I can re-run emerge to fix. Does this mean for portage -2.1.9.22 you advocate FEATURES=buildsyspkg in make.conf? If so is that the correct line or do we need FEATURES=buildsyspkg sandbox I find the man page wording a little unclear and its warning about an error serious. You're adding extra stuff into the mix and confusing the issue. Forget about sandbox in the context of this thread, just take whatever you have in FEATURES and add buildsyspkg to it. That's it, nothing more, nothing less. OK. Since currently it is empty, I just need FEATURES= buildsyspackage i.e, I do NOT need to include sandbox. Yes? allan
Re: [gentoo-user] Preventing a package from being updated
On Monday 25 October 2010 9:50:30 pm Allan Gottlieb wrote: Yes? yes -- - Yohan Pereira.
Re: [gentoo-user] Preventing a package from being updated
Apparently, though unproven, at 13:50 on Saturday 23 October 2010, daid kahl did opine thusly: 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. Just because you're paranoid doesn't mean they're NOT out to get you :-) Or in this case, it doesn't mean it's not justified. I now have buildpkg enabled for @system - everything else I can re-run emerge to fix. After watching portage break python *twice* exactly a year apart, watching the exciting developments in python-3, after some horrendous shadow breakage 3 years ago and the convoluted upgrade path for bash 2 years ago, and someone's b0rked commit of glibc-2.12 to the tree quite recently, I feel entirely justified in keeping binary copies of @system around. It long ago stopped being paranoia and started being good old common sense (right up there with backups). -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Preventing a package from being updated
Alan McKinnon alan.mckin...@gmail.com writes: Just because you're paranoid doesn't mean they're NOT out to get you :-) Or in this case, it doesn't mean it's not justified. I now have buildpkg enabled for @system - everything else I can re-run emerge to fix. Does this mean for portage -2.1.9.22 you advocate FEATURES=buildsyspkg in make.conf? If so is that the correct line or do we need FEATURES=buildsyspkg sandbox I find the man page wording a little unclear and its warning about an error serious. thanks allan
Re: [gentoo-user] Preventing a package from being updated
Allan Gottlieb wrote: Alan McKinnonalan.mckin...@gmail.com writes: Just because you're paranoid doesn't mean they're NOT out to get you :-) Or in this case, it doesn't mean it's not justified. I now have buildpkg enabled for @system - everything else I can re-run emerge to fix. Does this mean for portage -2.1.9.22 you advocate FEATURES=buildsyspkg in make.conf? If so is that the correct line or do we need FEATURES=buildsyspkg sandbox I find the man page wording a little unclear and its warning about an error serious. thanks allan This is mine. FEATURES= buildpkg sandbox fixpackages parallel-fetch --keep-going It has been that way here for a pretty long while and no problems that I know of. According to the man page, you should have sandbox in there as well. I think Alan was showing what could be added but not all the options that are available and should be there. Then again, Alan knows Gentoo pretty well and may know that he doesn't need sandbox. Just thought I would share a example that is in use and appears to work. Dale :-) :-)
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] 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] 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
Re: [gentoo-user] Preventing a package from being updated
Neil Bothwick n...@digimed.co.uk writes: On Mon, 18 Oct 2010 13:06:25 +0300, Timur Aydin wrote: I am using the ~x86 (testing) version of gentoo linux. After recent updates, my X windows became extremely sluggish and I found out that the problem is related to a new version of mesa (7.8.2 specifically). So I downgraded to version 7.7.1 and my desktop works great again. Now I want to prevent mesa from being updated until this issue is sorted out upstream. I have looked at package.provide, but that didn't work. Currently, I have placed media-libs/mesa into my /etc/portage/package.mask file and this seems to do the trick. Is this the recommended way for handling this situation? package.mask is the right place, but you should add the specific version. Then the system will only upgrade when a newer (hopefully fixed) version arrives. =media-libs/mesa-7.8.2 I tried this yesterday with great success. As mentioned in b.g.o. 7.8.2 causes slowdowns for many people (including me). This system is ~amd64 But this morning after an eix-sync, my normal update failed ajglap gottlieb # emerge --keep-going --update --newuse --with-bdeps=y --color n world These are the packages that would be merged, in reverse order: Calculating dependencies... done! [nomerge ] gnome-base/gnome-2.30.2 USE=cdr cups dvdr ldap policykit -accessibility -mono [nomerge ] app-crypt/seahorse-2.30.1 USE=ldap libnotify -avahi -debug -doc -test [nomerge ] app-crypt/gpgme-1.3.0 USE=-common-lisp -pth [nomerge ]app-crypt/gnupg-2.0.16-r2 USE=bzip2 ldap nls -adns -caps -doc -openct -pcsc-lite (-selinux) -smartcard -static [nomerge ] app-crypt/pinentry-0.8.0-r1 USE=gtk ncurses qt4 -caps -static [ebuild U ] app-admin/eselect-pinentry-0.3 [0.2] 0 kB [nomerge ] x11-base/xorg-x11-7.4-r1 [ebuild U ] x11-apps/smproxy-1.0.4 [1.0.3] USE=(-debug%) 111 kB [nomerge ] gnome-base/gnome-2.30.2 USE=cdr cups dvdr ldap policykit -accessibility -mono [nomerge ] gnome-base/libgnomeprintui-2.18.6 USE=-doc [nomerge ] x11-themes/gnome-icon-theme-2.30.3 [nomerge ]x11-misc/icon-naming-utils-0.8.90 [nomerge ] dev-perl/XML-Simple-2.18 [nomerge ] dev-perl/XML-LibXML-1.70 [nomerge ] dev-lang/perl-5.12.2-r1 USE=berkdb gdbm -build -debug -doc -ithreads [ebuild U ]app-admin/perl-cleaner-2.7 [2.6] 6 kB [nomerge ] gnome-base/gnome-2.30.2 USE=cdr cups dvdr ldap policykit -accessibility -mono [nomerge ] app-admin/sabayon-2.30.1 [ebuild UD] x11-base/xorg-server-1.7.7-r1 [1.9.0.902] USE=hal%* ipv6 kdrive nptl sdl%* xorg -debug% -dmx -minimal -tslib (-doc%) (-static-libs%) (-udev%*) 4,829 kB [nomerge ] gnome-base/gnome-2.30.2 USE=cdr cups dvdr ldap policykit -accessibility -mono [nomerge ] gnome-base/gdm-2.20.11 USE=branding consolekit gnome-keyring ipv6 pam tcpd -accessibility -afs -debug -dmx -remote (-selinux) -xinerama [nomerge ] sys-auth/pambase-20100925 USE=consolekit cracklib gnome-keyring sha512 -debug -kerberos -minimal -mktemp -passwdqc (-selinux) -ssh [nomerge ]sys-auth/consolekit-0.4.2-r3 [0.4.2-r1] USE=pam policykit -debug -doc -test [blocks b ] sys-apps/shadow-4.1.4.2-r6 (sys-apps/shadow-4.1.4.2-r6 is blocking sys-auth/consolekit-0.4.2-r3) [ebuild U ] sys-apps/shadow-4.1.4.2-r6 [4.1.4.2-r5] USE=cracklib nls pam -audit (-selinux) -skey 1,749 kB [ebuild U ]sys-auth/consolekit-0.4.2-r3 [0.4.2-r1] USE=pam policykit -debug -doc -test 403 kB [ebuild UD] x11-apps/xinit-1.2.1 [1.2.1-r2] USE=minimal pam -debug 139 kB [nomerge ] media-gfx/gimp-2.6.10 USE=alsa dbus exif gnome hal jpeg lcms mmx mng pdf png python sse svg tiff -aalib (-altivec) -curl -debug -doc -smp -webkit -wmf [nomerge ] media-libs/gegl-0.1.2 USE=cairo jpeg mmx png sdl sse svg -debug -doc -ffmpeg -openexr -raw -v4l [nomerge ] gnome-base/librsvg-2.26.3 USE=zlib -doc -tools [nomerge ]gnome-extra/libgsf-1.14.19 USE=bzip2 gnome gtk python -doc -thumbnail [nomerge ] media-gfx/imagemagick-6.6.4.5 USE=X bzip2 corefonts cxx jpeg lcms openmp perl png svg tiff truetype xml zlib -autotrace -djvu -fftw -fontconfig -fpx -graphviz -gs -hdri -jbig -jpeg2k -lqr -openexr -q32 -q8 -raw -static-libs -wmf VIDEO_CARDS=nvidia [nomerge ] x11-drivers/nvidia-drivers-256.53 USE=acpi gtk (multilib) -custom-cflags [nomerge ] x11-base/xorg-server-1.7.7-r1 [1.9.0.902] USE=hal%* ipv6 kdrive nptl sdl%* xorg -debug% -dmx -minimal -tslib (-doc%) (-static-libs%) (-udev%*) [ebuild N]x11-libs/libxkbui-1.0.2 USE=-debug 217 kB [nomerge ] gnome-base/gnome-2.30.2 USE=cdr cups dvdr ldap policykit -accessibility -mono [nomerge ] gnome-extra/gnome-power-manager-2.30.1 USE=hal policykit -debug -doc -test [nomerge
Re: [gentoo-user] Preventing a package from being updated
Apparently, though unproven, at 16:11 on Friday 22 October 2010, Allan Gottlieb did opine thusly: [snip] package.mask is the right place, but you should add the specific version. Then the system will only upgrade when a newer (hopefully fixed) version arrives. =media-libs/mesa-7.8.2 I tried this yesterday with great success. As mentioned in b.g.o. 7.8.2 causes slowdowns for many people (including me). This system is ~amd64 But this morning after an eix-sync, my normal update failed [snip] !!! All ebuilds that could satisfy =media-libs/mesa-7.8_rc[nptl=] have been masked. !!! One of the following masked packages is required to complete your request: - media-libs/mesa-7.8.2 (masked by: package.mask) /etc/portage/package.mask: # This version of mesa 7.8.2 is rummored to cause slowdown # The previous version 7.7.1 is rummored to be much better # Masking only 7.8.2 so that future (fixed??) versions can be installed (dependency required by x11-base/xorg-server-1.9.0.902 [ebuild]) For more information, see the MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. Would you like to merge these packages? [Yes/No] no Quitting. ajglap gottlieb # Perhaps I should be downgrading xorg-server as well. Masking mesa-7.8.2 means (per the ebuilds) you will have to drop back to xorg-server-1.7.7-r1. Both are latest stable versions. Or, you could always install the xorg overlay and build the latest git copy of mesa... Since I would rather have a slow X than an angry portage, I removed the package mask and expected all to be well, but was surprised by the following. In particular at the end it says there is one block but I don't see any. [snip] Here you go: [blocks b ] sys-apps/shadow-4.1.4.2-r6 (sys-apps/shadow-4.1.4.2-r6 is blocking sys-auth/consolekit-0.4.2-r3) [ebuild U ] sys-apps/shadow-4.1.4.2-r6 [4.1.4.2-r5] USE=cracklib nls pam -audit (-selinux) -skey 1,749 kB 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 -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Preventing a package from being updated
Alan McKinnon alan.mckin...@gmail.com writes: Apparently, though unproven, at 16:11 on Friday 22 October 2010, Allan Gottlieb did opine thusly: [snip] Perhaps I should be downgrading xorg-server as well. Masking mesa-7.8.2 means (per the ebuilds) you will have to drop back to xorg-server-1.7.7-r1. Both are latest stable versions. See below Since I would rather have a slow X than an angry portage, I removed the package mask and expected all to be well, but was surprised by the following. In particular at the end it says there is one block but I don't see any. [snip] Here you go: [blocks b ] sys-apps/shadow-4.1.4.2-r6 (sys-apps/shadow-4.1.4.2-r6 is blocking sys-auth/consolekit-0.4.2-r3) [ebuild U ] sys-apps/shadow-4.1.4.2-r6 [4.1.4.2-r5] USE=cracklib nls pam -audit (-selinux) -skey 1,749 kB I really did look for b's, but didn't see it. I guess I was looking near the ] where all the U's are. Embarrassing, to say the least. Thanks. 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. thanks again, allan
Re: [gentoo-user] Preventing a package from being updated
Am 18.10.2010 12:06, schrieb Timur Aydin: Hi, I am using the ~x86 (testing) version of gentoo linux. After recent updates, my X windows became extremely sluggish and I found out that the problem is related to a new version of mesa (7.8.2 specifically). So I downgraded to version 7.7.1 and my desktop works great again. Now I want to prevent mesa from being updated until this issue is sorted out upstream. I have looked at package.provide, but that didn't work. Currently, I have placed media-libs/mesa into my /etc/portage/package.mask file and this seems to do the trick. Is this the recommended way for handling this situation? Being a long time gentoo user, I want to do things the right way, so just working fine isn't enough :) Hi, from man poratage: package.mask A list of package atoms to mask. Useful if specific versions of packages do not work well for you. For example, you swear by the Nvidia drivers, but only versions earlier than 1.0.4496. No problem! Regards kh
Re: [gentoo-user] Preventing a package from being updated
On Mon, 18 Oct 2010 13:06:25 +0300, Timur Aydin wrote: I am using the ~x86 (testing) version of gentoo linux. After recent updates, my X windows became extremely sluggish and I found out that the problem is related to a new version of mesa (7.8.2 specifically). So I downgraded to version 7.7.1 and my desktop works great again. Now I want to prevent mesa from being updated until this issue is sorted out upstream. I have looked at package.provide, but that didn't work. Currently, I have placed media-libs/mesa into my /etc/portage/package.mask file and this seems to do the trick. Is this the recommended way for handling this situation? package.mask is the right place, but you should add the specific version. Then the system will only upgrade when a newer (hopefully fixed) version arrives. =media-libs/mesa-7.8.2 -- Neil Bothwick WindowError:01B Illegal error. Do NOT get this error. signature.asc Description: PGP signature
