[gentoo-user] swi-prolog-7.3.7 missing digest
I saw this last night: /usr/bin/eclean-dist * Building file list for distfiles cleaning... * Missing digest for '/usr/portage/dev-lang/swi-prolog/swi- prolog-7.3.7.ebuild' Does it need reporting or will it be OK on the next resync? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] swi-prolog-7.3.7 missing digest
On Thu, Oct 1, 2015 at 3:43 AM, Mick <michaelkintz...@gmail.com> wrote: > I saw this last night: > > /usr/bin/eclean-dist > * Building file list for distfiles cleaning... > * Missing digest for '/usr/portage/dev-lang/swi-prolog/swi- > prolog-7.3.7.ebuild' > > Does it need reporting or will it be OK on the next resync? https://bugs.gentoo.org/show_bug.cgi?id=561966 -- Rich
Re: [gentoo-user] swi-prolog-7.3.7 missing digest
On Thursday 01 Oct 2015 11:53:09 Rich Freeman wrote: > On Thu, Oct 1, 2015 at 3:43 AM, Mick <michaelkintz...@gmail.com> wrote: > > I saw this last night: > > > > /usr/bin/eclean-dist > > > > * Building file list for distfiles cleaning... > > * Missing digest for '/usr/portage/dev-lang/swi-prolog/swi- > > > > prolog-7.3.7.ebuild' > > > > Does it need reporting or will it be OK on the next resync? > > https://bugs.gentoo.org/show_bug.cgi?id=561966 Thank you Rich. :-) -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] Installing swi-prolog and gnustep-base in the same time
Hi, it seems, that swi-prolog and gnustep-base cannpot be installed in the same time because both packages share the same file /usr/bin/pl what is the best solution, to handle this situation? Regards
Re: [gentoo-user] Installing swi-prolog and gnustep-base in the same time
On Wed, 19 Dec 2012 23:21:01 +0100 Frank Schwidom schwi...@gmx.net wrote: Hi, it seems, that swi-prolog and gnustep-base cannpot be installed in the same time because both packages share the same file /usr/bin/pl what is the best solution, to handle this situation? file a bug at b.g.o. asking for one or both ebuilds to be modified. You've probably read the long output emerge gives when it encounters a file collision and the warnings not to file gratuitous bugs without full info on ebuilds and files etc. Well, this is not one of those cases, this is a valid bug. In the interim, you could also modify the ebuild locally (or slipstream your own patch) to rename the files before install. This will let you get both installed until the bug is fixed. -- Alan McKinnon alan.mckin...@gmail.com
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 dev-lang/swi
[gentoo-user] blocked packages both required by the system sys-apps/openrc vs. sys-apps/net-tools?
I just emerged --sync and now when I try to update world, I get this conflict: * Error: The above package list contains packages which cannot be * installed at the same time on the same system. (sys-apps/net-tools-1.60_p20120127084908::gentoo, ebuild scheduled for merge) pulled in by sys-apps/net-tools required by @system (sys-apps/openrc-0.9.8.4::gentoo, installed) pulled in by sys-apps/openrc required by (dev-db/mysql-init-scripts-2.0_pre1-r2::gentoo, ebuild scheduled for merge) sys-apps/openrc required by (sys-apps/baselayout-2.1-r1::gentoo, installed) where both sys-apps/net-tools and sys-apps/baselayout-2.1-r1 therefore sys-apps/openrc are required by the system. What can I do to resolve this conflict? Why does gentoo want to install conflicting packages at the same time on my system? # emerge --pretend --tree --update world These are the packages that would be merged, in reverse order: Calculating dependencies ... . done! [ebuild U ] app-misc/screen-4.0.3-r6 [4.0.3-r5] [ebuild U ] x11-terms/xterm-285 [279] [ebuild U ] x11-drivers/xf86-video-ast-0.97.0 [0.95.0] [ebuild U ] x11-drivers/xf86-video-tdfx-1.4.5 [1.4.4-r1] [ebuild U ] x11-drivers/xf86-video-tga-1.2.2 [1.2.1] [ebuild U ] dev-lang/swi-prolog-6.2.0 [5.10.5-r1] USE=static-libs%* -archive% [ebuild U ] x11-drivers/xf86-video-r128-6.9.1 [6.8.2-r1] [ebuild U ] x11-drivers/xf86-video-siliconmotion-1.7.7 [1.7.6] [ebuild U ] x11-wm/sawfish-1.9.0 [1.8.2] [ebuild U ] x11-drivers/xf86-video-i128-1.3.6 [1.3.5] [ebuild U ] media-video/vlc-2.0.3 [2.0.1] [ebuild U ] x11-drivers/xf86-video-sis-0.10.7 [0.10.4-r1] [ebuild U ] x11-drivers/xf86-video-glint-1.2.8 [1.2.7] [ebuild U ] app-emulation/emul-linux-x86-gtklibs-20121028 [20120520] [ebuild U ] app-text/build-docbook-catalog-1.19.1 [1.4] [ebuild U ] x11-misc/xscreensaver-5.20 [5.15] USE=-gdm% (-selinux) [ebuild U ] x11-drivers/xf86-video-apm-1.2.5 [1.2.4] [ebuild U ] x11-drivers/xf86-video-dummy-0.3.6 [0.3.5-r1] [ebuild U ] x11-drivers/xf86-video-s3-0.6.5 [0.6.4] [ebuild U ] sys-fs/fuse-2.9.1-r1 [2.8.6] [ebuild U ] x11-drivers/xf86-video-mga-1.6.2 [1.5.0] [ebuild U ] x11-drivers/xf86-video-i740-1.3.4 [1.3.3] [ebuild U ] net-p2p/transmission-2.73 [2.52] [ebuild U ] x11-drivers/xf86-input-evdev-2.7.3 [2.7.0] [ebuild U ] app-emulation/qemu-1.1.2-r2 [1.1.1-r1] USE=jpeg%* png%* threads%* uuid%* vde* vnc%* -mixemu% -systemtap% QEMU_SOFTMMU_TARGETS=-lm32% [ebuild U ] x11-drivers/xf86-video-qxl-0.1.0 [0.0.17] [ebuild U ] x11-drivers/xf86-input-elographics-1.4.1 [1.3.0] [ebuild U ] x11-drivers/xf86-video-mach64-6.9.3 [6.9.1] [ebuild U ] www-plugins/adobe-flash-11.2.202.251 [11.2.202.238] [ebuild U ~] www-client/firefox-bin-17.0 [15.0.1] [ebuild U ] x11-drivers/xf86-input-wacom-0.17.0 [0.14.0] [ebuild U ] x11-drivers/xf86-video-openchrome-0.3.1 [0.2.906] [ebuild U ] x11-drivers/xf86-video-ark-0.7.5 [0.7.4] [ebuild U ] net-mail/metamail-2.7.53.3-r1 [2.7.53.3] USE=static-libs%* [ebuild U ] x11-drivers/xf86-input-synaptics-1.6.2-r1 [1.6.2] [ebuild NS] dev-db/postgresql-server-9.2.1 [9.1.5] USE=nls pam python -doc -perl -pg_legacytimestamp (-selinux) -tcl -uuid -xml LINGUAS=-af -cs -de -en -es -fa -fr -hr -hu -it -ko -nb -pl -pt_BR -ro -ru -sk -sl -sv -tr -zh_CN -zh_TW [ebuild U ] media-sound/fluidsynth-1.1.6 [1.1.1] USE=dbus%* -examples% [ebuild U ] www-client/firefox-10.0.10 [10.0.7] [ebuild U ] x11-drivers/xf86-video-trident-1.3.6 [1.3.5] [ebuild U ] x11-drivers/xf86-video-s3virge-1.10.6 [1.10.5] [ebuild U ] sys-fs/cryptsetup-1.4.3 [1.4.1] USE=static-libs%* -static* [ebuild U ] x11-drivers/xf86-video-savage-2.3.6 [2.3.4-r1] [ebuild U ] x11-drivers/xf86-video-neomagic-1.2.7 [1.2.6] [ebuild U ] x11-drivers/xf86-video-voodoo-1.2.5 [1.2.4] [ebuild U ] media-libs/freeglut-2.8.0-r1 [2.8.0] [ebuild U ] app-crypt/gpgme-1.3.2 [1.3.0-r1] USE=static-libs%* [ebuild U ] x11-drivers/xf86-video-cirrus-1.5.1 [1.4.0] [ebuild U ] www-servers/apache-2.2.23 [2.2.22-r1] [ebuild U ] net-dns/bind-9.9.1_p4 [9.9.1_p3] [ebuild U ] x11-drivers/xf86-input-mouse-1.8.1 [1.7.2] [ebuild U ] x11-drivers/xf86-video-vesa-2.3.2 [2.3.1] [ebuild U ] x11-drivers/xf86-video-nv-2.1.20 [2.1.18] [ebuild U ] x11-drivers/xf86-video-fbdev-0.4.3 [0.4.2] [ebuild U ] x11-drivers/xf86-input-keyboard-1.6.2 [1.6.1] [ebuild U ] net-misc/wget-1.14 [1.13.4-r1] USE=pcre%* zlib%* -uuid% [ebuild U ] sys-apps/man-pages-3.43 [3.41] [ebuild U ] dev-db/mysql-5.1.66 [5.1.62-r1] [ebuild U ] media-video/mplayer-1.1-r1 [1.0_rc4_p20110322-r1] USE=-faac* [nomerge ] media-sound/pulseaudio-2.1-r1 [1.1-r1] USE=gtk%* webrtc-aec%* xen%* (-systemd) [ebuild N ] media
