Re: bad hash in repo

[Randy Bush]

> Is there any possibility there’s something between these you and these
> update hosts?

it is the internet; anything is possible :)  but the hosts having the
problem are on the nekkid global interner.
> 
> This thread has some interesting info

i need to tcpdump.  i'll try to do so in a day or three.

randy
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: bad hash in repo

[Charles Sprickman via freebsd-stable]

> On Sep 2, 2018, at 6:46 AM, Randy Bush  wrote:
> 
> someone asked if the failures were limited to update5.freebsd.org
> 
> today's batch were both 4 and 5

Is there any possibility there’s something between these you and these update 
hosts?

This thread has some interesting info, but specifically, note the description 
of how phttpget works at the bottom - it is NOT at all picky about what it 
receives, and seems to have some quirks:

https://lists.freebsd.org/pipermail/freebsd-stable/2015-December/083882.html 


Charles

> randy
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Problem reports for sta...@freebsd.org that need special attention

[bugzilla-noreply]

To view an individual PR, use:
  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id).

The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and obsolete releases.

Status  |Bug Id | Description
+---+---
New |230620 | "install -d" issue
Open|227213 | FreeBSD 10.4 kernel deadlocks on sysctlmemlock

2 problems total for which you should take action.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Failing to retrieve source tarballs for anything.

[Dave Cottlehuber]

On Sat, 1 Sep 2018, at 19:25, Alex McKeever wrote:
> After compiling PKG, when I go to ports to compile anything (my eMac can 
> run FreeBSD but not modern Linux due to the version of the Radeon GPU) 

Is it one these, https://en.wikipedia.org/wiki/EMac ?

A dmesg and ifconfig of this "eMac" may be helpful, and a specific model number 
in case somebody else already bashed their head against it enough to get a 
working setup.

Does it even get an interface up & running in some form?

Maybe start off with throwing a  USB ethernet wired adapter onto it and hoping 
a miracle occurs.

A+
Dave
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[Bug 228536] x11/nvidia-driver: 11.2-BETA3 - fails to operate correctly

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228536

--- Comment #11 from Kalero  ---
(In reply to Lena from comment #10)
Well, while I was waiting for an answer, I installed FreeBSD-11.2-RELEASE,
installed nvidia-driver-340 from ports and, to check if the binary package also
worked, removed the port with "make deinstall clean" and installed the
nvidia-driver-340 binary package with pkg. My surprise was it works, so after
reading your answer I don't understand why after deinstalling the port and
installing the binary package it's working.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[Bug 228536] x11/nvidia-driver: 11.2-BETA3 - fails to operate correctly

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228536

--- Comment #10 from Lena  ---
> Does this known bug also apply to nvidia-driver-340?

Yes. Install from ports (make or portupgrade/portmaster). I have almost all
others installed from packages.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[Bug 228536] x11/nvidia-driver: 11.2-BETA3 - fails to operate correctly

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228536

Kalero  changed:

   What|Removed |Added

 CC||cronicasdebolsi...@gmail.co
   ||m

--- Comment #9 from Kalero  ---
Does this known bug also apply to nvidia-driver-340? I'm going to install
FreeBSD-11.2-RELEASE and I have an NVIDIA GeForce 210, so I have to install
nvidia-driver-340. Thanks.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Constraints in libmap(32).conf do not work as expected, possible bug in rtld-elf

[Konstantin Belousov]

On Sat, Sep 01, 2018 at 12:32:07AM +0200, Andreas Longwitz wrote:
> On a FreeBSD 10.4-STABLE r337823 (amd64) server I have to run some old
> php52 scripts from an FreeBSD 8.4-STABLE r284383 (i386) server. I have
> copied the old php software to /usr/local/php52, installed the ports
> misc/compat8x and misc/compat9x and have copied all missing 32-bit
> libraries from the old machine to /usr/local/lib32. With the following
> libmap32.conf everything works fine:
> 
> ## php52
> /usr/local/lib  /usr/local/lib32
> /usr/local/lib/mysql/usr/local/lib32/mysql
> 
> Two examples:
> 
> -> ldd /usr/local/php52/bin/php
> /usr/local/php52/bin/php:
> libcrypt.so.5 => /usr/lib32/libcrypt.so.5 (0x28273000)
> librt.so.1 => /usr/lib32/librt.so.1 (0x28292000)
> libm.so.5 => /usr/lib32/libm.so.5 (0x28298000)
> libxml2.so.5 => /usr/local/lib32/libxml2.so.5 (0x282c2000)
> libz.so.5 => /usr/local/lib32/compat/libz.so.5 (0x283ec000)
> libiconv.so.3 => /usr/local/lib32/libiconv.so.3 (0x283fe000)
> libc.so.7 => /usr/lib32/libc.so.7 (0x284f2000)
> libthr.so.3 => /usr/lib32/libthr.so.3 (0x2866c000)
> 
> -> ldd /usr/local/php52/lib/php/20060613/mysql.so
> /usr/local/php52/lib/php/20060613/mysql.so:
> libmysqlclient.so.16 =>
> /usr/local/lib32/mysql/libmysqlclient.so.16 (0x28206000)
> libc.so.7 => /usr/lib32/libc.so.7 (0x2807)
> libcrypt.so.5 => /usr/lib32/libcrypt.so.5 (0x2835e000)
> libm.so.5 => /usr/lib32/libm.so.5 (0x2837d000)
> libz.so.5 => /usr/local/lib32/compat/libz.so.5 (0x283a7000)
> librt.so.1 => /usr/lib32/librt.so.1 (0x283b9000)
> libthr.so.3 => /usr/lib32/libthr.so.3 (0x283bf000)
> 
> Because I like to use constraints in libmap32.conf I chenged the file to
> 
> ## php52
> [/usr/local/php52/]
> /usr/local/lib  /usr/local/lib32
> 
> [/usr/local/php52/lib/php/20060613/mysql.so]
> /usr/local/lib/mysql/usr/local/lib32/mysql
> 
> The same examples as above shows that libmap does not work anymore:
> 
> -> ldd /usr/local/php52/bin/php
> /usr/local/php52/bin/php:
> libcrypt.so.5 => /usr/lib32/libcrypt.so.5 (0x28273000)
> librt.so.1 => /usr/lib32/librt.so.1 (0x28292000)
> libm.so.5 => /usr/lib32/libm.so.5 (0x28298000)
> libxml2.so.5 => not found (0)
> libz.so.5 => /usr/local/lib32/compat/libz.so.5 (0x282c2000)
> libiconv.so.3 => not found (0)
> libc.so.7 => /usr/lib32/libc.so.7 (0x282d4000)
> libthr.so.3 => /usr/lib32/libthr.so.3 (0x2844e000)
> 
> -> ldd /usr/local/php52/lib/php/20060613/mysql.so
> /usr/local/php52/lib/php/20060613/mysql.so:
>libmysqlclient.so.16 => not found (0)
>libc.so.7 => /usr/lib32/libc.so.7 (0x2807)
> 
> The constraints in libmap.conf are handled in rtld-elf with the help of
> contexts, and especially a "$DEFAULT$" context is used for all entries
> in libmap.conf before the first constraint statement. Now when rtld-elf
> loads a program the mapping rules from libmap.conf are applied. In a
> first step rtld-elf does a direct mapping using the correct context. But
> in a second step called "Searching for ..." rtld-elf uses always the
> "$DEFAULT$" context, which in the last example is empty. Therfore
> rtld-elf does never find a library in his searching step and cannot load
> programs where searching for libraries is necessary.
> 
> I cannot see any reason why rtld-elf should change the context between
> step1 and step2, The following patch provokes that rtld-elf uses the
> context from step1 in step2 too:
I am having problem understanding what do you mean by step1/step2. The
refobj reference that you cache in the patch, comes into load_object()
as the pointer to the object which initiate the load_object() call. It
is NULL for preloaded objects, otherwise it is not.
So, could you, please, explain where does it get passed as NULL in your
case ?

Also, your patch makes the ref_object stuck for all future invocations
of the load_object(), so it cannot be correct for this reason alone.

Another note is that libmap.conf use that you put it for, is quite the
strengthen of the original purpose.  You should just add the pathes
with your libraries to LD_32_LIBRARY_PATH or configure them into
/var/run/ld-elf32.so.hints using 'ldconfig -32'.

> 
> --- rtld.c.orig 2018-03-20 16:56:48.0 +0100
> +++ rtld.c  2018-08-31 23:17:18.051206000 +0200
> @@ -186,6 +186,7 @@
>  static Obj_Entry obj_rtld; /* The dynamic linker shared object */
>  static unsigned int obj_count; /* Number of objects in obj_list */
>  static unsigned int obj_loads; /* Number of loads of objects (gen count) */
> +static char *save_refobj_path;
> 
>  static Objlist list_global =   /* Objects dlopened with RTLD_GLOBAL */
>STAILQ_HEAD_INITIALIZER(list_global);
> @@ -1499,6 +1500,7 @@
>  if (libmap_disable || !objgiven ||
> (name = lm_find(refobj->path, xname)) == NULL)
> name = (char *)xname;

Re: bad hash in repo

[Randy Bush]

someone asked if the failures were limited to update5.freebsd.org

today's batch were both 4 and 5

randy
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Failing to retrieve source tarballs for anything.

[Ronald Klop]

First guess... Connect a network cable.


Please copy-paste the error message in your mail. It helps people helping you.
Any relevant message in /var/log/messages? 



Regards, 
Ronald.



Sorry for top posting, my mobile mail app does this.


Van: Alex McKeever 
Datum: 01 september 2018 23:06
Aan: Ronald Klop , FreeBSD Stable , 
FreeBSD Current 
Onderwerp: Re: Failing to retrieve source tarballs for anything.





I simply changed directory to which thing I want to compile in /ports, run the 
command make install, and after a short while it fails to retrieve the source 
archive (.tar.gz)


Sent from Yahoo Mail for iPhone


On Saturday, September 1, 2018, 4:56 PM, Ronald Klop  
wrote:


It helps a lot of you send the exact command you run with the error message. Or 
all the significant output.




Regards,
Ronald


Van: Alex McKeever 
Datum: 01 september 2018 19:50
Aan: FreeBSD Stable , FreeBSD Current 

Onderwerp: Failing to retrieve source tarballs for anything.



After compiling PKG, when I go to ports to compile anything (my eMac can run 
FreeBSD but not modern Linux due to the version of the Radeon GPU) it fails to 
retrieve any of the source tarballs for any of the software, desktop 
environments etc. I would like help to fix this, as I’d like to run something 
current.


Sent from Yahoo Mail for iPhone
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"









___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"