Re: [gentoo-user] glsa-check question
Marco Simeone wrote: Hello. Do you know why glsa-check tells me to update sun-jdk, even if it's alredy updated ? # glsa-check -p $(glsa-check -t all) This system is affected by the following GLSAs: Checking GLSA 200705-23 The following updates will be performed for this GLSA: dev-java/sun-jdk-1.5.0.15 (1.6.0.06) Checking GLSA 200702-07 The following updates will be performed for this GLSA: dev-java/sun-jdk-1.5.0.15 (1.6.0.06) Checking GLSA 200701-15 The following updates will be performed for this GLSA: dev-java/sun-jdk-1.5.0.15 (1.6.0.06) On my system there are installed sun-jdk-1.6.0.06 and sun-jdk-1.4.2.17 (required by eclipse-sdk-3.2), but not sun-jdk-1.5.0.15. Thanks, Marco. It's not saying what you think. Glsa-check wants to update java by downgrading it. See bug http://bugs.gentoo.org/show_bug.cgi?id=222861 PaulNM -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] glsa-check question
Marco Simeone schrieb: Hello. Do you know why glsa-check tells me to update sun-jdk, even if it's alredy updated ? # glsa-check -p $(glsa-check -t all) This system is affected by the following GLSAs: Checking GLSA 200705-23 The following updates will be performed for this GLSA: dev-java/sun-jdk-1.5.0.15 (1.6.0.06 http://1.6.0.06) Checking GLSA 200702-07 The following updates will be performed for this GLSA: dev-java/sun-jdk-1.5.0.15 (1.6.0.06 http://1.6.0.06) Checking GLSA 200701-15 The following updates will be performed for this GLSA: dev-java/sun-jdk-1.5.0.15 (1.6.0.06 http://1.6.0.06) On my system there are installed sun-jdk-1.6.0.06 and sun-jdk-1.4.2.17 (required by eclipse-sdk-3.2), but not sun-jdk-1.5.0.15. Thanks, Marco. I noticed this a while ago and reported it to the sec herd. They say that this something related to the way the glsa check works. That means every new version has to proofed to be not affected. If you do $ glsa-check -d 200705-23 you find this Vulnerable:1.6.0.01. So glsa-check found version 1.6.0.6 to be affected and report this to you. Reported it directly to the Sec herd or make a bug report to get this fixed. Probably you like to ask why a package is marked stable but not be proofed to be not affected by reported glsa's!? As an easy work around you can inject them, glsa-check -i 200705-23. signature.asc Description: OpenPGP digital signature
[gentoo-user] glsa-check question
Hello. Do you know why glsa-check tells me to update sun-jdk, even if it's alredy updated ? # glsa-check -p $(glsa-check -t all) This system is affected by the following GLSAs: Checking GLSA 200705-23 The following updates will be performed for this GLSA: dev-java/sun-jdk-1.5.0.15 (1.6.0.06) Checking GLSA 200702-07 The following updates will be performed for this GLSA: dev-java/sun-jdk-1.5.0.15 (1.6.0.06) Checking GLSA 200701-15 The following updates will be performed for this GLSA: dev-java/sun-jdk-1.5.0.15 (1.6.0.06) On my system there are installed sun-jdk-1.6.0.06 and sun-jdk-1.4.2.17 (required by eclipse-sdk-3.2), but not sun-jdk-1.5.0.15. Thanks, Marco.
Re: [gentoo-user] glsa-check
On Monday 19 February 2007 02:43:31 Daniel Iliev wrote:
Does glsa-check depend on portage tree syncing? If I haven't synced the
portage tree for let's say a couple of months would glsa-check show any
security updates that appeared after the last syncing?
I found the answer at the link below and it is yes. Sorry for the noise.
http://www.gentoo.org/doc/en/security/security-handbook.xml?part=1chap=14
Yeah, it parses the xml files in ${PORTDIR}/metadata/glsa ...
--
Bo Andresen
pgpjsBrTGIGka.pgp
Description: PGP signature
[gentoo-user] glsa-check
Hi, everyone Does glsa-check depend on portage tree syncing? If I haven't synced the portage tree for let's say a couple of months would glsa-check show any security updates that appeared after the last syncing? -- Best regards, Daniel -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] glsa-check
Daniel Iliev wrote: Hi, everyone Does glsa-check depend on portage tree syncing? If I haven't synced the portage tree for let's say a couple of months would glsa-check show any security updates that appeared after the last syncing? I found the answer at the link below and it is yes. Sorry for the noise. http://www.gentoo.org/doc/en/security/security-handbook.xml?part=1chap=14 -- Best regards, Daniel -- gentoo-user@gentoo.org mailing list
[gentoo-user] glsa-check script
has anyone written a script that checks for glsa security updates and then has it auto emerge the packages it needs to get rid of the security risk? if so i would be very interested in looking at that script. Keeping 5 gentoo machines up to date security wise is becoming very time consuming. thanks Nick -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] glsa-check script
On Thu, May 11, 2006 at 04:35:46PM -0400, Nick Smith wrote: has anyone written a script that checks for glsa security updates and then has it auto emerge the packages it needs to get rid of the security risk? if so i would be very interested in looking at that script. Keeping 5 gentoo machines up to date security wise is becoming very time consuming. There is glsa-check from gentoolkit. I never used it, though. Rasmus -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] glsa-check script
On Thu, 11 May 2006 16:35:46 -0400, Nick Smith wrote: has anyone written a script that checks for glsa security updates and then has it auto emerge the packages it needs to get rid of the security risk? if so i would be very interested in looking at that script. Keeping 5 gentoo machines up to date security wise is becoming very time consuming. I'm not sure that automatically emerging packages like that is a good idea, especially if config changes are involved. I have a daily cron job that mails the output of glsa-check to me, so I can decide for myself. -- Neil Bothwick Men who have playful kittens shouldn't sleep in the nude. signature.asc Description: PGP signature
Re: [gentoo-user] glsa-check script
On 5/11/06, Rasmus Andersen [EMAIL PROTECTED] wrote: On Thu, May 11, 2006 at 04:35:46PM -0400, Nick Smith wrote: has anyone written a script that checks for glsa security updates and then has it auto emerge the packages it needs to get rid of the security risk? if so i would be very interested in looking at that script. Keeping 5 gentoo machines up to date security wise is becoming very time consuming. There is glsa-check from gentoolkit. I never used it, though. Rasmus -- gentoo-user@gentoo.org mailing list thats what im talking about, has anyone ever wrote a script that would automate the check and apply the updates as needed? -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] glsa-check script
On Thu, May 11, 2006 at 05:09:41PM -0400, Nick Smith wrote: On 5/11/06, Rasmus Andersen [EMAIL PROTECTED] wrote: On Thu, May 11, 2006 at 04:35:46PM -0400, Nick Smith wrote: has anyone written a script that checks for glsa security updates and then has it auto emerge the packages it needs to get rid of the security risk? if so i would be very interested in looking at that script. Keeping 5 gentoo machines up to date security wise is becoming very time consuming. There is glsa-check from gentoolkit. I never used it, though. Rasmus -- gentoo-user@gentoo.org mailing list thats what im talking about, has anyone ever wrote a script that would automate the check and apply the updates as needed? from glsa-check --help -f --fix : try to auto-apply this GLSA (experimental) Use at your own risk. I wouln't think of applying anything without seeing what it is first. YMMV festus -- It is not unusual for those at the wrong end of the club to have a clearer picture of reality than those who wield it. Noam Chomsky pgpx3IX7XHc9b.pgp Description: PGP signature
Re: [gentoo-user] glsa-check script
On Thu, 2006-05-11 at 17:41 -0400, John J. Foster wrote: Use at your own risk. I wouln't think of applying anything without seeing what it is first. YMMV I have a cron job that fires off hourly. #!/bin/sh glsa-check -f new 2/dev/null [[ $? -eq 0 ]] || echo glsa-check: error Never had a problem. Never got an error. It's been this way for months. (My mileage doesn't vary ;-) --- Vladimir Vladimir G. Ivanovic Palo Alto, CA 94306 +1 650 678 8014 -- gentoo-user@gentoo.org mailing list
[gentoo-user] glsa-check cron question
Hi, I use often the great tool glsa-check in this way: /usr/bin/glsa-check -l new /tmp/`date +%F`.glsa To produce a file which I could read or mail, to check for vulnerabilities in a machine. What I want to do is to generate this file everyday with a crontab entry like this: 45 6 * * * /usr/bin/glsa-check -l new /tmp/`date +%F`.glsa The problem is that this is not working, it works in the shell, but it doesn't works from cron. If anybody can enlight me, I would appreciate it. -- Andres -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] glsa-check cron question
On Mon, 5 Dec 2005 15:39:00 +0100, Andres Becerra Sandoval wrote: What I want to do is to generate this file everyday with a crontab entry like this: 45 6 * * * /usr/bin/glsa-check -l new /tmp/`date +%F`.glsa The problem is that this is not working, it works in the shell, but it doesn't works from cron. If anybody can enlight me, I would appreciate it. It is probably the redirection screwing things up, but you don't need it with cron. As long as you have cron configured to mail its output to you, you only need 45 6 * * * /usr/bin/glsa-check -l new or, as I prefer to only see the effects on installed packages 45 6 * * * /usr/bin/glsa-check -t all -- Neil Bothwick When there's a will, I want to be in it. signature.asc Description: PGP signature
Re: [gentoo-user] glsa-check cron question
On 12/5/05, Neil Bothwick [EMAIL PROTECTED] wrote: On Mon, 5 Dec 2005 15:39:00 +0100, Andres Becerra Sandoval wrote: What I want to do is to generate this file everyday with a crontab entry like this: 45 6 * * * /usr/bin/glsa-check -l new /tmp/`date +%F`.glsa The problem is that this is not working, it works in the shell, but it doesn't works from cron. If anybody can enlight me, I would appreciate it. It is probably the redirection screwing things up, but you don't need it with cron. As long as you have cron configured to mail its output to you, you only need 45 6 * * * /usr/bin/glsa-check -l new or, as I prefer to only see the effects on installed packages 45 6 * * * /usr/bin/glsa-check -t all -- Neil Bothwick When there's a will, I want to be in it. Thank you, I will set cron to mail me the output. -- Andres -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] glsa-check cron question
On Monday 05 December 2005 09:39, Andres Becerra Sandoval wrote: | 45 6 * * * /usr/bin/glsa-check -l new /tmp/`date +%F`.glsa | | The problem is that this is not working, it works in the shell, but it | doesn't works from cron. If anybody can enlight me, I would appreciate | it. Most of the time, you must put the full path for executables in the crontab... 36 * * * * /usr/bin/glsa-check -l new /tmp/`/usr/bin/date +%F`.glsa works for me. Regards, Kurt -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] glsa-check cron question
On 12/5/05, Kurt V. Hindenburg [EMAIL PROTECTED] wrote: On Monday 05 December 2005 09:39, Andres Becerra Sandoval wrote: | 45 6 * * * /usr/bin/glsa-check -l new /tmp/`date +%F`.glsa | | The problem is that this is not working, it works in the shell, but it | doesn't works from cron. If anybody can enlight me, I would appreciate | it. Most of the time, you must put the full path for executables in the crontab... 36 * * * * /usr/bin/glsa-check -l new /tmp/`/usr/bin/date +%F`.glsa works for me. Regards, Kurt -- gentoo-user@gentoo.org mailing list Thanks! -- Andres -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Glsa-check and binutils-- how to stop the madness?
On Tue, 14 Jun 2005, Holly Bostick wrote: I've been running a little scriptlet to test whether I could get mail sent to my ISP inbox. The full script runs esync and glsa-check, but naturally I didn't want to sync 700 times, so I just ran the glsa-check section. Is this script glcu ? ;-) -- -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Glsa-check and binutils-- how to stop the madness?
Neil Bothwick schreef: On Wed, 15 Jun 2005 01:52:37 +0200, Holly Bostick wrote: Checking GLSA 200506-01 The following updates will be performed for this GLSA: sys-devel/binutils-2.16-r1 (2.16.1) which it has already re-emerged twice, and yet still reports the same vulnerability-- and more importantly, the exact same fix. So it seems to ignore slots, that seems worthy of a bug report. I've never used the --fix option with glsa-check, I read the GLSA and merge the package manually. OK, thanks for the tip. That's two bug reports I've got to submit, then (I've found one in Totem, two days ago). I didn't realize that glsa-check was bugable, since it's 'known buggy' and not really official/supported. But now I'll get to it with all due haste :-) . Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Glsa-check and binutils-- how to stop the madness?
Richard Fish schreef: Holly Bostick wrote: OK, I'm following both of you so far. Yes, I do have 'multislot' for binutils. I admit it was just guesswork on my part; I read the USE flag description, thought about automake and autoconf, thought that binutils sounded like the kind of system utility that might need similar functionality (though for reasons I wouldn't know about, as a non-programmer), so enabled it. But of course, now I still don't know if I actually need it or it's just causing me grief. Was it a bad call? First, let me say that I couldn't find any documentation via google (site:gentoo.org multislot) or in use.desc for multislot. So if I contradict anything that the documentation says, I am probably wrong. ;- $ useflag multislot /usr/portage/profiles/use.local.desc:sys-devel/binutils:multislot - Allow for multiple versions of binutils to be emerged at once for same CTARGET /usr/portage/profiles/use.local.desc:sys-devel/gcc:multislot - Allow for SLOTs to include minor version (3.3.4 instead of just 3.3) useflag is an alias that searches the system useflag docs for the description of the requested useflag. I got it from a posting on this ML, and saved it, it's so useful-- which is why I'll post it again. Put this in your .bashrc: alias useflag='grep /usr/portage/profiles/use.*desc -e' and . ~/.bashrc, and you can just type useflag flag_you_don't_know to get the descriptions. The only reason I can think of for having multiple versions of binutils around is for cross-compiling or distcc use. For both cases, I think you would want the same compiler version and platform target available on all systems. There also might be a dependancy between binutils and gcc versions, (version x of gcc requires version y of binutils). But the current version of gcc should always work with the current version of binutils, so unless you are doing cross-compiling or distcc, I don't really see the point in keeping multiple versions of binutils around. OK, thank you. I am doing neither. Guess that explains why it's an optional dependency. I should have learned by now that adding features that you *might possibly* need (but you don't really know if you need), as opposed to features that you can clearly see that you need (based on your specific system), is just a losing proposition. Every time I try compiling for the future, it just doesn't work out. I've gotta give it up. Now gcc is a different matter, because there are some libraries (libstdc++, libgcj, ...) that are built and installed with gcc, so you could argue that you want to keep multiple versions of that around to avoid breaking dependancies. Since libstdc++ is used by a great many programs, removing it before rebuilding all dependancies with revdep-rebuild could be dangerous. So my advice is, to be safe, update make.conf and/or package.use to remove the multislot flag from binutils but keep it for gcc. That sounds fair. Now, with that said, I don't even think removing multislot from gcc would be dangerous, because every program that links against libstdc++ should be linked against either libstdc++.so or possiblity libstdc++.so.6, not a minor version. So as long as /etc/ld.so.conf and /etc/ld.cache are kept up-to-date (as portage does), and gcc doesn't move to libstdc++.so.7, there is no reason that a gcc update should break anything. Well, since I'm in the process of updating my toolchain and world to make sure that everything is compiled against the same version of GCC (3.4.4), I suppose I don't really need to have multislot for that either. Sigh. I feel like such a yutz... For the record, I don't have either multislot or multitarget, but then again, I also run ~x86, Well, I don't (yet)... this install is new enough that I really want to keep track of what's stable and what's testing (which having to use /etc/portage/package.* enables me to do). But the system is starting to get a bit *too* mixed, and it's about reached the point where it's a diminishing return not to just set ACCEPT_KEYWORDS=~86 in /etc/make.conf which I will probably do after I've finished making sure that the system is all on the same page, as it were. 1) trim out a bunch of binutils slots that I may or may not need (and therefore whose loss may break unknown applications), so that glsa-check The only shared libraries that binutils includes are libbfd and libopcodes, and the only thing I could find on my system that linked against them outside of binutils was oprofile. Since oprofile isn't exactly a critical program, revdep-rebuild would easily fix this. I think the worst case is that you would not be able to compile anything, and would need to run binutils-config to select the correct version. Well, I don't even have oprofile installed, nor do I have most of the other programs: Programs That Depend On binutils app-crypt/johntheripper app-misc/git dev-embedded/tigcc
Re: [gentoo-user] Glsa-check and binutils-- how to stop the madness?
Hi, Richard Fish wrote: Holly Bostick wrote: OK, I'm following both of you so far. Yes, I do have 'multislot' for binutils. I admit it was just guesswork on my part; I read the USE flag description, thought about automake and autoconf, thought that binutils sounded like the kind of system utility that might need similar functionality (though for reasons I wouldn't know about, as a non-programmer), so enabled it. But of course, now I still don't know if I actually need it or it's just causing me grief. Was it a bad call? First, let me say that I couldn't find any documentation via google (site:gentoo.org multislot) or in use.desc for multislot. So if I contradict anything that the documentation says, I am probably wrong. ;- Just a note here, try running: euse -i multislot, here's the output: ...BEGIN... euse -i multislot global use flags (searching: multislot) no matching entries found local use flags (searching: multislot) [-] multislot (sys-devel/binutils): Allow for multiple versions of binutils to be emerged at once for same CTARGET [-] multislot (sys-devel/gcc): Allow for SLOTs to include minor version (3.3.4 instead of just 3.3) ...END... Beside looking in use.desc you can also have a look at use.local.desc file. 'euse' is in gentoolkit ...SKIP... Richard HTH. Rumen smime.p7s Description: S/MIME Cryptographic Signature
Re: [gentoo-user] Glsa-check and binutils-- how to stop the madness?
Holly Bostick wrote: $ useflag multislot /usr/portage/profiles/use.local.desc:sys-devel/binutils:multislot - Allow for multiple versions of binutils to be emerged at once for same CTARGET /usr/portage/profiles/use.local.desc:sys-devel/gcc:multislot - Allow for SLOTs to include minor version (3.3.4 instead of just 3.3) Ah, thanks. I didn't know about use.local.desc. Cool alias. All I've got is gcc, I haven't even gotten around to installing prelink yet. And I can't imagine that any of these programs (gcc, prelink, and elfutils, which prelink requires), would need some old version of binutils hanging around, especially since I would be keeping these reverse dependencies up-to-date. Right. These other dependancies just need to be able to run a program from binutils (ld, ar, etc). That kind if dependancy is much more stable than actually linking to libraries provided by a package. BTW, one of the advantages of prelink is that it will fairly quickly identify every program on the system with a broken library dependancy. I know revdep-rebuild does this too, but prelink is faster. So you're probably right; I can most likely remove multislot from both binutils and gcc (since I only mean to have one version of GCC anyway), recompile everything *yet again* (just to be safe; this system is I know the feeling...can't wait until I can buy a dual-core laptop. -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Glsa-check and binutils-- how to stop the madness?
Holly Bostick wrote: Hi, So my questions are: 1) Am I supposed to have 4 versions of binutils in the first place? Do you have USE 'multislot' or 'multitarget' for binutils? If so, then looking at /usr/portage/eclass/toolchain-binutils.eclass it seems that binutils becomes a slotted package, so you can have multiple versions installed. Otherwise, no. 2) How do I get this GLSA to actually apply, or know that it's applied, or whatever? I think emerge --prune binutils should do the trick. It will remove all versions except the most recent, so the GLSA shouldn't apply to you anymore... -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Glsa-check and binutils-- how to stop the madness?
Richard Fish schreef: Holly Bostick wrote: So my questions are: 1) Am I supposed to have 4 versions of binutils in the first place? Do you have USE 'multislot' or 'multitarget' for binutils? If so, then looking at /usr/portage/eclass/toolchain-binutils.eclass it seems that binutils becomes a slotted package, so you can have multiple versions installed. Otherwise, no. Matthew Cline schreef: Holly Bostick wrote: 2) How do I get this GLSA to actually apply, or know that it's applied, or whatever? IIRC, glsa-check has an 'inject' option for just this purpose. If you run glsa-check without command-line parameters, it should print out a usage message. OK, I'm following both of you so far. Yes, I do have 'multislot' for binutils. I admit it was just guesswork on my part; I read the USE flag description, thought about automake and autoconf, thought that binutils sounded like the kind of system utility that might need similar functionality (though for reasons I wouldn't know about, as a non-programmer), so enabled it. But of course, now I still don't know if I actually need it or it's just causing me grief. Was it a bad call? As far as the --inject option, yes it's there, I just didn't notice it; Syntax: glsa-check option [glsa-list] -l --list : list all unapplied GLSA -d --dump : show all information about the given GLSA --print -t --test : test if this system is affected by the given GLSA -p --pretend : show the necessary commands to apply this GLSA -f --fix : try to auto-apply this GLSA (experimental) -i --inject: inject the given GLSA into the checkfile But what all this advice adds up to is that to fix this problem, I can either: 1) trim out a bunch of binutils slots that I may or may not need (and therefore whose loss may break unknown applications), so that glsa-check (which is apparently broken with respect to binutils compiled with the multislot USE flag) can accurately determine that it has applied the fix to the binutils it perceives; or 2) lie to glsa-check and tell it that I've fixed the problem, even though I may still be vulnerable to it (because one of the other versions that it has some vague sense are installed but cannot see well enough to fix may in fact need to be fixed). I recognize that this is really a problem with glsa-check, which is, by it's own admission, untested/buggy, but I am, perhaps understandably, not completly comfortable with either of these proposed solutions. Although I'm fairly sure one or both of them would solve the presenting symptoms, what I ultimately want is not only for glsa-check to stop acting up, but some assurance that the GLSA is actually applied to the application or applications in question. Frankly, glsa-check can say whatever it wants, if I know the GLSA fixes are actually applied properly. Can either of you, or anyone, instruct me further in these matters? Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Glsa-check and binutils-- how to stop the madness?
On Wed, 15 Jun 2005 00:16:20 +0200, Holly Bostick wrote: 1) trim out a bunch of binutils slots that I may or may not need (and therefore whose loss may break unknown applications), so that glsa-check (which is apparently broken with respect to binutils compiled with the multislot USE flag) can accurately determine that it has applied the fix to the binutils it perceives; I don't think that glsa-check is at fault here. You have four versions of binutils installed. according to the GLSA, one of them, 2.14.90.0.8-r1, is vulnerable. So it would seem that as long as you have this package installed, glsa-check is correct to warn you. -- Neil Bothwick Windows - From the people who brought you EDLIN! pgpnwULrk6HS9.pgp Description: PGP signature
Re: [gentoo-user] Glsa-check and binutils-- how to stop the madness?
Holly Bostick wrote: OK, I'm following both of you so far. Yes, I do have 'multislot' for binutils. I admit it was just guesswork on my part; I read the USE flag description, thought about automake and autoconf, thought that binutils sounded like the kind of system utility that might need similar functionality (though for reasons I wouldn't know about, as a non-programmer), so enabled it. But of course, now I still don't know if I actually need it or it's just causing me grief. Was it a bad call? First, let me say that I couldn't find any documentation via google (site:gentoo.org multislot) or in use.desc for multislot. So if I contradict anything that the documentation says, I am probably wrong. ;- The only reason I can think of for having multiple versions of binutils around is for cross-compiling or distcc use. For both cases, I think you would want the same compiler version and platform target available on all systems. There also might be a dependancy between binutils and gcc versions, (version x of gcc requires version y of binutils). But the current version of gcc should always work with the current version of binutils, so unless you are doing cross-compiling or distcc, I don't really see the point in keeping multiple versions of binutils around. Now gcc is a different matter, because there are some libraries (libstdc++, libgcj, ...) that are built and installed with gcc, so you could argue that you want to keep multiple versions of that around to avoid breaking dependancies. Since libstdc++ is used by a great many programs, removing it before rebuilding all dependancies with revdep-rebuild could be dangerous. So my advice is, to be safe, update make.conf and/or package.use to remove the multislot flag from binutils but keep it for gcc. Now, with that said, I don't even think removing multislot from gcc would be dangerous, because every program that links against libstdc++ should be linked against either libstdc++.so or possiblity libstdc++.so.6, not a minor version. So as long as /etc/ld.so.conf and /etc/ld.cache are kept up-to-date (as portage does), and gcc doesn't move to libstdc++.so.7, there is no reason that a gcc update should break anything. For the record, I don't have either multislot or multitarget, but then again, I also run ~x86, 1) trim out a bunch of binutils slots that I may or may not need (and therefore whose loss may break unknown applications), so that glsa-check The only shared libraries that binutils includes are libbfd and libopcodes, and the only thing I could find on my system that linked against them outside of binutils was oprofile. Since oprofile isn't exactly a critical program, revdep-rebuild would easily fix this. I think the worst case is that you would not be able to compile anything, and would need to run binutils-config to select the correct version. -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Glsa-Check -f Was [What is the recommended order of maintenance updates?]
On Mon, 2005-04-25 at 11:56 +0800, William Kenworthy wrote: Are etcat -v evolution [ I] 1.4.6 (0) [ I] 2.0.3-r2 (2.0) Hmm.. seems like that may be the case.. Thanks. -- Ow Mun Heng Gentoo/Linux on DELL D600 1.4Ghz 98% Microsoft(tm) Free!! Neuromancer 15:41:02 up 18:47, 7 users, load average: 1.25, 0.54, 0.44 -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Glsa-Check -f Was [What is the recommended order of maintenance updates?]
I find glsa rarely lies, which is more than can be said about the other three: often one will pick something up but not the others. This also brings up one of the disadvantages of gentoo's slotting system - without running something like glsa, its quite possible (probable on an older system in fact) that you will leave insecure versions hanging around if you just do an emerge -u. The old watch the security list and manually emerge -u wont always protect you ... Add things like package.keyword and the problem multiplies. BillK On Mon, 2005-04-25 at 15:47 +0800, Ow Mun Heng wrote: On Mon, 2005-04-25 at 11:56 +0800, William Kenworthy wrote: Are etcat -v evolution [ I] 1.4.6 (0) [ I] 2.0.3-r2 (2.0) Hmm.. seems like that may be the case.. Thanks. -- Ow Mun Heng Gentoo/Linux on DELL D600 1.4Ghz 98% Microsoft(tm) Free!! Neuromancer 15:41:02 up 18:47, 7 users, load average: 1.25, 0.54, 0.44 -- William Kenworthy [EMAIL PROTECTED] Home! -- gentoo-user@gentoo.org mailing list
[gentoo-user] Glsa-Check -f Was [What is the recommended order of maintenance updates?]
On Sat, 2005-04-23 at 15:56 +0800, William Kenworthy wrote: In my experience, you may get away with this regime for a short time on an almost new system, but it will almost invariably break an older system (due to emerge depclean) The safest/most reasonable order is emerge sync glsa-check -l|grep \[N glsa-check -f AnyPackagesReportedAbove glsa-check seems to want to patch up Evo for me. 200501-35 [N] Evolution: Integer overflow in camel-lock-helper ( mail-client/evolution ) but I have Evo 2.0.3-r2 installed what gives?? -- Ow Mun Heng Gentoo/Linux on DELL D600 1.4Ghz 98% Microsoft(tm) Free!! Neuromancer 11:10:44 up 14:17, 7 users, load average: 0.30, 0.41, 0.28 -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Glsa-Check -f Was [What is the recommended order of maintenance updates?]
Are etcat -v evolution equery l evolution qpkg -i evolution consistent? This sometimes happens on older systems with upgrades that slot, and/or clean properly. glsa-check is a good way to pick this up BillK On Mon, 2005-04-25 at 11:10 +0800, Ow Mun Heng wrote: 200501-35 -- William Kenworthy [EMAIL PROTECTED] Home! -- gentoo-user@gentoo.org mailing list
