Re: [gentoo-user] Re: Network scanner
On Saturday 25 Feb 2017 08:25:43 Neil Bothwick wrote: > On Sat, 25 Feb 2017 07:35:43 +, Mick wrote: > > Back on topic, I always held the view that one should not mix and match > > package managers on the same system, as they may end up stepping on > > each other's toes. So, I thought emerge and rpm don't go together. Is > > this not the case? > > Using another package manager is no worse than installing from source, > either way you are installing software without the knowledge of portage. > A better solution is to look for an ebuild on Bugzilla, which probably > ends up installing the same files but now portage knows about that. > > There's even an rpm eclass for such ebuilds to call on when software is > only available as an RPM package. Yes, this is my understanding too. Thanks for confirming. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] Strange hickups while trying to compile a kernel in a chroot
hi,
I am trying to build a linux kernel (vanilla from ftp.kernel.org)
in my chrooted new root.
make modules install
failed
with:
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
CHK include/generated/bounds.h
CHK include/generated/timeconst.h
CHK include/generated/asm-offsets.h
CALLscripts/checksyscalls.sh
CHK include/generated/compile.h
./scripts/gen_initramfs_list.sh: Cannot open '/usr/share/v86d/initramfs'
make[1]: *** [usr/Makefile:73: usr/initramfs_data.cpio.gz] Error 1
make: *** [Makefile:988: usr] Error 2
make bImage fails with
(chroot) make bzImage
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
CHK include/generated/bounds.h
CHK include/generated/timeconst.h
CHK include/generated/asm-offsets.h
CALLscripts/checksyscalls.sh
CHK include/generated/compile.h
./scripts/gen_initramfs_list.sh: Cannot open '/usr/share/v86d/initramfs'
make[1]: *** [usr/Makefile:73: usr/initramfs_data.cpio.gz] Error 1
make: *** [Makefile:988: usr] Error 2
I look for the magic v83d and found (being at my old root)
[I] sys-apps/v86d
Available versions: 0.1.10 {debug x86emu}
Installed versions: 0.1.10(02:34:27 02/28/11)(x86emu -debug)
Homepage:https://dev.gentoo.org/~spock/projects/uvesafb/
Description: A daemon to run x86 code in an emulated environment
Is this "quite normal" or does the make process of the kernel make
false conclusion while being chrooted?
Do I really need initram? ... For years I though my grub had
booted the kernel which runs my linux directlu...
My commandline to build the kernel at my old root was:
kernel=/boot/vmlinuz-4091200-64-RT && make -j7 all && make -j7 modules_install
&& /bin/cp -f ./arch/x86_64/boot/bzImage* $kernel; emerge nvidia-drivers
;emerge app-emulation/virtualbox-modules ;grub-mkconfig -o /boot/grub/grub.cfg
whjch had.
v86d is not installed yet and of course I will install it if needed.
But I want to get shure, that the chrooted environment has not
confused the kernel build process...
Thanks for any help in advance!
Cheers
Meino
Re: [gentoo-user] Strange hickups while trying to compile a kernel in a chroot
On 02/25/2017 07:23 AM, meino.cra...@gmx.de wrote:
> hi,
>
> I am trying to build a linux kernel (vanilla from ftp.kernel.org)
> in my chrooted new root.
>
> make modules install
>
> failed
>
> with:
>
> CHK include/config/kernel.release
> CHK include/generated/uapi/linux/version.h
> CHK include/generated/utsrelease.h
> CHK include/generated/bounds.h
> CHK include/generated/timeconst.h
> CHK include/generated/asm-offsets.h
> CALLscripts/checksyscalls.sh
> CHK include/generated/compile.h
> ./scripts/gen_initramfs_list.sh: Cannot open '/usr/share/v86d/initramfs'
> make[1]: *** [usr/Makefile:73: usr/initramfs_data.cpio.gz] Error 1
> make: *** [Makefile:988: usr] Error 2
>
>
> make bImage fails with
>
> (chroot) make bzImage
> CHK include/config/kernel.release
> CHK include/generated/uapi/linux/version.h
> CHK include/generated/utsrelease.h
> CHK include/generated/bounds.h
> CHK include/generated/timeconst.h
> CHK include/generated/asm-offsets.h
> CALLscripts/checksyscalls.sh
> CHK include/generated/compile.h
> ./scripts/gen_initramfs_list.sh: Cannot open '/usr/share/v86d/initramfs'
> make[1]: *** [usr/Makefile:73: usr/initramfs_data.cpio.gz] Error 1
> make: *** [Makefile:988: usr] Error 2
>
>
> I look for the magic v83d and found (being at my old root)
>
> [I] sys-apps/v86d
> Available versions: 0.1.10 {debug x86emu}
> Installed versions: 0.1.10(02:34:27 02/28/11)(x86emu -debug)
> Homepage:https://dev.gentoo.org/~spock/projects/uvesafb/
> Description: A daemon to run x86 code in an emulated environment
>
> Is this "quite normal" or does the make process of the kernel make
> false conclusion while being chrooted?
>
> Do I really need initram? ... For years I though my grub had
> booted the kernel which runs my linux directlu...
>
> My commandline to build the kernel at my old root was:
>
> kernel=/boot/vmlinuz-4091200-64-RT && make -j7 all && make -j7
> modules_install && /bin/cp -f ./arch/x86_64/boot/bzImage* $kernel; emerge
> nvidia-drivers ;emerge app-emulation/virtualbox-modules ;grub-mkconfig -o
> /boot/grub/grub.cfg
>
> whjch had.
>
> v86d is not installed yet and of course I will install it if needed.
> But I want to get shure, that the chrooted environment has not
> confused the kernel build process...
>
> Thanks for any help in advance!
> Cheers
> Meino
Check the CONFIG_INITRAMFS_SOURCE option.
How did you configure the kernel? Did you used the .config file from
your root system or perhaps ran make oldconfig (I think it tries to use
/proc/config.gz if it can't find it in /boot)?
--
Fernando Rodriguez
Re: [gentoo-user] Strange hickups while trying to compile a kernel in a chroot
Fernando Rodriguez [17-02-25 14:36]:
> On 02/25/2017 07:23 AM, meino.cra...@gmx.de wrote:
> > hi,
> >
> > I am trying to build a linux kernel (vanilla from ftp.kernel.org)
> > in my chrooted new root.
> >
> > make modules install
> >
> > failed
> >
> > with:
> >
> > CHK include/config/kernel.release
> > CHK include/generated/uapi/linux/version.h
> > CHK include/generated/utsrelease.h
> > CHK include/generated/bounds.h
> > CHK include/generated/timeconst.h
> > CHK include/generated/asm-offsets.h
> > CALLscripts/checksyscalls.sh
> > CHK include/generated/compile.h
> > ./scripts/gen_initramfs_list.sh: Cannot open '/usr/share/v86d/initramfs'
> > make[1]: *** [usr/Makefile:73: usr/initramfs_data.cpio.gz] Error 1
> > make: *** [Makefile:988: usr] Error 2
> >
> >
> > make bImage fails with
> >
> > (chroot) make bzImage
> > CHK include/config/kernel.release
> > CHK include/generated/uapi/linux/version.h
> > CHK include/generated/utsrelease.h
> > CHK include/generated/bounds.h
> > CHK include/generated/timeconst.h
> > CHK include/generated/asm-offsets.h
> > CALLscripts/checksyscalls.sh
> > CHK include/generated/compile.h
> > ./scripts/gen_initramfs_list.sh: Cannot open '/usr/share/v86d/initramfs'
> > make[1]: *** [usr/Makefile:73: usr/initramfs_data.cpio.gz] Error 1
> > make: *** [Makefile:988: usr] Error 2
> >
> >
> > I look for the magic v83d and found (being at my old root)
> >
> > [I] sys-apps/v86d
> > Available versions: 0.1.10 {debug x86emu}
> > Installed versions: 0.1.10(02:34:27 02/28/11)(x86emu -debug)
> > Homepage:https://dev.gentoo.org/~spock/projects/uvesafb/
> > Description: A daemon to run x86 code in an emulated
> > environment
> >
> > Is this "quite normal" or does the make process of the kernel make
> > false conclusion while being chrooted?
> >
> > Do I really need initram? ... For years I though my grub had
> > booted the kernel which runs my linux directlu...
> >
> > My commandline to build the kernel at my old root was:
> >
> > kernel=/boot/vmlinuz-4091200-64-RT && make -j7 all && make -j7
> > modules_install && /bin/cp -f ./arch/x86_64/boot/bzImage* $kernel; emerge
> > nvidia-drivers ;emerge app-emulation/virtualbox-modules ;grub-mkconfig -o
> > /boot/grub/grub.cfg
> >
> > whjch had.
> >
> > v86d is not installed yet and of course I will install it if needed.
> > But I want to get shure, that the chrooted environment has not
> > confused the kernel build process...
> >
> > Thanks for any help in advance!
> > Cheers
> > Meino
>
> Check the CONFIG_INITRAMFS_SOURCE option.
>
> How did you configure the kernel? Did you used the .config file from
> your root system or perhaps ran make oldconfig (I think it tries to use
> /proc/config.gz if it can't find it in /boot)?
>
>
>
> --
>
> Fernando Rodriguez
>
Hi Fernando,
I used the config I used for building the kernel of the 'old' root.
The new root is intended to replace the old root on the same machine.
Its even the same kernel source...
So everything should fine.
Even if it will use /proc/config.gz it will find the config of
the current kernel running the old root (and that way the chrooted
rooot).
scratching my head...
I will check the configs...may be there is something not readable
(permissions) ... I had copied a lot back and forth (I bought one
of those crappy harddiscs, which became full after a while...;)
Cheers
Meino
Re: [gentoo-user] Strange hickups while trying to compile a kernel in a chroot
On Sat, Feb 25, 2017 at 8:59 AM, wrote: > Fernando Rodriguez [17-02-25 14:36]: >> >> Check the CONFIG_INITRAMFS_SOURCE option. >> > > I will check the configs...may be there is something not readable > (permissions) ... I had copied a lot back and forth (I bought one > of those crappy harddiscs, which became full after a while...;) > Did you actually check the CONFIG_INITRAMFS_SOURCE option? It should be blank. If it is not, then whatever file it points to must exist. It might exist on your host, but not in your chroot. This option builds a kernel with an embedded initramfs, which is not normally something you need. Some Linux live DVDs might use something like this, but normal desktops generally do not. If your .config file originated from one of these that could explain the issue. Even if you wanted an initramfs this isn't the way to go about it. (A bit of trivia, Linux actually ALWAYS has an embedded initramfs, but by default it is empty.) -- Rich
Re: [gentoo-user] Strange hickups while trying to compile a kernel in a chroot
On Sat, 25 Feb 2017 13:23:11 +0100, meino.cra...@gmx.de wrote:
> make bImage fails with
>
> (chroot) make bzImage
> CHK include/config/kernel.release
> CHK include/generated/uapi/linux/version.h
> CHK include/generated/utsrelease.h
> CHK include/generated/bounds.h
> CHK include/generated/timeconst.h
> CHK include/generated/asm-offsets.h
> CALLscripts/checksyscalls.sh
> CHK include/generated/compile.h
> ./scripts/gen_initramfs_list.sh: Cannot open
> '/usr/share/v86d/initramfs' make[1]: *** [usr/Makefile:73:
> usr/initramfs_data.cpio.gz] Error 1 make: *** [Makefile:988: usr] Error
> 2
>
>
> I look for the magic v83d and found (being at my old root)
>
> [I] sys-apps/v86d
> Available versions: 0.1.10 {debug x86emu}
> Installed versions: 0.1.10(02:34:27 02/28/11)(x86emu -debug)
> Homepage:
> https://dev.gentoo.org/~spock/projects/uvesafb/ Description: A
> daemon to run x86 code in an emulated environment
>
> Is this "quite normal" or does the make process of the kernel make
> false conclusion while being chrooted?
>
> Do I really need initram? ... For years I though my grub had
> booted the kernel which runs my linux directlu...
Since kernel 2.6 (I think) the kernel has always had an initramfs built
in, this is separate from the standalone initramfs files built by the
likes of dracut. It is empty by default but it is there, so it is not
surprising to see build output relating to the intiramfs even if you do
not use one.
Are you cross-compiling here? That's the obvious reason for requiring
v86d. If not, there is no need to chroot to build a kernel, just cd to
its directory, although chrooting is needed to run make
{,modules_}install.
--
Neil Bothwick
USENET: Uniting Spammers, Erotomaniacs, Newbies, Extroverts and Trolls
pgpQqHXLbzhrA.pgp
Description: OpenPGP digital signature
Re: [gentoo-user] Strange hickups while trying to compile a kernel in a chroot
Rich Freeman [17-02-25 15:16]: > On Sat, Feb 25, 2017 at 8:59 AM, wrote: > > Fernando Rodriguez [17-02-25 14:36]: > >> > >> Check the CONFIG_INITRAMFS_SOURCE option. > >> > > > > I will check the configs...may be there is something not readable > > (permissions) ... I had copied a lot back and forth (I bought one > > of those crappy harddiscs, which became full after a while...;) > > > > Did you actually check the CONFIG_INITRAMFS_SOURCE option? It should > be blank. If it is not, then whatever file it points to must exist. > It might exist on your host, but not in your chroot. > > This option builds a kernel with an embedded initramfs, which is not > normally something you need. Some Linux live DVDs might use something > like this, but normal desktops generally do not. If your .config file > originated from one of these that could explain the issue. > > Even if you wanted an initramfs this isn't the way to go about it. > > (A bit of trivia, Linux actually ALWAYS has an embedded initramfs, but > by default it is empty.) > > -- > Rich > Hi Rich, yes the option was set for what reason ever...I will clear that. Next question...: Do I need v86d still then? Another thing which drives me crazy: Linux-headers! emerge insists of installing linux-headers-4.10. I am runnig 4.9.12. Unstable is globally set (~amd64). But giviing emerge sys-kernel/linux-headers-4.9 or emerge 'sys-kernel/linux-headers-4.9' gives me !!! 'sys-kernel/linux-headers-4.9' is not a valid package atom. !!! Please check ebuild(5) for full details. Even emerge sys-kernel/linux-headers-4.10 or emerge 'sys-kernel/linux-headers-4.10' results in !!! 'sys-kernel/linux-headers-4.10' is not a valid package atom. !!! Please check ebuild(5) for full details. . I only can do emerge sys-kernel/linux-headers but (as mentioned above) it installs 4.10. not 4.9. v86d does not compile with 4.10. ebuild (5) suggests to do, what I have done/written above. Doing a complete rebuild of the root of years of running gentoo is a hrm. intersting...hrmmmexperience... ;) Cheers Meino
Re: [gentoo-user] Strange hickups while trying to compile a kernel in a chroot
Neil Bothwick [17-02-25 15:24]:
> On Sat, 25 Feb 2017 13:23:11 +0100, meino.cra...@gmx.de wrote:
>
> > make bImage fails with
> >
> > (chroot) make bzImage
> > CHK include/config/kernel.release
> > CHK include/generated/uapi/linux/version.h
> > CHK include/generated/utsrelease.h
> > CHK include/generated/bounds.h
> > CHK include/generated/timeconst.h
> > CHK include/generated/asm-offsets.h
> > CALLscripts/checksyscalls.sh
> > CHK include/generated/compile.h
> > ./scripts/gen_initramfs_list.sh: Cannot open
> > '/usr/share/v86d/initramfs' make[1]: *** [usr/Makefile:73:
> > usr/initramfs_data.cpio.gz] Error 1 make: *** [Makefile:988: usr] Error
> > 2
> >
> >
> > I look for the magic v83d and found (being at my old root)
> >
> > [I] sys-apps/v86d
> > Available versions: 0.1.10 {debug x86emu}
> > Installed versions: 0.1.10(02:34:27 02/28/11)(x86emu -debug)
> > Homepage:
> > https://dev.gentoo.org/~spock/projects/uvesafb/ Description: A
> > daemon to run x86 code in an emulated environment
> >
> > Is this "quite normal" or does the make process of the kernel make
> > false conclusion while being chrooted?
> >
> > Do I really need initram? ... For years I though my grub had
> > booted the kernel which runs my linux directlu...
>
> Since kernel 2.6 (I think) the kernel has always had an initramfs built
> in, this is separate from the standalone initramfs files built by the
> likes of dracut. It is empty by default but it is there, so it is not
> surprising to see build output relating to the intiramfs even if you do
> not use one.
>
> Are you cross-compiling here? That's the obvious reason for requiring
> v86d. If not, there is no need to chroot to build a kernel, just cd to
> its directory, although chrooting is needed to run make
> {,modules_}install.
>
>
> --
> Neil Bothwick
>
> USENET: Uniting Spammers, Erotomaniacs, Newbies, Extroverts and Trolls
Hi Neil,
no, no crosscompiling at this point and for this purpose. I am
building the new root on the same machine as the old one is running.
I simply want to check out, whether essential things work before
finally booting into the new root (to prevent an """endless"""
back-and-forth-booting-experience).
Cheers
Meino
Re: [gentoo-user] Strange hickups while trying to compile a kernel in a chroot
On Sat, Feb 25, 2017 at 9:26 AM, wrote: > > yes the option was set for what reason ever...I will clear that. > Next question...: Do I need v86d still then? Probably not, but I have no idea why you even had it in the first place. > > Another thing which drives me crazy: > Linux-headers! > emerge insists of installing linux-headers-4.10. I am runnig > 4.9.12. Unstable is globally set (~amd64). In general I don't think matching the exact kernel version is important, though perhaps v86d cares if you need that. > > But giviing > > emerge sys-kernel/linux-headers-4.9 > or > emerge 'sys-kernel/linux-headers-4.9' > > gives me > > !!! 'sys-kernel/linux-headers-4.9' is not a valid package atom. > !!! Please check ebuild(5) for full details. > > Even > > emerge sys-kernel/linux-headers-4.10 > or > emerge 'sys-kernel/linux-headers-4.10' > > results in > > !!! 'sys-kernel/linux-headers-4.10' is not a valid package atom. > !!! Please check ebuild(5) for full details. > The syntax would be emerge '=sys-kernel/linux-headers-4.9' The = is critical, since that makes it an atom. Depending on your shell you might or might not need quotes. Again, I'm not sure you really need to worry about it. -- Rich
Re: [gentoo-user] Network scanner
On 02/24/2017 01:46 PM, the...@sys-concept.com wrote: > > No, Brother only supply rpm or deb drivers. > I was able to use "rpm" to install brother driver this way, so it should > work with the scanner as well. > This is not always the case, I had a Dell printer using an RPM that would not install properly. It was placing files in places where Gentoo did not expect to see them. I unpacked it and installed it manually and got it working. The easiest way to install it is to see if there's an ebuild available in an overlay. Scanners can be picky in linux. I bought a Canon flatbad knowing it had support in linux. A newer model of the same line of scanner that I have is *not* supported properly in linux. To give you an idea. Dan
Re: [gentoo-user] Need coaching with emerge failure logs (Understanting the problem)
On 170225-09:19-0500, Harry Putnam wrote: > Setup: VBox vm running gentoo(amd64) guest on a win-10 (64bit) host > Hardware: HP xw8600 - 2x Xeon CPU X5450 @ 3.00GHz - 32 GB ram > [ some cca. 80k text cut here ] Go for the guides, in which you will find that sending 5.5M log in an email is plain wrong. Read e.g. how to post bugs on Bugzilla. shouldn't be hard to find. Regards! -- Miroslav Rovis Zagreb, Croatia http://www.CroatiaFidelis.hr signature.asc Description: Digital signature
[gentoo-user] SHA-1 has just been broken
https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html ( you know I hate the Schmoog, and didn't take their cookies, and so they didn't show me their page in my Palemoon --working great here!, an Angel of Honesty in comparison to Firefox --and if anybody else don't want Schmoog prying in his machine, likely: $ wget \ https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html will do just fine as it did for me. ) -- Miroslav Rovis Zagreb, Croatia http://www.CroatiaFidelis.hr signature.asc Description: Digital signature
Re: [gentoo-user] Network scanner [SOLVED]
On 02/24/2017 03:19 PM, Dale wrote: > the...@sys-concept.com wrote: >> On 02/24/2017 02:28 PM, Alan McKinnon wrote: >>> On 24/02/2017 23:25, the...@sys-concept.com wrote: I've a Brother scanner ADS-2400N connected via network port. [snip] > > Unless you are using portage to install the Brother drivers, I don't > think that setting will matter. Emerge takes note of settings there > when it is about to build packages. If you install a package by hand, > outside portage, it won't likely matter. > > I might add this for future reference. Before buying equipment, make > sure it works with Linux, the distro you use for sure. Some brands work > pretty easy but has some models that don't. HP for example generally > works however, I've seen certain models that have something unique about > them that causes them to not work at all or only certain limited > functions. In my experience Lexmark is one that I have never got to > work, any model. I avoid Lexmark like it's a disease. Scanners are in > the same boat as printers, since some have both built in. > > I've seen on this list where some seem to have got Brother to work. > Maybe a search of past threads would shed some light. They might have > some tiny snippet that helps get you on the road to success. > > Dale > > :-) :-) Apology for all those annoying questions. I was able to make it to work: rpm -ihv --nodeps brscan4-0.4.4-1.x86_64.rpm emerge -avq media-gfx/brother-scan3-bin brsaneconfig4 -a name=Brother model=ADC-2400N ip=10.0.0.138 I know, mixing portage with rpm is not a good idea. Brother ADS-2400N scanner works with USB, Network connection, duplex works as well. The mail reason I bought this scanner is that it can be connected to network and has TWAIN driver (my Fujitsu ScanSnap-junk doesn't have one). However, following your suggestion I found "ebuild" in overlay for this scanner, so I reversed the installation and used ebuild: media-gfx/brother-ads2400n-bin The only annoying feature in this scanner is that doesn't have "auto crop" (windows does) auto-feeder does not work. Scanning small receipts showing black borders on both sides (snapscan borders are white - easier to fax, print). I'll need to ask Brother support if it possible to change the borders to white background. -- Thelma
Re: [gentoo-user] Need coaching with emerge failure logs (Understanting the problem)
> On 25 Feb 2017, at 14:19, Harry Putnam wrote: > > I've attached a hefty log of some 4000 lines and hope someone will be > patient enough to try to identify what is causing the problem. I took a look at this, but the broken colour codes throughout the log make it quite hard to read. Example at the beginning: [32;01m * [39;49;00m Example from the end: [31;01m*[0m Output to the terminal these would show the text in different colours, but the output was redirected to a textfile or mishandled in a copy-paste operation (not sure if screen or tmux does this?). Running emerge with `--color n` would have made this log much more readable. Its size already makes it hard to search. Stroller.
Re: [gentoo-user] SHA-1 has just been broken
On Saturday, February 25, 2017, Miroslav Rovis wrote: > https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html > > -- > Miroslav Rovis > Zagreb, Croatia > http://www.CroatiaFidelis.hr > Very interesting. The first useful SHA-1 collision was, if I remember, done in 2015, and subverted an HTTPS certificate (though not one which had been issued). This was some guys with a couple of servers lined with graphics cards. Seeing someone manage to do it in a garage a number of years before it was cosidered feasible should, hopefully, make you have more conservative estimates of the strength of modern cryptography. Aside: http://ecrypt-eu.blogspot.com/2015/11/break-dozen-secret-keys-get-million.html R0b0t1.
[gentoo-user] This time git failed to install
Hi,
...still trying to build a new root...
(I am using a globally set ~amd64.)
This morning emerge presented me a new (at least for me)
error while trying to update @world related to git:
./check_bindir "z$bindir" "z$execdir" "$bindir/git-add"
* ERROR: dev-vcs/git-2.12.0::gentoo failed (install phase):
* !!! newexe:
/var/tmp/portage/dev-vcs/git-2.12.0/work/git-2.12.0/contrib/gitview/gitview
does not exist
*
Searching with startpage I didnt find anything related.
I took a look in the build.log and as it seems the install procedure
looks for something (gitview) that is no longer meant to
be included/build.
The build.log does not show a compilation/link error, which would result
in a missing gitview (it shows no error/failure at all beside the
installation problem). The first time gitview is mentioned in the log
is when trying to install it.
The USE flags look unsuspicous to me:
[U] dev-vcs/git
Available versions: 2.7.3-r1 (~)2.7.4 (~)2.8.4 (~)2.9.3 (~)2.10.1 2.10.2
(~)2.11.0 (~)2.11.1 (~)2.12.0 ** **-r1 **-r2 **-r3 {+blksha1
cgi +curl cvs doc emacs gnome-keyring +gpg gtk highlight +iconv libressl
libsecret mediawiki mediawiki-experimental +nls +pcre +perl ppcsha1 +python
subversion test +threads tk +webdav xinetd LINGUAS="bg ca de fr is it ko pt_PT
ru sv vi zh_CN" PYTHON_TARGETS="python2_7"}
Installed versions: 2.11.1(05:13:31 PM 02/18/2017)(blksha1 curl gpg gtk
iconv nls pcre perl python threads webdav -cgi -cvs -doc -emacs -gnome-keyring
-highlight -libressl -mediawiki -mediawiki-experimental -ppcsha1 -subversion
-test -tk -xinetd LINGUAS="-bg -ca -de -fr -is -it -ko -pt_PT -ru -sv -vi
-zh_CN" PYTHON_TARGETS="python2_7")
Homepage:http://www.git-scm.com/
Description: stupid content tracker: distributed VCS designed for
speed and efficiency
Do I need a patch or is it a PEBKAC/PICNIC? ;)
Cheers
Meino
